Mistakes happen. Bad luck happens. But, when the same mistakes occur over and over again to different PMs on multiple projects, we really should figure out a way to avoid them, but we don’t. We call this lessons learned in the business – and believe me, it is better to learn from someone else’s mistakes! Although as Douglas Adams tells us in Last Chance to See,
“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”
Here are 10 of my favorite PM mistakes. Well favorite is really not the right word because it implies something good—like favorite ice cream flavors. Let me re-phrase: Here are 10 project management mistakes I see frequently.
#1. Over committing key resources. This relates directly to the discussion of the last three weeks on resource management. But it goes beyond that. There is an element of wishful thinking, too. When bidding contracts and developing schedules, ever-optimistic managers are tempted to decide how long a task requires if the “best-of-the-best” are working on it and the wind holds steady.
#2. Believing that good technologists make good project managers. Project managers need people and leadership skills that are not demanded of the technologist. The problems that PMs are called upon to solve often require working through and influencing others on the team. I often see a job description for a PM that involves lots of required technical skills and none of the people skills.
#3. Ignoring problems. If the PM doesn’t acknowledge that a problem exists, then he or she is under no obligation to solve it. We sometimes refer to this as the Ostrich maneuver. Believe me, problems don’t go away by themselves; they usually get worse with time.
#4. Not communicating with stakeholders. The people who care about the project either because they are funding it, reporting on it, or will be using it need to be informed frequently. “No surprises” is the best credo.
#5. Failing to control problem team members. This is one of the more frequently ignored problems because it can be messy and unpleasant. Whether someone is failing to do their tasks or making life miserable for other team members, the PM needs to acknowledge the problem and deal with it.
#6. Failing to manage risks. The risks to successful project completion come in many guises and sizes. Events such as: The new process management software that no one has been trained to use; Relying on an independent team to get their part of the project done on time; Moving offices or changing requirements and not changing the schedule to accommodate the predictable negative impact.
#7. Decreasing time allocated for testing. When project schedules get into trouble and deadlines are not being met, many project managers decide to cut allocated time for testing and user evaluation at the end of the schedule in order to meet the final delivery date. This is always double trouble – you don’t find the bugs and your users or clients are furious.
#8. Learning from experience. Projects should have post mortems and lessons learned that are documented and shared. I know there is never time left at the end of the project to do this, so try doing a capture of lessons learned during the project at different intervals.
#9. Not controlling requirements. Requirements creep is ubiquitous. Marketing wants additional features, senior management agrees to new capabilities, and future users ask for more, better or different. The PM must provide these stakeholders with realistic estimates of the consequence to cost and schedule of increasing requirements. And sometimes the PM has to say, “no”.
#10. Believing in saviors and miracles. To quote Pawel Brodzinski—there is no silver bullet. Or put another way, “Hope is not a strategy!”
I invite you to add to this list with your favorite project management mistakes. We can all choose to learn from the mistakes of others no matter what Douglas Adams says about the human condition.
December 15, 2009 at 4:16 pm
Excellent list. They are all relevant, but two in particular (#2 and #6) are ones I’ve addressed in a recent post: “NotesOn: The Four Fundamental Life Cycles Of IT” at http://www.fromtheranks.com.
The key is fundamentals, always has been always will be. When someone short-cuts (or doesn’t know) fundamentals they undermine the foundations upon which all successful projects are founded.
A friend forwarded me your URL. Nice site. I plan to come back.