A Step-by-Step Guide to Business Case Validation

Creating a business case is a systematic process designed to justify a proposed project, investment, or decision within a business context. 

A strong business case typically includes an introduction with background information, a clear problem or opportunity statement, a detailed analysis of options, a risk assessment, a financial analysis, a proposed solution, and a high-level implementation plan.

But validating your business case is just as important as creating it. 

The validation process is essential for confirming that the proposed initiative is likely to achieve its intended outcomes and align with organizational goals.

I have validated many business cases, both for my clients and as an active angel investor, and if there is one thing I have learned, it is the critical importance of ensuring that a business case is both robust and realistic before committing significant resources. 

Over the years I have developed a structured approach that I want to share with you.

1) Review the Problem Statement or Opportunity

Clarity and Accuracy: Ensure the problem or opportunity is clearly articulated and well understood. Question whether the impact of not addressing the problem or missing the opportunity is accurately presented.

See my article "Understanding Your Problem Is Half the Solution (Actually the Most Important Half)" for some further reading on this topic.

2) Scrutinize Assumptions

Identify and Test Assumptions: List and validate assumptions related to market conditions, customer behavior, cost estimates, and revenue projections. Compare them with historical data and industry benchmarks to ensure they are realistic.

Scenario Analysis: Conduct best-case, worst-case, and most likely scenarios to test the sensitivity of the business case to changes in key assumptions.

3) Evaluate the Analysis of Options

Comprehensive Consideration: Ensure all reasonable options, including doing nothing, have been considered. 

Verify Estimates and Projections: Ensure cost estimates are accurate and comprehensive, and validate revenue projections against market data and trends. Recalculate ROI and perform sensitivity analyses to assess the impact of changes in key variables.

Focus on Economic Benefits: In my opinion ALL benefits of a technology project should be expressed in dollars (or any other currency). To make estimating the benefits of a project easier and more realistic, I use a simple model to assess the economic benefits of a project. It consists of five benefit types (or buckets); Increased Revenue, Protected Revenue, Reduced Costs, Avoided Costs, and Positive Impacts.

Total Cost of Ownership (TCO): TCO is an analysis meant to uncover all the lifetime costs that follow from owning a solution. As a result, TCO is sometimes called 'life cycle cost analysis.' Never just look at the implementation or acquisition costs. Always consider TCO when looking at the costs of a solution. 

Time Value of Money: The time to value (TTV) measures the length of time necessary to finish a project and start the realization of the benefits of the project. One project valuation method incorporating this concept is the payback period (PB). There is one problem with the payback period: It ignores the time value of money (TVM). That is why some project valuation methods include the TVM aspect. For example, internal rate of return (IRR) and net present value (NPV).

Unbiased Evaluation: Check if the criteria for evaluating options are relevant and unbiased, and consider whether alternative criteria might lead to different recommendations.

For more details on the financial valuations of your options have a look at my eBook The Project Valuation Model ™. You can download it for free here.

4) Examine the Proposed Solution

Feasibility: Assess whether the proposed solution is technically, financially, and operationally feasible, with realistic timelines.

Strategic Alignment: Verify that the solution aligns with the organization's broader strategic goals and represents the best value. 

See my article "Do Your Projects and Initiatives Support Your Strategy?" for some further reading on the topic.

5) Engage Stakeholders

Involvement and Feedback: Engage key stakeholders, including executives and subject matter experts, to gather feedback and address concerns. Their support is critical to the project's success.

See my article "10 Principles of Stakeholder Engagement" for some further reading on the topic.

6) Perform a Risk Assessment

Comprehensive Risk Analysis: Review the risk assessment to ensure all significant risks are identified and properly analyzed. Evaluate the feasibility of risk mitigation strategies and ensure contingency plans are in place.

See my article "Risk Management Is Project Management for Adults" for some further reading on the topic.

7) Review Legal, Regulatory, and Ethical Considerations

Compliance and Ethics: Ensure the project complies with all relevant laws, regulations, and industry standards. Consider any environmental, social, and ethical implications.

8) Assess Market and Competitive Analysis

Market and Competitive Validation: Reassess market conditions and competitive responses to ensure the business case remains relevant and viable in the current environment.

9) Evaluate Implementation Feasibility

Resource and Timeline Viability: Confirm that the necessary resources are available and that the proposed timeline is realistic. Consider conducting a pilot to validate key aspects of the business case.

Opportunity Cost: If you implement the proposed solution, what other initiatives can't you do? Is it still worth it?

Cost of Delay: What does it cost me if I do the project slower or later? Is there urgency?

For more details on the opportunity costs, and cost of delay of your initiative have a look at my eBook The Project Valuation Model ™. You can download it for free here.

10) Seek Third-Party Review

External Validation: Consider an independent review by a third-party expert to provide objective insights and increase the credibility of the business case. 

See for example my Independent Business Case Review service.

11) Final Review

Final Review: Ensure all sections of the business case are complete, coherent, and consistent. Revise as necessary based on the validation process.

Best Practices

Documentation: Keep a detailed record of validation steps, findings, and any revisions made to create a clear audit trail.

Stakeholder Engagement: Maintain clarity and avoid jargon to ensure understanding and buy-in from all stakeholders.

Data-Driven Analysis: Base your analysis and recommendations on solid data and evidence.

Constructive Approach: Focus on strengthening the business case rather than undermining it, using challenges to ensure the best possible outcome.

In a nutshell: Effective validation ensures that any weaknesses in the business case are addressed before committing significant resources, thereby reducing the risk of failure and increasing the likelihood of success.

If you are an executive sponsor, steering committee member, or a non-executive board member and want an unbiased expert view on your business case? Then my Independent Business Case Review is what you are looking for.

Read more…

How "Hubble Psychology” Is Skyrocketing Your ERP Program Costs

September 2012, NASA Inspector General Paul Martin released the results of an investigation that looked into why the U.S. space agency has had long-standing problems in meeting its programs’ cost, schedule and performance goals. 

For instance, in 2009, it was estimated that the James Webb Space Telescope (JWST) would cost US $2.6 billion to develop and launch by 2014. At the latest count, the tab has ballooned to over $8 billion for development (not including $940 million contributed by international partners) and another $800 million for five years of operational costs. The huge cost overrun on JWST—as well as many other projects—has not helped win the friends in Congress that NASA needs in order to maintain its funding. 

Many large ERP implementation projects suffer from such cost explosions as well. See for example Case Study 7: The $2.5 Billion Cross-Border Expansion Mistake by Target, Case Study 6: How Revlon Got Sued by Its Own Shareholders Because of a Failed Sap Implementation, and Case Study 3: How a Screwed-Up SAP Implementation Almost Brought Down National Grid. 

And although the parties involved in these projects typically don’t need friends in the US Congress, they sure do need some friends in the organization implementing the new ERP system. 

The NASA report is an interesting read and gives a number of explanations for why these cost explosions happen. A culture of optimism, lack of experienced personnel, technological complexity, and constant changes in funding to name a few. 

Many of these reasons apply to large ERP projects as well and are not new insights. But one paragraph of the report really got my attention. It states that one of the primary causes of NASA cost/schedule problems is what the inspector general calls the "Hubble Psychology" that is common among the organization's managers. 

“… Many project managers we spoke with mentioned the “Hubble Psychology” – an expectation among NASA personnel that projects that fail to meet cost and schedule goals will receive additional funding and that subsequent scientific and technological success will overshadow any budgetary and schedule problems. They pointed out that although Hubble greatly exceeded its original budget, launched years after promised, and suffered a significant technological problem that required costly repair missions, the telescope is now generally viewed as a national treasure and its initial cost and performance issues have largely been forgotten.” 

How pervasive is this psychology? The report noted that, “when asked whether their projects had been successful, every project manager we interviewed answered in the affirmative, regardless of the project’s fidelity to cost and schedule goals.” 

I have observed the same psychology with program, project and workstream managers of ERP implementations. The same for system integrators and suppliers that are involved in the project. 

Because the investments in these programs are so large, the sunk costs of these programs after they have run for a while are significant for most organizations. And that is why these projects are almost never cancelled after they have run for longer than 6-9 months. Financial and reputational losses are just too big. 

And everybody involved in these programs knows that. So why worry about going over budget and moving the go-live date a few times? 

And it seems that after an ERP system actually goes into production, no one actually remembers how much it overran its budget or schedule. Or that the budget was ridiculously high from the get go. So also after going live there is nobody that holds anybody accountable for overspending. 

To fix this you will need to find ways to reward managers and suppliers for good stewardship of your organization's resources as enthusiastically as it does for successful implementations and to hold managers and suppliers appropriately accountable for mismanagement of resources. 

In a nutshell: Spend what you need, not what others want you to spend. 

Read more…

Show Me Your Budget and I’ll Tell You What You Value

Being in the middle of the yearly budgeting process I could not help but think about this quote from former US Vice President Joe Biden;

“Don’t tell me what you value, show me your budget, and I’ll tell you what you value.”

The RGB model developed in the early 2000s by Louis Boyle at Meta Group, and in increasing use by companies like Gartner and McKinsey, can help you with both seeing and showing what you value.

It offers a business-oriented way to categorize technology investments at a high level.

The model classifies investments as having one of three purposes: to Run, Grow, or Transform the business. Hence RGB model. Each classification implies different kinds of benefits.

“Run the business” investments

“Run the business” investments are about enabling essential, non-differentiated services having the desired balance between cost and quality. Benefits are measured in reduced cost, price-to-performance ratios, and risk.

Examples of “run the business” functions for most businesses include audit, payroll, and regulatory compliance. On the technology side, examples include most infrastructure investments, most IT security spending, and most IT operations spending.

“Run the business” investments do not produce revenue. They are essential to staying in business, but they don’t differentiate the business in most cases.

Exceptions include those cases wherein customers begin to perceive a "run the business" function as a differentiator, as appears to be happening now with “green” (environmental) initiatives and has happened recently with IT security in the financial and cloud services industries.

Many CIOs struggle to justify infrastructure investments, but in "run the business" terms the case is usually straightforward.

First, the function is essential and typically does not need justification per se (e.g., the organization is going to be compliant with Sarbanes-Oxley in one way or another), although the level of performance required may vary (how compliant must we be?).

Second, the proposed investment will deliver the best possible price for the required level of performance (e.g., it costs much less to upgrade systems over five years than to hire an army of expensive auditors annually). Price-to-performance benefits such as these are often easily and accurately calculated.

“Grow the business” investments

"Grow the business" investments are about improvements in operations and performance related to the company’s existing markets and customer segments.

The value of such investments may be measured in terms of operational performance improvements, such as cycle time or improved quality, or in financial terms, such as capital expense reduction, increased revenues and margins, increased customer lifetime value, or reduced general and administrative expenses.

Examples include opening a new online or social networking channel for sales and service of existing product lines, or eliminating 10 percent from costs of conducting a key business transaction.

When you’re talking about improved profits or service to customers, in most cases you’re talking about growing the business.

“Transform the business” investments

"Transform the business" investments are about new markets, new products, new customers—in other words, new horizons for the company, and maybe for the entire industry.

Such investments are measured in prospective market share and revenues in entirely new markets. These investments typically involve big rewards and high risk.

They can change the future of the company and even an industry when they succeed, or produce a large hole in the ground when they fail.

Apple changed its own course and that of the music industry with iTunes; Motorola lost billions of dollars and an untold amount of alternative opportunities when the Iridium project failed.

The word transform is often used in businesses to describe a lot of initiatives that would be classified as "grow the business" projects.

In this classification scheme, by definition transformative initiatives involve new markets, new customer segments, and new value propositions, and not merely improved margins or profits.

For example, a supply chain “transformation” that produces 40 percent increased throughput at a 30 percent reduction in costs with 20 percent improvement in quality is a "grow the business" initiative and not a transformation.

Focus on economic benefits of investments

Many projects and initiatives have objectives like “delighting the customer,” “improving time to market,” “happy employees,” or “operational efficiency.”

But hardly any organization will be blessed with unlimited resources to invest, and there’s just no getting around the fundamental challenge that all organizations face: sustaining themselves.

At some point the projects and initiatives you invest your limited resources in should help the organization to sustain itself and possibly even grow. So the question becomes “How do these benefits impact the economics of your organization?”.

The risk of placing too much focus on the economic benefits is relatively small and one can argue that lately it's largely been ignored by many organizations (just have a look at the number of Silicon Valley unicorns that are currently imploding). It is of no help having happy customers and no revenue.

The biggest risk of focusing on the economic benefits of projects is when organizations find opportunities to reduce costs that may ultimately have a negative impact on the customer experience. This is particularly problematic for service organizations, where a more efficient operation often translates to less happy customers.

To make estimating the benefits of a project easier and more realistic, I use a simple model to assess the economic benefits of a project.

It consists of five benefit types (or buckets).

1) Increased Revenue
2) Protected Revenue
3) Reduced Costs
4) Avoided Costs
5) Positive Impacts

Run, grow, and transform are not benefits; they simply point to the types of performance improvement that should be expected from an initiative and thus show you where to look for the benefits.

If you say, “This is a "grow the business" initiative,” it is still necessary to say exactly how the initiative will grow the business.

> Will it increase margins for a key line of business? If so, how—by reducing costs, or by increasing revenues faster than costs?

> Will it increase market share? If so, in which customer segments, in which markets, by how much?

> Will it affect soft measures of value, such as customer satisfaction, that ultimately may translate to customer retention and so to revenue? If so, how will the value be measured?

Or as Gartner states it: "Market leaders track IT spending against strategic planning pillars".

Technology budget conversations

Taking the above into consideration your IT budget conversations should have three dimensions:

1) Investments in IT needed to maintain products or services (Run). The benefits we can expect are reduced costs, avoided costs, protected revenue, as well as some other positive impacts;

2) Investments in IT capacity needed to support organic business growth (Grow). The benefits we can expect are increased revenue and reduced costs, as well as some other positive impacts;

3) Investments in IT needed to support new products or services (Transform). The benefits we can expect are increased revenue and reduced costs, as well as some other positive impacts;

Don’t forget that part of 2) are tools to make your IT organization itself more productive. In a company whose IT-related costs are 25 percent of the overall budget, improvements in IT productivity have a direct impact on IT costs per business transaction.

A classic problem this model brings often to the surface is the disproportionate focus on Run as many CIOs spend more time in running the legacy systems and tend to allocate upto 60% (if not more) of the annual budget to this category due to small business demands and other legacy reasons.

Grow and Transform are not given enough importance thus constraining the ability of the organisation to be ‘future-ready’ and competitive.

In a nutshell: Run, grow, and transform point to the types of performance improvement that should be expected from an initiative and thus show you where to look for the benefits.

Read more…

What Is the Real Value of Your Technology Project?

In order to assess project opportunities and make difficult trade-off and priority decisions about where to focus your limited resources, you need to be able to compare projects on a like-for-like basis.

And since there’s just no getting around the fundamental challenge that all organizations should be sustaining themselves, at some point the projects we invest in should create value.

Therefore, you should make project valuation — estimating the value of your projects — a part of your decision-making process.

So what is the value of a project? It’s simple:

Value = Benefits − Costs

In previous articles I discussed estimating project costs (see “What Are the Real Costs of Your Technology Project?”) and project benefits (see “What Are the Real Benefits of Your Technology Project?”).

If you have both the costs and benefits of your project in dollars, the computation of value is very straightforward.

But what this definition is completely ignoring is time. And time has a major impact on the value of a project.

Let’s take two projects, A and B, as an example. All figures are expressed in thousands of U.S. dollars.

Project A
Year	1	2	3	4	5	6	7	Total
Costs	800	100	100	100	100	100	100	1400
Benefits	400	500	400	300	300	200	200	2300

Project B
Year	1	2	3	4	5	6	7	Total
Costs	2000	1000	1000	1000	500	500	500	6500
Benefits	0	0	3000	3000	2000	1500	1000	10500

Now we will have a look at how time influences the value of these projects.

Measurement Period 

Let’s take one of the most used project valuation methods as an example: return on investment (ROI).

Return on investment (ROI) is a performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. ROI tries to directly measure the amount of return on a particular investment, relative to the investment’s cost.

To calculate ROI, the benefit (or return) of an investment is divided by the cost of the investment. The result is expressed as a percentage or a ratio. In our case, the investment is our project. The return on investment formula is as follows:

ROI = (Current Value of Investment − Cost of Investment) / Cost of Investment

When we apply this formula to our project A we will get the following result:

Project A
Year	1	2	3	4	5	6	7
Accrued Costs	800	900	1000	1100	1200	1300	1400
Accrued Benefits	400	900	1300	1600	1900	2100	2300
Value	-400	0	300	500	700	800	900
ROI	-50.00%	0.00%	30.00%	45.45%	58.33%	61.54%	64.29%

And for project B we get:

Project B
Year	1	2	3	4	5	6	7
Accrued Costs	2000	3000	4000	5000	5500	6000	6500
Accrued Benefits	0	0	3000	6000	8000	9500	10500
Value	-2000	-3000	-1000	1000	2500	3500	4000
ROI	-100.00%	-100.00%	-25.00%	20.00%	45.45%	58.33%	61.54%

You see that, depending on what year you use for measuring your ROI, the results are totally different.

Time to Value

The time to value (TTV) measures the length of time necessary to finish a project and start the realization of the benefits of the project. One project valuation method incorporating this concept is the payback period (PB).

The payback period refers to the amount of time it takes to recover the cost of an investment. Simply put, the payback period is the length of time until an investment reaches a break-even point. The desirability of an investment is directly related to its payback period. Shorter paybacks mean more attractive investments.

When we look again at Project A and Project B you see a massive difference in the payback period.

Project A has a payback period of 24 months, and Project B has a payback period of 42 months.

Time Value of Money

There is one problem with the payback period: It ignores the time value of money (TVM). 

TVM is the concept that money available at the present time is worth more than the identical sum in the future due to its potential earning capacity. This core principle of finance holds that, provided money can earn interest, any amount of money is worth more the sooner it is received. TVM is also sometimes referred to as present discounted value. 

That is why some project valuation methods include the TVM aspect. For example, internal rate of return (IRR) and net present value (NPV).

Net present value (NPV) is the difference between the present value of cash inflows and the present value of cash outflows over a period of time. NPV is used in capital budgeting and investment planning to analyze the profitability of a projected investment or project.

The following formula is used to calculate NPV:

As you can see, the higher your rate of return “r” is, the lower the current value of your project. Typically the value for “r” is determined by management.

The internal rate of return (IRR) is the discount rate that makes the net present value (NPV) of all cash flows from a particular project equal to zero. IRR calculations rely on the same formula as NPV does.

To calculate IRR using the formula, one would set NPV equal to zero and solve for the discount rate (r), which is the IRR. Because of the nature of the formula, however, IRR cannot be calculated analytically and must instead be calculated either through trial and error or using software programmed to calculate IRR.

Generally speaking, the higher a project's internal rate of return, the more desirable it is to undertake. IRR is uniform for investments of varying types and, as such, it can be used to rank multiple prospective projects on a relatively even basis. 

Assuming the costs of investment are equal among the various projects, the project with the highest IRR would probably be considered the best and be undertaken first.

Cost of Delay

Cost of delay (CoD) is a key metric that represents the economic impact of a delay in project delivery. It is a way of communicating the impact of time on the outcomes we hope to achieve. More formally, it is the partial derivative of the total expected value with respect to time.

CoD combines urgency and value — two things that humans are not very good at distinguishing between. To make good decisions, we need to understand not just how valuable something is, but also how urgent it is.

I discussed CoD in detail in the article “What Is the Real Cost of Delay of Your Project?”. Depending on your urgency profile, your project end date can have a significant impact on the value of the project.

So what is the real value of your project? 

As we have seen in this article, the value of a project is determined by its benefits, costs, duration, and urgency. Putting it all together leads to the following diagram.

An ideal project valuation method is one where all metrics will indicate the same decision.

Unfortunately, the approaches mentioned above will often produce contradictory results.

Depending on management's preferences, your economic situation, and selection criteria, more emphasis should be put on one metric over another.

As explained above, there are common advantages and disadvantages associated with these widely used project valuation methods.

Nonetheless, you should use one or more of them in your selection process.

In a nutshell: Determining the dollar value of your projects is essential for selecting the right one. Value = Benefits − Costs, and is dependent on duration and urgency.

Read more…

What Is the Real Cost of Delay of Your Project?

One challenge that every organization faces is deciding which project should be prioritized. Would it be in a company’s best interest to embark on a $1 million project that would take three months to finish or a two-year project that would cost $30 million?

And if you want to do both, which one should be done first? Or is parallel the best option? Does it makes sense to speed up or slow down an existing project?

All these questions center around the economic impact of the project's delivery time on it's business value.

Starting what date can we expect value to be delivered? And what happens when we don't deliver on that date?

Cost of delay (CoD) is a key metric that represents the economic impact of a delay in project delivery. It is a way of communicating the impact of time on the outcomes we hope to achieve. More formally, it is the partial derivative of the total expected value with respect to time.

Although the word "delay" implies this only applies to ongoing projects, exactly the same metric can be used for projects that have not started yet.

CoD combines urgency and value — two things that humans are not very good at distinguishing between. To make good decisions, we need to understand not just how valuable something is, but also how urgent it is.

Unfortunately, many organizations don’t use CoD in their decision-making process — mostly because they do not know why it's important and how to do it. This can be a very expensive missed opportunity as delays may cost millions depending on the scale your organization operates on.

In my opinion, every organization needs to understand what CoD is, how to calculate it, and how to optimize your project portfolio to reduce CoD.

Estimating cost of delay

As stated before, CoD is the economic impact of a delay in project delivery. Before we start with estimating this economic impact, here are some examples of possible CoD:

Product development – the amount of money you will lose if the launch of your new product will be two months later.

Software development – the amount of money you will lose if the release of an essential feature causes a big client to move to a competitor.

Solution implementation – the amount of money you will lose if you fail to replace the existing ERP system by the end of this year.

IT operations – the fines you have to pay if your systems do not comply with new regulations on time (GDPR, FATCA, etc.).

To estimate these potential costs of delay for your project, start with estimating the benefits that you will receive per week after you deliver anything to the market or to your organization.

These benefits typically take the form of:

1) Increased Revenue
2) Protected Revenue
3) Reduced Costs
4) Avoided Costs
5) Positive Impacts

See my article “What Are the Real Benefits of Your Technology Project?” for details on estimating your project's benefits.

For example, if you are selling a software-as-a-service (SaaS) product and you plan to deliver a new add-on feature that you anticipate will bring you $20,000 per week, every week that you postpone the release will cost your company this sum in missed revenue.

After you've estimated the benefits per week you can estimate the costs of the project per week. After all, when you are not starting a project the costs are zero, but when you do start the project you will have costs.

See my article “What Are the Real Costs of Your Technology Project?” for details on estimating your project's costs.

In order to estimate the real cost of delay per week you have to subtract these costs from the benefits. Not doing this is unfortunately a mistake many organizations make when using CoD.

Always remember that CoD is the partial derivative of the total expected value with respect to time.

Value = Benefits - Costs

When your project has a duration longer than six months you can estimate the benefits and costs per month instead of per week.

Types of cost of delay

Before you start estimating the CoD of your project it's important to understand that there are different types of CoD. Remember CoD combines value and urgency. Where value is depending on your project and your business, urgency takes usually one of four forms. These can be described with so called urgency profiles. Each of these profiles will lead to a different type of CoD.

In order to understand the urgency of projects, we need to understand the life cycle of benefits, and the effect of being late. The effect of delay can be different depending on what the type of benefits are, and whether there is any influence from the wider market.

The two main variables to consider are a) the length of the lifecycle of the benefits (how quickly the benefits ramp up and down) and b) whether the peak is affected by delay or not.

Profile 1: Short life-cycle; peak affected by delay

In some cases the life cycle of benefits is relatively short. Benefits ramp up to a peak and quickly decline again. Sometimes this is because the value-add quickly becomes standard for customers.

This is for example common for mobile phones. What is hip and differentiating today will be bargain-basement stuff in months rather than years. In other examples, the market is always creating new alternatives, moving on quickly to the new “new thing.”

The fashion industry is also a good example of this, which is why Zara competes by having very short lead-time from spotting the new look on the catwalk, to selling it on the hangers in the store.

With these types of benefits, if you are late, the peak benefits are affected, as shown below.

Profile 2: Long life-cycle; peak affected by delay

Another urgency profile is where there is a first-mover advantage, making it difficult for latecomers to recover position. This can be due to barriers to entry or the advantage that scale can bring.

A good example of this is cloud computing services. Offering something similar to Google Cloud Platform, Amazon Web Services, or Microsoft Azure can only be done with huge investments, and even then your chances are slim. This urgency profile is typical for services for which the market consolidates down to two or three major players. These products benefit from some form of preferential attachment mechanism or “network effect.”

Profile 3: Long life-cycle; peak unaffected by delay

A third urgency profile is where the lifecycle benefits are long-lived. Benefits ramp up to a peak and are sustained over a long period. In most established organizations this is the most common urgency profile you will find.

A typical example is where we are automating a process or improving efficiency, reducing time or cost. The ramp-up and peak of benefits is effectively the same whether the solution is late or not. This is also the easiest urgency profile for which to calculate the cost of delay, as it approximates nicely with a simple parallelogram.

Profile 4: Impact of an external deadline

Where requirements have a specific deadline the urgency profile is slightly different. The benefits profile itself can look like any of the above three, but the benefits only ramp up around a certain date.

As a result, the cost of delay is zero until the point where you need to start development — to avoid incurring any delay cost. To calculate the point at which the CoD kicks in, we need to consider the likely lead time, ensuring that the solution is delivered just-in-time, rather than too early or too late.

Let’s take for example a new regulation that will be effective from the 1st of January 2021. As of that date, front-office staff will need to prepare extra documentation in order to meet this regulation. The requirement is to automate the new documentation process so that the front-office employees can produce the documentation automatically.

The requirement will avoid the additional manual processing resource, which is estimated to cost about 10 full-time equivalents (FTEs) at $52K per FTE. The benefit type is categorized as “Avoided Cost.”

10 FTEs x $52K = $520,000 per year = $10,000 per week

Let’s say it is the 1st of March 2020 right now, which means we have 10 months to do something about this requirement. It’s going to take about 20 weeks to deliver this new feature. If we start developing the solution now it will be delivered in August 2020, but we don’t need it until December 31.

We deal with this by calculating when we need to start developing the solution by subtracting the duration from the external deadline. In this case we need to start development by the 1st of August at the latest (20 weeks before the external deadline of January 1st).

Before the 1st of August: cost of delay is $0 per week.

After the 1st of August: cost of delay is $10,000 per week.

In a nutshell: It’s vital for companies to understand what cost of delay (CoD) is and how to calculate it. Knowing the impact CoD will have on a business will give management greater insight on the projects in the pipeline and help them determine which ones should be prioritized.

Read more…

What Are the Real Benefits of Your Technology Project?

The benefits of a project.

Everyone talks about it, and there is no lack of opinions about what they are, but when it comes to project benefits it’s often hard to reach consensus on what people actually mean.

Additional revenue, higher profit margin, happy employees, satisfied customers, new clients, less pollution, less waste, operational efficiency. They are all benefits.

Most dictionaries define a benefit as something like “a helpful or good effect.” But good effects are very hard to measure, compare, and understand.

Therefore, in my opinion ALL benefits of a technology project should be expressed in dollars (or any other currency).

Using dollars is helpful for a number of reasons. The key advantage is that, with the benefits being expressed in a uniform way, you can compare projects immediately between business areas, across delivery streams, and in the whole project portfolio.

Another reason for assigning dollars to benefits is to prevent determining the benefits of a project by measuring “who shouts the loudest,” something many organizations suffer from.

And given that most of the costs of a project are already measured in dollars, you can easily compare the costs and benefits of a project to determine it’s overall value.

While estimating a number for costs is generally easy to do, assigning a dollar value to the benefits is more of a challenge. Getting to data and assumptions that make estimating benefits in dollars possible is difficult, but it can be done.

And it pays off: You'll gain a clear idea about what the expected benefits are, and what assumptions you need to test, in a way that all project stakeholders will be able to understand.

Focus on Economic Benefits

Many projects have objectives like “delighting the customer,” “improving time to market,” “happy employees,” or “operational efficiency.” But hardly any project will be blessed with unlimited resources to invest, and there’s just no getting around the fundamental challenge that all organizations face: sustaining themselves.

At some point the projects you invest your limited resources in should help the organization to sustain itself and possibly even grow. So the question becomes “How do these benefits impact the economics of your organization?”.

The risk of placing too much focus on the economic benefits is relatively small and one can argue that lately it's largely been ignored by many organizations (just have a look at the number of Silicon Valley unicorns that are currently imploding). It is of no help having happy customers and no revenue.

The biggest risk of focusing on the economic benefits of projects is when organizations find opportunities to reduce costs that may ultimately have a negative impact on the customer experience. This is particularly problematic for service organizations, where a more efficient operation often translates to less happy customers.

To make estimating the benefits of a project easier and more realistic, I use a simple model to assess the economic benefits of a project. It consists of five benefit types (or buckets).

1) Increased Revenue
2) Protected Revenue
3) Reduced Costs
4) Avoided Costs
5) Positive Impacts

Each project must contribute to one or more of these; if it doesn't, it has no benefits at all.

Increased Revenue

Increased revenue is the revenue associated with either increasing sales to existing customers or gaining new customers. It may involve increasing share of wallet, market share or even the size of the market itself. It can be done by making changes that add value to existing products or services that customers are willing to pay for, or adding new products or services that either existing or new customers are willing to pay for.

The projects in this area are likely to be “delighting” features for either current customers or new ones. This is also where innovation occurs, enabling new business models and increasing the size of the market by serving new markets and undercutting others.

Protected Revenue

Protected revenue is the revenue that is currently being received from existing customers who are paying for the products and services you already sell. Sustaining and protecting this revenue often requires ongoing improvements to at least keep up with competitors and maintain existing market share.

The projects in this area are more defensive in nature, making processes faster and easier to use and removing any pain that might drive customers to consider switching to a competing product or service. The changes made here are usually not considered valuable enough for existing customers to pay extra, though. This is the basic maintenance of existing products and services that can be described as “sustaining innovations.”

Reduced Costs

All those ideas about how to be more efficient contribute to this bucket. The projects that add to this bucket will reduce the costs that you are currently incurring. A typical example of this can be changes that speed up or automate processes, reducing the number of people required. It can also result in savings in overhead, equipment or other costs.

Avoided Costs

Avoided costs are costs you are not currently incurring but there is some likelihood that you will in the future, unless some action is taken. Some examples of these might be the need to hire additional people to handle a new process, fines you may have to pay, or loss of reputation that impacts goodwill or brand value.

This category typically includes a lot of things that many organizations might consider to be operational or strategic risks — often with an estimate of the probability of an event occurring.

Positive Impacts

Positive impacts are benefits that cannot be translated to one of the above but are important enough for your organization to take into account when evaluating a project. For example, creating less pollution and waste, or helping the family of a deceased colleague, or working for free for a non-profit.

When such benefits are important for you and your organization you will give them a disproportionate dollar amount as value. This way projects with such benefits will always be part of the short list of projects to be selected for implementation.

When these benefits are not so important, make the dollar value of the benefits equal to the costs, and projects like these will only be part of the short list if they have additional economic benefits.

And when the importance of these benefits are just lip service just give them a zero dollar value and you will see them almost never in your shortlist.

Make Assumptions Transparent

Once you have identified the benefit types of your project, getting to a dollar figure typically requires some assumptions about the effects of the change or the cost of alternatives. The reality of technology projects is that they involve many risks, unknowns and uncertainties. In order to calculate the dollar benefits, you will often have to make assumptions or educated guesses and apply probability where necessary.

The goal of these estimations and assumptions is accuracy, not precision. Accuracy is how close an estimate is to the true value. Precision is the number of significant figures you give in your estimate. These are two different things.

The initial process of estimating the benefits of projects needs to be fast — less than one week. Over time you will get better information to improve your assumptions or replace them with facts. You can then update your estimations and re-evaluate.

By making assumptions transparent you prevent blatant gaming of the benefits and cost figures. This means all assumptions are part of the document that estimates the benefits. Transparency of assumptions also allows others to scrutinize and improve those assumptions. And better assumptions will lead to more reliable estimations.

In some cases, the same assumptions are used again and again. It can be helpful to use the same numbers for particular project benefits and even start building a repository of assumptions and key data points that are shared and built on over time.

And Now What?

Now that you've arrived at an estimate of your project benefits expressed in dollars, and you already estimated the real costs of your project in dollars you are now ready to determine the real value of your project.  This will be the topic of my next article.

In a nutshell: Estimating the benefits of your project in dollars is essential for making good decisions, comparing projects, and aligning stakeholders.

Read more…

What Are the Real Costs of Your Technology Project?

As a project recovery specialist who works with organizations to help turn around troubled technology projects, I do a lot of cost evaluations and projections as part of my project review process.

Project budget and costs are topics of much discussion and I have more than once seen red faces and yelling matches between executives because of it. Lack of transparency, unexpected costs, and cost attribution being mostly the reason for such outbursts.

Understanding the real cost of a technology project helps you to determine if you should start, stop, or continue a project. It also helps you with vendor selection and project valuations. It is invaluable input for good decision making.

Total Cost of Ownership (TCO)

The real costs of your technology project can be found through the Total Cost of Ownership (TCO) of the solution your project is implementing.

TCO is an analysis meant to uncover all the lifetime costs that follow from owning a solution. As a result, TCO is sometimes called 'life cycle cost analysis.'

When evaluating the TCO, there are four main types of costs (or buckets) to consider:

1) Acquisition costs
2) Implementation costs
3) Operation costs
4) Improvement costs

The length of the TCO period depends on the expected lifetime of the solution. This can be any number of years, but typically for technology projects five years is used.

So, to estimate the TCO you calculate the cost for each bucket for each year of the chosen lifetime. In the end you add all costs up.

Acquisition Costs

Typically, this bucket will include the outright purchase of hardware and software. It is usually accounted for as a capital expense in the organization’s budget and can be depreciated over time.

There may also be a people component that should be accounted for in determining the total acquisition cost, represented by the time required to evaluate different vendors or solutions.

Additionally, acquisition cost may include the necessary pre-conditions to enable the new technology to function properly, such as new hardware to support a new software platform or the purchase of upgrades to existing hardware and software. In effect, any one-time purchase should be counted towards the acquisition cost of the technology.

With software as a service (SaaS) solutions like Salesforce or ServiceNow your acquisition costs are usually limited to the evaluation process. You will pay for the software on a monthly basis.

Implementation Costs

Once any necessary hardware or software has been acquired, it has to be set up, made operable according to its intended use, and deployed to the intended users. Costs in this category generally consist of the installation of hardware, software, and network connectivity.

Let’s take for example a Salesforce implementation. The increased use of web-based solutions might require a faster, more robust internet connection, which, depending on the organization’s office situation, could require installation costs on the part of the broadband vendor (or even a change in vendor), as well as the time cost of configuring and deploying the system.

Typically the bulk of your implementation costs come from the many people inside your company that will be key to your project’s success. Give a rough estimate of how many hours per week each of them will be involved in the research, implementation, and subsequent maintenance of your Salesforce implementation. In some cases, you may even want to hire a new staff member to oversee your implementation and maintenance.

Additionally, it’s also important to include the cost of training users on the new technology and have some sense of the impact of the change on productivity and efficiency. In almost every case, implementation of a new system causes a short-term dip in efficiency as users get used to working in the new environment. (Understanding that this dip is going to happen and planning how to help users transition through it is an important part of the change management process of a project.)

Depending on accounting interpretations, much of the implementation cost may be treated as a capital expense, and it is often the largest visible cost of a project, particularly when using external consultants to do the implementation.

Other fees to consider for a Salesforce implementation include additional licenses for your implementation partners as they’ll need their own login, a developer sandbox license for development and testing in an isolated environment, and a license for an API user. An API user will be how your third-party apps sync with Salesforce so this license needs to be separate from a user who might leave your organization at some point.

As with acquisition costs, implementation costs are generally one-time expenses, although they may fall within multiple budget years depending on project timing. Training and adoption support don’t usually qualify as capital expenses.

Operation Costs

Although often not highly visible in planning for projects, there are ongoing costs of keeping a new solution up and running in the long run, as well as scaling it to additional users. These are known as operation costs.

Operation costs include warranties, support contracts with external vendors, ongoing license costs and, occasionally, upgrade costs. The project charter must be able to forecast these recurring costs based not just on current numbers, but also on the organization’s planned future state.

For example, if Salesforce costs $25 per user per month with 3,000 current users, but the organization plans to scale it to 5,000 users in three years, the cost will also scale, which can provide an unwelcome surprise from a budgeting perspective unless it’s been planned for from the outset.

In addition to Salesforce licenses, you may need licenses for other applications. This could include a form solution, a payment processing solution, an email marketing solution, and more. After all, one of the biggest reasons people move to the Salesforce ecosystem is the ability to integrate third-party apps.

Additionally, future costs planning must take into account the staff resources necessary to meet the organization’s needs. This could include support or administrative staff for the technology, general technology support to keep up with the organization’s growth, and management capacity to keep up with the organization’s strategic planning.  This capacity may be maintained in-house or provided by external partners. Both having different impact on your TCO.

Improvement Costs

Deploying new or additional functionality or moving into a higher tier of an implemented SaaS solution with more features are typical improvement costs. Custom development and integrations with legacy systems are also very common business needs.

In my opinion you should take a certain percentage of your operation costs and budget these as improvement costs, because this is reality. Fifteen percent is a good value to start discussions.

The Real Costs of Your Project

Now that you've made estimates for each of the four bucket areas for each year of the chosen solution lifetime you can compute your project's Total Cost of Ownership.

With that, you're one step ahead in understanding the real costs of your technology project. You understand now the cost drivers for implementation as well as operation. You can compare different solutions as well as offers from different vendors and implementation partners.

You also have 50% of the information you will need for a project valuation. The other 50% of information you need are the benefits of your project which I cover in my article "What Are the Real Benefits of Your Technology Project".

In a nutshell: In order to make a good decision about starting, continuing, or ending a project you need to understand the real costs of the project. The Total Cost of Ownership (TCO) is the only metric that provides this understanding.

Read more…

What Are the Real Opportunity Costs of Your Project?

There are two ways to lose money on any given project

1) Create business value less than your actual cost.

2) Create business value less than your opportunity cost.

The first is clear to most people, and is used by most organizations to determine which projects to do and which not to do.

The second is not so clear, and unfortunately, it's ignored or misunderstood by many organizations … which is a missed opportunity by itself.

One of the biggest factors in the valuation of a project portfolio should be opportunity cost.

When you hear the term "opportunity cost" you are really hearing a fancy word for "tradeoff." Every time you make a choice, there is a tradeoff to consider. You must analyze what you are gaining as well as what you may be giving up.

Unless you have sufficient management bandwidth, technical capability, time, and money to execute every idea in your project portfolio, you will only be able to fully pursue some of the projects.

The remaining projects will either be set aside completely or, worse, be underfunded and understaffed, never getting the resources necessary to reach either success or failure.

It’s usually straightforward to understand the cost of the projects you pursue, but it is not always easy to understand the opportunity cost of the portfolio choices you make.

Value Ranges

One view of your project portfolio should be on the estimated value ranges of the included projects. To do this it is necessary that you estimate these values based on ranges and not on points (single value). One of the most straightforward and most used methods is the so-called three-point estimation.

The three-point estimation technique is used in management and information systems applications for the construction of an approximate probability distribution representing the outcome of future events, based on very limited information.

While the distribution used for the approximation might be a normal distribution, this is not always so and, for example, a triangular distribution might be used, depending on the application.

In three-point estimation, three figures are produced initially for every distribution that is required, based on prior experience or best guesses:

a = the best-case estimate
m = the most likely estimate
b = the worst-case estimate

These are then combined to yield either a full probability distribution, for later combination with distributions obtained similarly for other variables, or summary descriptors of the distribution, such as the mean, standard deviation or percentage points of the distribution.

The accuracy attributed to the results derived can be no better than the accuracy inherent in the three initial points, and there are clear dangers in using an assumed form for an underlying distribution that itself has little basis.

Based on the assumption that a double-triangular distribution governs the value of your projects, several estimates are possible. These values are used to calculate an E value for the estimate and a standard deviation (SD) as L-estimators, where:

E = (a + 4m + b) / 6
SD = (b − a) / 6

E is a weighted average which takes into account both the most optimistic and most pessimistic estimates provided. SD measures the variability or uncertainty in the estimate. In project evaluation and review techniques (PERT) the three values are used to fit a PERT distribution for Monte Carlo simulations.

When you put these in a chart it can look like below.

Each bar in the chart represents the range of value of a single project, where the range is determined by the uncertainty in the success factors of that project.

The thin white line in each bar is the most likely value. In this example, the most likely value of Project A is the largest of the portfolio projects, but more significantly, the potential upside of Project A stretches far to the right. With a well-crafted and executed plan, the actual value of Project A could be more than the combined value of projects E, F, G and H.

Each project, regardless of its significance, requires a certain amount of management attention to pursue. Managing projects E, F, G and H takes away from the attention available to manage Project A for maximum upside.

The champions for small projects may not see the opportunity cost from not redeploying their efforts to higher-growth projects. However, you can see that Project F also has a big upside; finding a way to pivot this project toward that upside can make it more valuable than Projects C or D. Set aside less significant projects — or pivot them to more growth — to reduce your portfolio’s opportunity cost and increase its overall value.

Difficulty to Realize Value

Another view on your portfolio should be on the difficulty to realize value. Difficulty is as different as costs. It is an estimation based on scarcity of skills and knowhow.

Scarcity of technical resources, such as engineering and marketing hours, affects each project’s chances of technical success, its potential value, or both.

At the top of this view by difficulty are easy projects that require less effort: Bread and Butters offer small returns and Pearls offer large returns. At the bottom are difficult projects requiring a great deal of effort that may not pay off: White Elephants offer small returns for the extra risk and Oysters offer potentially high returns.

Pursuing White Elephant projects creates opportunity cost in the form of resources that could be used to drive growth through creating and cultivating Oysters. Examine each White Elephant project to determine if it can pivot to be a high-potential Oyster; if it can’t, cancel it and redirect those resources to other projects to increase the overall upside potential of the portfolio.

Time to Realize Value

The third view you should have on your project value is time vs. estimated value. Time is another driver of opportunity cost. Cash velocity — the rate at which cash invested in business operations generates revenues and billings that replenish that cash — is relevant for your project portfolio.

Some projects require a few months to turn R&D investment back into cash-generating products or services; others may take years. A small-return project that completes quickly frees up development resources for the next project: the quick turnaround boosts cumulative returns.

Conversely, a small-return project that ties up resources for years creates the opportunity cost of preventing you from conducting several small projects in the same span of time.

Slow projects are Snails (small returns) or Tortoises (large returns); fast projects are Rabbits (small returns) or Racehorses (large returns).

Costs to Realize Value

Opportunity cost also stems from scarce financial resources. Fully funding one project over another means incurring the opportunity cost of forgoing the second project. However, fear of incurring the opportunity cost and/or sunk costs of killing some projects outright often leads to too many underfunded projects.

Because underfunding can lead to failure of projects that would otherwise succeed, this strategy often has a greater opportunity cost than committing to some projects and cancelling the rest.

The cost vs. value chart helps in allocating the budget efficiently by ranking projects by their ROI, or return-to-cost ratio. In the example, the budget is sufficient to fund projects E, O, D and C, and no other combination would yield greater total value. The vertical lines indicate that management can choose to cut the budget to just fund those four projects without losing potential value, or choose to increase the budget to capture the value from funding Project G.

Understanding the costs of your available opportunities — in difficulty, time and money — is the key to assessing the opportunity costs of your portfolio choices. You'll have a better chance of creating business value that's higher than your opportunity costs, which means higher returns and fewer losses.

When your organization needs the tools and training to understand the drivers of value in each of your projects, to find and unlock upside potential, and to make the most of your opportunities while minimizing opportunity costs, just give me a call.

In a nutshell: One of the biggest factors in the valuation of your project portfolio should be opportunity cost.

Read more…

What Is the Real Budget of Your Project?

Your real project budget should always be expressed in terms of the expected project benefits.

Simply put, project success occurs when outcomes add value to the business. The value of a project is defined by subtracting all costs from all benefits the project delivers.

Using this logic, when your expected project benefits are $3 million and your company wants a return on investment (ROI) on each invested dollar of 50%, your project budget is $2 million. In other words, project budget = project benefits / 1.5.

If the expected benefits of your project go down, your project budget should go down. It is that simple.

Many people confuse the real project budget with the authorized project budget. The authorized project budget is the total amount of authorized financial resources allocated for the particular purpose(s) of the sponsored project for a specific period of time. It is usually based on a mixture of project cost estimations, department budgets, free cash flow, and other factors.

But as soon as your costs go over the authorized project budget (which is highly likely for technology projects), or the expected benefits are not as big as planned (highly likely as well) you should ask yourself what the real budget of your project is and if you are willing to spend it or not.

How do you know whether you’re looking at the right factors when it comes to determining the real budget?

Whether or not your company can spend this money is a financing and risk question, not a budget question. You could even secure a loan to do certain projects. This increases risk and reduces ROI (because of paid interest) but can be a valid option.

Whether or not this budget is enough to realize the project is a cost estimation and risk question, not a budget question. You should never confuse your cost estimations with your budget. Budget is what you can spend, while cost estimation is what you think you will spend. Ideally, the latter is less than the former.

And whether or not your organization is willing to spend their money on this project is a prioritization question, not a budget question.

In a nutshell: Always express your project budget in terms of expected benefits delivered and you’ll have a better idea of the real budget of your project.

Read more…