A Project selection Primer

When is a project not a project?

The seemingly simple word "project" seems to mean so many different things to different people, in spite of definitions by the likes of PMI, APM, etc.

I recently came across a discussion on a LinkedIn forum where the following question was asked in relation to a specific scenario:

"Projects don't exist - they need to be identified, evaluated, quantified (based on estimates) reflecting their potential values to the business and created. The hardest part in the above scenario is selling your ideas to the management. What is your experience in this area? How would you identify potential projects?"

And the scenario was:

Mr. X is a Java Programmer. His job is to maintain a Billing System. This involves Billing system support, making changes to the system upon request, etc. Because of the increasingly heavy workload on the system, the billing system does not respond to the queries instantly as in the past. A query, which normally took 4 seconds to respond now takes 1.5 minutes. Programmer Mr. X creates a project known as "Billing Performance Measurement". His supervisor approves the project (Duration 6 weeks and paid overtime). Mr. X works on the project for six weeks, keeps a track of all transactions and their timings, uncovers and resolves all the problems and project is completed successfully. "Billing Performance Measurement" was not function in Mr. X's job description. This project (a one time effort) was created to address the problem. And this is how projects are created based on needs." 

The "project" Mr X doing is not what I would call a project at all. It is simply part of business as usual. In generic terms what is being described here is the twofold process of monitoring the effectiveness of the BaU system and applying incremental improvements to keep it stable as circumstances change over time. The fact that these did not exist in Mr X's department points to the need to change the way they work. Otherwise every situation such as the one described will be seen as a "one off" and dealt with in reactionary terms. In other words, the things that you do to monitor existing systems and keep them stable are not projects, even if it calls for the occasional one-off pieces of work to maintain stability.

So, what's in a project?

For me projects can be categorised in two different (but complimentary) ways.

The first is where there are projects that:

• you have to do because they are mandated by legislation, etc.; 
• will transform your business; 
• are essential to keep your business going;
• are improvements to business as usual. 

Have-to and essential projects are no-brainers in terms of deciding whether or not to do them, so the initial question is not really relevant: e.g. changes in tax law - if you're an employer there's a have-to requirement here; Microsoft withdraws all support for Windows XP - if you're on that platform there's an essential requirement.

Transformation projects will normally be top down, e.g. "let's stop focussing on computers and start making mobile devices" (vide: iPods).

It's really only BaU improvements that are bottom up and where you need to sell your ideas to management. Mr X's project could be said to be of this type, but as I noted above, I don't see it as a project at all because it's about keeping a system stable. An example for me would be where Mr X identifies that a new process could be introduced that would improve a stable system, e.g. "if we did this we could reduce our response time from 4 seconds to 2".

In my experience unless there is a portfolio management function where all these are brought together and the portfolio agreed, it will always be hit and miss and you'll end up with (a) too many projects; (b) wrong priorities; and (c) a high degree of project failure.

How to do your project

Secondly, you need to work out how to do your projects, and this is based on Prof Eddie Obeng's work [1], which defines projects as "paint by numbers", "making movies", "knight's quests" and "lost in the fog".

Each of these is basically one of four quadrants on a Boston Matrix where one axis is "we know what we want to do" (the goal) and the other is "we know how to do it".

• "Paint" projects are where we know both what and how (e.g. construction projects); 
• "Movies" are knowing the how but not the what; 
• "Quests" are about knowing the what but not the how (to get there); 
• "Fog" is when you don't know either. 

This distinction is useful for deciding your PM approach: for example PRINCE2 is good for "paint" and "movie" but disastrous for the others, whilst agile (e.g. DSDM Atern) is better suited to "fog" and "quest". A portfolio function should also fulfill this function, but in my experience almost never does.

If you lack an effective portfolio management function, welcome to normal life in probably 70% of all large organisations!

---

Reference:
[1] Obeng, E. (1997) New Rules for the New World: Cautionary Tales for the New World Manager Oxford: Wiley-Capstone (ISBN-10: 1900961156)