Switching your contracts from waterfall to duration and price can completely change how you manage a project. No longer will you have to manage exact hours and exact timelines, but you can focus on communication and completing the highest priority work for the client. When you are delivering the highest priority work for the client, this leads to greater client satisfaction, and less debate around what needs to be delivered from a contractual standpoint. Put simply, Duration & Price contracts prioritize client collaboration above contract negotiation and leads to great results.
- Type of Client Company: Financial
- Type of project: Application
- Cost range: $500,000 – $900,000
- Timeline: 1 year
- Methodologies: Agile/Scrum
- Team size: 5 – 7 (varying durations and allocations)
- Team makeup:
- 2 FTE Developers
- .5 FTE Test Engineer
- .25 FTE Designer
- .25 FTE Product Strategist
- .25 FTE Product Manager
We Started With A Prototyping & Validation Engagement
We’ve all seen the look. You have a potential client come through the doors for an initial engagement. They’re not sure what they need yet, but they know they need something different. In this case, our client knew that they needed to either completely rehaul their existing system to accommodate their growing business needs, or come up with an entirely new solution to replace the existing system.
Rather than trying to sell them a big product team right out of the gate, we recommended a Prototyping & Validation engagement in order to start projects off on the right foot with clients.
At our agency, we use Prototyping & Validation engagements to undertake a form of project discovery—to determine what to build and if the market or users will respond to it.
Here’s What We Include In A Prototyping & Validation Engagement
- We usually include a Product Strategist, Product Manager, and Designer.
- We produce high-fidelity clickable prototypes (we skip wireframing and go straight to this stage, as it helps speed up the process).
- We do user testing (finding groups of users to validate or invalidate our prototypes so that we build the right solution).
- We undertake a market validation process (in the case of this client, we didn’t need it, but we do this to ensure there’s actually a market out there willing to buy a finished product).
- For this client, we also included a technical audit to determine if we could use their existing system rather than build a completely new one.
Throughout this engagement, it became clear that they were in great need of an entire suite of products to solve their problem—a problem that included a legacy system built on an outdated codebase and framework in a way that was not extensible beyond its original intent.
Next, We Introduced The Duration & Price Contract
Switching from waterfall-style contracts can be tricky. It’s one thing to determine whether you should use agile or waterfall methodology for your projects, and it’s another thing to package this up in a way that makes sense to clients.
Introducing Duration & Price contracts can create a difficult conversation at the beginning, as it’s our job to convince clients that have never worked in an agile environment that this is the way to do it. What helps us most in these conversations is that we have solid examples of this working well, time and time again.
We knew going into the project that there was at least 7 months worth of work. We also knew that we’d need at least two full-time Developers along with a half-time Test Engineer, a quarter-time Designer, a quarter-time Strategist, and a quarter-time Product Manager.
However, even knowing the team makeup, the bigger challenge was explaining how a Duration & Price agreement would enable better progress towards their goals than a fixed scope contract. For clients that haven’t participated in a software project to this degree, it can be difficult to explain the benefits of flexibility, communication, and frequent assessment of priorities as things inevitably change.
Here’s What Happened During Project Implementation
The main goals of our initial 7-month engagement included critical fixes for their current system, prototyping, and product development.
Prototyping And Critical Fixes
We began with prototyping, as well as critical fixes to their existing system. Our team shifted to whatever was the highest priority: at first, this included critical fixes, but then quickly pivoted to the development of the product the client actually hired us to build.
The first portion of the new product we built was something that could be released on its own, without any dependencies. This would give us time to figure out the dependencies so they would be resolved prior to development. Shortly thereafter, the client determined that rather than finding another vendor to resolve one of those dependencies, we should build it. We agreed and reiterated that they occupied the “driver’s seat” of their team and that we go where the priority lies.
Untangling The Existing Business Logic
In this project, we vastly underestimated how much business logic had to be untangled by the client prior to us being able to finish this portion of the product. While we would normally build these solutions from the ground up and work with the client to determine the business logic, in this situation, there was extremely specific business logic that had to be followed so that their business could continue to run as needed.
Once the client finished outlining this business logic, we were in business (pun intended). We knew that we could knock out the rest of the product within a matter of a few sprints.
Then, we got some news that changed everything—just as our initial engagement was coming to a close.
Dealing With A Big Surprise
We were nearing the end of our engagement and feeling confident. We had one portion of the product complete, and we were on track to complete the next portion within a couple of sprints.
Then, we got the news that their existing payment vendor was pulling the plug on their system within a couple of months. While this wasn’t a big deal for the new product, as we had found a new payment vendor, it was a huge problem for their existing product, as everything was intricately connected to that product.
As I said earlier, we go to where the highest priority work resides. So, we agreed to help resolve the new issue as quickly as possible. The timing was tight, but based on the original requirements, we’d still make it.
Unfortunately, we all underestimated how interconnected their existing system was with their payment provider. There were a lot of edge cases that were unaccounted for and scenarios that were less than ideal to develop within an archaic codebase. This led to a lot of back-and-forth between us and the client to determine the best approach for this work.
Overall, this took much longer than originally anticipated, but it led to the best result: client satisfaction. Had this been a fixed scope, it would have been difficult to renegotiate & adjust to meet the necessary shift. We helped them out of a tough spot, and were only able to do so within our (freshly renewed) Duration & Price contract because it enabled significant flexibility.
Overall, here’s the big picture of what happened during this project. It’s helpful to look at what we anticipated in the beginning versus what actually happened:
Here’s a timeline that illustrates the main events in the project, showing our original plan along with the developments and pivots along the way.
Feedback From Our Client
While we (and the client) underestimated the amount of work involved in decoupling their existing payment provider and integrating a new payment provider to the spaghetti code that is their original system, I feel confident that it led to the best result: client satisfaction. We were able to pivot quickly and help them out of a tough spot due to the flexibility in our Duration & Price contract, which actually helped us develop a deeper sense of trust in our client relationship. The unfortunate side effect of this work was that it took us away from the much larger goal. This goal was to replace the system that caused this problem in the first place, so that when vendors change in the future it doesn’t cause as much disruption, whether we’re involved or not.
Even so, we (the client and our team) do feel like our goals have been achieved. While these goals have changed over time, I can confidently affirm that we have gone where the priority lies within any given sprint. This comes with ups and downs, as these are nuanced things that require you to justify why certain expectations haven’t been met. Since we were able to work with the client to help them understand that we’re all in this together as one big team, it worked out well. If they win, we win. If they lose, we lose. They knew that we had their best interests in mind.
Feedback From Our Team
Since the contract isn’t waterfall-based, it takes the contract out of the conversation and shifts the team’s focus. That allows for more room to do what is right—not what is required by a contract. It gives the team, and specifically the Product Managers, autonomy to do what they do best. They’re not constantly referring back to an outdated contract, managing timelines that can’t be met, and going over budget.
Additionally, this kind of contract structure really helps with overall team health. I’m not breathing down the necks of the production team to deliver based on exact requirements. Instead, they get to focus their time on being the professional for their craft and delivering the best solution to our client. This really helps with morale, as they feel a lot of ownership in what’s delivered on a sprint-by-sprint basis.
While this engagement was a success, it came with its own set of lessons. So, if you’re thinking about providing a client a Duration & Price contract, make sure you learn from me on the following points:
- Spend time educating your client. Make sure your client understands what it means to be in the driver’s seat, and don’t forget that you sometimes have to be a backseat driver.
- Get to know the existing system. When replacing an existing system with no documentation, find the people who know the system and have them explain how it works (and document the heck out of it!).
- Take time to explain changes. It’s critical that when priorities change, your client fully understands the implications of those shifts.
- Deliver consistently. Regularly deliver artifacts to your clients, such as updated roadmaps and release and/or epic burndowns.
- Trust your gut. I you feel like you’re not on the same page, chances are, you probably aren’t.