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:
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.
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.