One of then biggest obstacles to successful project delivery occurs right at the beginning of the lifecycle – deciding which projects to approve. You take in 20, 50, 100 project requests, and then it’s decision time! What do you do? If you’re like most IT departments, one of two scenarios occurs.

1 - The CIO looks the list over and decides, then takes the resulting flack from the stakeholders who were denied. And often his decision is based on the squeaky wheel principle – who will squawk the loudest if they don’t get their pet project?

Or 2 - the CIO has had enough of being the fall guy, and either brings the list up to the executive staff meeting or forms a steering committee to make such decisions. This is a huge improvement, in that enterprise level decisions are now owned by the stakeholders. The problem is, most of these discussions degenerate into VP’s arguing over their pet projects.

What that steering committee really wants is information. What are the benefits of each project? How much will it cost? What are the risks if we do it? What are the risks if we don’t?

This brings up problem #2 – how do you perform a cost/benefits analysis on 100 project requests? That’s a bigger effort than most of the projects themselves!

The answer is relatively simple – create scorecards that rank each request on a common scale over a number of attributes. But before we get to that, we need one more item – a good project request form.

In most IT departments requests come in haphazardly. The VP of Sales tells the CIO they need a new CRM system. An email comes into the PMO looking for a network upgrade in Boston. There’s simply no uniformity to how requests enter IT, and thus no uniformity to the type of information you get.

A good request form provides a method and channel for submitting these requests in a uniform way. While I could write an article simply on creating a request form, for our purposes we are looking for two items:

1.        Business benefits. What are the hard and soft benefits expected from this project?

2.        Impact. How many departments, users, processes, and geographies will be affected?

Now, on to the scorecard. The idea is to rank each request in 3 areas: Benefits, Costs, and Risks. By ranking each area on a common scale, we can compare apples to apples and make some decisions. A good practice is to break each area into it’s constituent elements, create a 1-5 ranking, then create a composite score for each area using a weighted average. For example:

Benefits: Elements could include Revenue Increases, Cost Savings, Strategic Objective, Customer Satsifaction, etc.

Costs: Elements should include Incremental Costs, Resource Hours (all staff, not just contractors), On-going Costs.

Risk: Elements could include Geographic Impact, Business Units impacted, Number of Systems Affected.

The 1-5 scoring depends on the size of the organization. For example, a Fortune1000 company might score incremental costs:

1 = $50-100K

2 = $101 – 500K

3 = $501K – 1M

4 = $1M - $5M

5 = Over $5 million

The same idea would apply to each element. Finally, add up the scores in each area and create a weighted average. The end result should be a relative Benefit, Cost, and Risk score for each project request.

Who should be deciding the scores? Obviously, the requesting stakeholder has the best grasp on benefits, which is why we asked those questions in the request form. Often, IT has the best feel for costs, and can use similar projects from the past to make a quick call on those scores. And both the stakeholder and IT have information on risk elements.

One more quick tip on ranges: Make them broad, so you don’t get bogged down in detailed estimating. At this stage you’re looking to make some quick cuts to get your request bucket down to a reasonable level. The remaining projects can go through a more detailed analysis for final decisions.

If you put all those scores into an eProject Dynamic App, you can then plot them onto a classic quadrant grid using Crystal (as I've done in the PMO in a Box solution set). Anything in the high-cost, low-benefit quadrant can be tossed. The low-cost, high-benefit projects are a no-brainer – get them going! The low-cost, low-benefit projects are small and can often be squeezed in for some quick wins. You’ll have to really think about the high-high projects – but that’s what steering committees are for!