Four Easy Steps to Help Your Project Fail

Are you letting your project fail?

I guess the title caught your attention. Projects do not fail by themselves; they need help. The help they get are called people, more specifically, project managers.  Projects that fail can be called people failures; projects do not fail – people fail. When projects fail, we seem to go through meticulous pain to identify every possible cause of failure. A brief list might include:

  • End user stakeholders not involved throughout the project
  • Minimal or no stakeholder backing; lack of ownership
  • Weak business case
  • Corporate goals not understood at the lower organizational levels
  • Plan asks for too much in too little time
  • Poor estimates, especially financial
  • Unclear stakeholder requirements
  • Passive user stakeholder involvement after handoff
  • Unclear expectations
  • Assumptions, if they exist at all, are unrealistic
  • Plans are based upon insufficient data
  • No systemization of the planning process
  • Planning is performed by a planning department that may have little experience in project execution group
  • Inadequate or incomplete requirements
  • Lack of resources
  • Assigned resources lack experience
  • Staffing requirements are not fully known
  • Constantly changing resources
  • Poor overall project planning
  • Enterprise environmental factors have changes causing outdated scope
  • Missed deadlines and no recovery plan
  • Budgets are exceeded and out of control
  • Lack of replanning on a regular basis
  • Lack of attention provided to the human and organizational aspects of the project
  • Project estimates are best guesses and not based upon history or standard
  • Not enough time provided for estimating
  • No one knows the exact major milestone dates or due dates for reporting
  • Team members working with conflicting requirements
  • People are shuffled in and out of the project with little regard for the schedule
  • Poor or fragmented cost control
  • Each stakeholder uses different organizational process assets, which may be incompatible with each other
  • Weak project and stakeholder communications
  • Poor assessment of risks if done at all
  • Wrong type of contract
  • Poor project management; team members possess a poor understanding of project management, especially virtual team members
  • Technical objectives are more important than business objectives

Ok, so the list isn’t so brief. What is apparent is that only a few of these causes of failure are related to the human side of project management as the failure and these may very well be the root causes of most of the other failures.

There are actions that project managers take without effectively understanding the ramification of their actions. While the project manager believes that some of these actions or steps are the right thing to do, the results can be devastating for the project.

Step #1: Let’s negotiate for the best workers and, if necessary, ask the sponsor for support in this effort.

First of all, your project’s cost baseline may not allow for the salaries of the best people. Second, the better the worker, the more likely it is that they will be in high demand elsewhere and the likelihood of you keeping them for the duration of the project is low. They will be removed from your project at the most inopportune time. But the third reason is the worst of all. The best workers always seem to try to gold plate the project with often unnecessary “bells and whistles, thus elongating the schedule and driving up the cost. This has been my experience. Having average or above average workers that can do the job effectively may be best. Average workers tend to look for the quickest and easiest solution to a problem rather than a solution that embellishes their reputation. Perhaps you should look at your projects that had schedule slippages and cost overruns and see if you had the best workers or average workers. Of course, I am assuming that the average workers can do the job effecively.

Step #2: Let’s use the power of acknowledgment to motivate the work force. 

If you have taken the time to read the book, The Power of Acknowledgment  by Judy Umlas, you would know how and when to provide acknowledgment and in what manner. Unfortunately, technically-oriented project managers would never be caught dead reading such a book because it does not require computers, mathematics, or a vast knowledge of Greek symbols. Yet these are the people that probably can benefit the most from the book (Yes, I am an engineer and am proud to say that I have read the book).
Many years ago (or perhaps I should say, decades ago), I was a young project manager managing a multimillion dollar project. At the end of the project, I wrote a letter of appreciation for one of the workers and, in the letter, I strongly recommended that the worker be promoted immediately. I sent a copy of the letter to the worker, his superior and the Personnel Department. Everyone on the team would see that I believe in acknowledging worker performance.  In less than 10 nanoseconds, the worker’s superior called me up to inform me that this worker that I had recommended for promotion was the worst worker he had ever had and that he would never be promoted. It seems that the worker was in his superior’s office almost daily getting assistance on the work he was doing on my project. I learned several hard lessons about acknowledgement from this brutal experience:

  • Never provide acknowledgment (or reprimand) to a worker without first checking with the worker’s superior to make sure you are in agreement with what is in the letter. There are exceptions, of course.
  • Make sure you understand how other members of the team will react if they do not believe that acknowledgement should have been given out to this worker.
  • Giving acknowledgment out the wrong way to people that do not deserve it may encourage them to continue doing what they have been doing in the past and not seek to perform better. You have thus defeated the purpose of providing the acknowledgment. The result can be several of the causes of failure identified previously. I think I’ve made my point; read Judy’s book to see the right way, wrong way, and timing for acknowledgment.

Step #3: Don’t worry about “time robbers.” They won’t happen on your project.
If I had to prepare a list of the critical skills for a project manager to have, understanding one’s own energy cycle would be near the top. Are you a morning person, afternoon person, or evening person?  I am a morning person and believe that I am most productive between 6:00 a.m. and noon. As a project manager, there were many activities that I had to perform myself rather than delegating them to someone else on the team. I would then identify the most critical items and these had to be performed in the morning. Today, most of my book-writing is done in the morning.
It might be interesting to look through the list of failures identified previously and see how many of those should have been done or prevented by the project manager. When project managers do not understand their own energy cycle, they tend to allow time robbers to destroy all of the precious time when they could have taken action to prevent many of the failures from happening. There were early warning signs, but the project manager was so busy that he/she refused to recognize the warning signs until disaster was virtually imminent.
Step #4: Virtual project teams are managed the same was as any other project team.
If you are one of those people that believes that this is true, then career termination is just around the corner. This would be a good time to update your resume just in case……  Well, I think I made my point. When we talk about enterprise environmental factors as we do in the PMBOK® Guide, most people simply think in domestic terms based upon their limited experiences. Managing in global market forces project managers to be more aware of global politics, working with a group of stakeholders from various countries that will probably never be able to come to an agreement, dealing with highly bureaucratic approval processes that require sign-offs by all of the government’s ministers, team members that are all working toward different personal agendas that are more important than the project’s objectives, and the list goes on….. And, of course, let’s not forget that you may have never met many of the people assigned to your team. Project managers that agree to undertake global projects without understanding cultures and politics that the team members must deal with are on the road to self-destruction.
What you see here are four steps, each of which could have led to self-inflicted pain. It is hard to manage a project successfully in isolation. Projects are managed through people. And unless you have a reasonable grasp of the human side of project management, more so than what is taught in textbooks, feel free to send me the causes of failure on your next project so that I can add it to the list.

If you enjoyed this article please make sure to share it on social networks you hang out in and don’t forget to ‘like’ me on Facebook

© 2011  This post was originally written on March 09, 2011

3 thoughts on “Four Easy Steps to Help Your Project Fail

  1. Dear Dr. Harold Kerzner,

    I am writing to tack your permission to translate (in Persian) your articles and after that share it by our company internal magazine and my blog.
    I am looking forward to hearing from you.

    Best Regards
    Yazdanbakhsh Zare-PMP

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s