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
- If the work / projects underneath can aggregate to at least 10% of the total ($$, LOE, revenue, whatever) – it’s an Initiative
- If it’s a bullet point on a slide for the CEO or the BoD – it’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 qurter, 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 realitionship. 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 crertain 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!"
(or)
"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.
Labels: business value of IT, PMO, presentations, tech management
posted by James P. MacLennan at 8:20 PM
| Permalink
| 0 Comments
