Agile Vs. Traditional Project Management

The first steps towards what we now recognise as agile project management strategies were developed back in 1986, when two product development managers, Takeuchi and Nonaka, published an article in the Harvard business review called the “New New Product Development Game”. In the article, the two imagined a project management strategy that resembled a game of rugby, where team members could achieve their objectives by a process of constant re-evaluation and response. They thought this would lead to project evolution which would end up with a product that met customers’ needs more fully.

These pioneers of Agile project management have been followed up by a number of further studies and reports, leading to what we know today as Agile project management. Even today the strategies and ideas at the core of Agile stay loyal to what Takeuchi and Nonaka thought up back in the 80’s, but what is it all really about, and why is it so different to traditional methods of project management?

The differences betwee
Agile and traditional

The teamsr
With Agile project management, teams are largely self-directed and are encouraged to accomplish their deliverables in any way they see fit, as long as they follow the constraints of budget, timescales and quality as well as any other rules of the ‘game’. This contrasts starkly with traditional project management methods, where teams are typically tightly controlled by the project manager, working to detailed schedules that are set out from the start.

The requirementsr
In Agile project management, the requirements of the project are developed throughout the process as various needs or uses are identified. This can, and often does, mean that the final outcome of the project is very different from what was imagined at the start. In traditional project management, things are very different. The project requirements are put together right at the start, usually before the project has properly kicked off. The problem with this is that this ‘crystal ball’ method of planning can lead to scope creep, due to stakeholders asking for a little more than they really need.

Testing and feedbackr
In traditional project management, the testing and feedback elements usually take place towards the end of the project run. By this point, everything has been designed and implemented and there is little scope to make drastic changes or improvements without major expense and additional time. With Agile, feedback and user testing is conducted throughout the process, giving the project teams plenty of evidence to make changes, improvements and to evolve deliverables. The downside of this is that this ongoing testing can be rather labour intensive, but can serve to save money in a big way compared to the late testing involved in the traditional method.

Deliveryr
The problem with traditional project management is that there is a set time period when the product is due to be delivered. In some cases this can be months or even years after the project started. This can mean the product is irrelevant or out of date because the user’s needs have changed during the process. Agile allows for this factor, with teams constantly reviewing their scope and direction, and being allowed the flexibility to change direction should the product no longer be desirable. This can cause issues with funding, however, because it is hard to write a business plan for a product that may be something completely different by the end.

Traditional project management certainly still has a place, and tends to fit in best where the environment is stable and the project needs to work to set times and budgets. Agile is a great way to manage projects in a more fluid environment, or in an industry where the pace of change is happening fast.