Estimating project timelines

After obtaining the hierarchical structure of the work, it is necessary to estimate the period of completion of each currently known area of work. Actually, for the sake of this, for the most part, the division of works in the IMR is carried out. The main mistakes that novice project managers make are the removal of the performer from the assessment of deadlines and an aggressive schedule.


In all textbooks, it is written in bold: to obtain a reliable estimate of the timing, it must be made by the direct executor of the work.

The fact is that it rarely happens that a performer does the same work in a project. Firstly, this is often impossible, and secondly, people usually do not like monotonous work. Therefore, it is rarely possible to occupy one programmer, say, solely with the implementation of database access.

Rather, in addition to implementing access, he will work on a large block of work, including the implementation of software and user interfaces, stress testing, locking, etc. The degree of knowledge of the programmer in each of the areas is different - in some areas he is better prepared and it will take less time, and in another - additional time will be required for training. No one, except the programmer himself, knows about the degree of his training in a particular field. And it will be he who will write, and no one else.



Again, all the textbooks say: aggressive schedule is unacceptable. What is an aggressive schedule? This is an attempt by the project manager to reduce the time given by the contractor to perform the work. Of course, the project manager does not do this because of congenital harmfulness - he is pressured by his superiors and demands to reduce the initially issued terms.

You can, of course, set strict deadlines for programmers on tasks and punish them for non-fulfillment, but what will this lead to? To two options:

• Option 1: Yes, the programmer will sit for 12 hours a day and write code. But there will be a lot of errors in this code, and the time to fix them will increase, so that in the end the total amount of time will not change. It seems at first glance, it turns out the same, but there is a strong side effect: de-motivation. The programmer will constantly be in a state of stress and, in search of a way to get out of it, will begin to look for another job. How will you feel when a programmer working on a task on a critical path puts a resignation letter on your desk?
• Option 2: same, only the programmer will work as usual, but will start looking for a new job right away. At the same time, assuring you that everything will be done on time and will be all sorts of tricks to delay this period before applying for another job. Then he will put a resignation letter on the table.

You can understand the desire of the project manager not to quarrel with his management, but then you already have to choose between two evils: either to protect the deadlines issued by the performers and seem unconcruous at the beginning of the project, or to disrupt the project deadlines at the end. The second is much worse – although, of course, it depends on the traditions adopted in the organization.

What are the ways out of this situation? 

There are several of them:

Remove tasks from the critical path where possible. Is it possible to start functional testing without waiting for the end of writing all the code? 

 

Let the errors be issued, just transfer their state in the bug tracker to the status of "frozen" for now.

Very often, the critical path is lengthened not because of the necessary sequence of tasks, but because of the lack of resources and the assignment of one person to perform many tasks – because there are not enough people.

See if this is not the case and if so, explain it to your management. It's his problems, not yours.

Is it possible to add people to the project on a critical path and, thereby, reduce it? Why can't you sit a technical writer next to a programmer and create documentation at the same time you write code? Surely not? Are you sure? Try it, I've always succeeded.

 

Then, of course, we have to edit and rewrite this documentation, but this is 15-20% of its volume. In addition, in the process of documentation, the technical writer asks questions that improve the quality of the code and less have to redo it.


Is it possible to move the implementation of some of the content to the next version of the product? If you put the manual in front of a choice: shift the deadlines or reduce the content, what will it choose? And marketers? I'm sure that both will choose the second, but try it yourself to see.


Let's imagine that all 4 questions are answered "No!". 

 

This immediately turns the project into the category of high-risk and requires special measures to reduce the overall risk of the project, as described by Edward Iordon. He recommends that the customer divide tasks into three groups of importance: "must be completed", "must be performed" and "can be performed".


This technique is based on the Pareto 80/20 principle, in our case it sounds like "80% of the functions necessary for the customer are provided by 20% of the program functionality." 

 

Therefore, it makes sense to immediately implement these necessary 20%, and then, having secured the company, make releases with the gradual addition of functionality and regression testing. Of course, all three groups of tasks will still not have time to implement in this way, but a working product with 50% of the functionality, delivered by the deadline, is much better than the phrase said on the day when the delivery of the product is scheduled: "Unfortunately, now we can not show you anything, but in a month everything will definitely work."


In the assessment of timing, there is one circumstance that plays a negative role - the innate optimism of programmers. The programmer can give, without any pressure, deadlines in which he will not meet. Not because he overestimated his strength, but because in addition to the actual main work, there is much more - certification, writing questionnaires for the personnel department, pre-sales activity. 

 

In addition, people get sick and have a desire to go on vacation at the most inconvenient moment. In reality, only 60-70% of people spend directly on the project.