Not only is a fixed bid project a bad idea, it’s actually a myth and doesn’t in fact exist.
Let me explain.
Agile has been around for 13 years. That seems like enough time for companies to adapt to Agile processes and get the hang of writing Agile contracts. Yet, when it comes time for companies to enter into a contract about Agile work processes and deliverables, we're still seeing Waterfall language persist.
Don’t believe me? Last week, I received a contract that had this exact phrase: “No changes will be effective unless and until memorialized in a written change order signed by both parties.” This is not an Agile-friendly statement, and these terms are not conducive to a true Agile process that would benefit both parties.
So, there is clearly more work to be done from the contracting side of Agile software development. If we want to see Agile software development contracts that are truly aligned the interests of all parties involved, there are a few steps that we need to take.
First, we start with the facts: There are three variables to any project: Money, Time, and Scope.
Next, in order to write an Agile contract that aligns with Agile software development, we must first determine which of the three variables we want to constrain. For a true Agile software development project, one, and ONLY one, variable can be fixed. The other two must remain flexible. Otherwise, it is not a contract that aligns with Agile development. Period. Sure, the development team on the ground can work in sprints, pair, practice TDD and do continuous deployment. But at the end of the day, the contract can’t align with an iterative process if it fixed more than one variable.
Who gets to choose which variable to constrain? The person paying for the project (otherwise known as the client).
Many times, the person paying for the project wants to know “How much will this cost?” That’s a fair question, but framing the cost question in a different way will help them contrain the “money” variable in the contract. I love the way Johanna Rothman states it in a recent blog post, where she advocates asking “How much do you want to invest before we stop?” She goes on to say “no business exists without managing costs. In fact, the cost question might be critical to your business. If you proceed without thinking about cost, you might doom your business.”
Cost is important. But framing cost as investment makes the conversation—and the work—about value, not just money.
Sometimes, it’s not about the cost. Instead, there is a deadline approaching, like end of the fiscal year or the holidays. In this case, it might make more sense to fix the “Time” variable.
And in other cases, the scope actually is quite defined, and both money and time are flexible. In these cases, it makes sense to fix the “Scope” variable.
Once we can agree on which variable will be constrained, we can move to step 2, which is to craft a contract that makes sense. If both parties can’t agree on which one variable to fix, skip down to option 4.
When writing fixed-budget contracts, I’ve used language like this:
"The engagement will begin at a mutually agreed upon date on or around XXX. The hourly rate will be $X/hr. Based on the hourly rate of $X, and the estimate discussed, the total engagement is estimated to cost approximately $XXX. The budget for this Engagement will not exceed $200,000 (the “Term”).
In this case, you give an estimate, which is ideally close to the budget, and then commit to not exceeding that budget. When a project has a limited budget, we often have to continuously prioritize the features. This helps maximize the return on investment by ensuring we are continuously building the most important features. Helping teams determine the “must-haves” vs. the “nice to haves” can be integral, because a fixed budget requires that we stop building when we hit that budget, or consciously decide to increase the budget. Keeping an open dialogue here is very important.
It is critical to note that “fixed-budget” is different than “fixed-price.” Fixed-price is a term often used to imply that BOTH scope and money are fixed, which is not something I’d recommend. “Fixed-budget” fixes only money, not scope.
I've used language like this:
"The engagement will begin on October 1, 2014 and will end on January 1, 2015. The hourly rate will be $X/hr. Based on the hourly rate of $X, and the estimate discussed, the total engagement is estimated to cost approximately $XXX.
In this case, you still want to give a cost estimate, and make it clear that the project will end on a certain date.
This type of contract is the hardest because it must clearly outline the necessary features and outcomes of the project that will be delivered. I've used language like this:
"The engagement will begin at a mutually agreed upon date on or around XXX. The hourly rate will be $X/hr. Based on the hourly rate of $X, and the estimate discussed, the total engagement is estimated to cost approximately $XXX. The agreed upon features for this engagement are: XXXX.
With a fixed-scope project, you want to ensure the client understands that both time and cost can increase in order to ensure the agreed upon features are delivered.
In essence, if someone requires fixing both scope and money, they are asking for a fixed bid. I personally avoid fixed bid projects 95% of the time. Every once in a while there's a compelling reason to take one. Most of the time there's not.
Trying to complete an Agile project under the constraints of a contract suited to another type of process will make life for the team very difficult. So be sure to begin any Agile project by having a conversation with the client about these variables and determine what is critical. This will ensure you’re all on the same page about workflow and expectations, and that the contract reflects what you are actually doing.
Debbie has over 20 years of experience in NYC tech. She is passionate about helping businesses improve through software. As CEO, Debbie has unparalleled leadership experience in the technology space - she built 4 companies from the ground up prior to co-founding Stride.
With a reputation as a passionate woman executive in technology, Debbie is a sought after writer and speaker. She has appeared in popular media outlets such as Harvard Business Review, Huffington Post, Forbes and The Wall Street Journal.
By Paul Blair
Pair programming is probably the most controversial and least-adopted Agile practice. Capers Jones finds that for...
Posted February 12, 2016
For this month's Stride Tech Talk, Stride CEO Debbie Madden discusses the importance of Liftoffs with Diana Larsen and...
Posted February 12, 2016
Pair programming is one the core tenants of Extreme Programming, commonly referred to as XP.
Extreme Programming is an...
Posted February 12, 2016