Agile procurement and procurement of agile projects

What makes a project successful? We believe it’s the exchange between the parties involved, i.e. the purchaser and the provider, mutual attempts to find common ground, and clarifying questions on both sides. Agile processes expressly promote and demand this kind of intensive exchange. So why shouldn’t we promote and demand this in procurement too? What’s stopping us from channeling our energy into mutual dialog to gain insight and understanding on both sides, instead of wast­ing it on long catalogs with innumerable specialist and technical specifications?
Nothing, in our opinion. The focus in pro­curement should change, so that purchasers and providers can get to know one another as early as possible, and learn together.

Agile – a buzzword
The Cynefin model by Dave Snowden helps to place the term “agile” into context with four categories: “simple”, “complicated”, “complex”, and “chaotic”. Problems that have never been solved, where the best-possible solution remains unknown, go in the “complex” category. The journey is the solution in this case, or at least a part of it: ideas are tested out iteratively, leading to new findings, which are then tested again until you reach the desired situation – agile, in fact. Other approaches, such as plan-oriented approaches, are more suitable for “simple” problems.
But what does agile mean in a procure­ment context, and how does that fit into a public law environment where plan-oriented mindsets tend to dominate? The combination of agility and procurement leads to two terms, and you have to be aware of the difference:
“agile procurement” and “procurement of agile projects”.

Agile procurement is where you follow agile principles and methods in procurement. It is characterized by open dialog between purchasers and providers, and by short learning cycles. It focuses on attaining the determinable (for example, a minimal viable product — the first version of a product to work on a basic level), while also regulating future interactions with the unknown, so that all parties gain mutual commitment. This is a key point, which differentiates it from plan-oriented procurement. Agile procurement needs agility to play a key role in the purchaser’s working method even before the procurement itself – in terms of identifying their own requirements, creating procurement documents, and in evaluation. And of course this also encompasses post-procure­ment, during the actual implementation of the project.
The procurement of agile projects, on the other hand, describes the type of procurement in which a complex good or service is to be implemented with the aid of an agile process such as Scrum. This requires a contractual framework permitting commercial activity, with the desired agility (which comes with a certain amount of uncertainty). These cases do not require agile procurement, but it is helpful. In these kinds of complex procurement cases, it is almost impossible for the purchaser to be aware of the best solution or approach for their problem in advance. In this case, the intellectual efforts and accomplishments that lead to the result, such as creativity and innovation, are more important than the result itself. In most cases, the goal is therefore the procurement of agile projects.
In practice, the two concepts “agile procurement” and “procurement of agile projects” tend to intermingle. That’s when we talk about complex procurements, because the actual challenge for the purchaser lies in the fact that the best solution or approach for their problem cannot be identified in advance. In these cases, the intellectual efforts made by the provider, i.e. their skills, play the pivotal role. That’s because their services are based on their creativity and power of innovation, as in software devel­opment. In our view, it is therefore only logical if the whole process from procurement to project is agile. This is the only way to integrate agility properly from the outset, and to work out and implement the future solution using agile methods.

Focus on cooperation
If the solution to the problem is unknown and the end product therefore cannot be more precisely characterized and described in a catalog of specifications, how do you attain the desired assurance that, at the end of the procurement process, the product developed will solve the problem? By directing the focus of procurement not on the best approach, but on the most suitable partner! Developing the solution iteratively is a mutual undertaking, requiring plenty of communication and collaboration. And it usually works best when all parties share similar ways of working, ideas about what collaboration means, and values. In a procurement process under public law, there are lots of provisions that must be observed in order to ensure fair competition. So it’s not always easy to interact with the various providers before finally awarding the contract. Despite this, there are more possibilities out there today than are actually used. Moderated forums, with all providers present, can be held to clarify outstanding issues and have questions answered more quickly. Instead of merely being a stage for providers to make their presentations, these events can also carry out assessments or even proofs of concept (PoCs) to ensure that the providers’ problem-solving skills and approaches are clearly apparent. They also provide an opportunity for dialog (including dialog between competitors). To improve mutual understanding and problem-solving, this approach can be employed early in the contract-awarding process. We think this is an excellent opportunity to experience “cooperation” even at the procurement stage. Contrary to popular opinion, the dialog doesn’t have to be heavy-handed and isn’t only suitable for large projects. We’ll be more than happy to show you how.

Focus on cooperation – including in the contract
The principal element of a contract designed to promote – and demand – an agile approach is the rules of collaboration: cooperation. The focus is on building trust by jointly discussing, working out, and
defining the rules of the collaboration, such as desired conduct, how to deal with uncertainty, and risk distribution. As agile procurement takes an iterative approach and the work to be developed only takes shape over time, a customary contract for services is not applicable here. Instead, a shared vision of the solution, quality features (for example, DoR, DoD), price/performance measures (for example, price per story point) as well as the rules of the collaboration are defined. Each individual iteration (or sprint) can set out what should be developed. On this basis, it is possible to conclude a so-called “mini works agreement” for every iteration.

Agile procurement and procurement of agile projects with the agile agreement
The agile agreement is a framework that brings together all our knowledge of agile procurements. It regulates the three phases of a holistic procurement process (see diagram) and contains planning elements and templates such as qualitative criteria and evaluation methods, instructions for carrying out provider assessments or PoCs, models for pricing agile projects, or even entire framework contracts for agile development and operations.

ti&m special e-government
What about the digital transformation of the public service? In our magazine ti&m special, we asked further digitalization experts from politics and government. to download