Agile and Fixed Price Contracts by AEi International

Agile project management Agile management or agile project management is an iterative method of determining requirements

for engineering and information technology development projects in a highly flexible and interactive manner.

Agile and Fixed Price Contracts

BY Mark Tolbert, PMP

At first glance, there does not seem to be a good fit between the fixed price world and Agile. In the fixed price world, it’s usually the case that the customer has a very clear understanding of the deliverables.

n 2012, the Washington, DC PMI Chapter – (PMIWDC. org) - sponsored more than fifteen meetings concerning Agile project management. (In the last five years, there have probably been more than forty or fifty presentations on Agile methodologies at chapter events. The chapter supports approximately 15 meetings each month where presentations on project management are delivered: for PMI members, it is a veritable PDU – (“Professional Development Unit”) - factory! A question that came up frequently in these presentations was: “How do I use Agile with Fixed-Price (FFP) contracts?” Or, “Can Agile be used effectively with fixed price contracts?” At first glance, there does not seem to be a good fit between the fixed price world and Agile. In the fixed price world, it’s usually the case that the customer has a very clear understanding of the deliverables and what they want created for the project. Therefore, the statement of work (SOW) should be very detailed and quite lengthy. The customer will be choosing between vendors’ solutions based mostly on price, and past performance.

January - February 2013 · MODERN GOVERNMENT

On the other hand, Agile is most appropriate for projects where the customer really doesn’t know what they want going into the project, and we need to discover or explore their requirements through iterations and prototypes. The customer will want a new solution created for the project. As Ken Schwaber – (one of the original authors of the Agile Manifesto) – said, “Agile is about the art of the possible,” not “you give me what I paid for, when you said that you’d deliver it.” For PMI, and for students preparing for the PMP exam, it’s understood that if the customer only knows what they want at a very high level – (“business requirements” or “functional requirements”) – then the customer cannot expect the vendor to bid a fixed price for this work. How could they? How can the vendor be expected to predict or estimate the schedule and their costs when the requirements are so high level? If we are the vendor, and we do not have a very explicitly detailed SOW, and we submit a proposal to do the work, how do we have any assurances the customer will accept the deliverables we

create? If there is ambiguity or vagueness in the SOW, then contractually, we won’t have a leg to stand on! We will have no assurances we will get paid. The customer can always look at the deliverables that have been created, and simply say, “This is not it! This is not what I need or want.” And the vendor will be forced to accommodate whatever change requests the customer gives them: add more features or higher quality to try to please the customer and get their formal acceptance. Of course, this is all about dealing with the dreaded “Scope Creep!” (One of the primary causes of project failure, especially in the fixed price world, is dealing with a vague and ambiguous SOW. In the fixed price world, the SOW needs to be a very detailed definition of the products and deliverables, and have the level of specificity and clarity one would expect in a Scope statement: clear “SMART” acceptance criteria for all deliverables, project boundaries or exclusions, and a clear definition of constraints and assumptions.) Of course, when the requirements are high-level, it is much harder to derive accurate

Project Management

estimates. Analogous estimating techniques are probably all we can use, and these types of estimates often turn out to be off by a significant percentage. (For PMI, at the beginning of the project, if we use analogous estimating to produce estimates, this first estimate will probably be a ROM – Rough Order of Magnitude estimate, - and its accuracy only from -50% to +50%. The real costs may turn out to be as much as 50% less, or 50% more.) Therefore, vendors traditionally do not want to make a fixed-price bid in this context, and if they have any leverage, they will want the contract to be a Cost-Reimbursable Contract type, or Time and Materials. In the Cost Reimbursable world, the customer is agreeing to pay the vendor for all of their costs: labor, tools, equipment, rooms and facilities, and perhaps some portion of their indirect costs. The customer is taking on all of the risk. If it takes more time, and costs more money for the vendor to create the solution or deliverables that the customer desires, then the customer is absorbing all of these extra costs. Additionally, on top of these

The customer can always look at the deliverables that have been created, and simply say, “This is not it! This is not what I need or want.”

costs, some profit or fee will be added. Similarly, in the time and materials world, the customer has most of the risk. Typically, time and materials contracts are used for very short duration engagements where the deliverables are quite undefined, the customer does not know what they really need, but they know they don’t have the resources – either people or tools and equipment – to meet the need. So, they bring in a vendor on a time and materials basis to provide the resources for the short duration contract. These are typically “best effort” contracts: the vendor is not committing to deliver any specific products or services, they are just providing resources at a certain rate, and the customer will have to monitor the vendor’s performance closely to see that they are producing something of value. So, this could also work well for the vendor using an Agile Project Management approach. But obviously, customers much prefer a Firm Fixed Price (FFP) contract model; often expect this, and when economic times are tough, they often have the leverage to demand this

type of contract. Now, in the fixed price world, the vendor is taking all the risk. If it costs the vendor much more to deliver an acceptable product to the customer, or it takes more time than what was estimated, then the vendor is responsible for all these additional costs. In today’s world, even with software contracts, it seems that most often customers are demanding the work to be fixed-price. So, if you are a software company, do you agree? Is there any way to make this really work? Yes, actually, software and consulting companies are proceeding with providing bids even in this context, and they are trying several strategies to protect themselves while still using Agile methodologies in this fixed-price model.

The simplest solution would be to protect against risk by just bidding a higher price. If you believe there is a significant risk that it will take longer, and cost more to deliver a product acceptable for the customer than your “most likely” estimate, add an extra buffer or reserve to cover this risk. For example, if you believe

MODERN GOVERNMENT · January - February 2013

Project Management Institute PMI is one of the world’s largest not-for-profit membership associations for the project management profession, with more than 650,000 members and credential holders in more than 185 countries.

there is an 80% probability the customer will want additional changes that will amount to a cost overrun of $30,000 (which perhaps corresponds to a schedule delay of two weeks), then add a reserve of $24,000 to protect against this risk. (This is using EMV - “Expected Monetary Value:” – multiply the estimated probability of the risk by the dollar impact to calculate the reserve amount.) Of course, the more conservative you are adding in reserve, the less likely it is your bid will be competitive with other bids.

Secondly, another approach that is often mentioned is to use a hybrid approach: Mix in a front-end detailed planning phase, so a portion of the high-level requirements can be defined in detail, and a fixed-price can be bid for this subset. Of course, the customer will need to be flexible, and agree to divide the project into segments with pricing determined for each segment or phase. At the end of each phase, a new set of requirements will be chosen and planned in detail for the next phase, and a fixed-price will be bid. But there are advantages for the customer too: unlike what is done in the classic “waterfall project,” useful products/ prototypes are delivered at the end of each iteration (or phase).

January - February 2013 · MODERN GOVERNMENT

In “waterfall,” the customer does not see the product until the end of the project. This shows that the Agile iterative approach can be viewed as a form of Rolling Wave Planning (plan in detail the things that will occur right away), and sketch in at a high level things occurring farther out in the future. Then, in a second wave of planning, and third wave of planning, come back and update the original high-level plans with details for the items that will be coming due in the near future. With this hybrid Agile approach, not only is the planning being done in waves, but prototypes are being delivered in waves or iterations. This approach does depart from the classic way of doing estimating in Agile. In Agile, the team does not plan in detail the architectural specifications of deliverables and work-packages, and use this to create a “bottomup” estimate: roll up from the detailed time and cost estimates of activities to the work-packages to the control accounts and higher levels of the WBS (work breakdown structure). Instead, relative estimates are made of the size of higher level “stories” and “features,” and as the team progresses in creating these stories or features, their “velocity” is measured, so forecasts can be made against this actual performance for the duration and cost of the sprint (or iteration).

A third approach is another variation on the second approach. Again, the customer agrees to divide the project into phases (or iterations) with separate pricing for each iteration, but we won’t do the detailed planning needed to decompose high-level requirements into architectural designs. The customer picks a subset – perhaps the top 10% or 15% - of their requirements for an initial prototype (or iteration). These requirements (or features) will also be their top priority requirements, and something the vendor estimates probably can be created in 2 to 4 weeks. The vendor knows how many resources are required for this first prototype – (perhaps 6 to 8 senior dedicated engineers), and how much time is estimated, so it will be simple to propose a price. The vendor may feel comfortable accepting the risk for a fixed price for this first iteration. Yes, of course, there is some risk that it will take longer, and cost more to create the feature set that is called for in this initial iteration, but the vendor may feel that their exposure is limited, so they can accept this risk. Alternatively, if they are not comfortable accepting this risk, then they will really propose doing this first iteration on a cost-reimbursable or time and materials basis. A “not to exceed price” could be defined for the iteration or sprint, but under this type of contract,

The real intent and spirit of Agile is to help the customer explore and discover a new solution when going into the project they only have a very high level idea of what they want. In this situation, the customer should not expect that the vendor can put together a clear precise estimate.

Project Management

the vendor is not held to a hard and fast commitment that all the features in this initial “product – backlog” will be created in the 2 to 4 week iteration. So, the customer is protected with a fixed price - (or “not to exceed price”) - for this first iteration, and they know that some useful product will be created. After the first iteration, the customer has the advantage of seeing a real product, and getting immediate feedback and assurances the vendor is on the right path early in the project. The velocity of completing the features for the first iteration is measured, and the vendor’s risk is reduced too since much more realistic estimates can be made for time and cost for future iterations. So, for the second iteration, the customer picks a new set of requirements, and again, the vendor bids a price. After the track record of the first iteration, there should be strong confidence in the soundness of the estimates that the price is built on. Change is a fact of life, and in this environment where the customer was looking for a new solution to be created, it is even more likely the customer will want changes. Now, moving from iteration to iteration, they have much more flexibility to add new requirements that were not part of the original SOW. Conversely, they could choose to delete

requirements they now believe will not have value. (A form of Pareto’s law usually applies: 20% of the customer’s requirements usually fulfill 80% of the customer’s need. Therefore, if we target that most important 20% of the requirements first, it is very likely the customer will discover other requirements they first thought were essential are not really needed. This could reduce the overall number of iterations, and therefore dramatically reduce the price of the entire project, so the vendor needs some sort of protection with a “penalty clause” if requirements are dropped.)

Lastly, another idea is to build incentives into the contract: Either use a “FixedPrice Incentive Fee” (FPIF) contract type, (or even a “Cost Plus Incentive Fee” – (CPIF) contract type). These incentivebased contracts help ensure that both parties are accountable, and are sharing risk for the project. The vendor is rewarded for beating the estimated costs, and

likewise, picks up a significant part of any cost overruns So, these are just a few of the ways that people are using Agile methodologies with fixed-price contracts today. However, it’s clear that the real intent and spirit of Agile is to help the customer explore and discover a new solution when going into the project they only have a very high level idea of what they want. In this situation, the customer should not expect that the vendor can put together a clear precise estimate of time and cost for a solution that is largely undefined. By default in this scenario, a Cost Reimbursable contract, or Time and Materials contract type would be the best fit. (MG)

MODERN GOVERNMENT · January - February 2013