10 Define Standard Process
We gain the advantage by doing things before they need to be done—positioning ourselves ahead of time in the best place. Those who think ahead of the approaching action will have the advantage. They will be the winners.
—Wynn Davis
An organization that is expending resources to ensure product quality knows that its product is only as good as its process. A standard process is a minimum set of procedures defined and approved for use by an organization. It is like the script in a drama class because it synchronizes the sequence of activities. Each person is given the same script, but everyone has a different role to play. A role may be assumed by one or more individuals. Having a defined process allows us to follow a written script and organize into clearly defined roles. As we execute the defined process, we know who is playing each role, and we can work together more efficiently. In software development, there are no dress rehearsals.
A software engineering process group (SEPG) should have a defined process for process improvement [Fowler90]. An SEI Level 1 SEPG cannot guide an organization to SEI Level 2 and beyond because its methods will be ad hoc. An SEPG needs a script for process definition. The SEPG is itself an action team that can help to structure the improvement organization, develop top-level action plans, and define the process of process improvement. Then other action teams can be established to achieve action plan goals. Each team established to improve a process needs the process definition script to be successful in meeting its objectives. Following this script, the output of all the actions teams will be in harmony, because the detailed work flows from one master design.
In this chapter, I explain the process of process definition. I describe how to establish an action team to define a reusable risk management process for your organization.
This chapter answers the following questions:
What are the activities of the process definition process?
What does a high-performance team have that other teams do not?
Why is a process definition notation important?
10.1 Establish an Action Team
The risk management process action team should have cross-functional membership because the diversity of various engineering and management disciplines provides a wealth of experience the team can draw on. Individuals should represent both large and small projects and various product lines. Organization members who want to participate should be recruited and given a charge number to track effort.
The key to establishing an effective team is understanding three important team concepts:
A team is not a group. Groups communicate; teams collaborate. Communication is the exchange of thoughts or information. Collaboration occurs when two or more individuals with complementary skills interact to create a shared understanding that none had previously possessed or could have come to on their own [Schrage90]. Team members must collaborate to solve problems under constraints.
A team is task oriented. A team is brought together to achieve specific goals. An effective team commits itself to achieving those objectives. Team members have a sense of shared purpose. When the objectives have been met, the team celebrates their accomplishment and disbands.
A team matures over time. As the task evolves, the team roles also evolve. Consensus is the decision-making process of a mature team. It ensures that everyone can live with the decision. In spite of obstacles, growth and progress are made. The process for working together is refined over time.
Task orientation demands the assignment of team roles. Team members may be assigned one of four roles on a rotating basis:
Leader. The leader ensures the clarity of the task requirements; sees to it that the team has adequate resources to complete the task; guarantees deadlines and the quality of deliverables; clarifies team roles and responsibilities; coordinates meeting time, location, and agenda; and is responsible for improving the team’s performance. The leader’s team notebook is the master copy and is maintained in the organization’s technical library.
Facilitator. The facilitator manages the decision-making process, encourages participation of all team members, keeps the team discussion focused, keeps track of the time and the meeting agenda, and can remind the team of constraints, such as the time remaining. The facilitator may also be a participant, and all team members may act as secondary facilitators.
Recorder. The recorder provides a team memory. He or she keeps notes of ideas, decisions, and working procedures; generates and distributes meeting minutes in a timely fashion; and documents essential facts and synopsis without editorializing.
Participants. Participants become fully involved in discussions. They contribute ideas, seek clarification to avoid misunderstanding, and help the facilitator keep the team on track.
As the task evolves, so will team roles [Scholtes88]. A team matures over time in four stages:
1. Forming. The team sets the ground rules for operation. They define their mission, task, and requirements and determine what behavior is acceptable and how much they are expected to do. Relationships for working within the team are established.
2. Storming. Some team members value their individuality over the identity of the team. They may ignore goals set by the leader and resist the requirements of the given task. When individuals do not conform to team rules, their behavior results in conflict and struggle.
3. Norming. As team members develop closer relationships with each other, new standards of conduct for operation of the team develop, and members adopt new roles within the team. The team is now capable of using consensus as a method of making decisions. A consensus process requires team members to share information and openly discuss their views. Issues are ranked to focus the discussion on possible decisions for dealing with the issues.
4. Performing. When the team is performing, issues are resolved, progress is made, and goals are achieved.
10.1.1 Build a High-Performance Team
High-performance teams have been created by beginning with an innovative workshop that trains in the basics of teamwork, problem-solving methods, and using data to achieve a goal [Janson95]. There are other important factors as well:
A shared compelling vision. A high-performance team is results oriented. The members share a common vision and have positive expectations of achieving success. Have your team brainstorm a vision statement, such as “No surprises.” Take several photographs of what that means to use risk management to prevent project disasters: a smiling customer, a clean lab environment, or an impressive demonstration at a trade show.1
1 A picture is worth a thousand words. We process a picture using our nonverbal right brain, which stimulates both emotion and imagination.
Individual accountability. Each person contributes through clearly defined roles and responsibilities. There is a sense of pride in belonging to the team. There is ownership and accountability for the product. Commitment is a by-product of accountability.
Synergy in collaboration. Team members are open to new ideas. They appreciate the diversity that the team is more than the sum of the individual members. Conflict and disagreement is a natural process that is handled with mutual trust and respect for each person. The team decides by consensus. Although decisions using the consensus process initially take longer to reach, once the decision is made, less time is spent resisting it, and real progress is made.
A high-performance team has the following characteristics:
Working on the team is fun.
More is accomplished than thought possible.
Ego and blame are replaced with commitment.
Conflict results in breakthroughs.
The team shares a sense of empowerment.
How will you know if you manage a high-performance team? The view from outside a high-performance team has the following characteristics:
Seamless operation as a team.
Accomplishment without visible effort.
Unwavering commitment.
Accountability for action as a norm.
Little or no direction required.
Your team can evaluate itself on the following characteristics of team excellence, rating itself on a scale of 1 to 5:
A clear, elevating goal.
Principled leadership.
Unified commitment.
Collaborative climate.
Results-driven structure.
Standards of excellence.
Reward and recognition.
10.1.2 Organize the Team for Success
The team leader should be responsible for creating team notebooks to be given to each team member at the first organizational meeting. There are several advantages for each person’s maintaining a notebook:
Team members stay on track better when they know the path to completion.
Process definition is reinforced through notebook tabs that serve as placeholders for the remaining work.
If an individual leaves the team, his or her notebook is passed on to the new team member.
Notebooks serve later as a handy reference that can be checked out from a technical library and used to educate others.
Notebooks can be used in process assessments to verify work in progress.
The team notebook includes the following sections:
Action plan—the task requirements, budget, and schedule given to the team leader by the organization, and team goals and products to be delivered.
Action team interfaces—a diagram that illustrates how the action team operates within the context of the organization defined for software process improvement (see Figure 10.1).
Member directory—the names and contact information for all team members.
Activity log—a one-page journal for team members to capture the date, time, and activity they performed using the action team charge number.
Meeting rules—the team operating principles. An example of guidelines for team meetings is shown in Figure 10.2.
The agenda for the first meeting of a risk management process action team should include the following activities:
1. Introduce team members. Once a cross-functional team is gathered, personal introductions can be made. Getting to know individual strengths is the first step to understanding the talent represented in the group, the action team’s greatest resource. Introductions should be interactive. Take the time to get acquainted by pairing up, interviewing, and introducing one another. Another way to introduce team members is for groups of three to discuss themselves (e.g., name, background, current position, and special interests). Stage introductions of individuals to the entire team using two people who dramatize meeting the third.
Figure 10.1 Improvement organization. The action team operates within the context of the organization defined for software process improvement.
Figure 10.2 Team ground rules. Teams establish rules of order to ensure productive team meetings.
2.Clarify team goals. The purpose of the team’s existence is to define the standard risk management process for the organization. The deliverables are the process definition and supporting mechanisms. The team should agree on a clear statement of purpose of what is to be accomplished. In order to agree on the team’s success criteria, have each team member finish the following sentence: “Our team will be successful if…” Arrange the responses in a purpose hierarchy, from general to specific. Achieve consensus on which statement best describes the scope of the action team.
3.Review the action plan. Develop an understanding of what has to be done and when.
4.Agree on operating principles. The ground rules for working together can be a brainstorming exercise by the team members. Ten rules are sufficient, and they can be prioritized in order of importance to the team.
10.1.3 Level the Playing Field
After the team is organized for success, there should be an educational meeting to level the playing field. This is important to ensure that everyone begins work with a common understanding of the vocabulary that will be used. Basic knowledge required to execute the action plan is established. Skills required include consensus, process definition, and risk management concepts. The team can be trained using videotapes, audiotapes, or a guest lecture. The team members can review a portion of the material and then present it to the team. To educate the risk management action team that I led, I invited the team to a risk management movie [Charette91], complete with popcorn and sodas. I also presented a risk analysis tutorial given by the Air Force Institute of Technology as part of an introduction to software engineering [AFIT92].
10.2 Develop the Draft Standard Process
A draft standard process is an important product for the action team. The draft is a brief overview of the final product, which is reviewed for understanding and consistency. It provides a sense of accomplishment early on that can serve as a catalyst for completion. There are four steps to develop the draft standard process:
Figure 10.3 Idef0 Process Design Notation. Process Elements Are Described By Idef0 Using Inputs, Outputs, Control, And Mechanisms.
1. Select a process design method.
2. Gather the risk practices data.
3. Scope the effort and products.
4. Define the draft standard process.
10.2.1 Select a Process Design Method
There are several process design methods that can be used as is or with modifications. If your organization does not already have a methodology, you may want to combine features to create your own process notation hybrid. There are three good process design methods:
IDEF0. The basic building block of the IDEF0 process definition method [AirForce81] is shown in Figure 10.3.2 Process elements are connected to make a more complex process definition. Using IDEF0 is systematic and easily understood and implemented. (IDEF0 was used to define the risk management process in Part II.) There are extensions of IDEF0 that focus attention on the tools and information that support the processes. A parallel information modeling standard, IDEF1X [AirForce85], has been used to transform information requirements into physical database schemas [Hsiao95].
2 IDEF0 is a function modeling standard established in 1981 for defining manufacturing processes. It has become the standard definition methodology for business process models.
Figure 10.4 Etvx Process Design Notation. Process Elements Are Described By Entry Criteria, Task, Validation, And Exit Criteria (Etvx).
ETVX. The ETVX method describes a process in terms of entry criteria, task, validation, and exit criteria. As shown in Figure 10.4, ETVX explicitly calls for the validation of activities prior to task completion [Tomayko91].
The 3 R’s. Role, responsibility, and resources are the 3 R’s described by a business engineering approach developed by David Taylor [Taylor95]. As shown in Figure 10.5, customers and suppliers, both internal and external, are addressed. The approach is based on modeling roles that encapsulate responsibilities and resources associated with the role. Roles decompose hierarchically from general to specific. At each succeeding role level, responsibilities and resources are more specifically defined. Solutions are developed from recursive design, construction, and test of requirements mapped to responsibilities and resources.
10.2.2 Gather the Risk Practices Data
There are numerous sources of information on risk management practices. Your team should gather information and write a bibliography of the sources you will use. Three categories are especially useful:
Company practices. Information on the current state of your practice. Policy, process guidebooks, process assessment findings, and project practices should be collected and catalogued in the team notebook.
Industry data. Information on the current state of other organizations. Conferences, training seminars, books, tapes, and articles provide information on the state of the practice in other organizations.
Standards organizations. The ideal model, considered “best practice.” The IEEE standard for software project management plans identifies risk management as a managerial process [IEEE88]. The INCOSE Systems Engineering Capability Assessment Model (SECAM) contains a key focus area for risk management [INCOSE96]. Risk management practices are embedded in key process areas of the SEI CMM for Software [Paulk93].
10.2.3 Scope the Effort and Products
Understanding the difference between the action team’s objectives and the organization’s current practice will help the team to scope its effort and products. To properly scope its work, the team should consider the risk of defining scope incorrectly.
Figure 10.5 The 3 R’s Process Design Notation. Process Elements Are Described By The 3 R’s: Role, Responsibility, And Resources.
A procedural change has a narrow scope. The degree of change may be an incremental improvement in an existing procedure. Small adjustments within existing functions are made. The philosophy may be, “We can do better.” The risk is lower, but the percentage improvement may be small as well.
A change that is structural or cultural has a broad scope. The degree of change is radical. Sometimes there is a large degree of desired change from “as is” to “should be.” We may start with a clean sheet of paper to define a new process. The philosophy may be, “We know what does not work.” The risk is higher, but the reward may be greater.
How much change is acceptable within your organization? Depending on your constraints of budget and schedule, you can refine the action plan. Adjust the scope of team goals using the purpose hierarchy (developed in section 10.1.2) in order to meet your constraints and ensure success. Decompose the work into task assignments for the team members. Are the team members able to commit to their task assignments? If they cannot, that is another reason to de-scope. It is acceptable to challenge your team, but there is no reason to bite off more than you can chew.
Recognize that there is flexibility in the level of process detail the team will provide. For example, there may be phased upgrades planned, where version 1.0 addresses software projects and version 2.0 addresses system-level risk management. Reach consensus within the action team on product scope.
There are three intermediate work products that are produced to help bound the task. A product scope review checklist (see Figure 10.6) can be used to ensure the completeness of the following work products:
Draft outline. Define the outline like a table of contents that contains the topics in the order that they will be covered. Describe the goal, objective, purpose, and context.
Product scope. Define the process as a “black box,” with input and outputs only. Define the process entry criteria and prerequisite conditions or products needed to start the process. Define the process exit criteria and verification criteria needed to end the process.
Process diagram. Draw the process using the standard process notation.
10.2.4 Define the Draft Standard Process
When the task and work products are properly scoped, a draft process is written. There are several common improvement themes to consider in designing the process activities:
Reduce bureaucracy. Remove unnecessary approval cycles and paperwork.
Eliminate duplication. Remove steps that are repeated.
Add value. Assess whether the activity serves the customer’s requirements.
Minimize errors. Make it difficult to introduce an error during the activity.
Standardize. Select a single best way to do the activity.
Automate. Use computers for routine or repetitive tasks.
The draft process is like a storyboard, with themes and figures that show both content and sequence of activity. There are three intermediate work products that are produced to generate the draft standard process:
Annotated outline. Develop the structure of the document by writing one or two sentences under each heading that describe what the section will contain.
Process description. Define the activities of each process element at a high level to describe the work flow.
Identify mechanisms. List the methods and tools used by each process element.
Figure 10.6 Product Scope Review Checklist. Items Are Reviewed According To Compliance Criteria Using A Product Scope Review Checklist. The Reviewer Signifies Acceptance Of Each Review Item By Writing His Or Her Initials In The Space Provided.
10.3 Review the Draft Standard Process
When the draft process is defined, the team members review the product in its entirety. A meeting is scheduled to discuss individual team members’ comments and suggested changes. When the draft standard process is documented, it should be sent out to a large group of reviewers. Some reviewers may not have time to respond, but at least they will have the opportunity to do so.
10.3.1 Prepare the Review Package
The distribution list should be checked to ensure coverage to represent the organization projects and levels of hierarchy. The material should be packaged with a review form that identifies the product under review and the current level of completeness. A checklist should be included in the review package to guide reviewers. Distribute the review package at least one week prior to the review meeting.
10.3.2 Review the Draft Standard Process
The draft process is reviewed for content and focus. Major issues that reviewers wish to change or discuss at the review meeting are recorded on the review form. Corrections should be made in the review package.
At the review meeting, reviewers bring their comments and discuss their suggestions. Corrections are submitted to the action team with the completed review form. All major issues are discussed and resolved as action items. The team recorder captures specific decisions reached on key issues and documents action items of what to change. For each action item, a determination is made as to whether a re-review of the altered product is required. At the meeting, an individual is identified to serve as the review team leader. This person will closely evaluate all incremental action team work products to gain the insight necessary for future selection and leadership of the final product review team.
10.3.3 Incorporate the Recommended Changes
Reviewers’ corrections will be incorporated into the product. The action team prioritizes the list of action items documented at the review meeting and determines which changes are feasible. When the team incorporates these changes, the action items are closed. Some suggestions will be good improvements but may need to be incorporated in future versions due to resource constraints. Action items in this category are carried forward.
10.4 Document the Standard Process
The standard process is an elaboration of the draft standard process, with examples added to increase understanding of the process. To assist process improvement, a change request form is part of the standard process documentation.
The action team may choose to use or reengineer the risk management process documented in Part II of this book. It may be easier to begin with a guide and suggest changes. When your work builds on existing work, be sure to cite your references. The purpose of defining a standard process for an organization is to own the process and thus avoid the “not-invented-here” syndrome. Spending three months (part time) defining a standard process is a small price to pay for the ability to leverage it on all projects.
10.4.1 Elaborate the Draft Standard Process
If the draft was properly decomposed, there should not be any new headings in the outline. After team members elaborate the draft standard process to the next level, they may uncover errors of omission in the draft outline. A process diagram will help to illustrate major process elements that can be described in the standard process definition. Document the detail in each section, and add examples as required.
10.4.2 Evaluate the Standard Process
The action team leader and the product3 review team leader coordinate an evaluation of the standard process. A subset of reviewers (typically three or four) is selected based on their experience and position in representing the organization’s business areas or product lines.
3 In this case, the process is a product.
A comprehensive review of the product is guided by a review checklist. The documentation should be consistent with other standards governing process specification. The process is evaluated in the following areas:
Implementation of approved organization policy.
Compliance to action plan.
Compliance to product standards.
Overall quality and usability.
The review team leader meets with the action team leader to discuss the evaluation findings. The actions necessary to resolve the issues are documented. As a guideline, if more than 25 percent of the product is changed, another evaluation is recommended.
10.4.3 Close the Action Items
Review team comments are incorporated into the final product. A brief response for each issue is prepared to indicate what specific changes were made. Action items not addressed are carried forward as open items.
10.5 Approve the Standard Process
The action team leader presents the standard process to the organization by sending the final document to those with signature authority. After the process is approved, the team should be recognized by management for their achievement. Recognition does not have to be expensive, but it must be timely to create a strong association between work and reward. Closure of an action team that collaborated on an approved standard process is cause for celebration.
10.6 Distribute the Standard Process
The action team leader is responsible for ensuring that the approved process is distributed within the organization. New processes should be pilot-tested and have a limited distribution until proved on projects. For a new process, associated training material should be given to the training department. For a modified process, updates to existing training material should be provided.
A summary process description may need to be written as a catalog entry in a higher-level guidebook that points to the process. Pointers, hot links, or icons need to be developed to locate the process definition. The leader’s team notebook is catalogued and placed in the organization’s technical library. The process repository may be on-line. Both hard copy and soft copy process definitions should be cross-referenced.
10.7 Summary
In this chapter, I explained the process of process definition. The activities of the process definition process are as follows:
1. Establish an action team.
2. Develop the draft standard process.
3. Review the draft standard process.
4. Document the standard process.
5. Approve the standard process.
6. Distribute the standard process.
I described how to establish an action team to define a reusable risk management process, and discussed what a high-performance team has that other teams do not have:
A shared compelling vision.
Individual accountability.
Synergy in collaboration.
A process definition notation is important because it is a form of written communication that describes a process in shorthand. When the notation is understood, it may be used as a building block to define more complex processes. I showed three good process design methods: IDEF0, ETVX, and 3 R’s.
A purpose hierarchy is used to describe the action team success criteria. I discussed how to adjust the scope of team goals in order to meet constraints and ensure success. While a procedural change has a narrow scope, a change that is structural or cultural has a broad scope. Teams must understand the risk and reward of defining too narrow or too broad a scope for their effort and products.
I listed several common improvement themes to consider in designing process activities:
Reduce bureaucracy.
Eliminate duplication.
Add value.
Minimize errors.
Standardize.
Automate.
10.8 Questions for Discussion
1. Symbolic metaphors help you gain different perspectives. Discuss how a defined standard process is like the script of a play. Explain how you would improvise the standard process “script” on a specific project.
2. Define the process of process improvement. Include an organization, action plan, and process notation. Explain how this process helps project teams.
3. Discuss the concept of diversity on process action teams. List the advantages and disadvantages of working in a cross-functional team environment.
4. What is the key to establishing an effective team? What is the difference between a group and a team? What is the difference between an effective team and a highperformance team? Do you think it is difficult to sustain a high-performance team? Discuss why you do or do not think so.
5. One way to clarify team goals is to ask team members to assess the risks of success. Identify and prioritize five risks of defining the organization’s standard risk management process. Describe a mitigation strategy for each identified risk.
6. What does it mean to “level the playing field”? Do you think it is important for an action team to do so? Explain your answer.
7. Compare and contrast two process-design methods. You may select IDEF0, ETVX, the 3 R’s, or another method. Discuss which process design method is best, and why. Can you design a hybrid method that would be better? If so, what improvement would your approach have over the current best method?
8. Discuss how scope relates to action team success. List five ways the scope of process definition can be adjusted to increase the chance of action team success.
9. Describe the not-invented-here syndrome. List three possible consequences of this syndrome with respect to a standard process definition. Explain how extensive review of the draft standard process helps to avoid the not-invented-here syndrome. Discuss other ways to prevent the not-invented-here syndrome.
10. What is the advantage to a project if its organization has a reusable risk management process? Estimate the cost savings to the project in terms of budget, schedule, and staff resources.
10.9 References
[AFIT92] Air Force Institute of Technology (AFIT). Introduction to software engineering: Risk analysis. Proc. Software Technology Conference, Salt Lake City, UT: 1992.
[AirForce85] Integrated Computer Aided Manufacturing Architecture, Part II, Vol. V: Common Data Model Subsystem—Information Modeling Manual (IDEF1 Extended). AFWAL-TR-86-4006. Wright-Patterson Air Force Base, OH: Air Force Systems Command, November 1985.
[AirForce81] Integrated Computer Aided Manufacturing Architecture, Part II, Vol. IV: Function Modeling Manual (IDEF0). AFWAL-TR-81-4023. Wright-Patterson Air Force Base, OH: Air Force Systems Command, June 1981.
[Charette91] Charette, R. Risk Management Seminar (video). Software Productivity Consortium. SPC-91138-MC. Herndon, VA, August, 1991.
[Davis88] Davis, W. The Best of Success. Lombard, IL: Great Quotations, 1988.
[Fowler90] Fowler, P, Rifkin S. Software engineering process group guide. Technical report CMU/SEI-90-TR-24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, September 1990.
[Hsiao95] Hsiao D. Project management methodologies: Using IDEF to support a comprehensive business process. Proc. Seventh Software Engineering Process Group Conference, Boston, May 1995.
[IEEE88] ANSI/IEEE. IEEE Standard for Software Project Management Plans. ANSI/IEEE STD 1058.1-1987. October 1988.
[INCOSE96] International Council on Systems Engineering. Systems Engineering Capability Assessment Model (SECAM), Version 1.50, Seattle, June 1996.
[Janson95] Janson J, Piekos J, Warner A. The rise and fall of a high performance team. Proc. Seventh Software Engineering Process Group Conference, Boston, May 1995.
[Paulk93] Paulk M, et al. Capability maturity model for software. Version 1.1. Technical report CMU/SEI-93-TR-24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.
[Scholtes88] Scholtes P. The Team Handbook: How to Use Teams to Improve Quality. Madison, WI: Joiner Associates, 1988.
[Schrage90] Schrage M. Shared Minds. New York: Random House, 1990.
[Taylor95] Taylor D. Business Engineering with Object Technology. New York: Wiley, 1995.
[Tomayko91] Tomayko J. Software Project Management. Academic Series (Lecture 19). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Spring 1991.