Traditional project management methodologies deal with complex projects by requiring everything to be clearly understood and documented at the start of the project. This has its benefits – a product is then designed to handle all the different requirements from the start so you never run into the problems of having to shoe-horn a necessary change into a design for which it was never intended at a later stage of the project. Well, that’s the theory at least, but in reality this only works if the whole story is known at the beginning and this is frequently not the case.
Even worse, sometimes the project team think they understand what is required, it is documented and the client also thinks the project team understand what is required but because of poor communication, unspoken assumptions etc. that’s not the case. Sometimes the majority of what has been specified is correct but, human nature being what it is, the client sees the opportunity to add a “simple” change part-way through the project but the “simple” change, in fact, undermines the whole design of the end-product.
None of these problems are new to experienced project managers but there can be much debate about how best to deal with them in a project situation.
Many organisations use traditional project management approaches but within a framework of their own that has been proven to work for their own business and often this will include some form of an iterative method so that the project never gets too far down the line before a problem is discovered. I used to work at a large organisation where the word “problem” was simply not used in a project context – we didn’t have problems we only had “issues”. I’m not sure whether psychologically issues seemed less serious than problems to the stakeholders but those working at the coal face knew that this was just a matter of semantics.
So if organisations are already recognising internally the benefits of an iterative approach to delivering successful projects then should they be considering Agile project management with its iterative approach to determining requirements typically used for IT projects?
The flexibility of Agile combined with the rigour of a more traditional approach may be just what is needed to improve project success rates.
This approach means you would plan only for the first set of deliverables at the beginning of the project but there would still be a requirements gathering phase it would just be shorter and quicker to complete because you are not trying to solve the whole problem at once. Then, once the first deliverable is tested, approved etc. you can move on to plan the next phase and then the next.
A downside to this approach can be the necessity to go back and change previously approved parts of the project as more understanding is gained of the overall picture but that is arguably less disruptive because the staged approach should mean that problems are revealed sooner. It can also have an unexpected impact on costs and schedule but, most importantly, it does ensure that the project delivers what the client wants, and, after all, what is the point of a project delivered on-time and on-budget if it does not provide what the client was expecting?
With an Agile project management approach, or just an iterative approach within a more formal method, each stage is effectively a mini-project and needs the basic processes, documentation, controls and management that any small project would need. The client will receive frequent deliverables, helping to visualise what the final end-product will be like and to determine for themselves the level of progress rather than having to rely on what can be mis-leading status reports.
This way of working can, at first, seem to be chaotic but an iterative approach such as Agile backed up with sound planning and solid controls may be just what your projects need. Controlled chaos is not such a bad thing!
If you have had any experience of and iterative approach to project management working well (or badly) why not share your experience with us?
