[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Community Building and Engagement- first pass
|
Community Building and Engagement around Standards It can be more important to manage engagement than to
develop a good standard. A good standard grows from the involvement of a diverse
community with diverse experience. Each company participating in the
development of a standard may commit hundreds of hours of engineering or IT
time. Company managers must consent to exposing and sharing intellectual
property. Committee members must maintain enthusiasm during the thankless
months or participation. Standard adoption is critical to the development of a
successful standard. Before a specification is voted on, participants must
develop and use implementations of the standard. This may require considerable
time to develop interoperable components with which there are currently no
systems to interoperate. Rapid adoption helps future versions of standards
improve. Companies see no benefit to being “buzz-word compliant” if
the standard or function has no buzz. Specifications begin because there is a small technical
problem to solve. Technicians like to solve technical problems. These problems
may present clear and expensive obstacles to daily business. For these classes
of standards that may be enough. Other standards invite new areas of interaction. They create
a possibility that was not there before. They enable solving a problem long
thought insoluble. For these standards. There must be a program of active
engagement of a wider audience and of building a community of stakeholders
around the standard. OASIS policies limits the pronouncements that may come from
members of a Technical Committee. [Mary – I can use some assistance here]
Despite these restrictions on the discussion of the standards themselves, there
are some approaches that the Committee Chair can follow to build and maintain
wider interest in the developing specification. First and foremost is the problem. The standard is being
developed for a reason. That reason should have been stated clearly in the
charter as the purpose of the standard. The first responsibility of the forming
committee is to state clearly the purpose of the specification. This purpose is
clearly visible and public, and discussing it violates not the procedures of
OASIS. The purpose section of a well-written charter provides the
theme for many an improvised talk. The purpose section of the charter is the
reason for the work. Someone on the Technical Committee, usually the Chair,
should keep that purpose always in mind. The first circle of engagement is the actual participants in
the TC. There are three kinds of participants in a TC. There are those who
participate just to slow changes to the status quo. There are those who are
just watching to see if they have to pay attention to it finally. There are
those who are driven to get the work done. These three groups do not self
identify themselves. The chairs has different responsibilities for managing
each group. The first must be kept content while keeping them from impeding
progress. The last group should be turned loose, given the encouragement and
advice they need to get the work done. The second group, the watchers, must be
continually re-engaged and re-energized. They should be reminded regularly of the
purpose of the work, and of the problems it is meant to solve. Behind each participant is the organizational representative
who has approved their participation, and who may have paid for their
participation. It is a good practice for the [chair] to recall the interests of
these representatives and to contact them regularly to discuss the progress of
the TC. After losing several members early in the process, I made a point of
producing regular emails restating the purpose of the TC, and the progress to date,
to the organizational members. I tried to do this at least quarterly. I made
sure to do this in the month before the birthday of the TC. I wanted the
managers of those who had joined OASIS for the particular TC to understand the
progress before they received their renewal of dues notification. This business case is also the basis for outreach. There are
certain magazines and trade shows tied to each business purpose. The committee
chair probably explored each of them prior to the formation of the technical
committee. Each of them represents a community that should be kept aware of the
TC. The writer must be careful to maintain a balance between evangelism and
making statements or promises that are entirely inappropriate. One of the challenges of standards and interoperability, is
that it is often the case that the largest player in the field is already in a
position that all other market participants must make their product compatible
with their de facto standard. If the primary company markets primarily by rent
seeking, then they will be resistant to change. Innovators who wish to join the
market cannot force adoption by the predominant player. In this case, building
consensus and adoption must be by creating customer awareness and demand. Where there is a local near monopoly, standards adoption is
often best encouraged by those who wield a contrary monopsonistic force. If
your standard is being built for such an industry, know who the regional
monopsonists are, and keep them informed of the standard. Such customers may
also advance a standard by providing funding for dedicated editors of the
standards process. Other standards offer the potential to create new markets.
The community there is the new participants and early adopters. Evangelists on
the committee should be encouraged to speak to that vision in whatever forum
the potential early adopters are in. These may be new businesses, just waiting
for their way to be made smooth. They may be existing companies who will gain
access to new markets. They may be consumers who never knew they could ask for
that functionality. The strongest tool that a committee chair has to maintain
community and build engagement is a sense of urgency. Standards take a while,
and their production is hard work. Standards development requires participants
who are willing to argue, seemingly endlessly, over small details. It is easy
for them to take longer than they need to. A committee that has an excellent
community but takes too long may fail. A standard that is good enough and
delivered rapidly may face fewer challenges. Go as fast as you can. Anything that look like an actual press release, or implies
that “OASIS says…” can only be issued in very specific
circumstances. If you are tempted to make such a statement, discuss it in
advance with the OASIS staff contact for your TC, and make sure the final
release is issued by OASIS staff. "It is the theory that decides what can be observed." - Albert Einstein
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]