Are you able to be Agile?

07 March 2018

The pressure to deliver successful IT projects continues and keeping up with the scale, complexity and pace of change is more challenging than ever. Almost every organisation needs to respond to the digital agenda and those with an eye on their long term sustainability are looking to innovate through commissioning projects to investigate and develop solutions to transform their business models in order to remain relevant to their customers and to protect themselves against market disruptors.

Traditional project management techniques have had mixed results in managing IT change programmes with overruns, extensions and increased costs all too common. Some projects even end up being abandoned entirely after incurring considerable costs and failing to deliver the desired results. The UK public sector has had its share of highly publicised project failures, with attempts to implement a national NHS patient record system and the Ministry of Defence’s secure military network costing £ billions more than originally expected without the objectives of the project ultimately being delivered.  The private sector is not immune to project failure either. Apple spent a substantial amount of money on a project to develop an operating system in the 1990’s before the project was cancelled and Sainsbury’s challenges with a project to implement an automated fulfillment system is still cited as a case study. There are many others that have not hit the headlines.

In response to the limitations of traditional project management and the need for projects to be delivered more rapidly and effectively a number of new ideas and approaches have been applied over the last 10 years – one such example is the use of ‘Agile’ project management methods, which are now widely adopted.

What is Agile?

Agile has four key values:

  • Individuals and interactions are more important than processes and tools
  • Produce working software in preference to comprehensive documentation
  • Invest time in collaborating instead of negotiating with suppliers
  • Respond to change rather than following a predetermined plan.

Where traditional project management establishes a detailed plan and detailed project artefacts at the start then attempts to follow the plan and a pre-determined specification throughout the duration of the project, Agile project management begins with a high level idea of what is required then progresses by delivering specific elements of the work (sprints) in a short period of time, clarifying the requirements and refining the specification as the project progresses.

A sprint is a set period of time during which specific work has to be completed and made ready for review. These sprints are repeated to refine the working deliverables until they meet the project requirements. The key measure of project progress is this series of working deliverables. Agile removes the need for the whole project group to meet and discuss full project objectives throughout each phase. Smaller more focused groups meet more frequently to discuss very specific goals, react to changes in customer requirements and to identify and resolve problems quickly - rather than waiting until the end of a project phase before recognising that the customer’s requirements have not been met.

What are the pitfalls?

In our experience, the main pitfalls in applying Agile techniques are:

  • The approach is not always understood by the project team – It is not uncommon for suppliers to propose using their recommended Agile approach but in practice their teams on the ground do not always understand the approach. Certainly, business users often struggle with some of the Agile terms and the language being used.  This is likely to result in ineffective project management.
  • Even though the project planning at the outset is at a high level, Agile project management still needs to have processes that ensure that for each phase of the project, the deliverables are defined and are in accordance with the project requirements - Agile does not replace the need for clear project objectives and scope.  For one project that we reviewed recently, the project team members were unable to tell us their expected end deliverable and only expected to know the answer to this after they had completed a series of six planned sprints.  This project was in serious danger of going off the rails.
  • Successful Agile delivery relies on the right input from the right people.  Under Agile the delivery team is intentionally left to concentrate on the completion of tasks. Unless this is carefully managed and business users are engaged there is a risk that the delivery team may lose sight of the overall objective of the project. We have seen several examples where the end deliverable did not match user expectations. Engagement of the appropriate stakeholders during each delivery cycle is essential to avoid the risk that the system implemented does not deliver what was intended.
  • The Agile approach is not always appropriate for the project. In one recent example, we noted that the project sponsor had been expecting the majority of development and testing work to be completed through the sprint process. However, due to the nature of the project none of this could be undertaken until the business requirements and processes had been signed off. Since the sign off was scheduled for after the final sprint, the result was that almost no testing was performed before that time and significant issues were not identified until it was too late to avoid project delays.
  • Poor or non-existent forecasting is all too common with Agile. Budgets must still be agreed, reviewed and updated if project costs are to be controlled sufficiently.

Every project is different and establishing a ‘hybrid’ (combining Agile and traditional methods) approach to project management may be more successful. More often than not, a hybrid approach means that the approach has been thought through carefully and the method tailored to the specific project.

How should Heads of Internal Audit approach Agile?

Traditional project management methods lend themselves readily to internal audit due to their emphasis on formal governance structures, process and documentation and the steady implementation of a project plan. Agile projects are not managed in this way, so internal auditors need to be adaptable in the way that they approach them and seek to provide assurance.

The focus of Agile on producing working versions of deliverables and refining these iteratively does not mean that project risk is not being managed and that project governance has been abandoned. Most of the traditional project management artefacts will not be present but there should still be a mechanism for direction and control.  Governance may be light touch but it should not be absent.

Under Agile, the delivery team define the performance metrics that they will use and self-monitor e.g. tasks completed, resources deployed, re-work required, backlog of issues and value to the business at the end of each iteration. This information should be updated frequently and visible to business users and management.  If additional performance reports are required for senior management as part of the organisation’s wider governance, these become a task in each iteration and a specified output of the delivery team. The delivery team should therefore be able to demonstrate that project progress is being monitored and managed.

Traditional project management has clear break points in the project plan, which the auditor can use to determine when to provide assurance. Since project management under Agile is iterative, the timing of when and how best to provide assurance is less obvious and will need to be thought through more carefully based on a more detailed understanding of the nature of the project itself. 

Across BDO we have project and change experts able to support organisations to deliver successful change. Our expertise extends across the entire life-cycle of change from nurturing a new project idea through to project delivery and the realisation of value and benefits. Our teams have reviewed many complex projects and have a wealth of knowledge which we use to inform both practical and value add recommendations.

About the author:

Ross is a Director in our Risk & Advisory Services team and has worked for over 20 years helping organisations deliver and implement Business and Technology change. Having worked both in industry and as a business advisor he has the experience to blend formal good practice with the practical knowledge of how to deliver successful projects.


Web references: