8 Clear-Cut Steps to Building the Business Case for Enterprise Agile Software

Building a business case in an Agile environment might seem like a difficult endeavor. And while it can be challenging, there are tools and methods that simplify the process and make it far more manageable.

When Forbes interviewed 500 international senior executives last July, they found one striking Agile statistic: Almost every single respondent—92%—agreed that “organizational Agility” is “critical to business success.” (We’ve got a free business case for software that will help you with just that.)

Another statistic? Enterprise Agile software radically helps with organizational agility. For example, a study out of Capterra shows that users see improvements in team communication, final product quality, and the number of projects completed within budget with the implementation of similar tools.

Scaled Agile Framework tools have the opportunity to supercharge large businesses’ productivity, product outcomes, and bottom line. They’re meant to be used with SAFe—or the Scaled Agile Framework—which is a system designed to bring iterative improvement to everyone, from the recent college hire to the C-suite. A number of other end-to-end business agility practices, like Nexus or LeSS, provide a similar system.

That said, building the business case for software to enable Agile cross-functional teams is not easy. In recognition of the work that goes into building this business justification, we’ll equip you with insights into how to:

  • Assess the business’s greatest priorities—and how to tailor your business case to those needs.
  • Verify whether or not your company is really ready for an enterprise-grade tool.
  • Evaluate the path for tool adoption.
  • Screen existing software for features that enable both strategic planning and fast, high-quality execution.
  • Find the numbers you need.
  • Analyze benefits and risks without hyperbole or minimization.
  • Propose a realistic change management plan and outline a corresponding timeline.
  • Distill your business case to a one-page proposal and corresponding half-hour presentation (both business case template and business case presentation are available for download).

If you’re itching to skip ahead, feel free to use the table of contents above to match where you are in your business case for software.

1. Assess your business’s greatest priorities before making your business case for software

As with many enterprise businesses, you should have a feel for what the C-suite is pushing hardest for in their annual goals. If you don’t, consider asking your leadership (or someone who reports to leadership with insight) the following questions:

  • If you were to choose the most important qualitative and quantitative goals for our company this year, what would they be?
  • What is your definition of a successful SAFe transformation? What metrics will you be looking for?
  • If you could snap your fingers and fix one thing about our business operations, what would it be?

You’ll probably get an answer that stems from one of the following:

Business priorities
As a note, this doesn’t include some values that are better left to qualitative metrics, like innovation, regularity, and quality.

Naturally, enterprise Agile software touches on a good number of these variables both directly (operational efficiency) and indirectly (financial stability). As much as you can, align your stakeholders’ goals with measurable outputs from your proposed enterprise Agile solution.

In the end, your business priority alignment diagram should look something like this (these are all included in the Enterprise Agile Software Business Case Template Free Download).

Business Case for Enterprise Agile Tools Business Alignment

Your stakeholders’ priorities create the scaffolding for your business case for software; if your reasoning for purchasing software deviates from these priorities, your ability to convince your leadership of investing in something that’s not a business priority will become incredibly difficult. Be sure to complete this step before moving on to the next.

2. Verify that your business needs an enterprise-grade Agile tool.

As many businesses grow, different software teams tend to identify tools and processes that work specifically for them. Unfortunately, if you want these teams to work smoothly as an individual unit and across the company, there’s a limit to how individual toolsets can sync.

For example, it’s not uncommon for some teams to start off with only free tools; I’ve certainly worked in environments based on a mishmash of Google calendar, Slack, Taiga.io, Codebrag, Git, Atom, Eclipse, and Jenkins—all free, yes, but all limited in communication. Anyone developer would have to access a multitude of tools to get insight into what the team was working on.

Another common problem is that the team uses a nicely integrated tool that’s outdated. Because it was tough to learn and expensive to boot, there’s fear that the sunk costs aren’t worth the change management involved in implementing a new tool.

That’s not an unreasonable fear! What would be unreasonable, however, would be adhering to that fear without considering what other opportunities might be available.

3. Evaluate the path for enterprise Agile software adoption

Designing and optimizing your adoption strategy will require significant creative thinking—it is the least pattern-based part of developing your business case for enterprise Agile software and the most critical factor to decision makers.

Bear in mind: a majority of business leaders do not believe change management is possible—a belief founded in an enduring disproven estimate from 1993.

There are three common pitfalls of adopting a new Agile tool. These are serious considerations, especially when advocating to executives who are time- and process-conscious.

  1. Your infrastructure isn’t ready. Unless you’re stuck in 2015, you’ll probably want a SaaS instead of an on-premise solution (they’re significantly more secure and often cheaper than on-premise software, even in the long term). That said, even SaaS tools have certain system requirements. For example, Targetprocess requires one of the latest two versions of Chrome, Firefox, Safari, or Microsoft Edge to run correctly. Be sure you have enough internet bandwidth to prevent the software from slowing down, and build redundancies so that you don’t run the risk of losing access to your Agile tool.
  2. You haven’t considered change that’s already happening in your company. Plot where you are in your Agile transformation. Business agility is such a new concept that most enterprises (with few exceptions like Spotify or certain divisions of ING) are not yet fully “Agile.” Whether you’re in the midst of launching the Agile Release Train or just forming your Nexus Integration Team, the introduction of cross-functional Agile software will undoubtedly bring more change to a company already in transition.
  3. Not all teams were considered when making an impact analysis. Detail how the software implementation will affect individual teams. If moving from Jira to Targetprocess to save money, for example, your programmers will be able to quickly make the switch. However, if you’ve been running your software teams off of ad-hoc tools like Slack, you may need to provide some required training. How much time will that cost your teams?

To avoid these problems when gathering information for your change management process, be sure that you have thoroughly completed the adoption pathway assessment. Below we’ve created a checklist of common questions to investigate during this stage:

  • What individual beliefs conflict with adopting an enterprise Agile tool? Sample answer from a developer: I like using [current tool] and I don’t particularly want to change.
  • What team-level beliefs conflict with adopting an enterprise Agile tool? Sample answer from a product owner: Learning SAFe is hard enough. Can’t we finish learning that system before adding more complexity?
  • Who is available to teach the desired tool to our development teams? Sample answer from the CFO: It would be cheaper for the provider to provide a four-hour training session.
  • Is the provider well-equipped to help with software implementation? Sample answer from you: The provider has a template that it has used successfully for companies similar to our own.
  • How will the new software change workflow? Sample answer from the CIO: I’m looking forward to it! It looks like the software will improve transparency through our entire department.

Think of yourself as an investigative journalist. Be sure to get a set of answers from at least one representative from each impacted team—ideally more.

It’s not your job to find all the answers to these questions, but it is your job to assess what challenges you may have to overcome when implementing a new tool. Addressing the answers to these questions will come from those in charge of change management in your organization, along with representative team members, is all you have to do at this point.

Finding the high-level answers to these questions is just the first step; later, you’ll create software advocates similar to the groups that you surveyed here to help with user adoption.

4. Screen existing enterprise Agile tools for scalability

You know that enterprise Agile software aligns with your business’s priorities.

You confirmed that there is a business justification for software adoption.

You worked through a set of investigative questions to gauge what problems may emerge when adopting the tool.

Let’s look at selecting the right software systematically.

There are plenty of programs that claim to provide “business agility,” some to their own detriment. While plenty of product management tools provide features for Agile development and also claim to scale, few were created with the intention to do so.

Luckily, there are a series of signs that suggest whether a tool can work well with SAFe, LeSS, Nexus, or other scaled Agile frameworks.

Feature A: Basic Agile

Of course, every enterprise Agile tool should have basic Agile features. Any tool that doesn’t provide the following should not be a consideration for your team:

  • Dependencies
  • Story types
  • Velocity and burndown reporting
  • Backlogs
  • Issue tracking

Many project portfolio management tools claim that they support Agile, but don’t in reality. For example, using just this short list of features that any Scrum team could expect of their project management software, many “Agile” tools don’t make the list.

Business case for software: Agile features
Business case for software: Agile features

Once you’ve identified scalable Agile tools, look for the second set of qualifications.

Feature B: Built with scaling in mind

While many tools market themselves as team-based solutions that scale, the features that they offer—not to mention the price point at which they offer it—quickly prove those claims untrue. But how can someone evaluate a tool for something that works not just for your team now, but your team of the future?

There are four features you should look for:

    • SAML or OAuth: Your Agile software should offer sensitivity to your company’s growth as an enterprise—and with it, increased security risks. The enterprise version of the tool should offer a single sign-on protocol to keep your teams’ information safe.
    • Customizable visual encoding: As your software scales across the enterprise, speed fuels its agility. Portfolio and product managers must be able to see all of their projects’ progress immediately on their dashboard—and those reports must be easy to set up, visual in nature, and immediately actionable. Be sure your new tool can tailor its views so that management can immediately see items in need of attention.
    • Scaled pricing: Not every enterprise Agile tool believes in pricing transparency (a concern in and of itself), but if you’re able to glean insight into pricing structures, beware:
      – Throttled non-administrative user roles.
      – Plugin dependency for features commonly available in traditional project management software (e.g. time tracking), especially if they cost extra.
    • User buy-in: If no one likes using the software, no one will use it; they’ll find workarounds.

Only consider tools that have a 90% (or 4.5/5 stars) satisfaction rating when averaging review sites like Capterra, Finances Online, and G2Crowd. When providing the example below, I averaged those three sites.

How to build the business case for software: Scalability
How to build the business case for software: scalability

Feature C: Enterprise-level, Agile-specific functionality

Whether you’re using Scrum at Scale, SAFe, LeSS, Nexus, or something else, you’ll want your enterprise Agile tool to be enabled to conform to these guidelines.

Given that many companies scale Agile differently (and often use a hybrid process), consider looking for these features:

  • End-to-end business agility: Tie business objectives to each product in development so that the whole company is pushing in the right direction.
  • WSJF and ART enablement: Look for features specific to continuous delivery, building and enabling a secure work structure, and investing in priorities transparency.
  • Advanced forecasting and estimating: Look for tools that can not only report on work you’ve already done, but also work that you will do. Adaptive tools are necessities.
  • Third-party validation: While awards aren’t everything, they can indicate a product’s strengths. Look for placement from objective evaluators like Forrester or Gartner in their latest evaluations of best enterprise Agile tools.
  • Method investment: Is the tool formally invested in one of the scaled Agile methodologies? Whether the enterprise Agile software is a Nexus, Scaled Scrum, or SAFe-specific tool, investing in sponsorship for a business agility framework demonstrates a commitment to the cause.
The business case for enterprise software: Scaled Agile
The business case for enterprise software: Scaled Agile

From here, it’s time to get quantitative.

5. Find the right numbers for your business case for software

No business case for software is complete without metrics, money, and methods. The people you’ll be presenting to will immediately forgo text if they can get numbers. Let’s find the ones they care about most.

And while understanding metrics and knowing how to read them is highly important for any decision-maker, there is still one aspect that trumps everything else in business. Let’s talk cash.

There are three questions you need answer for your Agile software business case: What is the initial cost of ownership, what is the short-term cost of ownership, and what is the total cost of ownership over the course of five and ten years.

The initial cost of ownership is the easiest of these to calculate. It simply means “how much will it cost to first implement?”

For some tools, this may be a heavy investment; if you need to upgrade your enterprise’s infrastructure, for example, implementation costs could net several million dollars.

However, if you’re choosing a cloud provider, that scenario is unlikely. Instead, you’re more likely to encounter one-time setup costs, training fees, or an annual bulk payment. If you’re planning on hiring a third-party implementation specialist, include them in the initial cost analysis as well.

Short term costs include the above-mentioned fees along with estimates about lost productivity. If the tool isn’t as easy to use as Facebook, your business may suffer from resistant employees and unenthusiastic leadership. Be sure that your enterprise Agile software account manager advises you, using experience from serving companies similar to your own.

Finally, the total cost of ownership (TCO) is an estimate of how much the tool will cost you in the long term. Use our calculator to estimate what your TCO will be.

(A complete TCO calculator is included in the business case for software kit.)

6. Analyze the tool’s expected benefits and risks

You’ve picked your tool and you’ve honed in on costs. It’s time to evaluate the tool’s benefits and potential risks.

The benefits of enterprise Agile software tend to stem from the following:

  • Provide value stream clarity
  • Create and share portfolio roadmaps
  • Alleviate portfolio resource and budget misallocations
  • Tie company goals to projects and initiatives
  • Break down large projects into easy-to-tackle parts
  • Manage and mitigate risk
  • Uncover and visualize dependencies
  • Predict upcoming user workloads
  • Prioritizing and assigning backlogs
  • Improve communication
  • Decrease unnecessary meetings
  • Increase budget adherence
  • Foster quicker deadlines
  • Clarify priorities
  • Systematize pipeline management

As I mentioned above, decisionmakers love numbers. Consider working with an account manager to estimate numerically. Some benefits may include:

  • Increase program velocity by 70% in six months.
  • Establish program predictability within first month.
  • Reduce running technical debt by 25% in first year.

No good things come without risk, and outstanding scaled Agile software is no exception. Ideally, your account manager will have worked with people in your industry before and be able to flag specific common problems. For example, in enterprise IT businesses, common risks include poor user adoption, poor security precautions, and poor implementation.

You’ll find many other possible risks as you evaluate the path (step 3).

When assessing what to do about those risks, remember that there are five common strategies. As I wrote in a prior article on risk management:

  • Avoidance: Change the objectives and scope to avoid the risk altogether
  • Transference: Push the risk onto a third party (like a subcontractor)
  • Moderation: Take steps to lower the probability of the negative event occurring
  • Acceptance: Accept that the risk may take place, along with any associated consequences
  • Abeyance: Determine how to address this risk at a later time.

Note: these suggestions were also pulled from the Office of the Assistant Secretary for Preparedness and Response, but the original document has been removed.

Be sure to investigate risks thoroughly and present them transparently; if decision makers uncover that you’re purposefully hiding or distorting realities that could damage their company, they will not take the rest of the proposal seriously.

7. Propose a sample implementation plan

While your enterprise’s decision makers will likely have follow-up questions and will want to demo the product themselves, show your preparedness with an illustration of how your company might deploy your new software. Your implementation plan will likely change, but it should demonstrate an awareness of what a plan might look like.

My suggestion is to take a calendar and select dates for the following over the course of three months:

  1. Confirm and reinforce executive support
  2. Create software advocacy groups
  3. Configure the system to meet enterprise needs
  4. Transfer existing data
  5. Initial onboarding session (this is typically an iterative process, but good to include as a benchmark)
  6. Provide enterprise Agile tool vendor feedback for customization
  7. Provide specialized training to software advocates to amplify adoption
  8. Audit processes for implementation failures after three months to iteratively address
January enterprise Agile software implementation plan
January enterprise Agile software implementation plan
February enterprise Agile software implementation plan

February enterprise Agile software implementation plan
March
March enterprise Agile software implementation plan

8. Distill your message to a one-page plan and presentation

Congrats: you have all that you need! To effectively organize all this information into a business plan for enterprise software and one-page business justification.

カテゴリ

タグ