Topic 9.9: Agile project management
As the name suggests, agile is a flexible response to delivery for those projects that cannot be perfectly mapped out in the planning stage.
Born from software projects where the end-state is known, but the process for getting there cannot be understood until the outputs of earlier tasks are realised, it is now widely applied in many industries (including sometimes, it should be said, inappropriately).
Indeed, the default for projects should be to complete planning before starting delivery; unless the specific circumstances of your project make this impossible – we’ll explain why in a minute.
Critically, agile does not excuse you from properly initiating a project – if anything, it is more important than ever to complete a comprehensive and robust business case, because overall delivery is focused more on outcomes than outputs, as we shall see.
What agile does particularly well is stakeholder communication through regular, programmed meetings.
I personally think the tight, time-bound meeting methodology is a perfect fit for standard projects as well.
Nevertheless there is a huge risk in agile projects that the schedules and budgets agreed to in the business case will overrun, as levels of uncertainty are that much higher.
We also know that the cost of change increases the further you get into any project; these costs can significantly blow out if we are unable to comprehensively benchmark them before we start.
Agile project management also depends on a high degree of team, management and stakeholder collaboration.
If this is not forthcoming, or even if a key stakeholder (such as a team member) changes mid-delivery, there can be serious consequences for the schedule as new members are brought up to speed.
That said, there is definitely a place for agile delivery methods, even within what we call the waterfall approach – that is, the standard lifecycle process.
Despite what some evangelists might say, the best-practice principles of project management are actually undisturbed by agile; if anything, they are more rigorously enforced during delivery!
I like to call it project management on steroids.
Therefore on smaller projects with clear objectives, tight, expert teams, but uncertain outputs, agile project management is strongly recommended.