New book about (agile) tenders and contracts

Western and US car manufacturers are being disrupted by Tesla and Chinese e-cars, banks by fintech (Revolut, ETF robots investment, crypto and others) as well as technology companies (e.g. Apple), Uber and Uber-like services disrupt traditional taxi and delivery services, and we can continue with many other examples. Disrupted corporations need to become software or digital companies as software is in the core of disruption. Some companies are aware about this, some are already on their journey.

Imagine complex digital product you use frequently, let’s say your mobile banking app. This digital product is composed and operated by dozens of software systems. These systems are quite often coded, and even operated by various vendors and the Intellectual Property Rights (IPR) are owned by them too. If the company needs to apply bigger change, it needs to run several tenders where these vendors compete. Just for one bigger change!

Only to run so many tenders bring extra complexity to already complex situation and slows down the whole process of product evolution. To tender larger change can take from several weeks to many months, no development included. And what if many changes like this appear? Instead on 6 months of development work it can take you years to just start the work (including all the preparation time, budget discussions, and internal decisions). Only because of this complex vendor setup, not talking about old legacy systems, architectures and technical debt…

To organize traditional tender for each bigger product change is not the way to compete with nimble disruptors.

The need to significantly speed-up the tenders and simplify the vendor structure is obvious. Same is the opportunity for insourcing the knowledge and IPRs internally with intention to build digital ability in-house, at least for frequently changing core parts.

Agile tenders with agile contracts can be the transition mechanism here that allows you to speed up product development and insource the IPRs.

Second reason for writing this book is agile movement becoming commodity. It’s being considered as a prevailing delivery model that helped many companies to better respond to changing market conditions and customer needs. We could see it mainly in covid times, followed by supply chain problems, and energy crisis to name a few situations in the past years. Very few company prepare their plans and strategies for these scenarios, therefore they needed to quickly react and adapt.

Typical attempts with agile thinking start in small isolated islands all around the company. It often comes up from IT teams with idea to join all IT delivery roles. Later, it continues by integration of business roles to delivery teams, creating virtual or even stable co-located teams. These changes usually help locally as they connect the development roles with business roles and start to understand different languages and co-create. However, this is not helping company at all as it just improves one small piece of the whole value flow, just the delivery or build part. The whole flow covers also ideas gathering and validation, connection to strategy, prioritisation, discovery work, risk assessment, integration, deployment, pilot deployments, or even tenders in some cases.

To gain the real business impact that can be measured by business numbers on the product or company level (improved revenue, quality, time-to-market, retention, innovation, …) the agile effort need to cover the whole flow how value is created around the company, not just the delivery part of it. The delivery part can make just 10-20% of the whole value delivery process. This is the reason why devOps movement or product discovery are so popular and successful as they cover broader context with more visible business impact. But neither those cover the whole value delivery flow as shows the picture.

One aspect fitting into the whole value delivery flow is cooperation with the 3rd parties. If company or 3rd party vendor follow agile principles in their way of work, tenders, contracts, collaboration routines and communication need to support it as well. And here is the right place for agile tenders and agile contracts.

It is very hard to provide digital products or solutions in an agile way under the traditional contract that specifies the details of product or solution upfront. Traditional models of contracts hinder valuable changes learnt on the way. 

The same is valid also for traditional tenders with decision making based on “paper work and paper proofs and promises” (known as RFI and RFP phases of tender). It needs to change to reflect lessons learnt on the way and incorporate real work experience and validation. How can you know the cooperation will work, if you just met the person, asked for documents and promises, but don’t have a real hands on experience? Ok, references can help, but it is not your experience in your context.

This book gathers practical experience from agile tenders and agile contracts and provides it in form of guidance, templates and stories. Applying these principles and methods can help you to speed up changes of your complex digital products and can be a means for insourcing some of the product implementation knowledge and IPRs.

Content excerpt:

• Traditional tenders
• What is agile tender about
• Important roles involved
• Build-in benefits of agile tenders
• Preconditions and building blocks of agile tenders
• Pay vendors for their effort
• How to prepare and run agile tender
• Templates, banking case study
• Context for agile contracts
• How are agile contracts constructed
• Agile contract template

For whom is the book recommended?

• procurement managers and team members – to speed up the tender and choose the right vendor
• product owners and managers – to speed up the product evolution if more 3rd party vendors are involved
• software vendors – to build trust and better cooperation with clients and to teach the market more relationship-based forms of tenders and contracts
• agile coaches interested in spreading agile principles among the whole value stream

The book is available as ebook or paperback on Amazon (84 pages, EN).

Shipping note: If you are from Czech republic and want to order just this book on Amazon the shipping costs can be quite high. In this case, just let me know, I have author copies and can bring it personally to Brno, Prague or in some place in Beskydy or send via Zasilkovna in Czechia and Slovakia.