Successful Projects » Project Recovery

Causes of troubled projects

jsweet — Mon, 05 Oct 2009 16:14:00 +0000

So I decided to do a post between knowing when your project is in trouble and action. I thought it might be nice to discuss the causes of troubled projects.

Almost always people issues rarely if ever technology issues!

Failure to plan, or failure to follow the plan

Lack of risk management

Poor communication, both within and without the team

Hiding of problems (lies)

Failure to use change control processes

Failure to use source control processes

“Build it all at one time” approach

“Code like hell” approach

Unknown Unknowns

Failure to maintain focus

Use of unqualified personnel without training them

Wishful thinking

I’m sure if we all sat down and thought about it for 30 minutes we could come up with a list of a hundred or more causes of project failure. But I’m also fairly sure that if we thought about it a bit more we could fit all 100 of those into one or more of the listed items above. My experience has taught me that project trouble almost always comes from two main sources – personnel issues and poor choices by management or a combination of the two.

Knowing when your project is in trouble

jsweet — Mon, 28 Sep 2009 16:01:13 +0000

As I discuss project recovery in more detail I thought it would be nice to share how you know when a project is in trouble. This info comes right out of the materials I gave SoWY Department of Health. What was interesting is that they could identify with many of these symptoms of a project in trouble:

Late Delivery (most common)

Involuntary Overtime

Non-specific Tasks on Schedule

Large Tasks on Schedule (over 24 person-hours)

No Schedule

Complaints About “Scope Creep”

High Turnover Rate, Especially Managers

Secrecy

Adding Resources

No Measurements Against Estimates (or No Estimates)

No Requirements or Design Documentation

No Reviews or Review Results Documented

PAIN in general

Everybody knows when a project is going south – most won’t admit to it, except by jumping ship or by pollinating poison through negative talk and gossip.

Once you know that the project is in trouble you need to act – next post

Recovering Troubled Projects

jsweet — Tue, 22 Sep 2009 15:23:50 +0000

Yesterday I met with the IT Director for the Wyoming Department of Health. Ostensibly we were meeting to discuss me coming to Cheyenne as a contractor to help them turn around the Wyoming Client Information System – a project with which they have been having a great deal of trouble. It was pretty obvious from early on that my rate is a bit too high fro them and so I steered the discussion towards how they could best recover the project. I had planned fro this eventuality and had brought with me a traditional consulting leave behind that is a guide for project recovery. I had gained significant historical info and a lot of insight by speaking with members of the development team in the weeks prior to the meeting. This helped me tailor my presentation and leave-behind materials to WCIS and SoWY specifically.

Over the years I’ve developed a process I use to accomplish a recovery. I didn’t invent this process all by myself it has bits and pieces from others who’ve gone before me, but it has been tailored over the years to provide a framework that is most effective for me. This project recovery process is what I introduced the folks within SoWY IT to and what I left behind for them to use to hopefully recover the WCIS project. Here is a picture that provides an overview of the process:

My meeting with SoWY Department of Health is a perfect excuse to discuss, once again, the process for project recovery. So I’ll be breaking it up into bite size chunks over the next month and posting about the specifics. Stay tuned!! Hopefully this refresher will be beneficial.