Iteration in fixed-everything projects
There are three main variables when setting up a project with a client: price, scope and time. The more flexibility we have here, the easier it is to run an agile project.
This is especially true when the scope is not fixed as agile development techniques really start to come into their own. Short development cycles of small, minimal, features allow the client to see the progress of the project earlier and so direct the shape of the project to ensure that a successful project is delivered.
Fixed-everything projects
However, sometimes it’s really hard to persuade a traditional client (and especially their financial department) to sign up for a variable scope project. Sometimes you even end up on a project that’s fixed-everything; the project has a fixed set of requirements listed in the contract, along with a hard delivery date and a fixed price.
As a result, you tend to see waterfall type development processes used. I think this may be partly due to lack of experience by the PM and also it seems “logical”. The contract has the requirements listed, along with a deadline and budget; hence you have a timetable. To the inexperienced PM, it seems logical to start with the design, do the build, test and then deliver.
Projects that follow this path are rarely successfully delivered to a happy client.
Agility helps
In an agile project, the requirements and hence what is delivered shift during the project as the customer understands what they actually need isn’t quite what they ordered. In Scrum, this is managed by the prioritisation of the backlog items based on business value. New items with more business value are added to the backlog as we learn what’s really required for this project to be a success. However, this doesn’t always work so well with a fixed price, scope and budget.
Nevertheless, I strongly believe that to succeed, key features from agile processes are required and the project manager needs to maintain a firm grasp of what’s going on though to ensure that the contract requirements are met by the deadline.
For me, the key feature of the agile process is iteration. By delivering the project to the client in small increments, the client is able to see the direction early and correct misunderstandings while there is still time and budget available. This is where a good project manager comes into their own. As the project progresses, the scope of change that the client can make is smaller, due to the oncoming deadline and lack of remaining budget. The project manager needs to reign back the client in later stages.
Each iteration needs to be a something that the client can comment on and ideal sign off as complete. It can also help if the iterations are in an order that makes sense to the client. While the scenes in a feature film is shot in a very different order to the what we seen in the final film, I’ve found that clients rarely want to sign off say the shopping basket before they’ve seen how the product catalogue looks.
As with all project management, communication is key. Clients come up with all sorts of great ideas once they start seeing the project come alive. One of the roles of the PM is to keep this in check as the project’s success is measured by the contract requirements, not by a new great idea. Don’t allow the project to be derailed by a change late in the day. If the client says that it’s a “must have”, then a contract change or extension is required. I’ve found that creating a “next phase” list is helpful and encouraging the client to to place all the new work onto this list. If nothing else, it starts the process of getting the next contract.
To sum up
So, in summary, try not to be fall into the trap of a waterfall-based development process just because you have a fixed project. Iteration is one of the best ways I’ve found to successfully deliver and works on all projects, especially the ones with the most constraints.
