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:

• Technical:

• ~ 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.

• Support:

• ~ Expertise of vendor Customer/Solution Engineering team.
• ~ Availability of vendor Customer/Solution Engineering team.

• Commercial

• ~ 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!

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:

1. 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.
2. 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…

1. 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!).
2. 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.
3. 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.
4. 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.
5. Architecture slide - This is essential as it will help all stakeholders understand where the solution fits into your existing tech stack.
6. Vendor proposal.
7. 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. 
8. 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.
9. 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!