QUESTION: What are the fastest moving objects ever encountered in engineering?
Answer: Project design specifications.
It is a common complaint of engineers in all sectors of industry, common enough to have become something of a standing joke that their lives are made considerably more difficult by random, uncontrolled changes to a project’s specifications during the design process.
While it is easy to point a finger and jeer at the amorphous mass of management, sales and marketing, who seem to thoughtlessly originate these changes, it will be far more useful to examine the causes and ways of coping or deflecting these problems when they occur.
It is convenient to examine the ‘moving goalpost’ problem in the context of the familiar low power radio industry, as the projects tend to be relatively simple, teams are small and uncomplicated, and customer-driven custom projects are fairly usual.
"EVERY ‘IMPROVEMENT’ TAKES EXTRA EFFORT, INTRODUCES UNFORESEEN PROBLEMS AND RISKS
So what do we actually mean by a ‘moving goalpost’?
Three specific categories can be identified:
Time constraint changes – where the amount of time initially estimated for the completion of the project is suddenly curtailed. This occurs either where the delivery date is moved, or where the design team workload increases, reducing the manpower resources assigned to the specific project.
Core specification changes – where the basic performance requirements, or the approval specification being designed to, are altered. This can be as simple as a need for more transmitter output power, or as complex as a change from one compliance document to another; i.e. from EN300-220 to EN300-113.
Feature creepage – the inclusion of apparently desirable extra functions, outside the original scope of the design, such as the addition of a display, an additional interface, or an extra power source.
The actual reason for a goalpost change is harder to pin down:
Incomplete specifications. At the outset of any design project, it is necessary to establish within a reasonable framework just what is being made. All too often, this process concentrates on a handful of vital characteristics, for example “the link must transmit 4800 baud data over a 10km sea-path”, while ignoring apparently mundane details which have considerable influence over the subsequent design choices, such as “nominal operating temperature is -45 degrees”, for example.
Attempt at an early stage to capture as much data as possible regarding the final application and insure that the design covers all these eventualities. Any areas where the customer (or application) seems vague or uncritical should also be detailed in some respect.
Late customer consultation. The end user must be involved from the beginning of the specification process and their actual requirements must be the foundation of the design. Once the program has started, however, they must not be allowed to ‘edit’ their specification, unless the entire project is revised.
I once worked on a project where a discussion with the customer produced a draft design based on minor changes to existing product. Work commenced. The customer was then approached again by sales and effectively asked for a ‘clean slate’ wish list. This resulted in a second specification far removed from the original, requiring far more design work, but which was promised within the same time scales as the first.
In-company enthusiasm. “If the new product can do X, then wouldn’t it be so much better if it could do Y as well”. People are unavoidably ambitious and enthusiastic. Salesmen and applications engineers will see exciting possibilities for a new product “which only requires this tiny change, or addition”.
This way lies disaster. Every ‘improvement’ takes extra effort, introduces unforeseen problems and risks indeterminate delay. While it is important not to stifle such enthusiasm, it must be curbed.
Offer the existing design “today” with the promise of the better thing “tomorrow” – when it can be properly designed, with sufficient resources.
Malicious actions. In the ideal world, everyone in a company will be working toward the same – profitable – ends. Any engineer with more than a few years of experience will know that the real-world is very different.
Not every decision taken in a company directly aids the whole. Internal power politics and personal feuds can result in changes to specifications or, more commonly, resource allocations which are calculated to disrupt the project, either slowing completion, or forcing a cancelation.
If a work environment is dominated by such issues, then the only professional response is to seek alternative employment. The challenges thrown up by both physics and commerce are too great to tolerate malicious meddling as well.
Insufficient research. It is an unpalatable (to most managers) fact that engineering is not necessarily a completely deterministic process. Not every design idea can be made to work in a given number of days. Some things never work at all.
It is vital to plan for some ‘feasibility’ work before finalising the project specification, in order to check that all the basic concepts and circuit techniques that are needed will actually function as intended.
In conclusion: How can the goalposts be kept still?
By Myk Dormer for Radiometrix Ltd
First published in Electronics World