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

One cross (+) meant that the messenger could go to the destination in steps, two crosses (++) meant a lynx, three crosses (+++) - an immediate gallop. Therefore, the gallop in the army was unofficially called the allure of the three crosses , and later this expression entered the Russian language, meaning the most rapid execution of orders from the authorities. [Wikipedia]
Tar pit (English, literally tar pitch ) - 1) an insoluble problem, 2) a bitumen lake (a place where underground bitumen comes to the surface, creating a section of natural asphalt). [English-Russian dictionary] Animals caught in bitumen cannot get out, so such lakes are a great place for excavating prehistoric skeletons [Wikipedia].

“Imagination represents dinosaurs, mammoths and saber-toothed tigers trying to free themselves from the resin. No matter how strong or agile the beast, in the end he will be destined for death. In the last decade, such a tar pit has been programming of large systems ... ” [1, p.16] With this striking image, the classic book by Frederick Brooks begins, first saw the light in the distant 1975. Another classic book, published in the same ancient 1987, begins no better: "And at that time the project is dying somewhere" [2, p.23]. Years go by, mankind enters the new millennium, but in 2014 the next best-seller begins all with the same eternal history:“On March 3, 2010, the Federal Bureau of Investigation decided to suspend its large-scale and promising plan for the modernization of information management ... The bureau tried to update their computer system for more than ten years, and it seems that they suffered a disaster” [3, p.14].

44 years after Brooks, we can, with a clear conscience, repeat: now, when you read these lines, the next project, like its predecessors, is sinking in the same tar pit . The chances of success in project management are less than when tossing a coin, and it does not seem to grow much:



According to CHAOS Studies from Standish-Group [4]

Why has the progress in management science (embodied in 6 editions of PMBoK and several dozens of other thick books) for 40 years (!) Never led to an improvement in the quality of management itself (unless, of course, by the quality of management is understood the probability of arriving at a given point)? To deal with this issue, we start with the main problem of any project, identified throughout the famous Brooks book.

The first problem: the complexity of the product being created


If you ask the first IT specialist that came across - “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 workers are not at all the same as the old ones." Even Brooks calls the “law” the provision formulated at the very beginning of the book (“If the project does not meet the deadlines, then adding more 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 a project when all the man-months are different?

“Mythical man-month” therefore became a bestseller, which gives an answer to this question. Here's how Brooks formulates his understanding of a basic design problem:

"... the classic difficulties of software development stem from this complexity of the entity and its non-linear growth with increasing size. Complexity causes difficulties in the process of communication between members of the development team, which leads to errors in the product, exceeding the cost of development, delaying the execution of work schedules. Complexity is the reason the difficulties of enumeration, and even more so the understanding of all possible states of the program, and hence its unreliability arises ... The complexity of the structure causes the difficulty during the development of programs and the addition of new functions so that there are no side effects ... " [1, p. 167]

The fundamental difference between the project and any other production is that the project created in it is produced for the first time [we are aware that many tasks like “screwing the counter of visits to the site” are also called “projects”, but we are talking about real projects]. Like any real thing, this new product (whether software or hardware) is composed 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 literally requires “better minds,” and not endless “man-months”:

“Outstanding projects are created by outstanding designers. Creating programs is a creative process. A strong methodology can empower and free the 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 to educate outstanding designers ” [1 , from. 185-186]

From the basic position of Brooks (designing is creativity , and the creative process cannot be carried out by the crowd), the whole real content of the “Mythical Man-Month” directly follows: the requirements of the “dictatorship of architects”, and “the effect of the second project”, and the recommendation “plan to throw away the first version” . But it also follows Brooks' most forgotten thesis - that in project management "there is no silver bullet ! " The complexity of the projects is objective, it can not be overcome either with the help of new programming languages ​​(even graphic ones), or by connecting artificial intelligence. It is necessary to cope with complexity every time 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, the manager has at his disposal fewer resources - both the time remaining 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 the project actually requires a lot more money and time than originally intended:

The next project, called “Sentinel,” the FBI began immediately, in 2005. The price of the issue is $ 451 million, and the Sentinel system will be fully operational in 2009 ... In March 2010, Lockheed Martin, the contractor, was late for the year by completing only half of the project and spending 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, since 1975, we know that the complexity of projects is growing, for example, quadratically, - what prevents the budget and team from being quadratically increased in the same way ? Why do all new generations of managers continue to lead projects with a predicted 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-famous bestseller Peopleware (“staffing” translated into Russian as the “Human Factor”), which appeared twelve years after the Mythical Man-Month, begins with a statement of the high mortality rate of projects. “About fifteen percent of the projects ended in nothing ... In the case of large projects, the picture is even worse, the collapse comprehended twenty-five percent of projects, the duration of which ranged from twenty-five person-years” [2, p.24] This was written in 1987 (the USSR was still alive !), with reference to the 1981 study (Brezhnev was still alive); and what do we have today?



According to CHAOS Report 2015 [5]

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

“In the vast majority of cases, there was not a single reason for the failure from the field of technology. Most often, the participants in our polls called "politics" as the cause of the crash

It is not at all the complexity of the product being developed, and not the insufficiency of resources, as one might expect when looking at the Brooks Cross! “Politics”, the relationship between people inside and outside the team (what Demarco and Lister preferred to call “sociology”) - this is what, according to the developers, prevented success most of all.

Think about this fact : those same people (developers, bosses and customers) who at first glance were most interested in success, united for the sake of the project, arranged “politics” in it, which brought the project to collapse! “We met the enemy, and he is us” [6]; the project revealed the second worst enemy - his own team.

It is intuitively clear that the more people are involved in a project, the more time they will have to spend on organizing joint work, and the less - on actually developing a product. The question is how much less:



Fig. 2 from 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 teams of larger numbers needed not less, but more time. Brooks' law (“add developers - slow down the project”) turned out to work not only with the threat of disruption to the project, but from the very beginning , starting with the addition of the ninth programmer. If you present the same results in terms of the notorious man-months, you get an even more expressive schedule. How much money (in monthly salaries) is required to solve the same problem forces of teams of different numbers:



Fig. 3 from article Putnam, Myers [7]

The data obtained roughly fit into a completely fantastic pattern: the productivity of a developer in a team is inversely proportional to its size. In this case, the development period will be the same for any teams, which is approximately what the data of Putnem and Myers demonstrate. Believe it or not, everyone’s personal affair; but even if you do not believe it, you have to admit that the time spent on politics grows non-linearly with the size of the team - and therefore, much less time is left to actually work in large teams.

The book by Demarco and Lister contains many examples of “sociology”, which replaces the work on the project with the work of maintaining “order” in the team. Open space offices, where the bosses can see who is swinging away from work (and employees are constantly distracting each other); detailed planning and constant requirements to meet deadlines (hurry up and leading to an increase in the number of errors); petty regulation (which makes you spend a lot of time reporting on work done and shifting employee motivation from code to “piece of paper”). All these measures seem necessary for the organization of joint work - but, when fully applied, they no longer leave time for the work itself.



Now we can understand why the “just add money” method does not work. An increase in the size 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 wallow in paper work by agreeing who is doing what and on whose side the problem is. The Demarco cross puts an end to attempts to increase the effectiveness of projects in an “extensive” way.

But what if we change the very principles of organizing joint activities? Demarco and Lister recommended this back in 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 under pain of dismissal and a ban on any initiative]. It was assumed that in Peopleware it was written quite clearly what the “opposite” measures should look like [in fact, no]. Let's look again at the project success graph. And where is the result from the book still included in the must read of any manager? Something not to see.

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

Third problem: the difficulty of planning a new


At first glance, the third obstacle to perfect project management is the unusual nature of the correct way to guide the creative process. One such method, now commonly known as Scrum, was described in an article [8] back in 1986, even before the release of Peopleware. Within a few years, in 1993, Jeff Sutherland first used individual elements of Scrum in his project, and was pleased with the result:

We delivered the software product to Easel on time, within six months, without exceeding the budget and with a minimum number of errors — no one could do this before.

However, a detailed description of the main ideas of Scrum was published only twenty years later , just 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 through word of mouth. The thing is that the main concept of Scrum, which directly follows from its philosophy, did not fit into any reasonable control logic:

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

If we mean by “project management” ensuring the creation of a product with specified properties on time within the budget, it turns out that Scrum is not “management” at all! The center of Scrum philosophy is a categorical refusal to come up with a “fixed deadline” from the ceiling (in isolation 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 stated that we are abandoning Gantt charts. Outraged by what he heard, he demanded an explanation.
- How many Gantt charts have you encountered for your professional career? I asked.
“With hundreds,” he said.
- How many of them were true?
“None,” he answered, thinking for a moment.
Then I explained that instead of unnecessary graphs and tables, by the end of the month we will give him part of a fully functional 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 a story told by Sutherland, the boss agreed to try. But we know what the "mistake of the survivors" is, and we are well aware that there are ten on one such boss who will send away such a "project manager". What kind of nonsense, to pay money honestly, that "we will work and will show something in a month"? What idiot does that?

From Sutherland's book, we know quite accurately which one: the one who has already tried to make the project a classic way , and has suffered a catastrophic failure. Only a leader driven into a corner, who has nothing to lose, dares to abandon the basic principle of management "resources - only under the plan for their use." Of course, after twenty years of using Scrum, the attitude towards him has changed somewhat, but even today most of the conversations “I will name the term and amount when I assemble the team and start working” run the risk of this.

The Scrum ideology is so contrary to generally accepted ideas about the project (“The customer agrees to pay, and the Contractor does the following work ...”) that it’s time to ask the question: why was Sutherland forced to take such a revolutionary step? Really it was impossible to leave the Gantt charts “for a tick” and focus on organizing the work of the team (for example, at daily standing meetings, in which many see the most important thing in Scrum)?

Judging by the vehemence with which Sutherland attacks in his book "Gantt Charts", one cannot:

When managing projects, two things are traditionally required - accountability and predictability. Such an approach will inevitably lead to the emergence of a huge amount of documentation, tables and diagrams ... Months of labor are spent on providing everything to the smallest detail, preventing a single malfunction, not overrun financial resources and moving forward according to the schedule. [3, p.23] The only trouble is that as soon as this perfectly honed plan is faced with reality, it immediately crumbles to dust. But instead of throwing both the plan itself and its approach to it into the trash, managers pretend that the plan works ... In fact, they pay people for lying to them . [3, p.20]

They pay for lying to them - that’s the thing! Drawing up a detailed plan and estimates of the project (collectively called Sutherland "Gantt chart") not only requires considerable labor in itself, but also leads to the adoption of a huge number of design decisions based on the fantasies of the planners. Being approved by the customer, these fantasies turn out to be binding, since they are now tied to the authority of the authorities ("we are doing everything according to plan!"). The result is quite predictable:

As a rule, management is not aware that the project is heading into the abyss, at least until 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 course of the project) with speculative tasks (invented in advance), and gives unconditional priority to the latter. And although Sutherland himself did not formulate the corresponding “law”, we can do it for him by drawing:



Any team (even organized by the last word of aggaila, facilitation and teambuilding), working according to a pre-compiled detailed plan, is doomed to carry out the larger percentage of work “for show”, the more complicated and detailed this plan was. The role of planning in managing creative activity is reminiscent of a joke: "The stick I grabbed to hit the snake turned out to be a snake."

Want faster - brakes! [9]


Now we have a much better idea of ​​what the “three crosses gait” means in project management. The usual methods that we use to improve the situation actually worsen it. A 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 amount of time. Attracting a large number of developers entails a sharp increase in managerial expenses (“ten managers per worker”) and reduces the overall productivity of the team. Careful planning with the goal of not spending a single extra cent creates a huge amount of extra work, which is why millions of dollars are wasted.

Why it happens? What kind of curse weighs on designing new things? Yes, all the same - complexity . As soon as instead of fighting the complexity itself (simplification), we try to take control of it with the help of another complexity, the summoned demon attacks us with renewed vigor. The only way to cope with a project is to cope with complexity .

The methods proposed in the world's best-selling books come down to just that. Use brilliant designers who are able to weed out unnecessary requirements and organize the rest into a “gathering” system. Let people work by minimizing control impacts (that is, “politics”). To abandon excessive planning, directing the saved time to the work itself. Simple in meaning methods, the only drawback of which is the lack of detailed instructions on how to do this . The fight against complexity is waiting for its implementation in a developed management methodology, which will finally allow us to change the disappointing statistics of project success.

  • [1] Brooks F. “Mythical man-month or how software systems are created”, St. Petersburg, Symbol-Plus, 2007
  • [2] Demarco T., Lister T. “The Human Factor: Successful Projects and Teams”, St. Petersburg, Symbol-Plus, 2005
  • [3] Sutherland, Jeff. "Scrum. The revolutionary method of project management ”, M., Mann, Ivanov and Ferber, 2016
  • [4] de.wikipedia.org/wiki/Chaos-Studie
  • [5] CHAOS REPORT 2015
  • [6] We have met the enemy
  • [7] Putnam, Myers "Familiar Metric Management - Small is Beautiful-Once Again", 1998
  • [8] Takeuchi, Nonaka "New Product Development: New Game Rules" (1986), Russian translation
  • [9] Makovetsky P.V. “Look at the root!”, M., 1966

Also popular now: