Do we have to prioritize our Project Pipeline?

"...Do we have to prioritize our Project Pipeline?.." These words are not unfamiliar.

This is the classical case of unplanned and unstructured demand, expectations not met, unsatisfactory performance, and limited value creation.

Prioritization

Prioritization is about applying certain basic questions or principles. These are:

1. What is urgent and important? (Do) (Do now)
2. What is urgent but not important? (Delegate) (Nice to haves)
3. What is not urgent but important? (Decide) (Start planning), and
4. What is not urgent and not important? (Delete) (Discard).

The above is also referred to as the Eisenhower Box - "What is important is seldom urgent and what is urgent is seldom important" - Dwight Eisenhower, 34th President of the United States.

Prioritising IT investments

In the case of IT investments, it is not as easy as just applying the above but the process is very similar. For this, I suggest a collaborative approach when it comes to IT investment prioritization. This really means that both business and IT need to align on the criteria that will be used for prioritization and selecting projects for funding. This does not leave much room for creativity.

In addition when it comes to the prioritization of IT investments one need to take into consideration: (1) Enterprise Architecture, as well as (2) The overall performance, stability and capacity of IT Services (Business Services, Personal Computing Services, Central IT Services, Communication Services, and Professional Services).

A relative easy way to prioritize projects would be along the lines and scale of: (1) Quantifiable benefit versus (2) Cost and Effort versus (3) Risk of doing (4) Risk of not doing, (5) Timing, (6) Business areas impacted, (7) Complexity, and (8) Impact of future cost.

Another approach that I have used before, that is similar to the above, is purely based on the planned yield. It is structured as follows: (1) Yielding benefit above the hurdle rate, (2) Yielding benefit equal to the hurdle rate, (3) Yielding benefit below the hurdle rate, (4) Addressing Legal, Regulatory and Statutory requirements, and (5) Addressing Risk.

As a decision maker you, when using the above model, have 5 buckets in which you can categorize the various requirements for funding. This however does not yet prioritize and rank the project pipeline and one will have to apply at a measurable scale of benefit.

Buckets (4) and (5) are normally "no-brainers" to decide on based on the companies appetite for risk. I would however guard against taking unnecessary risk as in the end reputational risk and the costs and impact associated of non-compliance may have a profound adverse impact on business and even the directors of the company.

It gets a bit more tricky with Buckets (1), (2) and (3) and it is suggested that proper benefit/ investment cases be developed to understand, quantify and rank benefits. As a side note my view is that benefits realization should be contracted during the funding approval process with the Project Sponsor, and where these benefits are quantified for a specific financial year or years (for example a reduction in cost) the costs must be removed from the forecasted/ future budgets).

Bucket (1) includes the typical projects that organisations want to do (because the benefit is attractive), especially if these projects do not requires a huge financial investment. The higher the investment requirement and the longer the project will take to go-live and deliver, the priority naturally moves from a High to Medium to Low priority dependent on the hurdle rate.

It must also be mentioned that companies, where cash is a concern, do not naturally lean towards the "more than the hurdle rate idea" - the argument could be - "we are not in the game of investing rather bring projects that requires less or no investment". Arguments could also be along the lines of: (1) "Why do not use the current operational budget for the project", and or (2) "cut costs, it is cheaper".

In the end it is the financial status of the organisation at a specific point in time with specific organisational circumstances that dictates the decision. In some cases the future benefit or alignment is also not considered because of economical conditions.

Buckets (2) and (3) would be the typical hardware and software replacements or upgrades - some of these could even boarder on Bucket (4) addressing risk, due to the age of the equipment and the risk of failure or non-compliance. Age of equipment and software is also relative - there are industries that stretches these to between 5 and 10 years - depending on their appetite for risk and cash preservation.

In summary:

1. Projects must be prioritized based on relevant criteria. The above criteria can assist in the process and should be used in combination to first of all categorize and then rank
2. To a certain extent, industries are unique and the model/s may have to be adapted to fit certain circumstances
3. Make sure the projects that are included in the portfolio support and enables the business strategy
4. Prioritization must be done in collaboration with business
5. The motivation for a project must include a proper value statement (quantifiable and non-quantifiable) so that it can be ranked and prioritized
6. Projects must ranked and prioritized based on the value that they provide, whether it is above the hurdle rate or addressing risk in some shape or format
7. Look for the value creators - these are projects that create value in the shortest possible time
8. Make sure that the prioritization also include the inter-dependencies between projects - there are always a "golden thread" what is first, what is second and what can be done in parallel, based on the availability of funding, and lastly
9. There is a lot of value inherent to following a sound process. Make sure that projects are well thought through, and that it supports the overall value that the organisation wants to unlock for its customers, staff and shareholders.