PMBOM! A guide to the project management body of mistakes
“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.” (Carl Jung, Psychologist.)
The genesis for PMBOM! arose from reflections on the immense difficulty faced by all individuals and corporations, in trying to transfer project wisdom. Not only is it laborious to codify and transmit, but also unfortunately it is rarely received and remembered. (This must be the reason why some project management magazines seem to repeat their articles every three years). Another dilemma arises from the situational nature of project management. How often is your question on what to do answered with “It depends”? Attempts to provide frameworks for the application of flexibility to our body of knowledge (Hornby, 2001) are only really useful to someone who has gained sufficient experience and judgment to apply the concepts. That's not much help to newcomers. But it's not just project managers who have difficulty giving unqualified advice to those who follow. As a test, try explaining the consistency of these favorites to your children:
“Too many cooks spoil the broth.”
“Many hands make light work.”
“A stitch in time saves nine.”
“Haste makes waste.”
So, this is the goal of PMBOM!—to offer advice applicable to every situation. Experience hard won by others that you can immediately use with no ifs, ands, or buts. They've been there, done that, and these are their top mistakes.
The dictionary defines mistake as “a wrong understanding, an error.” My interpretation aligns our propensity for certain kinds of mistakes with the personal style of a project manager. This paper does not offer advice on the fundamental processes and techniques of project management, such as planning, status monitoring, role and responsibility definitions, project audits, and so forth. These are addressed in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). This is PMBOM! It's personal, and it's about you.
Why We Keep Making Mistakes
The idea of learning from our mistakes is hardly new. The quality movement has developed this concept for 40 years. The importance of measurement, the application of process and technique, and engendering a sense of individual ownership of quality with each team member is well known. Team empowerment has been explored, with the implication that the team takes responsibility for quality and improvements. These trends culminated in the early 1990s with Peter Senge's description of the “learning organization” in the hugely influential business management book, The Fifth Discipline (Senge, 1990). This book suggests 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 management professionals have exploited this knowledge in attempts to formalize our own learning processes. Almost every process in PMBOK® Guide 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® Guide 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.
Lessons Learned Aren't!
Sadly, in the everyday world I inhabit, I don't often see the efforts described above being emulated. It is even more rare to see lessons learned used as a way of improving project management practice. When they are, they exhibit only temporary success. Ultimately, lessons continue to be rarely learned. 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.
Root Cause Analysis Misses the Root
A popular tool of root cause analysis is the fishbone (or cause and effect) diagram developed by Kaoru Ishikawa. An example of how this might be deployed to investigate a typical project performance issue is illustrated in Exhibit 1.
You can see that by using a framework drawn from the PMBOK® Guide, the method points to deficiencies in process and technique, and naturally leads the investigator to make the following recommendations:
Recommendation 1: On all projects, a formal scope change management system shall be implemented. The recommendation then usually follows with references to freshly minted policy regarding this topic, and a generic outline of process and approvals that must form a part of any future set of project procedures.
Recommendation 2: On all projects, a risk review shall be conducted three months after project initiation. An outline of how such a review shall be conducted, and perhaps another reference to a fresh policy statement might follow.
The analysts deserve some congratulations, as precious few organizations seem prepared to fund and act on even this modest level of introspective review. Unfortunately, the approach deludes us into thinking that an extra helping of process and technique can resolve all problems of organizational dysfunction, management inexperience, or plain incompetence. That must be why reasonable practices become overly bureaucratic and unworkable, placing into disrepute the entire project management process. We never confront the real issue. The problem in this example—an amiable relationship-oriented project manager who just couldn't say no!
These informal observations are validated in an analysis of the pros and cons of post-project reviews (Busby, 1999). Busby's comments on the reluctance to engage in diagnostic reasoning are more academic than my example, and support my conclusion that we need something new to get to the root of our mistakes.
Get to Know Your Mistakes
If project managers continue to make mistakes despite the increasing weight of PMBOK® Guide and the attempts at lessons-learned programs, then the need for PMBOM! is established. 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. I am sure our PMBOM! researchers will soon insist on more categories. The sequence of categories is significant. 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.
Failure to Act
Inaction, in the face of a problem where the solution has been identified but is unpleasant, is easy to understand. 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. A project manager can usually tell the difference, and might use a decision-tree analysis in complex cases to assess the “do nothing” option. Sometimes it's the actions demanded by others that are problematic. A simple rule of thumb, especially for boss-imposed action, is the three-time rule. The third time you're asked, you'd better do something.
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. One aspect tends to linger because it is less commonly looked for, and that is business judgment. Unfortunately projects are rarely discussed as a microcosm of business, and many project managers have been promoted through the technical ranks where business matters may be regarded as either beneath them, or vaguely obscene.
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 definitely thinking of Joe Whatshisname who has lost most of his marbles and is coasting his way to retirement in two years.
Overview of the PMBOM!
With our taxonomy defined, we can launch the PMBOM! Within each category, I have described the most commonly observed general mistakes. These can sometimes manifest in specific ways that are additional to the examples given.
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. Accepting quality lower than that required by the client is a recipe for disaster. Tuned-in project managers will usually find out as their project proceeds if this is the case, then actions must be taken. Finding out and proving the absence of quality is not easy, and requires the definition of metrics and the taking of measurements. When you do this, make sure you have thought through the behaviors and costs they will drive.
This is a natural response when relationships are at stake, and is more common than seeking conflict, thank heavens! Failure to confront an issue results in more damage when team moral, productivity, and even business relations start to fall apart. 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 isn't met. It will take stern resolve to turn in a nonperformer, but you have to do it.
Lack of Judgment
Yes, the little word with the big implication. We expect sales people to say “yes,” but when the project manager is in charge, and becomes responsible for the words uttered, 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. The obvious request item is a scope inclusion or a complex change, 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, if you aren't 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 do it, and stick to it.
Upsetting Your Stakeholder
This mistake is problematic. Some stakeholders get upset irrationally, and there isn't much you can do about that. I'm talking about a generally rational scenario where you are responsible for something that was or was not done, said or not said, that resulted in an upset stakeholder. The more important the stakeholder, the worse the mistake. An example is your sponsor. The worst kind of upset? Big negative surprises. Sometimes you must have a private conversation that will create a little upset in order to avoid a very big upset later on.
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. Many examples will come to the reader's mind, but to exemplify my 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, this mistake also lurks within the integrative process, the most intuitive and least technical of the project management processes, requiring attention to human factors. It 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.”
Ignoring Missed Milestones
If you want to condense the role of project manager into one philosophic phrase, it might be “to manage the use of time.” Projects must be managed one day at a time because they get late one day at a time. I know about critical path and float, so it's possible a milestone can be late and technically not affect the end date of the project, but paying attention to milestones means more than managing the critical path. It's emphasizing that every date in the plan was set for a reason, many people are synchronized for it to occur when planned, the project culture requires adherence to plan, and today's floating milestone can easily become tomorrow's critical path. Every milestone matters or we wouldn't have included them in the plan.
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 or issue of substance. Your stakeholders should always know where you stand. The exception to this is when the project starts, when you have a finite time to create order from chaos by progressive elaboration—defining all the stakes and sticking them in defined locations. 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 future shall become fact. As Captain Kirk 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, and 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, when actually the reverse is true. Attempts to protect such plans by inserting assumptions such as “This schedule is presented under the assumption that no changes will occur” are actually compounding the mistake (see—Making a Bad Assumption). It is better to acknowledge the reality of the planning horizon and if forced to place detail beyond the knowable, label the chart as being for illustrative purposes only!
Mapping PMBOM! to the PMBOK® Guide
Our launch of PMBOM! will not satisfy members of PMI® without a mapping to the PMBOK® Guide. Exhibit 2 provides this. The “X” should be taken as indicating a real and primary influence on the application of that knowledge area. Most mistakes have a significant impact on more than one area, as Exhibit 2 illustrates. Everything can ultimately be affected when a mistake is made.
Project managers are human. We make mistakes and human nature shows we prefer not to highlight them. That means traditional lessons-learned techniques stop short of uncovering essential truths about why projects fail or achieve only partial success.
Efforts to educate novice project managers typically dwell on matters of process and technique. Beyond the basics, this becomes an inefficient means for knowledge transfer because selection of process and choice of technique are only reliable in proportion to the experience of the project manager.
These issues have been examined from a different viewpoint. Through our experience of human frailty, and the thousand natural shocks that flesh is heir to, we have developed a common list of mistakes to avoid. I believe that the diverse personal styles of project managers predispose them to certain types of mistakes. Improvement begins with self-knowledge, and PMBOM! could be adopted by the novice to gain an awareness of personal flaws (we all have ’em) to reduce the possibility of future project failures. Just how prevalent these mistakes really are, we'll find out at the presentation.
Hornby, Robin C. 2001. Oaks and Palms—Flexibility in Project Management. Proceedings of the 2001 PMI Annual Symposium.
Project Management Institute (PMI®). 2000. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: Project Management Institute.
Senge, Peter M. 1990. The Fifth Discipline. Doubleday.
Berke, Marsha Frank. 2001. Best Practices Lessons Learned (BPLL): A view from the Trenches. Proceedings of the 2001 PMI Annual Symposium.
Crowley, Jack. 2001. Software Process Improvement (SPI) Program and Project Management Lessons Learned. Proceedings of the 2001 PMI Annual Symposium.
Busby, J. S. 1999, Sept. An Assessment of Post-Project Reviews. Project Management Journal.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA