In the past I have done a couple of projects (all CMS websites or portal development) where the deadline and budget were fixed, and the scope variable. Most of the times because the Senior User (business/client) did not completely know what they wanted at the start of the project. This is a problem. During the project more and more requirements become clear, and new ones pop-up. The work to be done, based on the existing and new requirements becomse more clear. And after some time it gets clear that the total amount of work requested will not fit the time and budget that is available.
That situation is not nice for the Senior User, because priorities have to be made and less important (but still wanted) requirements will not be delivered or additional time and money needs to be available. Also for the Senior Supplier (we) this a good situation. The client does not get all they want, which means the client will not be completely satisfied in the end.
Of course then you think…. but the agreements was based on variable scope, this problem is discussed in the project, everybody should be aware of it. Yes. But still the client wants everything, and is not happy if this doesn’t happen. String of thought: scope is variable, so let’s add this small feature, and this small feature, and this small feauture, ow… and this small feature.
In my current project we updated the offer from variable scope, fixed planning, fixed budget to fixed scope, variable planning, fixed budget. By defining the scope and offering it fixed it gives clearity to the client: this is what you will get, nothing more, nothing less (at least… without updating agreements). There will be less discussion, because is defined as fixed. And because the scope is fixed there is less reason to investigate all possible other nice related features.
No problems with scope changes, but they will have to be discussed separate. The advantage is the Senior User will verify if the additional scope adds value, because it’s clear what are the costs of this specific scope.
So my best practice (for the types of projects we normally do):
- analyse the needed functionality and create clear specifications about them (T&M)
- create a fixed scope offer for implementing the functionality described in the specifications
- changes: RFCs
Filed under: Componence, Project Management
