A Better Way to do Project Portfolio Management: Heat Maps
How do executives, looking over a wide variety of products and projects in your company’s portfolio, know when to stop or kill one?
The decision to stop or kill a project a midst a sea of projects in a portfolio can seem almost impossible. Not only is there a question around how to kill it, but can enough information be gathered in a timely fashion to know when to kill it?
The decision to stop a project or product line can’t be made in isolation. The decision has to be made considering the entire context of the portfolio. Can we in the program management and project portfolio management community help our senior executives with this decision?
Let’s stop for a minute to think about that concept and then further dive into what the requirements / specification would be in creating such a view. What if there was a way for senior management in your organization to see, in a one page dashboard, updated in near real-time, how their portfolio of projects is performing? The dashboard would have to be simple and intuitive so that quick decisions could be made, but with enough data behind it to ensure the quick decision was a correct decision.
The following concept is inspired by the recent advancements in technology and information gathering used by the financial and stock portfolio management community. The concept is called a “heat map”. A heat map is a visual aid used to track large amounts of information very quickly in order to see trends and make informed decisions.
For stock trading, the concept is pretty simple, as stocks go up; the heat map turns green and shows the percentage increase for the day. As stocks trade below where the stock closed on the previous day, the heat map for that stock turns to red, showing the % decline in overall value. Why can’t this same concept be applied to program and project portfolio management?
To use a heat map for program and project portfolio management, we would have to slightly tweak the concept. For instance, each project would need to be weighted differently based on the overall value it will bring to the organization. That value could be applied universally across all projects in the portfolio based on typical business case metrics like return on investment (ROI) or initial rate of return (IRR). Each projects value would have to be displayed visually to provide the proper context regarding the relative size of a projects value.
In order to do that, each project would need to be represented by an individual box or square (illustrated below). The size of each project box is representative of its relative value. The bigger the box, the bigger its value. You probably will want to keep things simple by having only three sizes of boxes to represent value. A simple high, medium, and low value determination will suffice. Value relative to size could then be kept in a legend at the bottom of the map.
High ROI = $20MM, Medium ROI = $10MM, Low ROI = $5MM
The benefit of this approach is that it visually represents in-flight projects with expected business value or ROI.
Next, we have to take our model and measure each projects progress along the way. To do that measurement, we have to understand that every project will be a balance of the infamous iron triangle – scope, schedule, and cost. To truly measure value against these three constraints, we need a way to quantify and assess the value of the project and identify, if value has been decreased. Measurement of how the value of the project progresses could be assigned to each project individually using the project management value equation:
Value = Scope / (Schedule + Cost)
Source: S.T.O.P. The Project Management Survival Plan ©2011
By assigning a value to each of these constraints we’re quantifying the value of the project. Increases to schedule and cost will decrease the value of the project if more scope is not being delivered to offset these changes. It’s important that you ensure that your scale for scope, schedule, and cost are the same. Assigning either a percentage value or using a 1-10 scale can work if each variable is quantified consistently. The idea being, at the start of the project, as you determine its overall value, Value should equal 100%.
As trade offs are made between each of the three variables, the project value will change. Change to the project value could then be given a color to represent how the project is doing. For example, if any project has decreased in value by 15%, that would equal the assignment of a Yellow color to that project and be represented as such in the heat map. This yellow representation would provide executives insight into projects that heading into trouble and where the fundamental underlying business case assumptions may be in jeopardy.
Projects decreasing in value by greater than 25% could be given a red color, meaning that the project is off the rails and the original business case or ROI no longer holds water and needs to be adjusted. That adjustment could lead to the project being killed or postponed.
Having the ability to see project data in this fashion relative to other projects would give executives better insight into how to balance their portfolios and manage resources more appropriately. Viewing data in this fashion also provides improved focus; focus on where the trouble is and how to manage through the trouble to maintain balance to the business and the portfolio.
Using a heat map helps ensure that the best projects stay on course and reduces the chance that the organization will be burned!