Summary: At the core of every standard setting organization (SSO) is a technical process, and the success of an SSO is in no small part a result of how effective, efficient, and appropriate a technical process it designs, implements and maintains. This article provides an overview of the technical process, and how to design a process that is best suited to the goals and realities of an SSO. It discusses different types of process and the base requirements of all technical programs; extrinsic factors that impact the type of process that is most appropriate for a given organization (e.g., the need to seek formal accreditation for its standards, relevance of government procurement, applicability of international treaties, and antitrust considerations); intrinsic factors (e.g., how broad or narrow is the mission of the SSO, how great are its resources, how many standards it will need to develop, how quickly it needs to operate, and what types of intellectual property rights may be impacted); structural and practical elements of a successful process; process steps and public access expectations and requirements; documentation and legal arrangements; and the process related to ongoing maintenance of adopted standards.
I – Introduction
Behind every standard there is the process that led to its creation. Whether that process was robust or flawed will determine whether the resulting standard is respected or denigrated, neutral or tainted, timely or rapidly outdated. In short, whether the standard proved to be useful and adopted, or just a waste of time.
Today, there are thousands of standard setting organizations (SSOs), each with its own technical process. While nearly all of these individual processes have much in common, there can also be important differences from one SSO to another. Such variations can arise for deliberate and productive reasons, or to serve proprietary purposes, or (in the case of new SSOs in their early years) simply due to inexperience on the part of the founders of the SSO in question.
In fact, the standard setting process is the product of over 100 years of evolution. As part of that process, more than one set of values and requirements.
This article will outline the principal steps in conceiving, structuring, documenting, staffing, and deploying an SSO technical process, from the proposal of a new SSO to the actual launch of its committees and working groups. For a detailed description of how to manage the other aspects of creating an SSO, see Forming a Successful Consortium — Part I: Business Considerations and Forming a Successful Consortium — Part II: Legal Considerations.
II – What is a Technical Process All About?
A technical process must be many things in order to be effective. Principally, it must be:
- Technically competent: The process must facilitate the creation of standards that have high technical quality, are easy to implement, and are free of needless compromise material and multiple permitted compliance alternatives. It must also enable effective long-term maintenance of already released standards.
- Open: Unless all can participate and have an equal say, and if the process is not managed skillfully, there will be suspicions that the resulting work product will favor some members more than others. Whether such concerns are justified or not, they can still lead to a lack of adoption of the resulting standards. Hence, the process itself must be created with safeguards and transparency, so as to inspire confidence and encourage participation.
- Timely: Unless work product is completed in timely fashion, it may no longer be useful upon release.
- Qualifying: If formal accreditation, or registration under the National Cooperative Research and Production Act (NCRPA), or eligibility under United States government procurement requirements, is deemed to be desirable, then general and/or specific process steps must be included.1
- Feasible: Different SSOs have different budgets. The more constrained the budget, the more care must be taken in creating and voluntarily staffing a process that can still be effective.
The planning of a technical process that can meet each of these tests should begin as soon as planning for the creation of the SSO itself commences. Otherwise, there will be a lag between the announcement of the new organization, and the initiation of real technical work. As a result, a process team should be created early on in the formation process, and should work in parallel with the business team that is addressing issues such as governance, membership structure, dues and recruitment.
III – Extrinsic Factors
While consortia in general and (to a lesser extent) accredited standards developments organizations (SDOs) enjoy a remarkable freedom of operation, there are a limited number of external laws, regulations and private sector rules that should be taken into account in crafting the technical process.
While each of these topics warrants the type of lengthy and detailed discussion that is beyond the scope of this article, they may be briefly summarized as follows:
3.1 — Formal Accreditation. The geology of the standard setting landscape has four distinct strata:
- Regulations (enforced by the power of the state).
- De Jure, or formally adopted, standards, that have been approved by accredited standards development bodies.
- Consortium standards, adopted by the many unaccredited standards organizations referred to as consortia, forums and special interest groups (SIGS), which are usually lumped together under the name “consortia”
- De Facto standards, that are the creation of a single company, or small group of companies, rather than through an open, consensus process. The most commonly cited example of a de facto standard is the Microsoft Windows® operating system, in its various forms. (Some purists use the designation “de facto” for any standard that is not created by an SDO.) Such “standards” are not standards in the classical sense at all, but due to their very wide adoption can still provide many of the utilitarian benefits that true standards are intended to convey
In order to have the status of a de jure standard, a specification must have been created within the organization that is internationally recognized as the official standard setting body of the host country, or by an organization that has been “accredited” by that body or an international accrediting body. In the United States, the organization that is recognized for most purposes in that regard is the American National Standards Institute, or ANSI. Some 200 SSOs, representing virtually all branches of industry, are currently accredited by ANSI.
Accreditation conveys two primary benefits (among others): first, it means that the organization itself meets a set of standards that are deemed to be conducive to values such as openness and due process. Second, it means that the standards that are produced by the accredited organization may be proposed by the national standards body for adoption by the major global standard setting organizations, such as ISO, IEC and the ITU. Adoption at this level can greatly add to the uptake of the standard in question for a variety of practical and international treaty reasons.
Traditionally, most new SSOs in the United States sought ANSI accreditation. However, beginning in the late 1980s, companies in the information technology (IT) industry began to break out of that mold, and began creating SSOs on models that were in some cases very similar, and in others much more proprietary, than those that would qualify for accreditation by ANSI. Over time, this model not only became well established in that space, but also began to spread into other areas of endeavor, such as the communications technology (CT) industry.
Moreover, the standards that these bodies created often became widely implemented on a global basis, notwithstanding the fact that they had not been approved by any national or global accreditation body. In fact, some of these SSOs (such as the W3C) voluntarily follow processes that were as open and stringent (or more so) than would be required in order to be accredited.
As SDOs lost market share to the consortia in the information and communications technology (ICT) areas, the SDOs began to create procedures that could be utilized by consortia to offer their work to national and global SDOs for adoption, albeit under a less prestigious designation. As a result, the advantages of seeking SDO status, at least in some industries, have eroded considerably in the eyes of some observers.
In summary, a crucial decision for those that would form an SSO is whether or not achieving accredited status is important to the achievement of their goals. If so, then the technical process in particular, but also the membership and certain other policies of the new SSO must meet the requirements of the accrediting body of the host country.2
3.2 — Government procurement. Governments of various countries have standards-related procurement rules. Since governments are often very significant purchasers of goods and services (in the United States the Federal Government is by far the largest purchaser), meeting those requirements can be a significant consideration in creating a new SSO.
Using the United States once more as an example, Congress passed a unique piece of legislation in 1996, titled The Technology Transfer and Advancement Act (NTTAA). Under the NTTAA, all of the federal agencies are encouraged to participate in SSO standard setting activities, and are required whenever possible to buy products that are based on SSO standards, in preference to “government unique” standards.
The primary document that provides guidance on the NTTAA is Office of Management and Budget (OMB) Circular A-119, which was revised by the OMB in 1998 in an effort to facilitate implementation of the NTTAA.3 Under A-119, a set of high-level process criteria is set out that generally tracks the more detailed requirements that ANSI uses to test the membership rules and technical process of an SSO seeking accreditation. While the federal agencies are not barred from purchasing even de facto standards-based products, alternative wares based upon standards that meet, or approach, the requirements of A-119 may have a competitive advantage in some settings.
Thus, whether or not a new SSO decides that seeking accreditation is advisable, it is still important to assess any procurement rules that may affect the value and the uptake of its standards. Especially in defense and other areas where government purchasing is very significant, companies may be less likely to join an SSO, or implement the standards of an SSO, unless that SSO’s technical process meets the minimum requirements of such rules.
Fortunately (or unfortunately, depending upon your point of view), the process requirements set forth in A-119 are in many respects general rather than specific. This has provided greater flexibility for the Agencies in purchasing products based upon the most technically effective and widely adopted standards, regardless of the finer points of the standards process that have produced those standards.
3.3 — Treaty requirements. In some cases, treaties impose national obligations to adopt certain standards. In such a situation (e.g., where food standards are in question), the first question to ask is whether such a treaty exists, and if so, how the requirements of such a treaty can be met.
3.4 — Antitrust and other safe harbors. In some cases, there may be national legislation that may provide total or partial immunity from the impact of certain laws. For example, in the United States, the NCRPA provides a measure of immunity from sanctions under the antitrust laws. Unfortunately, under legislation passed in 2004, the NCRPA was amended to cover standard setting more specifically (a good thing), but also deny coverage to SSO members. In order to be eligible to make a filing under the NCRPA, the technical process of an SSO must meet the requirements set forth in OMB Circular A-119. Since making a filing under the NCRPA is very easy, it is advisable to do so where the process requirements of A-119 are conducive to achieving the goals of an SSO’s members.
IV – Intrinsic Factors
Every new SSO should have the equivalent of a business plan, and that business plan must not only clearly articulate the goals of the new organization, but also dispassionately assess its projected resources and the image that it wishes to create in the general business community. In the area of technical process, that means that the plan should address factors such as:
4.1 How broad is the technical agenda? If the SSO has a technical agenda limited to a single specification, then a simple technical committee will be all that may be required. Conversely, if the SSO hopes to be the sole standard setting venue for an entire technical area or product space, then a variety of additional concerns will arise, such as the following:
- How many levels of working groups will be needed? In some cases, a single level of working groups operating under the Technical Committee will suffice. In other cases, an intermediate level of interest groups may need to be created to accommodate the domain-specific interests of members in a particular industry niche. Providing for SIGS below the working group level may also make sense, so that smaller numbers of members can (for example) explore possible projects and develop them to a point where a broader range of members can evaluate their potential interest.
- How will the output of multiple working groups be technically reconciled? Where an SSO has a broad technical agenda, it must worry whether its own standards will work well together. In such an organization, an “architectural review board” may be needed in order to identify potential conflicts early, and reconcile them appropriately and efficiently.
4.2 — How open does the organization wish to be? Ideally, the answer to this question will be “completely.” However, a given group of founders may not aspire to create open standards, but may instead contemplate an organization that is more akin to a joint venture. In such a situation, a technical process may still be required, but the result will be a cross licensing arrangement that will allow all parties to create products based on those standards, and to sublicense implementation rights as well (the unincorporated “promoter/adopter” model is often used in such a setting). In such a situation, the degree of openness should be clearly articulated from the outset, so that all involved are in agreement on this important point, and because many process decisions will be affected by the answer.
4.3 — What are the available resources? SSOs vary dramatically in the degree of infrastructure that they can afford. At one end of the spectrum, we have worked with limited agenda SSOs with annual budgets of under $50,000 that operate entirely on a virtual, voluntary, contributed resource basis. At the other extreme, we have helped set up organizations with multi-million dollar budgets, large paid staffs, very sophisticated IT platforms, interoperability centers, and busy in-person meeting schedules on multiple continents. What a given SSO can afford to do will be limited by how many members it can recruit, and what value those members attach to the goals of the SSO.
The most significant question under this heading is whether a full time technical director can be hired. In some cases, a member may be willing to contribute such an individual instead, and continue to pay her salary. Of these two approaches, the former is sometimes preferred, in order to neutralize any fears that one member will have disproportionate influence over the technical program. Regardless of the ultimate approach taken, a member employee will usually be needed to serve as technical director on an interim basis during the formation process, pending funding, identification and hiring of a full-time SSO employee.
While a first rate technical director (full, part-time or seconded by a member) is essential, the chairs of each working group are equally important for the work taken on by that committee. Care in the selection of individuals and clear articulation of the time and talent demands that the chair position will require are vital to optimizing the success rate of the technical process.
4.4 — What is the proper balance between speed and process? In some non-ITC sectors, the standard setting process can afford to proceed at a leisurely pace. More typically, the rate at which a given standard advances is a matter of critical importance to those involved. Since consensus processes are by their nature time consuming, a decision must be made regarding how much process can be provided while still ensuring a useful result. Multiple decisions will follow from the decision made on this point, from whether or not all negative comments must be reconciled to how long comment and voting periods will remain open, since each step in the process adds to the total production time.
4.5 — What rules should the IPR policy include? In recent years, it has become a given in the ICT sector that most members will not join a new SSO until its intellectual property rights (IPR) policy has been completed. Since a large number of companies will have strong opinions on the topic, it is imperative that the question of whether or not an IPR policy is a gating factor to formation be answered as a first order of business. Even if the answer is “no”, it will typically still be true that little or no technical work will be permitted to commence until that policy has been created and adopted.
As a result, it is important to assign a working group to creating an IPR policy as soon as the founding group of companies has agreed to move forward with the creation of an SSO. The task of creating an IPR Policy is not only vitally important, but also complicated and (often) laborious. For a detailed discussion of this topic, see the Intellectual Property Rights Policies <http://www.consortiuminfo.org/ipr> section of this site.
V – Mapping out the Process
Once a technical process team has been appointed and the above questions have been answered, the next level of details can be discussed, and team members assigned to work on them. The elements of this next layer include the following:
- IPR policy: The IPR Policy is typically a high-level rule set that is either a stand-alone document (our preference), or included in the membership agreement or bylaws. Elements of the IPR Policy will tie into the process itself as regards when IPR must be disclosed, when “patent calls” may be made at meetings, and so on.
- Process and procedures of the technical committee (PPTC): This document is the “Bible” of the technical process, and is roughly analogous to the bylaws of a corporation. In the PPTC document, all of the critical details of the process should be spelled out (as described in the Section VI of this article).
- Organizational structure: The final technical development structure should be diagrammed, showing not only the initial committees, boards and working groups, but also those that are expected to be needed at a later date.
- Approval structure: The workflow of a standard from proposal to release should also be diagrammed, as the required steps between approval at the working group level and final release of a standard can vary widely from organization to organization. In a single-specification SSO, the adoption vote of the Technical Committee, followed by ratification by the Board of Directors, may be all that is needed. In a very active SSO, however, there may be multiple intermediate steps (backwards as well as forwards) involving voting by subgroups, review by Architecture Boards, and approval by a business or other committee before final ratification by the Board.
- Technical platform: Today, there are excellent platforms (e.g., those provided by Kavi – see www.kavi.com) that provide great flexibility and effectiveness for managing and documenting the technical process. Arrangements should be made early on to contract for such a platform on a licensed or remotely hosted basis.
- Meeting schedule: A plan should be developed that spells out whether meetings will be face-to-face, telephonic and/or electronically hosted. Usually, the answer will be “all three”, but the actual schedule and distribution of methods nonetheless needs to be described.
- Roadmap: The technical deliverables necessary to fulfill the initial technical vision of the new SSO need to be prioritized and laid out chronologically, and the resources needed to execute on that plan reasonably determined and provided for.
- Staffing : The mix of volunteer, hired, and/or contracted personnel must to be agreed upon, and recruitment and contracts concluded.
VI – Implementation Requirements
Depending upon the high level decisions made, the rules of the technical process will need to incorporate the specific requirements of one or more of the following:
6.1 — Government Procurement. OMB Circular A-119 states in part that:
A voluntary consensus standards body is defined by the following attributes:
(i) Openness.
(ii) Balance of interest.
(iii) Due process.
(vi) An appeals process.
(v) Consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.
A-119 does not specify in detail what exactly would be required to meet these tests. However, the drafters of A-119 were certainly aware of the due process requirements of ANSI, and the language quoted above tracks the language of the ANSI rules discussed below. Accordingly, the ANSI process requirements may be regarded as sufficient, even if it cannot as certainly be concluded that meeting all of those requirements is necessary to meet the minimum threshold of A-119.
6.2 — NCRPA filing. The question of what process requirements would be required to qualify for effective protection under the NCRPA is somewhat complex. On the one hand, meeting those qualifications might preclude any filing by the members of an SSO as a joint venture. On the other hand, if the SSO itself wishes to avail itself of the NCRPA, then A-119 provides the test of eligibility (as well as the ambiguity: how much process (and of what type) does it take to meet the OMB A-119 test?) Unlike government procurement, however, where the federal agencies are not precluded from purchasing products based on standards created under processes that arguably fall short of the A-119 test, an SSO will either be protected or not, depending on whether a court decides that its process has made the grade. (For a more detailed discussion of the application of the NCRPA to SSOs after its recent amendment, see What Does 1086 Mean to Consortia?).
6.3 — Accreditation. If formal accreditation status is desired, then compliance with the rules of the host country will be required. In the United States, those requirements include not only adherence to the ANSI Patent Policy, but also the ANSI Due Process Requirements for American National Standards. While each of these documents is comprehensive, neither contains specific procedural steps that are mandatory. Accordingly, substantial latitude in process is allowed. Contacting the accreditation body in question at an early date is an obvious and recommended step.
VII – Significant Process Decisions
Whether or not a given SSO decides to seek accreditation or otherwise become subject to any formal requirements, there are a number of decisions that are inherent in the technical process that must be made. In chronological order, they are:
7.1 — Initiation. What should it take to launch a project within the SSO? The answer to this question should take into account allocation of often-scarce resources, relevance to the strategic mission of the SSO, and generality of interest to the membership as a whole. Typical preconditions include minimum numbers of supporting members, and approval by the technical director, vote of the technical committee, and/or approval by the Board.
7.2 — Member access. Will the work of a working group be open to all members, or only to those involved? The answer to this question will largely relate to the IPR policy provisions adopted, since access to information but absence of disclosure obligations can make it possible for non-participating members to file patents that map the evolving standard.
7.3 — Public access. The question of whether or not to make the in-process work of a working group publicly available has many facets beyond increasing the potential for IPR gamesmanship. For example, if anyone can track a standard in development, there is less incentive to join (and economically support) the SSO. On the other hand, making a draft standard public at some point during the process can have many advantages (and, in the case of accredited SDOs, is not required). Those advantages include receiving useful technical and other comments, bolstering the reputation for openness of the standards and process of the SSO, and sometimes learning of patent infringement issues in time to design around the problem. Many unaccredited SSOs as well as SDOs therefore adopt this practice.
7.4 — Reconciliation. SDOs typically require the reconciliation of all negative comments as part of their technical process. Many consortia, on the other hand, tend toward permitting detailed discussion, followed by majority voting (and then moving on), which requires fewer resources and allows for more rapid progress. Whether or not accreditation or the benefits and protections that compliance with A-119 may afford will have an impact on this decision. SDOs typically require the reconciliation of all negative comments as part of their technical process. Many consortia, on the other hand, tend toward permitting detailed discussion, followed by majority voting (and then moving on), which requires fewer resources and allows for more rapid progress. Whether or not accreditation or the benefits and protections that compliance with A-119 may afford are considered to be desirable, will have an impact on which approach a given SSO will decide to take.
7.5 — Who must disclose IPR. In light of the assertion of a number of “submarine” patents (i.e., patents that have been hidden until a standard has begun to be implemented, and then asserted for profit) in recent years against the implementers of standards, more and more SSOs are requiring that some or all of their members must disclose whether or not they have any IPR that would be infringed by the standard in development, if adopted. In the drafting of the IPR policy, decisions must be made not only regarding who must make such disclosures, but when. These decisions must then be implemented mechanically in the PPTC.
7.6 — Who must finally approve a standard. Most SSOs reserve the determination of the strategic direction of the SSO to the Board of Directors. As a result, many SSOs also require the Board of Directors to finally approve a draft standard. The scope of such review is typically limited to confirmation that the standard lies within the scope of the SSO. The Board may also serve as the court of final appeal to resolve any protests over violations of process that have not been otherwise reconciled.
VIII – Other decisions
In addition to the critical decisions described above, a variety of more mundane but still important determinations must also be made to flesh out the technical process. Specific topics include the following:
- Quorum: How many participants, and from what classes of members, must be involved in a meeting to move forward?
- Majorities: How many of those eligible to vote must do so to approve or advance a specification?
- Chairs: How are chairpersons nominated, elected and (when necessary) replaced?
- Timing: How long will working group formation periods last? How long will comment periods last? How many comment periods will there be? How often will there be votes? How long will voting periods remain open?
- Maintenance: How are standards, once adopted, updated and eventually retired? Do the working groups that developed them remain open, or are new groups commissioned for that purpose as and when necessary?
IX – Drafting the Policies and Procedures of the TC
A number of important rules relating to the technical process will typically be found in the Bylaws of the SSO (our preference), or, less frequently in the membership application or agreement. Those rules include which classes of members are entitled to participate in the technical process, which may vote in that process, and (sometimes) which classes of members can nominate technical committee officers. However, the bulk of the detail regarding technical matters should be found in the IPR Policy and the PPTC.
As a result, the PPTC is a vitally important document, and deserves not only careful planning, but also careful drafting to ensure clarity, comprehensiveness and ease of use. The technical process planning committee should prepare the PPTC as soon as practical. Once completed, the draft should be reviewed by legal counsel and approved by the Board of Directors before it is put into place.
The reasons for such thoroughness are multiple: in the first instance, the process must be mechanically effective. It also must be consistent with the values and goals of the SSO, and not result in legal risks for the members, staff or directors of the SSO. Finally, the process rules should make gamesmanship as difficult to engage in as possible.
For similar reasons, all material revisions to the PPTC should require legal review and Board of Directors approval.
X – Implementation
10.1 — Practicalities. Once the technical process has been fully planned, documented and approved, deployment follows. The deployment and ongoing maintenance of the technical process requires a few additional steps:
- Posting of Standards: Completed standards should be displayed at a public part of the SSO Website for free or fee-based downloading.
- Promotion: What if you gave a standard and nobody came? It is a rare SSO that numbers the majority of all potential implementers among its members, and therefore a plan needs to be developed to publicize the fact that a standard has been completed and is available for implementation.
- Reselling: SDOs that sell their standards for a profit to help underwrite the costs of their operations typically use resellers, even if they also sell their work directly. As with any other product, there are multiple channels available, and those channels must be identified, and then assessed to determine those that will produce the optimal result. Finally, they must be contacted and contracts agreed upon and signed.
10.2 — Legal arrangements. A variety of legal concerns require attention as well, including:
- Preparation and display of appropriate (and brief) “click wrap” licenses that must be accepted before a standard can be downloaded. Principally, such a license contains warranty disclaimers and permitted terms of use.
- Display of any “friendly” assertions of infringement by members that have been disclosed during or after the adoption process.
- Display of contact data or links to the owners of any such IPR that are willing to provide licenses.
- Notice of any “unfriendly” assertions of IPR that have been brought to the attention of the SSO.
No position is typically taken by the SSO as to the validity or invalidity of any assertions of IPR, whether friendly or otherwise
10.3 — Technical arrangements. All of the above features need to be enabled technologically. For SDOs that wish to sell their standards in electronic form, digital watermarking and other technical mechanisms will be particularly important, in order to prevent unauthorized copying and distribution.
10.4 — International adoption. Whether or not an SSO is accredited, it may wish to seek adoption of its standards by other national or international, accredited or unaccredited SSOs. In such cases, some level of synchronization of the processes and IPR policies of each organization is required.
10.5 — Maintenance. Standards must be evaluated on an ongoing basis to fix deficiencies as they are discovered and to determine whether the standard itself needs updating in order to continue to be useful. Process and staffing must be provided to serve this need.
10.6 — Withdrawal and archiving. Eventually, a standard will have completed its useful life. When this occurs, the standard should be withdrawn, but should remain publicly accessible for reference and study purposes. Once again, the PPTC should address how, by whom, and when this final step may be taken, and the SSO’s Website should provide access to the retired material.
XI – Summary
If the foregoing overview of the tasks that face would-be founders of an SSO is somewhat daunting, it is hardly surprising. Standard setting is a vital and important part of the modern world, and those that undertake it should not do so lightly. At the same time, no SSO progresses from an idea to a portfolio of adopted standards in a short period of time, and there is therefore ample time to carefully consider the decisions that need to be made, to recruit the talent needed to share the work, and to put in place the infrastructure needed to support the results. Typically, an SSO will take at least six months to complete most (but far from all) of what is described above.
At the end of the day, it should be remembered that the rewards for those that develop standards, and the stakes for those that rely on the products that implement them, are high. But standards, as noted at the beginning of this article, can be no better than the process developed to create them.
Creating such a process is a job that’s worth doing right.
NOTE: If you participate in the standards development process or are a member of the management of a standard setting organization, please feel free to contact Andrew Updegrove if you have questions about this topic.
Copyright 2007 Andrew Updegrove
End Notes
1 For an introduction to the NCRPA, see Department of Justice guide to the NCRPA:
http://www.usdoj.gov/atr/public/guidelines/ncrpa.htm
2 The ANSI policies and procedures referred to above, as well as guidelines and other related materials, may be found and downloaded here.
3 OMB Circular A-119 may be found on line here: http://www.dsp.dla.mil/omba119.htm