Abstract
Agile experts tell us fixed price projects are immoral, declaring that agility can only be delivered on a slippery schedule and budget. But what about the real world? What about fixed deadlines and fixed budgets? What about projects that are selected based on schedule and cost? Is it possible to deliver those projects in an agile fashion, and if so, how? In this paper, we will explore key principles for achieving agility in a fixed-price environment.
Defining The Problem
In order to develop effective techniques for implementing Firm Fixed Price (FFP) agile projects, we must first understand the nuances, connotations, and expectations for such projects.
Key Definitions
First, the PMBOK® Guide, Fourth Edition (PMI, 2008), defines Firm Fixed Price Contract as “a type of fixed price contract where the buyer pays the seller a set amount (as defined by the contract), regardless of the seller's costs.” This is a reasonably straightforward technical definition. However, most sponsors have the expectation that in addition to the fixed price, the project will also complete a fixed scope, and do so within a fixed schedule. Therefore, we have a project that is constrained by not permitting any change to key business constraints, regardless of fluctuations in risk or complexity.
Second, the Agile Manifesto (Beck, Beedle, van Bennekum, Cockburn, Cunningham, & Fowler 2001) mandates that project leaders should value “responding to change over following a plan.” Specifically, the Manifesto charges us to “welcome changing requirements, even late in development.” This is based on the conviction that “agile processes harness change for the customer's competitive advantage.”
This means we have a fundamental conflict inherit in the term “Fixed Price Agile Project.” On one hand, we must satisfy the expectation of allowing no changes to the project's key business constraints. On the other hand, we must also adhere to the charge to respond to changes as they arrive. How does one prevent change, and welcome it at the same time?
The Process for Initiating FFP Projects
Now that we see change is the key issue at hand, it helps to ask the next question, “Change from what?” To answer that question, we reference three additional terms from the PMBOK® Guide.
- Seller Proposal: All projects compete for resources. A proposal is the key means we use to articulate the business value proposition for a given endeavor. That business value proposition articulates high-level goals, and offers an estimated cost and schedule based on those goals.
- Contract: Once a given seller is selected based on the proposal, a “mutually binding agreement” is enacted to enforce the business constraints of the proposed project.
- Project: Finally, with a contract in place, a project team is chartered to execute our defined goals.
Therefore, we have three distinct and sequential activities: a proposal, a contract, and a project.
Exhibit 1 – Understanding Proposal vs. Project
These distinct activities require similar, but separate, techniques to ensure overall business success. Since the contract merely enforces the constraints defined in the proposal, this paper will explore best practices for more effective proposals and projects.
Best Practices for Proposing Fixed Projects
In the proposal, we want to define an estimated fixed cost and fixed schedule, to achieve the defined project results. Here are some specific guidelines for generating an FFP proposal that minimizes risk:
Define Business Success Criteria
FFP projects are considered successful when they are completed on-schedule and on-budget. Because agile processes emphasize the use of timeboxes, they present a distinct advantage to achieving this. It could even be said that Agile projects guarantee on-schedule on-budget execution, but with some significant caveats around the project scope. Rather than committing to the completion of specific work packages, a progressive proposal will discuss concrete measurable business objectives. If the project is intended to increase revenue or save operational costs, then project deliverables should have a measurable impact on those goals. It's not about the features. They are a means to and end. Instead, define the target business criteria. Then, estimate the cost and schedule associated with meeting the business criteria. If we incur new complexities and risks during the project, we can de-scope features that don't directly contribute to those goals. Project success is much more likely when we are authorized to modify the project scope, in order to meet our bottom-line business goals within the fixed price and fixed schedule.
Estimate With A Clear “Definition of Done”
Many FFP projects fail when they incur “surprise” requirements, not originally foreseen in the proposal phase. These are often the subtle, inferred expectations related to non-functional requirements, such as product quality, regulatory compliance, and product documentation. These items must all be explicitly discussed with the project sponsor during proposal estimation, in order to best understand the sponsor's expectations for a completed product. All of those expectations should then be documented as a “Definition of Done.” Namely, this should articulate the point at which the product is done, which is when every functional element of the product meets our agreed upon “Definition of Done.” Without this definition, the proposal's estimates will be too narrowly focused on the higher-profile work packages, missing potentially expensive less visible requirements.
Estimate With Actual Project Team
Several projects are initiated by experts that will not be doing the project work. For example, an expert assumes a certain rough order of magnitude (ROM), multiplied by a cost factor, to account for more junior resources. However, in this approach, the uncertainty in the ROM is multiplied by the uncertainty in the cost factor. This creates an unavoidable gap between project estimates and actuals. Instead, the estimates should be strongly influenced by the actual resources being proposed. In some cases, a specific product may have historical knowledge of how they will respond to similar challenges. On the other hand, larger projects may not yet have the resources on hand for such an activity. In this case, the proposal team should be targeted to lead the various sub-teams of the project, once it is initiated. This creates accountability on the estimates, but also more effectively transfers the thinking and knowledge used in the proposal onto the project team.
Best Practices for Executing Fixed Projects
As much as we would want to influence the proposal and contract process, project managers are often not permitted that degree of luxury. Instead, we are instructed to implement every work package within a fixed budget and fixed schedule we did not influence. In these situations, project leaders must adapt within their constraints, in order to achieve project success.
Re-Baseline Immediately
Once the project is initiated and staffed, an immediate re-baseline of the cost and schedule is absolutely necessary. If you are selected to lead a $1 million, one-year project, you need to know as soon as possible whether that is even possible. Facilitate a series of team meetings to re-estimate the fixed scope of the project, and then re-estimate the projected velocity for each iteration.
An example can be helpful here. A proposal team uses Planning Poker technique to derive a cumulative ROM estimate of 160 story points. The proposal team also forecasts an average velocity of 20 points for each monthly iteration. The proposal assumed the team size will be fixed for the duration of the project, and thus complete in eight months. However, after the project is initiated, the actual implementation team came up with a completely different baseline. They estimated the scope is more like 180 points. Furthermore, with the resources that were staffed, the team forecasted a 15-point velocity per iteration. Now the project is slated to complete in 12 months. This is illustrated in Exhibit 2.
Exhibit 2 – Re-Baseline to Calculate Variance-At-Start
With this re-baseline, the project manager now has data to facilitate a conversation about choices: “The project is already four months behind schedule, before we even started. What trade-offs are we prepared to make?”
Use a Flexibility Matrix
After a re-baseline reveals the gap between fixed constraints and estimated actuals, we need tools to give us the needed flexibility to deliver this project. A flexibility matrix can be a powerful tool to facilitate conversations around project trade-offs. Our cost and schedule may be fixed, but maybe we have some flexibility around quality, process compliance, or product security. In a meeting with the project sponsor and senior management, ask the open question, “Which of our project elements exhibit more flexibility, and which exhibit more fixedness?”
Exhibit 3 – Flexibility Matrix
Once we have some concessions, the team can re-estimate to see if we've reduced the cost or schedule gap.
Offer The “Dynamic Scope Option”
Although the Fixed Price structure is intended to protect the project sponsor for cost and schedule overruns, it also limits innovation and business value. When a customer learns of a new idea, or wants to remove a feature that no longer has organization appeal, the contract forbids him to do so. Because of this, the fixed-scope aspect of FFP projects can lead to frustration. A common technique to address this problem has been documented by Sutherland(2008), which he calls “Change For Free.” However, we suggest the more neutral term of “Dynamic Scope Option.” Specifically, after each iteration, a sponsor may add a new feature to the product backlog, but only if he removes another feature of equal or greater size. This gives the sponsor all the flexibility he wants, within the frozen cost and schedule constraints. This option can be so appealing that it may even give the project team sufficient leverage to renegotiate the FFP constraints, as in: “In order to get the Dynamic Scope Option, we need to amend the contract to honor our new re-baseline estimates.”
Conclusion
By their very name, Fixed Price Agile Projects offer a unique challenge: Prevent changes in scope-schedule-cost, while responding to changes in risk, complexity, and resources.
In summary, when it comes to Fixed Price Agile Projects, the following can be helpful:
- Understand the difference between a proposal and a project, and how to reduce the risk associated with each.
- Build a proposal with a proper “Definition of Done” for each work package.
- Collaborate with your sponsor to develop project success criteria beyond merely implementing all the work packages.
- Consider a contract amendment to permit scope changes with the original budget and schedule constraints.
