Traditional project management vs Agile

Submitted by Tim Finch on Thu, 24/9/2015 - 10:23

Within traditional project management, we're all familiar with the time-cost-quality diagram. Let's consider that we want to build a stadium; the features are fixed and agreed on at the start. Let's consider for example that we'd like a stadium with 20,000 seats.  It's the time and cost which no matter how well they're estimated will be the variables; there might well be a delay in delivery of concrete which is likely to extend the duration of the project or the price of steel has suddenly gone up which will increase the project's cost. The quality is also 'at risk' - if the project's going majorly over-budget we might have to resort to hard plastic seats, not the deluxe ergonomically-designed seats from the brief.

With an AgilePM® project (based upon the DSDM Agile Project Framework), time cost and quality are fixed early on. There might be a fixed amount of time (number and duration of timeboxes) and resources devoted to this project (team size). The quality is also fixed as it's formally agreed at the start. This means that the deliverable features are the variables. For example, a team might be producing a mobile phone app, they have a list of features that it should and could include - these are subsequently prioritised according to the value they will produce. The team then decides how many features they are able to produce during each sprint or time box. In Agile, these features are in constant review throughout the project.

Traditionally, Agile has been applicable to software development because often, the team doesn’t know yet what's going to work, and the customer often doesn’t know exactly what it is they want. Only when a 'feature' is released into the market to use do the development teams get feedback. It's not only software projects which can benefit from Agile, here are some projects which fit well with Agile frameworks:


  • Catering - if you're charged with revamping a menu for a restaurant or a chain of restaurants, release dishes onto the menu as soon as you can, that way they're getting tested by your customers and you're getting real-time feedback. This is more effective than releasing a 'perfect' menu of dishes at the same time.


  • Digital marketing - there's no use releasing the email campaign, online banners and AdWords at the same time - releasing elements when they’re ready means you can test out whether the blue banner or the purple banner is getting more clicks and adjust the campaign throughout. Closing the feedback loop by keeping a close eye on analytics means that you can tweak your marketing tactics to make the most effective combination.


  • Department store - if you're introducing a new product line, start with releasing a couple of products, thus minimising your risk. Listen to your customers for feedback and adjust the product line accordingly. If after a few months you've had no interest from customers, reconsider the viability of the new product line.


The one thing to remember is that moving from traditional to Agile involves a significant change in mindset. With the traditional approach, you deliver exactly what was on the brief. In an Agile project, it's more fluid as your main focus is on discovering what works and produces more value which as a result is bound to keep the project sponsor happy!

So in brief: use PRINCE2®, or traditional project management techniques if you know what you're looking for. AgilePM® or PRINCE2 AgileTM  is best if you're keen to move to Agile, especially from a PRINCE2® basis but want to keep documentation and control. Scrum is the most popular form of Agile by far, it works well and is a little more radical if you're willing to loosen documentation and let the team find their own way.