How to avoid 'too many cooks spoiling the silicon broth': an approach to making public and third sector multi-agency IT procurement work better

Most public sector IT procurement is multi-agency. This means that a ‘partnership’ or ‘collective’ of organisations or departments are given the task of defining needs and outcomes for an IT development project and then managing its delivery, role out and support.

The job of defining what is needed for an IT build, re-build or next stage development is difficult enough if a single agency is responsible for it. This is because needs, legislation and technology change continually. Add to this a multi-agency client and the best case scenario is one where perhaps part of the commissioning group get part of what they hoped.

A lot of projects however don't turn out for the best. In many cases the project will simply fall apart leaving a legacy of wasted public money, broken and unusable systems and tattered relationships both within the procurement group and with the developer. This can still happen, even that everyone was trying as hard as they possibly could and a recognised project management method like Prince2 was used throughout.

Some of the reasons that multi-agency IT procurement fails are:
Expectations and needs are rarely fully revealed and unpacked sufficiently to avoid misunderstanding between agencies
IT solutions are often expected to provide miracle cures to inter-agency working that are really cultural or people problems
Rigid implementation of big clever designs allows little room for changes to requirements to be added or systems to be developed in such a way that they can cope with change effectively
It isn’t until the thing has been developed that people realise that that wasn’t quite what they needed

These problems can be avoided and addressed through the adoption of methods that have worked effectively elsewhere in the IT industry. Such methods do not need to replace the methods that the government wants to see used for development (Prince2), but they can compliment Prince2 to provide new tools to fix common problems. These tools come from the group of methodologies known as Agile.

Agile takes a different approach to the process of specifying development needs and outcomes by placing much greater emphasis on defining the exploration and prioritising of such needs and outcomes through common language and thorough exploration. Agile also assumes that change is constant and therefore is the friend of IT development rather than the enemy waiting to derail well intentioned projects. But most importantly from the point of view of multi-agency procurement, it can be applied very effectively to ensure that there are no hidden or unrealistic expectations hiding in the specification or the contractual and design documentation that will lead to development failure.

Agile Lab use facilitated story writing workshops to help multi-agency teams unearth the potential problems before they become real problems. We also use workshops to help get derailed projects back on track.

We believe that the people involved in broken multi-agency IT procurement, whether the supplier or the supplied are generally well intentioned and will try the hardest. However, this alone is not enough. Without the right tools for the job problems will fester and can lead to disaster. We can help get your project back on track or heading the right direction quickly, saving you money, time and stress.

Get us in and get on!

What Agile isn't : five myths you may have heard about Agile

Myth #1 It's a silver bullet. Agile won't solve all your problems. Agile is a different way of planning and delivering projects. That deals well with constant change in project goals and development environment. Studies have shown that development using Agile can drastically reduce the number of software defects and improve the ability of teams to estimate how long it will take to write new software. But there are many other problems that Agile can't solve.

Myth #2 Using Agile means that you can do what you like. Quite the opposite. Using Agile means that at any point the team is working on the thing that the client wants most, the story that was given highest priority in the last iteration.

Myth #3 Using Agile means you don't have to produce documentation. If documentation is important to the client (e.g. because her quality procedures say that she needs it), it goes on the list of stories and gets prioritized and executed just like the others. Otherwise, the focus of the project is on working code.

Myth #4 Pair programming is a luxury, and a waste of time. Never mind that there's loads of research that shows otherwise. One of the ways that Agile works is it gives you lots of opportunities to say what you mean. Programming with someone else means that you have to get straight in your head what you're going to do, straight enough that you can say it out loud and explain it to someone else before you actually do it. When you combine this with test first, each bit of functionality ends up having to be explicitly described two or three times before it actually gets implemented. This is perhaps why code that is developed using test first and pair programming tends to have so few defects.

Myth #5 Agile is just another fad The family of Agile project management methods are fundamentally different from the waterfall, Big Design Up-Front methods which have been used in the software development industry since its birth. But outside of software engineering, these kinds of methods are nothing new, in the visual arts and theatre and in other highly skilled, creative and craft-oriented industries, these methods have been around and have been used successfully for thousands years. Agile isn't a new fad, it's a very, very old one.

What is Agile? Stories, Iterations and Dealing with Constant Change

1 Agile refers to a bunch of project management methods that are well suited to managing projects in an environment where everything is changing. Agile methods came from software development but can be used for managing all sorts of projects.

2 Using an Agile method, a project team organizes all its work into "stories". A "story" is a short description of one thing that needs to be done on the project.

3 The list of stories are prioritized in discussion between the project team and the client.

4 The team, in discussion with the client select a number of the stories to work on over a short period of time (from about a week, to about a month). This is called an iteration. Each story in an iteration is assigned to a team member. This team member estimates how long the story will take.

5 The aim at the end of each iteration is to have something working to show the client. The client then has a chance to give feedback, to add new stories to the list of stories still to do, or re-prioritize the stories that are already there.

6 The team go through the stories that they've finished and compare how long they estimated they would take with how long they actually took. They use this as guide to future estimation.

7 The client and the project team go through the newly-prioritize list of stories and decide on the next iteration.

Read More:

Agile on Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development

"Extreme Programming" by Kent Beck

"Agile Software Development with SCRUM" by Ken Schwaber and Mike Beedle

"Scrum and XP from the Trenches" by Henrik Kniberg

Introduction to Agile Training in Central London, Tuesday 11th March 2008

We are offering another training course in central London on the 11th March 2008 in association with 01Zero-One. This is the popular and previously well-received course "Crawl Before You Leap".

The course is suitable for anyone who wants to get an introduction to what Agile methods are all about and get a hands-on feel for how it feels to work in an Agile fashion.

Agile Course Outline