ICT standardization processes are carried out in many different types of organizations on a national, regional (e.g. European) or global level. Mostly, standardization is conducted following a number of identical process steps. In order to interface with standards bodies in the most efficient way, your project should take these steps into account when determining work packages, when allocating resources, and when planning the timing of your deliverables. Despite these general process characteristics there are also differences between processes, for example in the formal or non-formal approach taken.
Although not all standardization processes follow exactly the same steps, in exactly the same order, a number of commonalities can be identified that characterise a ‘typical’ standardization process:
1. First, a market need for a new standard or standardization activity has to be identified and recognized among a sufficient number of members of a standards organization;
2. Subsequently, a set of requirements has to be drafted, underlying the actual technical specification work (usually referred to as ‘commercial’, ‘user’ or ‘functional’ requirements);
3. Based on consensus reached among the organization’s members on these requirements, a specification is drafted by a group of technical experts;
4. Once the draft specification is finalized, a formal approval process is conducted; this may be limited to the organization and its members, but may also invite a wider audience, e.g. to broaden the support for, or impact of the future standard;
5. After its approval, arrangements are made for testing or (self-) certification by the industry, in order to guarantee interoperability between different implementations; this may also encompass developing reference implementations or implementation guidelines;
6. Finally, a maintenance or periodic review process will be embedded in the organization's procedures to ensure the standard will remain in sync with market requirements.
When planning its standardization activities and goals, your project should determine which of the process steps it seeks to address, and in how many sequential steps it aims to participate.
Standards processes do not always have the same objectives and therefore do not always produce the same type of output. Some processes may for example pursue results more fit for legislative purposes, e.g. through emphasizing the thoroughness of their formal and public approval processes, while others just seek to produce guidelines addressing immanent market needs, e.g. through consensus among their participants.
When planning to submit your project’s output to standards bodies, you should primarily determine which standardization results you will be pursuing. In conjunction with this, you should consider the differences between formal and non-formal standards organizations, as well as differences between the standardization processes they support and between standardization deliverables they produce.
In case your project or project partners are aiming to set standards that ultimately should have a more legal (or mandatory) character, choosing a formal standards body could be the best route. On the other hand, formal standards bodies should not exclusively be associated with formal standards processes; both formal standards bodies and industry consortia may be able to provide the processes that best fit your project objectives, regardless of the actual standardization deliverable you’re pursuing.