Getting out from under in projects

Excellent short post by Stacey Douglas on Exit Strategies as part of Project Plans.  Here is how she closes the post:

The inability to gracefully shut down one project when it needs to be shut down is a huge risk to your overall portfolio and to the company itself. Most of the time, the plan may be very simple, but working with your sponsor and stakeholders to identify how to recognize when the project needs to be shut down and what the process is very sensible, holistic risk avoidance for all involved.

She makes a perceptive point about mitigation plans and other risk responses.  When preparing risk responses, we tend to focus on how we will manage an individual risk event — most risk responses are aimed at ensuring that the risk event won’t happen or the impact will be lessened.  In other words, most approaches are aimed at preventing project exits.  It is rare that any contigency or mitigation plan looks at what to do if the project is stopped, never mind advocating termination as a risk response!

We address this topic in our project closure process; but we don’t account for project stoppage explicitly enough.  I’m taking an action item to take a fresh look at how we handle this within project and programs; as well as how we drive project termination in our portfolio monitoring and controlling process.

2 Responses

  1. Paul,
    One of the assesments of a schedule in the defense world is the “on ramp / off ramp” opportunities. Things always change, including cancelation of the program. So the Integrated Master Schedule must show how the on ramps and off ramps provided minimal distruption to the main stream flow.
    For ERP major changes are also common, but such an approach is just starting to moving into that domain.

  2. Thanks for the comment, Glen. As you imply, real program and portfolio thinking is pretty new to IT. There’s such an awareness and understanding gap that I’m not sure how much good it will be to teach tools and techniques until more folks “get it.”

    In other words, most PMs are used to optimizing a point solution. They don’t have any feel for the idea of evaluating multiple valid solutions, selecting, then re-optimizing (or at least doing “good enough” optimizing).

    I like your “stream” metaphor: one must first get why one needs to manage the options in a way that preserves a reasonably-optimal flow of deliverables, outcomes, and benefits.

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 )

Connecting to %s

%d bloggers like this: