The Practical CIO: Difficulties in project prioritization & selection, part 1

How does your company pick which projects to undertake?  Demand outstrips available resources: nearly always, there are far more “good ideas” for things to do than can actually be done in a given time period.  So how do you decide which ones you take on?

If you research this general topic, you’ll find a lot of rather intricate, idealistic screeds that detail how to model an admixture of financials, market potential, risk factors, etc., and promise that this will get you “the” answer.  I don’t dismiss the importance and general validity of such approaches, but let me be frank: that’s actually not what usually happens at most companies. Not even close. Here are some real-life (albeit generally unsuccessful) approaches to project selection that I’ve seen in real companies. In no particular order:

1) Do ’em all: everything proposed by anyone goes on a list, and people just work like crazy and do the best they can to accomplish whatever;
2) Let a single executive (CEO, CIO, CTO, whoever) decide. That’s what executives are there for, right?
3) Insist that all proposed projects be evaluated for ROI, and do the ones that produce the biggest ROI number.

Any of these approaches, in my experience, produces a great deal of thrashing, and causes eventual frustration that, yes, things aren’t working well. Various elements of the business feel disenfranchised or just inadequately served; or, people realize that ROI may not be the universal answer (or worse, they start to “game” their ROI estimates even more than before); or, there’s an outspoken disgruntlement that the right projects still aren’t getting done. People start to feel that the model of project selection that you’ve been using (if you’ve been using one at all) doesn’t let those projects float to the top that they know “in their gut” are the most important.

So let’s turn to a practical, doable approach that I’ve seen help considerably.  First, you have to establish ground rules about the process of project selection, and they have to be, collectively, wiser than the ineffective approaches that are outlined above. Most importantly, those ground rules have to cover both of the main dimensions of a disciplined project selection, as I’ve discussed in detail before:

• projects that we SHOULD do (based on determinations that use benefit measures primarily, such as likelihood of financial ROI for the company);
• projects that we CAN do (based on the “factory capacity” of the resources on hand and on the magnitude of the projects being attempted)

Note that, again, organizations tend to struggle with evaluating both of these dimensions, and decisions on both are often made very much by the seat of the pants (i.e., chutzpah, wishful thinking, blind determination).

I’ll use this post to discuss ways to pick projects that satisfy the “SHOULD do” dimension, and in my next post turn to ways to ensure that those projects will meet the “CAN do” dimension.  Both dimensions inform each other, of course; they’re not independent or sequential. In other words, the company might be able to tackle five smaller projects rather than one huge project, and figuring out if it’s a good idea to actually make that trade-off will be based on executive judgment of the benefits in both scenarios. By the time the chosen projects begin, though, both dimensions must be analyzed and baked into a concrete plan: you need to be confident that a) the selected projects will all benefit the company; and b) you have the resources necessary to complete all of them with high quality in the allotted time.  In other words, and I perhaps belabor the obvious here: don’t plan for things you can’t do!

In my experience, a practical process for choosing which projects the organization SHOULD do needs to incorporate the following guidelines:

• The process must be a repeatable one, with standard input artifacts (not mere table thumping by determined champions). Artifacts typically include:
  • a project proposal, with a clear but high-level statement of the objective, scope, ownership, anticipated benefits/ROI, and expected measures of success;
  • high-level estimates of the magnitude (level of effort) required to implement the project
  • discussion of alternative approaches and risks of each approach, including possibly retaining the status quo
• The process must be cross-functional: it needs to have senior representatives of the business’s main constituents at the table. Include the usual suspects:
  • Finance
  • Sales
  • Marketing
  • Customer service
  • IT / Engineering
• The process must be multidimensional: it needs to recognize that the set of chosen, viable projects will (over time) cover at least these aspects:
  • expense reduction;
  • revenue increase;
  • strategic (market positioning);
  • legal/regulatory/security exigencies;
  • risk mitigation
• The process must recognize that there’s no single, obvious, automatic, metrics-based “silver bullet” for picking which projects to do. That said, it’s also true that metrics can and should be part of the discussion: especially, metrics on appropriate resourcing can help prevent the standard optimistic approach of “overstuffing the bag” with more to do than the factory has capacity for.  I’ve already discussed some of the pitfalls of relying solely on ROI, where it’s not unusual to see wildly optimistic assumptions by zealous stakeholders baked into the resulting number.
• The process must incorporate fitting the chosen set of projects to “factory capacity”. See Part 2 for more details on this.
• The process must recognize that there will still be a judgment-based component to project selection, and focus on standardizing the input information to ensure that judgment is maximally informed.  Recognize that biases and politics will play some role in project selection, and seek actively at all times to mitigate the effects of such bias.  Again, the most important check and balance? Not to take on too much, despite whatever urgency, politics, or potential ROI may exist: that would be nuts.
• The process must be balanced in outcome across time, rather than tending to favor one type of project to the exclusion of others. If “roof projects” are never approved, for example, that indicates a lack of balance and a probable bias towards short-term revenue projects.
• The process must not be overly complex (for practicality, and again, in recognition that it’s going to be largely a judgment call in the end)
• The outcome of the process must be clear and unequivocal: a set of approved, sanctioned projects for the given time frame, with all other projects considered as NOT approved at this time. Ambiguity here can render the whole effort moot.

Clearly, such a process requires an able, active, and respected facilitator.  There’s no one answer for who that should be, since it depends on the personalities and the culture. I’ve seen it work with the head of the PMO as facilitator, or the CIO, or the COO. I do recommend that it be a fairly senior individual with the ability and cajones to tell people when they’ve stepped out of line with the above guidelines.

More coming next time on specific ways to “right-size” the project portfolio to what can actually be accomplished.

Lagniappe:
1) Frank Hayes, “Time to PONI Up”, http://www.computerworld.com/s/article/print/76504/Time_to_PONI_Up?taxonomyName=ROI&taxonomyId=74, December 9, 2002

2) Joshua Greenbaum, “The Paradox of ROI: Do ROI studies really help organizations make better buying decisions?”,  http://www.intelligententerprise.com/021115/518enterprise1_1.jhtml, November 15, 2002 *** Link and article no longer available ***

3) Sai Machavarapum, “Prioritizing IT Projects Based on Business Strategy”, http://www.cio.com/article/22976/Prioritizing_IT_Projects_Based_on_Business_Strategy, July 15, 2006

4) “Are you ready to analyze the demand for your 2010 portfolio? (Part II)”, http://www.chiefportfolioofficer.com/?utm_source=Twitter&utm_medium=twit&utm_campaign=Twit