Let’s run through an all-too-familiar scenario
A prospect goes through the agency sales process, is qualified by the team, and lands in the lap of you, the project manager. You read through the scope of work that’s been generated (not to mention, signed) to find out that a tall order has been promised. In this scenario, let’s assume the SOW states that a feature-specific MVP is going to be built within three months of the start date.
However, things come up. Priorities change. Curveballs get thrown. Now, you have the unique pleasure of mitigating all sorts of challenges, juggling change orders, and ultimately trying to do everything in your power to make sure the client is happy and the agency remains profitable. Since all project managers are superheroes in disguise, chances are you will get everything sorted out, but the tightly fixed scope they were up against certainly doesn’t help.
What if I told you there are ways to approach your contracts that would diminish some of the nail-biting stress and allow the team to do their best work?
Our shift to the "Duration & Price" contract model
In this article, I’m going to be describing a type of contract that our product development agency has adopted over the last few years that we termed a "Duration & Price" contract.
After shifting to this type of agreement, we’ve been able to operationally support our agile methodologies and focus on the value and results of a project, rather than the minute details that are often listed in other types of SOWs.
What we’ll cover:
- Duration and Price Contracts — What are they?
- Additional Context
- Implementation Considerations
- Getting Buy-In
- Benefits and Drawbacks
- Relation to Other Types of Contracts
- Words of Wisdom from the COO
The goal of this article is to help you understand another way to structure agency contracts that help to drive results and revenue to the bottom line.
Duration & Price contracts — what are they?
Duration and Price is a term we coined that describes our go-to method of doing business with our clients. With Duration and Price Contracts, the project cost is determined by the duration of our team members’ time on the project. We’ll dive into more specifics later.
Remember reading the agile manifesto and seeing that part that says: “customer collaboration over contract negotiation”? That’s where this all began for us.
After 6+ years of fixed scope, waterfall contracts, our team was leveraging agile methodologies to build products more and more. We wanted to create a better agreement for us and our clients that were supportive of our collaborative culture and focused around the value we were providing to the client teams we work with. We knew there had to be a better way than listing out specific deliverables or clear-cut features before the product was even underway.
After some research, our team realized we needed to create a pricing structure that allowed us to be flexible while also defining what a client is purchasing. If our clients are ultimately buying access to our team members, then why were we trying to be measured by a list of specs we could expect to change?
That's when we started to hone in on this idea of a dedicated product team, or a set of individual roles that were committed to a particular project over a span of time.
We started to experiment with some language that supported this idea and provided clarity to our clients. We wanted them to understand that the product team they will be working with to accomplish their objectives can do so without being tied to a specific scope.
This can happen because we are negotiating the scope along the way with our clients. They’re paying to work with a team for a duration of time. The price is derived from the number of team members, in varying levels of dedication, for a set amount of time.
Breaking down the two main elements
Thus, the name Duration & Price Contracts came to be. To our clients, we call them Engagement Summaries, but we are familiarizing them with the “Duration & Price” terminology along the sales process until the deal closes.
Breaking the elements apart, it looks like this:
- Duration is the length of the engagement from the authorized start date to the termination date.
- Price is the fees associated with the project engagement, determined by weekly rates of production team members
Some additional context
This didn’t happen in a vacuum. We looked heavily to other product shops we admired to get inspiration. The team at Hanno has always been a source of inspiration for us. Their model was available online at the time, and they plainly listed that they have a “sell people by the week” approach. This dead simple strategy stood out to us because it aligned with our concept of dedicated product teams.
This also didn’t happen overnight. There was a lot of trial and error in terms of getting the language right, figuring out how and where to infuse it along the sales process, and — obviously — how to execute on it once we landed the deal. We wanted to push ourselves to change and get to a brighter point because fixed scopes were causing us to soak overages for months and sometimes tied our team’s hands to do their best work.
An example of an experience with a past client
While we were experimenting with more agile language in fixed scope agreements, we started meeting with a prospect called tilr. They were an emerging startup at the time, working to disrupt the hiring space. We engaged in a 3-day strategy session with them that resulted in rough wireframes as well as 100+ user stories.
They wanted to move forward with full development for web and mobile platforms, but we didn’t feel comfortable scoping out everything into a fixed contract. It’d be a complete finger in the air, and that didn’t feel like the best way to start out a new partnership with a group we were really jiving with.
Internally, we tried to come up with a way to ship a contract that was bigger than anything we had done before without doing a full discovery process. If there was ever a perfect time to leverage a Duration and Price Contract, it was then.
After identifying how long we’d want to design/build/test this brand new product and the team members that would need to be involved, we pointed to the user stories as our basis to get started. We made it clear that the tilr team would be paying for the team’s agreed-upon level of dedication — not for the scope.
How that experience went with "Duration & Price"
Don’t get me wrong — there was some internal debate about this approach. Some recommended we engage in a full discovery to narrow down and specify the scope, but others feared that would make them walk away. We wanted a long-term relationship with this client.
Eventually, we all agreed and we shipped off our first full Duration and Price Contract right before Thanksgiving 2015 and crossed our fingers for the best. It was a leap of faith, and honestly, it went against some of our conventions at the time.
Once it was in the client’s court, there were some subsequent discussions with their team and a fairly intense legal review that took a couple weeks. This process allowed our team to walk through the contract time and time again, tightening up the language and polishing the whole approach.
In hindsight, it was a good thing. We felt like it brought three important things together:
- What our clients wanted
- How we wanted to manage ourselves
- How our culture operated
And guess what? It worked. They were a client of ours for almost 3 years.
Considerations for implementation (for agencies)
The number one recommendation I can give to prevent the potential pain associated with these kinds of contracts to involve project management in the sales process. In addition to the production team members, they’re going to be the ones in the weeds making sure that what’s scoped and promised can actually get delivered.
If PMs are left out of the sales process, it usually results in less than optimal contracts where details are missed and expectations are mismatched. Ain't nobody got time for that.
Additionally, when implementing this type of contract, make sure to put processes and conversations in place so the client doesn’t think they’re writing a blank check. We're careful to make sure these agreements don’t insinuate that we don’t know what we’re doing. On the contrary, we still invest quite a bit of time up front to identify what and how we’re going to get the work done.
Before we go into some brass tacks, I should also mention that you need to ensure your MSA or other existing agreements are audited to support this type of working relationship. This is vital in ensuring you can operationalize an agile contract.
What the proposal looks like
After we’ve vetted that an opportunity is qualified, we’ll create the first draft of a proposal that reiterates the engagement description, what a client’s goals are, and how we would structure the team around the objectives. This is a working document we end up editing a few times with the client team.
We want to get a sense of whether the budget is in alignment, as well as the timing, and other specific details. Typically, we’ll start with a 4-6 week engagement where we are creating high-fidelity prototypes of products to test & validate assumptions. Meanwhile, our technical team is planning the tech stack and investigating any integrations and 3rd party tools we’ll need to leverage.
Once we’re on the same page, we use PandaDoc to deliver all of our contracts. We’ve set up a template for our team so that we can easily spin up a duration and price contract when we’ve gotten the green light on the proposal. It’s intentionally simple.
Ideally, all of these highlighted sections — or “tokens” as PandaDoc calls them — will have been identified before we begin contract development. We’ll fill in each section with the overarching goal we are aiming to achieve with our clients and elaborate on the approach we will take to get there (i.e. 2 rounds of user tests, 3 months of product development sprints, etc.).
Then, we lay out the team members and levels of dedication each of them will have throughout the engagement. In this example, I used a 12-week engagement with a full product team in varying dedications with a $100/hour blended rate. It’s easy to play around with this and see how dedication, duration, and rate impact the price.
In the spirit of transparency, I should also mention a few things:
- Even if team members bill at different rates, you could adjust that in the second column to arrive at each subtotal.
- We consider “full time” to be 35 hours per week on client work. We leave 7 additional hours open each week for team members to focus on internal projects and overhead.
- We explain this to our clients. It helps to control the idea that clients could have unlimited access to team members throughout the course of the engagement.
- If we need to list out more specific working/support hours for a particular project, we can do so in the Engagement Summary. It’s meant to be built upon to support the goals of the client.
Getting buy-in
If there’s one main theme throughout this article, it’s communication. In order to get buy-in on this type of agreement, you should expect to invest a considerable amount of time researching, educating, and iterating on your approach internally.
Throw things out to the group. Experiment with this type of agreement on an internal project. Conduct retrospectives to track what’s working and what needs to be altered. Ask your production team if they’ve experienced this type of working agreement in the past.
Once you’re on the same page internally, you will need to educate your prospects and eventual clients — not just upfront, but throughout the entire process. Talk with them about the regular backlog grooming sessions. Remind them that they will be in the driver’s seat when it comes to directing priorities and what gets accomplished each sprint. Reiterate the focus on value and results vs. specific features. There will be plenty of time to get into the weeds of features as a sprint gets planned and is underway.
There’s no silver bullet to getting everyone aligned. It takes belief in the idea, commitment to experimentation, and ongoing education. If you believe this type of agreement could work for your business, find some champions internally that feel the same way, and get after it!
The benefits & drawbacks
As with most things in life, there are benefits and drawbacks to Duration and Price Contracts. We’ve been doing this for about 3 years and have found the following things to be true. Let’s start with the good.
Benefits:
- Duration and Price Contracts provide speed when it comes to getting the formal paperwork completed for a project.
- They reduce the impact of contractual obligations once a project is kicked off. The team can pivot if/when things come up.
- Because of this, the team can focus on doing their best work.
- The team can also suggest things for the benefit of the product without fear that it throws the entire scope off. This can create more value in less time because they aren’t held to a scope document.
- It puts the client at the head of the table. They are allowed to make decisions along the way. As much as any client knows what they want before a project starts, things will change. Duration and Price Contracts support this reality.
- Because the contract can generally fade away into the background, it benefits the relationship overall. The team can focus on the product and the value it provides the business.
- They make resource planning easier. We keep our dedications as simple as: quarter-time, half-time, or full-time.
- Full-time dedication for our team members is ideal from a utilization standpoint. We try to offer this up as often as possible, especially for development roles.
- At the end of the day, we still get paid, but there is less overhead involved for change orders and other issues that arise with fixed scope. Say goodbye to some administrative headaches!
Drawbacks:
- It is a harder sale. You have to commit to the education piece from day 1 with prospects and reiterate the process & value so a client is comfortable with this kind of arrangement. Those with extensive experience have usually been burned and understand. Less experienced clients may need some analogies drawn to better understand it. Spend the time educating!
- You may need to extend the time it takes to close a deal to ensure that everyone is comfortable with the goals of the engagement.
- From a business perspective, it limits the possibility of hitting a home run from a profitability standpoint. If the team gets done with something early, you can’t reap the benefits of that profit. The good news is, it’s reliable margin, but you don’t get to keep any excess due to efficiency.
- If these are contracts adopted widely, it can become too much of a go-to for everything. Realistically, some projects are not meant for duration and price. If your team is inexperienced or new to agile processes, it is not a recommended approach.
- Similarly, as an organization is growing, it’s okay to use fixed scope contracts for smaller-scoped, well-defined projects.
Compared to other types of contracts
There are many other types of scopes of work out there that businesses use to do this type of work. Here’s how we think Duration and Price Contracts differ from other options.
– Value-Based Pricing: This is difficult to do in an agency environment without having a firm understanding of what the work would save the client in the long run and base the pricing off of that. If someone out there has found a way to incorporate these into their agency, please tell us more about it in the comments below. Duration and Price Contracts do focus on the value, but we do not base the amount on value itself.
– Fixed Scope: We’ve contrasted this type of contract throughout this article, but in a fixed scope contract, teams are strictly tied to a set of deliverables. Duration and Price is not tied to deliverables, but rather a shared vision & expected outcomes.
– Time & Materials: In this arrangement, you only get paid for what you complete. With Duration and Price Contracts, we are billing a flat amount for the resources working on a project for a set duration. We don’t invoice hours, although we do keep a pulse on how team members are spending their time, especially for half-time or quarter-time resources, so we can help to navigate time management challenges.
Parting words of wisdom from our COO
I went straight to our COO, Dan Linhart, when I decided to write this article to get the full picture of the impacts it’s had and continues to have on our business. He bestowed some wisdom on me that is worth sharing.
To start, he said, “It’s incredibly important to get all roles in touch at the beginning stages. This includes the owners, biz dev, production roles, and strategists. If you don’t stack hands on it, it just won’t happen.”
He highlighted the importance of internal selling of the idea and education for all stakeholders in the agency. Even if you experience imposter syndrome, keep going and learning more about the model. He told me, “If you can sell your team, you can sell your client.” Prospective clients need to know the benefits of agile so you can ease their anxiety. They need to be able to report this up to other stakeholders on their side.
Beyond that, though, there is a huge implication of this type of contract and company culture. You want to make sure this is connected to how you work as a team. At Crema, this contract integrates nicely with our philosophy and how we build products. If your organization is more waterfall based, it’s okay to stick to specifications.
