Category Archives: Project Management

Titanic Project Management & Comparison with Software Projects

Few projects have ever taken on the fame and notoriety of that achieved by the Titanic and her sister Olympic ships, the Olympic and the Britannic, which began design one hundred and ten years ago this year.  There are, of course, many lessons that we can learn from the fate of the Olympic ships in regards to project management and, in fact, there are many aspects of project management that are worth covering.

(When referring to the ships as a whole I will simply reference them as The Olympics as the three together were White Star Line’s Olympic Class ships.  Titanic’s individual and latter fame is irrelevant here.  Also, I am taking the position here that the general information pertaining to the Olympic ships, their history and fate are common knowledge to the reader and will not cover them again.)

Given the frequency with which the project management of the Olympics has been covered, I think that it is more prudent to look at a few modern parallels where we can view current project management in today’s world through a valuable historic lens.  It is very much the case that project management is a discipline that has endured for millennia and many of the challenges, skills and techniques have not changed so much and the pitfalls of the past still very much apply to us today.  The old adage applies, if we don’t learn from the past we are doomed to repeat it.

My goal here, then, is to examine the risk analysis, perception and profile of the project and apply that to modern project management.

First, we must identify the stakeholders in the Olympics project. White Star Lines itself (sponsoring company and primary investor) and its director Joseph Bruce Ismay, Harland-Wolff (contracted ship builder) with its principle designers Alexander Carlisle and Thomas Andrews, the ships’ crew which includes Captain Edward John Smith, the British government as we will see later and, most importantly, the passengers.

As with any group of stakeholders there are different roles that are played.  White Star on one side is the sponsor and investor and in a modern software project would be analogous to a sponsoring customer, manager or department.  Harland-Wolff were the designers and builders and were most closely related to software engineering “team members” in a modern software team, the developers themselves.  The crew of the ships were responsible for operations after the project was completed and would be comparable to an IT operations team taking over the running of the final software after completion.  The passengers were much as end users today, hoping to benefit from both the engineering deliverable (ship or software) and the service build on top of that product (ferry service or IT managed services.) (“Olympic”)

Another axis of analysis of the project is that of chicken and pig stakeholders where chickens are invested and carry risk while pigs are fully invested and carry ultimate risk.  In normal software we use these comparatives to talk about degrees of stakeholders – those which are involved versus those that are committed, but in the case of the Olympic ships these terms take on new and horrific meaning as the crew and passengers literally put their lives on the line in the operational phase of the ships, whereas the investors and builders were only financially at risk. (Schwaber)

Second, I believe that it is useful to distinguish between different projects that exist within the context of the Olympics.  There was, of course, the design and construction of the three ships physically.  This is a single project, with two clear components – one of design and one of construction.  And three discrete deliverables, namely the three Olympic vessels.  There is, at the end of the construction phase, an extremely clear delineation point where the project managers and teams involved in the assembly of the ship would stop work and the crew that operated the ship would take over.

Here we can already draw an important analogue to the modern world of technology where software products are designed and developed by software engineers and, when they are complete, are handed over to the IT operational staff who take over the actual intended use of the final product.  These two teams may be internal under a single organizational umbrella or from two, or more, very separate organizations.  But the separation between the engineering and the operational departments has remained just as clear and distinct in most businesses today as it was for ship building and ferry service over a century ago.

We can go a step farther and compare White Star’s transatlantic ferry service to many modern software as a service vendors such as Microsoft Office 365, Salesforce or G Suite.  In these cases the company in question has an engineering or product development team that creates the core product and then a second team that takes that in-house product and operates it as a service.  This is increasingly an important business model in the software development space that the same company creating the software will be the ultimate operator of it, but for external clients.  In many ways the relevance of the Olympics to modern software and IT is increasing rather than decreasing.

This brings up an important interface understanding that was missed on the Olympics and is often missed today: each side of the hand-off believed that the other side was ultimately responsible for safety.  The engineers touted their safety of design, but when pushed were willing to compromise assuming that operational procedures would mitigate the risks and that their own efforts were largely redundant.  Likewise, when pushed to keep things moving and make good time the operations team were willing to compromise on procedures because they believed that the engineering team had gone so far as to make their efforts essentially wasted, the ship being so safe that operational precautions just were not warranted.  This miscommunication took the endeavor from having two types of systems of extreme safety down to basically none.  Had either side understood how the other would or did operate, they could have taken that into account.  In the end, both sides assumed, at least to some degree, that safety was the “other team’s job”.  While the ship was advertised heavily based on safety, the reality was that it continued the general trend of the past half century plus, where each year ships were made and operated less safely than the year before. (Brander 1995)

Today we see this same problem arising between IT and software engineering – less around stability (although that certainly remains true) but now about security, which can be viewed similarly to safety in the Olympics’ context.  Security has become one of the most important topics of the last decade on both sides of the technology fence and the industry faces the challenges created by the need for both sides to action security practices thoroughly – neither is capable of truly implementing secure systems alone. Planning for safety or security is simply not a substitute for enforcing it procedurally during operations.

An excellent comparison today is British Airways and how they approach every flight that they oversee as it crosses the Atlantic.  As the primary carrier of air traffic over the North Atlantic, the same path that the Olympics were intended to traverse, British Airways has to maintain a reputation for excellence in safety.  Even in 2017, flying over the North Atlantic is a precarious and complicated journey.

Before any British Airways flight takes off, the pilots and crew must review a three hundred page mission manual that tells them everything that is going on including details on the plane, crew, weather and so forth.  This process is so intense that British Airways refuses to even acknowledge that it is a flight, but officially refers to every single trip over the Atlantic as a “mission”; specifically to drive home to everyone involved the severity and risk involved in such an endeavor.  They clearly understand the importance of changing how people think about a trip such as this and are aware of what can happen should people begin to assume that everyone else will have done their job well and that they can cut corners on their own job.  They want no one to become careless or begin to feel that the flight, even though completed several times each day, is ever routine. (Winchester)

Had the British Airways approach been used with the Titanic, it is very likely that disaster would not have struck when it did.  The operational side alone could have prevented the disaster.  Likewise, had the ship engineers been held to the same standards as Boeing or AirBus today they likely would not have been so easily pressured by management to modify the safety requirements as they worked on the project.

What really affected the Olympics, in many ways, was a form of unchecked scope creep.  The project began as a traditional waterfall approach with “big design up front” and the initial requirements were good with safety playing a critical role.  Had the original project requirements and even much of the original design been used, the ships would have been far safer than they were.  But new requirements for larger dining rooms or more luxurious appointments took precedence and the scope and parameters of the project were changed to accommodate these new changes.  As with any project, no change happens in a vacuum but will have ramifications for other factors such as cost, safety or delivery date. (Sadur)

The scope creep on the Titanic specifically was dramatic, but hidden and not necessarily obvious for the most part.  It is easy to point out small changes such as a shift of dining room size, but of much greater importance was the change in the time frame in which the ship had to be delivered.  What really altered the scope was actually that initial deadlines and projects had to be maintained, relatively strictly.  This was specifically problematic because in the midst of Titanic’s dry dock work and later moored work, the older sibling, Olympic, was brought in for extensive repairs multiple times which had a very large impact on the amount of time in the original schedule available for Titanic’s own work to be completed.  This type of scope modification is very easy to overlook or ignore, especially in hindsight, as the physical deliverables and the original dates did not change in any dramatic way.  For all intents and purposes, however, Titanic was rushed through production much faster than had been originally planned.

In modern software engineering it is well accepted that no one can estimate the amount of time that a design task will take as well as the engineer(s) that will be doing the task themselves.  It is also generally accepted that there is no means of significantly speeding up engineering and design efforts through management pressure. Once a project is running at maximum speed, it is not going to go faster.  Attempts to go faster will often lead to mistakes, oversights or misses.  We know this to be true in software and can assume that it must have been true for ship design as well as the principles are the same.  Had the Titanic been given the appropriate amount of time for this process, it is possible that safety measures would have been more thoroughly considered or at least properly communicated to the operational team at hand off.  Teams that are rushed are forced to compromise and since time cannot be adjusted as it is the constraint, the corners have to be cut somewhere else and, almost always that comes from quality and thoroughness.  This might manifest itself as a mistake or perhaps as failing to fully review all of the factors involved when changing one portion of a design.

This brings us to holistic design thinking. At the beginning of the project the Olympics were designed with safety in mind: safety that results from the careful inter-workings of many separate systems that together are intended to make for a highly reliable ship.  We cannot look at the components of a ship of this magnitude individually, they make no sense – the design of the hull, the style of the decks, the weight of the cargo, the materials used, the style of the bulkheads are all interrelated and must function together.

When the project was pushed to complete more quickly or to change parameters this holistic thinking and a clear revisiting of earlier decisions was not done or not done adequately.  Rather, individual components were altered irrespective of how that would impact their role without the whole of the ship and the resulting impact to overall safety.  What may have seemed like a minor change had unintended consequences that were unforeseen because holistic project management was abandoned.  (Kozak-Holland)

This change to the engineering was mirrored, of course, in operations.  Each change, such as not using binoculars or not taking ice bucket readings, were individually somewhat minor, but taken together they were incredibly impactful.  Likely, but we cannot be sure, a cohesive project management or, at least, process improvement system was not being used.  Who was overseeing that binoculars were used, that the water tests were accurate and so forth?  Any check at all would have revealed that the tools needed for those tasks did not exist, at all.  There is no way that so much as a simple test run of the procedures could have been performed, let alone regular checking and process improvement.  Process improvement is especially highlighted by the fact that Captain Smith had had practice on the RMS Olympic, caused an at-sea collision on her fifth voyage and then nearly repeated the same mistake with the initial launch of the Titanic.  What should have been an important lesson learned by all captains and pilots of the Olympic ships instead was ignored and repeated, almost immediately. (“Olympic”)

Of course ship building and software are very different things, but many lessons can be shared.  One of the most important lessons is to see the limitations faced by ship building and to recognize when we are not forced to retain these same limitations when working with software.  The Olympic and Titanic were built nearly at the same time with absolutely no time for engineering knowledge gleaned from the Olympic’s construction, let alone her operation, to get to be applied to the Titanic’s construction.  In modern software we would never expect such a constraint and would be able to test software, at least to some small degree, before moving on to additional software that is based upon it either in real code or even conceptually.  Project management today needs to leverage the differences that exist both in more modern times and in our different industry to the best of its advantage.  Some software projects still do require processes like this but these have become more and more rare over time and today are dramatically less common than they were just twenty years ago.

It is well worth evaluating the work that was done by Harland-Wolff with the Olympics as they strove very evidently to incorporate what feedback loops were possible within their purview at the time.  Not only did they attempt to use the construction of earlier ships to learn more for the later ones, although this was very limited as the ships were mostly under construction concurrently and most lessons would not have had time to have been applied, but far more importantly they took the extraordinary step of having a “guarantee group” sail with the ships.  This guarantee group consisted of all manner of apprentice and master ship builders from all manner of support trades.  (“Guarantee Group”)

The use of the guarantee group for direct feedback was, and truly remains, unprecedented and was an enormous investment in hard cost and time for the ship builders to sacrifice so many valuable workers to sale in luxury back and forth across the Atlantic.  The group was able to inspect their work first hand, see it in action, gain an understanding of its use within the context of the working ship, work together on team building, knowledge transfers and more.  This was far more valuable than the feedback from the ship yards where the ships were overlapping in construction, this was a strong investment in the future of their ship building enterprise: a commitment to industrial education that would likely have benefited them for decades.

Modern deployment styles, tools and education have led from the vast majority of software being created under a Waterfall methodology not so distinct from that used in turn of the [last] century shipbuilding, to most leveraging some degree of Agile methodologies allowing for rapid testing, evaluation, changes and deployment.  Scope creep has changed from something that has to be mitigated or heavily managed to something that can be treated as expected and assumed within the development process even to the point of almost being leveraged.  One of the fundamental problems with big design up front is that it always requires the customer or customer-role stakeholder to make “big decisions up front” which are often far harder for them to make than the design is for the engineers.  These early decisions are often a primary contributor to scope creep or to later change requests and can often be reduced or avoided by agile processes that expect continuous change to occur to requirements and build that into the process.

The shipbuilders, Harlan and Wolff, did build a fifteen foot model of the Olympic for testing which is useful to some degree, but of course failed to mimic the hydrological action that the full size ship would later produce and failed to predict some of the more dangerous side effects of the new vessel’s size when close to other ships which led to the first accident of the group and to what was nearly a second.  The builders do appear to have made every effort to test and learn at every stage available to them throughout the design and construction process. (Kozak-Holland)

In comparison to modern project management this would be comparable to producing a rapid mock-up or wireframe for developers or even customers to get hands-on experience with before investing further effort into what might be a dead end path for unforeseen reasons.  This is especially important in user interface design where there is often little ability to properly predict usability or satisfaction ratings without providing a chance for actual users to physically manipulate the system and judge for themselves if it provides the experience for which they are looking. (Esposito)

We must, of course, consider the risk that the Olympics undertook within the context of their historical juxtaposition in regards to financial trends and forces.  At the time, starting from the middle of the previous century, the prevailing financial thinking was that it was best to lean towards the risky, rather than towards the safe – in terms of loss of life, cargo or ships; and to overcome the difference via insurance vehicles.  It was simply too financially advantageous for the ships to operate in a risky manner than to be overly cautious about human life. This trend, by the time of the Olympics, had been well established for nearly sixty years and would not begin to change until the heavy publicity of the Titanic sinking.  The market impact to the public did not exist until the “unsinkable” ship, with so many souls aboard, was lost in such a spectacular way.

This approach to risk and its financial trade offs is one that project managers must understand today the same as they did over one hundred years ago.  It is easy to be caught believing that risk is so important that it is worth any cost to eliminate, but projects cannot think this way.  It is possible to expend unlimited resources in the pursuit of risk reduction.  In the real world it is necessary that we balance risks with the cost of risk mitigation.  A great example of this in modern times, but outside that of software development specifically, is in the handling of credit card fraud in the United States.  Until just the past few years, it has generally been the opinion of the US credit card industry that the cost of greater security measures on credit cards to prevent theft were too high compared to the risks of not having them; essentially it has been more cost effective to spend money in reimbursing fake transactions than it was to prevent those fake transactions. This cost to risk ratio can sometimes be counterintuitive and even frustrating, but is one that has to drive project decisions in a logical, calculated fashion.

In a similar vein, it is common in IT to design systems believing that downtime is an essentially unlimited cost and to spend vastly more attempting to mitigate a downtime risk than the cost of the actual outage event itself would likely be if it were to occur.  This is obviously foolish, but so rarely are cost analysis of this type run or run correctly it becomes far too easy to fall prey to this mentality.  In software engineering projects we must approach risks in a similar fashion.  Accepting that there is risk, of any sort, and determining the actual risk, the magnitude of the impact of that risk and comparing that against the cost of mitigation strategies is critical to making an appropriate project management decision in regards to the risk. (Brander 1995)

Also of particular interest to extremely large projects, of which the Olympics certainly qualified, there is an additional concept of being “too big to fail.”  This, of course, is a modern phrase that came about during the financial crisis of the past decade, but the concept and the reality of this is far older and a valuable consideration to any project that falls onto a scale that would register a “national financial disaster” should the project totally falter.  In the case of the Olympics the British government ultimately insulated the investors from total disaster as the collapse of one of the largest passenger lines would have been devastating to the country at the time.

White Star Lines was simply “too big to fail” and was kept afloat, so to speak, by the government before being forcibly merged into Cunard some years later.  This concept, knowing that the government would not want to accept the risks of the company failing, may have been calculated or considered at the time, we do not know.  We do know, however, that this is taken into consideration today with very large projects.  An example of this happening currently is that of Lockheed Martin’s F-35 fighter which is dramatically over budget, past its delivery date and no longer even considered likely to be useful has been buoyed for years, but different government sponsors who see the project as too important, even in a state of failure to deliver, for the national economy to allow the project to fully collapse.  As this phenomenon becomes better and better known, it is likely that we will see more projects take this into consideration in their risk analysis phases. (Ellis)

Jumping to the operational side of the equation we could examine any number of aspects that went wrong leading to the sinking of the Titanic, but at the core I believe that what was most evident was a lack of standard operating procedures throughout the process.  This is understandable to some degree as the ship was on its maiden voyage and there was little time for process documentation and improvement.  However this was the flagship of a long standing shipping line that had a reputation to uphold and a great deal of experience in these matters.  It would also overlook that by the time that Titanic was attempting its first voyage that the Olympic had already been in service far more than enough to have developed a satisfactory set of standard operating procedures.

Baseline documentation would have been expected even on a maiden voyage, it is unreasonable to expect a ship of such scale to function at all unless there is coordination and communication among the crew.  There was plenty of time, years in fact, for basic crew operational procedures to be created and prepared before the first ship set sale and, of course, this would have to be done for all ships of this nature, but it was evident that such operating procedures were lacking, missing and untested in the case of the Titanic.

The party responsible for operating procedures would likely be identified as being from the operations side of the project equation, but there would need to be some degree of such documentation provided by or coordinated with the engineering and construction teams as well.  Many of the procedures that broke done on the Titanic included chain of command failures under pressure with the director of the company taking over the bridge and the captain allowing it, wireless operators being instructed to relay passenger messages as a priority over iceberg warnings, allowing wireless operators to tell other ships attempting to warn them to stop broadcasting, critical messages not being brought to the bridge, tools needed for critical jobs not being supplied and so forth. (Kuntz)

Much like was needed with the engineering and design of the ships, the operations of the ships needed strong and holistic guidance ensuring that the ship and its crew worked as a whole rather than looking at departments, such as the Marconi wireless operators, as an individual unit.  In that example, they were not officially crew of the ship but employees of Marconi who were on board to handle paid passenger communiques and to only handle ship emergency traffic if time allowed.  Had they been overseen as part of a holistic operational management system, even as outside contractors, it is likely that their procedures would have been far more safety focused or, at the very least, that service level agreements around getting messages to the bridge would have been clearly defined rather than ad hoc and discretionary.

In any project and project component, good documentation whether of project goals, deliverables, procedures and so forth are critical and project management has little hope of success if good communications and documentation are not at the heart of everything that we do, both internally within the project and externally with stakeholders.

What we find today is that the project management lessons of the Olympic, Titanic and Britannic remain valuable to us today and the context of the era whether pushing for iterative project design where possible, investing in tribal knowledge, calculating risk, understanding the roles of system engineering and system operations or the interactions of protective external forces on product costs are still relevant.  The factors that affect projects come and go in cycles, today we see trends leaning towards models more like the Olympics than dislike them. In the future, likely, the pendulum will swing back again.  The underlying lessons are very relevant and will continue to be so.  We can learn much both by evaluating how our own projects are similar to those of White Star and how they are different to them.

Bibliography and Sources Cited:

Miller, Scott Alan.  Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.

Esposito, Dino. “Cutting Edge – Don’t Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.

Sadur, James E. Home page. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.

Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16 February 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.

Additional Notes:

Mark Kozak-Holland originally published his book in 2003 as a series of Gantthead articles on the Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” the Online Community for IT Project Managers and later (2003): 8 February 2017.

More Reading:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.

Project Management of the RMS Titanic and the Olympic Ships

The idea to build the R.M.S. Titanic and her sisters, the R.M.S. Olympic and the H.M.H.S. Britanic, first began to take shape in 1907. These three ships together were White Star Line’sOlympic Classocean liners. (I will use the Olympic(s) in reference to the class of vessels throughout this text for the sake of clarity.) Few vessels in human history have become as well known and infamous as the R.M.S. Titanic.

In examining the R.M.S. Titanic from a perspective of project management it is important to first identify what type of product this project was set to produce. Unlike many projects where the final customer will own the final product the Titanic was designed to deliver a service, particularly a ferry service, to its end customers. This creates an interesting challenge in discussing “Project Titanic” since most views of project management see a project as having a discrete beginning and end as well as clear, well-defined stakeholders.

In the case of a project such as the R.M.S. Titanic we can take two views and approach the issue from two sides. In one case we have the project by which the three ships of the Olympic class were conceived, designed, built and delivered to White Star Lines. In the other case we have the R.M.S. Titanic as it was customized beyond the extend of its elder, the R.M.S. Olympic, completed in initial production and delivered, as a service, to the passengers which it was to ferry between Southampton and New York. To maintain scope I will not discuss the even larger project of testing, bug fixes, repairs, scope changes and enhancements that were applied to the two sister ships after the sinking of the R.M.S. Titanic. Both the R.M.S. Olympic and the H.M.H.S. Britanic saw many changes during their years of service including the re-scoping of the Britanic from the role of an ocean liner to that of His Majesty’s Navy’s principle hospital ship during World War 1 and the outfitting of the Olympic with a double hull and additional life boats as the crew refused to sail her until she had been made more safe. (“Olympic”)

It is my goal here to examine the Titanic as a service from conception to service delivery and, ultimately, service failure. From this perspective the Titanic can be treated much like one would treat a modern Software-as-a-Service (SaaS) project. Because of the nature of a ship such as the Titanic or SaaS products such as or SugarCRM we need to consider the intended lifespan of the product and the ongoing upgrades and maintenance that will be needed to keep it operating. The Titanic requires a huge staff of pilots, seamen, chefs, porters, stewards and more while at sea and required re-outfitting, repairs and, had she survived, she would have needed a new double-hull like the R.M.S. Olympic received. A SaaS project will similarly require a staff to maintain the datacenter and networking, ongoing upgrades and bug-fixes, new features, etc. In both the case of the Titanic and of a SaaS project there is a real potential for a service disruption that could prove to be extremely costly. Maintaining steady, reliable operations is a major factor in the success of either of these business plans.

Let’s begin our analysis of the project to bring the Titanic to fruition by examining the stakeholders. We can easily identify the passengers and crew of the Titanic as stakeholders, White Star Lines as a company as well as the project engineers, Harland-Wolff as the constructors, Alexander Carlisle and Thomas Andrews as shipwrights and designers at Harland-Wolff, Captain Edward John Smith who was responsible for service delivery and finally White Star director Joseph Bruce Ismay and his executive staff who were in the role of project sponsor. In any project of this size there will be many important players all of whom have some stake in the project. We will focus just upon these key people as the most prominent stakeholders in the Titanic project.

The Titanic project most closely resembled a Waterfall Model in IT Project Management parlance. The process started with a high level concept coming jointly from Joseph Bruce Ismay representing White Star Lines and Lord James Pirrie representing their ship building partner, Harland-Wolff. The project was conceived jointly between the two companies. The Titanic would offer great prestige and profit potential for both firms and would require a large investment from both. While we do not appear to have the original project charter available to us today we can view the meeting between Ismay and Lord Pirrie as the unofficial project charter and the initiation of the project. (Sadur)

The technical design of the Olympic class ships was undertaken by Harland-Wolff head shipwright, Alexander Carlisle, after high level plans had been drawn up by Ismay and Lord Pirrie. Carlisle was the lead designer on the project from its inception until 1910 when he retired and turned over the lead design role to Thomas Andrews the managing director of Harland-Wolff (Brander 1998). Andrews would be responsible for the final stages of the Titanic’s design. The Olympic, launched in the fall of 1910, would have been most likely completely designed under the direction of Carlisle. Since the Titanic shared almost all of the infrastructure of the Olympic (hull design, compass placement, lifeboats, bridge, etc.) we can safely assume that Andrews’ contributions to the design of the Titanic were mostly aesthetic or, in software development terms, “interface” related. (Thinkquest)

Because of the construction-like nature of shipbuilding and especially with mammoth ships such as the Olympics the design process involves heavy upfront design with very limited feedback loops later on once the designers can physically inspect the ship. In software terms this is referred to as “Big Design Up Front” or BDUF. In software where changing requirements are common this is generally considered to be a very bad practice but in mechanical and structural engineering this is simply the only reasonable solution.

As work progressed on the Olympics several decisions were made regarding the core infrastructure design of the ships. This is especially dangerous as the methodology in place for this type of project was not designed to allow for changes of this nature once the plans were approved. A ship is designed as a holistic system with interdependent safety systems and a high degree of complexity. Unlike most software it is very difficult to rapid-prototype a ship to the degree of accuracy needed to ensure safety. Making key changes to safety systems would have required a full scale reworking of the specifications to be done correctly. But since changes were made because of cost savings, timeline issues and luxury appointments there was little holistic thinking put into the changes. (Kozak-Holland)

The original design and intent of the Olympics was that they would incorporate the very latest technologies for safety. After the initial design was complete business pressure from White Star Lines and especially J.B. Ismay was put onto the architects and engineers to remove safety features in favor of first class luxuries. The two most famous changes were, of course, the removal of the lifeboats so that the views from the cabins would not be unnecessarily obscured and the modification of several of the bulkheads to no longer seal and to rise just ten feet above the water level in order to allow for an expanded grand ballroom facility. As with IT projects, engineering decisions for core systems are generally beyond the ken of business executives. Allowing business side decisions to influence otherwise technical decisions is dangerous as the usual precautions and thought processes are bypassed and expertise is overlooked. In this case these were issues pertaining to the care and preservation of human life. In software we seldom have such an important task at hand but allowing business managers without understanding of key systems to be involved in their design can be exceedingly harmful even if the result is as benign as loss of business or greater cost of operations.

One of the most dramatic problems that arose from late changes to the Olympics’ designs were that the changes, each being small on their own, were most likely never taken together and examined as a whole in the same manner that the original ship design was considered. When the lifeboats were removed the engineers involved were thinking that the ship was designed to be a floating life raft and that the purpose of the life boats was simply to ferry passengers from a motionless ocean liner to another ship in the “worst case scenario” that the Titanic or Olympic were to lose power. Even a collision was expected to only make them float low in the water, not to sink. The life boats were removed until only the minimum legal number remained at the behest of White Star Line’s executive committee. To the engineers this would have been an acceptable, although not recommended, safety trade-off. The design of the ship was such that having additional life boats was not a legal requirement nor was there any driving need to keep them as the usefulness of the additional boats was believed to be minimal. In the end, it would not have been the decision of the engineers but of White Star who was the final customer to the shipbuilders and whose decisions provided them with their livelihoods.

On its own the decision to remove the life boats would, most likely, have been a minor one. But additionally the decision was made to change the key structural design of the Olympics from having all tall bulkheads to having four of them be significantly lowered to just ten feet above the waterline meant that the concept of the ship as being a floating life raft was compromised. The bulkheads were never truly water tight as the marketing materials would have lead us to believe but they were quite tall and very water “resistant” and would have most likely been able to keep water from traveling between them under even a very serious hull breach. As the initial design of the ship was replete with safety features this would have been considered, like the life boats, to be a redundant feature and its removal would have only been lowering the ship to more common safety criteria. Taken individually the changes were mostly innocuous, but taken together the changes became a complete redesign of the ship and completely disastrous. At no point did the qualified engineers go back through and do a complete reassessment of the safety features of the ship with all of the changes in place.

In some respects we could look at J.B. Ismay as being a micro-manager. He did not trust the decisions of those that he hired for the purpose of their technical expertise and overrode, either directly or through indirect pressures, their decisions. Micro-managing has many negative results. The obvious being untrained and unqualified managers influencing decisions that others believe to have come from qualified professionals. Others include eroding the value generated by the project team and degrading employee loyalty and morale.

In ship building, in situations where ships are built of a class such as the Titanic, we need to consider three principle project phases – design and construction of the prototype, the Olympic; design refinement and construction of the Titanic; and finally service delivery and operations. In the case of the Titanic in particular we see that the principle design and any structural changes were made before the completion of the Olympic. Thomas Andrews sailed on the Olympic but this was mostly so that he could make aesthetic modifications for the Titanic as it was far too late for structural work to be changed at that point. For the same reason, Andrews was sailing on the Titanic so that he could do similarly for the soon to be launched Britanic (known to Andrews as the Gigantic.)

In terms of project scope we can see that the project adhered closely to the initially established plan. Construction was done based on preapproved plans with little change. The most dramatic changes in the scope occurred during the construction of the Titanic when the project had to be halted in order to accommodate the repairs of the Olympic. Both parties, Harland-Wolff and White Star Lines, understood that the Titanic would be delayed but that the serviceability of the Olympic took precedence. A major factor in any type of capital construction project is the need for contract level agreements between build phases as scope change is nearly impossible to accommodate once construction has begun. (“Olympic”)

It is difficult to find software projects that closely follow this type of model with a production prototype followed by a series of production implementations based upon the prototype but not identical to it. The closest example of this that I can postulate is the enterprise resource planning (ERP) package SAP. With this package, and others of its ilk, customers buy the package based upon its prototypical performance and features and then either on their own or through a consulting firm or the original vendor will heavily modify the package to their own needs. Generally the advantage to such an approach is that the core of the software package, the infrastructure, is very stable and well tested and often used across a wide degree of situations giving it both project side as well as client side testing. Care must be taken, of course, because customer initiated modifications will not have the benefit of the deep testing that one hopes has been performed on the core infrastructure nor do the changes have the benefit of “many eyes” from the wider client community.

In the case of the Olympic class ships there was serious testing done on the fifteen foot model of the ship and testing was done on the Olympic upon completion. With a ship of the Olympic’s complexity it is critical that real world testing be performed in addition to unit testing of individual systems. The Olympic was put through the usual testing measures that were standard for a ship of this type. However, when the Titanic was built the builders and the cruise line decided that as the Titanic was essentially a copy of the Olympic that the testing done and the ongoing successful use of the Olympic was test enough for the Titanic and the Titanic received very little additional testing. This, however, is not a best practice as mariners know that all ships, even copies, behave differently and each vessel is unique and must be tested on its own. (Kozak-Holland)

The Titanic was given almost no time for testing or performance trials. This came about partially because the Olympic had had a serious accident and had to be taken to the shipyards in Belfast and repaired. While the Olympic was under repairs the Titanic had to wait as only one ship of that size could be worked on at one time. This placed business time constraints on the Titanic as she was scheduled for regular transatlantic route duty and was needed immediately. Because of this, some additional testing that would likely have occurred was skipped and the Titanic was sent out with its primary testing being the journey from Belfast to Southampton, and, even on this leg of its journey, there was at least one paying passenger making it more a low capacity true voyage than a proper test. (Kozak-Holland)

It would appear that White Star Lines and J. B. Ismay were quite willing to take on exceptional project risk in order to get the ship into regular service as quickly as possible. Through standard maritime procedure they mitigated much of their capital risk through maritime insurance. This would protect them against many potential unknowns.

During the last half of the nineteenth century it was becoming increasingly common for both shipping lines as well as governments to see risk as a low priority issue. The S.S. Great Eastern built in 1858 is considered to have been, and proved to be in real world cases, far safer than the designs of the increasingly unsafe ocean going vessels that followed her over the next fifty-four years. Conditions would continue to decline until companies and governments reevaluated the situation in the wake of the Titanic’s sinking. It is argued that shipping companies saw acceptable safety track records as justifying their lackadaisical attitude towards safety over decades of relatively incident-free shipping. Financial market pressures won out favoring companies with loose safety standards encouraging the industry as a whole to move away from expensive risk management. (Brander 1995)

Under the guise of further mitigating risks due to a lack of testing and training, several crew members, most notably Captain Smith, were brought over from the Olympus to sail the Titanic on her maiden Atlantic crossing. This could be seen as Ismay seeking experience which would appear to lessen the “unknowns” derived from sailing a ship without testing her directly but at least having the maximum experience from the prototype vessel. However, this may not be the underlying reason for the decision and it is very possible that Captain Smith was chosen because his position with White Star Lines was rather questionable after he had just recently caused a serious accident involving the H.M.S. Hawke which had caused the Olympic to need emergency repairs and had delayed the sailing of the Titanic. Captain Smith was likely nervous, concerned for his career and in little mind or position to act as the final level of responsibility aboard the ship if pressures from the firm directed him against his better judgment. This may have been exactly the operational loophole that White Star Lines was seeking. This situation was probably exacerbated by Captain Smith coming in too close or too fast to the S.S. City of New York, when moored in Southampton, causing it to break its moorings and nearly collide with the Titanic. (Kozak-Holland)

Under customary maritime law, a captain is the absolute commander of the ship and has complete jurisdiction while at sea even if higher ranking officials, military or civilian, are aboard. The captain has moral and legal responsibilities first to the lives and safety of the passengers and crew and then to the cargo and the ship. (Kuntz)

Once the Titanic was built, outfitted and available for sailing we see a stage change and we move into the service delivery phase of the overall Titanic project. In this stage we are past the traditional stages of project management. In most scenarios a client would now have taken possession of the finished product. But in the case of the Titanic this becomes the service delivery phase.

Under service delivery White Star Lines took responsibility for any new issues that would arise with the ship. At this point the traditional system of design – build – test would no longer be used and instead the service delivery would be overseen by standard operating procedure or SOP. Ongoing ship modifications, repairs, tuning and the like would still continue but these would be designed to not be at the level of requiring a service interruption but would be minor and done without the knowledge of the final customers – the passengers. It is at this stage that the passengers arrive as our most critical stakeholders because, in this scenario, they are not just financial stakeholders but are literally staking their very lives on the reliability of the ship and the operations of the crew.

In the Agile Project Management community there is a fable often used to denote roles within the stakeholders. These roles are known as the pigs and the chickens. The fable tells us of a chicken and a pig who are interested in opening a restaurant together. The pig asks the chicken what they will serve. The chicken replies, “Well, bacon and eggs, of course.” To this the pig responds “I don’t think that I am interested. You will be involved but I will be totally committed.” (Schwaber 7)

The pig and the chicken metaphor is normally used to express the difference between stakeholders who have real money or careers on the line versus stakeholders who have a vested but non-critical interest in the project. The chickens would prefer not to see a project fail but failure is not necessarily devastating for them. In the case of the Titanic we see that the financial stakeholders, Harland-Wolff and White Star Lines, were effectively chickens. They had much to lose but their investment was insured and later, we will see, the government was even willing to protect companies of this nature at this time due to the pending war with Austria and Germany. Neither White Star nor Harland-Wolff were “totally committed” – they had a definite interest and the success of the Titanic was extremely important to them but the passengers and crew of the Titanic were truly the pigs here willing to put their very lives at stake. Seldom is the chicken and pig metaphor more appropriate.

In order to ensure a higher quality of ongoing service a guarantee group from Harland-Wolff was present on the maiden voyage. This team included many important members of the Harland-Wolff design and construction staff including the lead designer Thomas Andrews. This guarantee group was customary on all major projects of Harland-Wolff. This staff would use the voyage time to assess the construction under differing conditions from their tests, gauge customer satisfaction and look for opportunities for improvement. Thomas Andrews had already sailed on the Olympic for this very same purpose and had made many tiny changes to improve the Titanic. He would spend part of this journey, for example, designing less expensive clothing hooks for passenger rooms. (“Guarantee Group”)

The Guarantee Group comprised specialists from many different technical practices within Harland-Wolff. We see representation from the fitters, electricians, joiners, draughtsmen, design team and more. This group, with their varying specialist areas and their differing levels of experience with both seniors and apprentices included, would have been an exceptional cross-section of the project team that built the ship. Their presence aboard with the care given to appraising the workmanship, design and other final components can be seen in two principle ways.

In the first way we can see this as a “port-mortem” performed on the Titanic Project. It was the role of this team to assess the technical success of the project and to look for areas for improvement as well as to generate “lessons learned” so that future projects could benefit from the experience gained here. Considering the cost of the transatlantic trip and the time spent away from their regular duties this was a serious investment in project knowledge by Harland-Wolff and extremely commendable.

Taken in another light, this guarantee group could be seen as providing feedback on a construction iteration. The Olympic’s construction being the first iteration, the Titanic’s being the second and the Britanic’s being the third. In this approach we see a type of Agilefeedback loop being utilized, as much as possible, to allow for customer input even on such an extreme capital construction project. The iterations are very long, but this is by necessity. In this way we can view the Titanic as both a project unto itself, being a discrete deliverable, as well as being part of the ongoing project to deliver passenger service via the Olympic family of vessels.

The guarantee group being aboard ship would have presented the opportunity for the technical teams to get a first-hand appreciation of the real world application of their product. Rarely would a technical specialist be in a position, in 1912, to travel on a ship of this level of luxury. Without the sponsorship of Harland-Wolff in providing this chance for its staff to witness their own workmanship at work they might never understand their own roles in providing services to their final customers.

Having apprentices included in the guarantee group meant that direct one-on-one or small group, informal training could be performed. The apprentices and the senior technicians would have had many days to work together, and the apprentices would have had a great opportunity to learn from their seniors in a setting conducive to team building and knowledge transfer. In many ways we can see this time as being similar to off-campus team building sessions or retreats popular with many companies and project groups today.

Where we find the biggest surprise in our analysis of the Titanic is the almost total lack of standard operating procedure in use on board the ship. Some processes and procedures were documented but many were not. Examples of processes that were not standardized included key communications processes such as moving messages from the wireless office to the bridge, alerting passengers to the ship sinking and alerting the bridge that the crow’s nest had seen an iceberg. (Kozak-Holland)

Standard Operating Procedures are absolutely critical in any service delivery situation. In some companies these can even be considered so valuable as to be the core intellectual property of the company. Without the SOP a company is no more cohesive than the inherent “teamness” of the staff which, in cases of new employees, may be nominal. Staff will have to rely totally upon best practices, convention, informal staff instruction or, hopefully, training to learn their jobs and processes. But these will not be standardized if they are not written down and training will inevitably vary from trainer to trainer and no employee can retain all instructions for all possible scenarios.

Under normal conditions the lack of standard operating procedures may be of relatively minor importance. Staff can perform most job functions adequately, especially if trained, without needing an SOP. If they did they would need to carry the SOP with them at all times. When the SOP becomes extremely critical is when “normal operating procedures” are no longer available or, in more modern terms, when operations is no longer under BAU (Business as Usual) conditions. For the Titanic, BAU conditions were broken several hours before the iceberg incident.

In the case of the Titanic it is difficult to discuss standard operating procedures without also discussing communications. So we will begin with communications under BAU conditions and then see how the lack of an SOP caused the situation to deteriorate rapidly.

The Titanic was plagued with communication design flaws from the beginning. The wireless room, responsible for all communications going in and out of the Titanic, was not operated by White Star Lines but was instead staffed by Marconi personnel who were paid to communicate first and foremost for the passengers and for the ship only if time allowed. The wireless operators were overworked and undervalued and would often not relay messages to the bridge because they had other duties that were considered to be of a higher priority by Marconi, their employer. At least eight iceberg warnings were sent to the Titanic’s wireless room but only some of these were relayed to the bridge. (Kozak-Holland)

In this case it is important to emphasize the importance of managing third party contractors via a service level agreement. White Star Lines, in allowing the Marconi Company to staff its wireless room, should have had a clear SLA demanding that safety and emergency communications for the ship take absolute priority over the personal messages of the crew. They should also have not allowed Marconi to make an additional profit or be financially benefited by not following the SLA. As an outside contractor Marconi should have had a contract that was designed for mutual benefit – that is that when executed as stated that it was to all parties mutual benefits to act correctly. Contracts between vendors that give financial incentives for a vendor to work against the good of their client are very unwise.

The most important single incident involving the Marconi operators was the final iceberg warning sent by the SS California, which was extremely near to the Titanic – so near that later it would be the ship to see the emergency rockets from the Titanic. The California radioed the Titanic a warning that it had become trapped in pack ice and could not proceed, at any speed, due to the dangerous conditions. The Marconi operator replied “Shut up, shut up, I am busy. I am working Cape Race and you are jamming me.” It could hardly be made more clear where the priorities of the wireless room lay even with such danger looming so closely. Not only did the wireless room not keep communications open with the California but they also declined to inform the bridge of this final external warning. In frustration the California’s radio operator gave up his attempts to warn the Titanic, turned off his wireless and went to bed. The Marconi operators not only failed to heed the warnings but alienated external channels such that the only ship near enough to rescue them did not respond when the Titanic began to sink. (Kuntz)

Communications from the bridge to the crew at large and the passengers had no official process, was manual and was, at best, done in a best effort manner if it was attempted at all. The bridge did not notify anyone that a collision was immanent and no one was braced for what could have been a very serious impact. Once the ship began sinking it took over an hour before the bridge began informing the rest of the ship that they were going down. Key information affecting the lives of the passengers and crew was kept from them and held by just a few bridge personnel who were most likely hoping to keep the incident a secret or to minimize the publicity to the obvious risk to human life. As there was no system or process for communicating from the bridge to the ship in general this was a simple matter as it took a concerted effort to inform the passengers of any news at all. (Kozak-Holland)

Communications amongst the crew were little better. The Officer of the Watch, for example, was located outside of the bridge but his critical communications links were located inside of the bridge house. So the watch was unable to rapidly communicate to any other bridge personnel or to coordinate with the crow’s nest and other related functional areas. The crow’s nest and the watch were connected by a one way bell system that did not allow them to communicate in duplex and was very slow, and the watch had no means of feedback from the quartermaster at the helm when an emergency command was given. Commands were given by shouting from the open air towards the enclosed bridge. The watch could only hope that the quartermaster inside the bridge had heard, understood and was acting upon those commands. Communications from the standard compass were just as bad. The compass, instead of being located above or near the bridge, was placed far to the aft and the bridge was forced to coordinate with the compass on a regular basis which caused much confusion and delays. Little, if any, thought was put into making the bridge effective or safe. This lack of design for communication certainly did little to help the Titanic when rapid and accurate communications were necessary. (Brown)

When external communications to the White Star office in Boston were finally sent the information relayed was that there was no serious damage and that the incident was very minor. Unlike point to point information that is common today, however, this information was broadcast and could easily be intercepted by other ships and relay stations. Ship-to-shore communications were often used to effectively release information to the press under the guise of an internal communiqué. So instead of relaying honest and critical information the wireless was used as a marketing tool. What was sent was not a distress signal but was effectively nothing more than a press release designed to put “spin” on the situation. (Kozak-Holland)

Communications are key at any stage of any project. In the case of the Titanic the catastrophic situation highlights issues that occurred because of communications, but this is simply a worst case scenario. Projects need to have as much up-to-date and accurate data as possible when making decisions. Without it decisions are made using only a partial available picture and the less correct information available the less likely that a good decision can be made.

Perhaps the greatest project management issue affecting the Titanic, however, was its lack of standard operating procedures. The SOP should have been produced as an essential project deliverable during the later stages of the construction process. For a ship to have been deemed seaworthy when there was no SOP to operate her is truly inconceivable. Even the most agile of development methodologies fails to overlook the need for end-user documentation.

Since the design and construction portions of the project had failed to provide the crew of the Titanic with an SOP or, at least, a reasonable SOP (there were some generic standard procedures in the White Star Lines manual itself) there were no clearly defined rules or processes for dealing with communications, tracking alerts, providing warnings, etc. There was no emergency procedure to be followed and so the crew was forced to act on nothing other than experience and general mariner knowledge.

It is at this point, when examining the actions of the crew under emergency conditions, that we witness the complete breakdown of the command structure. In a traditional business the business executives are generally accepted as having the final decision-making power on any corporate action as long as it falls within legal boundaries, and often when it does not. In the average business a bad operational decision results in loss of revenue not the loss of life. A wise executive will understand the need to not override the decisions of those specialists hired to make operations decisions or possibly a board will require that an executive listen to her staff. Nonetheless, the idea of business side executives interfering with project operations is against best practices and is widely accepted as being a bad course of action.

In the case of the Titanic, Captain Smith was in command of the vessel at sea and was personally responsible for the ship and the souls aboard. His boss, J.B. Ismay, may have had the ability to have Smith removed from command upon returning to port but at sea he did not nor under British mariner law did he have the right to make commands from the bridge as he was not a licensed mariner. (Kuntz)

During the time leading up to the iceberg collision J. B. Ismay had been pressuring Captain Smith to drive the ship at an irresponsible speed – in excess of twenty-four knots or seventy-five revolutions. The Olympic, being considered the “test” for the Titanic, had never crossed the Atlantic at this speed and the Titanic was now operating even outside of the range of tests performed on the Olympic without even time enough to have performed a single Atlantic crossing under normal conditions. Ismay and Smith drove the Titanic beyond its known performance parameters and, more importantly, beyond the crew’s known operational parameters. It was simply unknown what operational risks would be involved with the ship at this speed. To maintain what should have been considered an unsafe speed while also going into waters known to be strewn with icebergs was extremely foolish.

Whether because of panic, confusion, insecurity, etc. we do not know but when the Titanic struck the iceberg Captain Smith allowed a layman, J.B. Ismay, to come onto the bridge and to begin making executive orders as the acting ship’s master for which Captain Smith had the right and obligation to have Ismay removed. Ismay made key operational decisions including emergency communications, passenger notification and, most importantly, to move the Titanic forward off of the ice shelf which is believed to be the actual cause of the ship’s main rupture and then to continue the ship moving forward at slow speed pulling the hull apart even after additional information was available that the ship was going to sink. (Kozak-Holland)

Given the distance in time that we are now from the Titanic it can be difficult to assess processes followed and to know what went right with the project when we know so much that went wrong. The sinking of the Titanic is so iconic in our minds that to see it as anything but a marketing and organizational disaster is difficult at best.

In the end the Titanic project was immense but well managed. Scope was controlled and changes accommodated when necessary. Large design up front with a well established contractual interface to the construction phase was used and this cementation of the specifications allowed for careful and accurate scheduling. The processes by which the ships were built were standard and well known. Using historical construction data Harland-Wolff was able to accurately predict the time needed for construction allowing White Star Lines to begin marketing and sales long in advance of the actual sailing of the ships. The Titanic, being an almost identical copy of the Olympic, had even fewer surprises. The only true surprise resulted from the change of priorities from White Star Lines that resulted in the Titanic project being put on hold for approximately one month.

In the words of J. Bruce Ismay “She [Titanic] was not built by contract. She was simply built on a commission.” This indicates that exceptional authority was granted to Harland-Wolff to use their own processes and oversight to ensure the delivery of the Titanic. The two companies operated more as partners than in a vendor-customer relationship. (Kuntz)

Project risk for the Titanic was handled poorly relying heavily upon external insurers and, in the end, the British government to protect the company from liability lawsuits at the expense of the primarily British and American passengers. Risk was considered to be very low and because of this many careless decisions were made first with the Olympic and then, when operational disasters were minimal, even moreso with the Titanic. Careful risk assessment was not made. Expert mariners could easily and quickly have defined many risk areas that needed to be addressed. Issues such as the lack of a complete Standard Operating Procedure would have been flagged and could have easily been handled since resources for this would not have needed to have come from the current Titanic team and would not have impacted the delivery date or any of the variables that we understand now to have been of primary concern to White Star Lines.

Communication on the project seems to have been handled very well until service delivery began. At this point design flaws, questionable decisions and the lack of SOP came to bear on the communication network on board the ship. This communication could be considered to be operational and not project based but the argument is semantic. The issues with the Titanic were holistic and with proper design methodologies being followed risk analysis would not have been missed which would have forced the creation of the SOP which would have highlighted or perchance even fixed the communications issues.

At its core the question was one of quality. The Titanic was proposed and sold as the highest quality transatlantic travel option. Quality was heralded, directly or indirectly, in almost every breath spoken about the Titanic. The customer interface was kept as clean and concise as possible. No expense was spared if the results would be witnessed by a customer. But the underlying core or infrastructure of the project (non-functional requirements according to Kozak-Holland – although I do not agree with their use in this context) on which this “quality” was to rest was ignored and the true quality of the Titanic and the quality of the operations of White Star Lines was to become ultimately evident.

Bibliography and Sources Cited:

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” the Online Community for IT Project Managers. (2003): 22 February 2008

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry. (2005): 23 February 2008

Sadur, James E. Home page. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 23 February 2008.

ThinkQuest Library. “Designing the Titanic.” (Date Unknown): 25 February 2008.

Titanic-Titanic. “Olympic.” (Date Unknown): 25 February 2008.

Titanic-Titanic. “Guarantee Group.” (Date Unknown): 25 February 2008.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 25 February 2008.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 25 February 2008.

Additional Notes:

Mark Kozak-Holland republished his 2003 Gantthead articles on the Titanic into a book:

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

More Reading:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.

First published on SheepGuardingLlama.