Nine key points for successful software project planning

The ancients cloud "ten thousand issues are established, no advance is abolished", the project must be well planned to succeed. Software Project planning is the most basic process in the project management process. The software project planning method must be mastered by the software project manager. In the actual project planning process, you must master the following nine basic points:

(1) grasp the timing of project planning

The output of the software project planning process is a documented project plan. Project planning is required at different stages of the project, but the project planning objectives are different at different times, and the workload is different. When there is a summary of customer needs without the formation of a detailed software requirement specification (SRS), project planning generates a project outline plan or milestone plan, after a detailed SRS is generated, the project planning activities can generate a detailed project plan. The project scale, workload, progress, and resources can be clearly estimated, which serves as the main basis for project management. When the demand changes or the project plan is significantly different from the actual situation, you can re-plan the project. It should be noted that when the demand is not determined, the software estimation is relatively rough, and there is no need to spend too much energy on project planning.

 (2) The task must be clear

During project planning, creating a Job breakdown (WBS) is a task that must be done, that is, splitting the work into independent and clear tasks. The so-called clear tasks refer:

● The task must have an output result;
● The output format is clearly defined;
● The output content has clear detection methods and acceptance criteria;
● The task time has specific requirements.

One of the above four criteria cannot be called a clear task. In practice, some tasks are difficult to define, because some results are difficult to predict. For example, for analysis, the specific time requirements are difficult to accurately predict. If the task is unclear, it is impossible to determine whether the task has been completed.

In the project team, tasks in the subsequent stages are hard to be clearly defined due to incomplete work in the previous stage. If the design is not completed, the coding work cannot be clearly defined, which often makes it difficult for the actual coding work to be completed within the required time, forming a project risk.

(3) do not omit identified tasks

During software planning, a common problem is that tasks are not fully identified. In the actual implementation process of the project, there are often unplanned and necessary tasks of the project team, rather than interference activities outside the project team. To complete the tasks, you can create a task identification guide to remind the project manager. Frequently missed tasks include:
● Project management tasks, such as project plans, planned changes, and plan reviews;
● Horizontally associated tasks, such as integration tasks and requirement tracking matrix formulation and updating;
● Project deliverables, such as the preparation of user manuals and training materials;

(4) moderate granularity of tasks

When dividing a task, the granularity of the task cannot be too large or too small. If the granularity is too large, it is difficult to identify problems in time. If the granularity is too small, it will increase the management cost. The minimum granularity of a task can be up to half a day and up to weeks. Generally, the granularity is less than three days. That is to say, the Project Manager can check the progress of members for at least two times in one week. Proper job granularity facilitates monitoring, while also facilitates task adjustment. When a task is delayed, you can flexibly reschedule the personnel to take over the tasks of other personnel.

 (5) It should be as reasonable as possible

To ensure the rationality of estimation, the following measures can be taken:

● Use historical data. Historical data is the quantification of "experience". Through comparison with historical project data,
● This can reduce the estimated risks. It should be noted that when learning from historical data, you should pay attention to data comparability, and check whether the project type is similar and the life cycle model is similar.
● Multiple estimation methods are used for mutual verification. Multiple estimation methods can be used to compare the results of multiple methods and analyze the differences to determine the rationality.
● Subdivide tasks. The more detailed the task splitting, the easier it is to estimate and compare it with historical data.
● Complete tasks. During estimation, all work content should be identified, so there should be no omissions.
● People with estimation experience participate in the estimation. On the one hand, we need to train people involved in estimation, and on the other hand, we need to accumulate estimation experience in practice. After each estimation, we need to compare it with the actual situation ~ Five iterations can accumulate estimation experience and improve the accuracy of estimation.

　(6) Identify dependencies between tasks

There are five dependencies between tasks:

● Input/output relationships. That is, the output of task a is the input of Task B. After task a is completed, Task B can start. For example, the relationship between encoding and testing.
● Resource dependency. Task A and Task B use the same resource. When the resource is a, it cannot be B. When the resource is B, it cannot be. For example, a programmer cannot develop two modules at the same time, but must complete one module and then create another module.
● Interface relationship between requirements. That is, the outputs of task a and Task B have interfaces. The outputs of the two parts must be assembled together. If the assembled task is C, tasks A and B are not completed, task C cannot start either.
● Call relationship. For encoding tasks, if task a's code is called by Task B's code, task a must be completed first.
● Procurement relationship. If there are external components to be purchased, the purchase must be completed first.

By defining dependencies between tasks, you can identify the key paths of a project and focus on the key paths.

　　(7) prioritize the development of system architecture-related requirements

Priority should be given to the development of key functional requirements, global functional requirements, interface requirements, and non-functional requirements. These requirements have a wide range of impact. Once reworked, the workload is relatively large, therefore, you must design, implement, test, and associate these requirements before you schedule tasks. If the task sequence is not arranged during the planning, some modules cannot be associated during the later stage of the project, such as joint debugging. You need to write a test program or wait for other modules to complete.

(8) milestones for project establishment

In the process of project progress, project managers, ppqa, and CM track the progress of the project team from different aspects of the project, but lack comprehensive and systematic analysis and evaluation, the milestone review can be used to make judgments based on the analysis data of various aspects. At the project milestones, it is generally through the milestone review to comprehensively present the project progress to members outside the project team to determine whether the previous stage of work is completed and whether it can enter the next stage. Many enterprises often take the milestone review as a form, which violates the original intention of the milestone review. During the milestone review, should you note whether the progress of the project team has been fully evaluated? Did you show the progress of the project team to related personnel outside the project team? If only members of the project team participate in the milestone review, the milestones are often minor and minor, which masks the real problems and is not conducive to discovering problems in the project team.

　(9) reserved Management Buffer

There will always be unexpected events and inaccurate estimates during the project process, so we can leave a buffer time in the plan. There are two ways to set the buffer time. One is a fixed buffer, that is, there is a fixed buffer time every week or month, such as half a day or one day. Second, there is a fixed proportion of buffering before all tasks connected to the Key Path. For example, task a is a task in the Key Path, and task B is not a task in the Key Path, however, after B completes, A, B, and a can be directly sequential. In this case, a buffer time can be left between Task B and task a to reduce the progress risk.

Management buffering should be clearly identified and not hidden in each task.

I believe that the nine points above will certainly help your project planning practice!