“Titanic Lessons for IT Projects” - FVP PMP Luncheons - Noblis

“Lessons From the Past 

that Assist the Projects 

of Today to Shape the 

World of Tomorrow” 

www.lessons-from-history.com 

“Titanic Lessons for IT Projects” 

IT Projects from Hell 

Authored by Mark Kozak-Holland, HP Services 

March 14th, 2007 

Presentation for Noblis 

Lessons-from-History 

Strictly Proprietary & Confidential 

Copyright 2007 MultiMedia Publications

Objectives: Analyze Titanic’s construction project and voyage 

and provide a contrary view to popular held belief 

• It explains how we can take stock and use lessons learned 

to help understand key project issues. 

• It looks at key decisions made during the project that led to 

compromises and cutting corners in the project stages. 

• It questions why the ship’s captain was unable to prevent 

the disaster. 

• It makes a step by step comparison to today’s IT projects. 

• Please prepare questions for the end of the presentation. 

Titanic Lessons for IT Projects 


Copyright 2007 

Page 2

As you probably know the success rate of IT projects is stubbornly 

low as first shown by the “Chaos” reports from Standish Group 

• Hypothesis: 

– IT projects set seeds 

for future operational 

failures - take months 

to come to light. 

– Problems in on-line 

operation attributed 

back to poor 

decisions made in IT 

project. 

Source: “Chaos, a recipe 

for success,” Standish 

Group, 2004. Part of a 

series 1994, 1996, 1998, 

2000, 2004 - 280,000 

projects evaluated 

Check www.lessons-from-history/Project Success or Failure/ 




Page 3

Some notable project failures during the project implementation or 

into operation 

• January 2007, Sweden's largest Bank, Nordea, the biggest heist of customer accounts on record 

more than $1m was stolen. 

• The Hershey Foods ERP system implementation failure ($112m) led to massive distribution 

problems and 27% market share loss. 

• The FoxMeyer Drug ERP system implementation failure led to collapse of entire $5 bn company. 

• July 2005 HSBC admitted hardware failure caused a major systems crash that hit thousands of 

customers for ATM, credit/debit, online services and internet, and it was the worst in its history. 

• June 2004, RBC fell behind processing salary deposits thousands of Canadian workers as 

millions of transactions were affected by a computer glitch that caused payroll delays. 

• June 2004, an air traffic control computer failure saw massive air disruption across the UK. All 

flights from UK airports were grounded after a problem at the National Air Traffic Service. 

• August 2004, a computer crash prevented thousands of UK pensioners collecting benefits 

payments on the busiest day of year after the £500m Benefits Transfer system went down. 

• September 2004, hundreds of flights grounded for 3 hrs, Western US airports. A computer failure 

stopped pilot/traffic controller contact. In 5 instances planes passed very close to each other. 

• October 2004, computer failure at Waikato Hospital (NZ) left thousands of health workers out of 

pocket and forced the manual processing of patient records. 





Page 4

Notable project failures during projects. Considering evolution of 

PM in last 3 decades and increasing maturity of IT why do problems 

still occur and some IT projects fail catastrophically? 

• 2006 Department of Homeland Security scuttles its $229m Emerge2 program (new 

financial IT system). 

• 2005 US Justice Department stated $170m FBI Virtual Case File project a failure, after 5 

yrs & $104m. In a 18-month period, FBI gave contractor 400 requirements changes. 

• 2005 UK Inland Revenue gave $3.45 bn of tax overpayments because of software errors. 

• April 2005 Australian inter-departmental warfare resulted in failure of $64m federal project. 

• 2005 British food retailer J Sainsbury wrote off $526m in automated supply-chain system. 

• IRS project on taxpayer compliance took decade to complete and cost $50 bn. 

• Oregon DMV conversion to new software took 8 years and public outcry killed the project. 

• State of Florida welfare system plagued with numerous errors & $260m in overpayments! 

• May 2005 major hybrid car manufacturer installed software fix on 20,000 vehicles. The 

automobile industry spends $2 to $3 bn per year fixing software problems. 

• July 2004 new welfare management system in Canada costing $200m unable to handle 

simple benefits rate increase. Contract never tested this in 6 weeks of acceptance tests. 

• 2004 Avis cancelled an ERP system after $54.5m is spent 





Page 5

The costs of lost services are significant regardless of 

industry & relate back to decisions made in the project 

Outage Costs By Industry 

Industry Description By Minute By Hour 

Package shipping Like Fedex $467 $28,000 

Internet e-tailer (small) Like CDNow $750 $45,000 

Computer vendor Like Dell $1,000 $60,000 

Financial Institution Like Citibank (credit/debit) $1,300 $78,000 

Retailer sales catalog Like Sears $1,500 $90,000 

Internet e-tailer (large) Like Amazon $1,500 $90,000 

Financial institution Like Charles-Schwab (brokerage) $1,500 $90,000 

TV home shopping Like The Shopping Channel $1,550 $93,000 

Telco Like ATT $2,000 $120,000 

Pay-per-view Cable provider, like Rogers $2,500 $150,000 

Network vendor Like Cisco $2,783 $167,000 

Microchip manufacturer Like Intel $3,750 $225,000 

Airline Like Sabre $36,000 $2,160,000 




Page 6

As complexity has risen so has the risk. The internet brings 

further risks as it exasperates dependencies on on-line services 

• Integration of solution into a complex environment of 

applications and databases. 

• Interface to the Internet: 

– Puts backend operation on-line, exposes integration flaws to world. 

• An online mortgage can be approved in 20 minutes, from days or weeks. 

– Carries high expectations of 24x7 service delivery and on-line access. 

– Enables fickle, savvy customers to click over to competitive services. 

– Leave site in 4 seconds if no response 

– Increases speed that on-line services acquire mission critical status. 

– Expands B2B services to global 24x7, e.g., suppliers, resellers, 

partners. 

• Millions of lines of code 

• Integration with complex technologies 

• Massive user populations (to justify solution) 




Page 7

Not only do projects need to be successful but have to 

come in on time, e.g., like hot products 

• Xbox get it right - launch window has to be “bang on” 

• Some product lifecycles last no longer than 4-6 months and 

sometimes, 1 month 

• HP reduces laptop development cycle from 9 months to 4 

weeks to respond to changing technologies and product 

obsolescence. 




Page 8

Bad IT service performance, IT project success rates, & IT investments 

are not just a CIO problem but for the whole c-level c 

executive 

• Corporate benchmarking study identified serious deficiencies 

in senior executive management skills with IT projects. Lack 

of PM skills cut benefits of IT projects by 25%. 

• “Project governance practices today focus on making 

commitments, not keeping them. Executives are involved in 

selecting and approving projects, but rarely delivering them.” 

49% experienced one project failure in past 12 months. 

• Source: KPMG's Global IT Project Management Survey, July 2005. 

• The CIO and entire c-level executive need to understand: 

– The relationship between IT projects & on-line operations 

– What can go wrong in a complex on-line operation? the cost and impact? 

– How it can be prevented? 

– ROI for creating a strong online operation 




Page 9

To better understand the relationship between on-line operations 

and IT projects imagine yourself back in 1912 in one of Titanic’s 

lifeboat being rescued by Carpathia. . You ask yourself: 

• How could such a disaster happen? 

• Why did the ship collide with ice? 

• Why did the ship sink it was supposed to invincible? 

• Why didn’t the ship slowdown through the ice field? 

• Was the ship carrying lookouts? 

• Who was in control of the ship? 

• Why were there so few lifeboat places? 

• Were there no other ships in the vicinity? 

• Why did it take so long for rescue? 

• Are these just the symptoms and not the causes? 

• We need to go back to 1909 and look at the project itself. 




Page 10

In 1909 White Star was facing stiff businesses pressures no 

different to corporations today. Executives responded with a new 

business strategy and took advantage of emerging technology 

• Increase in competition and new entrants. 

• Aging technology infrastructure, ailing and inferior business 

services, leading to loss of market share and customers. 

• Invested in a technology infrastructure with 3 new super 

liners to sweep Atlantic. 

• Pushed emerging technology to limits. 

• Addressed all three passage classes, priority on first-class. 

• Improved services by quality of 

crossing and customer experience. 

• Ships built for space and comfort 

(capacity) and not speed. 

Mauretania 

Olympic 




15% faster 

23% greater capacity 

Page 11

The strategy required major new technology investments but the 

business case was really solid. The business requirements 

specified a lavish ship with space that addressed 3 classes. 

• Project “profitability analysis” showed a breakeven in 2 years. 

• The construction project would take 6 years. 

• A staggering 75% of revenue driven by first-class passengers. 

• The price of: 

– 1 st class suite - $4,350, 2 nd class suite - $1,750, 3 rd class ticket - $30. 

• Titanic’s class segregation no different to how today’s 

organizations cater to customer segments. 

• By other ship standards third equivalent to second, and 

second to first. 

• Space allocated: 

– 60% for 905 first-class passengers. 

– 7% for 1134 third-class passengers. 




Page 12

In comparison for an IT project today the project team can 

minimize risks with the following techniques: 

• Ensure due diligence in examining the business 

problem, articulating competitive services, defining 

potential costs, and assessing risk. 

• Determine by segments customer/target audience, value 

propositions, create profiles and scenarios for these. 

• Determine existing services to be integrated into the online 

operation, or data dependencies. 

• Establish desirable service level targets to guide the 

architect. 

• Carefully assess solutions driven by new emerging 

technology. 

B EST 

PRACTICES 




Page 13

And build a business case for the IT project that looks into the 

operational side and incorporates potential risks: 

• Determines the cost of unavailability, based on affected users. 

• Identifies and calculates hidden availability costs, especially 

people costs. 

• Considers branding, image and prestige. 

• Highlights the exposure and risk, (potential for “bankruptcy”). 

• Ensure investments required to move on-line out-weigh costs 

B EST 

PRACTICES 

Revenue generating on-line operation 

Cost saving on-line operation 




Page 14

You can compute your exposure to lost customers/profits by 

surveying your customers on the items below 

B EST 

PRACTICES 

# of customers 

who experience 

a problem 

Source: TARP Study 

X 

Sought 

Assistance 

50% X 

Did not seek 

assistance 

50% 

% 

Completely 

satisfied 

% 

Mollified 

% 

Dissatisfied 

% Will NOT 

Continue 

As Customer 

X 

X 

X 

X 

5% 

25% 

70% 

45% 

= 

= 

= 

= 

# Will NOT 

Continue 

As Customer 

$ Profit Lost 

due to lost 

customers 

X $ =.............. 

X $ =.............. 

X $ =.............. 

X $ =.............. 




Page 15

In Titanic’s s architecture stage like in any IT project Architects 

faced many investment options 

Thomas 

Andrews 

• They created a luxury liner with priority to 

first-class service and accommodation 

priority on functional requirements (What). 

• Harland and Wolff were the most 

expensive craftsmen in Europe 

• Lavish attention and investments to 

passenger comfort implied an equivalency 

in safety and operations features or non 

functional requirements (How). 

• The designers had investment choices in 

safety features, from lifeboats to the new 

technologies like bulkheads, a double-skin 

hull, and electric doors. 




Page 16

White Star invested in a ship-builder 

builder’s s model the modern 

equivalent of an IT pilot. They used it to analyze all exposures to 

the possibility of loss. 

• White Star used early modeling 

techniques to test the designs 

and identify vulnerabilities. 

• Shipbuilders relied heavily on 

flow analysis or “static testing” to 

review ship characteristics. 

• This was a sound strategy 

considering the limited testing 

options available, and it identified 

problems prior to construction. 

• Risks of crossing Atlantic well 

known with 400 years of travel. 




Page 17

The Architects were well aware of the risks in crossing the 

Atlantic. The model tested worst case failure scenarios. 

• Running aground 

60 feet 

Waterline 

Tank top 

7 feet Hull bottom 

Double skin bottom 

• Collisions 

60 feet 

Front-end 

collision 

Side-on 

collision 

Crumple zone 




Page 18

In the architecture stage the project team can minimize risks with 

the following techniques 

B EST 

PRACTICES 

• Walkthrough the design, to catch problems early. 

• Walk along critical transaction paths end-to-end. 

• Complete “component impact analysis” and Architect to remove 

single failure points. 

• Build security zones for access. 

• Avoid under-investing in non-functional requirements. 

• Avoid one technology, lack of diversity increases susceptibility. 

• Avoid complexity, strive for simplicity, design for manageability, 

operability, scalability, performance, security, and ease of use. 

Check www.lessons-from-history/functional vs non-functional.html/ 




Page 19

Titanic’s construction stage integrated many complex technologies 

and selected safety features to reduce risks 

• Many disparate technologies integrated and 

controlled from a single point, the bridge. 

• In selecting the “availability level” and “safety 

features” assumptions were made about nonfunctional 

requirements. This led to over 

confidence in ship safety as construction 

progressed. 

• Investment dollars were put into expensive 

safety features based on new technologies in 

preference to lifeboats. 

• A perception developed that Titanic was 

unsinkable. 




Page 20

Decisions were made that compromised individual safety 

features and escalated the level of risk 

• No Titanic construction dollars were 

diverted from basic safety requirements to 

enhance the luxurious first-class. 

• BUT esthetic factors like spacious public 

areas compromised the bulkhead wall 

height, built 10 feet above the waterline. 

• The double skin not continued (narrowed 

interior) was only 7 feet deep and below 

the waterline. 

• 16 lifeboats were fitted rather than the 

recommended 48 (triple stacked) to 

provide an uninterrupted view for firstclass 

promenade decks 

60 feet 

15 Bulkheads/16 Compartments 

Bulkheads 

end10 feet 

above 

waterline 




Page 21

By the end of construction Titanic’s safety systems were severely 

compromised. But officers and crew believed they had the safest 

ship ever built and all risks had been mitigated 

• Safety regulations, for lifeboats, were hopelessly outdated by 

advances in ship-building technology. 

• Titanic was presented and sold at the highest safety level, but in 

terms of passenger safety, it was at the low to medium level. 

• The expensive construction effort was very misdirected 

incorporating the earlier mistakes, of the requirements and 

architecture stages. 




Page 22

In the construction stage the project team the project team can 

minimize risks with the following techniques: 

B EST 

PRACTICES 

• Identify building blocks (components vs prefab) and 

solution alternatives (build versus buy). 

• Identify non-functional alternatives (safety features). 

• Build in cycles. Start small (prototypes), and scale up. 

• Tier the solution, scale independently, and create 

redundancy. 

• Review Government regulations that may impact. 

• Ensure business executives and sponsors are involved 

throughout the construction, through steering committees. 




Page 23

The business pressures for Titanic to go live were enormous with 

the large investments tied up in its four-year construction. 

• Olympic was in dry dock for repair because 

of the collision with HMS Hawke, one sixth of 

original cost. This delayed Titanic’s maiden 

voyage by a month. Titanic's propeller shaft 

was used on the Olympic. 

 

 

 

• Extensive sea trials and testing were not 

considered critical partly because Olympic 

was established in service. 

• Olympic was a test bed or yardstick for 

Titanic. It is debatable how well the 

experiences from Olympic were transferred. 

• Formalized change-management/ control 

theory not been established. 

• Too much faith in Olympic’s track record. 




Page 24

In the planning stage the project team can minimize risks with 

the following techniques: 

• Review existing/previous projects with the PMO for 

commonality. 

• Follow a change-management process, use risk assessments. 

• Plan level of testing, and select right tests, and acceptance 

criteria. 

• Assign operations services ownership and control of process. 

• Define alternatives to launch (withdrawal), and back-out plans. 

• Create a test environment that mirrors the live environment. 

• Prepare for increase in frequency of changes with the Internet. 

• Deploy in test environment first, run parallel to live 

environment. 

• Ensure testing is broad not just on functions. 

B EST 

PRACTICES 




Page 25

The business pressures and pressing economic needs pushed 

Titanic into service and resulted in limited testing completed 

• In reality Titanic’s testing consisted of the maiden voyage 

across the Atlantic fully loaded with passengers. 

• On leaving port, Titanic nearly collided with the steamer New York 

coming within four feet indicating the challenges in operating a very 

large ship. 

• Only one lifeboat drill was performed. The crew was unprepared to 

handle a disaster and the launch of all lifeboats. 

• No time was spent in preparing 

the crew for the maiden voyage. 

The crew of 900 had 83 

mariners. 




Page 26

Titanic’s captain and officers were well aware of “Iceberg 

Alley” and the associated risks. 

• A well known feature of the North 

Atlantic to experienced mariners. 

• Winter of 1911 unseasonably mild. 

• April worst month for icebergs. 

• Sailing path moved 10 miles south. 

• Fate of French liner Niagara known. 




Page 27

At this point in the project it is common to implement Service Level L 

Agreements. Bruce Ismay went further and compromised these. 

• Bruce Ismay published a shipping 

announcement in the New York Times that 

Titanic would arrive a day early to published 

schedule. This was a new service level that 

proved to be fateful in pushing the ship to its 

operational limits. 

• The passenger list was a “who’s who” of 

public life, with 300 very famous people, 

collectively worth of over $500 million. This 

underlined public confidence in the ship. 




Page 28

In the testing stage the project team can minimize risks with 

the following techniques: 

B EST 

PRACTICES 

• Undertake business and technical risk assessments. 

• Ensure independent test teams with incentives to test 

objectively. 

• Establish the ability to stop an implementation if testing fails. 

• Ensure that major testing, once under way, can be halted. 

• Ensure the change-management process has various 

strategies for rapid promotion and implementation. 

• Avoid change-management process that lacks political 

support and “teeth” to be effective. 

• Avoid giving developers deployment rights to live 

environment. 

• Refine your service level objectives and agreements. 




Page 29

The operating stage required the deployment of the ship into 

production and her maiden voyage 

• Titanic had a number of built-in feedback mechanisms that were 

discounted, fudged (ice bucket test), or just ignored. 

• Operators overloaded by commercial traffic (noise) did not pass 

the ice warnings (signal) along in a timely fashion. 

• Ice-warning information eventually communicated through the 

hierarchy to Captain Smith wasn’t adequately acted on. 

• The captain very resistant to technology relied on “gut” feel and 

experience and undermined Marconigram information. 

• The officers kept their binoculars 

and did not share them with the 

lookouts. 




Page 30

During the operating stage Bruce Ismay was determined to prove 

Titanic was a superior ship to Olympic and meet his new SLO, 

dramatically increasing the risks 

• The chain of command on board was 

usurped as Bruce Ismay overrode 

Captain Smith and pushed the ship 

and crew continuously to its limits. 

• The captain succumbed to the 

director’s pressure to sail at full 

speed through the danger area. 

• The business pressure overrode 

the operations services mandate. 

• Stringent guidelines were broken 

putting everything in jeopardy. 




Page 31

The collision was inevitable and Murdoch almost 

succeeded pulling off a brilliant maneuver. 

• All the feedback systems were compromised. 

• The ship reached its peak speed as three additional boilers 

were lit, more than at any other time in the journey,. 

• Californian’s last radio message was ignored. 

• The lookouts warning came 37 seconds before the collision. 

• Officer Murdoch tried to dodge the iceberg and decelerate the 

ship through a “port-around” or “S turn.” 

Ice Shelf 

Iceberg 




Page 32

The ship grounded itself on the ice shelf in an effort to avoid a head 

on collision. Consistent testimonies of the collision describe it as 

innocuous. 

• “I heard this thump, then I could feel the boat quiver and could feel a sort 

of rumbling..” 

– Joseph Scarott Seaman 

• “... It was like a heavy vibration. It was not a violent shock.” 

– Walter Brice Able Bodied Seaman 

• “…I felt as though a heavy wave had struck our ship. She quivered under it 

somewhat.” 

– Major Arthur Peuchen First Class Passenger 

• “I was dreaming, and I woke up when I heard a slight crash. I paid no 

attention to it until the engines stop.” 

– C E Henry Stengel First Class Passenger 

• “We were thrown from the bench on which we were sitting. The shock was 

accompanied by a grinding noise….” 

– Edward Dorking Third Class Passenger 

• “It was like thunder, the roar of thunder…” 

– George Beauchamp Fireman 




Page 33

Unperturbed the bridge sends two assessment groups 

to survey the ship for damage. 

• No sharp jolt of ship slamming horizontally into immovable 

object. 

• No rebound effect from side swipe or glancing blow. 

• No on thrown about, breakfast cutlery in dining rooms 

barely rattled. 

• No deaths, no injuries, no broken bones. The ship quivered 

or rumbled for several seconds. 




Page 34

Two assessment groups surveyed the ship for damage. Bruce 

Ismay made a fateful decision to prove Titanic could save herself. 

• The first group quickly return with an inaccurate report of 

no major damage. They had descended only a few decks. 

• Ismay’s dilemma as there were several options available for 

recovery. 

– Remain static and put out a distress call. 

– Restart the engines and limp back to Halifax. 

• Before second group returned with architect and carpenter 

the director took the decision to sail off the ice-shelf. 

• First wireless message sent to White Star office in New 

York. 

– “TITANIC PROCEEDING TO HALIFAX. PASSENGERS WILL PROBABLY LAND 

THERE WEDNESDAY; ALL SAFE. SMITH” 

– All true at 11:53 pm. 

• The pumps could not keep up with the increased flooding. 

• The architect predicted the ship had 2 hours. 




Page 35

In the operating stage the project team can minimize risks 

with the following techniques: 

• Ensure the business/operations services refine 

SLAs, and adhere these. 

• Structure support for one holistic client view of 

the service, avoid technology silos, assign 

operations sole responsibility. 

• Build problem-management processes based 

on the speed of recovery, & recovery clock. 

• Base proactive problem-avoidance around an 

early warning system. 

• Synthesize and route timely information from 

feedback mechanisms to decision-makers. 

B EST 

PRACTICES 




Page 36

And take a comprehensive approach to organization, processes, 

and tools, a basis for continuous availability: 

• Monitor strategic components critical to environment 

availability. 

• Avoid claiming a project success too soon. 

• Monitor broadly across the whole environment after an 

implementation. 

• Investigate environmental anomalies quickly using 

cause-and-effect, delays may be costly. 

• Identify meaningful metrics in “User outage 

minutes” rather than percentages of availability. 

• Re-evaluate the initial business case based on 

returns and metrics. 

B EST 

PRACTICES 




Page 37

The officers and crew operated in a state of disbelief unable to 

perform an effective recovery. Panic ensued amongst passengers. 

• The disaster assessment took 20 minutes, and 65 

minutes before the captain ordered lifeboats filled. 

• Poor communication impeded passengers & crew 

from reacting, possibly deliberate to avoid panic. 

• The hierarchical organizational structure and 

physical segregation controlled information flow. 

• Many passengers got up and went back to bed. 

• The first life-boat left half full reluctance to get in. 

• The crew skeptical that anything was serious. Any 

recovery plan would have been poorly executed. 

• Launching 16 lifeboats took over 90 minutes. The 

last 2 Englehardts were floated off upside down. 




Page 38

In the operating stage the project team can minimize risks with the 

following techniques: 

B EST 

PRACTICES 

• Ensure once disaster is declared it is enacted according to 

the plan and followed without hesitation. 

• Ensure disaster recovery plans are easily accessible in the 

organization. 

• Nominate one group “guardian” (operations services) of 

the disaster recovery plan. 

• Ensure staff adequately trained to follow disaster recovery 

plans. 

• Practice and rehearse disaster recovery plans regularly. 




Page 39

Following Titanic’s s disaster, both the U.S. and British authorities 

conducted post-mortems. The U.S inquiry came close to uncovering 

the cover up. 

• US inquiry called 82 witnesses, 

specialists and technical experts. 

• Determined the ship had reached 

top speed through the ice-field with 

no attempt to slow down. 

• Forced Bruce Ismay to remain in 

U.S. & grilled him over role as 

director, and relationship with 

captain, officers and crew. 

• Recommended lifeboat space for 

every person on all ships from U.S. 

ports; lifeboat drills; adequate 

manning of boats; and 24-hour 

operation of radiotelegraph 

equipment. 

• British inquiry saved White Star 

from bankruptcy to stop German 

competition. 

• Saw European war looming, needed 

large ships for troops and materials. 

• Condemned Captain Lord for not 

responding to Titanic’s flares. 

• Criticized British Board of Trade for 

failing to update lifeboat regulations. 

• Today private lawsuits would have 

brought White Star. 

• Titanic unnerved western society’s 

faith in technology progress. 

• Olympic, served distinguished 24 

year career before being scraped. 




Page 40

Lessons learned - what can you take from all this. Your IT 

project is little different to Titanic’s project. 

• Historical analogy cuts away layers of jargon and complexity 

that shroud project’s today. 

• Roots of Titanic’s disaster in the project, compromises to 

safety features and elevation of expectations allowed 

business pressures to override operational procedures. 

• This lead to numerous violations of the “rules of good 

seamanship”. 

• The probability of failure was very high because of the 

inability to recognize the introduced risks. 




Page 41

Why do projects fail? Recap of Standish group 

Project Success Factors 

1. User Involvement 

2. Executive Management Support 

3. Clear Statement of Requirements 

4. Proper Planning 

5. Realistic Expectations 

6. Smaller Project Milestones 

7. Competent Staff 

8. Ownership 

9. Clear Vision & Objectives 

10. Hard-Working, Focused Staff 

11. Other 

Project Impaired Factors 

1. Incomplete Requirements 

2. Lack of User Involvement 

3. Lack of Resources 

4. Unrealistic Expectations 

5. Lack of Executive Support 

6. Changing Requirements & 

Specifications 

7. Lack of Planning 

8. Didn't Need It Any Longer 

9. Lack of IT Management 

10. Technology lliteracy 

11. Other 

•Why we have the 9 knowledge areas from PMBOK 




Page 42

Mitigate risk from the project outset through the application of best 

practices at each stage of the IT project 

• 100s of best practices listed by project stage: 

1. Project life cycle, deliverables and iteration 

2. Business case for an online operation 

3. Mission critical application dependencies 

4. Architectural models and frameworks 

5. Enterprise application integration and 

interdependency of data 

6. Organizational and process elements 

7. Change and problem management 

8. Use of metrics, service levels objectives and 

agreements 

9. Use of automation and Early Warning Systems 

10. Disaster recovery & business continuity plans 

B EST 

PRACTICES 

Project 

Managers 

Business 

Executives 

Implementation of one best practice can save thousands of dollars 




Page 43

Questions 

This presentation will be available on-line 

Mark is available to work with you and your organization 

(PMs and Executives), speak or run workshops 




Page 44

Credits and Sources 

• 1998 MERIT Project. Best Practices in Enterprise Management. 

• Bonsall, Thomas E. Great Shipwrecks of the 20th Century. New York: Gallery Books. 

• Bristow, Diana. Titanic: Sinking the Myths. 

• Brown, David. The Last Log of the Titanic. McGraw-Hill. 

• Davie, Michael. The Titanic: The Full Story of a Tragedy. The Bodleyhead Ltd. 

• Hyslop, Donald, Alastair Forsyth, and Sheila Jemima. Titanic Voices. New York: St. 

Martin’s Press, 1998. 

• Lord, Walter. A Night to Remember. New York: Holt, Rinehart, & Winston, 1955. 

• Lord, Walter. The Night Lives On. New York: Holt, Rinehart, & Winston, 1985. 

• Spignesi, Stephen. The Complete Titanic. Birch Lane Press Group, 1998. 

• Thompson, Harvey. Customer Value Management. McGraw-Hill, 2000. 

• Wade, Wyn Craig. The Titanic: End of a Dream. New York: Rawson, Wade, 1979. 

• Wels, Susan. Titanic: Legacy of the World’s Greatest Ocean Liner. Alexandria, VA: 

Time-Life Books, 2000. 

• Illustrations were used courtesy of the Ulster Folk & Transport Museum 




Page 45




Page 46

“Titanic Lessons for IT Projects” - FVP PMP Luncheons - Noblis

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?