Most information technology (IT) project management literature focuses on managing software acquisition projects. This article is different because it describes how to plan a business case development project – how to do the “due diligence” before deciding if and how to acquire a new system. The insights in this article should be a valuable resource to project managers, planners, sponsors, and stakeholders. After completing the activities described in this article, stakeholders and decision-makers will have enough information to know:
- The solution scope and the high-level nonfunctional and functional requirements for the system. In the Agile development world, this consists of summary level user stories, or “epics”.
- What the cost and benefits of the potential solutions are and if they justify continuing on with system acquisition.
- If there are existing, off the shelf products (commercial and open source) that can meet at least 80% of the mandatory requirements.
- If a custom developed system is a better option than an off the shelf solution from a cost and risk perspective.
The article assumes that your organization has a functioning IT governance process for reviewing and approving business cases and for authorizing software acquisition projects. Readers should consult their organization’s Project Management Office (PMO) or, if one doesn’t exist, their Chief Information Officer (CIO).
IT Product Life Cycle Summarized
If your organization has a formalized IT product life cycle, business case development will be the first project activity in the life cycle. As developing a business case is, in itself, a project, the business case development project is the first project activity within the life cycle.
The diagram in Figure 1 below shows a generalized IT product life cycle based loosely on the Enterprise Unified Process.
Kicking off the life cycle in the “initiate” phase is the recognition of a business problem or opportunity. This recognition usually comes from the business stakeholders and not IT personnel. If, however, technical obsolescence (described below) is threatening existing system’s viability, then IT personnel may inform management that something needs to be done to address the situation. Whatever the case, this results in a needs statement laying out the problem.
There is a decision point, represented by an arrow, between the initiate and elaborate phases, where management reviews the needs statement and authorizes the start of a business case analysis project. Each organization has its own process for reviewing and approving these kinds of projects. It could involve a decision at the business line level or, depending upon the potential impact the need has on the organization, at a much higher level. It really doesn’t matter which management level makes the decision, the outcome is to move to the elaborate phase by authorizing a business case development project to formally analyze, contrast and compare competing strategies for meeting the need.
Sometimes the need is (or perceived to be) so pressing that the approval authority (an executive or a committee) decides to immediately start system acquisition. In these kinds of situations, the need to put a system in place as soon as possible to meet the need overrides most other considerations (like cost and risk). This may be the only choice when facing an existential threat and it does save time and cost, bypassing business case preparation and analysis.
This a legitimate business decision, but it may not be the best way to go when timing is not so critical because the elaboration phase can consume considerable time depending upon the scope and complexity of the requirements. For example, if the goal is to replace an aging technologically obsolete system, then requirements and business case information produced by an earlier system acquisition effort should be available. All the business case development team has to do is review and revalidate the requirements and make any updates.
About Business Case Development Projects
The ultimate products of a business case development project are a validated and refined business case and a project team recommended alternative acquisition strategy (or “alternative”). The recommendation should be based on an unbiased examination and evaluation of the information gathered by the project team. As the review authority makes the formal decision, they can choose to ignore the project team’s recommendation and select a different alternative.
Like all projects, the business case development project has a:
- Project charter
- Project sponsor and project manager
- A review authority consisting of an individual or committee empowered to approve the recommendation and significant scope changes and move the life cycle to the acquire phase
- Budget and resources
- Project plan
Following the pattern described above, a well planned and executed investigation project should take no more than 6-9 months from project start to finish. The diagram in Figure 2 below shows the major activities in this kind of project. Later sections describe these activities in greater detail.
The project team comes together and finalizes the project plan using a combination of advice in this article, their organization’s project management process, and other sources of information or direction. Having the team work on the plan together increases buy-in and team ownership. The project team also locates and reviews earlier requirements analysis work to assess the effort for defining requirements. Once completing the project plan, the project team, with the project manager as the lead, walks the sponsor through the plan. The project begins only after the sponsor formally approves the project plan.
Business analysts work with business experts (or subject matter experts – SMEs) to define and prioritize system requirements. This may be a more cursory effort if the project team is reviewing existing requirements for replacing an existing system or more involved if the business need is novel.
The project team reviews the requirements with the approval authority, who may approve the requirements as-is or request changes in the requirements before approving them.
Business analysts review the market and find off the shelf products (commercial and open source) that could meet a majority (usually 80%) of the mandatory, or “must have” requirements. In addition, the team identifies developer organizations having the technical capability to develop a custom solution. Developer organizations may be in-house or may be existing contractors. The team may issue a Request for Information (RFI) to obtain more detailed product and non-binding cost information.
Cost Benefit Analysis
After discarding unviable alternative solutions, the team uses the information obtained through research and develops a four-year (or longer if required by the acquiring organization) total cost life cost estimate for the selected off the shelf and open source alternatives. In addition, the team obtains estimates for developing a custom system (but does not use the developers identified earlier to produce the estimates).
The project team prepares a recommendation to the approval authority.
The project manager and lead business analysts (and other team members as needed or directed) meet with the review authority and walk through the alternatives, the cost benefit analyses and the recommendation report. The review authority makes the decision to accept the project team’s recommendation or to selects a different alternative.
The project team revises the recommendation in response to approval authority requests for changes and to reflect the alternative selected if different from the original recommendation.
As with any other project, the project team identifies lessons learned from the project and writes an “after-action” report describing what went well, what didn’t, and suggestions for future teams working on similar projects. The project team also ensures that all documentation generated by the project are properly archived and available as needed.
This section discusses things to consider when planning a business case development project during the project planning phase.
Learn from Earlier Projects
One of the first steps in planning a business case project is to locate and review historical documentation and lessons learned from earlier business case development projects. Apply relevant lessons learned to the project plan to avoid risks identified by earlier project teams. Consider creating a list of risks using the lessons learned and, for each risk, a short description of how the project plan avoids or accepts and mitigates the risk.
If the goal is a technology “refresh” – to replace a technologically obsolescent system with a new system, then locate any requirements and test documentation used to acquire and maintain the legacy system. Review and evaluate the requirements for completeness. If there are “gaps” in the documentation, include effort in the project plan for business analysts to fill them in. Having a complete set of requirements and test documentation means the project team can reuse this information, reducing overall project time and cost.
However, if the business need is novel, the project team should plan for more business analysis work to define the solution scope for the new system. The team can do this by developing a system “vision” describing the goal of the system and listing high-level system features. There should be enough detail in the vision for the project team and review authority (and other stakeholders) to discern the solution scope. Also consider adding a solution scope review and approval checkpoint into the project plan. This gives the review authority the opportunity to verify that the project team is on the right track. Without this checkpoint, the team risks basing its analysis on the wrong solution.
As soon as the team complete the project plan, meet with the review authority and walk through the plan with them. Be prepared to make adjustments to the project plan if the approval authority insist on changes. Have the authority formally approve the project plan before actually starting the project, especially if there were significant changes made to the plan at the sponsor’s direction.
Requirements – Defining the “What”
There are many tools, methods, and techniques for gathering (or “eliciting”) and documenting requirements. The team should build the project plan around the tools and techniques which they have had the most success. Whatever method the team uses, keep these points in mind when planning requirements definition activities:
- Identify stakeholder subject matter experts (SMEs) and make them part of the project team. SMEs are most familiar with the business processes affected by the future system (they are often the end users of it). If senior staff are used as SMEs, particularly if they are supervisors and managers, make sure they understand their role in the project. It’s not unheard of for senior level SMEs to challenge the project manager and to exert undue influence on the project. There is no easy way to deal with the damage this can cause to a project.
- Let the SMEs prioritize the functional requirements into must have (mandatory), should have (material), could have (discretionary), and won’t (out of scope) levels. Use the solution scope to determine if a requirement is out of scope or not. If the SMEs insist on including an out of scope requirement (as determined by the business analyst), document the difference in opinion and review it at the next possible project sponsor meeting. Making out of scope requirements in scope should require project sponsor approval. SMEs and project managers should not have authority to change project scope.
- Get as much SME involvement in the requirements process as possible. Be careful and make sure that business analysts guide the SMEs through the requirements process, but do not dictate to them what the requirements should be. Some technical requirements may not be optional and the SMEs may disagree with them. It is the project team’s responsibility to demonstrate to the SMEs why these kinds of requirements are necessary.
- If the solution will serve multiple organizations, make sure SMEs represent a good cross-section of those organizations for a broader perspective. Keep the group manageable by having no more than 5 SMEs. Often, business processes perceived as unique to one organization turn out to be common across many or all organizations. Differences in terminology and organizational structure mask business process commonalties. Sometimes getting SMEs to agree on a common vocabulary is half the battle.
- Build time into the project plan for SME requirement discovery sessions and reviews of evolving requirements. Use facilitated meetings for the SME discovery sessions with the goal of having documented requirements as the outcome of the sessions. Leverage web collaboration tools to reduce travel expenses, but consider holding a face-to-face meeting with the SME group to launch the effort if members are geographically dispersed.
- Give serious consideration to including business IT specialists (not those working in central IT departments) on the requirements team. They often have a clear understanding of the business and can help the SMEs translate their requirements into technical terms. Also, since it’s likely these individuals will operate and maintain the eventual system, it helps them understand the context and encourages buy-in.
Use these rules of thumb to gauge if the team has defined all the pertinent requirements:
- SMEs cannot identify any more new mandatory requirements and start repeating them.
- Stakeholders have reviewed requirements with no substantive changes made after the third review.
Putting together and documenting a good set of requirements takes time and a lot of effort, but it pays off because it is a useful too throughout the life of the system – and beyond. As I mentioned above, future project teams can use your team’s work to speed their work (instead of starting “from scratch”). After the new system becomes technologically obsolete (all systems eventually do), it’s easier to update and revalidate the requirements than to start a new requirements definition effort.
Approving the Requirements
As the representative of the end users, the project sponsor should certify that the requirements are complete and accurate. The project sponsor may want to circulate the requirements to a wider audience, such as a project steering committee or other oversight and user groups before giving their approval. This will take time, so discuss this with the project sponsor during project planning to accommodate the desired level of review in the project schedule.
Baseline Cost Estimate
The baseline cost estimate serves for comparing the cost of the different viable alternatives identified by the project team. It is an estimate for developing a custom system meeting all of the “must have” business and technical requirements identified earlier in the project. While the business requirements define the solution scope, the technical requirements place constraints on the solution. This is necessary to ensure that the system, if it were developed, is compatible with its operational environment.
Cost estimates are only as good as the precision level of the requirements – the more precision in the requirements, the more certainty in the cost estimate. Low precision requirements usually result in highly uncertain cost estimates having a broad range between low and high estimated cost. The trick is to select the correct precision level so that the project team does not get bogged-down in analysis (“analysis paralysis”) or end up defining nebulous requirements that any piece of software can meet. If there is disagreement between the stakeholders about certain requirements, bring the precision level for the requirements in question to a lower level. Project managers should not hesitate to do this.
There are several options for producing the baseline cost estimate:
Use in-house expertise – If your organization has a Project Management Office (PMO), they may have in-house expertise and access to tools for generating development cost estimates. The PMO can also compare the requirements to those of existing IT systems that could meet the requirements with some modification. It may be possible to extend an existing system in operations and maintenance and reduce overall costs for both sets of stakeholders. (This should be included in the market research.) Also consider asking in-house developers to review the requirements and create an estimate. This is something the PMO can help with. However, if your organization does not have a PMO or a catalog of systems in use across the enterprise, then the project team will have to do this work on its own.
Use an expert to review the requirements and develop the baseline estimate – There are many companies specializing in software estimation. Consider using one of them to review the requirements and generate the baseline estimate.
Release the requirements for comments – If you are working for a government agency, you can release the requirements as part of a Request for Information (RFI) and ask for cost estimates. They may not be a very productive way to go, however, because it depends upon potential respondents having the time to analyze the requirements and create the estimate.
Whichever method chosen for obtaining the baseline cost estimate, be sure to include the time (and any cost) for obtaining the baseline cost estimate in the business case development project plan.
The purpose of the alternatives analysis is to compare at least three strategies (alternatives) for satisfying the approved requirements developed earlier. By following the advice in this article, your project team will have two alternatives to evaluate at the outset:
Business as usual – This is the “default” alternative – do nothing and continue using the current system. If there isn’t a system in use that can support the requirements, are there adjustments your organization can make that still get it to where it needs to go without new system acquisition?
Custom software development – This is covered in the baseline cost estimate – develop a custom software system for satisfying the requirements.
Other strategies – include:
- Gaining access to a production system that meets the requirements without modification. This is the best case (and usually least likely) alternative.
- Reconfigure an existing system to meet efficiency and performance (non-functional, but technical) requirements. This alternative works best as long as the reconfigured system does not use obsolescent or soon to be obsolescent technology.
- Add new capabilities to an existing production system to meet the requirements. Similar to the previous alternative, the obsolescence issue applies.
- Expand the scope of another “in-flight” system acquisition project to include the requirements. The resulting system would support two business cases. One down-side to this strategy is figuring out how to combine governance if the “in-flight” system is sponsored by a different group within the organization.
- Purchase a commercial off the shelf (COTS) product and configure and/or modify it to meet at least 80% of the “must have” requirements.
- Similar to off the shelf acquisition, acquire an open source solution. However, if there is a cost to acquire and maintain the open source license, then this is the same as a COTS acquisition.
Market research helps the project team determine if the approved requirements are so unique that they cannot be satisfied by a COTS product. It’s not unheard of for stakeholders to think their requirements are unique in the human experience only to find a COTS product that, with a little imagination, could meet, and sometimes exceed, the requirements. Sometimes it’s a matter of casting a wider net and looking at what other organizations are doing in related problem domains. Market research also helps the project team reevaluate the requirements and help guard against “gold plating”, which is another way for promoting “could have” priority requirements to “must have”.
Many information sources are readily available for conducting market research, as described below:
Vendor and Industry Contacts can be excellent sources of information, especially if their members are facing similar issues as yours. Talking to a number of companies is one of the best ways to get useful information. Attending trade shows gives access to the vendor community and can help identify vendors who can give needed information. Be sure to avoid conflict of interest issues when dealing with vendors. Published materials, such as trade journals, research publications, technical forecasts, business environment publications, and the web are also potentially useful sources of information.
If your organization has a contract in place, consider starting an engagement with a technical market research firm. Other organizations similar to yours, even competitors, may face similar problems and may be willing to share their experience with the research firm. The research firm may find that another organization in the same or allied industry has already implemented a similar system and can give technical and cost insights.
Teams can invite vendors in for demonstrations of their products. Make sure, especially if your organization is a government agency, that the vendors understand that the team is doing market research and not in procurement mode.
Another aspect to consider is the relative risk to your organization inherent in each alternative approach. In this context, risk is probability of a negative impact on the development project. Higher risk projects are more likely to finish late, exceed their budget, and deploy products not meeting user expectations (not to mention outright failure where the project delivers nothing). Building a new system using in-house resources is an attractive alternative, but, depending on the requirements, the probability of failure could be very high. There may be good reasons for in-house development, such as staff retention and information security considerations, but the cost combined with the risk could be prohibitive. Table 1 briefly describes these relative risks for different acquisition strategies.
Table 1 – Acquisition Strategy and Relative Risk
Use a production system
None, especially if the system works as-is, to low if the system needs some modification.
COTS Purchase, Open Source
Low – medium Development costs spread across the COTS vendor’s customer base. Stress software configuration, not customization (or coding).
Build with contractor resources
Medium – Classic software development risks; some risk mitigated by deflecting it to the contractor (depending on the contract type).
Build with in-house resources
High – Classic software development risks – all assumed by the Federal Reserve.
Some alternatives may become more attractive after considering these risks. Select the most promising alternatives for the cost benefit analysis.
Revise and Select Alternatives
Revise and refine each alternative using the market research information (and the RFI, if done). Earlier assumptions about some of the alternatives may prove false in light of the new information and some alternatives may look stronger after further consideration. “Weed out” the weak alternatives and document the reasons for removing them from further consideration.
The Cost Benefit Analysis
The cost benefit analysis (CBA) compares the cost, benefits, and risks of the viable alternatives. All cost benefit analysis should include the custom developed with in-house resources alternative because it is the initial cost estimate for the new system and forms one of the baselines for comparison (see above). The other baseline for comparison is business as usual – if it exists. For example, if the system will support new business goals, then there is no business as usual and no need to include these costs in the CBA.
The CBA will:
- Help find the best value alternative (the one with the optimal mix of cost, benefit and risk).
- Depending on the best value alternative, help decide if procurement activities are needed.
- Help revalidate the business case.
- Yield a refined lifecycle cost estimate to update the funding request and any plans.
Best value is not synonymous with lowest cost. Your organization may save money “up front” selecting the least costly alternative, but end up paying more for it later if the system fails to satisfy user expectations because of missing requirements, poor usability, and poor quality.
The cost benefit analysis is easier if there are clear, unambiguous and complete requirements for the new system and, for business as usual, well documented procedures. Also helpful is cost data for production systems slated for replacement by the new system. The more complete and accurate the requirements and cost data, the better the estimates and the more trustworthy the analysis.
Follow these steps for completing the CBA:
- If applicable, estimate the cost of business as usual.
- Estimate the cost of each selected (viable) alternative.
- Estimate the quantitative benefits of each alternative
- If possible, estimate the qualitative benefits of each alternative and their relative risk.
- Select the best value alternative (which may have a procurement component).
CBA cost estimates should use the current value of money and project the costs out four years beginning with the anticipated start of the development project. For example, if the plan is to start development in 2019, estimates should start in year 2019 using 2019 dollars for all four years in the cost projection (2019 through 2022). Similarly, full-time equivalent personnel (FTE) estimates would start in 2019 and extend through 2022. Table 2 – Template for Reporting Quantitative Cost, Benefit and Business as Usual Estimates – shows an example spreadsheet for reporting quantitative cost and benefit estimates for each selected alternative (i.e., a separate table per alternative included in the analysis). You may need to change (or add to) the cost categories shown in the table to correspond to those used by your organization. (You can download a Microsoft Excel workbook containing this table as a spreadsheet from here.)
Table 2 – Template for Reporting
Business as Usual Cost Estimate
When business as usual processes exist (which may not be the case for a new business need), the analysis team will often find a mixture of automated and manual processes. If the scope of the system under consideration extends across several organizations, the team may find several systems supporting the same basic processes. Stakeholders from the different organizations may insist that their processes are different from the other organizations. The challenge for the team is to define those differences, and, if there are not any, document that fact.
There are several ways to estimate business as usual costs:
- Use operating cost data obtained from the business responsible for the process. Costs should include the costs for operating and maintaining any automated systems supporting the business process. This is the most accurate method of estimating business as usual costs.
- Use surveys to collect costs estimate from the business area. Make sure that the surveys are easy to understand and follow-up to ensure a high response rate. Poorly written surveys are open to interpretation, so ask specific questions in the survey. Don’t forget to add time to the project schedule for distributing the survey, receiving responses, and collating results.
- Extrapolate the cost from the requirements definition process. This is usually the least accurate estimation method.
- Use documentation from earlier projects and revalidate the work. Sometimes, revising the cost estimates to reflect inflation may be all that is necessary if processes have not significantly changed. (This is why maintaining the documentation of a production system is so important.)
- Use work measurement data from time and expense tracking systems.
- Use case analysis techniques can identify workflows and cost impacts. This is the most time consuming option, but may be the only choice if documentation is incomplete or nonexistent.
Business as Usual Benefits
Any benefits gained from systems supporting business as usual are offsets to the cost of using the system, so there is no reason to collect and report business as usual benefits. If several systems are supporting business as usual, chances are that one will be more efficient than the others. Consider treating the more efficient system (if it is not technically obsolete) as an alternative in the analysis, but include the costs of the systems in the analysis.
Estimate the Cost of Each Alternative
Using cost data obtained through market research, the initial cost estimate, the request for information, and other techniques (be sure to document these), estimate the cost of the each alternative over the same four-year horizon as the business as usual estimate (if there is one) using the same cost categories use a copy of the template in table 2 for each alternative. Do not capitalize or amortize costs as it will distort the analysis. Costs to consider include (and these are laid-out in the template in Figure 2):
Personnel – estimate the number of personnel employed by your organization needed to acquire the system and to operate and maintain the system. Express this in full time equivalents (as shown in Table 2). If you need a cost figure, consult with your PMO or budgeting group for the annual cost per FTE your organization uses.
Material/supplies consumed during development and through operations and maintenance
Equipment, such as server hardware, storage, networking and heating, ventilation and air-conditioning equipment.
Software, which includes software licenses (purchase and ongoing maintenance fees) and contractor cost for developing and maintaining software.
Communications equipment purchases and maintenance.
Cybersecurity – costs for validating, verifying, and monitoring the security of the system. Some of these costs may be split across cybersecurity consultant charges and security software licenses (which may also be wrapped into hosting charges).
Other, or other expenditures not categorized here. If necessary, add categories to the table to provide a more thorough view.
With “cloud hosting”, some of the capital costs may, instead, be replaced by hosting charges. For example, a portion of materials/supplies, some licensing fees and communications charges, and mostly all environmental conditioning and data communications equipment charges are often built into the fees charged by the hosting provider. Since your organization is effectively “renting” capacity from the cloud hosting provider, these are no longer capital costs. Consider adding a new cost line for hosting charges to the table in Figure 2.
There may be other non-recurring costs not broken-out on Table 2, but should be considered for each alternative. These include costs for system installation and deployment, such as:
- Training users and system support personnel
- Converting data from existing repositories to the alternative
- If there are any, decommissioning the legacy systems
- Purging duplicate or obsolete software, databases and files;
- Future software licensing fees for existing systems that will fall into disuse
Some costs may not change much between alternatives. For example, the cost of converting data to a new system is often difficult to estimate. It may make sense to use the same estimate for several alternatives.
Estimate the Benefits of Each Alternative
In many organizations, the preferred benefit is budgetary savings because projected reductions in full time equivalent (FTE) personnel do not equate to workforce reductions. Presumably, more effective and efficient work processes free-up FTE so they can work on more value-added activities. In some situations, personnel costs could increase, such as reducing the number of data entry clerks and hiring more professional engineers to do the higher value work. This can become speculative, so use this kind of “workforce replacement” carefully. The assumption is that a new system will pay for itself over time by generating savings offsetting the acquisition, deployment, and operations/maintenance costs.
While this may be true for new systems that reduce the cost of business by supporting more efficient processes, it’s a bit different when the new system may be in response to a mandated change. For example, new federal regulations having novel reporting requirements (like Sarbanes-Oxley did back in the 2000’s) add regulatory burden. In this scenario, FTE may increase to accommodate the new regulatory reporting requirements. The cost to benefit ratio looks ugly because only the costs are quantifiable while the benefit – to be in compliance – may have no quantifiable value.
There are situations where it is difficult to impossible to reliably translate benefits into reductions in future budgetary outlays. Consider an improved business process that eliminates several manual, error-prone steps. A single iteration of the process may show a fractional savings like an hour here and a half-hour there. Savings grow in greater significance every time the process repeats. The problem is in estimating how many times the process repeats in a future work scenario and defending the assumptions used in the estimate. If you use estimates like this in the analysis, be sure to explain the assumptions and rational behind them.
Benefits can also come from future costs avoided or reduced when comparing marginal costs and marginal benefits. Examples include initiatives that will reduce or eliminate future budget requests to meet workload growth or result in decreases in equipment or software maintenance costs. Use well-founded and defensible estimates if cost avoidance is the main basis for showing a favorable cost-benefit ratio. Estimates of cost reduction are easier to track and tend to be more accurate than projected cost avoidance.
Another source of quantifiable benefits is the cost of maintaining hardware, software, and operations of an obsolete system the new system will replace. With the prevalence of cloud based hosting, these costs are becoming almost negligible, but could be offset by other costs, such as cybersecurity verification and validation. In addition, if the cloud hosting provider is a different organization, these costs are not capitalized since you organization will be effectively “renting” (and not buying) the infrastructure.
Additional benefits can accrue if the new system will replace several obsolete systems. Personnel savings, beyond those for managing the hardware and software, are less dramatic and more difficult to estimate. Lastly, don’t be too surprised if some alternatives have the same quantitive benefits.
Estimating Qualitative Benefits
Rather than attempting to estimate the monetary value to benefits that are difficult to quantify, consider using a ranking scale. The simplest scale is based on a traffic light red – yellow – green. Red would represent a high risk or undesirable characteristic, yellow for proceeding with caution, and green for no perceived risks. For finer comparisons, use a one to five scale where one is least desirable, three is neutral, and five is enhanced potential capability. Using more than a five-point scale is counterproductive because it gives a perception of precision (after all, we are dealing with qualitative measures). Examples of qualitative benefits include:
Flexibility – How easily does the alternative accommodate differences in work processes between groups of users (such as differences between regional offices)?
Expandability – How easily does the alternative accommodate growth in the number of users and volume of data?
Security – How well does the alternative meet your organizations information security requirements?
Risk – Is there a low, medium, or high risk of failure in acquiring the system?
There may be other qualitative factors important to your organization and the analysis team not covered in this short list. Be sure to include them in your analysis.
An example of a qualitative comparison between three alternatives appears in Table 3 below. This table uses a scale of 5.
Table 3 – Example Qualitative Benefits Comparison Table
Business as Usual
When ranking qualitative risks, assign the least points to the highest risks, adding points as the risk approaches no risk. Thus, a high risk would receive 1 point and a no risk 5 points.
One way to graphically show qualitative benefits comparison is to use “radar” charts. The figure below shows three radar charts, one for each alternative, based on the scoring in the qualitative benefits comparison table above.
Radar charts are a great way to show the differences between each alternative. The way the chart works is the greater the coverage, the better the overall qualitative benefits. Reviewing the charts for the three alternatives shows that buying a COTS product has the greatest coverage and is the alternative having the best combination of qualitative benefits. Executives like radar charts and I’ve used them successfully for several business case reviews.
Estimate the Risks Associated with Each Alternative
A risk has two components – probability of occurrence and impact. The team should review the viable alternatives and identify all significant risks for each. Some alternatives are inherently less risky than others (as shown in Table 1 – Acquisition Strategy). The team should, if possible, identify quantifiable risks and factor them into the estimates for each alternative.
Quantifiable risks are those risks (usually they are certain events) that, for good or bad, affect cost. Let’s say the team identifies a risk for a certain alternative having a 50% probability of occurrence with an estimated impact of $500,000. The adjustment for this particular risk to the estimate is .50 X $500,000 = $250,000. If there are more than one risks, than the total risk adjustment is the sum of all of the probability X impact of the quantifiable risks for the alternative.
Occasionally the team may find a risk that has a negative impact. In other words, the risk adjustment reduces the cost. These kinds of risks (opportunities, really) are often overlooked. For example, I worked one project where we identified an off the shelf component that, if used, would reduce the duration of a software development project by over a year, saving approximately $3,600,000. At the last minute, the contractor project manager decided not to use the component, meaning the customer organization (my employer) would foot the bill for developing features “from scratch” that could have been bought “over the counter”. Surprisingly, the project sponsor accepted the contractor’s decision! (I would have liked to have been a participant in the meeting where this was discussed and approved.)
Coming up with the risk probabilities and impacts for several software acquisition approaches can be time consuming and open the analysis up to questions on the risk assumptions. The easiest way to determine a risk factor is to review the outcome of earlier projects and extrapolate a risk multiplier. There are other techniques, such as Monte Carlo analysis, for generating risk multipliers, but your project team will likely need assistance for this. Outside consultants can run Monte Carlo simulations and use models to generate risk based estimates based on the requirements (and solution scope) the project team defined earlier. If counting on this type of expertise, include time in the project plan to acquire their services. As discussed earlier, your organization (especially the central IT group) may have these kinds of experts on retainer, so check with them first before trying to procure this service or do it yourself.
A Word About Adjusting for Risk
Some organizations understand risk adjustments and others (probably most, but I’m a bit of a cynic) don’t. We are, after all, dealing with estimates. But numbers can take on a meaning of their own. Beware of situations where management questions the risk factors. It’s OK to discuss them, but, if you can, make your decision-makers aware of what they are doing. Removing a risk reserve in its entirety is a recipe for cost overruns, especially for custom software development software. I remember one executive telling my project team that he was OK if we came back and asked for money once, but that we could not do it again – just after removing the risk reserve from the project budget!
As we all know, a dollar today isn’t worth as much as it was five years ago because of inflation, which must be factored into the cost benefit analysis. Total costs and benefits for each year are expressed in the detailed table in terms of present value, a technique for factoring inflation into the estimates. While there is no “crystal ball” for predicting inflation four years out, make sure you use a reasonable inflation rate. You can look at historical Consumer Price Index (CPI) figures for past years from the Depart of Labor’s Bureau of Labor Statistics web site. While past performance is not indicative of the future, you can use the CPI from earlier years (say the previous four years) and create your own estimate. Or better yet, check with your organization’s Chief Financial Officer for organization standard inflation rates.
Select the Best Value Alternative
This stage of the project is where the project team selects the best value alternative to recommend to the approval authority. Using the summary cost/benefit table (shown in Table 4 above), calculate the net present value (NPV) of each alternative by subtracting the present value costs from the present value benefits. A negative NPV indicates the alternative will not generate cost savings while those with a positive NPV are more likely to offset their cost with the benefits they generate.
Another measure is the benefit-cost ratio calculated by dividing the present value benefits by the present value cost. Generally, the higher the benefit-cost ration, the sooner the “break even” point where the alternative begins to generate savings offsetting its cost. Conversely, an alternative having a benefit-cost ration less than one will not generate enough (or any) savings to offset its cost. If none of the alternatives offer a positive benefit cost ratio, then the business case for the system is questionable unless there are legal implications (the Sarbanes-Oxley example above, for example).
Table 4 below summarizes information from Table 2 and shows the risk adjustment and benefit cost ratio. This table is also included in the Microsoft Excel workbook with Table 2 available here.
Using only the benefit-cost ratio is a bit short-sighted; the team should consider the following before selecting an alternative for recommendation:
- Qualitative factors may offset some cost
- If a new law or rule mandates the business case, recommend the alternative with the highest benefit-cost ration and qualitative factors.
- If the organization is concerned about cashflow and profit/loss, use other methods such as payback and discounted payback period, net present value, and internal rate of return. Most of my work has been on federal government business cases, so this kind of analysis wasn’t needed.
This is the last activity of the project where the team meets with the approval authority and:
- Reviews the solution scope
- Describes the alternatives selected for the analysis
- Describes the alternatives not selected for the analysis and why they were not included
- Summarizes the cost benefit analysis
- Presents the team’s recommendation and the rational for it
The project sponsor doesn’t have to accept the team’s recommendation and could select a different alternative. In any case, the next steps depend upon your organizations investment review process. For example, the project sponsor may have the authority to approve an alternative and direct expenditures up to a certain amount. Beyond that amount, an investment review board may make the decision. Ultimately, it is the purchasing organization’s management and executives to select the alternative making the most sense to them and not the project team’s.
As I mentioned earlier in this article, building upon the work of earlier projects can really reduce the time and effort needed to complete the business case. It’s always faster reusing and updating earlier work than starting over from the beginning. That’s why it’s important to keep good project files and to make the files “findable”. Some of the newer content management systems may help with this, but finding relevant information can be a hassle if these content management systems are improperly designed.
In this article I laid-out a process for planning and executing a business case development project. The goal of this kind of project is to provide information to executives and managers so they can make an informed investment decision. Along the way, the project team documents their work and creates a project file containing all of the pertinent information and decisions made during the project.
Don’t lose sight of the fact that the cost/benefit analysis is just an estimate – and, like most estimates, they have expiration dates. Major changes in the business environment or in available technology may make it necessary to “rethink” an alternative or tweak a risk or two. It’s OK update and refresh the cost benefit analysis (maybe even changing alternatives) to reflect these changes.
Another thing to keep in mind is that most IT professionals I’ve known have never done this kind of work – and many of them, if given the opportunity, would pass. There are, however, people that do this for a living. Seriously consider getting outside help – especially business and financial analysis help – for your business case analysis projects.