Talk given at 'Managing Change' conference organised by Public Service Events 28th November 2012 held at the Barbican

Centre, London

Government: Agile Project Management for Government:

Agile Project The Agile approach saves the FBI Sentinel Project

Brian Wernham FBCS FAPM

Brian Wernham 2012 CC BY-NC-ND

The Agile approach saves the FBI Sentinel Project

The questions being asked of me are: How do we seamlessly integrate technology into business change? 1 The Cabinet Office expects one in four government transactions to become digital by 2017 Then there is an 'inflexion point' - a major acceleration - over half of the remaining transactions are expected to be digitized in the next three years

Brian Wernham FBCS FAPM Author and Consultant Good morning to you all! In talking with my colleagues - in central departments and delivery agencies, I see a massive shift coming in the challenges we face. We have to move, and move quickly, to 'Digital, by Default'. The aim is for government to deliver everything online that can be delivered online.

How can we involve more medium sized companies in the supply chain? Are we ready to manage sub-contractors more directly? Spend on smaller technology contracts is expected to more than double2 So here is the issue that we will address together today: How do we lead this change to 'Digital, by Default' faster, with fewer resources and directly manage medium sized suppliers?

I put it to you that there are two alternative approaches to implementing 'Digital, by Default' - and only one is viable.

What is a 'Waterfall' project and how does its inherent problems relate to those of Big Design Up front? Well - when projects take a 'Waterfall' approach they divide work into discrete steps. One cannot start a new step until the previous step has been completed.

The Traditional Approach

Firstly, the traditional, monolithic, 'Big Design Up Front' approach of massive 'all or nothing' 'Waterfall' projects. Or, alternatively, the incremental, 'Agile' approach using 'Just Enough Project Management' to implement the new processes and supporting technology. Are the inherent problems of 'Big Design Up Front' and 'Waterfall' projects so difficult to explain? I dont think so. First, the problems with Big Design Up Front. You may recall an episode of 'The Simpsons' where a car manufacturer decides that Homer, being an average American, is the perfect person to design a new car. Homer is given an entirely free rein in the design, and specifies a car with every feature he could ever want. A bubble dome, a Rolls Royce radiator - and huge tail fins!

Once one has committed to swimming downstream, it is impossible to return to an earlier stage without a lot of effort as difficult as trying to swim up a Waterfall. Now, dont get me wrong. A 'Waterfall' approach is often unavoidable. For example, in making changes to mainframe systems. 'Waterfall' can produce good outputs if requirements are stable, if there is a longstanding change team in place, and if the technology is well understood. But that's a lot of 'ifs'. The fundamental problem of the 'Waterfall' lifecycle is that it relies upon pinpoint accuracy and perfect logic at every step if it is to produce a workable solution.

This car turns out to be totally unusable, and far too expensive to produce. An example of the result of a Big Design Up Front.

A 'Waterfall' approach is often predicated on a Big Design Up Front. 1

'Waterfall' and 'Big Design Up Front' go together like a horse and carriage - one requires and encourages the other.

The FBI Case Study

In 2001, the Oklahoma City bomber was about to be executed. Just one week before the date of the execution it was revealed that over 700 documents had not been disclosed to the defence. The FBI had forgotten to send materials and in many cases had lost evidence. The legal process was thrown into turmoil, a stay of execution was granted the FBI came under severe criticism. An investigation showed that the combination of the old computer system and outdated manual processes were to blame.

The results are often catastrophic.

Attempt 1
The FBI decided to set up a project to modernise their organisation with a budget of $400m. The project was planned in classic 'Waterfall' fashion. A grand design was drawn up before work started on the development of what was to be a monolithic system. All testing would be left to the end - the whole system would go live at once a 'big bang' implementation.

The Alternative: the Agile Approach

I want to explore the advantages of the alternative - the 'Agile' approach - through a story. A case study that resembles a scientific experiment where, after, two failed 'Waterfall' projects, an 'Agile' approach succeeded. In half the time and at half the cost. It is a compelling tale of how 'Agile' leadership can deliver. This is the story of 'Agile' success at the FBI.

Within a year, the classic symptoms of 'Waterfall' project failure started to reveal themselves. Despite $78m of additional funding after the 9/11 attacks it became obvious that the project would not deliver on time. Up front contracts with suppliers bound the project to a 'Big Design Up Front' based on unproven web technology - the testing that could have revealed these flaws came too late to allow a change of direction. It became evident that a total re write of the software was required. 2

Audit reports took a traditional view of what went wrong: more discipline was required more detail and planning needed. So with additional controls and oversight, work continued, but each year the deadline was put back by another 12 months. Every year a new project executive was appointed, but eventually the project was cancelled. Unfortunately, the FBI and GAO analysed the project failure using a 'Waterfall' perspective. These experts pursued the line of thought that if more detail had been planned upfront, with a more strict set of 'Waterfall' processes, then failure would not have occurred. But one factor that was not considered was whether more top down control could fix a broken 'Waterfall' approach.

comprehensive, but theoretical statements of work. The FBI awarded Lockheed Martin a contract to develop the Sentinel system at a cost of $305m. An additional $120m was allocated for FBI staff to track and oversee the work. That's one quarter of the budget being spent on detailed planning and control of the contractor, who in turn was carrying its own detailed planning and control! The new system was expected to take three years to build, so, in the meantime FBI Agents were given a web interface to hide the screens of the old, difficult to understand mainframe system. But the business processes remained unimproved. As a senior manager at the time later explained: "The new screens just allowed agents to interact with the old system through a sexy looking Web browser. Some called it lipstick on a pig!

Attempt 2
So - a second attempt to modernise the FBI was initiated - the "Sentinel" project was born. But the planning assumptions again took a 'Waterfall' approach and relied on a 'Big Design Up Front' - the delivery would take years to come to fruition. But everyone agreed that the problems of the previous project would be avoided this time. A great deal of effort was spent carrying out a beauty parade of suppliers. A desk based exercise scored suppliers proposals against Yes! And at sixty million dollars it was expensive lipstick! And the FBI Agents soon stopped using the temporary web screens. 3

Lockheed Martin are ejected

In December 2008, Chad Fulgham was appointed as the new CIO.

When it came to final testing, one year late in 2010, the stakeholders rejected the system, even though it was theoretically compliant with the original specifications. The dream of implementing electronic information sharing before the end of the decade had been shattered.

Chad Fulgham

Fulgham, who came from Wall Street, brought a business mentality with him that favoured quick results rather than drawn out planning. Although status reports were still optimistic because of the apparent comprehensiveness of project controls, Fulgham saw that little had been delivered, and that key tasks were well behind schedule. The new CIO now required outputs to be delivered every 3 months. But the project still remained bound to detailed specifications and inflexible plans. As functions were delivered, the users found that they did not meet their requirements, and the technical approach needed to be reworked again and again. Did the additional $120m spent on duplicating and checking the detailed project plans help? No. The project structure was large, unwieldy, and exhibited a huge optimism bias. Status reports were full of facts and statistics - but they never reported even one part of the project as being in trouble.

The Agile Approach Saves The Project

Fulgham now announced that he would take direct control of the project. He prioritized the existing requirements to focus on the most valuable. He reduced the project from over 125 heads to a team of just 55. Most significantly, he adopted an 'Agile' approach. He got the team to use the 'Scrum' Method, with a Scrum Master coordinating the development team. This is a role different from that of a project manager of a 'Waterfall' project. The Scrum Master leads and enables the team, rather than managing it. The original, monolithic requirements document was modularized into 670 separate 'user stories' each one describing just one end-to-end process that the system needed to do. Work now started to develop these user 4

stories incrementally. Each cycle of work (or sprint) was two weeks long. At the end of every sprint, all testing had to be complete and demonstrated to project stakeholders. After a few sprints, it became possible to forecast the rough timescales and start to plan the dates for incremental business change.

Success
By June this year, the system had been delivered using only half of the budget. Agents are now using the system on real cases. In the first quarter of this year alone, over 13,000 agents progressed over 600 cases, meeting or exceeding all expected targets. Firstly: Being very incremental. When Fulgham was appointed the FBI Chief Information Officer, he had to deal with a non-performing 'Big Design Up Front' contract. By breaking the work into shorter phases, each 3 months long, he placed a forensic spotlight on the supplier's failure to deliver. But this was not enough. It merely flushed out the symptoms of the problem - it did not solve it. Fulgham had to take direct control of the project, and focus the team on very short increments of work - each fully integrated and rigorously tested, and approved by stakeholders. He helped the team to claw its way back to success - two weeks at a time. The lesson here is that management became involved empirically - seeing the proof of the pudding with their own eyes every few weeks, rather than relying on status assessment by proxy through paper reports and committees. The second 'Agile' leadership behaviour that Fulgham exhibited, was 'light - tight' management discipline. Let me explain. 'Light - tight' management ensures light management of the team, whilst senior management follow tight disciplines. The light management of the team is more than just delegating decisions. It is about making it clear that decision-making belongs with the experts working at the coal-face. 5

The three-year 'Agile' project has now delivered - at a total cost of only $99m. A success after 10 years of failure and $597m wasted on the two previous aborted 'Waterfall' projects.

Conclusions
What lessons are to be learned? My research has identified nine leadership behaviours which enable 'Agile' success. Two of these were critical in the case of the recovery of the Sentinel project. 3

Just as important - 'tight' management discipline was exhibited at senior levels by getting hold of the risk and managing it directly. Fulgham did not accept that risk can be completely transferred to a prime supplier. Risk always remains with the government no supplier can bear the real costs of failure of government to deliver. There is now an extensive literature available on 'Agile' methods and best practice, but most of it is based on a leap of faith it is not evidence based. What many people in your position have told me they need, is a credible, evidence based argument that puts the business case for 'Agile' to the highest levels of leadership in public service. I have spent the last year researching projects in governments around the world to find

'Agile' success stories - and I have found them. The Ministry of Defence, US Veteran Affairs, the Government Digital Service, Managing Social Housing in Australia of course, modernisation at the FBI. All over the world these pockets of excellence demonstrate that government projects can be Agile. So, to go back to the question I posed at the beginning of my talk. An 'Agile' approach will enable you lead the change to 'Digital, by Default' with fewer resources, in less time and enable effective direct management of suppliers. Well, I hope that I have convinced you to look more closely at the 'Agile' approach and to consider using it on government change projects.

Thank you!

Brian Wernham's new book, "Agile Project Management for Government" was published this summer by Maitland and Strong.

brian.wernham@gmail.com

UK Cabinet Office, Digital Efficiency Report, 2012, Figure 10, http://publications.cabinetoffice.gov.uk/digital/efficiency/digital-efficiency-report.pdf UK Cabinet Office, One Year On - ICT Strategy Progress, 24/05/2012, 7, https://update.cabinetoffice.gov.uk/sites/default/files/resources/One-Year-On-ICT-Strategy-Progress.pdf
3 2

Wernham, Brian. Agile Project Management for Government New York, London: Maitland and Strong, 2012