Random Acts of IT Project Management

Project Management for Information Technology

How to Manage a Troubled Project

Posted by iammarchhare on 20 March 2009

This isn’t my first blog, nor is this my first writing site.  However, rather than reproduce a lot of material in many places, I will occasionally direct you to where some of that material is (don’t worry, I fully intend to make sure unique content is placed here as well).

One of the articles I am most proud of is the one at Helium on Project management basics: How to manage a troubled project.  Before you go there, though, let me give you a little background.  I was at one company in which a new, not even out the door, product ran into difficulty.  I got pulled into this project in order to do triage.  I got permission to pull in some architects, a DBA and I rallied the team to come up with a solution.  We came up with a solution, which we presented to my manager.   After her approval, it was presented to the executive team.

They (well, OK, the President of the division) had 2 questions.  The 1st initially took me by surprise, but it actually made sense.  “Is the patient on life support, or is the patient terminal?”  He wanted to know if the project was worth saving.

I have had to occasionally go over in my mind why this question took me by surprise.  In retrospect, I fully believe it was because that division almost never turned down a project.  I had seen money thrown at projects that perhaps 40 customers would use, which was well below the break-even point.  Even the President was known for “killer projects” where everyone was expected to work 60 hours per week for a couple of years!  Frankly, it has always bothered me that this question would have been so much the exception, but I believe it was tied in to that particular organization’s difficulties.

The other question was, “Can you do the remediation and still finish the required project by the end of the year?”  This one was tougher.  If I answered “No”, then it was time to update my resume, and I knew it.  Yet, if I answered “Yes”, then it meant a lot of very hard work for everyone.  It wasn’t impossible, but it wasn’t going to be easy by any stretch of the imagination.

Deep down, I knew what the answer had to be.  The project team deserved a chance, the product management team deserved some backing and the customer deserved what they were promised.  Saying “No” was a lot worse for everyone involved than saying “Yes”.  It wasn’t just my employment on the line, either.


2 Responses to “How to Manage a Troubled Project”

  1. matt said

    This blog’s great!! Thanks :).

  2. There is a lively discussion of this on LinkedIn’s Project Management Institute Group. The title of the discussion is “Why Do Project Fail?” Come in and enjoy the lively discussion!

Sorry, the comment form is closed at this time.

%d bloggers like this: