Skip to content

Subdivide a huge project list to simplify the prioritization process

A classic problem for many project-oriented organizations (IT, R&D, Engineering, Operations) … how can resource prioritization be simplified, yet repeatable? It’s a fairly involved topic, but a common approach is to group projects into a workable number of “chunks” … we’ll use the term Initiatives. How will this help?

Challenge: Clarify the team’s priorities, alignment, and resource levels – without going into the details

  • The CEO asks a question – what Projects are on the to-do list for IT? [Do we actually expect the CIO to review 300+, or the (current) top 20 of a fairly fluid list?]
  • Top tier of [insert business unit] asks [insert IT director] to break out IT spend / allocation against Projects / Priorities – on a single PowerPoint slide
  • The Finance team wants us to allocate next year’s budget across “projects”, somebody suggests calling out the business’ Key Projects – but that list will be outdated in a few weeks

Solution: Group all projects into Initiatives, and use this list to identify / prioritize / categorize new and existing work

Ok, this seems kind of obvious, but managing an ongoing list of projects and initiatives is a bit of a hassle – you’ll need to deal with

  • Fluidity – at the project level, the current #1 priority / “gun to the head” can and will change week to week
  • Detail – Work always expands to fill a perceived vacuum, and you can easily anticipate a “backlog” or oversupply of project ideas that could stretch out 2 years or more
  • Noise – Expect a lot of “noise” in the detail, especially if you’re taking on an existing backlog; you’ll see project requests that stretch back months and years, with names of Leads, Sponsors, and Requestors that are no longer with your organization

The Initiatives approach should help with all of these – especially in the beginning stages, when you are laboring to remove most of that old “noise” in the system.

Key Question: How do we identify an Initiative? Here are two simple rules

  1. If the work / projects underneath can aggregate to at least 10% of the total ($$, LOE, revenue, whatever) – it’s an Initiative
  2. If it’s a bullet point on a slide for the CEO or the BoDit’s an Initiative

Rule 2 is pretty important to understand – it’s your first simplistic hack at tying project prioritization to business strategy / corporate goals. Don’t be too cynical about this approach; the sound bites that appear on executive radar screens may change every quarter, but if you are eventually communicating with those folks for go/no go approval, capital / expense or people resources, you better make sure they can draw a straight line between a given project and their current hot buttons.

Ok, so with that premise, here’s a starter set of of Initiatives that are generic enough to work in most organizations. The first ones are for general business projects …

  • Compliance: Includes mandatory work due to regulatory, audit, and/or vendor requirements
  • Procurement: Streamline and standardize procurement to realize savings on Direct and Indirect spend
  • Cost Reduction: Drive hard-dollar cost reductions through improved process and use of technology
  • Maintenance of Business: Includes mandatory work due to customer demands, plus value-add work to enhance customer relationship. No hard-dollar revenue impact, except when preventing a loss of business
  • Productivity: Drive soft-dollar cost reductions through improved process and use of technology
  • Growth: Enable and support hard-dollar, top-line revenue growth

Note the focus on hard-dollar benefits. This is a philosophy/guideline, not a rule; your organization or your management style may allow for soft-dollar benefits in project justifications. Also, the list is sorted from things you have to do, to things you could/should be doing.

These next ones are for IT / technical projects; you need to make the point that a certain amount of the IT departments’ time should be spent on IT-focused projects (investment work) …

  • Business Continuity: Foundational work required to keep the business technology operating
  • Maintaining Currency: Drive down long-term cost of ownership by maintaining technology at a pace with vendor and environmental advances
  • Technology R&D: Frontier work to evaluate and operationalize new information technology to support business goals

Yes, these are all generic Initiatives – no examples of Rule 2 (above), since that will be organization-specific. The key is to make the list of reasonable length, assign projects to initiatives, and present the aggregate totals when discussing prioritization

“… our resources are distributed across 20% Compliance, 40% Maintenance of Business, 30% Cost Reduction, and 10% Growth projects”

“Sounds great!”


“Goodness, we need more growth – can we dial back on the maintenance projects?”

Now that is a very simple, meaningful, relevant conversation to have with an exec.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles

You Can’t Run IT Like A Business (except Maybe You Can …)

Well-intentioned IT leaders, and their functional peers, want to apply run-like-a-business concepts like customer satisfaction and value creation to the operations of shared service functions. If we can describe things with the same words, we can apply the same fixes. But it's a bit tricky to restate things in a meaningful way...

Read more
Saving For A Rainy Day ... (Innovation Budget)

Accelerate Innovation with a Simpler Budget Approach

Organizations are desperate for innovation, but these are still investment choices that require complete and credible data to enable the right decisions. Developing a simple standard for characterizing all costs will accelerate decision making.

Read more