Intergroup Coordination
a key process area for level 3: Defined
The purpose of Intergroup Coordination is to establish a means for the software
engineering group to participate actively with the other engineering groups so
the project is better able to satisfy the customer's needs effectively and
efficiently.
Intergroup Coordination involves the software engineering group's participation
with other project engineering groups to address system-level requirements,
objectives, and issues. Representatives of the project's engineering groups
participate in establishing the system-level requirements, objectives, and
plans by working with the customer and end users, as appropriate. These
requirements, objectives, and plans become the basis for all engineering
activities.
The technical working interfaces and interactions between groups are planned
and managed to ensure the quality and integrity of the entire system.
Technical reviews and interchanges are regularly conducted with representatives
of the project's engineering groups to ensure that all engineering groups are
aware of the status and plans of all the groups, and that system and intergroup
issues receive appropriate attention.
The software-specific practices related to these engineering tasks are
described in the Requirements Management and Software Product Engineering key
process areas.
Goals
Goal 1
The customer's requirements are agreed to by all affected groups.
Goal 2
The commitments between the engineering groups are agreed to by the affected
groups.
Goal 3
The engineering groups identify, track, and resolve intergroup issues.
Commitment to perform
Commitment 1 -- The project follows a written organizational policy for
establishing interdisciplinary engineering teams.
This policy typically specifies that:
- The system requirements and project-level objectives for the project are
defined and reviewed by all affected groups.
Examples of affected groups include:
- software engineering,
- software estimating,
- system test,
- software quality assurance,
- software configuration management,
- contract management, and
- documentation support.
- The engineering groups coordinate their plans and
activities.
- Managers are responsible for
establishing and maintaining an environment to facilitate interaction,
coordination, support, and teamwork between the project's engineering groups,
between the project and the customer or end users, as appropriate, and
throughout the organization.
The end users referred to in these practices are the customer-designated end
users or representatives of the end users.
Ability to perform
Ability 1 -- Adequate resources and funding are provided for coordinating
the software engineering activities with other engineering groups.
Ability 2 -- The support tools used by the different engineering groups
are compatible to enable effective communication and coordination.
Examples of support tools that should be compatible include:
- word processing systems,
- database systems,
- graphics tools,
- spreadsheet programs,
- problem tracking packages, and
- library management tools.
Ability 3 -- All managers in the organization receive required training
in teamwork.
Examples of training include:
- building teams;
- managing teams;
- establishing, promoting, and facilitating teamwork; and
- group dynamics.
Refer to the Training Program key process area.
Ability 4 -- All task leaders in each engineering group receive
orientation in the processes, methods, and standards used by the other
engineering groups.
Refer to the Training Program key process area.
Ability 5 -- The members of the engineering groups receive orientation in
working as a team.
Refer to the Training Program key process area.
Activities performed
Activity 1 -- The software engineering group and the other engineering
groups participate with the customer and end users, as appropriate, to
establish the system requirements.
Specifically, these groups:
- Define the critical characteristics of the customer's and end users'
requirements, as appropriate.
- Negotiate critical dependencies.
- Document the acceptance criteria for each product delivered to the
customer or end user, as appropriate.
Activity 2 -- Representatives of the project's software engineering group
work with representatives of the other engineering groups to monitor and
coordinate technical activities and resolve technical issues.
- The representatives of these groups monitor and coordinate technical
activities by:
Refer to Activity 10 of the Integrated Software Management key process area for
practices covering risk management.
- The representatives of the groups handle technical issues by:
- resolving project-level conflicts and clarifying system requirements and
design issues;
- developing joint recommendations to resolve problems; and
- addressing process issues that span the engineering groups of the
project.
Activity 3 -- A documented plan is used to communicate intergroup
commitments and to coordinate and track the work performed.
This plan is:
- The baseline for:
- the project schedule,
- the contractual and technical aspects of the project, and
- the assignment of responsibilities to the engineering groups.
- Used to coordinate activities between the different engineering groups.
- Readily available to the members of all engineering groups.
- Updated to incorporate all intergroup commitments and changes to these
commitments.
- Updated as the work progresses to reflect progress and plan changes at the
project level, particularly when major project milestones are completed and
when plans change significantly.
- Reviewed and agreed to by all engineering groups and the project manager.
Activity 4 -- Critical dependencies between engineering groups are
identified, negotiated, and tracked according to a documented procedure.
Refer to Activity 9 of the Integrated Software Management key process area for
practices covering management of critical dependencies.
This procedure typically specifies that:
- Each critical dependency is explicitly defined, including:
- the item to be provided,
- who will provide it,
- when it will be provided, and
- the criteria for acceptance.
- Critical dependencies are negotiated between the software engineering
group and other engineering groups in the project and organization.
- Need dates and availability dates of critical dependency items are tied to
the project schedule and the software schedule.
- The agreement for each critical dependency is documented, reviewed, and
approved by both the receiving group and the group responsible for providing
the critical dependency item.
- Critical dependencies are tracked on a regular basis and corrective
actions are taken when appropriate.
- Status and actual or projected completion are compared to the plan used to
coordinate intergroup commitments.
- Effects of late and early completions are evaluated for impacts on future
activities and milestones.
- Actual and potential problems are reported to the appropriate
managers.
Activity 5 -- Work products produced as input to other engineering groups
are reviewed by representatives of the receiving groups to ensure that the
work products meet their needs.
Activity 6 -- Intergroup issues not resolvable by the individual
representatives of the project engineering groups are handled according
to a documented procedure.
Examples of intergroup issues include:
- incompatible schedules,
- inadequate funding,
- technical risks,
- system-level design and requirements defects, and
- system-level problems.
Activity 7 -- Representatives of the project engineering groups conduct
periodic technical reviews and interchanges.
In these meetings, the participants:
- Provide visibility of the needs and desires of the customer and end users,
as appropriate.
- Monitor the technical activities of the project.
- Ensure that the groups' interpretation and implementation of the technical
requirements conform to the system requirements.
- Review the commitments to determine whether they are being met.
Refer to the Software Project Tracking and Oversight key process area for
practices covering reviews.
- Review the technical risks and other technical issues.
Refer to Activity 10 of the Integrated Software Management key process area for
practices covering risk management.
Measurement and analysis
Measurement 1 -- Measurements are made and used to determine the status
of the intergroup coordination activities.
Examples of measurements include:
- actual effort and other resources expended by the software engineering
group for support to other engineering groups;
- actual effort and other resources expended by the other engineering groups
in support of the software engineering group;
- actual completion of specific tasks and milestones by the software
engineering group to support the activities of other engineering groups; and
- actual completion of specific tasks and milestones by the other
engineering groups to support the activities of the software engineering
group.
Verifying implementation
Verification 1 -- The activities for intergroup coordination are reviewed
with senior management on a periodic basis.
Refer to Verification 1 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of the senior
management oversight reviews.
Verification 2 -- The activities for intergroup coordination are reviewed
with the project manager on both a periodic and even-driven basis.
Refer to Verification 2 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of the project
management oversight reviews.
Verification 3 -- The software quality assurance group reviews and/or
audits the activities and work products for intergroup coordination and
reports the results.
Refer to the Software Quality Assurance key process area.
The software quality assurance responsibilities for this key process area may
be subsumed into a quality assurance function that covers all the project
engineering groups.
At a minimum, the reviews and/or audits verify:
- The procedure for identifying, negotiating, and tracking critical
dependencies between the project engineering groups.
- The handling of intergroup issues.
Table of contents
Back one chapter
Forward one chapter
| |
|