Random Acts of IT Project Management

Project Management for Information Technology

Archive for the ‘Troubled Projects’ Category

Taking Over the Loser Project

Posted by iammarchhare on 27 August 2009

In case you missed the comment, The Corporate Sleuth over at the Survive and Thrive in the Corporate World blog posted “Myth: Loser Projects are for Losers“.  The author makes a decent case that the “black hole” projects give you a chance to showcase your PM skills.

Yet, the main issue I see is that you usually don’t get a whole lot of choice in the matter.  It tends to be do or die, and sometimes you just pull the short straw.  What I recommend in any event, on any project, good or bad, is to do your best.  Like my father used to say, “If you did your best, then no one can claim you didn’t try.”

Posted in Troubled Projects | Tagged: , , , | Comments Off on Taking Over the Loser Project

Ambiguous Scope

Posted by iammarchhare on 11 May 2009

If you don’t know where you are going, then you won’t know when you arrive.  It really is a simple concept, but it seems to go over the heads of many executives.  Unfortunately, it seems to go over the heads of some IT folks as well.  When that executive wants something and wants it now, it is hard to push back sometimes.  However, “something” is not a scope statement!

If I am dying of thirst, and I ask for a drink, then should I be dissatisfied when I get a cup of coffee instead of water?  Now, I love a good cup of coffee as much as the next coffee addict, but I also know it isn’t going to cure my thirst.  No, I should have been more specific.  The person giving me the drink should’ve asked questions.  Both failed to ask questions, and the task was not a success.

What makes a successful project?  Isn’t it one that delivers the goods?  If you don’t know what the goods are, how do you know when you succeed?  You don’t.  How do you know when you fail?  When you have angry people making demands of you, which is almost a surety if you don’t live up to their expectations.  That is almost a surety when the scope is not properly defined.

Ask the questions on any project:

  1. What is success?
  2. How do you measure success?
  3. When are you done?
  4. How do you measure done?
  5. What is the minimum required?
  6. What is the maximum timeframe?
  7. Can the minimum required reasonably be planned, constructed, tested, reworked and retested in the maximum timeframe?
  8. Will subject matter experts (SMEs) be available throughout the timeframe, or will you have to rely upon less experienced workers?a. Who is indispensible to the project’s success?  When will they most be needed and can you be guaranteed their availability during critical times?

    b. If less experienced people will be used, then is it reasonable that you can still do the minimum within the maximum timeframe?

  9. Are there any stakeholders who do not buy-in on the changes?
  10. Do you have executive support (real, not lip service)?

If any of the above are a concern, and if you cannot come up with a reasonable workaround or mitigation action for it, then it needs to be identified as a risk factor.  The likelihood of the risk occurring must be widely published.  The project sponsor must be engaged with the risk.

Remember that an unmeasurable business goal is no goal at all.  Don’t start out with a hardware or software change as the goal.  No, hardware and software changes may be functional requirements that support the business goal, but they are not in themselves the goal(s).  “Change web interface to make customers happy” is not realistic or measurable.  “Increase online sales by 5% by providing customers online discount codes” is a lot better.  Now you have a business goal, you can start asking the question of where do the discount codes come from, how much the discounts are for and how and when they will be input into the system.

If you started with the interface, then the goal becomes short-sighted.  You may not involve anyone in sales.  You likely would not realize that you needed their involvement until late in the project.  They may be only vaguely aware of your project, and they will likely have made assumptions about how it would work.  The end result would likely be that no customer would receive any discount codes, so sales would remain flat in spite of any work being done.

Even worse, if the project sponsor cannot tell you definitively when a project is done and a success, then your project will have constantly shifting requirements, priorities and timelines.  Force the measurements upfront.  This will force any disagreements among stakeholders to be uncovered at the beginning and not at the end.  This will differentiate between a success or a failure in objective terms.

Measurable goals help to define original scope.  One requirements are mapped to the goals, and as long as the requirements themselves are measurable, then original scope is established.  If there is no way to measure it, then the enduser/sponsor will want additional items put in without effective controls.

Posted in PM Basics, Risk Management, Troubled Projects | Tagged: , , , , , , , , , , , , , , | 2 Comments »

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.

Posted in Troubled Projects | Tagged: , | 2 Comments »