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

Comments

  1. Hi,

    I stumbled onto your blog when I was doing some research on competition. I really enjoy your blog.

    I wanted to make a comment about point 2 — the “common” thought that many organizations are using C-level execs to do project selection.

    There is actually a step prior to selecting the RIGHT projects to do, that is the C-level execs should decide on the direction of the company (ie: a roadmap) and assign a top down budget to that particular strategy. For instance, company X has $50MM to invest in 2011, the CEO/CIO/CTO must then decide the split of that $50MM — perhaps we are in a recession, so let’s minimize new and visionary products and focus more on enhancements to the current offering. Each of those strategies will get a quantifiable top down investment which will:
    (1) determine your scorecard criteria for the RIGHT projects to do.
    (2) determine whether you should get more internal/external resources and whether you have the finances (top down meets bottom up) so you CAN do the projects.

    It is up to the C-level execs to make strategic decisions and let portfolio/pipeline managers (SVP of Technology or the likes) do the actual selection of projects.

    Full Disclosure: I currently work at CA Clarity and have worked for Planisware.

Trackbacks

  1. […] This post was Twitted by ericderaspe […]

  2. […] This post was Twitted by ClearSpringBA […]

  3. […] Last time, I wrote about ways to pick projects that satisfy the company’s “SHOULD do” dimension: ones that are strategic, financially beneficial, risk mitigating, or legally mandated, for example. I set out practical guidelines for the process of selection in that dimension, to ensure as level a playing field as is possible.  And I left it for this follow-on post to discuss the other dimension, the “CAN do” dimension, which needs to calibrate the list of chosen projects to what can actually be accomplished by the available resources. […]

  4. […] philosophy of “consensus” no matter what. As with a PPM steering committee, you should put effort into designing an effective committee and process, and allow for quick “tie-breaking” authority and action as […]

  5. […] comments and the links he provided and I would encourage anyone to go back and look at those posts. Lots of good ideas, challenges, and issues highlighted in his comprehensive post. I wanted to focus on a few key points when I think of balancing the whole portfolio or […]

  6. […] posted myself, early and often, on myriad ways to push effectively for IT/business alignment. So I’m anything but a blind proponent for a […]

  7. […] a future post, I’ll expand further on this topic, talking more about the difficulties of and approaches for […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mastodon