Thinking the unthinkable
This report, never issued, was prepared during my time as a software testing consultant to a certain British bank. I was a consultant to its UKBBUG (United Kingdom Branch Banking User Group) in 1991. The report was never issued because it was already clear that no one would take any notice of its message.
All employees on the ISS project had been bribed. That is to say they had signed up to a bonus scheme. If the system went live on or before July 8th 1991, they would receive a lump sum in their salary. The intention was to secure commitment to an ambitious schedule and prevent further slippage on this project, which had been running so long that the technology was already obsolete.
The effect was to blind them to any other possibility, regardless of where truth lay.
I did my bit to make everyone see reason, with many words, many memos, many reports. I wrote this unpublished report just for my own sanity. I could see that the Emperor had no clothes, but others felt there was greater safety in collective belief.
Thinking the Unthinkable
Sinking the Unsinkable
To many of its passengers, the Titanic, even when listing at a steep angle and about to disappear under the waves, was a secure reality from which it was unthinkable to jump off. Beyond it there was nothing to cling on to. After the Titanic, the world of shipping learned that not only are lifeboats necessary but there should be regular drills so that when the unthinkable happens, at least there is something more than a cruel abyss, where even the imagination dare not stray.
This paper, then, explores scenarios which may be considered as taboo, on the grounds that they threaten the very will and commitment which are seen as necessary for the survival of ISS. But if the history of the project so far tells us anything, it is that aggressive schedules, exhortations to increased commitment, quality etc do not of themselves bring about a wished-for outcome. Indeed, the doctrine that it is forbidden to question, which becomes an article of faith, i.e. that "ISS will succeed" may in itself sow the seeds of disaster, for it divorces its believers from reality.
Reasons for Abandoning ISS
The slippage seems to keep pace with elapsed time. We don't actually seem to be progressing at all. Yet no one has yet been able to demonstrate that "This pig can fly".
Such a demonstration will need to show the following:
1. that there will be a clear net benefit, sufficiently certain, quantifiable and substantial as to justify the cost and risks associated with the development and implementation;
2. that the main design decisions are so well-justified that they would be made again were the project wound back to its start; or at least would not be hastily ditched in such circumstances;
3. that the system will be maintainable throughout its planned life;
4. that it will be enhanceable to any conceivable new requirement the Bank might have, and in principle to other requirements which cannot at present be conceived;
5. that the plan for its development to full specification has been adequately mapped out;
6. that various contingencies like destruction or failure of key system components will not be able to interfere with the normal Banking business in such a way as to cause loss of revenue or drive away customers;
7. that the effect on staffing requirements at branches will be fully consistent with the Bank's policies and plans in this area;
8. that it will be sufficiently usable by its users;
9. that it will yield the required performance;
10. that delivery dates are firm, permitting co-ordinated planning of implementation across the thousands of Branches involved;
11. that successful build to the specifications is well within the capabilities of the Development Project;
12. that human and machine resources are adequate to bring plans to fruition;
13. that test plans and responsibilities are such as to give confidence in quality of the end-product.
Most of the items above would need to be established clearly at the stage of a feasibility study. One assumes, perhaps over-generously, that they were. However, progress since then has had the effect of destabilising many previous certainties, whilst showing that nothing at all may be taken for granted.
None of the above points can yet be demonstrated adequately.
The Cost of Early Termination
If the ISS project were abandoned tomorrow, would it have any scrap value?
The sums spent to date, less this scrap value (e.g. functional specifications which might assist in definition of future requirements to some degree) would be written off. However, if the project is destined to fail anyway, it would be best to cut losses by identifying this now and making the decision. The spend on development to date is a small proportion of the likely total spend if ISS is allowed to continue.
There might be a serious problem of credibility and image, both within the Bank and in the wider world. The manner of halting the Project would need to be carefully managed to minimise this, even to turn it ultimately to advantage. The credibility problem in cancelling now would be considerably less than a dramatic disaster or a protracted limping system yielding no real benefits and generating impatience for its early replacement.
Every single member of the Project as well as many outside it and executives stretching up to the top positions would be affected by the decision. Their immediate or long-term career opportunities might be adversely affected, or at least they might be excused for thinking so. However, for managers at the very least, involvement with an unsuccessful project will not enhance their career. Though this Titanic may not yet have struck the fatal iceberg, the ocean is dotted with hazards, and it's only a matter of time.
It is in the Project Sponsor's hands to call a halt or give blessing for the Project's continuance. He surely has the courage to do what is in the best interests of the Bank with priority over lesser interests. [This is the silliest statement in the whole paper! - Ed] But there is no sense in stepping out of the Titanic into the cold Atlantic. There has to be some sort of lifeboat. There has to be some alternative.
The trigger for abandoning ship, when it comes, may not be something major. Enough small leaks can sink a ship. To avoid the ultimate catastrophe, to salvage as much as possible, is inevitably a subjective decision. To wait a moment too long is to be sucked into a whirlpool where events take over, where independent action is no longer possible. In short, if you have an alternative plan ready, you can choose your moment for action.The justification for abandoning ISS, apart from the judgement that it is not going to be a success, is in minimising the waste of time and resource and in getting started on something better without delay.
So it is now necessary to sketch out a brief critique of ISS, showing the fatal errors which have risked its downfall. By starting again and avoiding these errors, success next time round should be assured. At least, this is my thesis. To minimise loss to the Bank, I believe that we should have an embryo alternative plan ready now: this way we don't hold on to the old one past the point where it has lost all credibility. Also, we have a smooth transition from the one to the other, which is essential to maintain the Bank's credibility.
Lessons from ISS
Now is the time to gather the lessons we have learnt, to conceive an embryo alternative plan.
1. ISS has no Architect, no Director, no Visionary to keep its concept valid, to steer it through the vicissitudes, to provide both creativeness and continuity
2. The original objectives were diluted and eroded, then ultimately replaced by the ignoble and useless one of simply keeping a gigantic show on the road, preventing the momentum of the juggernaut from causing a catastrophe
3. The project has far too many people. I counted 356 people in the ISS telephone directory. Most of their efforts are wasted due to the lack of firm, complete and executable plans.
4. A project should not get under way without clear policies towards major aspects which can be determined up front - such as service levels, recovery, overall test plan, allocation of hardware & environmental resources.
5. The Functional Specification is an inappropriate medium for the determination of detailed requirements for the external design.
6. User Group members should be trained Business Analysts as well as knowledgeable about Branch Procedures.
7. The decision to replace Logica by IT's own resources was highly risky for at least three reasons - the break in continuity, the break in accountability and the decline in talent. [The last phrase would not have been publishable!]
8. The Phase 1 system, supposedly the establishment of a customer records database, was, as designed, far too big a step. It should have been simplified from the start rather than "descoped".
9. The Phase 1 (or Release 1) transactions are too complicated and bitty. Rather than a system design, one gets the impression that everything is an afterthought tacked on as a result of a change request.
10. Both System Knowledge and Business Knowledge are rare commodities except in pockets of narrow specialisation.
11. The long-drawn-out process of Change Requests, descoping etc and the difficulties associated with Functional Specs could have been reduced radically by modelling transactions using prototypes. As it is, we may have too wait till UAT [user acceptance test] before getting some understanding something of the impact on the user.
12. Marketing wish-lists have been superimposed on the system in the form of nice-to-have information. Unnecessary - should concentrate on storing information held already.
13. Insufficient attention to BOLP and the need to be compatible, both from user impact and also the credibility question.
14. Jobs which are extremely simple for the user at present using Kardex, CIC etc, become immeasurably more complex to operate under ISS, not to mention complex to build.
15. Much of the system at present is arbitrarily shaped by the ruins and stumps of earlier intentions which have been progressively descoped and modified.
16. Much of the system suffers from an "open-endedness" designed to cope with future possible requirements, instead of trusting in the flexibility of a well-designed core system and letting future enhancements take care of themselves.
17. The very basis of ISS - accessing accounts via the owning customers - could have been designed far more simply, based on facilities we have already, i.e. the Group Accounts facility of BOLP could have been developed gradually to hold additional attributes.
18. The concept of the draconian Roll-out Plan and the aggressive schedules for initial implementation have caused problems, stress and distress time and again, especially in view of the fact that the schedules have been put out without having resolved basic issues fundamental to their success. A gentler, more cautions alternative would be to design the system with prototypes before ever taking on a full development team.
19. According to the principles of top- down implementation, the first tasks of the development team would be to develop, test and install a skeleton system, with very little functionality, but which would allow each new function to be incorporated as it became available. This would reduce dependencies, test all aspects of the development process earlier and simplify the development cycle.
Rise of the Phoenix
From the ashes of ISS, a little but powerful core project needs to be reborn. Withdraw the mass of IT personnel for the moment. Retain just one or two top technicians and architects, who can advise on the basics, ensure that ideas never stray from the technically feasible and ensure that every aspect of infra-structure, logistics and integration with existing systems is constantly kept in mind.
1. Don't start with a vision of the ultimate on-line system. Start with what we have, and how we can get from here to somewhere more useful. Keep the emphasis on clear, simple steps which have their own validity and logic.
2. Aim for a clean, flexible framework which allows all kinds of options to be incorporated in the future, even though it doesn't do very much now.
3. Avoid dogmas which cloud the view of reality. Question everything again and again. Explore, change, criticise until no efforts can further improve the design. Test the prototype from every angle, try by whatever means to show that it won't work, can't be built. When it cannot be faulted any more, build it.
4. Avoid problems of BOLP compatibility by being fairly conservative. Make a new system which has high compatibility with it, keeping as many options open as possible.
5. Give prime consideration to the full context of existing systems, procedures, resources, etc. These are the problems to be wrestled with. Be extremely wary of allowing the new system to generate problems of its own.
PostscriptThe leaders of the project were allowed to retire in glory. Successive waves of management consultants were hired, each bringing their own remedies. New initiatives were launched overlapping previous initiatives which hadn't yet been fully implemented, like the seven plagues. When I worked again for the same bank in 1994-1995, ISS was still a front-end to nothing, and had not been developed as intended to replace the creaking BOLP system, created in the 1970s. BOLP was too complex to send to India for re-engineering against the deadly Millennium bug. There's a saying, "If you can't fix, it, feature it". A press release in 1999 tells the story:
Crucial to the bank's millennium programme for its retail division was the bank's core accounting system, Branch Online Processing (BOLP), a customer database built in-house. J----- W-------, group millennium director for the bank, described it as a "large and complex program - the largest commercial program in use.". . . .
BOLP, which has about 180 interfaces to other systems, "took a lot of effort because it was so big and important with a lot of dates," said W-------. "It took roughly two years to sort out." . . .
"Over 100 people are involved with BOLP at any one time. There is continuity there, so someone will always be able to understand it," explained W-------.
Moral of the story
I don't think the child who piped up "The Emperor has no clothes!" grew up to be a courtier. Nor did the author of this paper achieve eminence in management or a reputation for prophetic wisdom. Power and money can create a kind of truth that overrules the truth of poets and children.