Summary

Process Areas for the Maturity Level 3: Defined

Requirements Development

The purpose of Requirements Development is to produce and analyze customer, product, and product component requirements. Specific Goals and Practices for this process area include:

• SG1: Develop customer requirements

  • SP1.1: Elicit needs

  • SP1.2: Develop the customer requirements

• SG2: Develop product requirements

  • SP2.1: Establish product and product component requirements

  • SP2.2: Allocate product component requirements

  • SP2.3: Identify interface requirements

• SG3: Analyze and validate requirements

  • SP3.1: Establish operational concepts and scenarios

  • SP3.2: Establish a definition of required functionality

  • SP3.3: Analyze requirements

  • SP3.4: Analyze requirements to achieve balance

  • SP3.5: Validate requirements with comprehensive methods

SP1.1: Elicit Needs, when expanded to its full name , reads "Elicit stakeholders' needs, expectations, constraints, and interfaces for all phases of the product life cycle," and in the explanatory notes underneath it, states that this practice also includes identifying needs not explicitly stated by the customer.

Requirements Development is where requirements are initially defined and documented. Requirements Management at Level 2 is where changes are administered. Requirements Development gathers requirements and then must usually refine these requirements in some way by stating them more clearly, determining whether they are redundant or inconsistent with other requirements, and breaking them down into more detailed and traceable requirements.

The CMMI uses the terms "Product, Product Component, and Component." Examples of these terms might be that a Product is the final deliverable , such as a jet fighter plane capable of flying and firing missiles. The Product Components might be the navigation system, the fire control system, the fuselage, the landing equipment, and the communications system. The Components might be software to determine the distance from the ground, the software to aim a missile, the control panel, the tires, and the headphones. The manufacture of a communications system may have a different mapping, starting with the communication systems product, radios and antennas as product components, and the receiver, transmitter, and tuner software as components .

This process area introduces the Concept of Operations or, using the CMMI term , operations concept. This document is usually the first document written when determining whether or not to pursue development of a product. It is usually a high-level statement of the desired functionality, and a preliminary plan and schedule for development. This document is then used as the basis for further requirements identification and refinement, as well as project planning. This concept works well in a DoD environment or when attempting to build a highly complex product with many people. However, in the commercial, non-DoD world, these documents are generally not used. This can be a problem when following the CMMI because this document is expected in several practices throughout the model.

Shaded, gray areas are included in the staged representation of the model. These areas document the differences between the staged and continuous representation. For example, SP1.1 in the staged is called "Elicit Needs." The subpractice under the practice describes gathering requirements from relevant stakeholders. The continuous representation has practice SP1.1-1. The "-1" signifies that this practice is a base practice ("-2" signifies that the practice is an advanced practice). SP1.1-1 of the continuous representation is called "Collect Stakeholder Needs." So, while the practices look somewhat different, they really contain the same information they just state it a little differently and use a slightly different numbering system. Please see our discussion of the structure of the CMMI in Chapters 3 and 4.

Beta testing of requirements is mentioned here.

Requirements Development includes collecting and eliciting customer requirements from all involved parties at all levels; breaking down those high-level requirements into lower-level, more detailed requirements, and assigning them to categories for further development; defining interfaces among the requirements and any other areas necessary to fulfill the requirements; more adequately defining and documenting the operational need, concept, scenario, and functionality desired; ensuring that the requirements are complete, required, and consistent; negotiating needs versus wants versus constraints; and validating the requirements against risk in the early phases of the project.

Technical Solution

The purpose of the Technical Solution process area is to develop, design, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product- related life-cycle processes, either singly or in combinations as appropriate. Specific Goals and Practices for this process area include:

• SG1: Select product component solutions

  • SP1.1: Develop detailed alternative solutions and selection criteria

  • SP1.2: Evolve operational concepts and scenarios

  • SP1.3: Select product-component solutions

• SG2: Develop the design

  • SP2.1: Design the product or product component

  • SP2.2: Establish a complete technical data package

  • SP2.3: Design interfaces using criteria

  • SP2.4: Perform, make, buy, or reuse analyses

• SG3: Implement the product design

  • SP3.1: Implement the design

  • SP3.2: Establish product support documentation

Technical Solution implies a complex product requiring a complicated approach. New items included tend to relate to the systems engineering side of the house. A complex system requires more groups and more people. The Technical Data Package is used to coordinate these group efforts, as well as to satisfy procurement interests. The package includes such items as product architecture description, allocated requirements, process descriptions as they relate to products, interface requirements, materials requirements, fabrication and manufacturing requirements, verification requirements, conditions of use, operating and usage scenarios, and decision rationale. That is a lot more than what was recommended by the CMM for Software. In our experience, some of this information can be found directly in the Request for Proposal and the Statement of Work from the customer. Some of it can be found in process documentation within the organization, some in the contract between the suppliers/servicers, some in the Requirements documentation, and some in the Design documentation. Maybe this package is just recommended as sort of a checklist to ensure that the supplier is delivering everything necessary to complete the product. However, if this documentation can be found elsewhere, is the CMMI requiring the project to collect this information and store it in one place? Is this redundant? Would it be better to include this practice in, perhaps, Product Integration?

Technical Solution also expects a formal approach to providing solutions that is, to suggest alternatives and then study them. This approach is beneficial for large systems but probably overbearing for smaller ones. If an organization plans to undertake a new approach to an old problem, to use new technology, or to develop a totally new product, then this approach seems worthwhile. For example, I was once asked to do a feasibility study and alternatives analysis to determine whether using a specific programming language and database should be used to develop a warehouse system for a client. Because the client had already determined that this language would be used, as all of their software systems used this language and converting to something new would require a complete overhaul of all their code for lots of money, the expected outcome was a resounding "yes." This process area may promote a more balanced approach to deriving and evaluating alternatives, although there are always ways to get around the rules.

In this process area, when the model refers to processes, the model generally does not mean process improvement -type processes, but design processes. That is, the processes they are talking about in this process area focus on the technical steps necessary to produce the product. They do not focus on processes used to manage the project or manage the process for Technical Solution or the process used to improve processes in an organization. They are totally focused on engineering the product.

The continuous representation is referred to here by SP1.1-1, a base practice, which is named "Develop Alternative Solutions and Selection Criteria." While the subpractices , at first glance, look somewhat different, the information in them is contained in the staged representation practice SP1.1. Reading the practice documented in the continuous representation may simply give the reader a bit more understanding or information.

Peer reviews are mentioned in this process area. Technical Solution gives the reader some guidance on which products should be peer reviewed (SP3.1 and SP3.2 specifically discuss design and support documentation). The Organizational Process Definition Process Area also includes items and artifacts to be peer reviewed, including the Organization's Set of Standard Processes, life-cycle models, tailoring guidelines, measures, and the project's defined processes (also discussed in Integrated Project Management). We recommend that each process area be read for guidance on which products from each process area should be peer reviewed. For guidance on the steps to follow when planning and conducting a Peer Review, see the Verification Process Area.

Release baselines are presented here, as are unit testing and the operations concept.

Technical Solution includes determining how to satisfy the requirements via analysis of different alternatives and methods; creating operational scenarios; selecting solutions and follow-on designs; generating a technical data package that may include development methodologies, bills of material, life-cycle processes, product descriptions, requirements, conditions of use, rationale for decisions made, and verification criteria; defining and documenting detailed interface information; determining whether to make, buy, or reuse; and implementing the design and generating supporting documentation.

Product Integration

The purpose of Product Integration is to assemble the product from the product components; ensure that the product, as integrated, functions properly; and deliver the product. Specific Goals and Practices for this process area include:

• SG1: Prepare for product integration

  • SP1.1: Determine integration sequence

  • SP1.2: Establish the product integration environment

  • SP1.3: Establish product integration procedures and criteria

• SG2: Ensure interface compatibility

  • SP2.1: Review interface descriptions for completeness

  • SP2.2: Manage interfaces

• SG3: Assemble product components and deliver the product

  • SP3.1: Confirm readiness of product components for integration

  • SP3.2: Assemble product components

  • SP3.3: Evaluate assembled product components

  • SP3.4: Package and deliver the product or product component

SP3.1: Confirm Readiness of Product Components for Integration is expanded to "Confirm, prior to assembly, that each product component required to assemble the product has been properly identified, functions according to its description, and that the product-component interfaces comply with the interface descriptions." The entire practice gives a little more information as to what is expected than the practice label gives to the reader.

This process area is the favorite of one of the authors of this book. Why? Because this is where the product comes together and you get to see the results of your work. It is also where you deliver the product, and that means you get paid.

This process area expects the project to demonstrate each step to the user . This activity should probably be done by demonstrating one or a few modules at a time, rather than the entire system. If a phased approach for development has been used, then this process area would expect to build a little, test a little, demonstrate a little, and deliver a little, module by module. Integration testing (as defined by and used by software engineers ) is almost , but not quite, discussed here. This process area talks about testing integrated modules as an example, but it seems to mean tangible products that are being tested , not just software modules. This process area also overlaps with the Verification and Validation process areas, which may occur in parallel.

This process area is not release management. Releasing products is covered somewhat in Configuration Management, Supplier Agreement Management, and Technical Solution.

Product Integration includes determining how to assemble the product and what the sequence of assembly should be; creating an operational environment in which to satisfactorily deploy the product; documenting procedures and criteria for integrating the product; ensuring adequate integration of interfaces; and delivering the product.

Verification

The purpose of Verification is to ensure that selected work products meet their specified requirements. Verification ensures that the requirements have been met, while Validation assures that the product meets its intended use. Verification ensures that "you built it right" while Validation ensures that "you built the right thing." Specific Goals and Practices for this process area include:

• SG1: Prepare for verification

  • SP1.1: Select work products for verification

  • SP1.2: Establish the verification environment

  • SP1.3: Establish verification procedures and criteria

• SG2: Perform peer reviews

  • SP2.1: Prepare for peer reviews

  • SP2.2: Conduct peer reviews

  • SP2.3: Analyze peer review data

• SG3: Verify selected work products

  • SP3.1: Perform verification

  • SP3.2: Analyze verification results and identify corrective action

This process area is advertised as answering the question: "Did you build the product right?" The next PA (Validation) answers the question: "Did you build the right product?" So, Verification is: "Did you meet the requirements"?

Peer reviews are included in this part of the text.

Verification expects the usage of test setups and test simulators. Sometimes, the same test setups and simulators can be used for Validation as well you just use them for different purposes, looking for different things. Acceptance testing is mentioned here. The overall term "Testing" is used in this process area but never truly spelled out. Some examples of testing types are given path coverage, stress, test case reuse, etc. but testing by software life-cycle phase, or unit-integration-system-acceptance-regression, is not covered.

Verification includes selecting which work products are to be verified ; creating the environment necessary for verification of those products; documenting procedures and criteria for verification, and then following those procedures; conducting peer reviews; and verifying the product and taking any corrective actions needed.

Validation

The purpose of Validation is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment. Specific Goals and Practices for this process area include:

• SG1: Prepare for validation

  • SP1.1: Select products for validation

  • SP1.2: Establish the validation environment

  • SP1.3: Establish validation procedures and criteria

• SG2: Validate product or product components

  • SP2.1: Perform validation

  • SP2.2: Analyze validation results

Validation includes the same strategies as for Verification above, except this time we create what is necessary to validate the product, not verify that the requirements were satisfied. Validation involves creating an environment as close as possible to the environment in which the product will be used, in order to perform final testing of the product. However, this is not always a logical, practical thing to do. An example follows . When one of the authors of this book was working as a subcontractor on a defense contract, we were required, as part of the contract, to build the product and test the product in the same environment as it would be used. Well, the system under development was only going to be used by six people at any given time, although it could be used by up to 200 simultaneous users during peak loads. So, the powers-that-be overseeing the contract decided that, if only six people were going to use the system at any given time, then only six personal computers (PCs) would be necessary. The project managers had determined that to meet the time constraints for the project (a large, database-driven claims processing system), 15 programmers, three database administrators, five test personnel, and one database manager were needed. That adds up to needing at least 24 PCs. We were allowed six. The solution was to work shiftwork and share the PCs. This contract was cancelled after three years and no usable code was produced.

Are we saying that it is a bad practice to create similar environments? No, not at all. It is very worthwhile to test products in their ultimate environment, and to design products for their ultimate use. We are in favor of this. Just remember that it can get expensive and complicated. Plan ahead and plan wisely.

Because this process area also requires simulators to be built, one might want to consider the unique training requirements necessary to build the intended-use environment.

Validation asks: "Are you building the right product?" It includes selecting products and approaches for validating products; generating the validation environment; documenting validation criteria and procedures; conducting the validation activities; and analyzing the results and any issues that arise from conducting the validation process.

Organizational Process Focus

The purpose of Organizational Process Focus (OPF) is to plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization's process and process assets. Specific Goals and Practices for this process area include:

• SG1: Determine process improvement opportunities

  • SP1.1: Establish organizational process needs

  • SP1.2: Appraise the organization's processes

  • SP1.3: Identify the organization's process improvements

• SG2: Plan and implement process improvement activities

  • SP2.1: Establish process action plans

  • SP2.2: Implement process action plans

  • SP2.3: Deploy organizational process assets

  • SP2.4: Incorporate process-related experiences into the organization's process assets

Piloting processes is mentioned here, and process improvement proposals are mentioned here as subpractices. OPF introduces who should be doing process improvement and what process improvement is. The Engineering Process Group (EPG) is mentioned here one of the few groups still retained in the model. The EPG is the group responsible for planning process improvement and implementing the plans. They may or may not be involved in any initial assessments comparing their organization to what is included in the CMMI. The process area essentially describes how to initiate, diagnose, evaluate, act, and learn from process improvement in an organization. Those of you familiar with the IDEAL ^SM model will recognize the use of this model for the layout of the process area.

One recommendation we have in this area concerns the formation of the EPG. Some organizations have decided to form a separate EPG for each discipline that is, one EPG for systems engineering, one for software engineering, one for IPPD, and one for supplier sourcing. Those organizations have quickly found that this separation of duties based on job discipline defeats the purpose of the EPG. The purpose of the EPG is to define an integrated process for process improvement, and to implement this process seamlessly throughout the entire organization. By forming separate groups, feedback and communication are not really there. We recommend that you form one EPG that has representatives from the various areas and disciplines. How big should it be? We have found that the optimum number of full-time , fully engaged people on this type of team should be about ten. Any more and decision making becomes too lengthy and obfuscated . Too few and there are not enough people to do the work.

Yes, you can have levels of EPGs, just like there could be levels of SEPGs when using the Software CMM. Just do not get too hierarchical or too bureaucratic. This group must do real work in the process improvement area.

For more information, see Chapter 13 concerning Roles and Responsibilities.

Organizational Process Focus includes establishing a fundamental understanding of what process is and why it is important to an organization; assessing current processes in the organization and identifying areas in need of improvement; creating and following action plans for improvement; determining how to institute process improvement in the organization and what plans and documentation will be needed; and reviewing the process improvement effort itself and instituting improvements in this area.

Organizational Process Definition

The purpose of Organizational Process Definition is to establish and maintain a usable set of organizational process assets. Specific Goals and Practices for this process area include:

• SG1: Establish organizational process assets

  • SP1.1: Establish standard processes

  • SP1.2: Establish life-cycle model descriptions

  • SP1.3: Establish tailoring criteria and guidelines

  • SP1.4: Establish the organization's measurement repository

  • SP1.5: Establish the organization's process asset library

The process area is Organizational Process Definition because this is where you define and document your organizational processes. No big surprises there. The process asset library is commonly referred to as the PAL.

The measurement repository discussed here is different from what is mentioned in Measurement and Analysis at Level 2. The measurement repository at Level 2 is primarily concerned with project-level data stored in project-level repositories. At Level 3, the information from the projects is now collected and stored at an organizational level, and combined and integrated into organizational metrics that are meaningful to the organization as a whole. For example, at Level 2, the repository may contain when the Requirements phase began, and when it ended; when the Design phase began and when it ended; when Construction began and when it ended; when Testing began and when it ended; and when Implementation began . The repository may also contain defects found in testing. Each project has a repository, and each project collects these data to run their own projects. At Level 3, these metrics are bubbled up from the projects, and studied cumulatively to try to predict trends across the projects. For example, if one project was late getting out of the Testing phase because many errors were found, did that project skimp on the Requirements phase? Is there a correlation? If all of the project data are studied from all of the projects, and all of the projects except one had the same problem, what is it about that one project that made it different? Was it better? Can we devise a "standard" length of time to be set for the requirements phase to improve functioning downstream (like in the Test phase)?

Once an organizational-level repository has been built (based on historical, project-level data from the past) any project-level repository can also use the organizational-level repository as its foundation for building or updating its own (project) repository. This gives the project manager an idea of how to plan his project, where the bottlenecks commonly occur (or occurred in the past), and how long to schedule activities.

Tailoring is also discussed here. The organization must document its criteria for when tailoring of the organization's processes can be done by a project, and what those tailoring guidelines and rules are. However, if you find that you are often tailoring the organization's set of standard processes (OSSP), can you really state that you have a standard organizational process? I do not think so. It does not sound very standard to me.

Organizational Process Definition includes generating the OSSP; describing various life cycles approved for use; documenting tailoring criteria and guidelines; and creating and maintaining the measurement repository and PAL.

Organizational Training

The purpose of Organizational Training is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently . Specific Goals and Practices for this process area include:

• SG1: Establish an organizational training capability

  • SP1.1: Establish the strategic training needs

  • SP1.2: Determine which training needs are the responsibility of the organization

  • SP1.3: Establish an organizational training tactical plan

  • SP1.4: Establish training capability

• SG2: Provide necessary training

  • SP2.1: Deliver training

  • SP2.2: Establish training records

  • SP2.3: Assess training effectiveness

This process area expects a Strategic Training Plan coming from the OSSP, as well as business plans, process improvement plans, defined skillsets of existing groups, missing skillsets of existing groups, skillsets needed for any nonexistent groups necessary to be formed , mission statements, and vision statements. And all of these things tied into training plans. That is a lot of documentation that many smaller organizations do not have and do not need. Small organizations tend to operate at the tactical planning level and not at the strategic level. This process area expects a Strategic Plan that leads to a Tactical Plan.

Organizational-level training plans bubble up from project-level training plans and needs. Organizations also need to evaluate the effectiveness of the training received. That does not necessarily mean that the class fills out an evaluation after the class has been given. It means that the organization must track the value of the training received. Is what you learned what you needed to learn to do the job?

This process area is not about knowledge management. While you may define core competencies and certifications necessary, the concepts are not that similar. For a clearer discussion of knowledge management, review the People CMM, which gives much more guidance.

Organizational Training includes determining the strategic training needs of the organization and how to achieve them; procuring or delivering the training; and tracking its effectiveness.

Integrated Project Management

The purpose of Integrated Project Management (IPM) is to establish and manage the project, and the involvement of the relevant stakeholders, according to an integrated and defined process that is tailored from the organizational set of standard processes. For Integrated Process and Process Development (IPPD), it also covers the establishment of a shared vision for the project and a team structure for integrated teams that will carry out the objectives of the project. Specific Goals and Practices for this process area include:

• SG1: Use the project's defined process

  • SP1.1: Establish the project's defined process

  • SP1.2: Use organizational process assets for planning project activities

  • SP1.3: Integrate plans

  • SP1.4: Manage the project using the integrated plans

  • SP1.5: Contribute to the process assets

• SG2: Coordinate and collaborate with relevant stakeholders

  • SP2.1: Manage stakeholder involvement

  • SP2.2: Manage dependencies

  • SP2.3: Resolve coordination issues

• SG3: Use the project's shared vision (Goal and practices associated with IPPD):

  • SP3.1: Define the project's shared vision context

  • SP3.2: Establish the project's shared vision

• SG4: Organize integrated teams (Goal and practices associated with IPPD):

  • SP4.1: Determine integrated team structure for the project

  • SP4.2: Develop a preliminary distribution of requirements to integrated teams

  • SP4.3: Establish integrated teams

There are two versions of this process area: Integrated Project Management and Integrated Project Management for IPPD. To include the second version, the model adds two more specific goals that is, SG3 and 4 with their associated specific practices.

The policies written for this process area should include when and when not to include IPPD activities.

This PA is supposed to be the evolution of Project Planning, and Project Monitoring and Control from Level 2, plus more sophistication for Level 3. That means that this PA involves more rigorous techniques for planning and monitoring projects within the organization. In this PA, each project reviews and tailors the OSSP to fit a project's specific needs. The result is called the project's defined process, and yes, it must be documented. This process is then used to help build the project plan.

The difference between the standard processes, tailoring guidelines, and procedures mentioned in Organizational Process Definition (OPD) and here in Integrated Project Management (IPM), is that the documentation is created and stored in OPD and used in IPM on the projects.

The difference between management at Levels 2 and 3 is that Level 3 uses a set of organizational plans, processes, and assets (templates, checklists) based on best practices and lessons learned. The measurement repository is used for generating achievable estimates based on past performance. The repository of project and organizational information discussed in this PA becomes the basis of the performance baselines at Level 4.

Risk is not really discussed much here, at least not as much as in the CMM for Software. Risk thresholds are not discussed in depth, only as an example in SP1.4 subpractice 2.

SG1: Use the project's defined process makes this process a required element. Previous definitions of process in the CMMI were simply informative, or expected as part of the OSSP.

IPPD focuses on establishing and using a shared vision of what the project is to accomplish by way of using the IPPD team structure (Integrated Product Teams IPTs). SP3.1: define project's shared vision when expanded to its full practice reads: "Identify expectations, constraints, interfaces, and operational conditions applicable to the project's shared vision." If your organization is using IPTs, then please review Organizational Environment for Integration and Integrated Teaming.

Integrated Project Management includes defining a process or processes at the project level, when necessary to tailor from the organizational process(es); using the processes and documentation developed from the organization; integrating all plans (including plans for each process area as well as project management plans) with the project's defined process; managing the project according to the plan; incorporating measurements, documentation, and improvements into the project or organizational-level repositories and processes; ensuring stakeholder involvement; tracking critical dependencies; and resolving issues. For Integrated Project Management for IPPD, also include defining a shared vision of the project among all involved parties; determining the structure of the integrated team; establishing the team; and ensuring that team members have all relevant documentation and information needed to guide them in understanding the project and developing the product.

Risk Management

The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives. Specific Goals and Practices for this process area include:

• SG1: Prepare for risk management

  • SP1.1: Determine risk sources and categories

  • SP1.2: Define risk parameters

  • SP1.3: Establish a risk management strategy

• SG2: Identify and analyze risks

  • SP2.1: Identify risks

  • SP2.2: Evaluate, categorize, and prioritize risks

• SG3: Mitigate risks

  • SP3.1: Develop risk mitigation plans

  • SP3.2: Implement risk mitigation plans

Some sort of risk identification and control is touched upon in almost all of the process areas. In Project Planning and Project Monitoring and Control, risks are identified and strategies for handling the risks are introduced. Evaluating project risks and the impacts of probable risks are addressed. The Risk Management process area is much more proactive, involving identification of risk parameters, formal strategies for handling risks, preparing risk mitigation plans, and structured risk assessments. The Technical Solution process area discussed risk in terms of risks involved in selecting alternative solutions, and reducing risks in" make-buy-reuse" decisions. The Decision Analysis and Resolution process area discusses evaluation processes used to reduce risks made in making decisions and analyzing alternatives. Although preparing for risks can be considered an organizational-level task, mitigating risks is usually the responsibility of the project.

Periodic and event-driven reviews should occur on the project to summarize the most critical risks that might occur. Make sure you review risks during periodic reviews. Why? Because discussing risks only during an "event" (usually a bad thing like the risk has already happened and now what do we do about it?) only gives exposure to your project when problems are about to occur. In addition, risk probability changes over time and over the course of the project. The risk culture of senior management in a Level 1 organization is simply, "Don't tell me I don't want to know. Only tell me that things are fine." The risk culture in a Level 3 and above organization is more proactive. They want to hear what might happen and what to do about it.

Disaster recovery may be included as part of an organization's risk management culture but it is not included here. A risk repository can be built at the organization level that contains the risks that were most frequently realized on projects, and their solutions. This repository can help project managers avoid these known risks on their projects.

Risk Management includes identifying and categorizing risks; generating a risk management strategy; analyzing risks; documenting risk mitigation plans; mitigating risks; and monitoring the risk effort.

Integrated Teaming

The purpose of Integrated Teaming is to form and sustain an integrated team for the development of work products. Specific Goals and Practices for this process area:

• SG1: Establish team composition

  • SP1.1: Identify team tasks

  • SP1.2: Identify needed knowledge and skills

  • SP1.3: Assign appropriate team members

• SG2: Govern team operation

  • SP2.1: Establish a shared vision

  • SP2.2: Establish a team charter

  • SP2.3: Define roles and responsibilities

  • SP2.4: Establish operating procedures

  • SP2.5: Collaborate among interfacing teams

This process area coordinates the activities of the power brokers in the organization. The teams formed should have complementary skills and expertise to advance timely collaboration to produce the product. Relevant stakeholders should be part of the team, and communication channels should be built to communicate what is happening on the team to individuals not part of that team. It does no good to come up with a shared vision if that vision contradicts what other members of the project have devised who were not allowed to participate on the team.

This team is actually a specialized team (or teams) within the project itself. Team tasks are generated based on project objectives. Members should be selected based on their skills, expertise, and needs of the project. You may also need to train members to fill in the gaps of who is available versus who has the skills. Teamwork training is also a plus, as well as specific training or orientation as to how this team will function, and how it will function with other teams. It is not unusual to include customers and the marketing department on these teams. Be prepared to train and mentor, as people have different backgrounds, different skills, different perspectives, different cultures, and different roles in the organization, and bring them to the team. Establishing the shared vision is therefore critical and will require lots of work. It is not a trivial exercise. We suggest that when it comes to rewards, that the team be rewarded not the individual but you must ensure that everyone on the team actively adds value.

Each team should write a vision statement, plan, charter, and procedures. These documents should be written by the team as a whole, and not by selected members who just mandate usage because they had to write this documentation.

While this process area is top-heavy and formally structured, the basic concepts of this process area can be used and tailored to fit your organization's culture.

Integrated Teaming includes defining team tasks; identifying any knowledge or skill gaps among the teams and team members, and rectifying them; ensuring appropriate personnel are assigned to the correct team; establishing a shared vision of the product and of team objectives; defining team roles and responsibilities; documenting a team charter; and determining strategies for interfacing among teams.

Integrated Supplier Management

The purpose of Integrated Supplier Management (ISM) is to proactively identify sources of products that may be used to satisfy the project's requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship. Specific Goals and Practices for this process area include:

• SG1: Analyze and select sources of products

  • SP1.1: Analyze potential sources of products

  • SP1.2: Evaluate and determine sources of products

• SG2: Coordinate work with suppliers

  • SP2.1: Monitor selected supplier processes

  • SP2.2: Evaluate selected supplier work products

  • SP2.3: Revise the supplier agreement or relationship

This process area is the evolution of Supplier Agreement Management from Level 2. Integrated Supplier Management (ISM) takes a much more proactive view when identifying sources and evaluating them formally. This process area feeds into Decision Analysis and Resolution. ISM looks for a more cooperative agreement with suppliers, a more defined and formalized process, and active participation in improving the relationship between suppliers and customers.

Integrated Supplier Management includes identifying potential sources and suppliers; evaluating these sources; selecting a product source or sources; monitoring the processes and outcomes provided by the source; and revising the supplier agreement as necessary.

Decision Analysis and Resolution

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. Specific Goals and Practices for this process area include:

• SG1: Evaluate alternatives

  • SP1.1: Establish guidelines for decision analysis

  • SP1.2: Establish evaluation criteria

  • SP1.3: Identify alternative solutions

  • SP1.4: Select evaluation methods

  • SP1.5: Evaluate alternatives

  • SP1.6: Select solutions

Some organizations, in response to this process area, have stated that they do not need a formal mechanism to make decisions, nor do they need formal guidelines for choosing alternatives. Appraisal teams must ensure that these mechanisms are used, which can also prove difficult. This area could prove useful in the vendor selection process. The choice of which alternative, platform, architecture, language, and new technology overlaps somewhat with Technical Solution. The type of testing mentioned here concerns testing the possible solution approaches.

Why is this process area needed? The rationale is to provide managers and analysts with a mechanism to make decisions. This mechanism requires a formal approach to determine which issues need the formal approach of DAR, as well as what that mechanism should be. However, if you are having trouble making a decision, it seems this process area simply gives you more things to consider when making a decision, which increases the difficulty of making that decision, so that no decision ends up being made or the decision may be delayed. It is like saying that "You need to make a decision about which decision to make. Now, decide how to make the decision for the decision, and then make the decision." Well, if you could make a decision in the first place, do you not think you would have? And does this area really help you do that? We think not. Another way to look at this process area is as follows. You ask your boss for a new server. If he agrees, he just says, "Yes go get one." If not, he makes you follow the guidelines in this process area, hoping you will just give up and go away. However, large organizations tasked with initiating complicated systems may find this PA helpful.

Decision Analysis and Resolution includes determining which decisions will be part of a formal decision-making evaluation process; creating evaluation criteria; determining the types of evaluation methods to use; and determining alternative solutions.

Organizational Environment for Integration

The purpose of Organizational Environment for Integration is to provide an Integrated Product and Process Development (IPPD) infrastructure and manage people for integration. Specific Goals and Practices for this process area include:

• SG1: Provide IPPD infrastructure

  • SP1.1: Establish the organization's shared vision

  • SP1.2: Establish an integrated work environment

  • SP1.3: Identify IPPD-unique skill requirements

• SG2: Manage people for integration

  • SP2.1: Establish leadership mechanisms

  • SP2.2: Establish incentives for integration

  • SP2.3: Establish mechanisms to balance team and home organization responsibilities

This process area is where the infrastructure for the team is built. It supports integrated, collaborative behaviors. Shared vision is critical to success. The team must define this vision, and get commitment and buy-in before proceeding. This approach is difficult for low-maturity organizations, especially where individuals are rewarded for their individual not team efforts. The major points of this process area are:

• Communication

• Reward structure

• Physical location of the team

• Appropriate facilities

Team building classes are promoted here. Decision-making responsibilities are defined and distributed between the team and senior management. Project responsibilities ("real work") versus process improvement responsibilities and other work must be defined and balanced. It helps if your organization has developed an organization-level plan that each team can use as a guideline when developing their own team plans, and tailor as necessary.

Organizational Environment for Integration includes defining, once again, a shared vision; empowering personnel; identifying unique skills and needs related to IPPD; creating leadership mechanisms and reward structures promoting effective integration of teams; and documenting guidelines to balance work and home activities.