Talk given at

'Managing Change' conference

organised by Public Service Events

28th November 2012

held at the Barbican Centre, London

Agile Project Management for GovernmentAgile Project Management for GovernmentAgile Project Management for GovernmentAgile Project Management for Government::::

TTTThe he he he AgAgAgAgile ile ile ile approach saves the approach saves the approach saves the approach saves the FBI Sentinel ProjectFBI Sentinel ProjectFBI Sentinel ProjectFBI Sentinel Project…………

Brian WernhamBrian WernhamBrian WernhamBrian Wernham FBCS FAPMFBCS FAPMFBCS FAPMFBCS FAPM

© Brian Wernham 2012 CC BY-NC-ND

1

The Agile approach saves the

FBI Sentinel Project*

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.

The questions being asked of me are:

How do we seamlessly integrate How do we seamlessly integrate How do we seamlessly integrate How do we seamlessly integrate

technology into business change?technology into business change?technology into business change?technology into business change? 1111

• 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

How can we involve more medium sized How can we involve more medium sized How can we involve more medium sized How can we involve more medium sized

companies in the supply chain? companies in the supply chain? companies in the supply chain? 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 How do we lead this change to 'Digital, by How do we lead this change to 'Digital, by How do we lead this change to 'Digital, by

Default' faster, with fewer resources and Default' faster, with fewer resources and Default' faster, with fewer resources and Default' faster, with fewer resources and

directly manage medium sized suppliers?directly manage medium sized suppliers?directly manage medium sized suppliers?directly manage medium sized suppliers?

1

I put it to you that there are two alternative

approaches to implementing 'Digital, by

Default' - and only one is viable.

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 don’t 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!

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.

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.

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, don’t 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 long-

standing 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.

A 'Waterfall' approach is often predicated on a

‘Big Design Up Front’.

2

'Waterfall' and 'Big Design Up Front' go

together like a horse and carriage - one

requires and encourages the other.

The results are often catastrophic.

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.

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.

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.

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.

3

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.

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

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!

Yes! And at sixty million dollars it was

expensive lipstick!

And the FBI Agents soon stopped using the

temporary web screens.

4

Lockheed Martin are ejected

In December 2008, Chad Fulgham was

appointed as the new CIO.

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.

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.

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

5

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.

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

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.

6

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 Brian Wernham's new book, "Agile Project Management for Government" was published this Brian Wernham's new book, "Agile Project Management for Government" was published this Brian Wernham's new book, "Agile Project Management for Government" was published this

summer by Maitland and Strong.summer by Maitland and Strong.summer by Maitland and Strong.summer by Maitland and Strong.

brian.wernham@gmail.com

1 UK Cabinet Office, “Digital Efficiency Report,” 2012, Figure 10,

http://publications.cabinetoffice.gov.uk/digital/efficiency/digital-efficiency-report.pdf

2 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 Wernham, Brian. Agile Project Management for Government New York, London: Maitland and Strong, 2012