Traditional procurement procedures including steps like RFI (Request for Information) and RFP (Request for Proposal) are based on extensive paper work consuming a lot of time and resources on customer and vendor side. Such a procedure is sort of legal preparation, unintentional declaration of mistrust and delivers very low business value regarding the project itself. We “only” select the vendor but there is almost nothing to be used on business side when this procedure is done. The “valuable part” of the project only starts after contract is signed and the scope is fixed.

Such procedure and behavior is quite understandable from the customer point of view. Customer would like to select the best vendor according to proposed price, promised quality, declared business knowledge, experience and speed capability. But the point is the word “proposal”, “promised” or “declared”. In traditional RFP, you do not have many ways how to practically verify this information, apart from references. Is the proposed triplet price-quality-speed real? Is it even physically feasible? How can I – the customers that is not an IT expert – even asses it? The experience says the reality quite often varies from the proposal. And one of the reasons is the procedure itself. Big pressure on price, fixed scope with very low flexibility for change, late delivery, low value, lack of trust… Sounds familiar to you?

Such a distorted conditions are even more affected by so-called fix-price-contracts that are in reality fixing the scope, budget as well as delivery date. Still I don’t get the point why we call it fix price, if we fix all project aspects, not just the price. IT vendors are forced to lie in their proposals under such conditions. Fortunately, there are also other options. One of them is an Agile RFP.

What is an Agile RFP?

Agile RFP is a practical way of value-based competition between invited or pre-selected software vendors. Rather than asking and replying to questions and than determining which answer and proposal is better, you really try it, experience the vendors and see the real results.

What do you need to run such a RFP? You only need Agile experience and have a relatively small part of the future project that can be in the scope of RFP competition. It doesn’t matter whether it is a new service or a product to be built, integration project or implementation of CRM or ERP. Always, there can be found a small horizontal cross-layer-step that can be delivered to see (and immediately consume) the value of the project. Examples can be following:

• For the new project: it can be one core user story like the calculation of salary, first version of management dashboard with just a few measures or the invoice issuing, not the register to insert or edit the data although vendors can tell you they need to start with this. But what is the value of simple register without any extra function on top of it?
• For integration: it can be just one typical scenario integrating subpart of planned systems but delivering new functionality. Typically the scenario used daily (not only sometimes) or processing 30% of all requests or low frequent one but with highest value.
• CRM implementation: it can be simple sales pipeline feature or new valuable report based on existing company data.

The goal is to find few simple scenarios delivering something new that can be ideally used in real life customer environment after the RFP is finished. Of course, not always need to be released in the live environment, but it is and should be shippable. It is not buggy-spaghetti-code prototype. This is the point. And by such mini-project you verify the promises of the vendors. You experience their way of working, communication style, the team, flexibility, skills and domain experience. At the same time, it serves also your learning. By the regular demonstrations of the initial solution, you clarify your needs and expectations. Based on this, you can still adjust the scope of the whole project.

In other words, there is no better way to clarify your needs and verify vendors’ promised ability of frequent releases, high quality code, velocity, ability to work with open and changing scope, and cooperation style, than to experience it in real life under future planned conditions.

Already after the first sprint demonstration, you’ll see the profile, abilities, communication style and attitude of the vendor. You also see the week-by-week progress. Some vendor will set the speed and run like hell all the time. Others will significantly improve as they learn. One can be really business-oriented or proactive. Other can be more technical or passive. All this will help you to clarify your needs.

Built-in benefits of this approach

Why is it better to conduct such a competitive selection mini-project rather than a traditional procedure?

• You build trust and cooperation routines since day 1.
• All competitors deliver real value since day 1 of selection procedure.
• Much shorter time spent on paper work, people work on real value product, not on paper piles used later on for decision.
• Practical verification of their skills, experience, working routines and approach in the future project context.
• No (or at least less) room for politics. There will be collective agreement on the winner. The skills and results will be visible to all people participating the demonstrations. It will be based on facts, not on theoretical answers and personal/political preferences.

What people say after the Agile RFP? I will mention only one statement:

“Now we have 3 usable MVPs and clarified project roadmap just after 1 month of work. In the traditional RFP, we would be still in the phase of internal discussions about what we really need with just part of initial requirement description.”

Such Agile RFP is not so easy to run. There are many small aspects that can go wrong and a lot need to be prepared upfront (but still less than for traditional RFP). Therefore there is one key precondition before starting Agile RFP. You should be practically experienced with agile way of working, not just from software development or IT operations teams, but also from business teams.

If you answer yes to few of the following questions, you should be ready to try Agile RFP:

• Have you already tried to run project/product cross-functional business teams sitting and working together instead of “teams” in functional silos?
• Does your team have a clear prioritized backlog of tasks/projects (not just all is priority 1)?
• Do you limit Work-In-Progress (at least on project level)?
• Do you show and release outcomes of your work frequently?
• Do you ask your real users for the feedback on your work?
• Do you run regular retrospectives to improve?
• Was some of the mentioned done in the context of your business units, HR, sales, marketing or even in the management team?

If you don’t understand these questions or you haven’t heard yet the terms like retrospective, WIP or prioritized backlog, than I recommend to try it internally first. You can also read more about the required Agile experience and phases of Agile evolution in organization as I see it from the Agile adoption cases.

Your experience is important, because you need to prepare the business side of the project for RFP (scope, stories, benchmark estimates). You need to provide experienced Product Manager (team) that will take care of the competing vendors, consult priorities, and discuss acceptation criteria and all the proposed changes. You are also supposed to conduct regular demo sessions with vendors and all this should not be new for you.

Project velocity as the fair-assurance

You can wonder how to “compare” the vendors’ capability, velocity, value delivered and how to ensure the sustainability in the subsequent project. Vendors can run exhausting sprints to deliver the highest value and story points to win the RFP or they can use “hidden” internal people. But this is not much sustainable. This is quite crucial and can be done in several ways. We had following thoughts:

• Have the same/similar environment (internal or external)
• Have the same (claimed) team size and wanted to know the changes for the sprints during the sprint planning
• We have prepared benchmark stories (with expert estimate from our side) mandatory to all vendors
• Velocity achieved with claimed team in RFP was expected as the initial one in the subsequent project.

Although we trust our pre-selected vendors, we wanted to have these checks included in the RFP procedure. Such commitment to proven velocity removes all tempting techniques and forces vendors to be sustainable in the speed and be open to us. It worked perfectly in our case.

And to really gain the value out of the RFP, you should own the delivered code at the end. Therefore prepare the license and IPRs agreement and pay all vendors for their effort if they pass agreed RFP’s Definition of Done (e.g.: conducted all demo sessions, showing the sprint plans, having code in GIT for demo, …).

Remember, the goal of such RFP is not to act from the position of power. The goal is neither to catch vendors on something they don’t know. The goal is to build trust, uncover risks early enough, see how they progress and solve these situations, learn together and set the basis for future Agile project you are hiring for.

I necessarily skipped many important details, as I was part of the team that prepared and run the Agile RFP. Do you miss something critical? Are you interested to hear more? Or do you have your own experience? Please comment, ask or propose your ideas in comments and look forward for the next article with simple checklists for potential Agile RFP.