The most common causes of project management failure – Part II

Following are four more common causes of project management failure:

1.     Deliverables do not work

Example:

The Titanic did have “enough” lifeboats according to the standards in effect at the time. This was because the weight of a ship — not the number of passengers — determined the number of required lifeboats. At the time, the Board of Trade‘s regulations stated that British vessels over 10,000 tons must carry 16 lifeboats with a capacity of 5,500 cubic feet (160 m3), plus enough capacity in rafts and floats for 75% (or 50% in case of a vessel with watertight bulkheads) of that in the lifeboats. Therefore, the White Star Line actually provided more lifeboat accommodation than was legally required. These standards changed as a result of the inquiries into the disaster.

2.      Insufficient risk assessment and mitigation

Examples:

The Citicorp building was a pioneering design when it opened in 1977: its body raised up on nine-storey “piloti” located in the middle of each wall (and not the corners as you might expect). Unbeknown to engineer William LeMessurier, contractors substituted bolts for the welded bracing intended to transfer the building weight to the ground. When a student phoned LeMessurier, curious as to how the building would fare in high winds, the engineer ran further calculations and, learning of the substitution, realized the building was liable to sudden structural collapse. Working overnight with hurricanes predicted, the joints were reinforced and disaster averted.

In 1993, FoxMeyer Drugs was the fourth largest distributor of pharmaceuticals in the U.S., worth $5 billion. In an attempt to increase efficiency, FoxMeyer purchased a SAP system and a warehouse automation system and then hired Andersen Consulting to integrate and implement the two in what was supposed to be a $35 million project. The entire system was supposed to be implemented in 18 months, which was an aggressive timeline. The warehouse employees whose jobs were threatened by the automated system were not supportive of the project, to the extent of sabotage. The new system turned out to be less capable than the one it replaced: By 1994, the SAP system was processing only 10,000 orders a night, compared with 420,000 orders under the old mainframe. Once a $5 billion company, FoxMeyer filed under Chapter 11 in 1996 shortly after taking a $34 million charge to cover uncollectible costs related to shipping and inventory troubles. In 1998 the trustee in bankruptcy for FoxMeyer sued SAP for $500 million.  In 2004 SAP paid to settle the case.

3.      Lack of expertise

Example:

In 1628 the Swedish Navy’s new flagship Vasa sunk on its first voyage after completing less than 1 nautical mile. A gust of wind was able to capsize the ship resulting in considerable loss of life. As one of the world’s first double deck gunboats, the Vasa had a significant amount of weight above the waterline, including carvings and statues designed to impress and intimidate those who saw the ship. Although stability tests undertaken before the voyage had identified the problem, no one wanted to inform the King of the issue. At the time stability tests were performed by having the crew line up on one side of the ship and then having them run from one side to the other. After the crew had made 3 such round trips, the ship was rocking alarmingly. Lack of technical knowledge needed to make the project a success. “Vasa” was one of the earliest examples of a warship with two full gun decks, and was built when the theoretic principles of shipbuilding were still poorly understood. The safety margins at the time were also far below anything that would be acceptable today. Combined with the fact that 17th century warships were built with intentionally high superstructures (to be used as firing platforms), this made the Vasa a risky undertaking

4.      The project fails to understand who their stakeholders are, or fails to engage and communicate with them effectively, or the team themselves are not collaborating effectively.

Example:

The Qantas (an Australian airline) “Jetsmart” engineering parts management system cost $40 million and was renamed “Dumbjet” by aircraft engineers because the system was so difficult to use. In February, 2008, Qantas canceled Jetsmart, a $40 million parts management system implementation. Issues with the project go back to at least 2004, when the union entered a dispute with Qantas, claiming the software unnecessarily increased its members’ workload. At that time, the union advised mechanics employed at Qantas to “not assist with the implementation”. Also, the software was poorly designed and difficult to use, and that engineers didn’t receive sufficient training. Failure to engage the engineers who would be the eventual users of the system into the requirements and design processes resulted in a system that the engineers deemed to be unusable once it was launched. After just a few years in operation (during which time some staff refused to use it and unions threatened industrial action), a new system introduced, project Marlin. Qantas’s Chief Financial officer is quoted in Australian IT Magazine as having said “We wouldn’t ask the engineers (licensed airplane mechanics) what their views on our software systems were. We’ll put in what we think is the appropriate for us”.  The failure to engage the right stakeholders resulted in the total rejection of the project and the need to start from scratch with a replacement.

One final comment:

Many project managers treat the symptoms only, thus, one important root cause for PM failure is rarely considered: the system, with its hierarchies and incentives.  Like a body cannot function without all the parts, a company’s people, processes and products are interconnected. A project is usually carried out within an organizational setting, within unwritten norms and formal policies which dictate how things are done within the organization. Dysfunctional norms and policies could be the root cause of failure and they would have to be corrected before addressing the individual project failure causes.

References

http://eight2late.wordpress.com/2013/06/18/symptoms-not-causes-a-systems-perspective-on-project-failure/

http://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/

http://en.wikipedia.org/wiki/Sinclair_C5

http://en.wikipedia.org/wiki/Changes_in_safety_practices_after_the_sinking_of_the_RMS_Titanic

http://en.wikipedia.org/wiki/William_LeMessurier

http://en.wikipedia.org/wiki/Titanic_Disaster

http://en.wikipedia.org/wiki/Vasa_%28ship%29

http://www.brighthubpm.com/monitoring-projects/15893-lessons-we-can-learn-from-three-project-management-horror-stories/

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s