Considering NetBooks for Small Business

There really is not any question about whether or not NetBooks will be an important tool for businesses of all sizes – they will be.  The upsides to NetBooks are too big to overlook: highly portable, generally more rugged that laptop counterparts due to size, light weight, easier to store and transport and mostly quite inexpensive compared to traditional laptops.  There are exceptions to any rule but the prototypical NetBook is dramatically smaller than a traditional laptop, weighs only one to two pounds (under a kilogram) and often costs no more than seventy percent as much as a laptop (any price comparison is massively subjective for obvious reasons.)

The question is not whether or not NetBooks are a good idea, but whether or not the NetBook market is ready for the enterprise (or, in our case, the SMB.)  While the idea of NetBooks has been around for quite some time that realization of the market has only begun to take effect within the past two years.  The NetBook was originally developed by Psion in 2000 but they exited the market in 2003.  The next big player was the United Nations with the OLPC (One Laptop Per Child) which was an extremely low cost, ruggedized, Linux-based NetBook available for just $199USD.  With the development of the OLPC and the ecosystem of suppliers and developers that it fostered the low-cost, portable Internet device market was set to explode.

The big news for normal consumers came in 2007 when Asus, a major Taiwanese manufacturer famous for their high-quality motherboards, released their EEE PC line of NetBooks and, later, NetTops.  The EEE PC proved to be a major hit with consumers because of its low price tag, attractice looks and size.  Once the market was identified many manufactures jumped in with top-tier manufacturers like Acer, Lenovo, Dell and HP finally in the market now as well albeit generally from their consumer divisions and not from their commercial divisions.

Today we are in a rapidly maturing consumer NetBook market.  This means that NetBooks are well established, widely available and stable but, thus far, only in configurations designed for consumer use.  This presents our first barrier when considering these devices for the workplace.

With only rare exception, NetBooks ship with either consumer versions of Microsoft Windows (i.e. XP Home, Vista Home) or with non-enterprise versions of Linux (i.e. Linpus, Mandriva.)  To be sure, there are a few machines that ship with appropriately enterprise class operating systems like Vista Business or SUSE Linux but mostly the operating system that you find on the NetBooks are not the same as you would require in your business.  (Many niche NetBook manufactures do ship with Ubuntu or Fedora which are acceptable to many businesses but these are rare as well.)

In some cases, such as the very popular Acer Aspire One, it is quite easy for an IT department to establish their own operating system image and to apply it to the NetBook.  This is hardly a cost effective approach for a small shop to take, however.  This is only an effective approach under very specific circumstances or for very large orgazations who will be rolling out a large number of identically imaged machines and can spread the cost out over the group.

In the case of the Acer Aspire One we have a very well built unit that runs either Linpus Linux (a derivative of Fedora 8) or Windows XP Home.  Windows Home editions are not able to be integrated into business environments so we can rule out that option completely.  The cost of obtaining an additional XP Pro license would be very prohibitive on hardware that is so inexpensive.

The Linpus model is significantly less expensive than the Windows XP Home model and can be outfitted with a custom build of Fedora 10 replacing the including system at no additional external expense.  This does require a rather knowledgable Linux engineer to do and takes many hours to perfect and test.  Most likely a few days of labor at a minimum.  Only large shops with good internal Linux expertise or smaller shops with IT outsourcing partners with the necessary expertise should attempt to go down this path as it leaves you completely without any form of vendor support.  It also requires your IT department to monitor and support an additional operating system image unless you have already standardized on Fedora – which is not very common.  There are other options, such as installing OpenSUSE or an Ubuntu variant but these require additional work as Fedora is used to create the Linpus base and installs so easily onto the device.

Using Linux-based NetBooks often presents another problem.  On a normal corporate desktop running Linux it is most common to find either KDE or Gnome running as the desktop.  These are the two most popular, full featured desktop environments for the UNIX platforms and, to most users, it is the choice of KDE or Gnome that establishes the familiarity with the environment and not the underlying operating system.  Because of this, users who have used KDE on SUSE Linux can often be switched to KDE on PC-BSD without the user even realizing that the operating system has changed (Linux to FreeBSD.)  But NetBooks are often underpowered when it comes to running these heavy desktops and so alternatives are generally recommended.  Most commonly today we see XFCE chosen as a lightweight desktop environment alternative but even lighter options exist such as IceWM.  These environments can make NetBooks very usable instead of being slow and cumbersome but they do cause users to face potentially unfamiliar interfaces that can lead to additional support needs and possibly even training.

Having NetBooks available for a certain class of highly mobile or continuously on-call personnel can make a lot of sense.  The advantages are very real and, while some users are put off by the small screens and keyboards and dislike the lack of high-performance hardware, many users adore the portability and easy of use of these small devices.  If having a NetBook makes the difference between staff being able to work or having to disconnect from the office then the NetBooks will easily pay for themselves.

For most businesses I feel that we are still in a phase of early-adoption when it comes to NetBooks.  The hardware itself is well tested and widely available but the software is mostly not ready at this time.  In the next two years I expect that we will see a lot of advances in the market, especially as AMD and NVidia are expected to begin entering the market in force during this time allow with other potential players who currently have had very little input to the market such as Freescale.

Currently, and for the near future, businesses looking to NetBooks need to almost across the board make a commitment to using Linux rather than Windows.  The Windows operating system is just not ready to handle the NetBook market and will likely wait until NetBooks catch up to modern laptops in performance before really looking to enter the enterprise NetBook market.  During the mean time, however, alternative architectures, such as PowerPC, ARM and MIPS, are being experimented with within the market and their adoption poses a technological barrier to running Windows on these devices.  Microsoft may find that the NetBook could be a critical loss of market for them as Linux vendors like Novell, Red Hat and Canonical will see it as an inroad into the enterprise desktop space.  It is not coincidence that Red Hat has just announced its official return to competiting in this market.

At this particular time I feel that it is good to begin investigating NetBooks and seeing how they may or may not fit into your business IT strategy.  Most small businesses will find, like their large enterprise cousins, that the NetBook is inexpensive to obtain but expensive to support in a corporate environment.  This will be changing rapidly as the NetBook format becomes more common and business begin to clamour more and more to get these provided, in business-ready configurations, from the top vendors.

Free Web Reporting with Google Analytics

As a small business it can often be a challenge to obtain deep insight into the workings of your information technology organization.  When it comes to web sites there have always been a number of decent, free tools that would do the job adequately, such as Webalizer.  But these tools require some level of additional setup and expertise which means either more time being spent on your own attempting to learn and manage another IT skill or paying your IT staff to do so.  Today we have another option.

Google offers a great, free product available online called Google Analytics.  Analytics is a complete website tracking package that sends all of its data to the Google Analytics website where you can view your statistics online or have a report emailed to yourself automatically at set intervals.  Google handles all of the code, storage and reporting involved in keeping tabs on your company’s websites making your job very easy and allowing you to focus on your business rather than your technology needs.

The system works very simply.  After signing up with Google as an Analytics user you go through a very simple process of adding a web site to be monitored to your account and then Google generates a small snippet of JavaScript code which you then need to copy and paste into the code of your website.  This works for multi-page sites and with most content management systems such as WordPress – although for a CMS you will need to check your CMS documentation to know exactly where to place the code.

Obviously it will take a little while for Analytics to begin collecting the data that it needs in order to generate reports for you.  After a day or so you should begin to see the reports in action, although it takes a month or more before the data that is collected will really begin being valuable to you.  Some of the most important data obtained from a web site is changes in your readership over time to alert you to when you are doing things right or doing them wrong for your market.

Google Analytics collects and collates a lot of useful information for you.  You can see breakdowns of which pages are drawing readers and which are turning them away.  You can see what search terms readers are using to find your site.  Analytics also provides a very nice map report that allows you to see your readership from around the world.

Using Google Analytics you can find out more about the users that your site is attracting and you can learn how they are using your site.  By obtaining this data you can learn how you can better reach you intended customer base or learn more about your existing customers.  It can also teach you what information on your site users are able to find and what process they are using to reach that information.  A tool like Google Analytics or Webalizer is a critical first step in making your web sites work for you.

Visit Google Analytics’s Features Page to learn more about the features available from this product.

Using GMail to Backup Your Email

When disaster strikes it is a good time to reflect on what preventative measures might have saved the day.  Working in IT, as I do, mitigating and even preventing disaster is a big part of the job.  No matter how hard we try disaster can still strike and being prepared for it is very important.

Email is one of those systems that almost no business can function without in this day and age.  Getting to lost email messages quickly is almost as important as getting email flowing again.

Recently, I had to deal with a pretty significant email disaster.  A lot of email was lost.  Getting email back up and running wasn’t too hard but a lot of email had been lost.  In a post-mortem we looked into many potential solutions to the ongoing issue of email backups which are often tricky and difficult to do properly.

One of the best suggestions made in our post-mortem engineering sessions was to have email backed-up, on the fly, message by message via forwarding to Google’s GMail service.

Now, before we get too far, I need to state that this is not a comprehensive backup solution.  Using email forwarding to GMail (or any other email service) must be handled account by account which causes it to scale very poorly.  It would be an administrative nightmare for a shop of any size but is quite easy for a very small organization of up to possibly twenty or thirty people.  It also does not handle outgoing (sent) email in any way but only incoming email – which is almost always where the important messages are located.  A traditional backup of your email system is still necessary.  This is really a complimentary service not a replacement solution.

What is great about forwarding to GMail is that it is free, it is extremely convenient, it can be handled by the email users who want it and ignored by those who do not,  it is almost instantaneous and the backups will continue even when an email client is not connected – unlike an IMAP or POP client based backup strategy.  Google provides so much storage capacity that likely you can send years of email messages to GMail without ever needing to clean out your archived messages.

Email forwarding can be set up by individual users or by an email administrator although if individual users do not manage their own GMail accounts this can be problematic.  There is also the potential option to have several company email account forward to a single GMail account although comingling email will result is all kinds of potential headaches later and be sure to be very confident about your legal ground for combining email in this manner.

Smaller organizations need to carefully consider how to take best advantage of the email options that they have available to them.  Email forwarding is one way in which very small organizations can take advantage of their size.  Large organizations would be forced to use more complex and expensive backup strategies to achieve these same results.

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 Salesforce.com 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.” Gantthead.com 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.

The Information Technology Resource for Small Business