AgileTopics

How To Make An Agile Contract Work For Your Teams And Clients

By 11/09/2018 5 Comments

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.

You grab your chest because you know that’s not long enough. Then, you take a deep breath and move through the appropriate project set up processes, working diligently with the internal team and client stakeholders to try their best and deliver what was promised by when it was promised. You might need to take more deep breaths along the way.

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 superheros 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?

agile contract

In this article, I’m going to be describing a type of agile contract that our product development agency has adopted over the last few years that we termed a Duration and Price Contract. After shifting to this agile contract, 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. We’ll cover:

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 and Price Contracts: What are they?

Duration and Price Contracts are a term we arrived at that describe 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.

Crema is a product development agency with a distributed team across the country, headquartered in Kansas City, Missouri. After 6+ years of fixed scope, waterfall contracts, our team was leveraging agile methodologies to build products more and more. We wanted to create an agile contract that worked for us and our clients. Likewise, an agile contract would better support our collaborative culture and focus around the value we were providing to the client teams we work with. We thought 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 we’ll get into later in this article, 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? 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.

Thus, the name Duration and Price Contracts came to be. To our clients, we call them Engagement Summaries, but we are familiarizing them with the “duration and price” terminology along the sales process until we 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.

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. We took what we could find from Hanno and others in the industry and started to formulate our own spin on it.

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.

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 an agile 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.

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 agile 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:

  1. What our clients wanted
  2. How we wanted to manage ourselves
  3. How our culture operated

And guess what? It worked. They were a client of ours for almost 3 years.

Implementation Considerations

Let’s go back up to the scenario that started this whole article. The number one recommendation I can give to prevent the pain associated with this to involve project management into 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.

The biggest thing when implementing any type of agile contract is to put processes and conversations in place so the client doesn’t think they’re writing a blank check. We are careful to make sure the agile contract doesn’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. Plus, we’ve built a product development process that we know and trust.

Before we go into some brass tacks, I should 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.

After we’ve vetted that an opportunity is qualified, we’ll create a 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.

agile contract - engagement-summaryIdeally, 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.

agile contract - engagement rolesIn 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 For An Agile Contract

If there’s one main theme throughout this article, it’s communication. In order to get buy in for an agile contract, you should expect to invest considerable amount of time researching, educating, and iterating on your approach internally. Throw things out to the group. Experiment with an agile contract on an internal project. Conduct retrospectives to track what’s working and what needs to be altered. Ask your production team if they’ve worked with different types of agile contracts 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 agile contract could work for your business, find some champions internally that feel the same way, and get after it!

Benefits and 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 and value so a client is comfortable with an agile contract. Those with extensive experience have usually been burned and understand. Less experienced clients may need some analogies drawn to better understand what an agile contract is. 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 agile contracts are 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.

Relation 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.

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 and agile contracts 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 agile contract and company culture. You want to make sure this is connected to how you work as a team. At Crema, this agile 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.

Finally, don’t be afraid to try. You can experiment with Duration and Price contracts for as little as one week. The beauty of this model is that it can scale from a week to multiple years, pending the organization’s processes and maturity. Get the right people involved to manage that time, empower the team and the client, and buckle up for an agile team’s ideal working arrangement.

Disclaimer: This article serves to educate and inspire an easier way to approach a  more agile contract. It is not all-encompassing or legally advising. I hope some of the things you read below are helpful in your agency or business.

What do you think?

We are but one agency in the ocean of other agencies. I’m curious to know whether you’ve experimented with different types of agile contracts that have benefited your business & client relations. Comment below so we can learn from one another!

Alexa Huston

Alexa Huston

Alexa Huston is a former project manager at Crema, now working as a Business Development Strategist. Crema is a technology and innovation agency that partners with funded startup, small business and enterprise clients to prototype, test, and build their web and mobile applications. When she’s not at their KC office, she can be found at the gym working on getting stronger, in the kitchen whipping up something delicious, or drumming up plans for upcoming travel.

5 Comments

  • Madde says:

    Hi Alexa, great topic for the article! I have a question: how was the duration of the project (12 weeks) estimated by your team, based on what? For the estimation we simply need stories to know what we will be working on, and stories already define a scope. So do you create stories before the contract at all? Do you include stories in the contract as a specification? I can’t imagine a situation when the client asks me about the project duration and I can promise him some dates without estimating project breakdowns/stories to do so.
    But unfortunately I can imagine a situation when a client is completely unoriented in IT world, we define a business goals and time to deliver a product that will enable it to achieve, and the client imagines something completely different than we are able to offer him in this promised time. How to deal with it?

  • Mark Fromson says:

    Good job on your recent DPM article about Agile Contracts. The one issue I’ve found with them is clients that just don’t think you’ve made enough progress for the timeframe. It’s tough to illuminate all the daily detail to them, and many people are used to being “tough on the vendor” to get more out of them. Thoughts?

  • ahuston11 says:

    Thanks, Mark! That can be challenging, and unfortunately, most agencies get the finger pointed at them more often than they’d like.

    The best way we combat that is identifying our core contacts on the client side and integrating them into our PM software (Ora) and Slack so they can see all the activity going on in real time. They’re also in all of our product meetings and weigh in on what the focus will be in a given sprint. They prioritize the backlog with us. We try to release something every 2 weeks – even at its most basic form so we can get feedback from stakeholders. They’re the ones reporting this progress back up into the organization & we identify opportunities together to do larger demos of the work. Hopefully, if your process is working right, there truly IS work to point back to and say, “look at all we’ve done.”

    We’ve found this level of transparency and collaboration mitigates a lot of the feelings of work not getting done fast enough.

  • ahuston11 says:

    Hi, Madde. Thanks for the note! And you’re right – even if the specifications aren’t exact upfront, the client will NEED to know about particular milestones along the way.

    To answer your question: we rely on our product development expertise when we’re quoting duration to our clients. On average, for us, it takes about 12-16 weeks to build an MVP. That’s where I pulled the 12 weeks.

    That said, we do typically create some user stories in an initial phase of an engagement. These get put into the contract that drive what our goals are for development. It also gives the client some level of confidence that we know what we’re aiming for.

    We’ve found the best way to deal with a client – regardless of their level of expertise – is to integrate them into our process so they can approve individual components along the way. This reduces the feeling that we deliver something they didn’t ask for.

    I hope that helps!

  • Interesting read! What about projects that include a discovery phase within this agreed duration and the client procrastinates or gets distracted so your team end up twiddling their thumbs (well, works on other projects). Do you still charge for the elapsed time and the client just gets less actual hours?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.