IT專案啟示錄——來自泰坦尼克號的教訓（第七篇）（轉）

4月14日晚間，位於泰坦尼克號以北方位的加利福尼亞號正駛向波士頓。在遭到浮動冰架的一次幾乎致命的撞擊後，（加利福尼亞號的）史丹利-諾德船長決定不再前進，拋錨過夜。該船周圍雖滿是浮冰，但所幸並無什麼危險，遵船長之命話務員伊文斯向泰坦尼克號上的同行---那位每天都得工作14小時、不停收發商務通訊訊息的話務員---發出了浮冰警報。而泰坦尼克號則報以那句著名的回覆，“住口，閉嘴！我很忙。我正與瑞斯角通訊而你干擾了我。”

由於安排給話務員的訊息量過於超量，這最後的外來警報並沒能被適當地上傳給艦橋指揮部。工作章程中把相關訊息傳回艦橋指揮部的程式，在此時已被最大程度地歪曲。加利福尼亞號的話務員伊文斯也沒再繼續嘗試下去，關掉無線電後他就睡覺去了。

IT專案於此節上所能吸取的教訓在於，任何外來警訊，不管來自客戶還是供應商，都需嚴肅對待，予以徹底調查。從海量的噪音，冗餘的資訊中辨識和發掘出真正有意義的那部分，其重要性無出其右。在泰坦尼克號上，倘若有誰能把與冰雪有關的所有警訊都組合在一起研究一下，不難發現所有這一切都指明同一個事實：在本船正前方有一個寬度竟達80英里之大的巨型冰原。令人吃驚的是，當時確實沒有做對周圍航行環境的任何宏觀評估。

（事實上）任何有經驗的水手都應注意到當時那些預示著有巨大冰原存在的種種海況。（比如，）海面顯得很平靜，那正是由於大浮冰和積冰塊平抑了水浪；而且，海水看起來象油狀，也正是因為其已接近凝冰點。從船上往外的總體視距被認為好於正常水平，正是這一點使得船員們高度相信各種危險都能被發現。但是，雖說星空燦然、水波不興，地平線處卻已出現薄霧，它與天相接時將使得地平線再也難以分辨。

泰坦尼克號在其守望塔樓(the crow’s nest)和艦橋指揮部兩處都裝備有目視監視器。在守望塔樓的兩個目視監視點之上，艦橋指揮部的賴特霍勒船長還有一個自己專用的監視點。船上配備了6名專業目視監視員，下一班應在0:00開始輪值。(其實，此時)往往都應該在船首部部署特別監視哨，並安裝一條專線電話直接通到艦橋指揮部上。問題在於，為什麼在諸多警訊跡象之下，仍然沒有安排特別的目視監視員來當值。這一點再次說明指揮人員們的過分樂觀和自信。

此節上IT專案所能吸取的教訓是，在商業週期中，隨情況之變會出現所謂關鍵時段，比如在月末的種種操作，往往需要特別的安排和處理，此時任何不尋常的狀況都不得掉以輕心。

況且，泰坦尼克號的觀察哨發現雙筒望遠鏡找不著了，這太不尋常了。按慣例，在守望塔樓應至少常備一付。其實，觀察哨兵們已經不止一次地彙報了這一異常：哨兵們自從離開南安普敦就一路抱怨，這些本來列入在工作合同中將幫助他們更好完成其義務的工具，卻不見蹤影。哨兵們得到的解釋是，這些雙筒望遠鏡被分配給指揮官們用了，也或是有人偷了、但鑑於船大人多，沒法追查回來。

在此IT專案應吸取的教訓是，對那些處於關鍵位置的某些員工，如一線執行操作人員，應儘可能把最好的工作裝置配備給他們，而不是配給組織結構和階層中的任何其他人。

在估計與海上浮冰相距多遠時，水溫是非常精確的指標。通常，當船進入冰原時，應從船體的一側用帆布桶取海水，然後放入溫度計進行測量。按照此法每兩小時測一次，一系列的測試之後將能很精確地揭示出大冰川與船體的距離。然而，一個旅客（事後指出）當時曾看到一個船員往測量桶裡灌的是船上自來水管裡的水，原因是桶上的提繩不夠長，放不到海里。

而今IT專案應吸取的教訓是，當反饋機制不斷返回著相互矛盾、相互不能關聯的資料時，必須詳查反饋機制本身。然而現實中，泰坦尼克號反饋機制不僅本身就不完善，而且即便是透過該機制彙報上來的問題，其相關資料也是偽造來敷衍了事的。這同時又強調了在專案正式實施前，檢查測試所有反饋機制和操作步驟的重要性。

儘管有前述的種種警訊，也沒人採取任何措施減慢航速。從事後的角度看，船長和指揮官們應針對報上來的種種異常情況做更多的澄清工作，更直接深入地調查，集思廣智。然而，沒人料想得到在這一航程上如此快地就將直面冰山，因為冰山通常並不會飄遊到象泰坦尼克號的航線那麼南的海域。指揮員們當時一定認為在那樣“極好”的能見度下一切都能被及時發現。

如今許多IT專案在專案執行上打折扣，是源於不夠嚴肅認真、或屈從商務壓力，而過快地讓初步方案最終產品化。當初泰坦尼克號的船主們就被讓船儘快投入商業營業的經濟壓力所驅使。

結果，泰坦尼克號的（專案）測試，換變成了（直接）滿載乘客橫跨大西洋的處女航。考慮到已經投入和在泰坦尼克號建造中積壓的大量資本，這一點是可以理解的，然而是否是可以接受的呢？商業機會對奧林匹亞號是同樣存在的，而白星號的總體目標就是每週在大西洋上對開兩班豪華航線。況且，奧林匹亞號已兩次意外停運了近8個星期，所以Ismay急於讓泰坦尼克號儘快投入正式營運。而代價呢？Ismay為泰坦尼克號寫下了一個新的“服務水準目標”（Service Level Objectives），下一部分將證明它是對泰坦尼克號是命運攸關的東西。

下一部分將著眼於IT專案的執行階段。

原文：

On the night of April 14, the ship California was north of Titanic, bound for Boston. After a near-fatal collision with an ice shelf, Captain Stanley Lord decided against proceeding forward and pulled up for the night. Surrounded by pack ice but in no danger, radio operator Evans, under orders from the captain, sent an ice warning to Titanic’s radio operators, who had been working a 14-hour day sending/receiving commercial traffic. Titanic responded with the infamous, “Shut up, shut up, I am busy. I am working Cape Race and you are jamming me.”

This last warning was not passed back to the bridge because of the message overload. The procedure for passing messages back to the bridge was confusing at best. Evans did not try again, turned off his wireless and went to bed.

The lesson from this for IT projects today is that any external warnings, from customer or supplier, need to be taken seriously, and thoroughly investigated. Finding the meaningful information in a sea of “noise,” or redundant information, is invaluable. With Titanic, if someone had pieced together all the ice-warning information, it would have indicated a giant ice field, around 80 miles wide, directly ahead. Effectively, there was no macro view of the environment.

Any experienced mariner would recognize sea conditions indicative of ice fields. The sea is calmer, as the ice floes and pack ice dampen water movement. The seawater also takes on an oily appearance as it approaches freezing point. The overall visible distance that objects could be seen from the ship was thought to be beyond the norm. This gave the crew a high level of confidence, in being able to spot all hazards. However, although stars brightly illuminated the sky, and the sea was incredibly calm, there was a haze on the horizon created by the cold weather. This made it difficult to outline the horizon as it merged with the sky.

Titanic had some built-in visual monitoring through the crow’s nest and the bridge. Beyond the two lookouts in the crow’s nest, officer Lightholler maintained a lookout himself from the bridge. Titanic carried six specialist lookouts, and the next shift change was due to start at 00:00. A question remains why no extra lookouts were on duty, considering all the warning signs. It was typical to post extra lookouts on the bow of the ship, to which a telephone link ran from the bridge. This is another example of the overconfidence of the officers.

The lesson for today’s IT projects is that there are critical periods in the business cycle were conditions change, like month end processing, and this requires extra diligence. Unusually quite conditions should not be taken lightly.

In addition, the lookouts were missing binoculars, which was very unusual. It was customary to always have at least one pair in the crow’s nest. The lookouts had repeatedly reported this, since leaving Southampton, resentful at not having these since they were the tools of the trade required to make them effective. Explanations include they were assigned to officers on the bridge, or that someone stowed them away and was unable to find them with the size of the ship.

The lesson for today’s IT projects is that certain staff in critical positions, like operations, should have the best equipment available, in preference to others in the hierarchy.

The temperature of water is a very accurate guide to the proximity of ice in the water. Normally, when entering ice fields, tests were taken by drawing seawater from over the side of the ship with a canvas bucket, and then placing a thermometer in the bucket. Repeated every two hours, these tests were an accurate indicator of the proximity of large ice floes. However, one of the passengers noticed a sailor filling the bucket with tap water because the rope was not long enough to reach the sea.

The lesson for today’s IT projects is to investigate feedback mechanisms that are reporting contrary data in isolation to other data collected. In Titanic’s story, the mechanism was faulty but rather than report the problem the data was falsified to cover it up. It also emphasizes the importance of testing all feedback mechanisms and operational procedures before implementation.

No attempt was made to slow the ship down, despite all the aforementioned warnings. In hindsight, the captain and officers should have done more to clarify the scope of anomalies brought to their attention, investigate them more closely, and piece together all the intelligence. However, no one expected icebergs to be directly in the path of the ship so soon in the voyage, as icebergs did not usually drift down as far south as Titanic’s course. The officers must have perceived that anything would be seen well in time with such “excellent” visibility.

Conclusions
Today, many IT projects severely compromise implementation by not taking it seriously enough and bowing to business pressures to get the solution into production quickly. Titanic’s owners were very much driven by the pressing economic need to move Titanic into service.

In reality, Titanic’s testing consisted of the maiden voyage across the Atlantic fully loaded with passengers. This is understandable, considering the huge amounts of capital that had been invested and sat tied up during construction. But was it acceptable? The business opportunity was there for another ship (Olympic) and White Star’s overall objective was to have two luxury liners crossing paths on the Atlantic on a scheduled weekly basis. In addition, Olympic had been twice unexpectedly out of service for about eight weeks, so Ismay was anxious to see Titanic move into service as quickly as possible. But at what cost? Ismay wrote out a new SLO for Titanic that proved to be crucial in the next part of the story.

The next installment will look at the operation stage of the IT project.[@more@]