"Bloodsucker bosses" out of context or why they always fail

In my opinion, the article “Bloodsucking Bosses in the Context of ...” did not disclose the reason for the disintegration of self-managed teams, but the reason was precisely the slow speed at which product requirements spread, and the lack of understanding that the manager is always part of the team.

By changing the approach to planning the work of the design department in developing a new product, it is possible to increase the speed at which information spreads, which is much more important for a project than just having information.

Classic scheme

In the classical scheme, the work planning and development process has clear time boundaries. Usually the planning process is carried out before development. At the end of planning for each month, a “network work schedule” appears on which the product development process begins by the design and engineering department. There are not so many kinds of network graphs - these are mainly PERT and GANTT . The deadlines in the network graphics are usually declarative and not supported by anything, which creates some imaginary space when working in the process of development by the design and engineering department. In fact, the deadlines in the network schedule are agreed with the customer and the contractor is forced to comply with them, otherwise the failure of key development terms may threaten to close the project as a whole. Nobody asks the developers in the classical scheme and the project manager simply drops the deadlines for each work to the developers.

From the outside it looks like the project manager distributes everything to a kind of fishing rod (tool) and says: “Catch while the crucian. At the end of the month I’ll come and check how much I’ve got. Need to catch 2 tons. ” During the month, the project manager holds meetings at which someone reports to him, how many tons and what type of fish he caught. At the end of the month, a new “updated” network work schedule is launched by the project manager, according to which the customer wants to catch not carp, but for example “zucchini” . The “wise project manager” has a chance to get a bonus for buying a new plasma or a new modern SUV. If he is lucky and there will be at least one who catches a “fish-zucchini”, then he will pay a premium to himself and a successful angler, and the others will impose a fine.

This mode of operation forces the project manager to take on some of the development tasks for themselves, and the developers of such a project are constantly delayed at work, and sometimes they have to go on weekends in order to have time to develop new interfaces for user interaction with the product. All this, as I mentioned above, is aggravated by the fact that the requirements for the final product can change, and then the network schedule is adjusted, and the adjustment is made so as not to hurt the key deadlines in the project.
In such a scheme, all work depends on the human factor, which plays a key role. The human factor can be minimized by introducing automated planning and development systems, which many people actually do when they implement CAD , CAM , CAE , PDM , ERP , CRM , PLM, and so on.

However, the basis in the form of a classical scheme, when planning and development have clear time boundaries remains unchanged. As a result, developers have to maintain up to date numerous editions of the software product and documentation in each automated system, as well as constantly maintain system integration, which is problematic in today's competitive IT market conditions. The customer ultimately needs only one thing - this is a finished product or a streamlined production. In the classical scheme, the list of documentation developed by the contractor will always be redundant, since neither the customer nor the contractor has full confidence that the goal will be achieved, and therefore it is necessary to document the process as much as possible in order to identify “to shift responsibility” for the deadline. Even if the final goal will initially be formulated as specific (Specific), measurable (Measurable), achievable (Attainable), realistic (Realistic) and limited in time (Time-based), as a result, after the first additional requirement, the contractor may disappear the attainability of the final goal, and consequently there will be a failure to meet the deadlines and close the project.

How, then, to make the customer not change the requirements too often, and the performer fulfilled all the requirements of the customer on time?

In the classical scheme, the planning process is handled by an experienced expert in the field of project planning, who, based on his experience, determines the list of tasks and their deadlines. I believe that all this could not have been done by an experienced expert, because the timing of the tasks, as well as the list of tasks necessary for the implementation, can be determined by the team itself. To do this, the expert from the customer needs to describe the product in as much detail as possible in his TK and the deadline for which the product is needed, and that’s all! The team, under the leadership of the project manager, can carry out the work planning itself, reveal the pitfalls, decompose the tasks, in short all the work that the most experienced expert performs.

The “problem” is that in this case, each member of the team knows the final goal, it is transparent and at each moment in time we know how far the team is from it. “A wise project manager” will not be able to include his megacel in this goal: “buying a modern SUV”. In order for him to successfully achieve his 100% mega-goals, he needs to separate the planning and development processes and issue task lists in batch as the “problems” arise. In this case, the task of the project manager is to maximally divert the attention of the team from the final goal of the project, and focus their attention on solving the specific work of the network schedule just in time. In other words: “fill up the team with routine work”.

A fundamentally different scheme of work is a scheme of work using flexible development methodologies, where the main principle is:
frequent uninterrupted supply of a product valuable to the customer.

This is achieved primarily by the transparency of the planning process, when each team member knows the final goal and participates in the formation of a task pool for the next 1-4 weeks, after which the customer sees the first version of the product with new functionality. Obligation of the project manager to obtain approval from the customer or simply notify him of the product version with a new functionality that will be ready after the iteration is completed. All additional requirements coming from the customer should be taken into account when planning the task pool team in the following iterations.

In order not to stray from the goal of reaching the final goal, the team gathers every day for 15-minute rallies, at which each team member answers three questions:

1. What was done from the previous rally?
2. What will be done to the next rally?
3. What are the problems?

In the case when planning is carried out separately from the development, the answer to the second question is given by the project manager, as well as the answer to the third.

At the end of each iteration (sprint), the team demonstrates the product with a new functionality to the customer. After each demonstration, the team meets separately from the customer for a retrospective. Methods of conducting retrospectives mass, I would like to note a retrospective in the style of “PLUS / DELTA”, in which each team member gives 10 positive points (PLUS) and ten points that made the team deviate (DELTA) from achieving the intended goal.

In the scheme of work with the use of flexible development methods, automated systems play a key role, allowing you to get a product with the most developed new functionality at the end of the iteration. After each iteration, the product can be sent for technological development in ERP or CRM systems in order to further launch the production of a prototype product for testing under conditions as close to real as possible. Thus, after each iteration, a software product is updated and new functional requirements are increased. Customers themselves at the stage of technological development or a pilot project through feedback in the CRM- system will express demands that you would not even think about. The main thing is to bring these requirements to the developers in time, and not to hide them in the halls of the mind, as the “Wise Project Leaders” sometimes do.

Draw conclusions

Attempts to build the development process according to the classical scheme using flexible methodologies usually fail, and seeing so many project managers to please their “mega-targets” or simply automatically following the fundamental principle of “divide and rule”, they refuse to apply modern knowledge of project management in practice.