Five planning observations

In this short article there will be some thoughts about the general problems of delaying projects. Some of them lie at the junction between planning technologies and development technologies. If you are faced with the fact that after the middle of the project, each step does not really bring it closer to completion - you know, the plan was so-so. More specifically under the cut.

Why you need to look for a problem in terms of

It doesn’t matter whether it’s a flexible or waterfall plan - being any, it determines the order in which the functionality appears (even if it is internal or intermediate). The actual term is a function not only of the amount of functionality per person, but also of the quality of the product (even if not the code), and it is monotonously increasing in volume, monotonous in quality, although limited in this case. Write at least hello world, even though the search engine - the quality of course, but the functionality can be added and changed indefinitely.

It remains the reason for the change of the actual terms when fixing the volume and quality - only the "internal kitchen", what is done in what order. Naturally, all this is for some abstract programmer within the 40-hour work week.
Now go deeper into specifics.

What are the problems and what to do

Curvature of the analysis to the complexity of the synthesis

Incorrect splitting into tasks leads to the complexity of their subsequent unification into a result . What does the wrong partition mean? This is a partition in which all the tasks that have been completed do not form the final product, and the "Integration" task appears at the end. Its term can not be predicted without knowing the intermediate details. But it is, and it must be done.

Moral - you should not put off the integration risks at the end of projects. If you have, for example, an API, use appropriate development tools — for example, mock services (stubs, test data, and so on).

Overplan => overtime

The plan should not be more complex than the system; the system will not be able to be implemented with it . This follows from the fact that in order to "understand" (reflect) one system to another, the first must be no less complex, and in our case the product must be more complex than the plan. Otherwise, the plan will not be implemented, that is (if you follow the plan), the plan implements the wrong product (which, for example, in a TK).

Moral - the criterion of the adequacy of the detailed plan is a measure of the spread of its terms. If it is below the bar acceptable, the plan can be taken to work.

R & D in terms of

Research as part of a project plan is a direct path to loss . To losses precisely in project. Moreover, the research can be of the type “we will do half, and then it will be seen”, or of the type “we will lay out the choice of the framework in the project”. If you do not evaluate the project according to the event and decision tree method, then this project is very likely not to meet the deadlines. Because research can give a solution like "there is no suitable framework, you have to do it yourself."

Morality is everything, the consequences of which cannot be assessed as being acceptable for sure - should not be present in the project plan, which terms are subject to payment.

Score not by (three) points

What is the probability of making a mistake in one point (date) and what is in the interval (dates)? Naturally, a point is understood as a certain ray (to the left), but even then we have the probability of “meeting the dinosaur” from the discharge: either to the point we will or after (the probability of 50% is the lack of information in the application case). Based on this, the project’s interval time is always more accurate than a specific date — it is less risky. Of course, nobody writes an interval in contracts, there you can write the right edge for confidence. If you estimated everything at once to the maximum (and not the average of three points with the coefficients), then you would inevitably face inefficiency in a competitive market.

Moral - it is better to weigh different assessments into one than to believe one assessment (task).

Squirrel in a wheel or task-head-Gorynych

Several new tasks are added to each task when previous dependencies have not been made completely . My coach once spoke

All yours were underestimated a couple of times and they didn’t catch up three times during trainings - these are milliseconds and seconds from the first place!

Imagine that each task is not completed to the end: then in order to complete the next dependent to the end, you need to complete two already.

Moral - microservices are not in vain invented. This is a risk isolation including development. But in the case of if, splitting tasks into parts for the sake of optimizing parallelism in a project does not always speed up the project - in those cases when you need to complete the task completely.

Conclusion on the perfect plan

Summing up the morality of each story, the ideal plan goes almost inconsistent:

1. The plan grows organically, from small to large, and not from parts to whole.
2. The plan should be simpler than what is realized by it (otherwise the plan is unrealizable),
3. In terms of one project (it’s not about the series) there should not be fatal events,
4. Interval estimates give greater reliability simply by definition.
5. The plan should not be debt, everything that is used in the future, must be workable.

Something like a manifesto of flexible technologies ... but the waterfall is also not alien. Some items are easier to plan in flexible approaches, some in a waterfall. In any case, this topic, as well as considerations, points in it are not commandments, but rather information for thought. In fact, there are more such subtleties in planning, but they are more specific to the product or specific process.

All successful projects.