Measurement Program

Integration of Existing Policies, Processes, and Procedures

The separate process improvement initiatives in an organization are likely to have developed separate processes and procedures. Some organizations have written their policies, processes, and procedures to map directly to their process improvement model (e.g., CMM for Software, CMMI, SA-CMM), so one of the negative side effects of different process improvement models has been an incompatible set of policies, processes, and procedures. To resolve these problems, we offer the following questions and suggested approaches. ^[1]

Questions you should ask regarding your process- related documentation include:

• Do your current policies cover your selected CMMI scope?

• Do you need more detailed procedures?

• Do you have overlap in your procedures?

• What procedures should be merged?

• What procedures should remain separate?

Here are some suggested approaches.

Collect and Review the Policies, Processes, and Procedures

The first thing you need to do is collect, in one place, all the documentation that makes up your policies, processes, and procedures and conduct a review. Hopefully it will be as easy as it sounds. Make sure you have a good working definition of policy, process, and procedure: if in doubt, refer to Chapter 14 for documentation guidelines (this was written by one of the most intelligent people I know). Not everything you find will be labeled correctly. For example, we have seen lots of documents with the title "Process for X" that are really policies stating that you are expected to do X. These documents may still be helpful. Also look at your training courses ” sometimes a process or a procedure is only documented in a training course. (Note: We do not recommend only documenting processes and procedures in training courses; however, we recognize that it happens.) Identify the correct title, author, change authority, and sponsor of all documents. Create a document log with all the above information. Conduct a review and record your findings. Use the questions above and the rest of this section to give you ideas on what to look at.

Examine the Interfaces

Examine and consider the interfaces between procedures to ensure that artifacts produced in one process satisfy the requirements of the receiving process (e.g., Systems Requirements flowing into Software Requirements, Systems Requirements into Acquisition, and Software Requirements into Acquisition). Each of these processes represents a producer and a consumer part. The producer needs to provide part of what the consumer needs to do their job. What can be done to make your interfaces clearer and more productive? In one organization we worked with, the addition of a formal design review step between the Systems Requirements and Software Requirements improved not only the artifacts, but also the working relationship between the groups. It also resulted in savings of a staff year for a 15-person project.

Review the Roles

Review the roles people perform and the various disciplines within your organization. For example, configuration management and quality assurance often perform similar roles. These two disciplines (Quality Assurance and Configuration Management) exist at both the systems level and the software level, perform similar activities regardless of the discipline, and may or may not be performed by the same individuals. Can your procedures for these roles be improved by sharing ideas? For example, in most organizations we work with, the software quality group has much more experience in reviewing and auditing processes and the systems quality group has more experience in reviewing and auditing products ” sharing best practices has proven useful.

Consider Life Cycles

Consider the life cycle of the disciplines and scope of the procedures. Systems procedures may cover total life-cycle "lust to dust" (i.e., conception through to disposal), yet software and acquisition-related procedures may only cover the requirements phase to the test phase. How do these different life cycles affect your procedure integration? One example: some organizations find that systems engineering has a better technique for understanding customer needs and expectations. This technique can be borrowed and reused in software-only systems.

Consider the Level of Detail

Consider the level of detail of the written procedures. Some disciplines may have written procedures to just "pass the test" and be at such a high level that they provide very little value. Some disciplines, such as purchasing, may have developed detailed procedures and supporting checklists that help provide a repeatable and improvable activity. Now may be the time to leverage more practical process architectures and procedural approaches from other disciplines.

Consider the Format

Consider the format of the documentation you have produced, that is, process-related internal documentation, and the documentation you turn over to your user . Again, now may be the time to implement consistent process architecture, formats, and styles.

Exhibit 2 contains an example of what you might find existing across an organization. This example is based on documentation we have reviewed from organizations in the past. The three rightmost columns indicate the disciplines of systems engineering, software engineering, and acquisition (or purchasing). Key characteristics for each discipline are identified in the policies, processes, and procedures in the left-hand columns .

Exhibit 2: Example Characteristics of Policies, Processes, and Procedures by Discipline

	Systems Engineering	Software Engineering	Acquisition (or Purchasing)
Primary Standard	Systems Engineering Handbook: Focus on engineering practices Based on unique customer requirements and best practices from the organization	Organizational Standard Software Process: Focus on project management practices Based on best practices and Project Management Institute	Buyer Guidelines: Focus on open market acquisitions Based on government regulations, unique customer requirements, and corporate guidelines
Level of Tailoring	Very little tailoring allowed; requires contract change	Some tailoring done on most projects	Tailoring expressly forbidden
Process Architecture	Based on waterfall life-cycle phases plus unique phases for internal research and development	Based on CMM for Software Key Process Areas	Based on roles in acquisition process
Level of Detail	High-level process descriptions	Level of detail varies by process area: Detailed management processes High-level engineering processes	Very detailed guidelines with checklists
Review Approach	Formal reviews (with customer): systems requirements review, preliminary design review, critical design review	Internal peer reviews (some involve systems engineering and acquisition participants )	Process execution review by managers; technical details reviewed by engineering; all activities audited by customer
Configuration Control	Data management for all formal work products: plans, drawings, specifications, and prototypes	Configuration management procedures around change control boards and software library	Contracts library with limited access containing specifications, requests for proposals, proposal responses, contract and contract status, vendor performance and preferred vendor lists
Quality	Verification and validation by third party or with external witnesses	Both product and process review, emphasis on process assurance	All activities audited by customer or third-party representative

 

^[1] Chapter 16 is our "meat and potatoes" chapter on policies, processes, and procedures that will give you more details on some of these concepts, along with Chapter 14 that discusses documentation guidelines.