Why include the millennium bug in this section when everyone knows that it didn’t happen? Because it cost us over £400bn, yes that’s billion, that’s why!
In the lead up to the year 2000, a potential global problem with computer software materialized.
It was felt that many software programmes had been coded to use two digit instead of four digit year dates (e.g. 85 rather than 1985). Without the first two digits, how was the software to tell whether something had or was to happen in the 1900’s or the 2000’s?
Would lifts, cash machines, telephones, cars, everything that depended on a computer simply cease to work as the clock struck midnight on New Year?
Books were written:
Mr Spock (or, at least, Leonard Nimoy) was drafted in to warn people!
Well, it didn’t happen. The world watched as New Zealand, first through the time barrier, continued to function and, by the time countries such as the UK and US arrived at the appointed hour it was clear that problems would be minimal and were not likely to be visible on a national or international level. Though, of course, it’s entirely possible that many things kept working because the work had been done to rectify the problem.
IT contractors and vendors could command high prices in 1999 and many were paid large retainers to be on standby for the crucial first hours of the new year.
The decision to use 2-digits instead of 4-digits for the date was the cause all these issues, a problem that could have been avoided if programmers and their project managers had simply thought ahead at possible issues. This is a classic case of an example where business continuity exercises carried out during the project-scoping phase may have highlighted the issue, and saved everyone much grief.
You can see the extent to which concerns were held via this BBC site rounding up the issues (click on the graphic to go to the BBC site for more information):
The example here of the information for Russia shows how seriously this issue had to be taken by companies and authorities around the world (click to visit the BBC site for more information):
That said… It’s worth noting that our founder reports she and her IT manager had a simple solution to working out whether her then-employer would suffer any issues. They stayed back late one evening early in 1999, copied the key systems onto another server and there, in the safety on a sandbox, they rolled the date of the system over so it operated in the New Year to see what happened.
They knew they weren’t going to have any issues from July 1999, but remained concerned about the implications of other systems on their own.
That’s a sensible, controlled, real-life, technical business continuity exercise in practice!
What can business continuity planners learn from the millennium bug?
- It’s sometimes hard to tell if there is a problem. Finding ways to exercise the issues, ensuring such exercises cannot impact normal business, can be a useful way to determine issues and solutions.
- Just because everyone else thinks there’s a problem, doesn’t mean there is. Of course the reverse is also true, but challenging assumptions may be useful on occassion.
- Considering continuity in the project scoping phase is useful. Even running exercises that require the project team to imagine possible outcomes to scenario-based exercises for whatever they are delivering – before it exists – can be interesting and useful. You won’t catch everything but you might highlight some important issues that can be rectified before the project is delivered.
- Your problems aren’t always caused by you. Organisations that were fairly sure they had no software issues of their own were dependent on the systems of other organisations in an interconnected world. Banks, lifts, telephony, internet connection… the list of dependencies for your organisation is probably very long. Include those that key to your operation in your business continuity planning considerations and, in the case of special events, consider running exercises as brainstorming sessions to provide opportunities to highlight possible issues.
Was this article useful? Share it or comment below.
Subscribe - weekly news and a free course!