Let’s take a step back and look at the historically most
common path of projects. During the budgeting
process usually the year before an idea for a project is suggested. Then this idea goes through some cycles and
an estimated budget gets placed on the project list for the coming year. When the project is kicked off, the budget is
set to the estimated budget. Few
organizations go through a true project costing and just artificially constrain
themselves to the suggested budget.
However, let’s say we are a forward-thinking organization
that does a full project estimate and sets the budget. Most projects run into delays, issues, and
missed assumptions that inevitably puts a strain on the budget. There is a fear to go over budget. The project team compresses training,
testing, or both to come in on the budget suggested. This then leads to rework and enormous costs
to repair something in production instead of fixing it right the first time.
An additional issue is how the project is pitched in the
first place. It is pitched with a 5-year
savings, ROI, NPV, IRR, or a payback period.
However, many companies do not validate if the project did in fact
deliver the numbers suggested. Does your
company validate project savings for 5 years and report back?
These are all antiquated problems and have been the way
projects are done since I have been in the industry (over 25 years). Yet we rinse and repeat. Then comes Agile which throws organizations
for a loop in how to track and report costs.
So far, I have not suggested anything new.
The business suggests numbers and does not always measure
results and the project team suggests costs and must constrain something or
blow the budget. What if we applied a
different mindset to tell the story?
What if there is a single number that could govern the decisions? Enter Net Operating Value.
Net Operating Value makes budgeting a project a little more
ancillary. All the budgeting methodologies
and controls still apply; however, the question becomes framed a bit
differently. Net Operating Value (NOV)
is simply 12-month project benefit subtracted by project costs. From a business context, what are we gaining
for 12 months (revenue, cost savings, etc) minus the cost of the project? If a project takes longer than a year than
expand the benefit.
Taking this concept through a case study, let’s say there is
a project that the business feels could generate $1M of revenue in the first 12
months, however, do not have the resources necessary to complete the project . They could hire a vendor to complete the work
for $100,000. It can be painful to have
to suggest the added cost of $100,000 to the budget if it was not planned
for. However, if we frame the
conversation differently, then NOV comes into play. Instead of what it would cost to do the
project, we ask what is the net gain in the next 12 months of the project? In this case, the net gain is $900,000. The question becomes what are we willing to
risk for $1M rather than what will it cost?
The answer could be $200,000 for a NOV of $800,000. This aligns business and the project
team. The project team is signing up for
getting the $1M of revenue and the project team is signing up for $200,000 in cost. This changes how we approach change requests,
scope creep, etc. If the NOV is known
and widely displayed, then decisions would be represented in the NOV instead of
over budget.
For example, if an unknown was uncovered that would cost $50,000. The question becomes is $250,000 acceptable
to spend to get $750,000 of NOV?
What do you think?
