What should I do to ensure that projects do not take 2-3 times longer than planned? Part 2

Let's continue the discussion of the tools and methods for meeting the deadlines of the projects, given that the previous topic caused a rather active discussion and more than two hundred people added the topic to their favorites. This time the post will be more dull , I will try to give more detailed recommendations in text form.

The following set of recommendations looks like this:

• Make sure the term is really tough.
• Do not take on projects with unrealistic deadlines
• Plan using the oncoming wave method.
• Periodically review project evaluation
• Evaluate the project empirically
• Involve the team in the initial assessment

Make sure the deadline is really tough.

The most surprising thing about many “super-urgent” projects is that their deadline is not really tight. And the result is pressure on the team, sacrifices of functionality and, in the worst case, quality. The team or project manager needs to make sure that the rigidity of the term is objective, for example, the date of the event for the presentation of the product that cannot be affected. An example of a not tight deadline is the early estimate of the project deadlines without detailed analysis, voiced by the management: it is necessary to revise it and conduct appropriate negotiations to change the deadlines.

Do not take on projects with unrealistic deadlines

Another antipattern is a team taking on obligations to implement a project with an unrealistic period, and this is often clear before the project starts. The problem is that the team considers such a forced taking of the project as an order “from above” and the responsibility for the deadline remains only formal. Upon the unsuccessful completion of the project, the team will say: “We warned you in advance that it was impossible to sustain the deadlines.” Usually the most correct solution for this type of project is a sharp reduction in the amount of functionality implemented for the first release.

Plan using the oncoming wave method.

For large projects it is very important to have a competent and realistic work plan. Let's take an example with a map on which Michael Wolf made a plan. It was virtually the same size throughout, and because of this, problems started at the very beginning of the project. The correct method in this case would be Rolling Wave Planning: for the first section that we are going to go, we make a more detailed plan, use a map with a large scale, look at the photos of the area, and sections that we pass later - View on a map with a small scale.

For project activities under PMBoK, this approach means more detailed decomposition of work in the SRI for the first stages of project implementation. In flexible methodologies, the same approach is used: we store elements of backlog with high importance, broken into small “pieces”, and elements of backlog with low importance are stored in the form of large epics. Those. the team has a detailed backlog for one or two sprints ahead.

On the other hand, the fact that we do not describe the whole functionality of the project allows us to avoid the Big Upfront Design approach and launch development for a long time, not to mention the fact that quite a large part of the requirements (design layouts, etc.) will simply "go to sleep" when it comes to turn.

')

Periodically review project evaluation

When using the waterfall approach, it is necessary to revise the estimate of completion dates at the end of each stage of work, and if the critical chain method is used, such an assessment can be made more quickly using the project buffer. In iterative methodologies, such a reassessment is recommended to be done at the end of the next iteration.

The fact is that assessments made at an early stage of a project, as a rule, contain a very large amount of uncertainty. Over time, this uncertainty is clarified (some of the risks are removed) and the assessment can be given more accurate. The classic illustration to the above is the “cone of uncertainty”:

Evaluate the project empirically

Estimation based on the speed of the team is fairly accurate, so it should be used in all projects where this is possible. Run a few sprints and determine how much functionality (for example, in storypoints) your team does and calculate the total completion time of the project. Such fact-based planning provides fairly accurate estimates.

Involve the team in the initial assessment

Quite often it is necessary to evaluate projects at a very early stage. As mentioned above, such an assessment has nothing to do with reality is not very accurate. Accuracy can be increased by involving the team (or its core) from the very early project stage in the assessment; the team will additionally share responsibility for the specified time frame.

Links

Ten deadly sins in assessing the complexity of software development