Recently I’ve been talking to a colleague, during a happy hour, about good projects that lead to bad results. Despite the fact that in happy hour meetings one isn’t supposed to talk about work, the conversation brought some good reflections.

If the pyramids were software, the ones in the front would be the beta version

Since the time I attended high school in data processing – long seventeen years ago – I already looked at the numbers regarding information-system projects as a laughingstock. I remember one of my professors at that time comparing software engineering with civil engineering, invariably praising the management and construction capability of civil engineering in relation to software engineering. Anyway, civil engineers started building the pyramids five thousand years ago, we barely started punching cards a bit over fifty years ago. Historically, they are way ahead of us – I used to think.

Returning to the subject, this colleague used to talk about a project of which he was the manager, and which potentially represented an important evolution in the Company, but that at last was becoming a millionaire failure. My insane curiosity did not cease to be teased in order to understand, after all, why there was such a discrepancy between what was planned and what was achieved.

That project, with a budget of almost one and a half million reais, met four of the five classic reasons for initiation: strategic need, market demand, client request and technological advance. Not only fit to meet the legal requirements. Avoiding further discussion on so many other details, especially for ethical reasons, I can say that the project that was the subject of our discussion was interesting and promising. But then, what failed?

Chaos Report 2009

According to the 2009 Chaos Report published by Standish Group, 32% of IT projects were successful – within the deadline, budget, scope, and quality (!). In a comparison with the previous report published in 2006, the percentage fell by three points, when it was 35%. Even so, the scenario improved a lot, because at the time I was in high school, the 1998 report showed a 26% success rate.

We can certainly point out many reasons why so many projects have failed (if we built bridges, imagine that 68% of them fell). Here we will just focus on my colleague’s project. Of all this sad story, what caught my attention, and that could even be left in the background, was the direct intervention of the IT Director during the procedures for the selection of suppliers. After defining the necessary acquisitions, and passing through the ritual of proposal requisitions, the project team classified the suppliers and identified the one that best met the requirements defined at the beginning of the process. Although it is questionable, the final decision as to which supplier would be contracted was the Director’s, and he decided for the supplier with the lowest cost and biggest risk (according to the team reports). This is where my particular analysis begins, not to question the decision tree of my colleague’s company – who said it is questionable? – but to draw a parallel to the interesting psychological theory of the “freezing effect”, grounded by Kurt Lewin after World War II.

Kurt Lewin has grounded the Three Step Theory

After the Director’s decision to hire the least suitable supplier, according to the project team, the software development work began. It was not long before problems of quality and timing began, and at first they were bypassed within project management. With time and the persistence of occurrences, timeline milestones remained disregarded, and reports were issued with alternative solutions and their projected scenarios defined. Finally, the management team directly called on the Director to make a decision regarding the supplier. In the first foray, the decision was for the maintenance of the supplier, and a discreet request for the latter’s attention. There were still other three or four rounds, where the same process of identification, creation of options, and decision making was repeated, always with the same result; the maintenance of the supplier. Or would it be the maintenance of the decision?

People tend to adhere to their own decisions, promoting the maintenance of the commitment to the first decision, in an escalation of decisions. This helps to explain why the Director kept his decision for that supplier, even though he had access to reports that advised against it. The decision for the supplier selection was deliberately his. This first decision is the foundation of the “Escalation of Commitment” effect (Barry M. Staw, 1976). According to the psychological theory, the initial decision freezes the system of possible choices of the individual, causing him to focus on committing himself to the behavior that makes more sense to his decision. After all, this is the common and expected behavior of people, because in an organized society what would happen if everyone started behaving one way after having committed to another? Therefore, this effect is a basic block in the construction of personality.

Just as the Freeze Effect process explains the Director’s attitude in maintaining his decision, it also explains why the project management team, after analyzing the supplier’s performance, was able to seek solutions and even to suggest the replacement of the supplier: the original decision was not theirs. Without commitment to the decision, the team was free to use rationally the information obtained. It is especially interesting to understand that this psychological phenomenon exists and how it works so that we can manage it and seek ways to prevent its perverse effects by exploring and maximizing its virtues.

Of course my colleague’s episode is not an exception, as the Chaos Report figures prove. With even more certainty, not all projects have problems with suppliers. Information system projects have so many points of attention that an IT project manager should be promoted to a god (a bit of chauvinism). What is important to extract from this tale is the lesson.

As the freezing effect comprises the Escalation of Commitment, two other concepts are also related: the Irreversible Expense and the Trap.

I can imagine that at a certain moment, while presenting themselves to the Director, the project management team suggested replacing the supplier. The Director, on the other hand, must have argued – with more or less emotion – that the project had already spent financial resources with said supplier and therefore would not be prudent to replace it. This is an example of the judgment by Irreversible Expense, the phenomenon that occurs when the individual persists in the decision because he had previously invested money, time, effort, in detriment of other decisions, which had potentially more advantages.

It is worth remembering that the hypothetical manual of good project management says that in deciding for the continuity of the project, efforts which have already been made must not be considered (these costs are sunk in the accounting norm). Therefore, a good project management, in itself, should be enough to prevent the Irreversible Expense phenomenon from contaminating the decision making.

And as far as timeline milestones are concerned, isn’t it one of their functions to serve as a checkpoint to help control the project? Yes, but, perhaps they were not used satisfactorily. The last phenomenon, the Trap, can help the understanding of how to improve the use of those milestones. Who knows, maybe in my colleague’s project, this concept could have helped correct the course, and ensured that the end result was the one intended.

What now?

An experiment conducted in 1979 by Joel Brockner, Myril C. Shaw and Jeffrey Z. Rubin, showed that players who were exposed to the opportunity to decide whether to continue or stop betting, lost less when they were forced to decide to continue. On the other hand, those who, on the same occasion, would only act if they decided to stop, lost more.

The timeline milestone generally works as the first case of the cited experiment. There is a milestone, where the opportunity for decision occurs. If a strong decision is not taken, the project will continue automatically. Like the bettor who loses more, the project remains consuming more resources, even if it is out of control. The lesson learned comes in here, as it would be enough changing the way the timeline milestone works so that the initial decision Trap is controlled. Thus, at each milestone of the project, if there is no decision, the project is then discontinued. Radical? Perhaps. Now, think about the resources that would be saved in exchange for more aggressive management.

In this conversation with my colleague, and consequently in the reflection of the case he presented, I did not expect to discover the philosophical stone of project management. But I was glad that we understood human psychology a little more, and how it guides us in a subtle and transparent way.