Doomed projects

Over the years I've been involved in some weird and wonderful projects. Some I remember fondly, some I try not to think of at all. Most projects have been successful, if "success" is defined as "what we built worked, the customer signed off, we got paid and the system went into production". But one or two ended in failure, and I was thinking about one of these this weekend while contemplating the question "how does a big IT project get launched when it should be obvious to anyone if possession of the facts that the project is doomed from its inception?"

I worked on one of these train wreck jobs about 10 years ago. At that time I was working for a reseller, and my job was on the help desk, providing technical support for things like SCO Unix, ArcServe and several sorts of hardware. Home internet access was becoming increasingly common in Australia, and the internet itself was evolving rapidly from a place where geeks talked about geek stuff to a place where non-geeks were trying to do business.

On the other side of the world a Big American Bank (let's call them B.A.B.) had launched a very swish new website. Their customers could register on this website, tick the boxes for the information that interested them, and then on their next visit, the website would show them relevant, fresh, content. And the software would keep track of who visited and what they looked at. By modern standards this is trivial, but in the mid-nineties it was hot stuff. The site had been built using software and professional services from a famous Californian application vendor (let's called them CalVend), and it was extremely slick. Other banks were deeply envious, and a certain large Australian bank (let's call them L.A.B.) decided that it was their destiny to be the first bank in Australia to have a website like B.A.B.'s.

Now it so happened that my employer was reseller of CalVend's products. CalVend were very keen to have L.A.B. deploy their software, so keen that they sent a presales engineer to Sydney to assist in closing the deal. And the deal was closed, and then it dawned on the sales folk that someone was actually going to have to deliver the solution, which only ran on Solaris. The company didn't have many Unix-literate engineers: most of the in-house geeks were Netware specialists. Remember when Netware was fashionable? I digress.

They needed a Unix engineer to work on this project, so I was summoned from the depths of technical support and seconded to the project team. The project manager and I were sent to California to do the application training course, and by the time we got home the hardware had been delivered and installed. I installed the operating system and the application software, and the rest of the team started reconstructing the rest of the L.A.B. website, so that it would mesh nicely with the new application. I settled down to write the Perl CGI scripts that would interface the registration form into the application. All the application actually did was record user details, record what each person was interested in (investment or retirement planning or whatever), and retrieve pieces of content from its store to be displayed to the user. Getting the information in there in the first place was my problem.

A number of other problems soon became apparent. The first one was that the application software was both badly documented and riddled with bugs. The second was that CalVend had expected that their professional services would be engaged to do this job. When they found that we were planning to do it ourselves, and that the only revenue they were going to get was the stupendous licencing fee for the application, they became extremely uncooperative. We would call them to ask how to resolve some problem, and it would always transpire that the only person who could answer our question would be "travelling", typically in Korea or Outer Mongolia, and would not be available for at least a week.

However, we persevered, and the day came when everything worked. You could register, and the system would hand you the test pages we were using as dummy content. The operator could apply weighting to selected content, so a user was more likely to see page A instead of page B. All as required by the specification. So I turned to the L.A.B. person who was working with us, and said "OK, we need to load the first cut of the real content, so we can test properly" and he went away and returned shortly with a 3.5" floppy, saying "here it is". So I dumped the files into the system, and had a look at them. I experienced the first twinge of alarm when I saw how few there were, about 15 as I recall. And they were all PDFs. I opened one. Then another. The full horror hit me: the contents of the floppy was a set of PDFs for the printed brochures that you could get from a L.A.B. branch. Boring leaflets featuring carefully staged, politically correct photos of happy bank customers, a few paragraphs of waffle and the phone number of the bank's call centre.

I asked when the rest of the content would be available. The answer was that there wasn't any more. "We thought we would just start with that, and see how it went" they said. I pointed out, firmly, that no end user would go through the web site registration process for the privilege of getting the same brochures that they could get from the local branch. And if that was all they could get, they wouldn't bother revisiting the site. That scared them: the whole point of this exercise was to increase traffic to the bank's web site, and to be able to monitor that traffic. B.A.B. had a large staff churning out content, so there was almost always something fresh to look at on their site. L.A.B. had nothing in place to supply a constant stream of content. Problem.

So they called their marketing department, and arranged a meeting. I was there (I had to explain how the system worked, most of the bank staff still didn't really understand it). The meeting was interesting. The marketing folks had not heard about this web site project, and you could see they weren't happy. Once they understood what was going on, and how far it had got, you could see them fighting for composure and control: they could see brand name ruination staring them in the face. If the site went live with the current "content", the result could only be public humiliation of the bank on a national scale. But they had no resources, and more importantly, no plan for what content should be created and why.

The marketing folks were smart people. They didn't say anything negative. They said that they needed time to formulate a plan, and they went away. We went back to the office we were working from, to await developments.

I don't know exactly what happened next, because there were meetings to which I was not invited. Nor, so far as I could tell, was anyone else working on the project. What I think happened is that the marketing folks went a few levels up the bank's chain of command, and had our project put on hold, pending the creation of content. They then produced a plan for content creation, and as part of that plan, had control of the project transferred to them. And once they had control, they signed off the completed work, and shut the project down completely. We got paid for the work we had done, but the site never went live, and about a year later when the bank did launch a new web site, it was a completely new development (and it didn't use CalVend's software).

How did this go so wrong? The project could never have succeeded without good content, but nobody thought about the content at all. All the project sponsors thought about was the "coolness" of the web site, and everyone on the implementation team assumed that there would be content available when we needed it. Nothing in our scope of work mentioned content, all it talked about was functionality. We delivered the functionality, but functionality with no content is meaningless.

But it is far easier to focus on the technology, the gadgets, the bells and whistles. I've seen quite a few project sponsors do this over the years: they like to come and have their photo taken in front of the equipment racks when the new system goes live. Unfortunately, most end users are completely unimpressed by the technology, because they don't understand it and they don't need to understand it. They do not care about the sophistication of the software, the elegance of the design, or any of the fascinating little details that will absorb an engineer for hours. They just want "the system" to do something useful, and to do it quickly, without making them feel stupid.

For the engineers, a successful project is one where the technology works, and we don't start getting support calls as soon as we hand the system over to the customer. For the project manager, it's one where the job is completed on schedule, the customer signs off and we get paid. But for the end user, a successful project is one that creates a service, utility or product that they will want to use. If the end users stay away, what you have built is a white elephant, often a very expensive one. I don't recall what L.A.B. spent on their doomed project, but I don't believe there was much change out of $AU500,000.