One major concern of companies engaging in Lean and Agile Project Management is how to combine the principle to always welcome changing requirements -even late in development-, with client demands for a fixed price. How can one possibly promise that?
First of all, let’s accept that it’s totally fair for a client to expect a fixed price for a service or a project. The client may simply have a determined budget and is obviously eager to maximize her benefit from that budget and to select the provider that offers the most value for that service or project.
In Lean and Agile Project Management we define the scope of a project by establishing Themes and User Stories, preferably with the client, or otherwise for the client. Then we do a Planning Poker exercise to estimate how much work each User Story would be as compared to the other User Stories. By extrapolating from our experience of accomplishing one User Story, we calculate the hours needed to accomplish the entire project. And then we can fix the price, based on a given collection of User Stories. Finally, when doing the Iteration Planning, we distribute the User Stories among the available Iterations.
The principle to welcome changing requirements means that the client is always invited to join Iteration Meetings and then to change and adjust priorities or even requirements. Changing priorities means that a specific User Story could move from one Iteration to another. Changing requirements means that the weight of a User Story (the amount of User Story Points attributed to it) can increase or decrease, or that User Story is eliminated or added to the scope. When it’s eliminated from the scope, this means that room is being made for another User Story of equal weight, or for an increase of weight of another Story. When another Story is added to the scope, this means that another User Story of equal weight should be removed.
If the Team has a Fixed Price contract, the Velocity to be accomplished remains equal. The overall scope of the project doesn’t change. The total amount of User Story Points won’t change. Yet the exact User Stories to be delivered may vary.
Now why would this be such a big deal? The main reason is that many project organizations have learned to bind themselves to extremely stringent contracts. Tons of hours are spent on setting up terms of reference, functional design and legal disclaimers for the Project. Sometimes even a detailed planning is part of that effort. When that’s done, changing anything is complex and may lead to review of contracts, or ground for endless arguments on the invoice after completion of the project. And nobody likes that.
So, in Lean and Agile Project Management we basically argue that much of that preparatory paperwork is waste, because it needs redoing anyway as soon as we start the work -and also because it takes us away from what really needs doing-: delivering services, doing the project. In Lean and Agile Project Management we prefer to deliver value, and while we do that, we acknowledge that the exact definition of value may still need adjustment.