GOVERNMENT PROJECTS
Project Size
Government projects are typically very large in size. They do not undergo a "pilot" mini-project to better understand requirements and challenges. Governments typically jump from nothing to a mega project. Who hasn't heard of a mega-highway or a monster dam or a major software system that went bust? Budgets and deadlines are allocated politically with the understanding, wink-wink, that they will shift. Basically, there are no realistic budgets or deadlines. Resources are allocated based on preliminary -and rosy- plans and they are very much tinted by political -not project- considerations. If anything, government agencies and departments are in constant turf wars with each other for larger budgets and more people. They do not cooperate with each other. Because of these factors we have to rate this parameter as RED.
New or Unknown Project Processes
Bureaucrats are used to bureaucracy. Which means that project plans that they are used to deal with are "paper" project plans. They typically manage people/paper processes i.e. bureaucracy. There is an old saying in academia: "paper supports anything". What this means is that a plan for a "paper" project can be horrifically wrong but its consequences may be minor because they can be fixed easily, cheaply or simply swept under the rug. Unknowns have very little effect on "paper" plans since they must only look good on paper. Real projects, the ones involving actually building something (virtual or physical) e.g. a public web interface for a new bureaucratic process or a new bridge are quite different. These projects must work in the real world, not in the parallel make-believe world in which bureaucrats live. But bureaucrats are not used to have to deal with systems that must operate without failure in real life. As such when plans are drawn they are automatically assumed to be correct, executable and flawless. The notion that there will be unknowns is completely foreign to bureaucrats. They have some foggy idea that there will be "problems" but they fully believe that they will be solved by "tech" people. Who hasn't heard or knows of government systems that do not work? Because of these factors we have to rate this parameter as RED.
Human Dynamics
Typical government projects are staffed by government employees from a specific group. Because of the constant turf war between divisions, there is almost no consideration to make the project team strong by selecting appropriate people regardless of division or group, The objective is to make the division or group look good. As such whatever weaknesses these people bring with them, they will remain in the team. This will create a weak team. Team cohesion is typically a non-event. Almost all government employees have learned long time ago that the path of least resistance is to work "to regulations". This is, they don't ever go above and beyond their contractual requirements. As such, there are no incentives to interact cohesively and smoothly with other team members. That would require extra effort that does not bring in extra payments. Team assignments are taken as that, neutral assignments. One is equal to the other and all required performances are the same.
Also and quite typically as team member assignments are made from within a group, the familiarity of people with project tools is lacking. Instead of searching for experienced people, government organizations typically "train" their employees for a specific project. As such most team members are inexperienced.
Lastly, there is a very, very strong emphasis of having a perfect plan. This stems from the notion that bureaucrats deal with "paper" plans all the time. There is little or no incentive -or thought for that matter- as to plan execution. This is so because, again, the execution of "paper" plans is a non-event. If they fail, then yet another "paper plan" plan can be put in place to "fix" the old one and so on. Because of these factors we have to rate this parameter as RED.
Quality
In the realm of bureaucracies everything is relatively simply because bureaucracies do not operate in the real world. What this means is that as there are no profit requirements, they cannot and do not perform economic calculations to determine profits or loses (see Austrian Economics For Dummies - Economic Calculation). As such, because there are no numbers external to bureaucracies that may be used to asses them, bureaucracies make these numbers up as they go along. The typical effect of this impossibility are "employee reviews" which are utterly meaningless and measured against foggy "departmental goals". The underlying problem is that there is no way to define the meaning of quality in some sort of objective manner in a bureaucracy. As such, bureaucratic minds think in terms of quality as something foggy that can be changed at a whim or better off, made up along the way. The problem is that in the real life quality matters. Quality will determine if a development or system will actually work. Having weak (and cheap) cement for a bridge is not the same as having a strong and resistant one. Removing bugs from a large software system so that it does not crash is not the same as leaving them in. How quality is defined matters. But because bureaucrats have no clue as to how to do this, quality is typically very poorly implemented in government projects. There is no conscious effort to have good quality systems, properly defined and adequately embedded in project plans.
Yes, there are exceptions to this rule but again, they are exceptions. Sometimes a contractor is hired by the government to define quality attributes but even in those circumstances quality is an add-on and not an integral part of the project with everybody -top to bottom- acutely aware of it. Because of these factors we have to rate this parameter as RED.
Summary
In summary, large government projects fail because they fail all four of the project management factors. Furthermore, these failures are not project-based or one-time events, they are systemic and systematic. They are based on the very basic operations on which bureaucratic systems are built on. Bureaucracies cannot go against those systems because so doing would mean to go against their own self-interests. Essentially, bureaucracies fail at project management because they are designed in such a manner as to drive project failures. Government project failures will typically be made visible through "costs overruns" and "deadline slippage" because governments very seldom cancel projects. In visual summary:
We can now move on to compare what happens in the industry.
Note: please see the Glossary if you are unfamiliar with certain words.
