Reaching beyond traditional RFPs – Lessons learned Series

Recently, I had the opportunity to partner up with a leading sourcing strategy vendor (hint their name rhymes with “Partner”)  to lead the RFP process for a brilliant customer.  The mission is to re-engineer a large mission critical platform.  Over a period of 9-months, we created and executed an unconventional RFP process that resulted in amazing results and we learned several lessons.  In this series we will explore our major lessons and provide practical pointers for you.

Background

Our customer has embarked on an adventurous mission to re-engineer their core mission critical transactional platform.  The platform provides a highly available service (four 9’s) and supports millions of concurrent transactions

Step 1 – Sourcing Strategy : The process started like every other RFP.  We began by defining the sourcing strategy.  Upon approval of the strategy, we began the execution phase.  This entailed defined conceptual architectures, guard rails, requirements, service levels, and various other documents that resulted in an RFP package of over 600+ pages.  Yes, you read that right. The result was a 600 page package.

Step 2 – Market Scan :  The next logical step was a market scan.  Vendor market scans used typical criteria like market presence, track record, suitability and other factors determined by the customer.

Step 3 – RFI : Then we went through an RFI and interest assessment and sent the RFP to interested vendor partners.

Are you still with me?  This is typical of a traditional RFP process. 

Step 4 – The RFP Package : The RFP requirements were written taking in to account a strong desire from the customer for agile execution and collaboration.   The customer had an internal engineering team that was integral to the transformation.

Step 5 – Evaluation : We went though an elaborate process for evaluating responses based on criteria, rack and stack proposed solutions and assessing alignment with our customer’s requirements.

1200 hours, 30 spread sheets, 130 cups of coffee later …

The “A-Ha” moment

Most vendors (we are no different) have a boiler plate response template (perfected over years) that covers a wide spectrum of engineering activities, which they use as a baseline for responding to an RFP.  The team was stuck on one key question How do you assess the human side of engineering from a paper response.

• How can you determine if the vendor would work in our culture based on a paper evaluation?
• Does the vendor understand agile and how to apply agile for a large transformation?
• Would the vendor be collaborative and inclusive?

To answer these questions, we decided to invite down-selected vendors for a “Show and Tell” exercise.  Each vendor was told to bring in their “A” team.  The team should include all key personnel who will be part of the program, if the vendor was selected.

The email read

“Its going to be an intense 3 days of show and tell, bring your best people, make sure you bring a fully functional team, and be prepared to leave your team behind…”

The exercise included the customer’s engineering team to better account for a typical sprint.  Vendors were provided an ‘epic’ write-up 48 hours prior to the demo.  All vendor associates were provided access to the customer’s agile management and DevOps tools.

Step 7 – The “Show & Tell” Mockathon : Each vendor was given 2 days to actually show what they can do (based on their RFP response) and the third day was to demonstrate a working product to customer’s product management team. Here is an outline of the agenda (high level).  In future posts, we will explore, each day in greater detail.

Day 1 – Develop a backlog, define user stories, prioritize and select a story.  Create an architecture runway, define architecture guard rails and have a mock architecture review

Day 2 – Sprint planning, tasks and activities on the sprint board, sprint execution.

Day 2 Optional Homework – Sprint prototype development, application mockups, engineering, UI design and cloud deployment.

Day 3 – Sprint Demonstration, Sprint status and reporting (burn downs, velocity,) and Retrospective.

Due to the short duration of the effort, vendors were not expected to develop working software.   Some vendors pleasantly surprised us by actually developing a working prototype, complete with automation. Brownie Points!!!

As we went through the process, the RFP team and the customer engineering team collected valuable feedback about the agile skill level, the balance of roles and the soft skills for each vendor.

What did we Learn?

The RFP team easily placed Vendors in to 4 categories based on observations, interactions and process.

1. Collaborative & Open.
2. Consensus Builders.
3. Chaotic
4. Combative

These qualitative assessments provided clear and definitive direction to the customer as to who they can work with.

Where do you start?

Begin by looking at your pipeline of RFPs and pick a small RFP for an agile product.  Define a “show and tell” exercise.  Bring your “down-selected” vendors to a 2-3 day demonstration, one at a time and ask them to showcase their agile, collaboration and technical skills.  Develop a consistent and objective rating scale that is focused on Chemistry, Culture Fit, Collaboration and Competency.

Then, tweak your RFP evaluation process to include Show and Tell as key criteria with sufficient weightage.  You will be amazed at what you find out.  We were.

How can Terafuze help?

Our agile RFP process allows for the best of both worlds.

1. It provides contracting officers, procurement departments, business sponsors and IT stakeholders the ability to execute a traditional RFP process to obtain responses from interested and capable vendors.
2. Vendor demonstrations provide the human side of agile adding the culture fit and collaboration metrics.

Together, our methodology gives you an objective success score for each vendor.  The process is so intuitive that, most customers have a clear idea of the leader post demonstrations. Are you ready to begin your agile RFP journey?