What makes a project valuable in this economy?

A lot of my time has been spent recently thinking about the criteria that define which projects should be terminated.

However, merely taking the opposite of these criteria will not define what makes projects valuable in this economy.

Here are a few ideas for what ideas might be worthwhile:

1. “Any customer can have a car painted any colour that he wants so long as it is black” – Projects that help companies differentiate themselves sufficiently in a very short time such that they can capture and retain more market share – we all love these “game-changing” projects, but they are few & far between.  These don’t necessarily have to directly drive incremental revenue, but can also focus on retaining existing revenue.

2. “Cash is king” – projects that help companies reduce their monthly cash flow over a sustained period of time with a minimal up front investment.

3. “Plan for the future” – companies that only execute life-support projects when they can afford to do more are asking for trouble.  We will eventually see the other side of this economic downturn and the companies that took some measured risks will distance themselves from those that were completely conservative in their project investment decisions.  This is not advocating the reckless project decisions that were made in the 90′s but rather guidance to carefully examine discretionary projects that have low upfront investment (so as not to impact cash flow) but also limited short term returns (which would normally eliminate them from consideration) to see if they would “boldly go where no one has gone before”.  Remember that these are the projects that will keep your star performers energized as they perceive broad-based cost cutting across your organizations.  These are the “incubator” projects that can turn into the transformational gems of tomorrow.

Taking risk management seriously…

While no one would argue that risk management is a critical component of project management, most companies I’ve worked or consulted with consistently rank it as the knowledge area that is the worst implemented within their organizations.

Why does this happen?  Here are a few of the key reasons:

1. Project risk registers are created early during project initiation or planning and are not reviewed or updated ever again.

2. Project risk events are too generic or non-actionable or of inconsequential impact for risk response owners to take notice.

3. Risk response plans have insufficient visibility to merit action and completion.

4. Risk biases are not normalized resulting in a lack of credibility for probabilities, impacts and response plans.

So what do I recommend?

Consider risk management as being an insurance policy for your project and invest a corresponding amount of effort into the practice as you would spend on the costs of an insurance policy.  This could translate into 1-2% of the overall effort/costs of your project.  With that kind of funding, you should:

1. Focus on a small, manageable set of critical risk events – ones that senior management will take seriously.  Remember how valuable their time is.

2. Focus on business impacts when crafting risk event statements.

3. Build the risk response plans developed during project planning right into the project schedule so that their activities will merit the same visibility as in-scope project tasks.

4. Review and update the risk register at every second project team meeting as well as after every major project change.

To learn a lot more about pragmatic, value-based approaches to project risk management, visit Dr. David Hillson’s (“The Risk Doctor”) website.

A rose by any other name…

Project identification is today’s topic – organizations (especially in IT departments) struggle with the subjectivity around what constitutes “project work”.  One person’s “simple service request” is another person’s stealth project.

From a purist perspective, one could apply PMI’s (or any of your favorite PM association’s) definition and focus on such criteria as a start & end date, uniqueness, consumption of resources and delivery of value.  However, based on that high-level definition, many minute activities could be considered projects and we obviously don’t want to go down that road…

Use of multiple criteria is a must – we’ve all worked in organizations where they purely identified projects based on cost or effort – it’s amazing how many non-project activities emerge that are JUST below the threshold (a slight segue – this is similar to the 99 cent phenomenon).

Here’s a few popular choices:

- Effort/Cost

- Duration

- Cross-functional involvement

- Degree of integration with other projects

- Degree of external (or internal) dependencies

- Risk profile

- Utilization of a specific critically bottlenecked resource

Whichever combination of criteria you choose to go with, make sure that EVERYONE that works on projects in your organization has a copy of the criteria and their thresholds printed out and stuck to their cubicle walls like those old HIPAA/PIPEDA (depending on what side of the border you are on) privacy posters…