Requirements

Few cars have such a notorious reputation as the Edsel, launched in 1957.  It was intended to provide the Ford Motor Company with a premium range of cars to sit between the everyday Fords and the high-end Lincolns.  Yet it was a dismal failure and cost the company hundreds of millions of dollars.  Several things went wrong – the Korean War delayed work on the programme, the US economy hit a dip at a critical time, and there were plenty of quality deficiencies.  But was a big part of the problem failing to understand what new kind of car the American public actually wanted?

There are several different sorts of requirements

Having a single, clear, written down set of requirements for the project output is essential to planning and running the project – as well as being the foundation of an unambiguous contract between the project supplier and the client of what has to be delivered.  Requirements may change or evolve, but having one agreed requirements document is part of the process of keeping a project under control throughout.  Functional requirements cover what the output is expected to consist of and be able to do.  Derived requirements come from functional requirements – such as training of end users.  External requirements may be imposed – such as relevant government regulations.  Delivery requirements define how the project must be carried out.  Capturing requirements from key stakeholders and potential consumers and end users can be a difficult and expensive task and using the right methods in the right way is important.  Surveys and interviews of various kinds, focus groups and workshops are common.  Rapid prototyping and computer simulations can be used to test reactions.  Directly observation of previous outputs in use can yield powerful insights into what changes and improvements are desirable and where trends are heading.  In the car industry, design concepts are shown off to gauge public reaction as an input to future designs.

Defining requirements is an iterative process

Requirements evolve as the project proposal comes together. In the Planning phase there will be a major effort to get the requirements clear and they are embodied in a statement of requirements. These are translated into an output specification as part of the project plan. Once Production starts, the requirements need to be reviewed and enhanced, or pared back, depending on the project’s progress, external events, and the resources available for the project. It is not uncommon for new requirements to emerge once the customer sees tangible evidence of what the output is likely to be.

Eventually requirements must be frozen and scope creep must be resisted

At some point all or some of the requirements must be frozen so that the production phase can be run effectively. If they are not, then scope creep can occur where the requirements are allowed to expand, often due to ineffective stakeholder relationships or an undisciplined or weak sponsor.

There are many instances where a far-sighted organisational leader has rejected conventional requirements gathering because they felt that consumers or end-users would be unable to visiualise the revolutionary new product or service they had devised unless they actually saw it. Classic examples include Henry Ford, who believed that most turn-of-the-20th-century Americans would be unable to grasp how a self-propelled car could possible replace the horse and trap, and Akio Morita, who pushed along what became the Sony Walkman personal music player in the face of fierce skepiticism from his marketing and engineering experts.

Main sources

Bonsall, T. (2002). Disaster in Dearborn. Stanford, CA: Stanford General Books.  Brooks, J. (2014). Business adventures. London: John Murray.