-- Establish project's goals and description, that is, make sure that you know what needs to be achieved and what the priorities are.
-- Identify the application users needs and wants.
-- These tasks that the application's future users perform very few times or very seldom are not good candidates for programmatic implementation if the development time exceeds the task performing time. However, all these tasks that involve computer usage and are performed more than a few times are good candidates for computerization if the task performing time clearly exceeds the development time.
Make the relevant estimations for different users and user groups, add up the total numbers and present the results to the decision makers, so that you can specify and verify what actually needs to be built.
-- Make sure that effective project development-related ROI analysis is conducted (preferably by the customer).
-- Based on the goals that need to be achieved and application users needs and wants, identify all the work that needs to be done. Divide the project into atomic-granular parts, that is, into small, clearly identified steps and tasks, so that all the steps and tasks are identified sequentially. (See the Dividing the project into small, clearly identified steps and tasks subsection for additional information on this step.)
-- Identify every needed task's resources needs, including software and hardware needed, and the skills and, as applicable, possible training needed.
-- Make sure that the customer company management is committed to the project. This includes user group management commitment, and departmental and company management commitment of people's time and other needed resources.
-- Every person who is expected to contribute to achieving the project's goals is this project's participant. Identify the project participants and their skill levels that are relevant to your project.
It is prudent to build the project development team so that unexpected participant unavailability situations are taken into consideration.
-- Assign each task the duration, that is, how much time the task's completion is expected to require from the person or persons working on it. Keep in mind the worst case scenarios. Further, keep in mind the skill levels required for individual tasks completion. For example, an experienced programmer can accomplish much more than a beginner can. Think through the tasks and be as realistic about the durations as you can.
The more creativity and problem solving does a step require, the more extra time should be scheduled for the step. Similarly, the less familiar are the programmers and other people working on the application with the specific kind of work the step requires, the more extra time should be scheduled for the step.
Using additional models designed for calculating software development labor input and cost can also be helpful (COCOMO or PERT, for example). However, no such model or method is a substitute for your ability to understand what is needed, how you are going to deliver the results and what obstacles you can anticipate.
-- Add the individual task durations together, then multiply the total duration by a number higher than 1.
If a sufficient variety of factors are taken into consideration that may affect the product delivery schedule adversely, then the resulting time reserves should be sufficient, because it is extremely unlikely that every possible factor that may affect the product delivery schedule adversely will actually materialize.
-- Then add together the realistically available time between the project's start date and end date. One person working for 8 hours gives you 8 hours of work completed, 2 persons working the same 8 hours gives you 16 hours of work completed, and so on. (If today's date is later than the project's start date, you may want to use today's date instead of the project's start date.)
When making the calculations, make sure that are able to differentiate between the tasks that can and cannot be completed faster by increased numbers of participants. For example, as has been observed for decades, it often is the case that having more programmers working on the same program does not improve productivity.
However, many software development projects contain tasks that different participants can perform simultaneously - or, these tasks can be performed by fewer people or just by one person sequentially, in which case the tasks will be most likely completed later in time. Further, in many instances teamwork can improve productivity if the participants are able to find better solutions faster through collaboration.
So, depending on the tasks, 8 + 8 can be more than 16, or it can be less than 8. As IT project developer, only your own expertise combined with your ability to obtain the right information will enable you to produce the correct results for the project planning purposes.
-- Now compare the total duration to the total available time. If the total duration exceeds the total available time, more labor resources, or more time, are needed. For example, if the total duration exceeds the total available time by factor close to 2, then approximately twice as much labor input or time is required as initially planned.
-- Similarly, identify any other gaps between the available resources (including skill levels) and project's needs.
-- In the light of project's goals and requirements review the individual tasks.
Unless extra time is available, decide what project parts can be outsourced or be done by hiring additional help. Many tasks can be done by others, even though it initially may not look that way. Further, in many cases, budget permitting, it is more economical to let the experts do the work that you don't have in-house expertise for, or that would occupy your existing labor resources for too long time. Even though your personnel may be able to acquire some of the needed skills, the project's deadlines may favor using the outside experts instead. Similarly, it may be more economical to hire (temporary) help for completing tasks that require much less skills than these people possess who are available and on your payroll.
Additional resources require additional expenditures. You can (and probably should) also try to find ways to reach the goals with fewer recourses, so that you can use the available resources in the most efficient and effective way.
Alternatively, if needed, you can drop some of the initially identified tasks. Given that these tasks are actually necessary, such reductions usually lead to reduced quality in the application that is being produced.
So, whether to focus on obtaining the necessary resources, or on getting more done with existing resources, or on dropping some project requirements, depends on what the project development-related priorities are.
-- Based on the above analysis make the necessary arrangements.
-- Always plan for having a sufficient time and labor reserve, because the reality is usually more demanding than is anticipated. I would recommend 20% to 30% time and labor (combined) reserve in addition to calculating the total duration in a safe way, using a suitable multiplier, as is recommended above.
-- Make sure that all the tasks have been assigned to project participants.
-- Make sure that all the project participants understand their roles and the work they need to do, and are able and willing to reach the goals associated with their tasks, and can and will do so by the relevant tasks' deadlines.
Further, make sure that all the project participants, including the people who work for the customer (user group representatives, for example) know what their responsibilities are. Things that nobody is responsible for tend not to get done right, or may not get done at all. When that happens and there is nobody who is responsible for the task, there isn't anybody from whom you and others can rightfully ask, why the things are the way they are.
Good planning can take you only so far; people who carry out the plans make the plans the reality. The more important role does a team member have in the project, the more important it is to have the right person for the role. Honor the project and each role in it. Choose people by analyzing and listing out the qualities that the role requires, and match the qualities that people actually have (versus that you wish they would have) to the qualities that the role requires. Every time when you choose people simply by seniority or a job position, and do not take into consideration the actual skills, aptitude and abilities, you take your project a step closer to failure. The more important the role, the bigger the step. Make it in the right direction.
-- People must be motivated to complete as many tasks as possible on time. Motivating people so that as many tasks as possible are performed on time is a project leadership issue. Balancing time between individual tasks is a project management issue.
-- During the project development these atomic-granular tasks that are completed as initially planned, that is, without having to use the extra time reserve allocated for the task, generate extra time reserves. That extra time can be used to cover unexpected shortages (that are likely to occur) that are generated by these atomic-granular tasks that were not completed on time. The project manager, who should closely monitor project's progress, should decide when, where and how the time reserves are used up.
-- While the project planning structure that is described here results in a comprehensive project development plan, the individual project development steps can be carried out somewhat autonomously, and by using certain flexible project development principles.
Project manager decides when and what principles to use, so that the project objectives are met on time and within the budget. Accordingly, at the onset of the project the project manager and other participants (especially programmers) must be informed about, and be agreeable to, the specific project management methods that will be used.
