Studies show that the key factor for job stress is not the job itself, but rather the fit between the person and the environment. And this begs the question: If you change your environment to a more agile one, will that improve people’s well-being?
IT Project Lessons from Titanic (Part 1)
Most people are very familiar with the Titanic story from James Cameron's 1997 movie, or the documentaries on the Discovery or History Channel. Typically, these focus on the last two days of the voyage and the last hours of the disaster itself. But what about the four-year construction project? Was it significant? What impact did it have on the disaster? What can we learn from it and transfer to today's Information Technology projects?
Let's go back to 1909 and the business situation that faced White Star. Their aging fleet of liners was grossly inadequate to compete with stiff growing competition. White Star embarked on a strategy to invest in new emerging technologies and create three super liners. These were major investments as the liners were likely to be in service for at least 20 years. So for the designers it was critical to get the design right and they proceeded with a design strategy of luxury over speed where the ship's second class was equivalent to first on other ships, and third to second.
To match the luxurious splendor or the "functional requirements," investments had to also be made into "non-functional requirements," everything that supports the functionals including performance, safety and capacity.
From the outset, no expenses were spared in investing in the latest emerging technology for the non-functionals like the safety systems, which included a double skin hull (the bottom space divided into 73 watertight compartments), 15 bulkheads and electric doors, 48 lifeboats and advanced water pump technology. However, as in many projects a struggle took place in the project team where the success of the business strategy overrode other considerations.
One by one, compromises were subtlety made in the non-functional requirements as the focus stayed on the functional requirements. Non-functional requirements were less visible, so this "corner cutting" went unnoticed. For example, the functional requirements for a spacious ball room resulted in four of the bulkheads not extending to the top deck severely compromising the ability to self contain flooding. It wasn't just the business executives, principally Director Bruce Ismay, who was responsible for this but also the technical people both the White Star architects and the Harland-Wolff constructors.
By the end of the project construction stage, most of these safety features had been compromised. The height of the bulkheads was only 10 feet above the waterline in some places. The logical explanation to these compromises is that assumptions were made by the White Star architects that the "aggregated" safety features incorporated would protect Titanic from whatever nature handed out.
By the end of project, the project team believed that the safety levels were still maintained at initial levels. So this set a high level of confidence for the maiden voyage or production. The arrogant view evolved that Titanic was a huge lifeboat. The Titanic project team made the mistake of believing the initial design assumptions, and not testing these far enough. Such was the confidence in the safety of the ship that by the end of the project, disaster recovery and business continuity plans were considered superfluous.
In short, the people "who should have got it"--the architects--allowed the compromises to pass. As the ship went into operation, a perception emerged that even if things did go wrong operationally the ship had enough safety features to protect it. This instilled a mindset in the crew and passengers that the ship was unsinkable. Why else were 53 millionaires aboard?
Even JP Morgan, the richest man in the world, cancelled his trip the night before. The ship set forth, after a grossly inadequate "testing" phase, and enormous operational risks were taken. The ship's speed was steadily increased as it approached the ice field. Compromises were then made operationally as the "ice bucket" test was fudged, radio ice warnings were not passed to the bridge in a timely fashion and a minimum number of lookouts posted without binoculars. The ship's officers failed to piece together the extent of the ice field and understand the true danger as the feedback systems went awry.
Pull it back to today and there are many comparatives that can be made to modern IT projects from construction, right into production. For example, there are many similarities in how IT project problems and issues surface days, months or even years after the project is completed and in production.
IT projects may be successful on deployment and pass a broad number of "standard" tests (system, performance and acceptance) yet still fail catastrophically in operation. After all, only 25 percent of all IT projects are successful, a figure that has been continuously verified in various surveys (Only 26 percent of all IT projects finish on-time, on-budget and with all the features and functions originally specified according to "Chaos, a recipe for success," Standish Group, 1994, 1996, 1998).
The success of IT projects should not be measured on deployment but after the solution has been in production for a while and carefully measured. Metrics should be closely tied to the overall impact to the business. The Titanic story helps us better understand the relationship between functional and non-functional requirements, the interplay of compromises in the project and why things go horribly wrong in operation.
The next installment will look at calculating the real cost of IT projects.
Mark Kozak-Holland recently completed his book On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive (IBM Press). It is about delivering Internet projects in a world where on-time and on-budget is not enough. Mark is a Senior Management Consultant with IBM Global Services. He has been working with mission-critical solutions since 1985, specifically with the availability of business services to the end-user. Mark can be contacted via e-mail at email@example.com.
Want more content like this?
Sign up below to access other content on ProjectManagement.com
Already Signed up? Login here.