In my last blog, ‘How do I convince my boss I need an Internal Developer Portal?’, I covered off the suggested process for convincing your own engineering organization to implement an IDP (Internal Developer Portal). That article was focused on the navigation, politics and persuasion of trying to implement tooling changes within your organization.
This time, we’re diving into the ‘nitty-gritty’ of putting together the actual business case for your IDP (although the principles will be the same for most SAAS solutions, not just IDP’s).
If you’re replacing an existing technology with an equivalent, the requirement for a business case is lesser. If you’re positioning a brand new technology, you’re going to have to roll your sleeves up (or get a sales guy to do it for you)!
One little disclaimer before I get into this. I realize that not every company needs to create a full-blown business case to implement a new software solution. When you are small especially, a lot of the time, there are just a handful of stakeholders and you can just make a reasonable assessment of what is right for your business. However, if you’re a mid-market to Enterprise size company and you’re looking for significant budget for tooling (especially a new type of tooling), you’re going to need a business case to prove:
- That there is a problem to solve and it’s worth investing in.
- That you’ve considered other options.
- You have laid out the benefits according to the requirements of your engineering organization (and not just your own needs).
- That you have recognized the need to prove ROI (Return on Investment) and that you have developed a calculation for measuring this.
- That you have taken the company’s purchasing process into account, regarding compliance, legal, Infosec (just a light touch assessment is needed at this point).
What format should I present this business case in?
Whether you use Confluence, Powerpoint, Word or whatever else, is not particularly important. There are 2 important considerations to take into account:
- You should present this case and not simply hand over a document. To create the best chance of getting your point across, you’ll want to create a scenario where the other stakeholders can ask questions, clarify uncertainties, challenge assumptions and generally feel included in the decision-making process. This will allow you to make adjustments and if required, make a second attempt at what matters most to the rest of the business.
With point 1 in mind, you should create 2 versions of the business case, one that is light on text for presenting and another that is heavier on detail as a follow-up document. Reason? When people are looking at a presentation, most of us can either read what is being presented or we can listen. There are very few that can do both at the same time. If you want to control the narrative, you should only include headlines, images and architecture diagrams if required. The detail should be in your own narrative in presenting. This means that you have everyone’s undivided attention and people will not zone out during the session.Then, to follow-up, you send the more detailed version which includes the same narrative as you have presented orally.
Who should I invite to the presentation?
Everyone who has influence in getting the project and investment across the line. Take into account that you may not even know all of these people. I see it happen so often that a team will go through the arduous process of validation and PoC, only for the deal to go missing in an approvals chain. 9 times out of 10, the reason it’s stuck in approvals is because one or more of the approvers had no idea the project was even happening.
Think about it from their side. If you saw an automated email come in looking for an approval for $50K for a project you weren’t aware was happening from someone you didn’t know, how would you react? Sometimes it would get rejected, most times it simply gets ignored.
When things eventually get escalated to getting this approver’s attention, you’re now back-tracking and trying to convince this stakeholder from a position of weakness.
Get to know your approvers, what matters to them and make them feel like part of the process (because they are!).
I’m a bit shy and my manager/director has more influence than me. Should I ask them to present this?
Only if they have been part of the assessment process and have been allowed to give their own input into the business case. The vendor will always be best placed to ‘sell’ the product but for the purposes of an internal business case, getting them involved for those internal discussions is not a good look. So you must do the next best thing; let them arm you with all of the detail and content required to get your point across as well as possible. It will still be second hand information but you can make a decent stab of it if you have been through the PoC process and got your hands dirty with the tool. If you are handing this over to your boss, it’s turning into 3rd hand information and this is where these requests for budget tend to fall flat, as they often fail to deal with challenges or communicate the value proposition of the solution.
If you’ve made the decision to purchase a proprietary Internal Developer Portal, as opposed to going down the DIY or open-source route (as laid out in this IDP whitepaper), then you may have to adjust to the mindset that comes with that. One of those points is in dealing with a sales person (or Account Executive as they’re often referred to). It’s common and even prudent to maintain a level of caution when dealing with sales guys, especially early in the process. The fact is that they are trying to sell you their product and you don’t know if it’s right for your business or not yet. Therefore, until you’re convinced that this IDP fits your needs and requirements, the relationship might seem a little forced and sometimes heavy-handed from the vendor side.
The best way to approach this (from both yours and vendor’s perspective) is to agree on objective success criteria for the assessment project. This applies whether you are performing a Proof of Concept or otherwise. What’s more, you should aim to be forward thinking with the PoC. If you lay it out in the right way, it should really help form the bedrock of the business case.
These may include:
- ~ Integrations with your tech stack.
- ~ Documentation - is it clear, comprehensive and up-to-date.
- ~ Performance - This would come under the overall goals of an engineering organization but you may not be able to use this as a financial return metric.
- ~ Engineering hours savings - Sometimes this is one and the same as performance, but not always. Any feature that helps to reduce engineering toil or build times can be used to measure this. You may not always be able to measure this fully in a PoC but projections should be adequate. This will be the most important metric in any business case.
- ~ Expertise of vendor Customer/Solution Engineering team.
- ~ Availability of vendor Customer/Solution Engineering team.
- ~ What is the cost of the solution.
What’s more, by coming up with this list of success criteria, you may be able to qualify out many vendors without much time drain (sometimes even before a demo!). Ideally, you would perform as few PoC’s as possible. By the time you’ve come to the PoC stage, this should already be a preferred vendor and you’re simply using this PoC as a proof-point and basis for your business case.
At this stage, you and the vendor are officially on the same side and you should take advantage of any content or expertise they can lend. Realize the point that you are on the same side!
RFP’s (Request for Proposal) and tenders
For a lot of organizations, there may be a requirement for an RFP if there is new technology or even if the value of the license is expected to be above a certain value. If you’ve never been involved in developing one, I can tell you that the process for developing an RFP is even harder than answering it. There are 2 common types of RFP:
- Blue-sky - A common approach is to develop a suggested workflow and work backwards towards the functional requirements. 3rd Party consultants frequently take this approach as the scope of their job is completely detached from your actual budget. Very noble but completely impractical. Usually if these were to be followed through, the cost of covering every bit of required functionality in the RFP would be eye-watering and unviable. It also creates a huge amount of redundant functionality which they'd still be paying for. Everything ends up being stripped back and they soon realize their ambition ran far deeper than their budgets.
- Vendor led - I know, even the name grates. It’s a dirty but well known secret that these are the RFP’s that actually go somewhere. This is where the person developing the PoC has created the functional requirements list working backwards a preferred vendor’s technology. This can happen when the RFP author has either previous experience of this tool or where there may have been a previous discussion with the vendor to make them realize they needed this solution in the first place.
RFPs aim at protecting the company from conflicts of interest by providing an "objective" view of the possibles.
However, in 99% of the cases RFPs are mainly a forcing function (making authors actually review the market) rather than a holistic analysis (which let's be honest is not realistic). So authors should do their research work, find a tool (or tools) that seems to fit the bill but then build the RFP with the help of vendors.
Although this approach seems less noble from a technology perspective, sometimes we ‘don’t know what we don’t know’ until we see a solution that we know could benefit us. If the functional requirements list is mapped back to this product (or even a couple of products), it will make the project far more viable as we know it will fit under a single software license.
Let’s use a Rely.io example here (and a great excuse for a shameless plug!). A lot of the people interested in Rely are looking for a Service/Product Catalog, User Journey health dashboard etc. For most organizations, they know that SLO’s are the way to go but it seems like something far in the future, as they just don’t have the expertise to set this up in-house. When they see how easy it is to set up in Rely, they often change their tune. Without the demo and vendor exposure, this was never going to be included in a blue-sky RFP for an IDP, even though it has the potential to completely revolutionize engineering productivity.
RFP’s are there to create a well governed and fair process for picking a solution. A vendor-led RFP may not seem fair to the other vendors invited but oftentimes with newer technology, there are significant differences between vendors and you may already know what you need for your business and you just need to guide it that way. RFP’s tend to work better with a more mature technology space where multiple vendors have reached functional parity.
And now the moment you’ve all been waiting for…
The presentation document:
- Describe the problem statement: Why it needs to be fixed. Include estimated man-hour cost of the current process vs the one you are going to recommend. (You can include the breakdown of where this came from at a later point). Don’t get caught up on details about accuracy of data, use conservative return figures. What you and your director care about is the efficiency and performance of the sales organization. Let the bean-counters worry about the ROI sheet. And as long as you are happy with the validity of the ROI sheet, they will be happy too (as long as there is budget!).
- Alternative solution analysis. This is an essential part of the process, otherwise your preferred choice will seem as if you’ve merely been ‘taken in’ by a sales person. Not a good look! Include a pros and cons analysis on each but nothing too in-depth. Just enough to give confidence that they have all been properly considered and discounted.
- Benefits of solution to your goals. Use the results of the PoC (or demos) to describe this. The vendor will most likely have material on this already or you may even be able to lift it from their website. No need to reinvent the wheel here. The solution you’re looking for might have a bunch of functionality that you’ll never use. This is perfectly fine and it’s always the case. But people don’t like the idea of spending money on functionality they aren’t going to use, so only show what’s relevant to your business.
Make sure to include details around scalability and overall UI.
- Vendor support. It’s not good enough for SaaS companies to merely provide a ‘product’ any more. One of the main benefits of the SaaS world is the support and expertise that comes from the vendor. It should also be free. If professional services are another cost that comes with the solution, it could end up becoming a ‘Trojan horse’ of expense.
- Architecture slide - This is essential as it will help all stakeholders understand where the solution fits into your existing tech stack.
- Vendor proposal.
- ROI calculator. In the engineering space, these returns tend to be measured by engineering hours, rather than revenue, but don’t you worry, they finish off the math themselves. There’s rarely a need to put this together from scratch. Most vendors will have something like this ready-to-go. Some tend to be a little overzealous with the ROI projections. If they do, no need to get annoyed (remember, you and the vendor have recognized that you have the same goals since the successful PoC), just make the necessary fixes. For example, 40 minutes for each unit of context switching is going to raise eyebrows and lower credibility. Maybe keep it at a nice, conservative 10 minutes. A good figure for ROI on a SAAS product would be about a 10X return. The vendor's ROI sheets will usually include the correct metrics to measure but not always realistic figures.
- Infosec run-through. Depending on your own company’s processes, this may come sooner or later. Oftentimes, you or someone on your team may have a good idea of what will get through Infosec audits, such as SOC 2 compliance, etc. Again, the vendor will usually have a one-pager on security and the details in there should suffice at this point.
- Executive summary. One or two paragraphs should suffice. Focus on the highlights from the benefits and ROI. Remember also that for many looking over this business case, this might be the only page they read!
So there you have it! It’s not too bad when you lay the structure all out. Better yet, you’ve seen how much can be ‘outsourced’ to the actual vendor!
At Rely, we’re focused on solving problems and not just pitching solutions. If you’re looking at solutions for a Software Catalog, SLO Management or maintaining/scaling operational standards, we have a template ready-to-go. Feel free to get in touch with me and I’ll share the model, regardless of where our own discussion goes!