• Bookmark

The Failed Vasa: COBIT 5, Technology-related Goals and the New Process Model (Part 2)

By William C. Brown, Ph.D., CISA, CPA

COBIT Focus | 29 September 2014

William C. BrownOn 10 August 1628, the Vasa, among the most expensive ships of the era, sailed on her maiden voyage and, within minutes, sank below the waves in the Stockholm (Sweden) harbor.1 The second article of a three-part series that illustrates Vasa’s stakeholder drivers, benefits, risk factors, costs, enterprise goals and, ultimately, enabler goals—all of which provide context for the seven COBIT 5 enablers—reminds readers that COBIT 5 is context-based and is not one size fits all.


COBIT 5 embraces an enterprise view, rather than a technology division or technology-in-isolation approach; a holistic approach; and a new process model with distinct roles for governance and management. The Vasa and King Adolphus of Sweden, who commissioned the building of the ship, characterize a technology solution that created demands for new governance and management capabilities similar to many organizations adopting new technologies today.


Shortly after deploying the sail in August of 1628, the Vasa began to heel as the sails caught a breeze. She then righted herself slightly—only to heel over again. Water gushed in through the open gun ports and, to everyone’s disbelief, the Vasa suddenly sank. Fifty-three lives were lost during the Vasa sailing of only 1300 meters.2


Two gun decks were a significant departure from traditional shipbuilding in the 1620s—a configuration that significantly changed the weight distribution of a ship built in that era. Most analysts now believe the ship was disproportionately narrow for a second tier of heavy cannon.


So what factors contributed to the Vasa disaster? And how do COBIT 5 enablers matter in the context of the Vasa? COBIT 5 translates the king’s needs into specific, practical and customized goals within the context of the enterprise, technology-related and enabler goals (figure 1).


Figure 1—Stakeholder Drivers Ultimately Cascade to Enabler Goals and Interactions
Figure 1
Source: Adapted from ISACA, COBIT 5, 2012


Technology Goals and the Vasa

Cascading from the balanced scorecard (BSC)3 are the technology-related goals (figure 1). COBIT 5 integrates a goals cascade from the BSC to drive technology-related goals, which support critical processes to reflect an enterprise view.


As the enterprise goals cascade to technology-related goals (figure 1), an alignment process occurs to identify the relevant BSC and shipbuilding technology goals to each enterprise goal (figure 2). The ultimate objective is to create a common language between the BSC and the technology-related goals.4
 

Figure 2—Technology-related Goals and the Vasa
BSC Technology-related Goals
Financial 01 Alignment of technology and shipbuilding strategy
02 Technology compliance and support for compliance with external laws and regulations
03 Commitment of executive management for making technology-related decisions
04 Management of technology-related shipbuilding risk
05 Realization of benefits from technology-enabled investments
06 Transparency of technology costs, benefits and risk
Customer 07 Delivery of technology in line with requirements
08 Adequate use of technology solutions
Internal 09 Technology agility
10 Security of information and infrastructure
11 Optimization of technology assets, resources and capabilities
12 Enablement and support of business processes by integrating technology into shipbuilding processes
13 Delivery of program benefits on time and on budget while meeting requirements and quality standards
14 Availability of reliable and useful information for decision making
15 Technology compliance with internal policies
Learning and growth 16 Competent and motivated technology personnel
17 Knowledge, expertise and initiatives for shipbuilding innovation
Based on: Kaplan, R; D. Norton; The Balanced Scorecard, Harvard Business Review Press, USA, 1996


Vasa’s Process Failures and Technology-related Goals

Scrutinizing the Vasa using COBIT Process Assessment Model (PAM): Using COBIT 5, it becomes apparent that process failures occurred with technology-related goals 1, 4, 7, 8, 11, 13, 16 and 17 (figure 3). Failures occurred at multiple levels, ranging from the qualifications of personnel and the inability to innovate, manage change and, ultimately, build a ship that could sail on the open seas. Risk management, a critical process for a ship, did not exist for the Vasa and will be discussed, using a COBIT 5 enterprise view, in the third article of this series. Risk management was critical, as King Adolphus of Sweden could not afford to lose a warship in the midst of the Thirty Years’ War.
 

Figure 3—Aligning BSC to the Technology-related Goals for the Vasa
BSC
BSC Goals
(See part 1 in series.)
Technology-related Goals
(See figure 2)
Financial 1. Stakeholder value: Maximize value at least cost. 1. Alignment of technology and shipbuilding strategy
3. Managing risk: Create a meaningful risk-reward paradigm. 3. Management of technology-related shipbuilding risk
Customer 7. Continuity and availability: Balance timeliness of delivery with the ability to survive high winds and storms. 7. Delivery of technology in line with requirements
Internal 8. Agility: Meet a wide range of service demands. 8. Technology agility
11. Shipbuilding processes: Optimize processes. 11. Optimization of technology assets, resources and capabilities
13. Managed change programs: Ensure that programs are in place and managed. 13. Delivery of benefits on time and on budget while meeting requirements and quality standards
Learning and growth 16. Architects and shipbuilders: Secure skilled and motivated personnel. 16. Competent and motivated technology personnel
17. Innovation culture: Ensure that architect and shipbuilders maintain innovative designs. 17. Knowledge, expertise and initiatives for shipbuilding innovation
Based on: Kaplan, R; D. Norton; The Balanced Scorecard, Harvard Business Review Press, USA, 1996


If one narrows a list of goals to further develop a continuum of the most important to least important, which would be the most important goals in the story of the Vasa? While the BSC and COBIT 5 assign primary and secondary to suggest discrete assignments for risk or benefit optimization, it is more likely that the technology-related goals are on a continuum. The assignment of that continuum is context-based and depends on such factors as whether the enterprise is large or small or whether the enterprise is a financial institution in the 21st century or a shipbuilder in the 17th century. Ranking the goals, technology-related goals 4, 8, 13 and 17 are essential or primary to a successful Vasa outcome. These four goals are high on the primary continuum, with the other goals close behind.


Risk management, or goal 4 “management of technology-related shipbuilding risk,” is the most important goal in the context of a financial loss, but even more important in the context of losing a significant warship in the midst of a war. As such, goal 4 also holds a primary rating for meeting customer requirements. Goal 8 has a primary role in supporting the innovation. Goal 13 has a primary role in the delivery of a ship that can sail in the open seas without sinking. It can be argued that goal 17, “knowledge, expertise and initiatives for shipbuilding innovation,” is ranked as primary because evidence emerged that the Vasa engineering fell well short of the requirements.


The processes underlying COBIT 5 (figure 4) are essential to success whether they are primary or secondary in a 21st century enterprise. Beyond the significant process enablers (37 processes in figure 4) are the Culture, Ethics and Behaviour enabler and the People, Skills and Competencies enabler (figure 12). Whether stakeholders ignore any of the 37 processes due to culture or ethics indifference or if the stakeholders are incompetent, the outcome is equivalent: a failed or compromised outcome. Underlying the Vasa failure are significant issues related to the culture of ethics and the risk appetite and competency of stakeholders. (A broader discussion of enablers will occur in the third article of this series.)
 

Figure 4—Processes for Governance and Management of Enterprise IT
Figure 4
Source: ISACA, COBIT 5, 2012


Failures in Processes for Management of Enterprise Technology

COBIT 5 describes the failures in processes for management of enterprise IT (see the dark blue shaded area in figure 4). Between January 1625 and November 1625, King Adolphus ordered three different lengths for the same ship (figure 5) using oak timbers for the underlying structure. One particularly noteworthy detail about the construction effort for the Vasa was that cutting timber before the specifications were final created limitations in any subsequent ship designs. Adding length to existing cut timber required new designs and add-ons to meet the new requirements. The new design was not comparable in strength to cut timber that met the length requirement and, as such, compromised the lengthened keel design.
 

Figure 5—The Vasa Design Requirements Changed Frequently 

COBIT 5: Align, Plan and Organize and Build, Acquire and Implement

  • APO02: Manage strategy
  • BAI06: Manage changes
  • BAI07: Manage change acceptance and transitioning
Date Design Requirements Changed Frequently
January 1625
  • The king ordered four warships built over a four-year period: two at 108 feet and two at 135 feet in keel length.
Summer 1625
  • Lumberjacks cut oak from the king’s forest for the keel inventory.
  • Precut oak predetermined the future size of naval ships.
September 1625
  • The Swedish navy lost 10 ships in a storm.
  • The king ordered the 108-foot ships built on an expedited time line.
November 1625
  • The king ordered the 108-foot ships to be replaced with a 120-foot keel length.
  • Construction began using a 111-foot keel length as only precut oak timbers were available.
Based on: ISACA, COBIT 5, 2012, and Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014


After construction of the 111-foot keel ship began, King Adolphus learned that Denmark was constructing a large ship with two gun decks. As such, he ordered the Vasa to include a second gun deck, but written specifications for the lengthened keel to support a longer ship configuration never existed (figure 6). Ultimately, the subsequent changes made the Vasa unseaworthy.
 

Figure 6—Drivers for Change Management 

COBIT 5: Align, Plan and Organize and Build, Acquire and Implement

  • APO04: Manage innovation
  • APO08: Manage relationships
  • BAI06: Manage changes
  • BAI07: Manage change acceptance and transitioning
  • BAI10: Manage configuration
Drivers for Change Management Response to the King’s Request
The king drove changes to the original design that were unsupported by staff competencies.
  • The lead shipwright constructed a new keel for the 135-foot ship with modifications to the original 111-foot keel.
  • A thinner and weaker keel resulted, a design unsuitable for a 135-foot ship.
Based on: ISACA, COBIT 5, 2012, and Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014


The king escalated the size and array of cannon on the Vasa on several occasions (figure 7). As the king added more cannon to the second deck, risk associated with the Vasa’s stability grew.
 

Figure 7 —Armament Requirements Changed Frequently

COBIT 5: Align, Plan and Organize and Build, Acquire and Implement

  • APO10: Manage suppliers
  • APO08: Manage relationships
  • BAI06: Manage changes
  • BAI07: Manage change acceptance and transitioning
  • BAI10: Manage configuration
Evolution of the Vasa’s Armament and the Rising Center of Gravity Armament Changes
Initial design 32 medium cannon on a single gun deck
Second iteration 36 heavy cannon on the lower deck and a variety of 42 smaller cannon and guns on the top deck
Third iteration 30 heavy cannon on the lower deck and a variety of 30 medium and small cannon on the top deck
Fourth iteration 32 heavy cannon on each deck using off-the-shelf vs. custom specifications
Fifth iteration Vasa launched with 24 heavy cannon on each deck (vs. 32) because the cannon vendor could not meet the accelerated time lines.k
Sixth iteration: political theater Addition of hundreds of ornate, gilded and painted carvings of biblical, mythical and other historic themes
Based on: ISACA, COBIT 5, 2012, and Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014


During the construction of the Vasa, the lead shipbuilder became ill in 1626 and later died in 1627, one year before the Vasa launched. The handoff of project leadership to his assistant created further delays, and numerous project management issues developed (figure 8).
 

Figure 8 —Unexpected Changes

COBIT 5: Align, Plan and Organize and Build, Acquire and Implement

  • APO07: Manage human resources
  • BAI01: Manage programs and projects
  • BAI02: Manage requirements definition
  • BIA05: Manage organizational change enablement
  • BAI08: Manage knowledge
Unexpected Changes in Project Management Accompanied by a Lack of Documentation Professional Qualifications and the Consequences to Project Management
Despite a strong reputation and many successes, the lead shipbuilder failed in project management skills.
  • Detailed specifications, including project milestones, schedules, and division of responsibilities, did not exist.
The transition to new project management was poor.
  • After the lead shipbuilder’s death, a new project leader attempted to continue with numerous design changes with no project plan.
  • Communication during the transition was poor, which resulted in further schedule delays.
  • More than 400 workers built the Vasa without coordination and with poor communication and limited leadership.
Based on: ISACA, COBIT 5, 2012, and Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014


During the 17th century, methods to calculate the center of gravity, heeling characteristics and other stability factors for ships did not exist. Captains and shipwrights learned the seaworthiness of their ships on a trial-and-error basis (figure 9).
 

Figure 9 —Lacking Body of Knowledge

COBIT 5: Align, Plan and Organize

  • APO04: Manage innovation
  • APO06: Manage budget and costs
  • APO12: Manage risk
Body of Knowledge and Risk Professional Qualifications and Testing Innovative Concepts
Trial-and-error methods were common to new ship designs.
  • Captains learned the characteristics and limits of each ship on a trial-and-error basis.
  • Many ships sank because of innovative technologies and designs.
The king accepted the risk of not knowing the outcomes of the two-tiered design.
  • The king assumed considerable risk and was aware that designs of this nature were untested.
Based on: ISACA, COBIT 5, 2012, and Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014


Robust quality control and Monitor, Evaluate and Assess domain processes can offset the risk associated with new designs and a trial-and-error design environment. Even a failed stability test just before launch was not communicated to the king, the shipwright or the lead shipbuilder (figure 10).
 

Figure 10 —Quality Control Issues

COBIT 5: Deliver, Service and Support and Monitor, Evaluate and Assess

  • DSS01: Manage operations
  • DSS02: Manage service requests and incidents
  • DSS03: Manage problems
  • MEA01: Monitor, evaluate and assess performance and conformance
  • MEA03: Monitor, evaluate and assess compliance with external requirements
Quality Dimension A Critical Quality Control Test and Response
Quality control test before the first launch Before delivery, a stability test determined the unseaworthiness of the Vasa:
  • 30 men ran side-to-side to determine its stability.
  • After three traversals, the Vasa was rocking violently.
  • Additional ballast would push the lower gun deck ports below the waterline.
Communication
  • The shipwright and the shipbuilder were not present during the stability test and were unaware of the failed stability test.
  • The added pressure from the king to launch the ship played a role.
Lack of policy around or communication of expectations
  • A formal process to report problems on the Vasa among the shipwright, shipbuilder and the king did not exist.
Based on: ISACA, COBIT 5, 2012, and Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014


The failed processes described in figures 5-10 occurred within the COBIT 5 PAM (see the dark blue shaded area of figure 4). Failures also occurred within the processes for governance of enterprise IT (GEIT) (figure 11) and ultimately doomed any chance of resurrecting the Vasa’s flawed engineering and short life.
 

Figure 11—Processes for Governance of Enterprise IT
Figure 11
Source: ISACA, COBIT 5, 2012


The third article in this series describes the failed processes supporting GEIT, and when combined with parts one and two, sets the stage to answer the ultimate question in this three part series: Why do the seven COBIT 5 enablers (figure 12) matter in the context of the Vasa?
 

Figure 12—COBIT 5 Enablers
Figure 12
Source: ISACA, COBIT 5, 2012


Watch for part three of the series, “The Failed Vasa,” on 13 October.


William C. Brown, Ph.D., CISA, CPA

Is an assistant professor, chair of the Accounting and Business program and director of the Master of Accounting program in the College of Business at Minnesota State University, Mankato (Minnesota, USA). His teaching experience includes management information systems and accounting, and he has served at various levels of responsibility, including chief financial officer, at three US Securities and Exchange Commission (SEC)-registered organizations for more than 25 years. Brown has led several project teams to implement enterprise accounting and related systems.


Endnotes

1 Vasa Museet, “The Ship,” 2014
2 Fairly, W.; “Why the Vasa Sank: 10 Lessons Learned,” Oregon Graduate Institute, USA, 2014
3 Kaplan, R; D. Norton; The Balanced Scorecard, Harvard Business Review Press, USA, 1996
4 Van Grembergen, Wim; Steven De Haes; Erik Guldentops; “Structures, Processes and Relational Mechanisms for IT Governance,” IDEA Publishing, 2004

THIS WEBSITE USES INFORMATION GATHERING TOOLS INCLUDING COOKIES, AND OTHER SIMILAR TECHNOLOGY.
BY USING THIS WEBSITE, YOU CONSENT TO USE OF THESE TOOLS. IF YOU DO NOT CONSENT, DO NOT USE THIS WEBSITE. USE OF THIS WEBSITE IS NOT REQUIRED BY ISACA. OUR PRIVACY POLICY IS LOCATED HERE.