How Agile Project Management is different from Traditional one?
Posted by Babou on May 14, 2008
There is a proverb, “You can’t teach an old dog new tricks.“ But this is not true in Project Management. Managers need to learn new techniques and adapt them as quickly as possible to bring project success.
Traditional project management methodologies widely used across different fields. It involves very disciplined and deliberate planning and control methods. The traditional PM approach, is a linear approach where you try to get it all done at one time. Everything should be planned before start executing tasks in the defined order. Traditional project management is best suited for engineering projects like construction, but it is used in all fields nowadays including IT.
The Standish Group 2006 Survey on IT projects revealed,
* 46% of projects over time or budget & 19% of projects failed;
* $80 -145 billion per year is spent on failed and canceled projects;
* Meta group estimated 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management.
In today’s IT world, organizations needs improvement in performance and they expects for – rapid product delivery, increased revenue, more flexibility, coping with change, good quality. Agile Project Management(APM) meets these expectations excellently especially for IT projects.
What is Agile Project Management?
Agile Project Management (APM) is a way of managing projects to deliver customer value via adaptive planning, rapid feedback, continuous improvement and intense human interaction and collaboration.
– Sanjiv Augustine
Agile methodologies are new approach in Project Management and it is effective for IT projects where requirements changes too often. In APM, processes are iterative & incremental. Agile Project Management is particularly appropriate for projects that have:
* clear project value
* innovative business requirements
* unstable requirements
* incremental feature-driven development
* early and active participation of stakeholders
* resources, time & budget are limited
* visual documentation
* collaborative co-located development team
References:
Sanjiv Augustine’s Web Site: http://www.sanjivaugustine.com/
Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html
Demian Entrekin said
I too am a proponent of the agile approach, but I must say that I’m not so sure of the value of the Standish statistics. For example, the number 19% of projects failed is a tough number to get your head around. What does that mean? I’ve seen great projects that were simply tagged as “failures” because it suiting the political climate, and I’ve seen much the same of “successes.”
I would also point out a fundamental assumption gap between the agile approach and the Standish comment that “60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management.” With agile, these concepts are turned inside out and the Standish numbers may not make sense anymore.
In my view, software developers need to spend more time on prototypes and true market testing. This is inherently iterative and fits in with agile.
Babou said
Hi Demian Entrekin,
Thanks for your valuable input.
I agree with your statement on ‘Project failure’. Usually, there is always a healthy argument on deciding which parameters need to be considered to declare a project as ’success’. In their survey, Standish group analyzed certain(or limited) parameters to tag a project as ‘failure’.
Also, these survey figures show most of these projects followed traditional project methodologies and not agile. I think, by adapting Agile PM, one can reduce project failure percentages.
Babou said
I found an excellent article on ‘failed successes’ in CIO Magazine – “Applied Insight – Tracks in the Snow” By R. Ryan Nelson.
Link: http://www.cio.com/article/24423/Applied_Insight_Tracks_in_the_Snow
Though the article dated Sep-2006, It is worth reviewing even today.