Does anyone have a preferred method / model for evaluating long lead-time major capital projects?
Answers
Yes! I prefer the NPV calculation. For example, at Kaiser Permanente, I helped the team model out a 15-Yr NPV for a business case that was front-loaded with expenses and led to 4 types of benefits: 1) revenue enhancers, 2) expense reducers, and 3) cost avoiders and 4) cost delayers.
Items 1 and 2 are obvious. 3 just refers to other capital projects that are obviated by the primary capital project. 4 refers to pushing out an upcoming capital expense. An example of 4: Say you have a $50M building that needs to be built in 2017. However, if you do the capital project you are evaluating, then the new building does not need to be built until 2022 -this building will cost about the same, but the project is delayed 5 years which is a positive impact to your NPV and should help make your case.
Also: need to compare scenarios such as:
"Do nothing"
"Go live in Year x"
"Go live with a partial piece of the capital project"
Here is an excerpt from an article I am looking to publish in 2013 based on the work I did with Kaiser that led to multiple presentations at Beyond Budgeting Round Table Conferences:
Best practices for creating agile planning center around quickly analyzing three types of benefits: 1) expense-reducers, 2) cost-avoiders, and 3) revenue-enhancers. These agile planning models enhance margins by rapidly providing answers to three types of “what-if” questions: 1) “take it out” 2) “push it out” or 3) “reduce it by a percentage,” leading to better, faster capital allocation decisions that drive the organization forward.
Separate “Baseline financials” from “Impact financials”
Create a high-level financial model based on “business as usual”
Be able to toggle and compare between “do nothing” and “do the capital project”
Be sure to include underlying drivers in the baseline financial model that are material to modeling financial impacts associated with the capital project. For example, we included forecasted membership by region in the case of Kaiser where membership was a key driver.
Separate Financial Impacts to make the capital business case easier to communicate.
Expense Reducers: Any benefit that reduces existing expenses; these tend to be common in capital planning projects.
Revenue Enhancers: Does the capital planning project enhance revenue?
Cost Avoiders: Does this capital project enable us to avoid a significant planned cost- possibly another approved capital project in the future?
Leverage Driver-Based Planning to set up separate benefits models
Incorporate “hard benefits” in the financial model; do not attempt to quantify “soft benefits”
Hard benefits must be actionable: cutting pharmacy staffing by 10% may be a hard benefit in some cases but a soft benefit in others. For example, we separated pharmacies into small, mid-sized and large. At the small pharmacies with 1-3 FTEs, we do not model the 10% cost reduction does as a hard benefit because 10% of 3 FTEs translates to 0.3 FTEs which does not justify cutting staff expenses. However, large locations with 20 FTEs should be modeled as hard benefits with a cost reduction of 2 FTEs.
Agile/Scenario Analysis
Take it out: Use Switches “1 or 0” to enable rapid scenario analysis that either includes or excludes financial impacts from each benefits model. In some cases, set it up to include/exclude each benefits model by stakeholder group in anticipation that some stakeholder groups may or may not “buy into” a given financial impact.
Push it out: Use these same switches to model the “ramp-up” for when the financial impact will begin. In most capital planning projects, there is a phased approach and the timing of benefits may be a key driver as to whether a capital project will be approved. You must be able to quickly “push out”
Reduce it by a percentage: Set up a modifier for each benefits model that enables you to quickly multiply the financial impact by a percentage. This enables you to quickly provide feedback to anyone suggesting that the benefits model looks real in theory, but we should take it down by a percentage to be more realistic or conservative.
The question is perhaps slightly too vague, the type of project would help.
A large project requiring long lead time would be a standout even in a list of 100's of projects so one way to keep tabs on the milestone development is to ask for a monthly update on budget to actual for that specific project.
Budget to actual with commentary breakdown on what is going well, what is not going well.
If you are looking for analytics, ask the team to include those in the report.
Status reporting does two things. Informs
So hold a meeting with the PM and one level down as well, the team leads to identify and clarify issues for your own understanding.
Project management is about providing the environment for success, and more about consistently managing away the obstacles than about analytics that really don't speak to the underlying human issues.
Create a communication channel and decide who is really in the know, and later when the timeline gets tight you will know who to tap into for the real story.
I'm a little different in my views about team management because I tend to manage the progress of people in light of their core objectives and help them deal with their obstacles, and spend less time analyzing analytics. Of course it does depend on how large the project is. If you are managing thousands of people on a Dam build, then analytics are going to be something you rely heavily on. If you are managing a software implementation and you have a couple hundred involved, but only say 50 or less core milestone individuals, the timeline will dictate where you need to get involved to smooth things out.
Budget to Actual with commentary is a good start. Decide what projects are large enough to warrant that kind of detail. Meet with the PMs or engineers to learn the story on the ground.
We have projects that can extend to two years. I can tell you that we use the same discipline that you would use in shorter projects. Use your IRR rate that you would use for short term projects, but you should consider adding a contingency amount as the longer the time horizon, the more likely you will have overruns.
I like Ben's layout above, but I would note that we used to run cuts at three and five years over the project lifetime horizon to commit to funding rates. Longer term projects which inevitably generate assumption modifications can result in scope/cost creep. My past boards wanted to insure results in their
Tornado diagrams for returns (limited by best/worst scenarios) are important to establish credibility and launch the approval discussion.