“If you want... ...a two-hour presentation, I am ready today. If you only want a five-minute speech, it will take me two weeks to prepare” – Mark Twain
Launched on 10th August 1628 at Lödgarden in Stockholm, the Vasa was the largest and most expensive ship ever built for the Swedish navy (www.vasamuseet.se, 2020). The story is told in a Harvard Business School case study (Maccormack & Mason, 2005) and has been used as a great example of how not to manage projects (Fairley & Willshire, 2003).
When the Vasa was conceived and its build was initiated in 1626, it was planned to be a relatively small ship. When launched in 1628, it was a much larger ship that had seen numerous changes in requirements. After timbers were cut to form the keel of a smaller (111-foot) vessel, King Gustav of Sweden ordered the length be increased to 135 feet and include two enclosed gun decks, in order to compete with what intelligence suggested the Danes were constructing. The Swedes had never built a ship with two enclosed gun decks. Pressure of time meant that the keel intended for the 111-foot vessel was repurposed for the larger ship, instead of laying a new keel. As a result, the keel is relatively small and shallow for such a large ship. Because the keel had already been laid when the decision was made to amend the gun decks, the additional structure needed was only added to the upper part of the ship, meaning that the centre of gravity was much higher than was desirable – and because of the small keel, there was insufficient space for ballast to remedy this. Also because of pressure of time, it is unlikely that any formal specifications or drawings were ever prepared. Certainly, none has been found – but it is known that the ship was originally intended to be fitted with 32 24-pound guns. Gustav increased this to 64 guns, although the final number was reduced to 48 because of supply problems and the pressure to launch as early as possible. In order not to be outdone by the Danes, the King ordered the addition of several hundred oak carvings, further increasing the cost of the ship and further raising its centre of gravity. Potential stability problems were anticipated. A stability test was in fact abandoned because it became clear that the ship would have capsized had the test been concluded. It was reported that at the time the Admiral in charge of the aborted test remarked “If only the King were here…” (Fairley & Willshire, 2003).
The ship was launched with known problems because of pressure of time, because nobody could think how to solve the issues and because of pressure from a King who was conducting an overseas war and therefore unavailable for consultation.
On her launch day, the Vasa’s fate was sealed. The vessel had been subject to uncontrolled and unchallenged changes in requirement, a lack of documented specification, and a deliberate ignorance of red flags resulting from the stability test. Having sailed just 1400 yards, the ship “heeled right over and water gushed in through the gun ports until she slowly went to the bottom under sail, pennants and all” (Maccormack & Mason, 2005). It has been calculated that a breeze of no more than 4 knots would have been enough to capsize the ship. The vast size of the ship when compared to its keel can be seen clearly in the image below.
It’s clear that the Vasa project would have benefited from a clear requirements specification, as well as a mechanism for reviewing the changes in requirements that a customer as capricious as a King would have inevitably introduced. It isn’t easy to come up with a concise requirements specification. It can be a challenge to distil the objectives of a project down to the essentials, but it is well worth the effort.
Also, because problems are inevitably encountered during project execution, it is not enough to have a monolithic specification where all requirements are equally important. That would almost always lead to time and cost overruns as problems have to be solved. Some form of prioritization is needed so that the scope can be reduced to allow the project to be delivered on time and on budget. Oracle described an excellent way to define and classify requirement priorities, the MoSCoW method (Clegg & Barker, 1994). The name comes from the initial letter of each of four categories, and quoting from Clegg and Barker their categories are:
“Must Have – this item will be included in the delivered product”
“Should Have – the current project plan indicates that this item will be included… if circumstances alter it may be traded out”
“Could have – the current project plan indicates that this item will not be included… if circumstances alter it may be traded in”
“Won’t Have – this item will not be included in the delivered product”
Although it was initially designed for agile software development, this is a great and universally applicable tool to help to understand where trade-offs can be made. The two critical categories to get right are Must Have, which defines the minimum viable product, and Won’t Have, which allows things to be explicitly excluded as being out of scope. This is really useful to clarify, not only if you want your project to finish on time and in budget, but also if you don’t want your ship to sink.
Because projects rarely run early, and in practice “Could Haves” are rarely traded in, and also because projects that include the creation of hardware of any kind generally need interfaces to be built in as far as possible with an eye to the future, I prefer to repurpose the “C” as a “Contingency” to define things that, while out of scope for the current project, should be considered in the design process. For example, leaving spare connector pins, or memory space on a chip, or physical space so that a circuit board or other device can be added in a future generation product.
As a result, my definition is slightly different:
Must Have – absolutely required for a minimum viable product
Should Have – included for now but can be removed if things get difficult, in order to finish on time
Contingency – consider during the design and leave space
Won’t Have – absolutely not required, has no place in our thinking
While it lacks a bit of the elegant symmetry that characterised Clegg and Barker’s original approach, I think it adds clarity and is equally useful. The M, the C and the W each have a different meaning and are fixed as requirements. The S is the variable that can be used to trade scope against time and cost by the Project Manager. I also like to use color coding, so that each of the four categories of requirement is written in a different font. Thus:
Must Have requirements are written in green
Should Have requirements are written in orange
Contingency requirements are written in blue
Won’t Have requirements are written in red
This makes it very clear, at a glance, what each requirement means and therefore how it should be treated. It also provides a mechanism for reviewing the requirements as they change, and for understanding what can easily be traded in or out. And it makes it clear what the project will not do – what is clearly out of scope. However good the idea, a development project is doomed if the requirements specification isn’t correct. It has to fully describe what is needed AND it has to avoid scope creep. It’s as important to say what we won’t do as it is to say what we will do. The specification, and therefore the project that delivers it, should be kept as simple as possible.
“Wasting resources is a mortal sin at IKEA.… Expensive solutions to any kind of problem are usually the work of mediocrity” – IKEA founder Ingvar Kamprad
Although the requirements specification must be clear, it cannot be inflexible. It must be updated as customer requirements evolve, and immediately they evolve, but only within the scope bounded by the “Won’t Have” requirements. If customer requirements have clearly moved beyond that bound, then you are looking at a new project – and the abandonment of the current one. Abandoning the 111-foot keel when requirements clearly exceeded its capabilities might have saved the Vasa. The requirements specification is a set of “rules to live by” for the project team but must be reviewed and revisited regularly.
Two great questions to ask a Project Manager are: “exactly what does your customer need?” and “how will you know when you’re done?”. If they can’t answer straight away, they will probably fail.
Key Learnings
- Every project requires a clear requirements specification
- The requirements specification is not cast in stone, and must change as customer needs change through the course of the project – but it must have bounds
- Requirements must be reviewed regularly during the course of the project
- If customer requirements exceed defined bounds at any time, the project must be stopped, and consideration given to starting a new one.
- As well as what is out of bounds (out of scope), it is very useful to identify what is absolutely necessary for success of the project and what can be traded in and out as requirements change and as the project proceeds
References and further reading
https://www.vasamuseet.se/en/vasa-history/ (accessed June 13, 2020)
Clegg, D., & Barker, R. (1994). CASE Method Fast Track – A RAD Approach. Wokingham: Addison-Wesley.
Fairley, R. E., & Willshire, M. J. (2003). Why the Vasa sank: 10 problems and some antidotes for software projects. IEEE Software, 20(2), 18-25.
Maccormack, A., & Mason, R. (2005). The Fate of the Vasa. Boston: Harvard Business School.
© 2020 J M Clegg Ltd
Image © Art Media Factory – stock.adobe.com
Image © bob – stock.adobe.com
400 years later we are still learning this lesson!
There is so much we can learn from the past
The “Ready, Fire, Aim” approach has worked for me on many occasions. Get something in the field that meets the core requirement and then refine refine refine. Even with a lifetime of experience, stakeholders and designers so often don’t know what they don’t know until it’s been built!
Jeff – yes there’s often no substitute for field experience and exposure to the customer. As long as those core requirements are right. I think knowing what’s definitely out of scope (the “W”) can help with that. And also I think agile lends itself much better to that test/refine/test and exposure to customer feedback than more traditional techniques.
Great read John! Over time I’ve been the design engineer who had his scope creeped on and admittedly I’ve been the product line person doing the creeping.
I think my creeping ways can be attributed to a couple of things. First and foremost, not having the right information from the right customers to properly set the requirements prior to establishing the project as you described. Using biased information from second party sources and not getting the information directly from the eventual end user is a problem.
Second, I found myself having a direct line of communication with the design engineers and their optimism of what fancy bells and whistles could be included would put me in the position where I felt if we could add one or two of them, we could serve a wider customer base. Unfortunately what would happen is that we’d complicate the tool, reduce its reliability, and delay launch. A strong project manager interface could have mitigated this, but ultimately I should have known better.
What else do you see as major contributors to scope creep?
Good question Jason. You’ve covered a couple of the key issues right there. In no particular order I would say that key sources of scope creep are:
1. poor initial scope definition or poorly controlled requirements collection, trying to meet wants and not focusing on needs or not talking to or listening to the
2. uncontrolled additions to scope during project execution – these could be your engineers’ “bells and whistles” or pet projects (which can come from the bottom or the top of the organisation), or solutions to unexpected technical problems, or injections directly from the customer, or changes in the market. Agile processes serve us much better than stage-gate in situations where there is a lot of discovery during the project, but so many people use stage-gate or similarly inflexible processes. The “S” in MoSCoW can help here by giving sacrificial padding that can be removed if necessary
3. lack of engagement by a senior sponsor or stakeholder can remove an important check and balance on the team, leading to more of those “bells and whistles” or pet projects
4. longer monolithic projects are more likely to drift, better to divide into bite-sized chunks which again favours some form of agile process.
Very apt, particularly in the startup arena where resources are tight, market needs are often fluid, and is imperative that the product coming out of the gate is capable of delivering on its promises.
Thanks Deepthi. Yes, the dichotomy between fluid needs and delivery first time out is challenging but can be managed with the right approach.
John,
I appreciate you revisiting the Vasa, it is a n excellent example of how ‘management oversight’ can turn into ‘overreach’ resulting in a disaster. I appreciate your juxtaposition of the Vasa and the MosCow Rules prioritization process in a short, pithy and useful manner. Well done!
I have pulled shamelessly from this for my current project, even using your Key Learnings to open the presentation. thank you sir.
Thanks Nelson, of course you are welcome to use the content (credit appreciated). I’m glad it will be helpful to you.