5 steps to build a business case for Identity
In this blog, Max Faun explains the five steps to take when building a business case for Identity & Access Management (IAM).
Successful adoption of any enterprise tech solution requires three things: time, effort, and investment.
This is especially true when it comes to Identity & Access Management (IAM).
But before you can even consider delivering secure, frictionless log in experiences for your applications. Or automating employee lifecycle management to save your IT team hours of work – you need to convince your CFO to sign off on the investment.
As is often the case, the value of modernising identity and access management (IAM) is readily apparent to technologists.
If you’re a senior architect, for instance, and you’d like to upgrade to an IAM solution that can perform both SCIM provisioning and SAML authentication, it’s obvious that this is a big step above a solution that can only do SAML.
For business decision-makers, however, the value isn’t always so clear.
Enter the business case.
A business case quantifies the value that a project will deliver, explaining why the benefits of making a change (or a purchase) outweigh the costs of doing so. Building a business case is a structured approach to demonstrating why the project will realise measurable improvements that will help the business advance towards its goals. It is essential for ensuring that your project gets prioritised amidst a sea of other potential purchases, and for ensuring that stakeholders understand how it will drive the business towards an outcome that they’re trying to create.
An effective business case will serve as a bridge from the world of technology into that of the business. Technologists may not have extensive experience with these sorts of processes, but understanding — and adhering to — them is key for communicating the value of a project to business stakeholders.
Nowadays, when every company is a technology company and making the right IT investments is essential for success, building a business case is something that every technologist should learn to do.
Any business that’s achieved a certain level of maturity will have their own structured processes in place for approvals and procurement. That being said, there are generally five steps to take when you’re creating a business case. We’ll explore them in greater depth below.
Step One: Understand your Why
If you don’t know where you’re going, any road will get you there.
When it comes to a business case, it’s important to understand what you’re hoping to achieve before you begin to assemble information and evidence, create the document, or socialise it.
Perhaps an IAM solution will solve a problem that you — and other stakeholders within the business — have long been struggling with. Maybe it will mitigate significant financial risks. Or perhaps it will enable you to follow industry-wide best practices.
A business case will give you the means to communicate the value of a particular solution to a current business problem. A solid business case lends credence to your argument, showing that the solution you’re proposing isn’t just better in your opinion, but is superior in a way that’s backed by logic and quantitative evidence.
Building a strong business case:
- lowers the risk that your project will be underfunded or deprioritised
- speeds approval
- demonstrates that you have business acumen as well as technological expertise
Step Two: Know Who you Need to Persuade
Understanding your audience is vital if you’re to convince them of the merits of your solution.
You’re not building the business case for technologists alone, so it’s important to speak about things other than the features and capabilities of the technology. Instead, you’ll need to consider the requirements and priorities of the stakeholders who will be involved in the purchasing decision.
This means you’ll need to persuade:
- your immediate supervisor
- senior leadership (Depending on your organisation’s size, this might mean members of the C-suite or senior technology executives.)
- procurement
- other affected functions
The latter group is among the most important. If, for instance, a new IAM solution will automate a number of tasks that HR currently performs manually, saving them a great deal of time and effort that they now spend on data entry, HR can become a powerful voice speaking in your favour to senior leadership. Plus, the fact that you’ve got cross-organizational alignment demonstrates that you understand the needs and priorities of the business as a whole.
To reach these stakeholders, you’ll need to talk in terms of outcomes. You might say things like, ‘We’ll be able to onboard new users in less than a minute instead of three days.’ Or, ‘We’ll reduce our total cost of ownership in the area of account provisioning and de-provisioning by 30%.’
These concrete, quantitative statements of value are especially important to the procurement department. Procurement’s goal is to prioritise projects and investments that give value to the business. A solid business case demonstrates that you’ve already done the due diligence that procurement would otherwise need to do themselves, prior to sign-off.
Once you’ve figured out who you need to approach, you should build a stakeholder map. This consists of a list of the people who have sign-off authority, as well as those who influence them and make recommendations to them.
With your stakeholder map in hand, you can begin to create a contact strategy. This is a list of all the specific meetings you need to have in order to socialise the business case to all relevant stakeholders. In most cases, there will be deadlines for scheduling these meetings, since you’ll need to ensure the project fits within budgetary approval cycles.
Step Three: Describe the As-Is State
In order to build a case for change, you need to understand your baseline. In this stage, sometimes also called the ‘today state’ you quantify what things are currently like. These metrics will also enable you to demonstrate the benefit of the project, once it’s complete, by providing a point of comparison.
Taking stock is a critical part of the process of building a business case. You’ll want to think about the pains that you’re currently experiencing, the solution that you have in place, and what’s wrong with it. Each pain point should be expressed in quantitative terms that can easily be comprehended by someone without a technical background.
We’ll delve into this process in greater detail in our next blog in this series, on building a value framework for identity.
Step Four: State the Intended Solution(s)
Once you understand your current pain, as well as the stakeholders you need to address and your reasons for doing so, you’ll need to evaluate solutions.
A business case can be built for a single solution, assuming that you’ve already done the comparative work and have picked one, or it can set multiple solutions side by side to show what the benefits of each would be.
Just as you did with the current state, you’ll need to quantify the fix. How much will the problem’s severity be reduced? 100%? 50%? 30%?
You also need to factor in implementation timelines and costs. These can include expenses associated with professional services and change management. It may be the case that, while initial costs are higher if the rollout is accomplished more quickly, you’ll also begin to realise the solution’s intended value sooner, offsetting the increased upfront investment. This step, outlining the ‘to-be’ state, should consider these sorts of tradeoffs as well.
Step Five: Package and Present
This work isn’t complete until its results can be shared with others. It needs to be in the format that’s best for your business and the stakeholders you’re trying to convince.
Larger enterprises often have pre-created templates for business cases. You can augment this template to make it more granular, quantitative or compelling if you’d like, but you should use it if it’s available. In businesses that have one, it’s likely that this will be expected.
In other organisations, there may be a typical mode of communicating that’s always used for business cases. For some that’s a doc while for others it’s a slide deck. In certain organisations, videos are the medium of choice to share this information.
What matters is that you package the business case in the way that’s most likely to be impactful to the stakeholders involved. If it’s a senior business leader who won’t have time to look at more than a handful of slides, you’ll need to be concise.
The key is that this asset has to be sharable, and it has to exist in a form that can be readily appreciated by its audience. If it lives only in your mind, it’s not a business case yet. This asset must become something concrete that you can circulate and socialise.
Keep in mind, too, that a good business case is a living document. As your evaluation of technology and your business needs change, the business case should evolve. And as you get feedback on it, you can iterate to better reflect stakeholders’ concerns and the business’s shifting priorities.
In the end, the goal is to drive the business towards improved outcomes. This can come in many forms: reducing cyber risk, increasing productivity, lowering costs or boosting customer experience. But the final outcome should generate value for the business. Like an argument in a court of law, a good business case makes this value apparent in a way that’s clear, precise, compelling and logical.
Learn more about why you should consider Okta for your security and identity needs and how you could start building a business case by clicking here.