People working for SaaS, IaaS, and PaaS companies, especially those with highly regulated customers, know that the “request for” process can be a really painful business undertaking. Anyone involved in providing the materials for a Request for Proposals, or a Request for Information, or a Requests for Briefs (hereafter I’ll call them RFx) knows that they are very difficult and time-consuming to produce. For us at MuleSoft, when we participate in an RFx, there are numerous processes that involve our engineering, pre-sales, finance, legal, and infosec teams, which take a long time to complete.
For Kevin Paige, our chief of information security, this is particularly complicated because information security plays a big role in RFx processes MuleSoft participates in, and the team doesn’t want to be a blocker for sales or the customer getting the needed information to conclude a sale and ensure the risks are fully understood. This means Kevin and his team, with their particularly specialized knowledge, could spend weeks on an RFx proposal, tying them up and preventing them from working on other projects. And RFx’s are just one method in which InfoSec gets questions about the security controls in place to support customers. Customers also have annual reassessments, and many times even though a company did an RFx process, the information doesn’t get passed on to other internal teams, so those teams further want validation of security for cloud vendors.
MuleSoft is a startup in high growth mode, so it needs to move faster than traditional business processes can accommodate; also, there’s no standardized method in the security industry for security vendor management. It, therefore, becomes difficult to gauge which type of customers will ask which type of questions, making planning for RFx projects very cumbersome. Kevin knew there had to be a better way to support this business process.
Dealing with an organization’s “giant pain.”
“The RFx process is a giant pain,” Kevin told me. “There was no visibility into when or how many were coming. And then when they did come some were 5 questions, while others were 1500 questions. Whoever got assigned an RFx would work hard and fast to get it done – it could take 3 weeks or 1 day — it was impossible to tell. We started to use JIRA to provide more transparency and visibility, and that kind of worked, but we still had no overall visibility of the questions and answers. And we had no way of providing those answers to the larger group and establishing a curation process. Plus, we needed to manage KPIs like how long do RFxs take and how many and what kind of questions they usually contain. The main problem is that it’s difficult to assess the level of effort needed to serve an unknown amount of customers with an unknown amount of questions. It’s a black box.”
“Another problem,” he continued, “is that the entire RFx completion process is manual; the account executive has to write an email, and then the managers have to approve it, and then the RFx team has to create an approval, and then the sales leadership team has to provide approval as well. So nobody knows how many RFxs are actually happening, and those completing RFx questions are reaching out to individual teams without doing everything from a central point. Given the rate of change in the organization, there could be places where AEs were using answers to security questions that were not correct anymore because they wanted to help and quickly fill out the questionnaires for the customers.”
An efficient solution: semi-automating the process
What Kevin and his team did was decide to semi-automate the process. “On average InfoSec comprised about 45% of the effort of the RFx, and as there are other avenues where security questions come from, I wanted to create a process that was straightforward and simple. Our vision was to create something that we could turn into an internal self-service tool for InfoSec and then modularly grow it by pulling in other pieces of the business like legal, finance, etc. It needed a simple approval process that is geared around visibility and automation.” The idea,” Kevin said, “is that the approval process is automated, so you just have to populate it with answers to existing questions and the relevant information you need to get the deal across the line, in a way that’s visible for the whole company.”
“The first step we took,” Kevin said, “was to create a method to approve a “Master Q&A” Knowledgebase, with automated subject matter expert curation, and a way to automatically assign a specific question to a specific team/person with an SLA on the response. This will be incorporated into a web-based tool to ensure ease of use and self-service. Eventually, I want there to be a mechanism for all types of information to go into the tool. For example, “It could take information from Salesforce and then populate the tool with data for use by other teams in the company.
Empowering the entire organization
“My goal with this new tool,” Kevin continued, “is to empower anyone in the company can answer and validate infosec questions. Before, only a couple of people had the knowledge to do so. Now, all the information in my head will flow into the tool. The whole company can use this for RFx processes. Ideally, we want to get to a spot where we have a master set of curated questions, 2000 questions for every RFx that comes in so anyone could answer 85% or 90% of the questions from the knowledge repository. You would have the ability to search and pre-answer the questions to make the process even easier.”
Kevin and his team have started in the early stages of using this web-based tool, with some the features described above (a master Q&A, a simple question curation, and approval process, etc.) The early results have been quite dramatic. “Rather than my team taking an average of 14 days to do these tasks, it now takes four days,” Kevin says. “Now we have a centralized historical view, giving us both a method to manage tactically for the things happening now, and a method to provide a strategic data-driven capability to know what may be coming in the future.” But importantly, this tool, with its automated processes built in and knowledge repository, has huge use cases throughout the company, for more than simply completing RFx proposals.
“The secret of our success is that this tool emerged from one project at a time. One little team is solving this project and sending it out to other little teams,” Kevin says. He points out that the IT world is littered with failed integration projects and metadata stores that didn’t because they were instituted the wrong way. “It’s not top down – an order to use this particular curation tool – we’re solving the problem and creating the documentation and reference architecture, and spreading it organically for small teams. Processes, knowledge, technology, and document management systems are usually done in an opinionated way. There’s lots of stuff that you have to figure out, but it’s important to us to make sure the tool fits the processes we’ve defined rather than letting the tool define our process.”
The old way of working was cumbersome,” Kevin points out. “Since the business is growing at breakneck speed, the question we had to ask ourselves was whether this can be solved by hiring lots of people, or do we find a way to enable the people who need the data to find it in a self-service, more efficient way. My hypothesis was the most sustainable, useful solution was to enable self-service and greater visibility, and as the organization as a whole becomes more complex and getting more processes, long-term this will be a better solution.”
Take a look at more resources on how your organization can start projects like this and create a culture of change and adaptability.
