Wahl and Case

In my 13 years of experience in managing projects, I have learned that ‘Doing the Right Project’ is often more difficult than ‘Doing the Project Right’. For both, large sources of knowledge are available and finding suitable processes in these areas is not difficult. However, I often see that when selecting which project to start, the C-suite commonly use only one or two parameters and sometimes just go on their gut feelings.

Impact of Selecting a Low Priority Project

Beside the potential opportunity loss, following are the negative sides starting projects in the wrong order:

• Resources assigned to the project such as staff, equipment, and funding, will find their way to other, higher priority projects. There could either be a small trickle over time or a one-time substantial cut.

• The project team will sooner or later discover that even though they succeed delivering within the stipulated time and budget their invested hours will have a small impact on the company’s bottom line.

• It will be difficult to request dependent projects to adjust their schedules, resulting in delays.

• As high priority scope items are put on hold in favor for this project, it is likely that some of them will be added as change requests, further slowing down the project and causing the team a lot of extra work.

As result, despite having a clear project charter and all required resources assigned, the project is heading for doom. The team, trying their best to salvage the situation, realizes that this might affect their careers.

In such a scenario, what do executives need to do to remedy the situation? Do they need to kick-start an initiative to design a new project approval process? And have all projects—which are about to start— follow it? Maybe, but it will take time. Is there no easier solution available?

A Simple Project Selection Tool

Let me present a method I learned from “Scaled Agile Framework”, a few years back. This takes a number of parameters into account when calculating project priority and offers some quality insight regarding financial impact of selecting one project over another. And, the additional advantage is that it is super easy to get started – just a whiteboard will do fine!

First, it introduces the concept of “Cost of Delay,” expressed as the sum of Business Value plus Time Urgency plus Risk Reduction. This is to be regarded as the opportunity loss incurred by not having the product released. Now, in this simple model we are not interested in calculating the dollar value for this, instead we are only interested in knowing the relative difference for Cost of Delay (CoD) between projects.

Table 1 is an example from an IT organization with a team of great engineers who can basically work on any type of project. Which one should they start with, #1 or #2 or #3?

Table 1

To fill in the numbers in red, IT and business stakeholders participate in a short workshop carrying out four different rounds of discussions (one per category) to agree on which value each project should have. They can only choose between the numbers 1, 2, 3, 5, 8, 13, and 20, which have no units. This number series offers rather large jumps, which will ensure that long debates does not occur if the value should be 8 or 9, since this really does not matter much in this model. (Sometimes business side only joins Round 1 and 2 and IT only joins Round 3 and 4 due to domain expertise.)

After quickly calculating the blue values in the columns on the right hand, we can see something important; it makes most sense starting with project #3, then #2, and last #1. The reason for this is that despite #3 has a low CoD, it can be released quickly and business can keep capitalizing on it while the IT organization continues working on the other longer projects.

The Numbers

There is a need to provide a proof, so that readers can make an informed decision regarding the usage of the model. Firstly, let’s assume that the whole team will be assigned only to one project at a time.

What would be the total CoD in running the projects in the order 1, 2, 3 compared to 3, 2, 1 (details in Table 2?

Case 1: Execute the projects in order by size

Here, we can see that since we postpone project #2 and #3 for a long time, we will incur a high cost of delay.

Case 2: Execute the projects in order of the new value for priority we calculated

Here, we can see that since we released both #2 and #3 early, we don’t incur a large opportunity loss.

Conclusion

I strongly recommend taking efforts to find out which project should start first. This will improve both staff morale and financial results. If you have no current model for this, or have encountered too many inflated ROI calculations and question their credibility, I recommend first trying out, the above mentioned, Simple Project Selection Tool. This will provide important buy-in from both Business and IT side.