There is no argument that agile can work well for some projects, but it is fair to say it is not a universal panacea. The originators of DSDM, right at the start, identified types of projects that would benefit from the approach and, by default, those that might not. Agile teams should for example, as far as possible, have user representatives empowered to define and modify user requirements without having continually to refer to distant authorities. If this is not the case, then the full benefits of agile will not be reaped. Available agile approaches also vary hugely. If agile is the road you want to go in, there remains the question of the brand of agile that is going to be your vehicle.
In manufacturing, there are two distinct phases: product design/development, and then the actual production of goods for the market. ‘Agility’ can be applied to both these processes. In the world of software, some agile approaches, such as Scrum, are very much based on the product design model. On the other hand Lean adopts a production line model.
Earlier in January, Gary Palmer, of Critical Point Consulting, gave an interesting and useful talk to PROMS-G in London on critical chain project management (CCPM), a non-agile approach that follows the production line model. Very crudely each activity on the longest path through the project is treated as a process in a production line. Parallel activities to the main line are treated as sub-assembly lines that feed into the main path.
For Project Eye, the most useful take-home idea from CCPM was that when a software developer is asked for an estimate of effort for a task to be done, they firstly identify the most likely duration if there are no unforeseen obstacles. They then think about common annoyances and glitches that can hold up progress. They then add a safety margin to allow for these. The problem, according to CCPM advocates, is that if this estimate is accepted, the task will inevitably expand to meet the estimate + safety margin and time is lost.
The CCPM answer is to ask the estimator to provide two estimates: the most likely duration and a proposed safety margin. The first stripped-down estimate becomes the target for the individual activity. The safety margin contributes to a common pot, which makes up a buffer zone at the end of the project. The project manager becomes the custodian of the accumulated contingency, not the individual developers.
The longest path through the project is called the critical chain, which is similar to the critical path except that resource constraints are taken into account. Project Eye got the feeling at the meeting that there was some unease about this. Demand on staff and their availability during a project can be very volatile which suggests that the activities making up the critical chain might also be subject to frequent change. This is not to say that CCPM might not be helpful, just that some project managers might be cautious about it.
A positive is that ProChain, a software tool that supports CCPM, has been constructed as an add-on to MS Project, so that, hopefully, the adoption of CCPM could be seen as a progressive development from existing practices, rather than something that throws tried and tested approaches out of the window.
Of course, Project Eye is guessing at a lot of this based on the content of the presentation. There must be lots of people out there who have tried CCPM - what has been your experience? Why not let us know?
