As we continue Titanic's story, we focus on the four-year construction project, which had a significant impact on the operation and the disaster. Titanic's project startup and business requirements stage went according to plan, creating a solid business case and a strong business rationale for building three super liners. The competitive differentiator was based on creating an ultimate passenger experience based on luxury using the latest in emerging technologies (see part 1). This second article examines the second stage of Titanic's project--the design--and highlights how bad decisions in this stage can have a detrimental effect later in operation. In essence, this article is a case study for today's IT projects.

As part of the design stage, Titanic's architects transferred the business requirements into the functional requirements of the ship, principally hospitality and transportation. These functions defined accommodation, catering, recreation, entertainment, and the shipment of passengers and cargo. In contrast, the nonfunctional requirements define the operational characteristics of a system, as explained in the first article. For Titanic's architects this included reviewing safety, performance, stability, security, maintainability, and the environment. Effectively, no matter what the functional requirements specified, the nonfunctional requirements ensured the ship could deliver these in all situations and conditions.

Likewise, today's IT projects include nonfunctional requirements, such as availability (safety), security, and system management based on system runtime properties. Other nonfunctional requirements based on system non-runtime properties include scalability, portability, maintainability, environmental factors, and evolvability. As with ships, the nonfunctional requirements ensure that the system delivers the functions it was designed for, incredibly important to get right in the design stage as addressing these further into the project becomes very expensive.

In determining Titanic's nonfunctional requirements, like safety, the architects had to consider various worst-case scenarios to determine alternative safety features and their optimum implementation, i.e., size, scope, and numbers of. For example, if the ship ran aground, the hull could sustain ruptured plates along the bottom, which would cause major flooding. In another scenario, a front-end collision could cause massive damage to the ship, depending on speed and the type of object struck, such as docks, other ships, rocks, and icebergs. Similarly, a side-impact collision to the ship could cause severe damage and flooding through a ruptured skin. The architects had to identify the critical areas of a ship that were prone to risk, rather like automobile manufacturers would do today when designing new vehicles.

Likewise, with today's IT projects, to determine nonfunctional requirements, like availability, the approach requires that the designers first determine the scope: Does the whole solution or only part of it need to be architected to meet minimum levels? This is done through four steps:

1. Identify the critical areas of the solution.
2. Identify the critical components (hardware and software) within each critical area.
3. Determine each component's availability and risk.
4. Model worst-case failure scenarios.

The approach is essentially bottom-up and models what-if scenarios for the failure of a single critical component or for aggregate components within an area. It tests these scenarios using architecture models of the solution. This analysis provides a clear understanding of the overall risk of a component and its interdependencies, which leads to an overall view of both the technical and business risks.

Titanic's architects assessed the safety features to be had and selected one of four levels of safety. They based their decision on the possible what-if failure scenarios and the required investments. These four levels lay between the lowest level (defined as having no safety features, in which the ship had the characteristics of a closed rowing boat--good enough near land but not in open sea) and the highest level (defined as having comprehensive safety features, in which the ship had a lifeboat seat for everyone on board, water pumps, double hull, multiple water compartments, sealed bulkheads, electric doors, a collision ram, and pressurized air to force water out). Ultimately, the ship had the characteristics of an ocean-going vessel, able to undertake most conditions--the highest level of safety.

Likewise, today's IT projects need to assess availability features and make investment choices. There are numerous software and hardware solutions available for improving business against the five classes of outages (physical, design, operations, environmental, and reconfiguration). These solutions and techniques include everything from fault-tolerant or clustered systems to tiering, which enables "sideways scalability" by eliminating single failure points through replication and redundancy.

In keeping with the philosophy of building the best ship possible with the latest emerging technologies, Titanic's architects opted for the highest level of safety features. However, there was a turning point in the project when the architects took a step back to review what they had just designed. So advanced was the design that a perception evolved that Titanic was practically unsinkable. This was based on the aggregated effect of all of the advanced safety features, the use of latest technologies, the broad hull design, and the sheer size of the ship (50% increase in length over the last great ships built). What in nature could possibly affect Titanic? It appeared that Titanic was invincible.

At the same time, executive business pressure, notably from White Star Director Bruce Ismay, was still pushing to create the ultimate (first-class) passenger experience, and this would impact some of the safety features. For example, there was a desire to build a spacious 200-foot ballroom, which would cut straight across four of the bulkheads in the center of the ship. Similarly, there was a desire to give a clear ocean vista to the first-class suites on the promenade deck, which was also the lifeboat deck. As a result, Titanic's grossly overconfident architects relented to Bruce Ismay's pressures and made serious compromises to the safety features, believing they would still have a very safe ship. In the end, four of the bulkheads did not reach the top deck and were only 10 feet above the water line. On the promenade/lifeboat deck, the 48 triple-stacked lifeboats that would have obscured the ocean view were reduced to a single bank of 16 lifeboats, well below the capacity of the ship.

Likewise, in today's IT projects, hundreds of micro decisions are made daily or weekly that are deemed too technical for business executives. In fact, it can be difficult to keep track of these and their overall impact on the final business solution. Nonfunctional requirements are typically beyond the comfort zone of most business executives, so any compromises to these may not be readily understood. Yet they may have a major impact later, once the solution is in production, and can affect the business itself. So the business executive may unknowingly or knowingly put the business at risk.

By Titanic's construction stage, it was too late. Although the ship's nonfunctional requirements had been severely compromised, there was little acknowledgement that anything was seriously wrong. Titanic's architects still believed that Titanic was practically unsinkable and could survive any situation. In hindsight, it is easy to see how the architects viewed the lifeboats as an added safety feature, something useful if Titanic had to rescue another ship in distress. Of course, Titanic itself would never be a ship in distress. This belief justified the horrendous decision to limit the lifeboats to 16.

As the ship was constructed, the visible sumptuous investments in the state-of-the-art passenger comforts (functionals) implied that there was an equivalent investment in the less-visible safety and operations features (nonfunctionals). Rather like buying a luxury automobile today, you expect that the hefty price tag reflects that the basics, like safety, are covered. The perception of the ship's invincibility led White Star to market Titanic to the public as a ship that was practically unsinkable.

Lessons from History

Today, many IT projects are severely compromised in the design and construction stages, almost unknowingly because the impact of these compromises may not be readily apparent. Often, the problems do not surface until after the project is completed and the business solution is in production--possibly weeks or months later. These compromises are made when careful attention is not paid to the nonfunctional requirements. Very often, these requirements are sacrificed because they are not visible and their importance is not highlighted to business people, project leaders, or executive decision-makers. Project managers need to ensure that both sets of requirements receive equal attention. With hundreds of micro decisions being made weekly, project managers also need to aggregate the impact of these adequately for the business executives to understand. It is vital that a technical risk assessment is completed, which includes looking at how the new solution is architected for availability, and an outline of the safety features for high availability.

The next installment of IT Project Lessons from Titanic will look in more detail at the compromises made in the planning and testing of projects.

Mark Kozak-Holland 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 is passionate about history and contends that paying attention to how historical projects and emerging technologies of the past solved complex problems of the day provides valuable insight into how to solve today's more challenging business problems.

Mark's book On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive (IBM Press) is about delivering Internet projects in a world where on time and on budget is not enough. IT professionals need to be online--connecting to the Internet and dealing with the 24x7 expectations of customers and partners. The book is designed to help the business executive successfully maneuver through the ice floes of IT project management in an industry with a notoriously high project failure rate.

Mark can be contacted via email at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

The Principles of Project Management, Part 1

COVID-19 and Working from Home

Internship Tales