An adventure in failure

I toddled along to Library Camps' FailCamp recently. I thought I'd put in a pitch for a discussion about my experience with the People's Network, not as a technical failure but as a failure of project management. I'd put together a few notes, and these are they, with a couple of clarifications arising from the discussion.

---

Introduction

At the fag end of the Major administration in the mid-90s the government accepted a proposal that every library in the country should provide free access to the internet. The details were finalised by the Blair government: Lottery money would be provided to do the necessary; each local authority had to match the Lottery funding, either in money or kind; bids had to be submitted to claim the money; and final delivery on the ground had to be completed by the end of 2002. There was no "national People's Network" along the lines of the academic JANET network — every local authority had to invent their own solution.

We had 19 sites to work with, 10 of which were completely offline. In 2001 our public internet provision was 2 coin-operated PCs in big wooden cabinets plugged into ‘phone lines. We successfully put our bid in at the last possible moment (literally half an hour before the final deadline), received confirmation of funding in May 2002 and by December 2002 all the libraries and 142 public terminals were online. This was a failure. Years later this would feature in staff conferences as “The failure we have to live with.”

Why was it a failure?

Because the customer (the Library Service) saw it as a failure.

So the customer’s always right? 

No: sometimes, as in this case, the customer can be irresponsible and wrong-headed. But if, in the end, you can’t demonstrate to the customer that you have successfully delivered what was required then to some degree, however unfairly, you have failed.

So why a failure?

• There were no pre-defined success factors. If you can’t define success you can only fail.

• The desired outcomes were extremely vague — “Public access to the internet” could, and did, mean many different things to different people or to the same people depending on which way the wind blows on any given day. So you could only fail.

• There was no buy-in to the project by the line of business. While the IT Department planned for and delivered a business transformation project the Library Service didn’t and expected that the change to the service offer to the public didn’t mean that there would be any corresponding change to the libraries’ business as usual. So the customer experienced severe disruption without getting the expected benefit. The lack of buy-in also meant the customer could behave as if the disruption was imposed from without rather than being a service transition within their operational business.

• Technical assumptions made based on the base specifications of the national project didn’t match the real-life requirements that evolved post-implementation. The necessary changes were made within weeks but that wasn’t fast enough — the new solutions weren’t immediately available to solve each problem as it was presented. The narrative became: “It doesn’t work properly.”

• There were the inevitable technical hitches, not least because we were applying technologies we were only just learning directly into a live environment within a very limited time frame. Test environments for the technologies but no test environment for the business implementation. When problems arose the same people trying to solve the problem were the ones being pressured to roll out the problematic solution to all sites p.d.q. The narrative became: “It doesn’t work properly.”

• The Library Service didn’t know what it wanted the public internet for, save that everyone said they should have it and everybody else was doing it. “We want public internet provision” is the same as “We want tables and chairs,” what you get and how you get it depends on what you want to do. Nature abhors a vacuum so the public either found their own uses for the service (some of which — reasonably or not — didn’t find favour with the library staff) or wanted to do things which the solution wasn’t designed to deliver (generally typified as: “I can do this on my PC at home, why can’t I do it on this?” — downloading ringtones and loading software brought in on disks onto the public PCs were the two most popular). The Library Service’s user input to the design and specification went no further than “We want the internet,” consequently expectations weren’t managed, were confused and were inevitably often disappointed.

• As stated already this was seen as a technical implementation, not a business transition. Providing public access to the internet creates a new support load at the front end of the business. Members of the public needing help creating documents, finding and using online services or creating and using email were seen as technical problems to be addressed by “techies,” not service delivery issues and customer support to be addressed by the business. This disconnect was presented as a failure of project delivery not as a failure of business management.

• There was a complete failure of the relationship between business managers and technical support. This lasted years.

Lessons learned?

• Experience isn’t what happens to you, it’s what you do with it.

• You need to specify desired outcomes and success factors. How will you know if the project has successfully delivered? If you don’t you can only fail.

• If you get to the implementation phase of a project without you and your customer both having the same clear idea as to what you’re going to deliver you can only fail.

• If the only pre-implementation meeting you have with business managers is devoted to anything other than the nitty-gritty of the project you are going to fail. (In this case it was 3 hours discussing the location of one table in one library, and no, I’m not making that up. A textbook example of Parkinson's Law of Triviality.)

• Never. Ever. Work on a “We’ll leave you to it” basis. By doing so you are taking the entire risk of the enterprise on your shoulders. Insist on milestones where you get sign-offs of the work that has been done to date. No sign-off, no further work will be progressed. You will be hated for it. But you’ll be hated if you cop for the blame for any problems or failures so you may as well go for it .

• All technical implementations are business transitions, otherwise they wouldn’t be done. The changes may be small or incidental, they may be majorly disruptive. Whatever, changes — and their associated risks — need to be managed and not ignored. Business failure may be blamed on the technical solution not on the failure of business transition management.

• If business managers are more concerned with assigning blame than in finding solutions you need to get out. This type of organisational culture fosters failure without ever learning from it.