I have been thinking about how you could best apply agile principles to project management for a while – you can read some of my earlier musing here. This draft programme design has been drawn from my experience in both action research and also agile development – the latter being in a management rather than practitioner capacity but I think still valid here. The objective is to create a project management methodology which meets a number of criteria:
- It ensures clarity about objectives and outcomes at the same time as being able to be flexible about methods
- It is able to ‘listen’ and react to changes in context and new learning
- It can integrate technical/non-technical sides of a project
- It provides robust governance to large scale projects
I think the essential need is to balance flexibility and adaptive behaviour with accountability and clarity of purpose.
My secret objective is to make Prince2 obsolete because I think that it has run its course and has too many outdated assumptions (such as a fixed context for development and control of all the variables) which I think means it is no longer fit for purpose. As our development methodologies move on its essential that our management systems do so as well.
The structure I am outlining here is something that we are trialling with a few different projects at the moment and seems to work. I am going to use this post to define the experiment (in an action research sense) in more detail so that I can properly test this with the project participants over the next few months. The (slightly rubbish) diagram below provides an overview:
Agile programme design overview
The intention is to create a programme which is modular and resilient to one element either failing or not performing as expected. The programme structure I am suggesting has four distinct elements:
- Vision: A document that captures the future or change that you are trying to create but which is updated at the reflection points throughout the project. Ideally this needs a very simple ‘mission statement’ with more narrative around it. The more approachable this statement is in terms of language the more useful it is.
- Research and learning: A process of actively setting research questions and test criteria and then learning from and disseminating the answers to these
- Operational plan: A critical path – a clear articulation of project milestones
- Project or experiment plans: More detailed project plans for the modular components of the programme
Communication needs to be built into each of these and I would hope that the programme would operate in an ‘open by default’ mode whereby participants are actively talking about work in progress rather than communication being funnelled through any kind of gatekeeping process.
Programme rhythm
This design is intended to be iterative and so one of the key questions is what is the ‘sprint’ period. In tentatively applying this we are finding that different situations require different sprint periods and we have been working with projects with both 2 and 3 month sprints. A sprint will have very clear objectives, research questions and project outcomes all of which contribute to the vision of the future. At the end of the sprint period there is a reflection point built in to examine learning, reconfigure plans for the next sprint and also test progress against to overall vision and where necessary amend it.
The idea is that the project steering group or sponsors are the audience for that reflection in order to ensure project governance and accountability but where possible this is an open process which all stakeholders can participate in.
One of the things I like about this approach is the way it can encourage collaborative leadership as different people can lead on different aspects and this brings with it the need for continual dialogue which is also useful. It can also bring people together across disciplines – for example in one project the research strand is shared between the UX and community engagement teams.
What’s missing and what’s next?
I want to think more about how the concept of ‘tech debt’ might be used here to reflect the compromises you make to ensure progress as I think this could be a critical element to how you go on to operationalise the output of the project so that is one of the questions I am leaving open at this stage. I also want to see whether or not we can actually get people to accept that the project management overhead is shared in this model where previously it was often one poor soul with a lot of GANT charts. I also think that the willingness of the steering group to engage with the reflection aspect will also be critical.
At the moment we are trialling/testing aspects of this but we are about to put the whole thing into the field in two big projects and this will mean creating templates of documents etc etc. I will the try and do some fieldwork with participants to see how it is working and will try and blog about this – I am particularly interested to see how that first ‘reflect’ session goes and whether we are able to evidence adaptive behaviour against the vision. it would be good to know if anyone else is trying anything like this – or if you have comments on what I am suggesting here so please comment or get in touch if you have thoughts on it – I will be adding to this strand on the blog as this develops.
Steve Halliday
Catherine, interesting thoughts, as usual. I have a slightly different view: Agile is to Prince as beer is to wine.
I have a friend who would only drink beer. That’s all he liked, so that’s all he drank. Then he discovered wine. “That’s much better” he said. From now on I’m only drinking wine.” He threw out all the beer.
“How sad” we all said. They are both nice. I like wine with a meal and a pint of beer in the pub with a few friends. They serve different purposes.
Agile and Prince are a bit like that. You don’t have to choose one and spurn the other. They also serve different purposes. Agile is really good for user interfaces and user rich process design. Try something out, see if they like it change it and try something else.
You wouldn’t want to depend too heavily on user feedback for a space rocket landing system. Try it out, kill the first astronauts, change it, try it again – would be a bad strategy. You’d want a precise requirements specification and be very confident it is “right” before you launch.
Some projects need a bit of both. A payroll system has right and wrong algorithms to calculate statutory sick pay. If it’s 1% wrong it’s pretty much useless (probably best with a good requirements specification). But a user interface that people can like or dislike (best with agile).
There is a reason why Prince has been adopted by the construction industry. It helps big companies waste less money.
Some analysts have suggested that Universal Credit has run into problems because an agile method has been used where a waterfall method like Prince would be better.
http://www.newstatesman.com/business/2013/09/lets-be-honest-universal-credit-disaster-was-not-simple-it-screw
Others suggest it was less of a problem with Agile, than with the procurement through one large supplier. Although the components of UC could have been broken into small agile modules, their interdependencies would need to be project managed.
DSDM, an early agile method, has a model similar to the one you describe:
http://www.devx.com/supportitems/showSupportItem.php?co=32836&supportitem=figure3
And actually even the fans of Prince don’t think agile is at odds with waterfall
http://prince2msp.com/2011/04/14/prince2-itil-agile-can-i-have-the-best-of-all/
Agile in the construction industry sounds hard. “You don’t like the window on that wall? No worries, I’ll just move it over to that wall. Pass the mallet.” But actually there has been some interest in managing multiple construction contractors with agile.
http://chrisklein.wordpress.com/2009/11/02/an-agile-construction-project/
So don’t throw the beer out and kill the prince when you get the wine in. Like Grandad used to say, “get the right tool for the right job”.
curiouscatherine
Mmm…perhaps the issue here is that at present people are lacking a real choice in this. At present large scale programmes tend to managed in a very linear way and while good project managers always work around this restriction the underlying governance and decision making model is all about the getting to the finish line as defined at the start rather than achieving an outcome by reasonable means. On the ground people may work in an agile way but as long as the decision making support is linear the programme will always be ‘warped’ in some way.
I think the rocket landing analogy is flawed though – actually NASA used hugely experimental methods to get to the moon and ran very adaptive engineering programmes which were led by scientists. They backed this up with rigours change management and a sense of ‘permission’ for the people making the frontline decisions (sorry – I am a space nut – what can I say).
You are right – killing off Prince2 is a bit extreme and were we are really working in a fixed context – or in a context where we don’t want to get distracted – then it is useful and works. My argument is that many bigger programmes need more adaptive decision making and as a result a more adaptive structure designed into them – its not just about agile development from the coders, its about agile thinking around the context as well.
Am looking forward to the conference to debate this further!!
C
Nico Viergever
Poor understanding of PRINCE2,is unfortunately very, very common. Also in this discussion I noticed strange perceptions.
A fixed context, a Waterfall approach? Please, guys. Read the manual. Ask back your training fee, if you took a course.
Never ser the Principles (http://www.viergever.info/en/prince2principle.aspx)?
The combination of Management by Stages and Tolerances, as well as the approach to plans should tell you that the context is not fixed. The combination of the focus on products, management stages will make the Waterfall concept impossible.
Here is the real difference: PRINCE2 is there for the project’s customer to make sure the right things are dome. IT Agile approaches are there for the project’s specialists to make sute things are done the right way.
PRINCE2 is there for the wine- or beer drinker. Agile approaches are there for the waiter.