The 9 Characteristics of the Ideal Agile Tender

Does the traditional tender process still work if an organization invites tenders for an agile project? According to Barry Overeem and Rini…

Does the traditional tender process still work if an organization invites tenders for an agile project? According to Barry Overeem and Rini van Solingen, it doesn’t. However, there is an alternative. They describe nine characteristics of the ideal agile tender.

The Traditional Request for Proposal

A traditional Request for Proposal (RFP) is a step-by-step process in which a large number of potentially suitable suppliers (long list) go through several steps to ultimately end up with that one supplier (often through a shortlist) that seems to be best capable of meeting the demand. This is a document-intensive process involving presentations, question and answer sessions, and — last but not least — price and contract negotiations. These steps take a lot of time — and, therefore, money — to complete. The total completion time of a somewhat extensive RFP can easily take six months — and several man-years in terms of effort. Given the speed with which the market is currently changing, the phrasing of the question or formulation of the problem is often already outdated. Isn’t there a way to make all this effort and completion time more profitable?

It is, for example, striking that the most important choices in an RFP are primarily made based on promises and assumptions rather than facts. For it is only after the RFP that the collaboration starts, which is when evidence emerges. And that’s a shame. After all, we know that the real test takes place in practice, because ‘The proof of the pudding is in the eating.’

Agile working revolves around collaboration, equality, getting results early, learning quickly, and responding to change. However, nothing actually happens during the traditional RFP process. To actually find out which supplier is the most suitable, can cope with change in the most effective manner, and delivers results in the most reliable way, decisions should be made based on experience rather than promises and assumptions. The traditional concept of inviting tenders seems to be unsuitable for starting a truly successful agile collaboration, as it postpones the start of the collaboration until after the choice has been made. What would happen if all those RfP steps were thrown away in order to decide on one single supplier in a completely different, interactive, and result-driven manner? This does, however, require an entirely different approach — that is, an agile approach to the tender itself.

Reorganize the Entire Process

We advocate reorganizing the entire current process of RfPs. Start collaboration with a (limited number of) supplier(s) as soon as possible. Emphasize operating software in frequent deliveries. Just pay suppliers for it and decide which supplier you can cooperate with in the most successful way as soon as possible. In reality, one already starts within the selection process and makes a choice based on real performances.

Collaboration — as well as the building of mutual trust — starts from the very first moment. Therefore, you should try to apply agile principles as soon as possible. Centralize interaction, work on valuable products from day one, and don’t defer collaboration until all details have been laid down. In this case, a large project will be split up into a series of smaller projects. And that’s just fine. After all, research has already shown that small projects are much more likely to succeed. Additionally, a small project will also produce working and tested results, and — as already stated — it can be discontinued at all times. This creates true agility.

An additional advantage is that all hours traditionally used to choose one single supplier can now be utilized to achieve working and valuable results. In other words: a win-win situation. The purchasing process for an agile project is only truly agile once a supplier selection no longer resembles an RfP and all those involved are working on achieving the optimum collaboration in the best possible way.

The 9 Characteristics

Implement the tender process itself in an agile manner. Split the process into short iterations, delivering the final product in completed portions. Each iteration should have the objective of designing the entire tender in a more specific manner. So don’t start with: writing out a request, documenting, Q&A, and presentations, followed by making a selection. Instead, go through this entire sequence in each iteration. Agile concepts that may be incorporated include workshops and — primarily — reviews and demos of the (sub) products.
Work on product- and business value from the very first moment. The focus must be placed on the product and the business value that it should achieve. Consequently, it’s about the operating result rather than the system. This automatically emphasizes a focus on value, quality, and the end-user instead of deadlines, budget, and scope. Because of this, the price and costs are related to earnings.
Make the Definition of Done part of the tender. Ensure the requirements necessary for documentation, test automation, or code quality are transparent. The supplier has the obligation to deliver working and tested software during every sprint — all in accordance with the agreed-upon Definition of Done. This way, the quality will be guaranteed.
Create the product vision and product backlog together with a number of suppliers. Invest a number of days to create a product vision and product backlog along with a supplier. You should perform this exercise together with the development team that will actually do the realization. Jointly assess the backlog, so that difficulties, uncertainties, and risks can be discussed in a transparent manner. Perform this exercise with a number of different suppliers to be able to test which cooperation feels best suited.
Describe the problem rather than the solution. Often, the supplier understands the technology much better and has experience with solutions and ideas. Therefore, it’s advised to jointly clarify the problem to be solved than describe the solution yourself. Provide the KPIs and use scenarios that are representative and can be used to test whether the system delivers the desired value. Consequently, you shouldn’t establish the functional scope, but the scope of the business value to be delivered. Best-value procurement fits an agile mindset much better than traditional RfPs.
Create a win-win situation around stable teams and productivity growth. Highly productive teams that frequently generate a lot of business value are rewarded with a high rate. For this purpose, one must steer towards teams with a stable composition. You should, therefore, ask the supplier to provide a Scrum team in its entirety. This team has probably been working in the same composition for some time, as a result of which it is well-practiced.
Collaborate with the suppliers to realize a contract as agile as possible. Although contracts don’t always serve as a guideline for the manner in which work is actually performed, they are needed to set preconditions for being able to collaborate in an agile way. Consequently, the contract must clearly state that the product is always ready (working and tested software during every sprint), contain simple exit/stop criteria (ultimately, the product is always ready, so stopping is always an option), changes in scope should be free (after all, changes proceed through the product backlog and don’t involve any additional work), and clear agreements should be made on keeping teams stable (bonuses for stable teams and discounts in the event of staff changes).
Use extremely transparent pricing. As a supplier, you should sell entire Scrum teams per sprint. Indicate how the Scrum team is structured and how the total price of the team is defined. The customer may disclose the available budget, its structure, and the main preconditions. Or — even better — make pricing transparent by agreeing on a price model; direct labor costs with a markup percentage for overhead expenses and a separate markup percentage for profit. Negotiate on the overhead and profit percentages rather than the price. Arrive at a joint decision on a fair profit that both parties can explain to their following.
Ensure that both the client and supplier are truly agile themselves. If the supplier or customer decides to have a product developed in an agile manner, you should assess whether the party involved possesses knowledge and experience in ‘agile.’ Make sure they ‘are agile’ and don’t just ‘act in an agile manner.’ As a client, you should also be agile. Both during the RFP process and during the realization of the project, the agility of the client largely determines the success achieved. The ability to respond to advancing insights during the RFP process enhances the quality of the selection procedure. Agility during the realization guarantees the development of a product that is in line with current needs and requirements. With this, the client holds the key to success.