The life of bricks. Why prioritization is a key element of planning

This is an attempt to speculate in the pictures, why projects are so difficult to produce on time, and how setting priorities can improve the situation.

So we take on the development of the project. The goals and general outlines of the project have already been defined, but so far nothing is known about its implementation. What tasks will have to be solved? What resources will be required? It is not clear.

At this stage, the project for us is a tangible, but still rather shapeless cloud.
')


What we need are the details. Starting from the goals of the project, we step by step divide it into relatively small, and most importantly - very specific tasks, the solution of which will mean the successful completion of the entire project.

As a result, the angular contours of its technical implementations emerge from the initially streamlined forms of design — in the form of a set of “building blocks” tasks that together constitute the entire project. "It is weighty, rough, visible."



So, the project is divided into separate "bricks", each of which separately is already amenable to awareness and evaluation. Our next step is to identify the resources required for the implementation of the entire project as a whole. This step is no longer so difficult - having estimated the resource intensity of each of the tasks separately, by simple summation we find out how much the whole project will cost us.

For clarity, we will present the resources of the project in the form of a table or shelf, on which, one after another, all the “building blocks” tasks that make up our project are put in a row. Each task takes a place on the shelf (that is, “consumes a resource”), the size of the shelf corresponds to the scale of the project and, of course, is limited - just as in life, time, money, or both, are usually limited.



The above actions should already give us the answer to a number of important questions:

• What resources are needed to complete a project?
• What tasks need to be solved?
• What resources will be required to complete each of the tasks?

It seems that these are not just answers to questions - this is a plan. Getting to its implementation.

As time goes by, tasks are solved one by one - and mentally set out on our fictional “resource shelf”. Now the "resource shelf" clearly shows how much of the project has already been implemented, and how much of the planned resources have actually been spent. Of course, when everything goes according to plan, each of the tasks performed will take exactly as much space on the shelf (i.e., it will devour resources) as was initially supposed, emphasizing universal world harmony.



Unfortunately, there are difficulties with world harmony. Sooner or later, some of the tasks (and usually - not one) suddenly turn out to be more difficult, more expensive, longer - or all at once. She no longer fits in the place she had been allotted to her — she was bursting , as it were.



Here comes one of the most unpleasant moments of development - bricks fell from the shelf . The tasks that spent more resources than was planned for them, not only became “more expensive” in themselves - they took away the tasks that still have to be implemented - those tasks that are neatly drawn on the diagram with a dotted line.

Perhaps luck will still smile, and we will still be able to fit all the tasks back on the shelf - but this will have to be done with the remaining ones at a lower cost than planned . How likely is such an outcome? ..

Let's not fool ourselves and take it for granted - in any project, sooner or later, the bricks fall off the shelf . Why not release the project on time, but without a part of the planned functions? Just because very often at the very end of the project very important things suddenly appear.

How to be? Solving the problem is in the initial prioritization.

By virtue of the probabilistic nature of any project, one cannot be absolutely sure that everything will go strictly according to plan. It is not known when and in what direction an accident will play with us, but it can be said with confidence that the closer the task is scheduled to the end of the project - the higher the chance for her to be "out of the box" of implementation. It may simply not be enough time, or any other resources - and, alas, it is not always possible to increase the budget of the project.

Perhaps by itself the possibility of losing one or even several tasks (by “not getting into the budget”) is not a huge problem; this will become a real problem only if some very essential elements of the project are “under reduction”.

Based on this understanding, the obvious solution is to streamline tasks from the most important to the least significant at the planning stage, and to begin implementation with tasks that are critical for the project. Thus, the risk of “not having time” does not disappear anywhere, but only the least important, secondary tasks will be put at risk.

The essential point: it is difficult and unproductive to make a start when setting priorities from “unimportant” tasks, considering all the others as “important”. Firstly, it is difficult to note anything in the project from the very beginning as insignificant and “not very necessary” - all the more so to engage in its further planning and implementation. Secondly, looking for a “minor” project, it is very easy to miss critical and primary tasks.

It is much more effective to ask the question - “without which the project cannot be released?”. With this question, it is not so easy to forget about such important, but easily missed when planning “bricks” of the project, such as testing, supporting documentation, “setup.exe” and similar tasks. Which, of course, should try to implement as early as possible to reduce the risk of bricks falling off the shelf .

Let's sum up:

• initial estimates of the resources needed for the project, as well as their actual consumption in the development process - a probabilistic value that has an element of randomness in it;
• because of the probabilistic nature of projects, there are risks of a budget deficit, which often lead to the rejection of the implementation of any parts of the project;
• tasks planned for the early stages of development have the best chance of obtaining the necessary resources;
• setting priorities at the planning stage allows critical project tasks to be planned for the early stages of development, leaving minor ones at the final stages - thereby increasing the chances of successful implementation of the most important project elements.