July 30, 2014 | Written by: Christian A. Schmidt
Share this post:
Photo courtesy of Peter Isotalo and is reproduced with permission.
In my previous blog post I told you about the Swedish warship Vasa to demonstrate the importance of proper preparation and communication. Failure in these areas can be fatal to your cloud projects.
Back in those days, most people (including the experts) thought that the bigger and more impressive a warship, and the bigger the guns it carried, the more indestructible it would be. No wonder the king got so obsessed with the idea of building something that no one else had ever accomplished. The lessons to be learned from the sinking of the Vasa are as relevant today as they were in 1628 and can easily be linked to our modern way of driving projects. In 1628, no one dared to approach King Gustav about his plans, but what about today? What have we learned in the last 400 years?
The Vasa was salvaged in 1961, and since then it has been extensively analyzed and the historical records about it have been examined. Some of the the lessons from the Vasa story are summarized below, along with my own added thoughts and suggestions on how to avoid those common challenges when implementing an integration project.
(Related: How to avoid the Vasa syndrome on your next cloud journey — Part 2)
Known challenge: Excessive schedule pressure
Vasa: The Vasa was completed under strong time constraints to meet a pressing need. Severe issues around acknowledging the problems encountered, lack of communication and the simple fact of ignoring the obvious gave it a course toward disaster.
On today’s cloud projects: Four hundred years later and apparently we haven’t learned much; at least most projects are still suffering from time constraints. Up through the 1980s, people developed a number of paradigms related to this, one of them being the theory of constraints (TOC). TOC basically adopts the common idiom of “a chain is no stronger than its weakest link,” meaning that technology, processes, software or organizations are vulnerable because the weakest part can always damage or break them or at least adversely affect the outcome. Always gain agreement on what the problem is, and then do the following:
- Gain agreement on the direction for a solution
- Gain agreement that the solution solves the problem
- Agree to overcome any potential negative ramifications
- Agree to overcome any obstacles to implementation
Don’t ignore the fact that you have a problem; if no one knows, no one cares. Ignoring the obvious caused the sinking of the Vasa because the ship was considered ready even after failing a stability test. This test failure was known to some but was not communicated to others. Don’t promote a project that won’t work just because some senior person approved it. If no one tells him differently, he won’t know about it not working.
Known challenge: Lack of a documented project plan
Vasa: The original shipwright of the Vasa died without there being a robust project plan in place and there is no evidence that the new project manager (the former assistant) prepared any new plans. After the year-long transition in leadership, it was difficult for the assistant to manage the project. This resulted in poor supervision of the various groups working on the ship (the ship builder, the engineers and the numerous subcontractors).
On today’s cloud projects: Again, 400 years later and apparently we haven’t learned much. In reality, most projects that have to go through a transition will become victims of a lack of documentation. It can be more of a challenge for the incoming project manager, as the exiting project manager no longer has the same motivation since that person is headed for new glory. Below are some useful tips for the outgoing project manager to help make the transition a success:
• Provide a project schedule deep dive. Understanding the critical path, key milestones and the core sections of the project schedule are important aspects of supporting the transition.
• Share the unspoken truths and the inside story. The project mechanics are important, but ultimately, it is people that deliver the project. There are always different personalities in teams—some may need motivation while others can be left alone to deliver without supervision.
• Provide an overview of the project stakeholders and their interests. Some stakeholders expect the status deck 24 hours before the status meeting, some stakeholders require a pre-review before the meeting and some stakeholders just need to know what you need from them to be successful. In the story of the Vasa, it seems that no one was aware of the degree to which the Vasa had evolved during its 2.5 years of construction and the (nonexistent) specifications were not revised as the operational requirements constantly changed.
Please share your firsthand cloud experience—which obstacles you encountered along the way and if possible how you managed to solve them. Comment here or connect with me on LinkedIn or Twitter @PowerOnCloud.
Please visit the IBM Cloud website for more information and to see how IBM can help you on your cloud journey.