March 26, 2012
Posted by on
Longer projects run, higher likelihood of project failure. One of the moves in recent times to reduce complexity in software development is to adopt Agile delivery approaches. The desire to build confidence and leave tangible benefits even if projects are cancelled has provided further impetus to adoption of Agile practices. This approach has delivered good outcomes for teams that work in in-house and product development teams. However, challenge remains in successful adoption Agile practices in contracted deliveries.
It is rarely the willingness of the project teams or suppliers that is the barrier, but the way organisations work. A quick review of how most organisations initiate projects will highlight this. In most organisations operational staff will identify areas of improvement. Organisations have processes to provide feedback to management to achieve this. Management then compile business case, which is then reviewed and approved by the organisation. It then moves through the procurement cycle, supplier selected and contracts agreed. These contracts are on the basis of deliverables (outputs in PRINCE2) from the project, rather than benefits.
Let us now review the consequence. The project is set up with A, B and C as deliverables. As the project starts, it becomes clear that modifying B will provide far more benefit, even if C is dropped off altogether. In an agile project, the customer is able to provide immediate feedback and the product backlog would be adjusted accordingly. Here the project team consists of suppliers who are under contract to deliver C. They cannot alter the required deliverables. The project team from within the organisation is also not authorised to make this adjustment.
As you keep moving up the organisation challenges still remain. Project governance is set up to hold people accountable for the delivery. Benefits are more difficult to quantify than outputs. Therefore the culture is usually to hold people accountable for the outputs. Modifications to business cases are usually treated as acknowledgement of omission, rather than as an evolution of the project.
So why this inertia for reviewing the deliverables in order to extract the best benefit? Consider what else the people in charge of procurement acquire for the organisation. For most things they are able to show something tangible – an air conditioning unit, an executive table, a new building. Other things they procure are services that are usually measured in time – 3 weeks of consulting. Software development is somewhere in between. You have time, the deliverable is something abstract and it is difficult to judge whether you got what you had asked for – a lot of grey areas. The people to judge is often not the ones that approve the procurement or control them. Auditing the procurement is therefore difficult terms of benefits. As a result you end up with controls on outputs.
In order to successfully embrace Agile delivery practices it is imperative that procurement and auditing methods in the organisation is geared towards measuring benefits, rather than outputs.