It can be quite daunting when planning a change management program such as driving the adoption of enterprise 2.0. One way to tackle planning for enterprise 2.0 is to take an iterative approach: this is through a repeating cycle of planning, doing, checking and then acting on the results. There is an abundance of valuable resources describing how to apply an iterative approach to project work as well as arguments for an agile approach.
Let’s take a look at an example plan:
Every iteration delivers something of value:
The project sponsors may decide to stop the project when they have realised enough value from the initiative. This means any iteration could be the end of the project. The iterations, releases and whole project is planned so that every initiative is delivering something valuable, such as a training module, an updated policy or a structure for internal blogging. Later iterations will be changed to course correct as people start using the output of the early deliverables.
Showcases let stakeholders see progress and provide feedback:
Each iteration finishes with a public showcase that is available to anyone to attend. The showcase let’s stakeholders, including sponsors and people impacted, see how the initiative is progress and what has been delivered during the iteration. It’s a chance to provide feedback and ask questions about the work underway.
Retrospectives let the team learn as they go:
At the end of each iteration the team will hold a retrospective to learn from what has gone well as well as what hasn’t gone well. The lessons learnt will be applied in the next and future iterations.
Communicating a compelling vision:
Taking an iterative approach doesn’t change any of the fundamentals of driving the cultural change required for enterprise 2.0 adoption. The deliverables will include effective communication and a compelling vision, they may include training, feedback and recognition.
Obviously the deliverables will be determined by the organisational needs and the goals of the project, this iterative approach provides an approach to delivering these in a way that builds support and incorporates early feedback.
As my team works through our understanding of the current situation and moves onto developing our proposal we hope to use this iterative structure for the implementation plan. There are many critics of agile approaches and arguments against, however, in my expereince it’s a valuable way to tackle organisational change projects, it’s particulary strong in building support from sponsors who can see things happening at early stages as well as from people affected as they are able to influence the changes that will affect them.
It’s early days and we haven’t yet determined the deliverables so I’ve mocked up a few to make the plan more meaningful. So, with this in mind if we’re just thinking about the structure, what do you think? What have I missed?
Some more reading (there’s a lot of software development examples because of the heritage behind iterative approaches):
The Agile Manifesto – the principles behind agile approaches to projects.
Continuous Delivery – looking at how Apple create products through releasing a minimum viable product to get early feedback
Articles on retrospectives – Singing the songs of retrospectives is a particularly good piece from Linda Rising, the doyenne of retrospectives
Time to get agile – Explaining agile for business leaders using examples at Telstra and Suncorp