A really expensive experiment

I was speaking at a PMI conference in Sweden and took the opportunity to listen to some of the other speakers, one of whom was Henrik Kniberg. Henrik is a guru on agile and lean and he told the story of a rather large public sector project in Sweden. The inadvertent experiment was that they did the same project TWICE!
To start with, Henrik discussed what “success” is and he defined it as being happy customers, happy users and happy development team. With apologies to PMI’s “triple constraint” he said to forget about time, cost and scope . . . actually this bit of the talk mirrored the start of my own talk at that conference, so “Mr Classic PM” and “Mr Agile” are on the same page. Why you undertake work is more important than what or how you deliver.

Henrik’s different perspectives on success, over and above the “triple constraint”. This thinking matches my thinking in Project Workout.

Henrik’s case study was all about improving society by helping the Swedish police force work more effectively. You’ve all read those dark, gloomy Scandinavian crime thrillers, so you get the idea. As we were in Sweden in “Wallender” country, it all seemed appropriate.
So, the first project was like this:

• Mission Improve society
• Requirements Unclear
• Delivery Agile (= Iterative/incremental)
• User involvement Continuous
• Team’s influence over technology choices High
• Technical platform Java

It took two years and comprised a series of releases, starting with the first one after 6 months, which the police hated, then after 18 months a nation-wide release and ending up with something they all really liked. SUCCESS!

Then “someone” had a bright idea to rebuild the whole thing in Oracle Siebel as Oracle said it would be better and cheaper. And as they were in a hurry to save money, they would go “big bang”. After all, they knew the requirements as the project had already been completed. So this is project 2:

• Mission Reduce maintenance cost
• Requirements Clear
• Delivery Big bang
• User involvement None
• Team’s influence over technology None
• Technical platform Oracle Siebel

This turned out to be a train wreck in slow motion:

Stakeholder response: outrage
Cost 200m KR (double that of project 1)
Time 24 months (as opposed to 18 months for project 1
Measured impact: Police blocked from using it several hours a day; error rate increased.

Lesson to be learned

So, the lessons are:

• Focus on solving user needs not just cost: effective nearly always out-strips efficient;
• Deliver iteratively and incrementally if you don’t know what you really need;
• Involve real users.

Beware of standard platforms:

• They might not be as standard as you think;
• Listen to your technical people not just to a vendor selling stuff.

How many of you are building major capabilities on the promise of using a “standard” platform? I can certainly think of one I was involved with recently!

How do you think the re-platforming should be handled? . . or even should it be done at all, if what is there isn’t broken?

What about migrating from one to the other? Should we always design this in from the start? Or is it like turkeys voting for Christmas?

So agile is always better, is it?

Oh, and the stuff about ‘agile’ and ‘big bang’? That is just a red herring. You should use whatever delivery approaches are appropriate and proportionate to what you are doing. I expect some people reading this have had senior executives issue an edict: “do all projects agile!” This approach is just as mistaken as not trying agile at all – it underlines the classic IT confusion between a development approach and a project method. It’s not a case of ‘agile’ versus ‘project management’. Nor of thinking ‘waterfall = project management’. ‘Agile’ and ‘waterfall’ are delivery methods. Project management is a wrapper, which can contain any number of delivery methods, depending on the type of deliverables being produced.