Agile has become an overwhelmingly popular tool for project execution. Whether it’s for time & materials, fixed price or similar projects, organizations are adopting Agile methodologies at an increasingly rapid pace.
While there is a broad consensus on Agile’s usefulness for time & materials projects, opinions on its compatibility with fixed price contracts still creates some debate.
This blog underscores the difficulties teams are currently facing and how they are tackling these challenges. Let’s begin by exploring why teams choose Agile and fixed price projects in the first place.
Why Agile?
As opposed to the waterfall sequential model, Agile zeroes in on smaller though frequent value increments. Clients and vendors consistently choose its multi-framework approach as a flexible, fast, and responsive method for their development, maintenance and support projects.
Why fixed price?
The fixed price contract is defined as an agreement to provide services to the client for a fixed price. In a fixed price project all three components (cost, time and scope) are fixed and set at the beginning of the project. A change in any component will invariably affect the other two, which is why change control becomes critical. The cost set at the beginning of the engagement is not expected to change during the product development stage.
The prospect of financial certainty makes this type of contract particularly appealing to clients. However, leaders will often assume a fixed price will imply a guaranteed specific timeframe and a precise scope of work. But in reality, this is rarely the case, in particular because changes frequently occur to better meet customer and market expectations.
We will discuss how to successfully deliver a fixed price project using Agile in later sections of this blog.
Myth: Agile doesn’t work in fixed price projects
There is a common-held belief that Agile can’t work in fixed price projects. The argument goes that while Agile offers flexibility in terms of work to be done (i.e. scope changes), fixed price projects already have all 3 fixed components (cost, scope and time). Irrespective of the chosen method (Agile or Waterfall), fixed price projects entail challenges such as new changes, project delays, and cost overshoot among others. If they are to succeed, teams won’t be able to fix all three components. Rather, they’ll need to increase the cost by adding extra resources, reduce the scope or extend the timeline to meet their goals.
Agile can actually become a boon for fixed price projects, as cost and date are fixed but the scope is subject to variations. The burden is on the team to make sure requirements are properly prioritized and organized. Teams can deliver high priority items as ordered in the backlog, while low priority items might never be developed at all.
Challenges in Agile fixed price projects
Agile isn’t so straightforward a method either. We therefore need to discuss how to overcome the many challenges associated with using Agile. A common issue is when an organization is new to Agile and expects the project to complete on time with a fixed scope and cost. Halfway through the project, the client might approach the development team and ask to accommodate a few changes as per the latest market trends. Fixed scope and timelines make such changes difficult to implement. In addition, there are additional challenges we may face down the line.
Scope
- Unclear or one-liner requirements. The major challenge teams can face is when a fixed price project changes in scope. Requirements for fixed price projects are sometimes unclear or ill-defined at the onset of the project. Teams generally size one-liner requirements based on their own experience and understanding, which by and large can be underrated. When later stages of the project expose the true complexity of the challenge, teams usually have no choice but to work overtime to make up for the underestimation.
- New changes come up halfway through a project. Sudden changes based on ongoing market trends or new priorities are nearly a rule of thumb within large fixed price projects. Clients deem such changes integral to proper product rollout and marketing, but expect no modifications in either cost or timeline. Project teams usually hesitate when faced with such changes, which in turn impacts customer relationship and trust.
Dependencies
- Ownership from other internal teams and third party vendors. A large fixed price project will most likely involve more than one team and perhaps even additional third party vendors. There needs to be a framework where all teams share the same sense of urgency and ownership of their respective tasks. Interdependent as they are, it takes just one team to be out of sync with the rest to immediately hinder progress.
Customer involvement
Sometimes there are challenges posed by clients not being actively involved during the development phase. They are usually under the impression that the requirement disclosure early on in the project renders all active involvement unnecessary. This hinders effective communication (such as addressing possible doubts and queries) and can cause delays. Clients tend not to focus much on sprint review or demo either, but on final product review they end up stating it’s not what they wanted. This can cause further delays as the team has to rework the feature to meet expectations.
Team and client lacking Agile knowledge
Despite Agile methodologies having been around for almost two decades, some organizations are still unaware or hesitant to adopt them. This poses a challenge when needing to implement Agile in fixed price and other similar projects. As already explained, organizations without Agile knowledge sometimes think that their job is done once they have provided the vendor with the fixed price contract and requirement list. They then not only expect that the project will be delivered on time, but also that all change requests do not affect the final cost.
A team without proper agile knowledge poses an even bigger threat to project success. They may continue with development via waterfall techniques, whilst by and large neglecting Agile ceremonies altogether (such as the sprint review and demo). This is the main reason why many features fail to meet customer expectations by the end of the project. This in turn calls for rework, with teams ending up working overtime to meet the inflexible deadline. In most cases, this results in neither quality nor key features being completed by the original intended deadline.
In the next section we will discuss how we can grapple with and overcome these challenges.
Handling challenges in Agile fixed price projects
Use the Agile triangle with size, not scope
While the traditional waterfall fixed price project has three fixed components (scope, time and cost), Agile fixed price projects replace the scope with the size of the project. As we know, Agile projects are typically measured in story points. Thus fixing the size (in story points) will help customers to change the scope based on market trends, provided that the new scope doesn’t increase the overall project size (in story points).
Trade changes
Agile promotes changes even in later stages of development. Many changes can occur related to market trends and reprioritization. The best adaptation strategy is to negotiate with the client to trade low priority items from the product backlog, which have a size value that equals that of the new change. This streamlines the process by which teams accept new change requests. Within this framework, a fixed size makes sense for all stages (including final outcome), with teams now delivering the same size product with added value.
Initial analysis phase workshop
The early stages of a fixed price project are always critical. This is the phase when teams set up workshops with a client to go through the list of backlog items and understand the requirements in detail. The team will then ask the client to define the acceptance criteria for each backlog item. After this workshop, the team can come up with an accurate sizing and collate it against the initial size defined in the project contract. If there is a deviation in the size, the team can negotiate the removal of backlog low priority items with the client.
Use the MoSCoW technique
MoSCoW prioritization is a popular technique for reaching an understanding with stakeholders on how to manage and deliver requirements.
Agile always promotes a healthy product backlog – one with all items prioritized and sized in story points. Teams can use the MoSCoW technique with clients to categorize backlog items once they have completed the initial analysis workshop.
Generally speaking, essential backlog items (“musts”) shouldn’t take up more than 60% of the overall project size. Unessential but nonetheless important backlog items should not exceed 20%. In short, “must” and “should have” items should ideally comprise around 80% of the project size. Hence, teams need to plan ahead to complete all backlog items. If the project implementation runs smoothly, teams should be able to deliver both “musts” and “shoulds”, and squeeze in a few extra “could haves” in the process.
This technique allows not only for the team to deliver a working product of high value, but also for customers to generate market value early on, as high value items are delivered.
Team collaboration & third party vendors
It is of the essence that all teams share the same sense of urgency and ownership for the project. A key tactic in this framework is to define frequent milestones and allocate ownership of each milestone to different teams. Periodic status updates for each team are critical to pin down common patterns in challenges across teams, allowing for early joint solutions. Consistent review of a dependency tracker and a risk register are also indispensable if a team is to warn the client of potential delays and complete their task on time.
With each team working on different items, many disparate backlog items may start simultaneously. This allows for clients to get an early insight on the final product. Teams can also strive for better code reusability: whatever any one team may implement, other teams may reuse those same components, saving time and effort in the process.
Collaborate with the client
No project can succeed without the consistent involvement of everyone involved. Even if the product backlog has been defined at the very onset of the project, the client can still explore current market trends for subsequent backlog updates. Similarly, when clients regularly attend sprint reviews, they can provide the teams with invaluable feedback early on in the project. This can also prevent rework at later phases. Clients should also be readily available to address any questions or doubts the teams may have.
Agile team training
It is critical that teams be fully trained in the Agile methodology at the onset of any project. This is the only path for them to change their working style and leverage maximum benefit. Through Agile, teams can work according to the sprint plan and can periodically deliver working products to the customer. In stark contrast to the traditional waterfall method (whereby clients don’t get to see the final product until the very end of the process), Agile makes teams earn customer trust by making clients perceive products as an actual work in progress.
Agile client training
Client training is just as important. Unlike the traditional waterfall method, clients need to understand that Agile demands their constant involvement throughout if a project is to succeed. They also need to grasp the importance of the product owner role and their work when helping teams prioritize the backlog and plan their work in the sprint.
Conclusion
Fixed price projects will always prove challenging regardless of methodology. If a project is properly carried out in Agile, it can become a boon for these projects as they are way likelier to succeed.
I have worked on multiple fixed price projects and have seen both failures and successes. Challenges rose in all project stages, and to overcome them I used many of the techniques described above. I was also aided by a fantastic team who has supported me throughout.
