“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.
- 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