A Guideline for Standards Implementation

Stewart Crawford
AT&T Bell Laboratories
Holmdel, New Jersey 07733

ABSTRACT

This paper summarizes a discussion session on standards implementation. The session goal was to consolidate and refine the group's experience into a set of relevant considerations for implementing standards. After defining the "consistent use" of a standard within a project to be the measurable hallmark of successful implementation, this paper covers guidelines for planning the introduction and use of a standard, introducing and using it, and then improving it based upon feedback from its use.

AUTHOR'S NOTE: I recently re-read this paper, from the mid-80's, and was impressed at how well the collective wisdom of a top-notch group of practitioners has stood through time. It is as relevant today as when written down 20 years ago. I have since continued in other directions, but consider myself privileged to have worked with them all at the time. The original publication is rather obscure, so as a service to my profession I post it here. Originally published in: "Computer Standards Conference 1986, Proceedings", IEEE Computer Society Press, Washington DC, IEEE Catalog #86CH2283-0, ISBN 0-8186-0698-3, pp. 18-20.

1. Background and Summary

This paper summarizes the results of a discussion session on the topic of Standards Implementation, a session I conducted at SESAW-III, the Third Software Engineering Standards Applications Workshop1. My overall goal for the discussion session was to consolidate and refine the group's collective experience, both with successful and unsuccessful implementations, into a set of relevant considerations for implementing standards. Though the workshop had a software engineering orientation, much of this experience is applicable to software standards in general, and even to standards outside the software domain.

The discussion session involved approximately 25 people of varied background in a two-part interaction. The first meeting was a brain-storming session where the participants threw out their observations, ideas, and concerns to the group. I consolidated and organized these ideas, and fed this back to the group for discussion during the second meeting. This paper is based on the summary of the group's general consensus which I presented on the final day of the Workshop to all the participants.

The paper is divided into five major topics based on the group's discussion. First, we agreed on a definition for what it means to talk of the successful implementation of a standard. Next, we outlined some fundamental prerequisites for such success. And then, dividing the subject into three parts, we discussed planning for the introduction and use of a standard, introducing and using it, and then improving it based upon feedback from its use.

2. Defining Success

As we discussed what we meant by success, it became clear that we could talk of the successful implementation of a standard either within a project, within an organization (consisting of many projects), or within an industry (consisting of many organizations). Thus, to focus the group on one particular task, we addressed and defined what we meant by "successful" implementation of a standard within a project. Though this particular definition is somewhat narrow, the group's observations can be readily extended, since the success of implementing a standard within an organization or industry depends upon successfully using the standard within the constituent projects. In fact, multiple implementations of a single standard can be made with a lower per-project cost since certain economies of scale, especially regarding planning and support, can be realized.

The group's consensus was that the consistent use of a standard within a project was the measurable hallmark of successful implementation. We also discussed as criteria for success the acceptance by users and the understanding of [the standard's] purpose. However, these seemed to address more specialized cases. The former is a good indicator of the success of a voluntary standard. And with regard to the latter, use is the desired and measurable result, not understanding; as one participant noted, "You don't have to love it, just use it!"

3. Implementing Software Engineering Standards

What follows is the group's consensus recipe for successfully implementing a standard within a project.

3.1 Fundamental Prerequisites

At some level within the project's management where use of a standard is contemplated, the standard should address a recognized need, and the overall benefits of its use clearly understood. The need and benefits should be documented and promulgated. Those people whose lives and work will be impacted by a standard need to understand the problem the standard addresses and the benefit expected from its use. This understanding is necessary background for those people who will ultimately either use the standard or work their way around it.

When a standard is mandated, e.g. when specified by contract, there is generally little flexibility in its content. However, when an existing standard is selected and/or modified, or a new one developed from scratch, here are some important considerations:

Underlying it all must be support from the project's management. There will always be some short term costs involved in implementing a standard; someone will have to provide either money or staff for the activities necessary to introduce a standard and successfully support its use. In the case where motivation for a standard comes from the bottom up organizationally, management must be, at a minimum, informed of and acquiescent to the standard's use.

3.2 Planning for Introduction and Use

Whenever possible, a standard should be tailored for the project where its use is intended. "Generic" standards, by their nature, often lack the detail necessary for adequate understandability and usability. When a generic standard is mandated or selected, this tailoring may take the form of supporting or companion documents when actual modification of the original standard isn't feasible or desirable.

The staff who will be using the standard need to be prepared for its introduction and use, and for the necessary transition from current practice. A transition plan and user training are needed. When these are developed, involvement of the users will yield a more effective and acceptable program. At a minimum, the training should include:

To support the standard during use, plans should be made to provide a "center of expertise" for the user's technical support. This is a person or group to whom a user can turn when questions arise as to how the standard should be applied in practice. This center of expertise is a natural place for developing the tools, techniques, and procedures necessary to make the standard's use routine and habitual. One of the easiest ways to assure consistent use of a standard is to instantiate its use in a tool. For example, coding standards are supported by tools which format code and check for common errors, and standard testing methods assisted by tools that analyze the flowgraph or execution of a program.

A final aspect in planning for use is to develop those validation procedures necessary to measure compliance of practice to the standard. Often those tools developed to help the user can be used to monitor the consistency of a standard's use.

3.3 Introduction and Use

Once plans are made for the users' training and the standard's transition into use, introduction of the standard can begin. The training activity should be a cornerstone of this introduction. The standard's rationale, purpose, and application need to be communicated to the users and their managers. Remember that the training need doesn't end after introduction, for as new staff is brought into the project they need this to adequately perform their tasks, and as managers change responsibilities this information is good background.

As the standard begins to be used, the "center of expertise" should be ready to provide the necessary technical support. Questions will need to be answered, cases of ambiguous application resolved, and actual initial use closely monitored to ensure appropriate and consistent interpretation. The need for support will probably be at its greatest during the transition phase; it should decline to a much lower steady-state level as the standard becomes integrated into accepted practice.

During the standard's ongoing application, compliance to the standard needs to be measured and ongoing motivation for use provided. Classically, motivation can be maintained by directly integrating some measure of use into an organization's reward structure. Other less direct methods also exist, such as visibly reporting summary data of compliance reviews and maintaining awareness of a standard's value during peer-group meetings.

3.4 Improvement Based on Feedback

After the standard has been through a period of stable use, the standard and its support environment should be evaluated with an eye toward improvement of them both. Are the standard's goal and purpose still valid? Is the expected benefit being realized? Based on recent experience, how can the standard be revised to be made more effective? Are tools envisioned that could automate a standard's application or reduce the effort called for by its use? How can the support environment be improved? The standard's implementors, users, and their managers should all be involved in this evaluation, for each brings their own distinctive perspective.

When improvements to the standard or its application environment are implemented, the changes should be controlled and integrated in an orderly way. Periodic evaluations and modifications should be planned, and separated by intervals of use long enough to gain sufficient experience with the revised methods. As the standard is revised, the training, examples, tools, procedures, and compliance measures also need to be updated to reflect the revisions.

One final plea comes from those of us who write standards which others use in their work. When a standard has been selected from those already written and experience provides insight into ways it can be improved, please share the problems and improvements with the standard's originating organization. This further information can be folded into future revisions of the parent standard.

4. Acknowledgements

I'd like to thank all those who participated in the SESAW discussion session from which this paper arose. It is through our collective experiences, shared and discussed in sessions such as this, that our profession grows and we all become so much the wiser.

5. References

[1] Proceedings of the Third Software Engineering Standards Applications Workshop, October 1984, IEEE Computer Society Press, Silver Spring MD, p. 27.