Journey to the ten commandments of project management
“Mistakes are, after all, the foundations of truth, and if a man does not know what a thing is, it is at least an increase in knowledge if he knows what it is not.”
Despite its significance, there is very little focus on the issue of project manager behaviour and mistake avoidance. Almost all project management texts illustrate the more technical aspects and few seem to give any guidance on how to avoid or resolve problems that we, as human beings, cause for ourselves. As a result, project managers develop blind spots and fail to build their personal foundation of project behaviour skills.
Through serving time at UHK – the University of Hard Knocks, long-term project managers gain a base of experience sufficient to provide confidence, flexibility in decision-making, and the first inkling of personal mastery. Often, this takes many, many years. Sometimes it takes forever. Can the learning curve be shortened? There is no proven answer to that, but the thought that experience-based guidelines applicable to all aspects of project life might exist provides some encouragement. Thus was born the Ten Commandments of Project Management. Let's follow the journey.
Why do Projects Fail?
The place to start in any discussion on project failure is to quickly survey the accepted causes. Now I have to acknowledge my background, Information Technology, and beg the reader's indulgence as I briefly dip into some topical issues. The first thing we think of as a problem is the technology itself. As it turns out, although projects do fail because the technology is a bust, that cause is well down in the list. Survey after survey (e.g. Standish Group, Gartner Group, and many others) consistently report, year after year, the same three reasons at the top of the list with a host of others close behind.
Fig. 1 Failure Reasons (year after year …)
Maybe this is like the proverbial Russian doll? Behind these long lists of observations are there more fundamental causes that need addressing before projects succeed? Let's step back from the problem and create another list.
Fig. 2 Is Lack of Process the Root Cause?
This list takes panoramic view and suddenly a panacea comes into focus. If we clinically analyze the root cause of project failures, nine times out of ten we will pick on the absence, or misapplication, of the fundamental processes and techniques of project management, such as planning, status monitoring, role and responsibility definitions, project audits, and so forth. These are all addressed in A Guide to the Project Management Body of Knowledge (PMI® 2000 – the PMBOK®).
But wait a minute. PMBOK® has been around for ten years, everyone you meet is now a PMP, and project management training is virtually an industry in its own right! Yet still, projects fail, or succeed inadequately (75% to 85% in IT, depending whose statistics you believe). So here's my conclusion. We are ignoring the human factor. Project managers are human. We make mistakes.
Why We Keep Making Mistakes
The idea of learning from our mistakes was first seriously introduced into the corporate environment by the early phase of the quality movement 40 years ago. Processes for quality control and quality assurance were the first formalizations. In the 1980's Total Quality Management (TQM) introduced the notion of incremental improvement, quality circles, and employee-driven change (rather than management-ordained change). Team empowerment was explored, with the implication that the team takes responsibility for quality and improvements. These trends culminated in the early 1990's with Peter Senge's description of the “learning organization” in the hugely influential business management book, The Fifth Discipline (Senge 1990). This book suggested that the ability to learn and to respond is the only real competitive advantage and that systems thinking is the means to obtain it. This idea became a favorite with management consultants and their large corporate clients.
Project managers have exploited this knowledge to try and learn from our own mistakes. Almost every process in PMBOK® that deals with corrective action (and there are lots) includes the lessons-learned technique, derived from the continuous improvement branch of the quality movement. The PMBOK® itself can be seen as a prescription for process improvement and many authors use this as a base to model process maturity. Recent examples of a lessons-learned methodology (Berke 2001) and a process improvement initiative (Crowley 2001) illustrate how these theories can be harnessed. Berke's successes are drawn from Japanese-inspired incremental continuous improvement methods and rely on external facilitation, clear management commitment, and acknowledgment of the limitations of the public forum. Crowley overviews the considerable effort required implementing a “one-shot” improvement program (in this case, software development using the SEI SW-CMM™ as the target model). He emphasizes the need for executive support, a total systems approach, and adequate time to make the cultural change followed by evolution into a continuous improvement program.
Unfortunately, in the everyday world I inhabit, the efforts and processes overviewed above are seldom emulated. It is rare to see lessons-learned used as a way of improving project management practice, other than as very short-term initiatives following obvious SNAFUs. It's interesting to contemplate some reasons why this is so:
- Lessons-learned programs are only successful when a skilled, enthusiastic and energetic organizer is responsible (such as the authors of the cited papers), but dissipate when the organizer leaves
- The program requires criticism – an unpopular pastime
- Project management is a service, and any criticism of a service is an implied (sometimes explicit) criticism of an individual
- Self-directed lessons-learned require a good degree of maturity and self-knowledge – a minority in most growing organizations
- Reliance on customer contact staff (sales people) for customer feedback as input to lessons-learned is notoriously unreliable – why risk asking a question that might have a negative answer?
- To openly acknowledge to peers and bosses ways in which one's project management could have been improved requires a level of trust that is rare in today's organizations.
Get to Know Your Mistakes
What more can be done to help project managers avoid mistakes, despite the increasing weight of PMBOK® and the attempts at lessons-learned programs? First, we have to figure out the kind of mistakes we make. To keep things simple, I have lumped them into one of three categories: 1) Failure to Act, 2) Lack of Judgment, and 3) Perceptual Dissonance. The sequence of categories has some significance. It denotes a diminishing level of awareness of the mistake that is being committed and an increasing difficulty of avoidance. Presumably mistakes you are aware of are easier to avoid than mistakes you aren't.
1) Failure to Act
Inaction in the face of a problem is easy to understand when the solution is unpleasant. Procrastination and avoidance are traits we all recognize. Most people know when they're doing it. The issue is complicated by the fact that many problems that might seem to demand action are actually resolved by doing nothing. Sometimes the actions demanded by others are problematic and can be ignored. The long-term project manager learns to make the differentiation.
2) Lack of Judgment
Judgment comes from experience, and experience comes from a lot of bad judgment. This type of mistake is naturally more prevalent with junior project managers. Unfortunately, age doesn't always eliminate this characteristic. However, poor judgment and poor decisions can be recognized relatively easily by peers, bosses, and reference checkers, so project managers with this innate limitation tend to get weeded out as time goes by. The rest of us get to recognize it in ourselves and strive at self-improvement. Good business judgment often remains elusive, mainly because projects are rarely discussed as a microcosm of business. Many project managers have been promoted through the technical ranks where business matters were regarded as either beneath them, or vaguely obscene.
3) Perceptual Dissonance
This term is coined to describe a universal condition all project managers find themselves in and, because it doesn't have a name, we very seldom recognize it. Well, now we have a name so no more excuses! Psychologists use the term “cognitive dissonance” as referring to an internal conflict that arises when we are asked to do something that negates the value of a previous thought or work. The activities are valid and must be done. However, because of cognitive dissonance, self esteem is eroded, the work is done poorly and quality suffers. The classic example is asking a computer programmer to test his own code, the implication being the previous coding work was inadequate. Perceptual dissonance arises when two people look at the same thought or work, and each assign different values or meanings. Worse, because it lies in the tricky realm of perception, normal discourse will never reveal that the condition exists. A common example is found in lists of assumptions. When I write: “It is assumed the client will provide a subject matter expert in materials planning to work with the team during the specification phase”, I am thinking of an expert. The client is probably thinking of Joe Whatshisname who has lost most of his marbles and is coasting his way to retirement in two years.
The Errors of our Ways
With our taxonomy defined, the road to the ten commandments is now surveyed. Within each category, I have described the most commonly observed general mistakes. These manifest in many ways of which we provide only a few examples.
Failure to Act
Not Paying for Quality
John Crosby has a lot to answer for. Because we've all heard of his book, but few have actually read it, there is a myth that quality is free. This is never true in projects. Every increment in quality has to be planned, resourced and paid for up front, to avoid the cost of rework later. On the other hand, accepting quality lower than that required by the client is a recipe for disaster. Finding out and proving the absence of quality is not easy, and first requires agreement on quality targets, then the definition of metrics and the taking of measurements.
Avoiding conflict is a natural response when relationships are at stake, although it is more common than seeking conflict, thank heavens! Failure to confront a simmering issue destroys team moral, productivity, and even business relations. When normal processes or reference to clearly drawn roles and responsibilities doesn't resolve differences, they escalate to the project manager's in-basket.
Accepting incompetence turns into the insidious rot of tolerating incompetence when it should never have been accepted in the first place. If managers insist on giving you incompetent or disruptive staff, or subcontractors who won't deliver, you are entitled to insist on performance reviews and the return of these staff if performance requirements aren't met. It takes stern resolve to turn in a non-performer, but you have to do it.
Lack of Judgment
‘Yes’ is a little word with the big implication. We expect sales people to say ‘yes’, and that's another issue, but for the project manager an unqualified ‘yes’ in response to a new request is a definite no-no! Just about everything in project management is connected, sometimes in surprising ways, and we need to take a period of analysis and synthesis (integration) before providing a response. Scope change is an obvious request, but the request could be for a delay, change in approach, or overtime effort, or anything that might have a better solution given time to think. Nothing is that urgent in a project, outside an act of God, that doesn't permit a finite period for study, consultation and reflection.
Quoting Single Point Estimates
How often have I regretted this! It doesn't matter what it is, unless you are the person doing the work (and thus accountable for absorbing your own risk), you cannot quote one number for anything to do with the triple constraint. Why? Because risk, be it high or low, is always present and must be explicitly recognized. How will we ever train our clients on the relationship between risk and estimate if we don't do it ourselves? Many techniques are available to help with this including ranged estimates, an estimate with an assigned probability, an estimate hedged with an uncertainty percent factor, or for detailed cases, estimates predicated upon different sets of assumptions. Choose the right technique, study it so you can explain it convincingly, train your resources to use it, and stick to it.
Not Quite Speaking the Truth
This issue addresses integrity, one of the project manager's most precious commodities, so dearly won and easily lost. There is a fine line between providing information on a “need to know” basis, and withholding or disguising information for reasons not aligned with stated project objectives. You must keep on the right side of that line at all times. To exemplify the point, think of a situation where you are providing a fixed price estimate to a client known for lack of tolerance of padded estimates but with whom you have partnered on a number of successful projects. As project manager, under what conditions would it be appropriate to reveal or not reveal the degree of contingency included in your bid?
Unrealized Stakeholder Expectations
Setting unrealistic expectations is the great granddaddy of mistakes, along with its cousin, failing to explore your sponsor's personal interest in the project. It takes hold on day one and then spawns a lot of secondary mistakes. Obviously a communication issue, the best tool is clarity in objective setting and business alignment. The problem is closely linked to “Saying Yes”, but its perceptual nature allows it to occur in a variety of situations, such as by saying nothing when your sponsor says, “I look forward to seeing your Oracle performance expert on site here next month to fix the batch update problem”.
Making Bad Assumptions
Of course, the worst assumption is the one that isn't written down! Implicit assumptions can create a frenzy of perceptual dissonance. At the same time, useless, unrealistic, and ambiguous assumptions written down and left unchallenged can also do their share of damage. Estimates, risk and assumptions go hand in hand as the trinity of core planning, and if they're not in balance then the centerpiece of your plan is invalid. Work your assumptions hard. As the PMBOK® Guide says, they will be taken as “true, real, or certain”.
Not Putting a Stake in the Sand
This mistake has two flavors, each with different and unpleasant outcomes. The first is not putting the stake anywhere so, in effect, it either flops around on a day-to-day basis, or is perceived by a stakeholder to be in a favorable position. We're talking primarily about scope boundaries, but the stake can be the project's position on any matter of substance. Project stakeholders should always know where you stand. The second flavor of this mistake is setting the stake in concrete prematurely. This brings with it the nightmare of over-bureaucracy and lack of responsiveness, with the very real danger the project will fail to meet the essential needs of the owner.
Planning the Unknowable
Every time we plan into the unknown we create a perception that our definition of the distant future shall become fact, brought about by will power alone. As Captain Picard in Star Trek might say “Make it so!” Regrettably, project management is not that scientific and even the strongest-willed manager discovers the natural law of the planning horizon intervenes. This law suggests that detailed plans start to lose validity more than six weeks out. When you get to six months out, the detail really turns into guesswork. Even so, it seems to be a fact of project life that detailed plans (as opposed to general or phase-level plans) are demanded by owners or sponsors who don't feel you have any credibility unless you can generate such a work of fiction. Attempts to protect such plans by inserting an assumption such as “This schedule is presented under the assumption that no changes will occur” actually compound the mistake (see - Making Bad Assumptions).
Project managers are human. We make mistakes, often in a misguided attempt to help and often not even recognizing our errors. When errors are revealed, human nature dictates that we prefer not to highlight them. Traditional lessons-learned techniques therefore stop short of uncovering essential truths about why projects fail or end up regurgitating truisms on processes and techniques we could have looked up in PMBOK® in the first place.
So now we draw inspiration from biblical times and ask, “can we synthesize a generally applicable list of rules to help steer us clear of the mistakes that seem to haunt us project after project?” Yes, of course! Reviewing and reordering the errors of our ways yields the list in Fig. 3 – and we now arrive at the Ten Commandments of Project Management.
Fig 3. The Ten Commandments of Project Management
As a part of the research to test the veracity of the ten commandments, we have made presentations centered on the human errors overviewed in this paper. We have asked audiences comprised of project managers from all disciplines – mainly IT, but at least 50% from other areas such as government, construction, health care, finance, and telecommunications – to rate their agreement with our list in terms of contribution to project failure. The chart in Fig. 4 shows the average ratings. A rating of 5 is strong agreement, 3 is a maybe, and 1 is a definite disagreement. Clearly the list strikes a chord.
Figure 4 Project Managers' Popular Mistakes
In each poll, the relative ratings are remarkably consistent. The top mistakes are always: setting wrong expectations, saying yes in haste, and making wrong assumptions. Comparing mistake preferences between IT practitioners and all others also showed no discernable differences. Perhaps this is evidence of the universality of the ten commandments, despite the author's background experience in IT.
The issue of project failure causation has been examined from a different viewpoint. We have focussed on human frailty, not process, organization, technology, or technique. Just as the Ten Commandments of the Old Testament gave guidance to life, so do our analogous project management commandments help us avoid project mistakes. I hope you will be encouraged to build these commandments into the foundation of your project management behaviour and that they will inspire you to deliver a more righteous project!
Berke, Marsha Frank. (2001, November). Best practices lessons-learned (BPLL): A view from the trenches. Proceedings of the PMI Annual Symposium. Nashville, TN.
Crowley, Jack (2001, November) Software process improvement (SPI) program and project management lessons-learned. Proceedings of the PMI Annual Symposium. Nashville, TN
PMI® 2000, A Guide to the Project Management Body of Knowledge, Upper Darby, PA; Project Management Institute
Senge, Peter M.(1990). The Fifth Discipline, Doubleday.
Journey to the Ten Commandments of PM