You are here: Customer
Council-> Promoting Customer Requirements
Procedures to Promote Customer Requirements
(draft, March 21, 2001)
Purpose
These procedures describe the context and operational policies of the Customer Council
with regard to the identification, clarification, endorsement, and tracking of issues,
problems, needs, and opportunities (to be described collectively as requirements)
which from an IT customer's perspective
- can demonstrably improve the efficiency and/or effectiveness of IT utilization in
industry
- can be addressed at least in part by Open Systems collaborative efforts, such as those
within The Open Group's current or potential scope of operations.
An important part of the mission of the Customer Council is to identify customer issues
and promote their resolution. This document explains some of the ways that this is done.
The Customer Council charter mentions functions, such as:
- Raising, discussing, and initiating action on items of general interest.
- Defining, analyzing, and endorsing Open Systems requirements for consideration by The
Open Group.
- Identifying pervasive trends, issues and opportunities across all of The Open Group
activities, and prioritizing the best opportunities for consideration.
Why?
These procedures are documented here for the
guidance of Customer Council members, to help members communicate effectively and build
consensuses efficiently. These procedures are not mandatory. They are not confining or
constraining. Members are free to extend, alter, or improvise, as appropriate, to promote
any good ideas that they may recognize.
It is hoped that the understanding and use of
these procedures by Customer Council members will help add continuity, substance, and a
sense of mission and urgency to the activities of the Customer Council.
Measuring Success
The Customer
Council is not an organization in the traditional sense. The success of the Council's
activities is difficult to measure.
Although the
Council can introduce and support ideas that turn into collaborative initiatives, it, per
se, is not responsible for delivering solutions.
The best Council
meetings are not necessarily the ones in which the attendees are entertained, educated,
etc.
A good measure of
Council success is a continuing belief on the part of customer members that the Council
did make a contribution to the identification, clarification, and resolution of issues
(requirements) that are meaningful to customers.
Relationship to The Open Group
The
fundamental relationship between the Council and The Open Group is that the Council is an
ongoing association of Open Group members who try to make both The Open Group and their
membership investment in The Open Group more valuable through Council interaction and
activities with the rest of the organization.
There is
no formal way for the Council to compel The Open Group to take specific actions, or for
The Open Group to compel the Council to take specific actions.
Both The
Open Group and the Council, however, value highly the work of each other, and take
seriously under consideration any recommendations or endorsements passed from one to the
other.
Thus,
not all ideas and initiatives taken up by The Open Group (or its Forums) come from the
Council. Similarly, not all ideas and recommendations from the council are directed at The
Open Group (or its Forums) for action.
This
relationship is specialized with respect to the Open Group Forums as one of shared
membership, shared interests, etc. but without absolute dependencies.
To
enhance these relationships, Council liaison positions exist with each Forum
(Forum/Work-Area Representatives), and elected Council representatives have seats on The
Open Group Board of Governors.
Requirements Come in All Shapes and Sizes
The term requirements is used here as a catch-all phrase for a wide variety of
ideas, problem, and opportunities. For our purposes, a requirement is a statement of the
form: Industry's use of IT would be better if such-and-such change [addition,
subtraction, modification] could be achieved.
Requirements can:
- be problem oriented or solution oriented
- be targeted at a specific action or not
- be precise or fuzzy / ambiguous
- be complete or partial
- be linked with named technologies, products, processes, etc. or not
- be detailed or not
- be consistent with other statements of requirements or not
The Council is not in a position to limit the expression of a requirement. The
procedure for identifying requirements tolerates all kinds. The primary goal is to bring
all contributed ideas in front of the Council. Sorting, sifting, and improving can be done
after ideas are first proposed and accepted.
Policies
Policy 1. Valuable requirements items can originate from many sources and may be
presented in many forms. Therefore, the Council will accept new requirements items from
any Council member with minimal screening criteria or initial editing.
Policy 2. Requirements items will attract interest, participation, and endorsement from
Council members in proportion to their inherent value as long as they are clearly
expressed and widely communicated. Therefore, (a) the Council will record all items and
make them Web accessible; (b) the Council will ensure clarity through an edited,
up-to-date description and links to supporting material for each item; (c) the Council
will track actions related to each item, including actions at Conferences, by Council work
teams, or by other relevant groups.
Policy 3. Requirements items that are dormant for a period of nine months will be
considered as candidates for withdrawal. If after three additional months, substantive
action is not taken on such an item, the item will be withdrawn and archived.
Policy 4. The Council will prepare a quarterly report on the inventory of current
requirements items. Discussion of the report contents will be revisited during each
conference meeting. The report will highlight the items that particularly need imminent
Council action, e.g. endorsement, participation in a work team, etc.
Policy 5. The Council is not a standing body with a formal organization structure.
Therefore, Council endorsement will be achieved through a simple majority of attending
member organizations voting at a meeting. Alternatively, a simple majority of voting
member organizations in a pre-announced electronic vote over a voting period of not less
than three weeks will constitute endorsement. In each case, a majority of Yes votes to
total votes (Yes, No, Abstain) is required. Council votes do not constitute official
positions of The Open Group or its member organizations. References to vote results should
be written in the form "The Open Group Customer Council endorsed such-and-such in a
meeting / electronic vote held on such-and-such date".
Policy 6. Diverse opinions are valuable and welcome. Therefore, comments and
recommendations pertaining to requirements items from any Council member will be accepted
and recorded.
Policy 7. Besides unsolicited new requirements items from Council members, the Council
will regularly seek out new requirements items from sources, which include Open Group
plenary sessions and Open Group Forums. Items from Forums may represent requests from a
Forum for Council action (e.g. endorsement, document review, questionnaire completion) or
may identify a so-called roadblock, i.e. an existing Open Systems specification/standard
that is not being taken up in industry as had been anticipated.
Policy 8. The Council will encourage parties interested in an item to identify one or
more Champions for the item. The Council will keep a record of Champions (and their
contact information) to simplify communication about the item. It is recognized that
substantive progress on an item is very difficult without at least one Champion who is
driving the needed work towards a resolution.
Policy 9. Although requirements items can be expressed in many ways, there are a small
number of typical steps and criteria that items follow leading to a state of completion.
The Council will maintain a list of these steps and criteria, which will be updated over
time as warranted. A starter-set includes:
- Tangible use cases in an industrial setting and associated business bottom-line
benefits.
- Illustrative architectural material, including target environment components,
interfaces, etc.
- Demonstrable customer interest - within and beyond the Council itself.
- Software supplier analysis, including effects on product lines, market opportunities,
etc.
- Demonstrable supplier interest - within and beyond the Supplier Council.
- Development plans for the necessary common vocabulary, specifications, etc. - whether
done collaboratively in an existing or new Open Group activity or elsewhere.
- Response (accept, under consideration, or other) from The Open Group to a well-formed
proposal based on the developed requirements item.
Policy 10. Although it is possible to track a requirements item all the way until
commercial solutions are available and deployed in industry, requirements items will be
considered closed as soon as a path forward has been formulated and accepted by The Open
Group or other groups. Subsequent issues may call for new requirements items to be
submitted and tracked.
Policy 11. As items are refined and considered, items may be withdrawn in favor of
newly submitted items. This can be done by the originator up to the time that a Council
endorsement for the item is achieved and can be done by majority vote of the Council at
any time. In some cases, one item may be replaced by many. In other cases, many items may
be replaced by one.
Policy 12. It is the responsibility of the Open Group Forums to manage their own
resources, commitments, and work plans. Therefore, the Council will cooperate with
Forums/Work-Areas in refining and developing requirements items into actionable work
proposals, but the Council will not accept responsibility for preparing detailed work
proposals for submission to those Forums/Work-Areas. Similarly, the Council will work with
The Open Group on strategic objectives, but the Council will not prescribe requirements
items as strategic objectives for The Open Group.
Customer Council Requirements Journal
For the present time, requirements items are being recorded and tracked in a
spreadsheet form. More sophisticated means of recording and viewing the journal will be
considered for the future.
The journal will be physically managed and made Web accessible by The Open Group.
New entries (whether for new or existing items) should be sent by e-mail to journal-entry@opengroup.org or
ogcc_steering@opengroup.org . The Open Group will check the entry for basic
understandability and completeness and will work with the submitter to correct or enhance
the entry, as required.
A subcommittee of the Council steering committee will have 3 work days time after the
entry is deemed understandable and correct to raise any issues concerning the suitability
and clarity of the entry. If no substantive concerns are raised the entry will be added to
the journal.
Items that become candidates for withdrawal due to inactivity for nine months will be
so marked by The Open Group. Items that are being withdrawn after an additional three
months of inactivity are archived, leaving a short reference behind in the journal. Items
withdrawn intentionally are archived after a period of three months.
Each entry for a new item requires the following information:
- Item # - unique identifier assigned by The Open Group
- Item Id - identifier assigned by the submitter.
- Item Title - a short description of the essence of the problem or opportunity.
Each entry for an existing item requires the following information:
- Item # and Item Id - to match to the existing entries.
All entries require the following information:
- Entry Date - the date that the entry is recorded (after verifying completeness and
understandability).
- Entry Comments - a paragraph-length description of the problem or opportunity for new
items - of the action taken for existing items.
- Next Step Recommendations - a paragraph-length description of the next action to be
taken, including who, what, and when.
The Open Group and the Council subcommittee will characterize each item at the time of
each entry according to its stage in the life cycle of a requirements item and in other
ways. The characterizations will be refined as more experience is gained. To begin the
process, these stages have been identified:
- Related to existing standards versus a new industry need
- The fitness for purpose characteristic of the industry processes affected by this item
has been defined or not.
- A focused industry proposal for endorsement has been defined or not.
- Market opportunities for software suppliers have been defined or not.
- A proposal to motivate software supplier participation in the solution process has been
defined or not.
- A program intended to address and resolve this item has been put into action or not.
The Open Group and the Council subcommittee will add references to the Open Group
Forums/Work-Areas as each entry is added. This is intended to enhance communication
between the Forums/Work-Areas and the Council.
Prioritization
It would be helpful if the inventory of requirements items was prioritized to indicate
which items were first, second, and third levels of priority. This, however, cannot map
directly onto work priorities because of the nature of the Council and the fact that
meaningful action on items depends so much on the voluntary efforts of individuals and
groups (inside and outside of The Open Group).
A means will be found to approximate a prioritization by assessing the magnitude and
urgency of items along with the likelihood of achieving a satisfactory resolution. As a
first proposal, the basic feedback scheme used by The Open Group can be adapted, as
follows:
- Importance: Score from 1 to 10. Suggested quantitative or qualitative meanings will be
developed for the score values, possibly with illustrations from past standards
development work.
- Satisfaction: Score from 1 to 10. Suggested qualitative meanings will be developed. For
example, 10 means a 100% sure bet for resolution. a 1 means a 10% chance of resolution.
These factors will be assigned by The Open Group and the subcommittee, subject to
review and voting from the Council, as necessary. |
