Related Pages: [ FEE Paris 2000 ] [ Enterprises 2002 ] [ Euro Compliance ] [ 7 steps to success ] [ Eurotown Project ] [ Lessons learnt ] [ UK Decimalisation ] [ Euro Implications ] [ Managing Risk ] [ SME Changeover ] [ Euro Myths/Facts ] [ Leclerc 1996 trial ]

Lessons from the birth of the euro

An article appeared in May 1997, "Why the Euro Currency Can't Happen" on the Westergaard web site (which was closed down 15 August 2000)  http://www.wbn.com/y2ktimebomb/Economy/Predictions/germany9722.htm

A software vendor speaking in 1998 said "many small to medium sized banks, even in Germany and France, stand a fair chance of not making the deadline with tested and proven systems. I think that the January 1, 1999 and its repercussions in Europe will be a dress rehearsal for January 1, 2000 in the entire world. The same human nature of saying that everything is OK till the last minute, will play in both cases."

However, in January 1999, industry observers were surprised at how smoothly the transition to the euro went. For example, Howard Solomon, a reporter at Computing Canada, asked:

"[W]hat lessons can be learned from the seemingly successful transition to the euro? Critical observers who say IT projects rarely get delivered on time and bug-free predict that Y2K and euro transition will be painful. But in Europe for the euro this is seemingly not the case. If so, why? Or is it too soon to tell? Does this mean Y2K transition will be easier than predicted?"

This was echoed in an article by Mitch Ratcliffe in PC Week. See http://www.zdnet.com/zdy2k/1999/01/5490.html "What Have We Learned From The Euro? As a problem of similar scale, the Euro conversion is an excellent basis for making projections about the Y2K date roll-over."

Of course, both are large projects requiring management and resources; but then, what important projects do not? The crucial difference is that Y2K is a mass change project to remove date-related defects, more like maintenance; the euro is the implementation of new functionality, which is more like normal new business projects.

Unlike Y2K, "the" deadline is not fixed. In fact, there are several deadlines, which apply to different industries. And different people will take different approaches depending on the industry. So for 1/1/1999 there was a "big bang" change from national currency unit (NCU) only to euro only, for central banks and stock exchanges - and those who depend on their data feeds. The rest will change in 2000 (other things being equal) or 2001 or 2002.

Big bang is easier to do for smaller organisations. Large, multi-national companies will have quite a different scale of problems. So for people in the wholesale markets, their deadline has come and gone, and yes, they did have that management challenge. They had prepared for it for a couple of years and in a newspaper article recently some spoke of four rehearsal runs during 1998. It was done on duplicate (redundant) systems and checked for accuracy. One project manager told me that on the conversion weekend, one team ran over by a few hours. But the next in line were not nervous about this. They had rehearsed what they had to do three times already, they knew what to expect. Then they took their place in the job stream and did it. Rehearsals were necessary because the wholesale conversion had to happen over a long weekend around 1 January 1999. Y2K projects can be managed over a longer timescale where it possible to convert systems at different times and use bridges to maintain interfaces.

Other software projects have deadlines - tax and budget changes, date-related (seasonal) product launches, etc. Having the characteristic of having deadlines is not really a strong comparative measure; one would need to see more attributes in common for comparability. I'll talk about the technical differences below, let's start by seeing how differently these are managed:

1. Risks

There are Euro risks not in Y2K (cf Capers Jones)

Creeping requirements

Gold-plating requirements

Inadequate user preparation / documentation

Low user satisfaction

Harmful competitive actions

Friction between developers and users

There are Y2K risks less likely in euro:

Litigation expenses

Common risks are:

Low software quality, poor testing

Unachievably compressed schedule

Cost overruns

Inadequate configuration control

Unstable tools (Silver bullet syndrome)

High maintenance costs

Redundant applications

Inaccurate metrics

Inadequate measurement

2. Changes

Some early changes are deceptively easy. A utility can add a line at the bottom of their monthly consumer bill showing the total in euros with very little effort. When it comes to changing their purchase ledger, that might be more difficult! But some changes require only agreement among trading partners to avoid redundant work.

Embedded systems are a unique Y2K issue (the only analogy in the euro is cash handling machinery) and the one that seems to give the most concern. The financial services industry does not have much in the way of embedded systems (security access and safety is probably the most important), so success in IT system changes is not a predictor of success in industrial process control systems.

Mitch Ratcliffe in the PC Week article spoke of the euro birth as a bellwether, or early indicator, of possible Y2K success. Evidence of managing one project well is an indicator of the ability to manage one project well; but not necessarily two together. The banks may have focused on the euro at the expense of Y2K, so they may have a Phyrric (short-lived) victory. This argument will not be resolved until 2000. You can argue either way: we simply don't know how the resources in these companies were allocated to these two projects. Managed well, they are carefully estimated and the appropriate amount of change managed. Managed badly, everything was thrown into one project at the expense of the other.

3. Rumours on the street

The main changes on 1 January 1999 were in the central banks and stock exchanges and secondly their data feed users. The banks and exchanges did a big bang switch - all national currency before, all euro later. No dual currency here, but single currency both before and after. The simplest possible technical solution, except of course for changing literals and symbols and suchlike in code. The main challenge is the database conversion - some banks reported four days to do the conversion. So that leaves just the data users. There were some stories of problems reported to the euro2002 discussion list. For example:

"Rumour has it that some of the big players on Wall Street have difficulty processing the excessive volume of Euro transactions. For example, Swift and Target have been paring down settlements of say 100Million to 10 transactions of 10Million each"

"A problem has been identified in the […] pricing feeds. ... Research is indicating that they are, in fact, euro values being mis-reported as legacy. "

The London Financial Times reported some local custodians were having problems in the conversion. One bank was mentioned by name as not having sent converted information to clients due to "technical glitches".

The Dutch press published articles about a major domestic bank losing hundreds of transactions since it changed its systems. A non-European bank was apparently unable to deal with several hundred million dollar's worth of euro business, and one of its major competitors had to stand in to take over the business - closing ranks in support of each other's common interest.  And the Belgian press gave an example of a domestic bank mis-posting a massive amount of money as a result of its software changes. We will of course not hear about the many problems that were squashed internally. As long as they do not impact on trading partners, why should we? There are stories of higher volumes of manual reconciliations being necessary. If the volume of such exceptions begins to exceed the ability of the bank to handle them, then the problems will become visible.

In the public sector, there were more alarming reports. An example is an article at http://www.silicon.com :

"Euro crashes French post office system

PUBLISHED: 0:20am on Friday 8 January 1999

The French Embassy in London has admitted that a systems crash at the French national post office was partly due to problems arising from the euro conversion. Riot police were called to calm angry savers at the Marseilles branch of La Poste, after they were unable to access their accounts on Monday and Tuesday."

Bear in mind that riot police in Marseilles is business as usual there. Also, only three branches getting trouble out of thousands is not bad news either.

When predicting Year 2000 problems, be careful too of making a judgement based only on one sector - the wholesale financial industry. They have the money to make these changes. Retail financial systems will not change for a year or two (apart from some cosmetic euro-friendly touches like the total at the bottom) and the business world in general is still to make its euro-move. And we have no idea how any of these are progressing in Y2K.

In October 1998 I asked a group of IT people at a Y2K seminar how many of them tracked their projects and knew the accuracy of their estimates. Only one put up his hand - the IT manager of the central bank in Ireland.

So if you are a Y2K project manager who manages your process, uses good estimating and tracking techniques, and has gone through at least three rehearsals of your database conversions, regression tests, and future date tests, you are in good shape for success. Those who only get one shot at it, without the aid of quality metrics and historical performance data to guide them ... well, let's see.

Bibliography

"The Year 2000 Software Problem; quantifying the costs and assessing the consequences" by Capers Jones, Addison Wesley, ISBN 0-201-30964-5