If programmers usually give estimates, then making a project plan is the task of middle managers. Remember, I wrote that these guys can be helped if one tool is used for decomposition and project management. Evaluation and calendar dates are not the same thing. For example, to display a simple data table, you would need:

  • DB table
  • Backend code
  • Frontend Code

Performing tasks in this order is easiest from a technical point of view. However, in reality there are different specializations. A front-end specialist may be scheduled to free earlier. Instead of waiting, it’s more logical to start developing a UI by replacing a server request with mock or hardcoded data. Then by the time the API is ready, all what is needed is to replace the code with a call to a real method … in theory. In practice, the maximum level of parallelism can be achieved in the next way:

  1. First we make swagger quickly to get ready API specification
  2. Then hardcode the data on the back or at the front, depending on who is at hand.
  3. At the same time, we do database, backend and front-end. The database and the backend partially block each other, but most often these competencies are combined in one person and the work actually goes sequentially: first a database, then a backend
  4. Collect everything and test
  5. Fix bugs and test again

It is important that steps 1, 4, and 5 are executed as quickly as possible to reduce the number of locks. In addition to technological limitations and restrictions on the availability of specialists of the necessary competence, there are still business priorities! And this means that after three weeks a demonstration has already been scheduled for an important client and he doesn’t care about first half of your project plan. He wants to see the final result, which will be available no earlier than two months later. Well, then you have to prepare a separate plan for this demonstration. We add to the plan to create necessary database data, insert new links for transitions to the UI, etc. It is also desirable that in the end it was necessary to throw out percent 20% of the code, and not all this demonstration.

Creation of such a plan is not an easy task. Building dependencies greatly simplifies the process. Before proceeding to the report module, you need to make a data input module. Is it logical? Add a dependency. Repeat for all related tasks. Believe me, many of the dependencies will come as a surprise to you.

In the tasks of automating business processes, you usually get several long “snakes” of related tasks with several large locking nodes. Most often, the initial plan is not effective in terms of resource utilization and / or too long in calendar terms. Revision of the estimated labor costs – not an option. The estimation, therefore, is most likely optimistic. We have to go back to decomposition, look for chains that are too long and add additional “parts” to increase the degree of parallelism. Thus, due to the increase in total labor costs (more people are working simultaneously on one project), the calendar period of the project is reduced. Remember the “mythical worker-month”? Almost impossible that a plan will shrink by more than 30%. In order to agree about the budget and deadline, the plan can be reviewed several times. There are several tricks to make the process faster and easier.

Task lock

The first reason for blocking – dependencies – we have already considered. In addition, there may simply be incomprehensible / inaccurate requirements. A tool is needed to block tasks and ask questions. With the specification of requirements, you can unlock tasks and adjust the grade. This process, by the way, almost always goes on during the project, and not before it.

Critical path, risks ahead

The critical path method is based on determining the longest sequence of tasks from the beginning of the project to its completion, taking into account their relationship. Tasks that lie on the critical path (critical tasks) have a zero reserve of lead time, and if their duration changes, the terms of the entire project change. In this case, during the implementation of the project, critical tasks require more careful monitoring, in particular, timely identification of problems and risks that affect the timing of their implementation and, therefore, the timing of the project as a whole. In the process of project implementation, the critical path of the project may change, since when changing the duration of tasks, some of them may be on the critical path.

So, if you will make the structure of the database not right, you have to rewrite the backend, if do not calculate the load, you may have to change the technology in general. I wrote in detail about the risks of design work in the article “Cost Effective Code”. The sooner the risks on the critical path materialize, the better. After all, there is still time and something can be done. Even better if they do not materialize at all, but let’s be realistic.

Therefore, you need to start with the most complex and unpleasant tasks, put them in the “blocked” status and clarify, overestimate and remove dependencies wherever possible.

Acceptance criteria, test cases

Native language: Russian, English or Chinese – it doesn’t matter – can be redundant and inaccurate. Test cases overcome these limitations. It is also a good communication tool between developers, business users and the quality department.

Project management

Do you want to make God laugh? Tell him about your plans. Even if a miracle happened and you collected and clarified all the requirements before starting work, you have enough competent people, the plan allows you to do most of the work in parallel, you are still not immune from employee illnesses, errors in evaluating and materializing other risks. Therefore, it is necessary to regularly update the plan and compare it with the fact. And for this, accounting for working time is important.

Time tracking

Time and attendance has long been the de facto standard in the industry. It is highly desirable to make it in the same instrument as the estimation. This allows you to track the deviation of the actual time spent from the estimated. It’s good if this tool is also used by the project manager. Then all delays of the critical path will be immediately noticeable. A variant with different tools is also possible, but it will require significantly bigger labor costs for servicing the process. We already know how this ends. We use YouTrack. Everything that I wrote about in the article is currently available out of the box, although it requires a little customization.

Conclusion

  • Evaluation is hard
  • Decomposition allows you to find gaps in requirements and improve the quality of assessment
  • Group scores are more accurate than individual ones, use poker
  • Blockers, test cases and formal acceptance criteria improve communication, which in turn increases the project’s chances of success
  • You need to start with the most risky tasks on the critical path of the project
  • Evaluation is not a one-time action, but a process inseparable from project management
  • Without taking into account working time, it is impossible to keep the project status up-to-date and adjust your estimates