I spent some time on Monday watching another SDO group struggle with determining scope for a project. I have some doubts about the outcome, but getting this right is both very important and very hard. It's something that takes training, experience, and the willingness to learn from other SDO efforts. The training I mean is training in systems engineering, not training in the processes of this or that SDO. Almost all the scope problems can be traced in part to failures of system engineering.
There is one rule of scope that is crucial and very hard to accomplish:
The scope of the standard should be the smallest possible scope that still solves the problem. If this means splitting into multiple standards, split the problem and solve each one independently. This means eliminating all, really all, of the desireable goals. Include only the absolutely necessary. But don't leave out anything crucial.
To determine this scope you need to understand the problem and the context. You don't design in isolation. The awareness of the context and all its problems presents a powerful motivation to expand the scope of the standard. It's very hard to see obvious problems crying out for solutions and cut them out of the scope.
System engineering training can help. Systems engineering is the branch of engineering that concentrates on taking complex systems, dividing them into pieces, and understanding the relationships between those pieces. This is crucial to finding the dividing lines that allow the standard to both solve one problem completely and fit into a system with many other solutions for other problems.
One example of a success in controlling scope is the 10baseT ethernet standard. It defined everything from the connector through electrical signals and timings for 10 Mbit/s ethernet. Then it stopped. It did not cover any other aspect of networking, neither the wiring nor the software. This allowed 10baseT to evolve and co-exist with other standards successfully. The router, hub, and other wiring could evolve with those technologies. The networking could be SNA, OSI, TCP/IP, PPPOE, and other networking methods. The host computer could be a mini-computer, and introduction of PC desktops, laptops, etc. did not cause problems. The care in designing 10baseT allowed ethernet evolution to add 100baseT and 1000baseT without forcing mass replacements.
That's because 10BaseT chose it's scope well. It did the ethernet job without failure or compromise. It did not interfere with other solutions to other parts of the problem by attempting to solve even a small part of that other problem.
An example of a failure is the RS-322/323 specification. Few people have heard of this because it was a failure. It was to be a replacement for the RS-232 serial interface between computer and modem. It was to solve problems with cable length restrictions, signalling speed, and new modem features.
RS-322/323 introduced a huge 37-pin connector, with the implied 37 wire cable between modem and computer. It had pins and wires defined for controlling all the new modem features. It had new electrical signalling methods for better noise rejection and allowing longer cables. It could run up to 2 Mbits/sec, instead of quitting at 64 Kbps. It had massive government support. For a while, the US government was mandating RS-322/323 connections on all purchased modems. (It was like a mini-ONC for computers and modems.)
It was a total failure.
The computer industry invented it's own, unofficial, non-SDO standard. The signalling part of RS-322/323 was good, because it solved the speed and distance problem. The 37-pin D connector was much too big and 37-wire cables way too difficult. One problem with RS-232 connectors was that they were already too large, not too small. The industry considered the core problem and picked a 9-pin connector. That was enough for all the data and data control signals. All those other nice to have wires for this and that modem feature were eliminated. Modem controls moved out of hardware and into the data stream, with controls like the "Hayes" modem controls. The 9-pin serial connector could be found on minicomputers, desktop PCs, and laptops for a couple decades. It's faded away along with the modem[
The SDO problem was scope. All those nice to have modem controls should not have been in scope. They were not crucial to solving the core problem of moving data. But the SDO team could not abandon the important problem of controlling the modem. They could not accept that some other standard should control the modem. They were the modem experts. They did an excellent job, but having chosen the wrong scope they ended up with a failure. The good quality of their work shows in the decision by industry to steal all of the electrical signalling work and all of the work on the data connections. Industry stripped RS-322/323 down to the smaller scope and simpler standard that it should have been.