Fair contracts build trust: How Test Double does it differently

Over the years, I’ve become comfortable with our approach to software consulting being different.

We didn’t want Test Double to be like a lot of the other consultancies we’d worked at as many of them were set up for failure. They heavily incentivized a commission based sales force to do whatever they could to close a deal. That sales force would often agree to fixed bid contracts as it was the easiest path to a signature.

All of this urgency to close a deal eventually left me and the rest of the delivery teams with a set of constraints and goals that were unachievable, so we had to choose between making the project successful in terms of profit or successful in terms of quality, but never both. Time and time again, I was left having an adversarial conversation with client stakeholders when we should have been collaborating on a successful outcome.

Having these no-win conversations consistently over a number of years at varying agencies, ultimately caused Justin Searls and I to start Test Double so that we had the freedom to build something else. The beauty of starting your own company is that it comes with a blank slate for every aspect within the business. One area we debated for years was how to contract with our clients.

We had been a part of teams that did fixed bid, fixed scope, hourly billing prorated down to 15 minute increments, and even one organization that had a pay by story point delivered scheme. All of these approaches had serious issues that created bad behaviors and results for both the client and the consulting company.

Fixed Bid is a Broken Promise

Fixed bid, fixed scope engagements are so inherently bad for all parties that they warrant some discussion.

First and foremost, software estimation is really hard. No matter how many analogies we try to come up with, there is nothing quite like the process of estimation for software. It’s not the same as building a house to plan, solutions in the software industry are unique. If something is truly different, then it is often very difficult to align with prior experience and therefore estimate with any level of accuracy. People who are generally really good at software estimation can still be wildly off as much is learned about the final solution when the team delivers more functionality to end users and gathers feedback.

If a team is practicing agile software delivery methods (and they should) then they must embrace change. The cone of uncertainty is real, we learn a lot more about the ideal software solution the farther along we go in a project.

Software development is an exploratory, experimental process. We often can’t tell what features are useful, what design is most simple, or users are actually willing to pay for until we have delivered some amount of software to them. Having a fixed scope and price contract at the outset works against the goal of exploration. Fixed bid contracts presume that everything about the final solution is known up front and our experience tells us this isn’t true.

Fixed Bid is a Procurement Fantasy

Sadly, client procurement teams think that a fixed bid / fixed scope engagement is a win for them as the total costs are known prior to selecting the right vendor. We have seen this manipulated by countless consulting companies who will tell a buyer anything they want to hear just to win a deal. These low integrity providers will lowball the original quote with the comfort that their team can litigate any feedback or feature adjustment into a costly change control later thereby bringing the project up to a profitable margin for them, but leaving the client scratching their heads, wondering why the project came in at 2.5x the cost they were quoted.

Alternately, some vendors will provide a buffer in their quote, knowing that their estimates are likely wrong. They will still push back on any changes to the approach though, in order to try and harvest as large a profit margin as possible, at the expense of the client’s budget and the end solution. If a project is running late in this model, will the consulting team still build at a reasonable pace with a high level of quality and test automation? Likely not, knowing that company profits (even personal incentives) may be at risk. Instead they will begin to cut corners, doing just enough to get approval from the client while the end users are left with software that is difficult to use, riddled with defects, and the client maintenance team is left with a solution that will be much more costly to maintain in the months and years to come. We have been steadfast in avoiding those approaches as we believe software consulting is a high trust, collaborative model.

Collaborative Consulting

For these reasons and more, Test Double has always focused on leveraging a time and materials model with our clients. We always strive to build with a level of quality that reduces the cost of maintenance for our solutions, knowing that maintenance costs of any long lived software solution will likely be upwards of five times the cost to build it.

In Test Double engagements we’re also striving to ensure that the teams we are working with are in a better state than they were prior to having met us. Companies in a fixed bid model, won’t take the time to collaborate with the client on a design for the system. They wouldn’t spend any time helping the client developers level up with a technology that they are using. They try to do as little knowledge transfer as possible, knowing that it wasn’t a firm requirement outlined at the time they made their bid, so it doesn’t move them closer to getting paid. At Test Double, we feel that clients need to have complete understanding of the decisions we have made, the technologies we’ve used, and the overall design of any system we’re working upon, so we take the time to communicate and collaborate with them throughout.

Weekly Pricing

The approach we use at Test Double for our time and materials engagements is also slightly different than most, we work on a weekly price per software consultant, prorated down to the nearest half day. Most buyers are accustomed to hourly rates, so this also warrants some explanation. We know that context switching is the ultimate productivity killer so we strive to have every consultant at Test Double billing at only a single client at any given point.

Further, our consultants are conditioned to notify the client if they are working a full day, half day, or not at all as we don’t want to bill clients for time away where we are completely away from client work. We also don’t believe it’s inline with the level of autonomy that we like to provide all employees, to micromanage their work down to the hour or 15-minute increment. As my cofounder, Justin Searls, once said: “It’s like buying a turkey by the ounce instead of the pound, it doesn’t make sense.” Justin’s right; it’s the wrong granularity for what a client is purchasing.

Growth Time

Clients then ask, “How many hours will your consultants spend on my project per week?”, which is ultimately a question I can’t answer for any given consultant on any given week. We advise our team that we expect a 40-hour work week, but are not focused on micromanaging it. Some weeks may require more, some weeks may require less, but ultimately we trust our team to deliver value to our clients in line with a 40-hour work week.

In the ever-changing industry of software, we also expect our team to continue to evolve their skills, learn new approaches, and research changes within our industry. All of these things benefit our clients, but they aren’t necessarily directly related to feature delivery. Some weeks there may be less urgency or demand, so we may spend more time sharpening the axe than chopping wood.

To support this, we reserve up to 10% of our week towards individual growth and improvement. Some projects may be challenging enough where we don’t see a need for this time, while others may be a little more rote and this growth time will serve as a means for our team to continue evolving and growing regardless of client project. Our industry is constantly evolving. For Test Double consultants to remain as highly valued as they are, they need to have some space in their week to continue researching and learning about solutions we can bring to bear with our clients.

Open Ended

Prospective clients may review the prior two sections and feel like they are being taken for granted. We’re in essence telling them that we don’t know how many hours our team will be working on their project and some of those hours may not be heads down focused on feature delivery. How can a client trust us then? Trust has to be the foundation for any consulting relationship, so to earn the trust of our clients we provide them with an escape hatch - our contracts are open ended. Just as Test Double benefits from the freedom to pursue unexpected changes while building a software solution, clients should have the benefit of responding to unexpected changes in their business. If a consultant is not performing, if budgets change, if a client goes on a hiring spree, or for some other reason they realize they no longer need our services, the client should be able to respond in a manner that works best for them.

We simply ask to have just a week’s advance notice before removing any of our team members from the engagement in order to tie up any loose ends, transfer knowledge to the client team, and ensure that any efforts already underway are ready for their team to run with. The client gets the comfort that if they feel they aren’t ever receiving value commensurate with their spend, they can terminate the relationship. We get a positive level of pressure to always deliver value to the engagement which motivates our team to continue delighting our clients until the point where we’re no longer required. Most often this is used by clients when budgets change, but it is available to all of our clients should they need it for any reason.

Not Normal, but Equitable

Our approach to contracting may not be normal, but we started this business because we felt normal software consultancies were often doing a disservice to the clients that they served. We are comfortable with the ambiguity of our contract length and have found that our clients are generally not concerned with the hours our team works.

We believe that our model has proven to be successful, as evidenced by the vast majority of revenue coming from existing or past clients via extensions, expansion, or referrals. A mutual level of trust needs to be there for any consulting relationship to work but when it is there, both parties find that it is an equitable arrangement that also embraces the constant of change within software projects.