Project management applies previous experience to delivering current projects. Traditionally, this meant delivering ‘the agreed scope on-time and within budget’. Today, other parameters such as quality, environmental protection and safety are considered equally important.
While the basic methods are mostly simple, it is their careful application which often makes all the difference. This article illustrates the importance of identifying and validating project assumptions.
Projects are unique undertakings that deliver some useful result. This could be something tangible, concrete and and visible, such as a road or a new product. It could also be a service or information package, such as the processes to support the launch of a new type of insurance policy.
It is perfectly possible to carry out projects without reference to previous experience, muddling through and addressing issues as they arise. The manager of a cement factory in the Philippines told me that her team tend to “attack” issues and this can be more “exciting” than painstaking and detailed work.
On the other hand, business is usually more interested in results than excitement and it makes sense to apply the so-called ‘lessons learned’ to projects, so that they can be completed as efficiently as possible. This reduces the excitement factor and is more typical of engineering projects.
All project stakeholders will be interested in the delivery date, so that they know whether they can then use the output (deliverable) or close their involvement. The better previous experience is applied, the higher the probability of estimating and meeting a delivery deadline.
One less glamorous element of ‘lessons learned’ is attention to assumptions. By identifying and documenting these inconspicuous items, the project manager can move forward with planning, even if all the necessary information is not available. If the assumptions turn out to be correct, then useful work will already have been done. If they turn out to be incorrect, then at least only a limited amount of work will need to be corrected.
This means that the simple process of documenting assumptions and validating them later can add considerably to project success.
The failure to validate them can lead to project failures, sometimes quite spectacularly. I have heard it said that the company culture in HP used to be passed on by stories about the founders Hewlett and Packard, rather like our own seanchaithe, and this is often a good way of increasing awareness. In this spirit, let us now look at some cautionary tales about assumptions: we can chuckle about the failures of others, but we can also learn from them.
Laufenburg Bridge misaligned
[caption id="attachment_30482" align="alignright" width="300"]
Construction of Laufenburg bridge[/caption]
The twin towns of Laufenburg (Germany) and Laufenburg (Switzerland) face each other across the Rhine river and enjoy daily contact. Since Switzerland joined the Schengen Zone in December 2008, there is no systematic control of people movement between the two countries, just like the boundary between Cavan and Fermanagh.
The new bridge, which was opened almost exactly four years earlier in December 2004, is an important element of this free movement of people and relieves the two town centres of 5,000 vehicles daily. It has also made it possible for the the town on the German side to hold its Christmas market in the city centre.
The bridge is 225m long and 11.2m wide and cost 12 million Swiss Francs, the cost of which was shared equally by the German state of Baden-Württemberg and Canton Aargau in Switzerland. The building of the bridge was, however, not without its problems.
The first of these was the arduous diversion route for motorists through the narrow streets during two years. Then, during the hot summer of 2003, as the building reached out from the two sides towards the middle of the Rhine, it became clear that something about the height was not right.
As everyone was preparing for Christmas, a routine construction control discovered a 54cm height difference between the two sides. The Germans were relieved to confirm that, from their viewpoint, this could be corrected relatively easily on their side, but that the error was definitely on the Swiss side.
It might be assumed that the error lay in the fact the reference height on both sides was not the same. But the situation was not quite so simple.
Since 1878, Germany takes its sea level reference from Amsterdam. The zero reference there was defined by the average level during the period 1 September of 1683 and 1684. This was then marked by marble tablets, whose height was given as 9 feet 5 inches (this was before the French Revolution brought in the metric system) above the zero reference.
Switzerland takes its sea-level reference from an erratic stone brought down the Rhone valley by glacier movement and deposited near Geneva. It is one of a pair called
Repère Pierre du Niton – the 'Reference Stone of Neptune'. This name was given to the stones by the Celtic inhabitants in the area before the Romans. Guillaume-Henri Dufour used this reference for the 1:100,000-scale maps he developed between 1845 and 1864. At the time, it was thought to be 376.86m above the level at Marseilles, which is on the Mediterranean. The actual height of the reference was corrected to 373.6m above the reference in 1902.
In summary, one reference point was on the North Sea and the other in the Mediterranean. As well as matters of definition, the globe is not perfectly round. At Laufenburg, the height difference of 27cm between these two standards partially due to the uneven curvature of the earth was known to the planners of the Laufenburg Bridge.
It appears that the correction calculation was assumed to be correct. But unfortunately the minus sign was missing, so the ‘correction’ of 27cm was made in the wrong direction, giving a total error of 54cm. No wonder that the error became a theme at Fasnacht, the carnival at the beginning of Lent the following year.
Lesson learned: Validate your assumption – in this case, that the calculation was correct.
Trains too wide for the platforms
[caption id="attachment_30509" align="alignright" width="300"]
Regional TER train, France[/caption]
In France, two principal companies are involved in providing rail transport. They are SNCF (
Société nationale des chemins de fer), which run the trains, and RFF (
Réseau ferré de France), which provides the infrastructure such as tracks and stations.
This is a classic split between major stakeholders, where any problems are likely to be projected on the other. This is exactly what happened in the case of new trains that were too wide to pass the platforms. During May 2014, it came to light that an order for trains consisting of 341 train compositions, about two thousand coaches, had been designed with too little tolerance between the trains and the platforms.
How this arose is similar to any accident: several details all went wrong at the same time. In this case, the SNCF had envisaged a space of 1cm but several other factors came into play which suggested that a margin of 3-4cm would have been more suitable:
- The space varies with temperature;
- Trains cause vibrations, for which space should also be factored in;
- The vibrations also cause small shifts in the track location.
In addition, RFF reported that some of the stations are as much as 150 years old, when the building tolerances were not as tight as today. SNCF also accused RFF of not knowing the dimensions of its own stations.
The result was that the platforms at nearly 1,300 stations had to be rebuilt at an estimated cost of €50 million. The magnitude of the task was played down, because this number was only a “limited proportion” of the approximately eight thousand stations in the railway network.
The assumptions:
- RFF knew the dimensions of its platforms;
- SNCF accepted the dimensions as correct;
- ‘Somebody’ had factored in tolerance for stability, temperature changes etc.
Lesson learned: Validate your assumption, in this case that the dimension for the train width was correct.
Author:
Dr Deasún Ó Conchúir CEng FIEI is collaboration consultant for Scatterwork GmbH, which specialises in online training for project management and team building. He has a third-level education liaison role for the Biomedical Engineering Division.
A globally experienced project manager and trainer who spent several years at Waterford RTC as head of the School of Engineering, he has worked in over 35 countries and with dozens of companies including Zain, Holcim, General Electric, Novartis, Swiss Re, Nestlé, Ericsson, the European Commission, Zurich Financial Services, Nokia, Sun Microsystems, Bausch & Lomb, HP, Alstom, SIA and many others.
He obtained his doctorate in Biomedical Engineering at the University of Strathclyde and his Honours Degree in Electronic Engineering at the University of Wales, Bangor. He speaks Irish, French, English and German.