For a IT service provider, doing projects in fixed fee would mean the hours to be spent is capped. Each IT service company is having is its own benchmark hourly rate to compute fee from the estimate hours. That make the job of estimation very important. But Agile brings its own challenges: it doesn't have any end to requirements specification, not does it have any project/product sign-off criteria. Once somebody is entrusted to run a project on fixed fee, putting such boundaries are essential to keep the project afloat, financially.
Once more, we need to bring the PM back here. The PM will now evaluate the areas where boundaries are to be defined, and will do the necessary fencing to guard those. Let's talk about a bit on those common areas in general -
Scope Management: The scope of the work can be defined with various level of details. It can be a one-pager for a 5000 hours worth of work, or it can be a one-pager for a 50000 hours of work. Defining the scope of work crisply and succinctly is very important while agreeing to execute a project in a fixed fee. While drafting the scope, the local cultures are to be kept in mind too. Some regions on this planet expects the exclusions to be written down separately, others are fine with inclusions only. In some parts, it requires to be submitted in local language. All such cases are to kept in mind to ensure minimum (if not zero) room for ambiguity, second guessing, and arguments.
Requirements Management: Gathering requirements and documenting those for the software developers play a key role in keeping the costs at tab. While requirements are gathered, it's important to understand that the requirements documents will be read by the business users too. Accordingly, the clarity for each functionality / feature are to be documented. Objectivity of the requirements are also to be very clear: Is it being done for a specific sprint? Is it being done before submission of the fee quote? Is the fees are already determined? For the first and third questions, the stakeholders should be alerted if the requirements are blowing out of proportion.
The second situation is rather win-win combination. In such situations, the requirements analysis phase is taken out of the project and are performed separately. Most of the economic buyers are comfortable in paying by the hours for this phase, since the uncertainty is less. Even if it is to be capped at a fee, the duration of the work can be capped as well. Once the requirements document gets ready and accepted, the document(s) are used as the basis for quoting the implementation fee. The benefit of such situation is that it allows the IT service provider to quote an educated fee. It also allows the provider to invest, benchmark, and improve its estimation model to a higher level of maturity and certainty.
During the acceptance phase, new requirements and modified requirements are inevitable. The PM must drive those hard enough to get documented as individual CRs so that those can be priced separately. One popular approach is to bundle a set of logical CRs into one release, quote a fee (again fixed), and deliver.
Schedule Management: Once the project is underway, it's important to keep it on schedule. If the schedule is not on track, there is every possibility of leakage of hours through non-productive work and idle hours. Although, idle hours are not generally counted as the project hours, but it's still the cost to the company. Every PM should be aware of keeping it under control.
There would still be situations where the schedule cannot be kept under control. The effective way to keep the project financially viable is to cut down the team size. A slim team is capable to running long by burning less hours yet accomplishing all the expected tasks. The big assumption here is that the scope is under control.
To summarize, the project can be done in fixed fee and following some of the best practices of Agile method, as long as the team is open to borrow practices and processes from the traditionalists for ring fencing their own risks.
