What Can We Learn?
So, how does this case study of an Olympic-class ship project help us with our projects today? It raises such questions as: Why do stakeholders like to "meddle"? It could be that they:
- Are following an agenda
- Have recently experienced a poorly run project or project failure
- Want the project to go their way for personal benefit
- Are not confident in the project leadership
- Do not trust the organization
- Recognize that the organizational culture panders to them
- Are building a power base at the expense of the project
For project managers today, one of the bigger challenges up front is the identification of all of the stakeholders and their motivations. This is often difficult to do in matrix organizations but things to look for include who has:
- Financial signing authority for the project.
- The staff and resources to bring to the table.
- The ability to get things done in the organization (i.e. the organizational connections).
A project tool is available help address this problem is the Stakeholder Onion Diagram. It is used to help identify the layers of various project stakeholders and is shown for the Titanic project in Figure 5.
Figure 5: The Stakeholder Onion Diagram
In any project today, project architects/designers are responsible for ensuring that subsidiary functional requirements - everything that supports the primary functional requirements, i.e. the expressed wishes of the principle stakeholders - are adequately met, including all project constraints. Non-functional requirements may also relate to the technical aspects of the design. However, these considerations are typically beyond the comfort zone of most business executives so any compromises to these, like the impacts of the bulkheads and salon, might not be readily understood. So such impacts might not be apparent as any problems might not surface until days, months, or even years after the project is completed, when the product of the project is in use.
When I was writing this case study, I spoke to many solution architects about the stakeholder scenarios in this case study. The message for project managers I got back was:
- Pay attention to what the architects (project core team) are saying relative to the requirements, and provide support in the face of meddling stakeholders particularly when changes to the non-functional requirements are called for.
- De-scoping non-functional requirements is typically very costly and a completely different scenario to de-scoping functional requirements. The two need to be understood, especially by stakeholders. De-scoping functional requirements is far less of an issue as typically they can be reintroduced in future projects, or iterations.
I believe that in the Titanic case study, the project sponsor, Bruce Ismay, steered the project to meet his agenda of providing the ultimate customer experience. The compromises to the safety features accelerated the sinking which led to the disaster, and this ended up bankrupting the company.
|
The Effect of Sponsor Meddling