At first glance, the term “agile fixed price project” sounds like a contradiction in terms. Fixed price projects feature exact specifications, offering both sides clarity as to the services to be performed, the schedule, and the parties’ cooperation obligations. The contractor bears the risk – for which the client pays a commensurate markup in turn in some cases.
The term “agility” means that something is flexible and mobile, so it encompasses change as a characteristic. Agility is becoming increasingly popular, especially in the context of agile software development: Less red tape and more iterative cycles lead to the result that is truly needed at the end of the project.
Changes at a fixed price – how could that possibly turn out well?
How much agility does a successful project really need, anyway?
While some people involved in a project process swear strictly by the waterfall model, a scrum is essential to others. As in so many areas, the truth lies somewhere between the two extremes. A project’s success factors include a great many different aspects. Alongside the “usual suspects” in achieving targets, such as deadline, budget, and performance, project excellence also includes focusing on targets and on the customer. And this is exactly where the causes are usually to be found when a project is less than completely successful: The project turns out exactly what was specified at the start and set out in the fixed price agreement. Unfortunately, though, the result cannot be used afterward in many cases, since targets have changed – or should have changed – over the course of the project, but the plan was not adjusted.
Many larger projects based on the waterfall model never get started, or they get started much too late, since the time needed to set out exact specifications is often underestimated. And yet, all the parties want to do at this stage is simply maximize clarity, thereby minimizing the risk for both sides.
Agile software development doesn’t have to be based on a single paradigm
After all, agility is already created within a project if two main features are taken into account:
- Feature swapping – the right and ability to reduce, expand, entirely eliminate, or replace an originally planned part of the project
- Release whenever you want – Small iterations of about a month yield functionality or partial functionality that is ready to use early on.
Both features enable an optimum focus on changing project goals and current requirements over a longer project term – and thus allow the parties to focus on targets. The end product is truly exactly what is needed at the time. This is the basis for responding quickly to changes in the market: “time to market.”
The following aspects help with agile software development:
- Careful analysis of requirements – The use scenarios define the implementation in the database, and not vice versa.
- Iterative approach – Every function has its own roadmap.
- Pareto principle – The technical architecture and user interaction must be ranked first in the specifications for a function. All other details can be set out concretely in the course of implementation.
All too often, it is the lack of clarity at the outset that carries a risk of misunderstandings. An agile approach is also only sustainable if there is intensified communication between the client and the contractor. This depends on two factors: a higher budget, and the parties’ actual communication practices. In the end, any change in the project should be captured via change management. Every change also represents additional time, effort, and expense.
The client always wants to receive the best possible result. Unfortunately, all too often they try to minimize risk in the form of a contract that nails down every possible point – while missing the opportunity to leave some room for maneuvering in order to get exactly what they actually need in the end. This does not break the vicious cycle in which, very often, the requirements are not yet very clear at the start of a project. The parties’ attempts to hedge their bets and provide security for all eventualities also produce a great deal of red tape, which then stands in the way if there are requests for changes after all.
Where does all of that fit in with agile fixed price management?
The basis for a solid project is the original estimate of time, effort, and expense. Whether a top-down approach or a bottom-up one is taken, experts and appropriate procedures can help establish a rough budget very quickly. This budget by no means already incorporates all of the conceivable aspects, but instead merely lays out the essentials. That is exactly as it should be, and in particular, it is also a component of the iterative approach within a project. This establishes a framework for each function. The approach used to find a solution is then supposed to be geared toward the function. It is also possible to perform initial cost-benefit analyses already at this point in order to decide whether the path to implementation should be taken in the first place.
In principle, an agile fixed price project represents a course of action with a cap on time, effort, and expense. There are no hidden markups for risk, since both parties commit to share the risk between them. There is also no need for the client to manage the project team, since there is an appropriately experienced project manager on the contractor’s side available to do this. The client primarily takes on the role of the product manager who defines the roadmap and is responsible for it. The project manager works together with the product manager, supporting a highly important and decisive process during implementation. In line with the design-to-cost approach, the project manager develops possible approaches to arrive at a solution and development stages of a function in order to achieve the best possible result with the available budget.
The process
Ideally, the requirements are formulated as stories told to the future customers. In this process, it quickly becomes apparent what benefits these stories convey, which means that priorities can also be set already at this stage. Past experience and/or key indicators from comparable projects can be used to estimate rough volumes for the expected time, effort, and expense. The total determines the budget. If the budget is known in advance, the expected time, effort, and expense can also be distributed based on this amount for the stories. If the stories, their priority levels, and the volume (budget) are known, the order for the agile fixed price project can be issued, and the project can get under way.
The approach within the project is an iterative process, and one where parallelization is possible. It starts with choosing the next story, with an analysis/design phase following this choice. Possible solutions are formulated using about 15% of the budget proposed for the story. These details can be used to estimate the time, effort, and expense more precisely than at the start of the process. If the estimate still fits, concrete planning and implementation can start, with a release as the end result.
If the time, effort, and expense do not fit, the currently planned roadmap for the fixed price project is adjusted. Ideally, the story is structured in multiple parts that are then prioritized in greater detail accordingly. This makes it possible to strike parts of one story or another or to postpone them until later. Sometimes, however, an estimate will also show that the time, effort, and expense are much lower than was planned. In this case, both the implementation and the roadmap are adjusted. More stories can be implemented.
During the term of the project, new ideas come up and the customer requests a new feature that had not yet been considered at the outset, but is considered a high priority based on the current view of the market. In this case, a ballpark figure is set for the time, effort, and expense just like at the beginning, and a budget is also defined based on the benefit. In the end, this story can be included in the fixed price that has been ordered by adjusting the roadmap. This procedure is then often termed a feature swap.
Summary
A more agile approach to projects is only possible if there is a good working relationship with the client. The opportunity to achieve an optimum project result before others outweighs any possible additional effort and expense resulting from intensified communication. The risks become manageable due to professional cooperation between the parties and the knowledge that the risk is shared between both sides.
We and our customers have had many good experiences with agile fixed price projects up to as much as 1,000 person-days. In the process, the certified project managers (IPMA) are able to draw on a highly experienced team of usability experts who help to analyze users’ needs and requirements specifically at the start of the project and audit these factors regularly with acceptance tests while the project is running. The project managers rely on our many certified Java experts in assessing the possible paths to reach solutions and the sustainability of the target architecture. A sophisticated standardized development structure enables not only optimum test coverage, but also short release cycles.
Tassilo Kubitz
akquinet tech@spree
You must be logged in to post a comment.