« Avoid “Analysis Paralysis” When Using Metrics
Real World Project Management - Communications - Part I »

Portents of Project Failure

March 27, 2008 | Author: admin | Filed under: Risk Management

Portents of Project Failure
By Kailash Awati

Most project managers have had to deal with a failed project or two. Unfortunately, by the time it is recognised that a project is in trouble, it is often too late to do anything about it. Many project failures, however, are presaged by other, less serious problems. It is useful to keep an eye out for these so that one can take action to prevent subsequent disaster. To use a medical analogy, it is best to to identify sick projects before they become terminally ill. As doctors say : the earlier the diagnosis, the better the prognosis.

So here they are, six symptoms of sick projects (in no particular order):

  • Low team morale: Team members complaining that things are out of control and that they can’t cope is a sure sign of trouble ahead. Solution: get to the root cause of the problem. Figure out why they think “things are out of control” or “they can’t cope”. You need to find the underlying cause for their angst before you can address it.
  • Chronic buck-passing: A typical case of this might be where a team member says, ”I coudn’t finish on time because X didn’t give me what he was supposed to last week.” Project roles and responsibilities should be defined in the plan, and I’m assuming that this is the case (if not you have bigger problems!). In a situation where responsibilities are defined, buck-passing is usually a consequence of communication breakdown across a project interface. This has to be handled by smoothing out the obstacles to communication.
  • Sponsor loses interest (or worse, quits!): A sponsor quitting is a situation that a project manager can’t do much about, except be aware it might (will!) impact the project. Loss of interest, on the other hand, could mean that the business no longer considers the project important. Whatever the reason, it is probably best to speak to the sponsor to find out more.

  • Chronic distractions: This is possibly the most common one I’ve come across. It typically happens in corporate environments where team members are temporarily “loaned out” to the project team. The demands of their regular jobs still remain and consequently they’re continually pulled away to do non-project tasks. The way to handle this is to speak to the relevant managers, reminding them of the importance of the project and their original commitment to it. As a last resort, one might need to involve the sponsor. The preferred option, however, is to settle the issue at the level of the manager.
  • No one in-charge: This is really a variant of the previous point, but is important enough to stand on its own. It typically happens when the project manager is a part-timer who has to focus on his or her real job whilst (additionally) looking after the project. Although such an arrangment might work for a small project with limited scope, it will not do for a project of any decent size. It still surprises me how many important projects (such as ERP implementations) are run by part-timers. Although the people involved do their best, part-time attention is rarely enough to stay on top of the complexity of the project. I should also add that this can also happen when a project manager is incompetent!. This, however, is much rarer as such folks tend to get weeded out of the profession before they get to handle a big project. In either case the solution is to get management to understand that (competent!) full time attention is necessary for project success.
  • Lack of familiarity with technology or processes (coupled with the lack of external help): This one is common enough. I’ve seen several frustrated project teams struggle to familiarise themselves with an unfamiliar technology whilst attempting to use it in a project. The time to a learn a new skill is before the project. It’s too late to throw people into training after the project starts; they need to learn and practise the technology well before that. If your team doesn’t have the necessary skills, for heaven’s sake get help from outside. Else you’ll kill morale along with the project.

To sum up, projects rarely fail without warning. It is helpful to keep an eye out for signs that a project is heading south, and to act on these before it’s too late. To this end, I’ve listed a few of the symptoms of sick projects. I’d welcome your contributions to the list via your comments.

Original article can be found at http://eight2late.wordpress.com/2008/02/21/portents-of-project-failure/

Kailash Awati currently manages IT development at a multinational in Australia. Over the last several years, he has managed IT projects at companies ranging from startups to established firms. He has also worked as a business and technology consultant for companies in Europe and the US.

On the technical side, he is a seasoned database architect and administrator with wide experience in designing, implementing and administering databases for transactional and analytical applications.

Earlier, in what seems to him like another life, he did research in fluid dynamics and other areas of physics.

For what it’s worth, he holds doctoral degrees in physics and chemical engineering together with assorted certifications in project management and database administration. An admittedly strange mix, which he sometimes finds hard to explain.

He blogs at eight to late, where he writes about project management and other (at times distantly) related topics. Oh, and he also maintains a web presence at www.orafusion.com where he publishes longer articles on his professional interests and the occasional cryptic crossword.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

    • This entry was posted on Thursday, March 27th, 2008 and is filed under Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

    No comments yet.

    feel free to leave a comment

    Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

    XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

    All fields marked with " * " are required.

    Project Management Categories