Project prioritisation matters

In business, how often do you see a list of tasks or initiatives, yet only the high priority ones are worked on? Lower priority initiatives are then delayed until they are forgotten or until they become high priority. Worse still is when lower priority initiatives are halted before completion, so higher priority initiatives can commence. Where do the less glamorous housekeeping activities fit? In these circumstances, business becomes reactive with lots of initiatives starting but very few finished; those that do are often semi-finished and descoped.

Decisions, decisions

Priority involves a decision. While it is true one could create a mathematical model from a number of preset weightings and criteria, the reality is that priorities are usually set and then interpreted by people. People use subjective judgement and emotion, no matter how much they try to remain objective. Most people can only effectively work on one task at a time, which task they work on comes down to their own perspective of priority: “This task is priority 1, but I’ll just check my email first”; “I’m flat out today but I just need to grab a coffee before we get started”; “I’ll be right with you, I just need to finish my timesheet”; “I know this is priority 1 but my boss insisted I get this report to him”.

What does priority 1 mean anyway, especially when three or more initiatives can all be ‘priority 1’ or ‘high priority’? The most effective priority systems in portfolio management are ladder-based systems. They involve only one priority 1 initiative, one priority 2, and so forth. The beauty with them is the simplicity, as the system needs no explanation. Any new project gets assigned a priority; the others adjust priority accordingly. In one large organisation we worked with, people knew that if your project wasn’t priority 150 or higher then, forget it, you wouldn’t get resources.

Decision-making involves input, for prioritisation that means information such as strategic fit, costs, benefits, risk and so on. This information comes from scoping and analysis, however these require funding and resources and that means prioritisation—a classic catch-22. An effective approach we saw, which worked in the IT side of a large organisation, was considering each project as comprising three main stages. Based on a very brief analysis, projects could be initiated and prioritised through to the end of feasibility.

After business case approval, projects were held until a subsequent build priority was set. Projects could then proceed through to the end of build and test where once again they were held until a subsequent deployment priority was set. It was recognised that projects, once given the green light at each gate, would proceed uninterrupted until the next gate, with priorities used to resolve resource conflict. Those setting priority needed to be mindful of the resource capacity of the organisation.

Making relative priority work

Inherent in these priority models is to conceptually separate the business case and funding approval process from the relative prioritisation. Business case and funding approval is focused on ‘should we?’ and it is a key decision point that should be revisited throughout the project lifecycle. Relative priority is a different decision, it focuses on the ‘who’ and ‘when’.

While it is sometimes the case that a business will involve similar people in these decisions, the relative priority is a specific decision typically made by a group of senior managers. This group, called a steering committee, project review committee, or other impressive moniker, will typically include key representatives from both the supplier and customer sides of the business. Relative priority requires consensus of opinion, a challenge.

Relative priority will be painful. For it to work, some projects will need to be placed on hold, others will need to be cancelled. ‘The boss says’ projects will need to be formally prioritised, tricky politically. Business-as-usual activity will need to be added to the mix. Try telling IT that responding to a systems outage or major bug is less important than your project. Project plans and business cases will need to be altered to suit, interproject dependencies and impacts assessed, especially where projects are delayed.

Through simple concepts such as a funnel diagram for reporting (e.g. only so much fits through the spout of the funnel, the rest bank up), the parking lot (for those initiatives on hold), simple decision gates, and open communication with and support from senior management, relative priority is an achievable objective.

The four pillars of prioritisation are:

1. A simple relative priority model such as a priority ladder.
2. Priority specific to stages, separated by formal decision gates; e.g. feasibility versus build/test versus deploy.
3. A formal decision making forum for prioritisation, made up of supplier and customer representatives.
4. Communication.