Skip to content
Our website will be unavailable from 17:00 GMT Wednesday 20 November until 9:00 GMT Monday 25 November while we carry out important upgrades.

If you plan to update your membership, book an event or access APM Learning, APM Community or use other resources, please do this outside of these dates.

The 15 November Chartered Project Professional submission date is unaffected.

Thank you for your patience.

Why do we need a guide to the governance of agile projects and change?

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

Agile working has been greeted, by some, as the latest saviour of projects. At the same time, investors and directors of project work are hearing that they will not be involved in agile projects as all the work will be controlled at the workface. This has caused some alarm in the senior levels in organisations and help was requested.   

Consequently, the APM Governance SIG has developed a guide to the governance of agile change. Directing Agile Change is aimed at de-bunking some of the myths and providing good practice on how these new style projects should be controlled by organisations.

Agile is not a panacea – it should be applied in certain circumstance but not others – the guide provides guidance and is agnostic to methodology. 

The myths
Agile working is about collaboration and ‘letting the dog see the rabbit’ by iterative and early deliveries of products to users and customers with a view to avoiding nugatory work. This allows the products to be made fit for purpose incrementally and importantly tailored to the priorities of the investment.
Myths have grown - inaccurately - hinting that  anarchy will break out with engineers and project staff  doing what they want without recourse to documentation, reporting or business cases which form the normal fabric of good project management. These myths are tackled and explained in the guide. 

The principles
Agile projects are ‘different’ and need a different governance approach and mind-set that recognises and supports the degree of empowerment undertaken. New behaviours are required by directors and leaders; insistence on traditional measures may make agile the worst choice, so behaviour and culture are key. Governance must be supportive not directive to succeed and the sponsor in particular will have different relationships with the work and the project team. 

Checklists
Checklists are provided for the key governance roles within an agile project environment(the board, sponsor, project manager and project reviewers).  We challenge the reader to think slightly differently. The thinking is not about throwing away the popular guidance in Directing Change, the definitive project management governance piece also published by the Governance SIG, but supplementing and altering the disciplines of good governance to new behaviour. We are not providing a recipe to be slavishly followed.

After all, good governance is one of the critical factors in project success. I commend this publication to you. 


The Directing Agile Change guide is available here, APM members receive a 10% discount.

1 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Tim Podesta
    Tim Podesta 28 March 2017, 07:28 PM

    I have downloaded the Directing Agile Change pdf and was looking for a place to comment and raise a question so have posted here. I found the guide extremely useful to understand better the concept of projects which have incremental scope and phased delivery. Coming from a industry where Construction is the mainstay of projects small and large I have always struggled to relate to the Agile approach. With the guide and some lateral thinking I have a vision of a project which has a fixed element of scope with flexibility for managed expansion to include incremental scope and phased delivery. Normally this flexibility would be left for a subsequent project but I can see examples of where multiple projects could be working in parallel. I would be interested in the views of others.