7 Evolving a Funding and Governance Strategy

We have personally had the great privilege and pleasure to work on some large and very impactful traditional waterfall projects in aerospace, defense, higher education, large financial systems, and global logistics. Having assisted numerous companies over the past two decades in their transition to agile methods, we have observed several organizational and behavioral patterns. One of these is an understandable reluctance to change and move on from the past, even if the need to do so is clear and pressing and is officially sanctioned by senior management. As an example, when an organization is making its first moves toward agile methods, we often hear the refrain “But we’ve had many successes using our waterfall model! We’ve delivered many projects over the years with very solid outcomes; a few have been great successes.” This is likely true for many organizations. They probably wouldn’t still be in existence if we had been unable to be financially successful using traditional methods. This, however, is not the whole story.

If we want to dig deeper in the spirit of continuous improvement, the questions that we might ask are, Could we have done better? What percentage of our projects have really paid off? For the projects that were successful, could they have been more successful? Could they have been substantially more successful? Suppose that we spent $10 million on an effort and achieved really good business results. How do we know that we couldn’t have achieved a similar business outcome by spending half as much money, by delivering only half of the features (because only a few features ended up getting regularly used), and doing it twice as fast? For projects that were not so successful, could we have found out sooner that we were not on the right track? Could we have then adjusted our priorities and features and approach to better match what the market was telling us? Could we have turned some of those projects around and avoided some big losses?

We’ll visit these questions and explore answering them in this chapter.

Budget, Predictability, and Outcomes

Traditional approaches to funding are driven primarily by a rigid annual budgeting process. As we explored in previous chapters, the annual financial planning effort kicks off toward the final quarter of the current fiscal year to prepare for the next. Business unit managers team with counterparts from finance and accounting and work together for several weeks to generate a budget that is often suspiciously similar to what it was the previous year. This plan locks scope, time frame, and budget over the entire year in the hope of creating predictable financial outcomes. The sad truth, however, is that financial outcomes are seldom predictable. The original schedules are rarely met and substantial budget overruns are commonplace.

Common traditional practices include nonagile elements like annualized budgeting and funding, annualized strategy, detailed up-front requirements, and detailed cost estimates. The self-imposed straitjacket from these traditional funding and governance models hinders organizational agility in several ways, limiting flexibility and slowing down reaction time. These are usually implemented in response to a need for budget and schedule predictability. However, given the huge number of budget overruns and schedule slips, it is safe to say that these methods simply do not work very well, regardless of their intention.

The VMO shares a desire to achieve a level of predictability, but the predictability that we seek is centered on outcomes as opposed to outputs. Specifically, the VMO strives to achieve measurable business outcomes within a near-term timebox for a set budget. By operating at this higher level, the VMO can review, approve, and adjust much more rapidly than the highly detailed, overly rigid methods that we have used in the past.

At Nationwide Insurance, the VMO assisted their digital marketing group in the initial shift from a project to a product model. This involved helping set up end-to-end agile teams with business representation and aligning those agile teams to customer experiences as covered in the chapter 1 case study. The VMO advised senior management and helped secure fixed funding for those experience-aligned agile teams as the very first step toward a full product model. While the new structure still served projects, in that agile teams still delivered functionality aggregated to projects, this adaptation to the team and funding model accelerated value delivery and created a much higher degree of predictability around business outcomes.

As in this example, the VMO seeks predictable business outcomes not through rigidity but through flexibility. VMOs need to work with leaders in portfolio management and finance to evolve a new funding and governance model that creates and leverages adaptability as a primary means of achieving desired business outcomes while maintaining strong financial governance. VMOs need to lead the organization in keeping the funding model flexible, as covered next.

Flexible Funding: What Will Consumers Value?

According to the Business Agility Institute’s “2019 Business Agility Report,”¹ there are three clear organizational predictors of business agility: flexible funding models, organization of work around value streams, and the drive for relentless improvement. Much has been written about the power of value stream management and creating a culture of continuous improvement. Less has been written about the “how” of moving to more flexible funding, particularly in larger companies with a long history of annual project funding cycles.

While the underlying plans created in annual budgets may be highly precise, the resulting outcomes are often very inaccurate. Worse still, the business outcomes are not achieved at the level that was desired, even if most of the requirements were delivered. Sadly, organizations that use traditional project management tend to focus so much on delivering the project that they measure only scope and schedule and budget and do not really measure business outcomes at all. External focus on the customer needs, market strategy, and competitive forces are often lost, and internal project management becomes more important than anything else.

Three principal flaws in the traditional model together result in a shocking amount of wasted time and money in most companies. The first is in thinking that we can know, a priori, exactly what features the customer will utilize. The second flaw is thinking that we know the economics involved and how much the new functionality is worth to customers in an economic sense. The third serious flaw is that we can accurately determine how long it will take and how much it will cost to build the functionality. Even the most advanced product development organizations on the planet have a long history of significant product failures. Here are but a few:

• Apple Newton

• Apple Lisa

• Apple eMate

• Amazon Fire Phone

• Google Nexus

• Google Plus

• Google Inbox

• Google Picasa

• Microsoft Phone

• Microsoft Zune

• Windows Me

• Microsoft Cortana

The list goes on and on. If the richest, most successful, and most experienced development firms that the world has ever known cannot reliably predict what consumers will value, and what the resulting business benefits will be, then it is beyond ridiculous to think that we, using our long, linear, outdated, waterfall funding model, can reliably do better.

More flexible approaches are the key to creating an environment where we can quickly develop, deploy, learn, and adjust in order to iterate toward a solution that is successful across multiple dimensions. We need to be successful in the eyes of users, successful from an internal spending standpoint, and also successful in terms of achieving business goals. In our experience, we can often achieve the business results for less spend and in less time by simply allowing ourselves the flexibility to change midcourse instead of simply working the plan.

Our VMO can build on waterfall successes to evolve a new funding and governance model by taking the following basic approach:

• Provide fixed funding for value streams.

• Strategize more frequently; annually is not fast enough.

• Monetize at the feature level.

• Devise a fixed-cost model.

• Adopt business outcomes as key governance controls.

• Utilize a lean business case.

• Require frequent delivery and measure incremental business results.

• Recognize that it is fundamentally about the time value of money.

HAIER’S VALUE MANAGEMENT APPROACH

Provide Fixed Funding for Value Streams

The lean community has long advocated funding value streams instead of transactional projects. The idea here is that most organizations have long-term stable business processes such as billing, account management, sales, accounting, HR, and more. These functions will always exist, they tend to remain relatively stable, and they will always need support. Therefore, instead of funding a lot of discrete and transactional projects and incurring all of that project overhead, let’s instead budget for a stable level of support and dispense with projects.

In this model, we might say that we are willing to spend $25 million across three product lines this year, and we will also spend $5 million on HR, accounting, and similar shared systems. Great; we have just done in a few minutes what most organizations spend September through January doing. We did it by taking a top-down instead of a traditional bottom-up approach, but more on that later. How do we know that we have the right numbers, though? Well, here is the dirty little secret: budgets do not tend to change that much from year to year. In our consulting work over the past two decades we have seen, time and time again, that next year’s budget for a particular department or function tends to look remarkably like the budget they had last year, give or take a few percent. In most organizations, we go through months of hoops in order to justify keeping our current staff and in the end, that’s more or less where we end up. What a waste.

Instead, if we know that we are willing to budget $25 million toward product development across three product lines, let’s set the business outcomes that we are expecting in exchange for this investment. These target business outcomes will become the keys to our governance and controls model and to business agility. Given an agreed-to set of desired business outcomes, we can start to design features, capabilities, and MMPs (minimally marketable products) that will help us achieve the desired business goals. Since we are committing to an outcome instead of to a set of predefined features, we can let those features flex to meet the market needs as they evolve. As part of the governance model, we would expect to see transparent monthly reporting on metrics such as the following:

• functionality delivered

• measured business outcomes with respect to desired business goals

• percentage of budget spent to date

• goals and timing of the next release

• next set of features to be delivered

This model puts clear accountability and freedom in the hands of product management. It also creates a true fixed-budget model. In this model, we don’t come back asking for money because we are unable to deliver the required features given the time and money that we have been allocated. We don’t do this because we aren’t bound to a set of fixed requirements. If we can’t deliver a particular requirement due to time or money constraints, then we change the requirement. We break it down, simplify it, or perhaps even discard it because it is too expensive. No cost overruns here. What we get instead is a real and thoughtful analysis of how much a feature costs versus how much it is worth to our business. Product management makes the appropriate trade-offs, and we avoid wasteful process overhead. The first step in this direction is to strategize more frequently.

Strategize More Frequently; Annually Is Not Fast Enough

The model that we propose shifts the primary emphasis away from scope and toward measurable business outcomes. These desired business outcomes come from the VMO. The VMO works with senior leadership and product management to set quarterly strategic goals that align to organizational strategy and then uses those desired goals to approve or prioritize work accordingly. As we covered in chapter 4, the VMO can help conduct scenario planning to set strategic goals and capture them using objectives and key results (OKRs). As another example, assume that one is the following.

Objective: Create highly effective and efficient internal processes that allow us to provide world-class service to our customers. Key results:

1. Improve financial health by driving down the cost of sales processing by 15 percent

2. Improve customer sales feedback scores by 10 percent

The VMO, working closely with product management, can discover, select, and sequence MMPs that we think will achieve this measured objective. This creates a tight alignment between strategy and execution. Using the governance steps outlined earlier, leadership can track the MMPs that have been selected, the deployments, and the interim business results. We can measure whether these decisions and these leaders are on their way to achieving the business outcomes that we have invested in.

Once we have OKRs defined and MMPs charted out, the next level of funding discipline is at the more granular feature level.

Monetize at the Feature Level

To make the trade-off decisions necessary to meet our business objectives at fixed cost, we will need to get much better at understanding the economics of the features that we are building. By this, we mean that we need to understand that some features are both high value and low cost and therefore they are clearly the economic winners. Other features are low value and high cost and are economic losers. To meet our business objectives we need to be able to find the economic losers and do our very best to either not build them at all or find ways to modify them so that they are more economically viable. This is what we mean by monetizing at the feature level.

Customers and some business leaders are frequently of the I-want-it-all mindset. The result is that we have our teams spend huge amounts of time and money building too many features that turn out to be economic losers. By packaging the features that are economic losers with the features that are economic winners into the same project, we lose insight into where the real economic value is. This is not a trivial matter. Given how poor we are at estimating time, cost, and business outcomes, how can we ever hope to be able to understand the economics at the feature level?

The reality is that it is extraordinarily difficult to predict the economic winners and losers and that we will all need to get much more comfortable with the idea of experimentation and fast hypothesis testing. There are, however, fast and relatively simple ways to come up with reasonable approximations.

In particular, the WSJF (weighted shortest job first) technique mentioned previously can help here. With the WSJF estimation completed, we now have a pretty good picture of which features are most likely to be the economic winners and losers. Our product management team should then strongly consider using this information to sequence, or prioritize, the features to maximize economic value. Once we have addressed prioritization, we need to figure out the financial aspect.

What about the Money?

Those of you who know something about the WSJF model know that it does not deal in real dollars and time. It uses standard agile estimation in points that is based on the Fibonacci scale instead to come up with a fast approximation. In our experience, this is quite effective and results in sound decisions much of the time. Business, however, doesn’t run on the currency of points. Business runs on currency—dollars, euros, rupees, yuan. How do we get a handle on the actual costs? Some organizations may not be able to justify expenditures or get approvals when the decision is based on this nebulous (but highly efficient and effective) notion of points.

Focus on Economic Value, and Not Just on Costs

Here is a common pattern that we frequently see. A huge amount of time and effort goes into coming up with the precise cost of a project to within some ridiculous percentage of accuracy, but not nearly the same level of effort goes into determining what the project is worth. It is common to see fuzzy and vague or even have nonexistent business upside metrics, hockey stick projections of growth, financial benefits that won’t actually materialize for years, sloppy consumer behavior justification, and other dubious economics employed to get funding.

Return on investment (ROI) is simply the business return divided by the cost, as indicated in figure 7.1. We put a ton of effort into coming up with the exact cost but we are comfortable with fuzzy upsides. When we divide a fuzzy return by a precise cost, guess what we get? A fuzzy ROI. The result is that most of our investment decisions are fuzzy. Why put all of the time and effort into coming up with precise costs? These delays and activities just slow us down only to end up producing a nebulous business case at best.

Figure 7.1: ROI formula

Large sums are often spent not because it makes good financial sense but simply because an important stakeholder is demanding some capability. Also, because our financial planning cycle is so long, we justify the lack of rigor in the upside by saying we don’t have time or that we know our business and what our customers want. However, we can probably agree that given the huge number of projects that fail to meet their stated objectives, we obviously don’t know our customer economics very well at all, at least not to the level that we are able to monetize their behaviors. In our experience, we need to focus much more on the value of the work, why we are doing it, and how we will measure the outcome in real terms. Basically there is way too much focus on the “I” part of the ROI and not nearly enough on the “R.” The result is poor investment decisions that utilize enormous sums of money and tie up our limited resources only to result in mediocre levels of business improvement. All that said, in most organizations, someone is probably going to ask to see a cost.

So How Do We Estimate Costs in This Model?

Traditionally, we use bottom-up estimation to come up with a cost estimate. We develop fairly detailed requirements, then estimate what it would take to get the requirements done. Then we set all of this in stone, locking the requirements and the funding and the time estimate. By doing this, we lose all of our flexibility and we often lose a lot of time (and money) coming up with the detailed requirements and the detailed cost estimates. These activities can often take months.

For process improvement folks, note that putting more focus on the up-front budgeting, approval, and funding processes will speed up your end-to-end delivery process. These up-front processes are often as long or even longer than the delivery process.

In the flexible funding model, we don’t develop and estimate detailed requirements up front. How can we estimate what the required investment will be if we do not know exactly what we are going to deliver? We estimate from the top down instead of from the bottom up. Basically, we set a budget and our product owners need to stay within that budget.

Top-Down Estimation

In this top-down estimation method, we can work backward from a desired financial goal to develop a business case. Perhaps we have a business goal of reducing costs in some function by $5 million over some time frame.

The next step would be to get a rough budget for this work that would fit within our internal financial ROI hurdle. To justify the investment, perhaps we would be willing to spend up to $3 million to get the $5 million savings. Do we need more info than this? Using top-down financial outcome planning, we would be happy spending $3 million to get $5 million. Using this approach can get a level of investment without having to spend tons of time and money developing and estimating the detailed requirements.

How do we know if we can achieve the outcome with this top-down imposed budget? We might need to do a quick estimation of some of the key high-level requirements. The trick would then be to not lock in those requirements but use them as budgetary placeholders. Actual requirements/solutions would evolve as we learn more, and we could update the business case as we learn more.

The requirements and estimates that we come up with are used as a gauge, not as a mandate or a contract. What is contracted is the outcome and the overall budget and the timing. We will let the requirements specifics flex so that we can find the most impactful and economical solutions.

Now, though, we are back to having to estimate high-level requirements for the desired outcome given the budget that has been made available. How can we do that without knowing the details? Estimating requirements in hours is immensely time consuming and often grossly inaccurate. While it does give the illusion of precision, that precision is usually highly inaccurate. This is why our estimates are so often off by 100 percent or more. But there are alternatives that are much faster and easier and that if used conservatively, may be more accurate.

Equipped with a top-down estimate, we can now develop a fixed-cost model for our agile teams.

Devise a Fixed-Cost Model for Your Stable Agile Teams

Agile teams are cross functional and stay together over the medium term. They stay together often for years and so learn how to work together. They become a high-performing unit that has a predictable productivity. The ramifications of this are huge from a cost and time estimation standpoint. Imagine this scenario:

1. A 10-person agile team has a mix of developers, testers, analysts, and perhaps part of a database person and a scrum master.

2. Some folks make more and some make less, but on average, the blended cost per hour is $150.

3. Each Sprint is two weeks long, or 80 working hours.

In this example, the cost of the team, per Sprint, is 10 × 80 × $150 = $120,000. There are two important pieces of information here: the cost and time frame. Work is done in two-week chunks, and each two-week chunk costs $120,000, as shown in figure 7.2.

Figure 7.2: Cost of the team per Sprint

In estimating work, let’s get away from huge spreadsheets with row upon row of people, titles, labor categories, rates, allocation percentages, and all of that. Instead, let’s estimate in team Sprints. For example, we might come up with a ballpark estimate that it would take two agile teams and 10 Sprints, plus or minus 2 Sprints, to perform some piece of work.

Cost: 2 teams × 10 Sprints × ($120,000/Sprint) = $2.4 million

Time: 10 Sprints × (2 weeks/Sprint) = 20 weeks

Variance: 2 Sprints, which equates to 4 weeks of time variance and up to $480,000 in cost variance

Wow, that was easy.

Now we have a defined business outcome, a cost, and a time frame and an idea of the uncertainty. This way of estimating is fast and easy. When it is combined with early delivery of functionality, these practices provide us with two huge benefits. The first is that we can quickly see how much of the solution the team was able to accomplish and thereby validate our estimate. The second and much larger benefit is that we can quickly stress test the business assumptions to see if the delivered features are contributing to the expected business outcome. We need to stress test the “R” in the ROI to see if it still makes sense to even do this work at all.

An important financial outcome of this approach to budgeting is that with a set budget in place and a desired business outcome, teams will have to choose solutions that are both impactful and relatively economical. They will be forced to consider best-bang-for-the-buck solutions that make financial sense. This is quite the opposite from the usual approach of doing big up-front budgeting for every requirement that you think you will need. The result is that you usually overspend and probably could have achieved the same business results for less.

Why do we prefer top-down estimation? Because it is significantly faster and easier and, in most cases, will provide the necessary level of control and accurate-enough information. The alternative is to go through a long detailed requirements and estimation activity. Additionally, given that our ability to accurately estimate is bad at best, the outcome is likely to be unsatisfying and inaccurate anyway.

This Way of Working Is Natural and We Do This All the Time

Think of a simple grocery shopping example. We are throwing a party and we need to estimate the food costs to determine our budget. We might factor in certain snacks, drinks, entrees, and desserts, and we would use some specific numbers to help come up with more accurate estimates. For example, we might budget for 10 bottles of wine at $39.99 each. These specifics all add up to an overall budget that we decide we can live with. We get to the store, and we find some wines that are just as good but on sale for less than what we budgeted. We might also find that something else we wanted is out of stock and we have to get something that costs a bit more. We are all totally fine with this approach, and we use it every day to manage our own money. The goal is not to get this exact shopping list; the goal is to have a well-stocked party that is within our budget that results in happy partygoers. It would be ridiculous to rigidly stick to a preconceived shopping list in the face of the new and more accurate information that we gather when we arrive at the store.

We can do the same thing with requirements. We can estimate requirements for budgetary purposes to help us establish an overall cost target, but it may turn out later that another requirement that we didn’t anticipate can get us a better outcome for less money and that some requirements we thought we needed might not be necessary at all. So long as we hit our business outcome, we should be good. In fact, we can say that there’s a much better chance of actually achieving the outcome using this model, and we can often do it for less money.

How Do We Manage Changing Scope?

A key change in this approach is that the model calls for scope to be defined much more loosely. If a new requirement comes in that helps us to achieve the agreed-to and funded business outcome, then it is fair play. However, if a requirement comes in that does not directly tie to the business outcome, then it will likely not be in scope. If there is an expectation that a requirement will be delivered and it is determined that the requirement is not needed to achieve the outcome, then we will not need to spend time and money delivering it. This sort of thinking can greatly cut time and costs, since most projects have many requirements that are hitching a free ride and do not clearly contribute to measurable business outcomes.

In this model, requirements will evolve and change, and this would be evidence that the process is working! We should be changing our requirements as we learn more about how the customer behaves, as we learn more about the economics of this situation, and as we learn more about the outcomes of our technical decisions. If the requirements are not changing, then we are not learning.

Changes in requirements do not break our governance/control model because our model isn’t based on requirements: it is based on outcomes. The change management challenge then becomes one of frequent communications and alignment and transparency. Various VMO meetings, customer meetings, backlog prioritizations, release planning meetings, Sprint planning meetings, backlog reports, and other avenues exist for maintaining communications, creating visibility, and managing change so that we can stay aligned. Alignment is around the goal, and we need to be flexible if we are going to use the latest information to help us meet that goal.

If there is no fixed scope, then how do we measure progress? How will we know where we are and when we’ll be done? The answer lies in adopting business outcomes as key governance controls.

Adopt Business Outcomes as Key Governance Controls

In this model, commitment is at the business outcome level, not at the requirement level. Figure 7.3 shows the basic governance process. The project is funded to achieve an outcome, so the commitment is at the outcome level. The requirements are then allowed to flex in order to achieve the commitment. The product manager, project manager, architect, and other key parties are now on the hook to discover solutions that are both effective and economical and fast. Business outcomes should be measured at regular intervals to determine if the project is meeting its business goals. Wait! Measure regular business outcomes? That’s too late! The project will be over before we can measure against the controls, right? Wrong! Not if you are delivering into production often and are measuring feature usage and business outcomes. Agile doesn’t mean “development Sprints,” it means frequent delivery, getting feedback, and making adjustments based on what the data is telling us.

Figure 7.3: Outcome-based governance model

Bear in mind that we greatly favor a pure value-stream-based flexible funding model such as that described earlier. In that model, we would fund the value stream at a level that is likely to be similar to previous years with adjustments as needed for unusually large efforts or contractions. However, for many organizations, this may be too much change too soon. For those desiring a less disruptive approach, we could try an outcome-based funding process. In this model, organizations can continue to fund projects but they would base the project funding on business outcomes instead of detailed scope as the primary form of governance. In this model, we maintain a project-centric model as opposed to a fixed-funding value-stream model.

In this model, the VMO could fund a project for $X million to achieve some desired business outcome such as account growth, cost reduction, compliance with a regulation, or parity with a competitor. In this outcome-based project, we still have a project, but the primary financial governance is around the business case, which comprises the business outcome, the spend, and the time frame but not the requirements scope. For example, we might say that sales order processing needs all the following:

• costs reduced by 15 percent

• cost reduction achieved by the end of year

• costs remain within a budget of $4 million

• processing funded incrementally on the basis of quarterly demonstration of results

Organizations do not have to abandon projects entirely to achieve business agility. They can still have projects with a defined and measurable business-outcome target, a time frame, and a budgeted dollar amount, allowing the requirements to flex to meet the business needs and customer needs. This gives the flexibility to add, change, and remove requirements as needed to achieve the outcome. In this model, the business outcome is what counts, but we do still have some of the old project parameters in place:

• We still have a budget.

• We still have a time frame.

• We have a means of control (frequent demonstration of business results).

• What we do not have is fixed scope.

Using this funding model, combined with early delivery of functionality and an experimental mindset, we should start to see early and measurable financial results, cost savings, revenues, new users, lower dropout rates, and more. If we don’t, we can learn from the results and quickly pivot to functionality and features that will provide the results that we are looking for. These actual results can be measured against the monies spent to date to see if the ROI financials are still making sense.

This sort of approach could be the basis for an interim funding model that will allow us to maintain projects for a while longer while we begin to get adept at outcome-based funding and governance. Hopefully, over time, we will begin to realize that we might not even need projects at all anymore.

Utilize a Lean Business Case

One way to help drive business agility is to utilize a lean approach to business cases. In many organizations, business cases are far too detailed, and that level of detail removes our ability to flex and pivot as needed. By capturing requirements at too low a level, we end up painting ourselves into a corner. The detailed requirements then end up becoming the driver of success instead of the business results becoming the driver. However, we probably do still need some sort of a business case to justify and document our investment. A lean business case can provide the answer. A lean business case will be at a higher level of abstraction. It will focus on the business goals, desired timeframes, major functionality or capabilities to be delivered, and high-level estimates. Given that it is not unusual for estimates of time and money to end up being hundreds of percent off using our traditional approaches, it is relatively safe to say that we can live without the details if for no other reason than the details are often wrong anyway. A lightweight business case, seen in figure 7.4, would be a smaller artifact of only a few pages that would likely have the following elements:

• The business problem to be solved

• The importance, severity, or magnitude of this business problem

• The new capabilities or high-level features that the solution will provide

• The business outcome that will be achieved and how it will be measured

• The constraints or nonfunctional requirements that we need to address

• A release road map that gives approximate timing for which features will be delivered when

• A requested working budget that the team will stay within

We have helped clients implement such business cases, so we know this can be done. Some lean business cases have been as small as four pages. Such lean business cases not only provide flexibility but also are much faster to produce and review. Managers often spend months preparing highly detailed business cases. Given what leaders make in terms of salary, this is an extraordinary cost in terms of time and money. Lean business cases are smaller, faster, and cheaper and can be just as effective. If this weren’t enough, they also provide us with the flexibility that we need to rapidly adapt to the changing needs of our customers.

Figure 7.4: Lightweight lean business case

Require Frequent Delivery, and Measure Incremental Business Results

The lean business case focuses primarily on the desired outcome. To measure progress toward the business outcome, the VMO must move the organization toward requiring interim releases to production that allow us to get objective data on the performance of this project. The only measure that matters is actual incremental business results. The flexible funding model we have paid out thus far is based on the achievement of business outcomes. The control, therefore, is predicated on getting real business feedback, measuring performance against the business goals, and adjusting the product requirements to achieve the business outcome. If we don’t deliver something, then we don’t get the feedback, and we can’t make the pivots necessary to be successful.

In exchange for flexible funding, VMO leaders need to work with finance and other leaders to require early and frequent delivery. They also need to demand measurable operational data from agile teams that can be used to assess the business outcome and drive financial performance. Without this, we have nothing more than a waterfall project with a blank check.

Here is where finance and accounting can be drivers of business agility. By demanding early and frequent operational data that can be used to justify continued spending, the business achieves financial results sooner and gets massively more visibility into the viability of projects than it ever did before in its old plan-the-work-and-work-the-plan model.

What about Capital Expenditure? Traditionally, capital expenditure (CapEx) has been managed using waterfall phases with the early phases being expensed, later development and test phases being capitalized, and any work done after deployment being expensed once again. In an agile delivery model, we are performing analysis, design, development, testing, production deployment, and break-fix activities simultaneously. Obviously, a phased approach to capital and expense management will not work here. Luckily, we can manage CapEx using other means. The most obvious, and perhaps even more accurate than the traditional approach, is to use the actual work items or tasks themselves instead of phases.

Using an agile project management tool that tracks stories and tasks, we can say that new feature or functionality story development is capitalized, defect stories are expensed, and testing tasks for new functionality are capitalized. In this way, we can measure the actual amount of work going to expense versus capital.

In some cases, the organization may have capital versus expense targets or ratios that they need to maintain. In these cases, we could work backward and give our product owners “budgets” for capital and for expense. If this were needed, we could say that 40 percent of the backlog items can be expensed but the rest must be capitalizable, for example. In this way, we are engineering a financial outcome by prioritizing our backlog in line with CapEx guidelines.

But things get more complex after we have an initial deployment to production of an MMP or other minimal solution. If we continue to add on to this minimal solution, is it capital or expense? If the add-on work offers new or enhanced functionality then it probably should be capitalized. If new work is maintenance or a defect fix then it should be expensed. But some firms have more rigid internal rules around this, such as “Any work done to support the release after deployment should be expensed” or “A new software version release is synonymous with a project.” In these cases, we may need to work with accounting to design smarter and more accurate rules that are still in alignment with generally accepted accounting principles.

In these cases, it can be helpful to put more fine-grained definitions around the word release. For example, if we are deploying new code to production every few weeks, is each new deployment a new release? Deployment and release do not necessarily have to be synonymous. A new version or release of software could be delivered through many individual deployments.

The CapEx topic has historically been tricky, but most auditors have by now seen many companies go down the agile path and will have some experience in how to handle these situations. So the CapEx problem is now readily solvable with an agile project management tool of some sort that we can use to tag or categorize stories and tasks so that they can receive the most appropriate accounting treatment. The result should be more accuracy, not less.

Recognize That It Is Fundamentally about the Time Value of Money

It is amazing that even the largest and most sophisticated firms do not often focus sufficiently on the time value of money with respect to project and product work. Everyone should understand that a dollar today is worth more than a dollar next year for a variety of reasons. Yet, remarkably few organizations require their project and product investments to deliver dollars back to the business sooner rather than later.

The financial investment advisory firm the Motley Fool explains it this way: “Time value of money is one of the most basic fundamentals in all of finance. The underlying principle is that a dollar in your hand today is worth more than a dollar you will receive in the future because a dollar in hand today can be invested to turn into more money in the future. Additionally, there is always a risk that a dollar that you are supposed to receive in the future won’t actually be paid to you.”²

A couple of concepts here we should more deeply explore. The first is that a dollar in hand can be invested now, and the second is that dollars you are supposed to receive in the future may not materialize. We typically invest in projects to be paid a return. Projects are usually expected to reduce costs, increase revenues, improve efficiencies, and reduce risks. This means that most of our projects should be paying us back not only for the cost of the project but also for additional gains.

In most organizations, the demand for projects greatly exceeds the funds and capacity available, resulting in many unfunded project requests. Imagine what we could do if all of these investments could start paying us back sooner. We’d have more money to fund more work, and we’d become even more accomplished. The key is to force projects to start to pay us back sooner.

Agile and DevOps techniques give us the tools to accelerate both deployment and payback. By focusing efforts on a few features that we believe are economic winners, and using agile to design, deliver, and deploy those solutions quickly, we can start to reduce costs now. We can start to bring in more revenues now. This generates more money and it generates it now, so that we can start to make those additional investments, just as the Motley Fool said in the preceding quote.

What if we make these deployments and we don’t see the uptick in revenue or the downturn in costs? This is where the second part of the time value of money definition comes in. As the Motley Fool’s definition stated, “There is always a risk that a dollar that you are supposed to receive in the future won’t actually be paid to you.” By using early deployments, we can start to see that some of these projects are not going to be able to pay us back. We can see sooner rather than later that the economics just aren’t there. The calculated upsides were faulty and our estimated costs were low. Using agile delivery, we can see that we aren’t going to get paid back, and we can start considering whether to cancel or redirect these efforts.

An agile and financially disciplined organization would heavily tilt funding toward those projects and products that can achieve positive financial impact sooner rather than later.

Summary

Funding and governance can be serious barriers to or enablers of organizational agility. The VMO can provide strong leadership that moves funding and governance toward key flexible practices that get investments to pay back sooner. To make this work, the VMO will need to educate leaders and to get clearance and support from senior finance sponsors to evolve a new model.

We can focus on metrics for the time value of money to achieve more frequent delivery of value, lower risk, and more frequent measurement of project economics. Working this way would allow us to make smaller bets, which are much lower risk. We make these smaller bets through a flexible funding process.

A flexible funding model along with more frequent strategizing helps to create an environment that lends itself to quick development, deployment, and learning. In this model, we provide fixed funding for value streams. We find economic losers by monetizing at the feature level and by doing our very best to either not build them at all or find ways to modify them so that they are more economically viable.

We use business outcomes as key governance controls, using lightweight lean business cases to document and justify investments, capturing requirements at a high level.