Using Agile Project Management for Continuous Improvement Projects
Project Management in CI Projects
For most Lean Six-Sigma practitioners, the heart of CI (Continuous improvement) Project is the A3 Project Plan, usually following the DMAIC (Define, Measure, Analyse, Improve, Control) structure. The Improve section typically includes some form of description of who is going to do what, when, preferably in a visual form such as a simple Gantt chart. But, for larger more complex CI project the A3 on its own can lack sufficient information or detail, and manage the project . There are two challenges here:
1. The project team needs to have project management skills to do this effectively, and, in my experience, this is often not the case outside of project management businesses (and sometimes even within those!)
2. Traditional Project Management techniques perform less well when there are many unknowns and where the scope can shift significantly across the project life cycle (I think we’re all familiar with moving goalposts), which is typical in CI Projects by their very nature.
Enter Agile Project Management
Agile methodologies are now firmly embedded in the field of project management, and are particularly suited to projects where the potential for scope shift and significant unknowns exist at the outset of a project. This makes Agile a good fit to CI projects, which necessarily incorporate a period of analysis and solution development. The reasons Agile adapts well are:
In agile, not all the desired deliverables listed at the project concept phase are necessarily expected to be finished during the project life. Instead, each deliverable is assigned a priority (usually using the MoSCoW method; Must Have, Should Have, Could Have, Would Have/Won’t Have). Higher priority items take precedence over lower priority items, and the aim is to complete all the Must Haves, at least a majority of the Should Haves, and then the remainder opportunistically as the allocated time allows.
The time allocated to complete each deliverable is based on relative estimates rather than the absolute estimates used in traditional project management. To do this, the largest and smallest deliverables are identified and allocated weights (Story Points) that bookend the range, with all other tasks then being scored relative to these upper and lower limits using a technique commonly known as ‘Scrum Poker’. This allows a project plan to be created based on the number of story points the team expects to finish in a given period (the ‘sprint’). As items are completed, the true ‘velocity’ (story points achieved per sprint period) of the project is revealed. Future sprints can then be loaded accordingly.
The Agile process allows dynamic review and adjustment of the project as new circumstances are discovered, making it far more adaptable than traditional project management techniques.
How is Agile used in CI Projects?
The Agile Project method breaks projects into Epics, which are defined on an Epic Card. Epics are then ‘sliced’ into user stories which are documented on Story Cards (User Story Cards can be considered as equivalent to Work Packages, part of a Work Breakdown Structure, in traditional project management). In Continuous Improvement projects, I would usually use a traditional DMAIC A3 document as a substitute for the Epic Card and have not found it essential to re-write the DMIAC into an Epic Card. What I have found useful is to re-write the Work Packages into User Stories. Each Story Card describes a deliverable from the perspective of a user, outlining the tasks that need to be completed and the validation criteria for completion of the deliverable. Once all the User Stories have been written, they can be prioritised using MoSCoW and allocated story points using the scrum poker technique. The end result is a set of story cards, each prioritised and rated for the amount of work it represents relative to the other story cards.
Why is this beneficial to CI Projects?
CI Projects often suffer from poor planning and having to compete with day-to-day operations. Agile provides a mechanism to create an implementation plan that progresses as a series of sprints, with adjustment made at the end of each sprint. This maintains momentum, while respecting the shifting nature of a CI project, which needs to adapt to new information and findings as it progresses.
Actually, given that Agile was, from its inception, clearly an effort to incorporate lean concepts such as smaller batch sizes, continuous flow and visual management into software development, it should not come as a surprise that it is a good fit.
If you would like to know more about Agile Project Management and how it applies to Lean Process Improvement, call us on 1800 088 494 or go to www.kallistaconsulting.com.au
