The 9 Characteristics of the Ideal Agile Tender

Closeup of male hand about to sign a business contract with a fountain pen.

Does the traditional tender process still work if an organisation 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 short list) 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, 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 the tender itself.

Reorganise 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 dinscontinued 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

  1. 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, 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.
  1. 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 emphases a focus on value, quality, and the end user instead of dealines, budget, and scope. Because of this, the price and costs are related to the earnings.
  1. Make the Definition of Done part of the tender. Ensure the requirements necessary for documentation, test automation or code quality 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, quality will be guaranteed.
  1. Create the product vision and product backlog together with a number of suppliers. Invest a number of days 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 realiziation. 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.
  1. 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 mind set much better than traditional RfPs. 
  1. 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.
  1. 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). 
  1. 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 mark-up percentage for overhead expenses and a separate mark-up 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. 
  1. 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 on ‘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.

What experience do you have with a call for tenders in an agile context? Please share your tips & tricks.

One thought to “The 9 Characteristics of the Ideal Agile Tender”

  1. I worked large project executed with a traditional Request for Proposal (RfP). It was a detailed process involving a number of companies and the legal department. An important aspect was getting the tender correct according to EU Regulations so that a passed over bidder would not sue.
    I am interested whether anyone could share how an Agile Project was handled in such circumstances.
    Are there any reports of Agile Tenders being performed?

Comments are closed.