Geekly Articles each Day
📜 ⬆️ ⬇️

Allure three crosses, or Why projects are so hard to finish on time

One cross (+) meant that the messenger could go to the destination step, two crosses (++) meant trot, three crosses (+++) - an immediate gallop. Therefore, in the army, the gallop wore the unofficial name of the gait three crosses , and later this expression was included in the Russian language, having a meaning as quickly as possible the execution of the commission of the authorities. [Wikipedia]
Tar pit (English, literally pitch pit ) - 1) an insoluble problem, 2) a bituminous lake (a place where underground bitumen comes to the surface, creating a section of natural asphalt). [English-Russian dictionary] Animals trapped in bitumen cannot get back, so these lakes are a great place to dig for prehistoric skeletons [Wikipedia].

“Imagination represents dinosaurs, mammoths and saber-toothed tigers trying to free themselves from the resin. No matter how strong or dexterous the beast is, ultimately, he is destined to die. Such a pitch pit in the last decade was the programming of large systems ... ” [1, p.16] The classic book by Frederick Brooks, which first saw the light in the distant 1975, begins with this vivid image. Another classic book, published in the equally ancient 1987, begins no better: “But at this time the project is dying somewhere” [2, p.23]. Years go by, humanity is entering a new millennium, but in 2014 another regular bestseller begins with the same eternal story: “On March 3, 2010, the Federal Bureau of Investigation decided to suspend its large-scale and promising information management modernization plan ... The bureau tried to update its computer system for more than ten years, and it seems that they have suffered a catastrophe ” [3, p.14].

Forty-four years after Brooks, we can repeat with a clear conscience: as you read these lines, another project, like its predecessors, is drowning in the same pit of tar . The chances of success in project management are less than when tossing a coin, and it does not seem like they would grow much:



According to CHAOS Studies from Standish-Group [4]
')

Why the progress in management science (embodied in 6 editions of PMBoK and several dozens of other thick books) in 40 years (!) Did not lead to an improvement in the quality of management itself (if, of course, quality management means the probability of arriving at a given point)? To deal with this issue, let's start with the main problem of any project, indicated in the well-known book by Brooks.

The first problem: the complexity of the product being created


If you ask the first IT person, “What is the main thing in the Mythical Man-Month?”, The answer is likely to be: “That all the man-months are different, the new employees are not at all those of the old ones”. Even Brooks himself calls the “law” a clause formulated at the very beginning of the book (“If the project does not fit the deadlines, then adding labor will delay it even more”). But this is only an empirical observation, known to everyone, that at least once "changed horses at the crossing"; the question is how to plan the project when all the man-months are different?

“Mythical man-month” therefore became a bestseller because it provides an answer to this question. Here is how Brooks articulates his understanding of the underlying design problem:

"... classic software development difficulties arise from this complexity of the entity and its non-linear growth with increasing size. Difficulty is the reason for the difficulty of the communication process between the participants of the development team, which leads to product errors, excess development costs, delays in the implementation of work schedules. Difficulty causes the difficulties of enumerating and even less understanding all the possible states of the program, and hence its unreliability arises ... The complexity of the structure is the cause of the difficulty th when developing programs and adding new functions so that side effects do not occur ... " [1, p. 167]

The principal difference of the project from any other production is that the project created in it is being produced for the first time [we are aware that many tasks like “fastening the visitor counter to the site” are also called “projects”, but this is about real projects]. Like any real thing, this new product (whether it is software or “hardware”) consists of a large number of components capable of the most unexpected interactions (both negative - thalidomide and positive - viagra). It is extremely difficult to foresee how all this will work together, and this requires literally “better minds”, and not at all endless “man-months”:

“Outstanding projects are created by outstanding designers. Creating programs is a creative process. A strong methodology can empower and liberate a creative mind, but it cannot ignite or inspire someone who is busy with tedious work ... Therefore ... I believe that the only and most important effort we can make is to develop ways of educating outstanding designers ” [1 , with. 185-186]

From the basic position of Brooks (designing is creativity , and the creative process cannot be carried out by the crowd) all the real content of the Mythical Man-Month follows directly: both the requirements of the “dictatorship of the architects” and the “effect of the second project”, and the recommendation “plan to throw the first version” . But it also follows from the most forgotten thesis of Brooks - that in the management of projects "there is no silver bullet" ! The complexity of the projects is objective, it can not be overcome with the help of new programming languages ​​(even graphics), nor by connecting artificial intelligence. Each time it is necessary to cope with complexity anew, and if the designer’s talent is not enough for this, the project will not be successful.

The main enemy of the Brooks project is the complexity of the product being created . With each line of new code, with each page of technological documentation, this complexity grows, and grows nonlinearly. And at the same time, at the disposal of the manager there are less and less resources - both the time left until the end of the project, and the money left until the end of the budget:



At the point of intersection, or shortly before it, it becomes clear that in fact the project requires much more money and time than originally thought:

The next project, called "The Guard", the FBI began immediately, in 2005. The price of the issue is $ 451 million, and the Guardian system will be fully operational in 2009 ... In March 2010, Lockheed Martin, the contractor, was late for a year, having completed only half of the project and spent 405 million. To complete, according to independent experts, it would take another six to eight years, and an additional $ 350 million. [3, p.17-18].

But let me! If we know from 1975 that the complexity of projects grows, for example, quadratically, - what prevents you from quadratically increasing your budget and team? Why do all new generations of managers continue to lead projects with a projected success of 30%, when you can just add money ?

Now it's time to move on to the next book.

The second problem: the complexity of collaboration


As we already know, the world bestseller “Peopleware” (“staffing”, translated into Russian as “The human factor”), which appeared in twelve years after “The Mythical Man-Month”, begins with a statement of high mortality of projects. “About fifteen percent of the projects ended in nothing ... In the case of large projects, the picture is even worse, the collapse was comprehended by twenty-five percent of projects whose duration ranged from twenty-five man-years” [2, p.24] This was written in 1987 (the USSR was still alive !), with reference to the research of 1981 (Brezhnev was still alive); and what have we got today?



According to the CHAOS Report 2015 [5]

The average developer today costs 100K dollars a year, adding overhead, we get that 25 man-years is about 3-6M dollars. As you see, the situation has not changed since those old years: 26% of medium-sized projects and 43% of large projects are failing, and we cannot do anything about it. But why is this happening? Demarco and Lister asked the developers about the reasons for the failures, and that's what they got in response:

“In the overwhelming majority of cases, there was not a single reason for failure due to technology. Most often, participants in our surveys called "politics" as the reason for the collapse

It is not at all the complexity of the product being developed, and not the insufficiency of resources, as one would expect, looking at the “Brooks cross”! “Politics”, the relationship of people inside and outside the team (what Demarco and Lister chose to call “sociology”) - that's what the developers thought was the most difficult thing to succeed.

Think about this fact : the very people (developers, bosses and customers) who at first glance were most interested in success, united for the project, organized a “policy” in it, which brought the project to ruin! “We met the enemy, and he is us” [6]; the project had a second worst enemy - his own team.

It is intuitively clear that the more people are involved in the project, the more time they will have to spend on the organization of teamwork, and the less - on the actual product development. The question is how much less:



Fig. 2 of the article Putnam, Myers [7]

Having collected the numerical characteristics of 491 software development projects from 35 to 95 thousand lines of code, Putnam and Myers came up with results that are almost impossible to believe. Projects of comparable size were completed by teams of different numbers almost at the same time, and the teams of greater numbers required not less, but more time. Brooks's law (“add developers - slow down the project”) turned out to work not only with the threat of a project disruption, but also from the very beginning , starting with the addition of the ninth programmer. If we present the same results in terms of the notorious person-months, we get an even more expressive graph. How much money (in monthly salaries) is required to solve the same task by teams of different numbers:



Fig. 3 of article Putnam, Myers [7]

The data obtained approximately fit into a completely fantastic pattern: the developer's performance in a team is inversely proportional to its size. In this case, the development period will be the same for any teams, as the data of Putnam and Myers demonstrate approximately. Believe this data or not, the personal file of each; but even if you do not believe, you will have to admit that the time spent on politics grows non-linearly with the size of the team - and therefore, the actual work in large teams is much less time.

The book of DeMarco and Lister contains a lot of examples of "sociology", replacing work on a project with the work of maintaining "order" in a team. Offices open-space, where the boss can see who is shirking from work (and employees constantly distract each other); detailed planning and ongoing requirements to meet deadlines (forcing a rush and leading to an increase in the number of errors); petty regulation (forcing to spend a lot of time on reporting on the work done and shifting the motivation of workers from code to "piece of paper"). All these measures seem necessary for the organization of joint work - but, being fully applied, they don’t leave time for the work itself.



Now we can understand why the “just add money” method does not work. The increase in the number of the project with the modern organization of work (open-space, tight deadlines, detailed reporting) does not lead to a significant increase in productivity. On the contrary, the larger the project team, the higher the risk that it will completely get bogged down in paperwork as agreed on who does what and on which side the problem is. DeMarco's cross puts an end to attempts to increase the effectiveness of projects in an “extensive” way.

But what if you change the very principles of organizing joint activities? Demarco and Lister recommended this as early as 1987: In order to effectively manage people in the field of intellectual work, it is necessary to take measures opposite to those listed above. [those. regulation, standardization, work on pain of dismissal and prohibition of any initiative]. It was assumed that it was written quite clearly in Peopleware what the “opposite” measures should look like [in fact, no]. Let's look again at the schedule of success of projects. And where is the result from the book, still included in any manager's must read? Something not to see.

So why? Is there another cross on the path to effective project management?

The third problem: the complexity of planning a new


At first glance, the third obstacle to the perfect management of the project is the unusual way to manage the creative process. One of these methods, now widely known as Scrum, was described in article [8] as early as 1986, even before the release of Peopleware. Already a few years later, in 1993, Jeff Sutherland was the first to use some elements of Scrum in his project, and was pleased with the result:

We gave Easel a software product on time, having stayed at six months, without going beyond the budget and with a minimum number of errors - before anyone could do this

However, a detailed description of the main ideas of Scrum was published only twenty years later , literally the other day, in 2014 [3]. All this time, Scrum existed as a semi-sectarian methodology, transmitted literally from teacher to student, and gained popularity exclusively due to word of mouth. The fact is that the basic concept of Scrum, directly arising from its philosophy, did not fit into any reasonable management logic:

This is what I constantly say to the leadership: “I can name the time only when I see how effective the team will act” [3, p.28).

If we understand by “project management” ensuring the creation of a product with specified properties within a specified time within the budget, it turns out that Scrum is not at all a “management”! The center of the Scrum philosophy is a categorical refusal to invent a “preset time” from the ceiling (apart from the real team and its performance), and the first consequence of this refusal is a completely unconventional approach to project planning:

I went to the head of the company and declared that we were abandoning Gantt charts. Angered by what he heard, he demanded an explanation.
- How many Gantt charts have you encountered for your professional activities? - I asked.
“With hundreds,” he said.
- How many of them are true?
“None,” he answered, thinking for a moment.
Then I explained that instead of the useless graphs and tables, by the end of the month we will give him a part of a completely workable system, which he himself will be able to test and see for himself whether the development is in the right direction " [3, p.50]

In the story told by Sutherland, the boss agreed to try. But we know what the “error of the survivors” is, and we are well aware that there will be ten for one such boss who will send such a “project manager” away. What kind of nonsense, to pay money on parole, that "we will work and in a month we will show something"? What kind of idiot does that?

From the book of Sutherland, we quite accurately know which one: the one who has already tried to make the project in the classical way , and suffered a catastrophic failure. Only a leader driven into a corner, who has nothing to lose, dares to abandon the basic principle of managing “resources - only under a plan for their use”. Of course, after twenty years of application of Scrum, the attitude towards him has changed somewhat, but even today, most of the conversations “I will call the time and amount when I put together a team and start working” are at risk of running out of it.

The Scrum ideology is so contrary to generally accepted ideas about the project ("The customer undertakes to pay, and the Contractor to perform the following works ...") that it is time to ask the question: why did Sutherland have to take such a revolutionary step? Was it really impossible to leave the Gantt charts "for show" and focus on organizing the work of the team (for example, standing at daily meetings, in which many see the most important thing in Scrum)?

Judging by the vehemence with which Sutherland attacks in his book "Gant charts", you can not:

Project management traditionally requires two things - controllability and predictability. Such an approach inevitably leads to a huge amount of documentation, tables and diagrams ... Months of labor are spent to provide everything to the smallest detail, to prevent a single failure, not to waste money and move forward according to schedule. [3, c.23] The only trouble is that as soon as this perfectly honed plan collides with reality, it immediately crumbles to dust. But instead of throwing the plan itself and its approach to it in the trash, the leaders pretend that the plan is working ... In fact, they pay people for lying to them . [3, p.20]

They pay for lying to them - that's what's the matter! Drawing up a detailed plan and budget for the project (collectively referred to as Sutherland's “Gantt chart”) not only requires considerable labor, but also leads to the adoption of a huge number of design decisions based on the fantasies of planners. Being approved by the customer, these fantasies turn out to be binding, since they are now tied to the authority of the authorities (“everything is going according to plan!”). The result is quite predictable:

As a rule, the management is not aware that the project is rolling into the abyss, at least until such time as millions of dollars and thousands of hours of work have been wasted [3, p.23]

Sutherland discovered and described a completely objective feature of any management process: planning replaces the really necessary tasks (arising during the project) with speculative tasks (invented in advance), and gives unconditional priority to the latter. And although Sutherland himself did not formulate the appropriate "law", we can do it for him by drawing:



Any team (even organized by the last word of the Ajail, facilitation and team building), working according to a predetermined detailed plan, is doomed to carry out the greater percentage of work "for show", the more complex and detailed this plan was. The role of planning in the management of creative activity is reminiscent of a joke: "The stick that I grabbed to strike a snake turned out to be a snake."

You want faster - brake! [9]


Now we have a much better idea of ​​what “three crosses” means in project management. The usual methods that we use to improve the situation actually worsen it. Careful collection of requirements “just not to miss something important” leads to a huge number of functions that are almost impossible to implement in a reasonable time. Attracting a large number of developers entails a sharp increase in management costs ("for every ten managers working") and reduces the overall productivity of the team. Careful planning in order not to spend a single extra cent creates a huge amount of extra work, because of which millions of dollars are wasted.

Why it happens? What a curse over designing new things? Yes, all the same - the complexity . As soon as instead of dealing with the very complexity (simplification) we try to bring it under control with the help of another complexity - the summoned demon attacks us with a new force. The only way to cope with a project is to cope with complexity .

The ways offered in world bestsellers come to exactly this. To use brilliant designers who are able to weed out unnecessary requirements and organize the rest in the “gathering” system. Letting people work by minimizing control actions (i.e., “policy”). Abandon excess planning, directing the saved time to the work itself. Simple means, the only shortcoming of which is the lack of detailed instructions on how to do this . The struggle with complexity awaits its implementation in a developed management methodology, which will finally allow changing the disappointing statistics on the success of projects.

Source: https://habr.com/ru/post/460505/

More articles:


All Articles