Are your project contracts setting you up for success—or holding you back? In this episode of Innovation Tales, we dive into how the fine print can make or break a digital transformation. You’ll hear two contrasting stories: one where rigid agreements lead to setbacks and frustrations, and another where agile contracts open the door to faster, smarter decisions.
We’ll look beyond the usual agile vs. waterfall debate and explore how the structure of a contract shapes the dynamics between teams and suppliers. Discover the power of collaboration and how an agile approach to procurement can turn uncertainty into opportunity, setting your project on the path to success.
The episode offers practical advice on structuring contracts that don’t just manage risk but actively build trust between all parties, fostering a collaborative environment where challenges are met head-on. Whether you’re a leader, project manager, or just curious about what makes some projects thrive while others flounder, this episode offers insights you won’t want to miss.
SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc. Please visit https://scaledagileframework.com to learn more.
Pega® is a trademark of Pegasystems Inc. Please visit https://www.pega.com to learn more.
—
Agile Contracts: The Secret Weapon For High-Stakes Projects
What do you do when time isn’t on your side and a competitor suddenly surges ahead besides a mild panic and an extra cup of coffee maybe? In this episode, we’ll see two ways to handle the unexpected, one that cracks under the pressure and the other that rises to the challenge with speed, trust, and adaptability. We’ll dive into two stories where the role of contracts becomes the unexpected game-changer, one that leads to frustration and setbacks and the other that opens the door to smarter, faster decisions. It turns out that being flexible isn’t just a yoga thing.
After the stories, I’ll also share references and practical advice on how to apply these strategies to your own projects. As a disclaimer, the stories in this episode are inspired by my own experience, but to protect the privacy of those involved and to under confidentiality agreements, they’re not exact descriptions of actual organizations. Instead, I’ve combined several projects into a fictitious tale with dramatic elements to illustrate this topic. Therefore, any resemblance with real persons or events is purely coincidental.
—
Echoes Of Innovation
The first story takes place at a large insurance company. Let’s call them Crestline Insurance. I’m involved in an audit of a project that is expected to deliver a Customer Relationship Management system or CRM for short. Crestline’s Chief Sales Officer, Emma, has this big vision. She wants employees across the country to cross-sell and upsell more effectively using a modern CRM.
Emma is always bursting with ideas. She’s that person sketching out new strategies during lunch, usually too excited to remember to eat. She’s focused on the big picture, improving sales, but she’s not paying too much attention to the details of how the CRM will fit with existing systems. Everyone feels that energy and the organization pushes ahead.
The Crestline team spends over a year drafting a specification, every feature and every integration, pages and pages of detailed plans trying to account for everything except for what happens once the project begins. When the request for proposals goes out, it follows the organization’s standard procurement processes and is therefore locked into a fixed scope.
System integrators respond, each one saying, “We can deliver,” but with long lists of assumptions buried deep in their proposals. The Crestline team is already stretched thin and doesn’t have the time nor the expertise to dig into every assumption. They choose a supplier and push ahead. It feels like progress, but with such a rigid contract, they’ve unknowingly tied their hands when things start going off-track.
With a selection made, the project is handed over to IT. Emma focuses again on her main goals, boosting sales and enhancing customer engagement, while the project team moves forward with the CRM implementation and organizes the work into a series of sprints. IT is used to rolling out off-the-shelf software or building custom software from scratch, but this CRM project is right in that tricky middle, complex but not quite custom and flexible but not exactly off the shelf. The project team gets to work. After all, it’s a simple task of integrating new software, adapting it to old systems, and magically making it work for thousands of employees. No big deal. It’s a plug-and-play deployment. What could go wrong?
As the project sails ahead, it keeps on hitting rough waters. Every few weeks, there is a new snag. A feature cannot be delivered as specified or an integration is far more complex than expected. The supplier, with no incentive to deliver more than the bare minimum, keeps on pointing to the fine print of their assumptions as an excuse. They offer workarounds that save them effort but rarely align with Crestline’s course.
It’s like trying to sail a boat that keeps bringing leaks. The project team keeps on plugging holes, but with each fix, another issue pops up. Instead of steering smoothly towards their goal, they are forced to spend all their energies trying to keep it afloat. The further the sail, the more distant the original destination becomes. The project is adrift, trying to navigate through a sea of change requests with the business still expecting to arrive on time. The rigid contract, which was supposed to chart a safe course, is an anchor weighing them down, making it harder to adapt as they face even more turbulent waters.
At this point, the project team begins demoing parts of the system to business users. The feedback? Not good. What they’re seeing doesn’t match what they need. The workarounds feel like patches that don’t address their actual workflows. Some of you will recognize the dilemma. You’re supposed to use the system, but no one’s asked you what you needed.
Users had expected IT and the supplier to dig into their day-to-day processes. Instead, they’re delivering a system that will be very hard to use. That’s when the audit kicks in. Crestline’s leadership realizes that the CRM, which is meant to transform their business, is becoming more of a problem than a solution. Confidence in the project starts to sink.
As the audit unfolds, Emma begins to reflect on how far the project has strayed from her original vision, which was intended to make Crestline more competitive. It was leaving the organization struggling with internal adoption and frustrated employees. Emma had trusted the process believing that by following the organization’s standard procurement procedures, they were reducing risk, but she wonders how they got so locked in. She doesn’t know exactly where things went wrong, but the rigid path left little room to maneuver.
Sitting with the audit team, she thinks out loud, “Why are all parties pulling in different directions?” The project is very far from the solution she envisioned. Emma is left wondering, “How could it have been done differently?” The audit findings are clear, but their impact is limited. They highlight misalignment between the CRM and business needs, pinpointing where the project went off-track.
They do provide leverage for Crestline to push back on the system integrator, but it is not a complete solution. Within the organization, the damage is already done. Crestline’s leadership is facing a stark reality. While the audit may help them negotiate contract adjustments, it cannot turn back the clock. They already have lost years and getting business users to buy in again is going to take a few more.
Imagine yourself in Emma’s shoes. You had a vision that promised to transform your company, empowering your team, boosting revenue, and giving you a competitive advantage. You trusted the process, followed the plan, and believed you were making the right choices, but as the project nears completion, the solution has become a source of frustration. Business users aren’t adopting it, and instead of praise, you hear complaints. How would you feel? You might start asking yourself, “Where did we go wrong?” Could we have changed course?” Deep down, you’d know those questions won’t change anything.
Let’s shift gears. The second story takes place in a completely different place. Shield Insurance Group is driven by an ambition to expand beyond its traditional model. Lucas has one of the company’s business units. He has his eye set on a new goal, transforming how they engage with customers. They’ve operated exclusively through partners, but Lucas wants to change that. He’s focused on building a new digital channel to engage customers directly.
Lucas is always on the move, whether it’s finding shortcuts at work or taking the stairs two steps at a time instead of waiting for the elevator. He believes there is always a quicker way to get things done. In the case of this project, he knows that speed isn’t just nice to have. It is essential. The market opportunity is there, but it won’t last forever.
As Lucas lays out his vision for transforming Shield Insurance, the real challenge is not technology. It’s convincing leadership and himself to take a gamble. Shield has a habit of taking its time with big decisions, often spending months selecting and negotiating with suppliers before a project can begin. That process gives them control, but Lucas knows that they have to move fast or competitors will overtake them. This is where the decision gets tricky and Lucas has to weigh his options. Stick with a slow careful approach or take the gamble, push forward, move fast, and shoulder the risks if things don’t work out?
When I first got involved in the project as a member of a potential supplier team, it was clear that Shield Insurance was looking for a different approach. Lucas isn’t interested in months of negotiations and detailed RFPs. Shield needs speed, but more importantly, it needs a partner who can navigate the uncertainty ahead. Early discussions reveal that delivering in sprints won’t be enough to address the challenge. We have to manage the unknowns collaboratively.
We pushed for an Agile contract, seeing that Shield’s requirements will evolve and that the market won’t wait. The Agile contract sets the stage for real-time adaptation without getting tangled in legal red tape. Lucas understands that while the project won’t be predictable, the right contract will keep us aligned and moving forward. That’s why we were selected.
An agile contract sets the state for real-time adaptation without getting tangled in legal red tape.
Things are moving along smoothly until early customer tests reveal an issue. Shield’s products are too rigid and the lack of customization options means that some customers aren’t seeing how they could fit their needs. It’s a bit like buying a great-looking pair of shoes online only to find out when you try them, they’re a bit too tight. They look good, but if they’re not comfortable, you’re not going to wear them for long.
That’s exactly what’s happening here. Customers like the products, but without the ability to adjust coverages and premiums, they have to look elsewhere. This wasn’t part of the original plan. Adding product customization isn’t going to be a quick fix, but without it, there’s the risk of not attracting enough customers. The challenge is to adjust the project scope without throwing it completely off-track.
With the realization of how critical that capability is, you might expect the usual response, months of negotiations, and long meetings. We don’t need any of that. Why? It’s because we set up things differently from the start. When you have an Agile contract in place, things flow a lot smoother. Instead of going back and forth endlessly or getting caught in red tape, we sit down with Lucas and his team.
The conversation is simple, direct, and focused on solving the problem. We quickly agree to prioritize product customization and find a feature that can be postponed, something that is less crucial for beating the competition to market. It’s the kind of dialogue you can only have when both sides trust each other. The contractual framework lets us make decisions that keep the project moving forward with minimal risk and no wasted time.
Everything is on track, at least we think it is. We are well into our final stretch, checking off milestones and feeling like we’ve got this in the bag, but then, because no project worth telling ends without one last curveball, a competitor unleashes an aggressive marketing blitz. Everywhere we look, there they are, whether it be Google, Facebook, Instagram, or probably even Yahoo for all we know. We feel the pressure building. Shield needs to act fast or risk being drowned out by all the noise. The team has been moving at a solid pace, but the question isn’t about finishing on time anymore. It’s about finishing fast enough to stay competitive. With a competitor’s marketing blitz in full swing, Shield needs to accelerate.
Lucas reaches out to us. We work out a plan with the second team to speed up delivery. Thanks to the Agile contract, we have a built-in mechanism to adjust capacity, and there is no need to waste time in legal negotiations. Lucas secures the additional funding easily with leadership feeling the pressure from the competition. With the extra resources in place, we fast-track the remaining work right on time to be the first ones to market.
Agile Contracts: Thanks to the Agile contract, we have a built-in mechanism to adjust capacity, and there is no need to waste time in legal negotiations.
In the end, everything comes together. The Agile contract, the trust we’ve built, and the ability to adapt quickly make all the difference. Shield launches its direct-to-consumer channel right on time. Lucas’ business unit doesn’t just keep pace, but it pulls ahead, offering customers product customization and flexibility that the competition cannot match. For Lucas, it’s not about getting the project over the finish line. It’s knowing that the decisions along the way have all paid off. The solution goes live, and all the pressure, the sleepless nights, and the risk he has taken have led to something real.
What a contrast with the earlier story where rigid planning left Crestline stuck, unable to adapt when things went wrong. Shield’s story shows what happens when flexibility drives success. Here, being able to adjust course doesn’t just keep the project afloat. It’s what gives it the edge. If you enjoyed these tales of innovation and want more practical advice on navigating digital transformation, make sure to tune in to the show. We’ve got plenty more to share. Your support helps us bring these insights to an even wider audience.
When flexibility drives success, it gives the edge to any business project and keeps it afloat.
—
Blueprints Of Innovation
Let’s take a few minutes to define Agile contracts. Many of you, I’m sure, are familiar with Agile methods in order to deliver technology or other types of innovative projects within your organizations with or without suppliers. Often, agility is limited to the team that does the delivery. The rest of their organization, including procurement, follows traditional standard processes.
Often, we’ll see contract types that fall into 1 of the 2 extremes of a spectrum that we can visualize if we think about who is taking more of the risk, the client or the supplier. On the one hand, organizations will sometimes invest months or years to specify their requirements and then have maybe an RFP process where suppliers will bid and commit as a result to a set of requirements, like schedule and costs.
In this case, at least in theory, most of the risk is borne by the supplier who has to absorb any unforeseen complications. On the other end of the spectrum, we’ve got contracts executed on a time and material basis or hourly projects where the client can make changes to the scope at any point and doesn’t have any commitment from the supplier to how much the overall project will cost them.
The trouble with both of these extremes is that those contracts create tensions between the client and the supplier. In the case of fixed-price projects, there is an incentive for the client to ask for as much as possible when, for example, interpreting the specifications. It’s the opposite for the supplier who very often will, in their response, provide a number of assumptions and will then try to reduce the amount of effort they need to spend to deliver the scope throughout the project. There is constant tension during the project.
The same applies to time and material project contracts. For the supplier, the incentive is to keep the project going for as long as possible. The client often doesn’t have any kind of visibility that would enable them to trust the supplier long-term. Whatever trust might have been there at the beginning gets evaporated with time.
In contrast, Agile contracts are designed to foster trust between the parties and motivate them to build the best possible solution within the agreed-upon economic boundaries. Consequently, they must provide a number of outcomes. Specifically for the supplier, they need to have confidence for the short and medium term that they’re not going to end up with a number of resources, but no project costs that they cannot recover. Whereas for the client needs ways to manage risk and exploit variability when new information becomes available.
An example is the managed investment contract from SAFe. The Scale Agile Framework. In this model, the first thing that both parties commit to is the contract model. In essence, defining the principles and the approach that both parties will follow throughout the initiative. Both parties will also collaborate on establishing an economic framework or making explicit assumptions about the solution, the product that must be created, and how it needs to perform in the real world. That leads to the definition of a minimum viable product that can be delivered quickly in order to validate those assumptions.
The definition of such a minimum viable product in the pre-commitment phase strikes a balance and avoids the extremes of the fixed price or time and material projects. It gives the client enough clarity about what is going to happen in the coming weeks and how those actions are going to help them reduce risk and understand whether they’re going to be able to identify a product market fit.
This pre-commitment phase typically takes only a few weeks compared to months or years typical for fixed-price projects, at the result of which both parties can move to executing which proceeds iteratively where sprints are organized into program increments, which typically are ten weeks long. While parties can choose to have longer or shorter program increments, the important part here is to have regular checkpoints where progress is objectively measured and any course corrections that must be taken can be taken.
This transparency creates the incentive for both parties, not just the customer but also the supplier, to ensure that they’re doing their best to move forward to create the solution that will, in fact, deliver value. Otherwise, simply, the project will not be a very long-lived project. If progress isn’t being made, it will become apparent very quickly and funding levels will simply drop. In summary, Agile contracts are simply an extension of Agile methods to procurement to ensure that the contract is a vehicle to build trust and support the Agile principles applied to delivery.
—
Innovator’s Playbook
In this third and last segment, I’ll share some practical advice regarding procurement and Agile contracts. I’ll start with risk. Often, when we are doing innovative projects, there is a tremendous amount of risk because there is so much unknown about what the market may need, what the competitors might do, and so on. It’s almost, by definition, that if we were working on a project where risk or uncertainty was low, it simply would not qualify as an annuity of the project. It will be more business as usual, maybe some sort of migration or something like that.
If we are doing projects where we are working on something new, like in this episode we’ve had two stories where 1 was a CRM implementation and the other 1 was going to market through a new channel, those qualify as risky and adventurous because it’s not clear how the market will react, how the users will react, and whether the technology supports the vision. There’s also the risk because the actors may not know exactly what the technology is capable of or the technology may move forward even while the project is underway.
Under those circumstances, I do not believe that it’s possible for a client organization to outsource its risks to the supplier, especially when it comes to feasibility and scope risk. The reality is that suppliers, such as systems integrators, will be very good at managing this risk on their side. They have an economic incentive to do that. Also, they have experience since they’re doing these projects day in and day out. Every employee and every team will have delivered a number of these projects, so they will know what to expect. When they’re responding to an RFP, that list of assumptions isn’t an accident. It is a very critical piece of ensuring that a system integrator remains profitable.
For the customer, it is almost impossible to anticipate how those assumptions are going to play out. There is an imbalance in the knowledge and the experience. The customer is doing maybe a CRM project for the first time in years whereas the system integrator, it’s their 5th or 10th this year, so this negotiation is not fair. In the end, very often, it’s the customer who is going to pay the price, not necessarily financially because they might be able to go to court or something, but they will have lost those years of struggling through this project.
The best way to manage risk is to use those minimum viable products. One way to do that is with the lean startup approach. It is where you explicitly identify the assumptions that you’re making about the market, customer needs, technical feasibility, what the competition will do, and so on, and you rank them starting from the one that’s going to have the most impact if it turns out to be false. You build those experiments to validate or invalidate. Each of these experiments is going to be a minimum viable product. I don’t have time, unfortunately, to go into more detail about the lean startup. Maybe that’s something I will do in a future episode.
My second piece of advice relates to how Agile is often perceived as the methodology for the development team, maybe because they need to run sprints or something like that. The problem is the rest of the organization may be using completely different methods. There will be a lot of clashes between the rest of the organization and the development team.
Instead, I recommend considering trust as a project resource. What do I mean by that? The ability of a customer and the supplier or their suppliers to trust each other and collaborate long-term is, to me, one of the key factors to be successful with an innovative project. While it is important to recognize that even if your team executes in an Agile way and does reviews, for example, and system demos to provide transparency, they will still end up with conflicting interests if the contract under which they execute creates a win-lose situation.
For example, a time and material contract can be very dangerous for a supplier because overnight, the project could stop and they might end up with a number of resources on the bench, leading to a drop in their profitability. It’s important to manage that explicitly through contracts and ensure that, on the one hand, the supplier can rely on a stream of work they can commit good resources to and that will lead to a number of positive outcomes, especially the quality and expertise of these resources. On the other hand, the same contract needs to ensure that the customer doesn’t get locked in, and when changes are necessary due to new information arising, the contract does promote and exploit the variability.
My third piece of advice relates to how you implement Agile contracts. From my experience, the main reason why Agile contracts are rarely used is simply because most people in an organization are unfamiliar with that particular type of contract. As a result, during the initial phases of the project, it’s so much easier to go for a request for proposal and a fixed price or maybe a time and material because there are going to be templates available.
People are going to know and expect that this is what projects do. It might even be required from all projects by a project management office, for example, to use a specific template for their contracts. This is where there is an opportunity to create value during those initial weeks of an initiative. You can work with stakeholders and explain to them the benefits that you’ll get from an Agile approach that goes beyond the sprints and reviews that the development team will perform.
Let’s start with procurement. Why would the procurement department be interested in making the additional effort to implement a new type of contract for your project? The main reason would be that delivering an innovative project is quite different from most of the services and products that the procurement department usually acquires for the organization. Therefore, there is a tremendous amount of risk that they will have to deal with which slows everything down and takes a significant amount of time for them when they’re preparing the contracts and even more time later during execution if you end up with dozens or hundreds of change requests.
The chief financial officer might be another stakeholder who might be reluctant at first to consider a new type of contract. For them, it’s important to highlight the way that you’re managing scope creep and the financial risk that is associated with it. Compared to time and material, there is much more visibility, and compared to a fixed price, the main benefit is your ability to exploit variability.
If you are going through the project and you’re discovering that circumstances have changed, you don’t have to spend resources because you committed to them a year or two ago. You can re-adapt to the new conditions and potentially deliver more value with the same or fewer resources. Last but not least, let’s talk about the business stakeholders or the people who are going to be using the solutions. They’re often the ones paying the price when tensions between customer and supplier arise. Any improvements in collaboration, shared responsibilities, and trust are going to be an enormous win for them.
When circumstances change in the middle of a project, learn how to adapt to the new conditions and deliver more value with the same or less resources.
In summary, when working on innovative projects, uncertainty is not going to impact the development team. If you are the sponsor or maybe a manager responsible for the delivery of a new solution, take some time and explore how Agile contracts will make your life easier. We explored two contrasting approaches to digital transformation, one that struggled with rigidity and another that thrived on agility and trust. We broke down the challenges of procurement and the importance of adapting quickly in a fast-moving market. You can rate and review the show in your favorite app. We look forward to your feedback. In the meantime, we have more episodes lined up, so stay tuned for more tales of innovation that inspire, challenge, and transform. Until next time, peace.
Important Links
Enjoy New Shows
More from this show
Explore
© All Copyright 2024 by Glaukos Digital OÜ