We know that the proclivity of large government projects to fail is legendary. The most salient characteristic of government projects is that the best that can be expected is a mediocre performance if not an outright failure. Government projects that are actually delivered on a reasonable amount of time, on budget and with good quality are rare indeed! Strangely enough there aren't that many statistics "out there" measuring the actual objective performance of governments when it comes to deliver projects. How strange... NOT! Today we are going to explore the reasons behind these dismal and constant failures.
THE COMMON SENSE EXPLANATION
When it comes to explaining government stupidity, there are two common sense explanations that are usually set forth. The first one is that government bureaucrats are simply stupid and lazy and can't do anything right. The second is that as governments do not operate on a profit basis, money is… literally… no object and any failure can always be "papered" on top with fiat money. So, why bother, right?
Well… these explanations do have a hint of reality in them, but the truth is far more complicated than that. In order to provide a better understanding of what's going on, we will reach and make use of a tool that software engineers use: the Four Factors Model. But for that, we need to start from the beginning.
BLOOM'S TAXONOMY
A taxonomy is simply a classification system that provides a hierarchy (things that are more important than others). Benjamin Bloom developed his taxonomy for educational systems (and if you are interested in the subject, search for "Bloom's Taxonomy" in Wikipedia). He tried to explain the educational stages of children in three areas: Cognitive, Affective and Psychomotor. We are only going to use the first one. This is so because coincidentally enough, good project management undergoes the same stages. And project management is the critical piece that fails most often during government projects. As we develop this article the reasons for it will become obvious. For now, please humour us. The graph below illustrates Bloom's Cognitive taxonomy in terms of importance to project management. The items at the bottom are the least important while the items at the top are the most important.
The explanation of the stages is as follows:
- Remember: recall the lessons learned either through experience or education. Memory.
- Understand: be able to explain the lessons learned.
- Apply: be able to solve problems using the lessons learned.
- Analyze: be able to break a problem down into parts and identify their individual causes.
- Create: be able to put parts together to create something new. Synthesis.
- Evaluate: ascertain fitness for purpose for ideas, concepts and principles (i.e. solutions) for a project plan.
THE PROBLEM
We know that as government bureaucrats are people, they are not stupid (despite that horrible, horrible rumour going around stating that only people with IQ's lower than that of a potato get hired by governments). As such we know that most of the time they have no problems with Remembering, Understanding, Applying and Analyzing. If anything, analysis is overdeveloped. Bureaucrats are known for their attention to detail as they need to follow strict regulations. They are trained time and time again to focus on details. Analysis is not the problem.
The problem begins to appear when we jump to the next skill: Create. From a project management perspective the "creativity" required for success has to do with looking at the bigger picture. However, as bureaucrats are overtrained in analysis, they over-focus on details and miss the forest because of the tree. They are incapable of assembling teams based on individual strengths and weaknesses. They are incapable of trading minor imperfections for larger gains. They are incapable of minimizing processes and letting details go. They are incapable of consolidating processes and de-duplicating efforts and designs. Basically, they cannot think creatively because they have been overtrained to analyze. They cannot see the "big picture" because they are always looking at the details.
At the same level as "Create" we find "Evaluate" (or Judge). For a successful project management process it is of critical importance to determine which processes will be suitable for the project to proceed smoothly from a very high perspective. What this means is that the biggest and more important decisions must be taken first. For example, at the onset of a project it must be determined first the most effective outcome, the most appropriate technology to be used, the key requirements to be met and the likelihood of success.
Judgement is the general direction that a project must take while Analysis is the detail path within that direction. It is obvious that if the judgement is in error, no matter how much analysis we perform, we will still be in error because we will be following the wrong path.
For example let's say that a town wishes to build a bridge over a small river. Architects and engineers are called to provide consults regarding aesthetics and building techniques and costs. Town meetings are spent discussing the characteristics of the bridge, it's future toll, tourism, mapping and so on. This is analysis. The problem is that nobody stopped and asked if the bridge should be built in the first place, considering that there is an old bridge nearby which could be repaired at a fraction of the cost and add touristic attraction to the town! This is judgement.
Basically, government organizations are truly horrid at judging projects. It is for this reason that they fail miserably most of the time. But there is more. This is only the surface.
JUDGEMENT FACTORS
It so happens that it is possible to break down the "Judgement" black box into its constituent elements. They are:
Project Size: This factor questions whether or not scale has been properly taken into consideration in terms of allocation of resources, required specialties, deadlines and so on. This is important because as all engineers know, scaling a system up (i.e. making it bigger) is not a straightforward process and presenting its own unique problems. It is easy to do a small project for a small group, but it is not easy to extend that project to an entire organization.
New or Unknown Project Processes: Successful projects find a way to deal with unknowns. In order to do so there should be processes in place to catch these unknowns and resolve them. Unsuccessful projects ignore unknowns and assume that everything will go as planned.
Human Dynamics: Successful projects select the project team based on overall project strengths, this is, team members compensate each other's weaknesses. In this manner individual team members may have weaknesses but the team itself does not. Successful projects look at team cohesion and interaction; familiarity with project tools and the will to have a perfect execution not a perfect plan.
Quality: Successful projects find a way to introduce quality in the project plan itself so that it becomes part of the plan. Quality is the biggest driver in determining whether or not to move to the next project milestone. Quality must be constant, designed appropriately to measure meaningful parameters and must use the proper tools.
These four factors create a model. Each one of these factors interacts with the other three. We can see this in the graph below:
In order to keep evaluations of these four parameters simple, we will use a traffic light analogy. Green means that a parameter was properly implemented. Yellow means that a parameter was implemented with many errors and it is borderline. Red means the parameter was implemented incorrectly.
Note: please see the Glossary if you are unfamiliar with certain words.
