What Doesn't Kill the Project Manager Makes Him Stronger

Pain and learning experiences are good for us...right?  As long as they don't kill us first.  Stress, chaos, misdirection, issues, changes and scope creep.  All the things that drive us crazy as project managers on our engagements make us better project managers on our next engagements.  No way does it seem  worth it at the moment.  We probably want to stick our head in the sand. But, the things we’ve learned during our trials and tribulations in managing those less than desirable projects - the ones that fall in that ‘more than 50% of all projects fail’ category…can be worth their weight in gold on our next project or five projects down the road.

The key is – we must learn from the mistakes we make, the failures we experience, and the very difficult clients who may have helped us realize those setbacks.  How we pick ourselves up and move on will define us as project managers and help us to establish a more meaningful career than if we float on by thinking everything we touch turns to gold.  Remember my saying?  “You’re only as successful as your last customer thinks you are.”  I try to live my professional life by that statement.  (And it’s really not a bad statement to live your personal life by, too.)

So how do we ensure that we learn from the past so as not to repeat it in the future? 

Meet with the customer.  One way is to meet with the customer as the project closes out (or in times of complete and utter failure ….shuts down).  Conduct a lessons learned session and talk about what went wrong.  It’s not just you…or your team.  The blame or problem was probably spread across several players and occurred in different areas of the project.  The key is to figure it out so you can recognize it later on in another project and take corrective action before it becomes a major failure point.

Plan better and identify potential risks.  Another step is to vow to do a better job during planning to identify potential risks.  Many projects encounter failure points due to a lack of risk planning and management.  I know it seems like a waste of time and money early on to sort out risks.  You may even tell yourself that you don’t know enough about the project at that point to identify risks.  Well, that sounds like a potential risk right there, doesn’t it?  There is no better time to begin risk planning and management than during the requirements definition and planning phases as your getting the project fully defined and identifying a course of action.  That should be when most of the risk and issue questions arise.  If it isn’t, then you have a bigger problem.

Discuss what you've learned with management.  Finally, go to your senior management and discuss what you’ve learned from this project, from your lessons learned session with the customer and how you plan to proactively work to ensure this doesn’t happen on future projects.  They’ll appreciate your proactiveness and planning.  You’ll probably end up being the spokesperson for lessons learned in your project management department as a result, but being considered the leading expert isn’t that bad of a thing.

Call for input

What are your thoughts?  We've all had rough spots on our projects.  What do you think of the steps to take to “do better next time.”  Do you have some actions hidden up your sleeves that help you learn and manage better on future engagements?


Comments (1) -

By ChrisH at 11/23/2015 4:12:52 PM

Your suggestions are all very valid and important. However, it is rarely that simple. This simple truth is that many projects fail because we are human, and prone to the trappings of human engagement.

If the sponsoring organization is unhealthy, disorganized or poorly managed, the project inherits those conditions as function of its delivery. In a sense you might say that whatever challenges it faces are exposed or augmented by the project. Oftentimes these are risks and dependencies that are recognized early on in a project. One of the reasons clients don't like risk planning on projects is that it forces them to deal with their underlying organizational issues, technical operational debt. The team, however, is highly motivated to expose these, particularly if it is a client/internal team or hybrid consultancy / employee team, because they can't be successful without resolving them. In some cases, they may have been living with these problems for a long time, and they are as emotionally invested in using the project to resolve them as they are in delivering the project itself.

Additionally, projects rarely get everything they need to be successful at inception. It is a graduated process of learning and funding, along with building absent capabilities to deliver.

Lastly, the organizational and cultural change that even successful projects bring can be highly disruptive. Most organizations consider the project complete when it's technical aspects are accomplished. Very few organization put the same value on properly integrating the project into steady state. Documenting, training, coaching and mentoring people through the change properly can alleviate a lot of problems. Making sure that the organization has the capability and expertise to care and feed the new systems and capabilities is routinely overlooked.

There are, of course, other reasons that projects can fail, but these are the ones I have found are the most significant and most difficult to overcome.

Add comment