Transcript Evolution of Project Management Maturity

Project Management Maturity
Model
12/22/14
© 2014
Amit Mitra and Larissa Zhurakovskaya
Evolution of Project Management
Maturity
MATURITY OF PROJECT MANAGEMENT
Level 1
(Initial)
Unpredictable, poorly
controlled processes
Level 2
(Repeatable)
Can consistently
repeat previously
mastered tasks
Level 3
(Defined)
Best Practices
standardized
for Organization
Level 4
(Managed)
Quantitative standards
& controls in place
Level 5
(Optimizing)
Focus on continuous
Process Improvement
CAPABILITY LEVEL 2
Consistently Repeatable Process
LEVEL 2 ANALYSIS HIERARCHY
Process Capability
GOALS OF KEY PROCESS AREAS (KPAs)
In moving from level 1 to 2,
managing requirements
will benefit the
organization more than
optimizing engineering
methodology
REQUIREMENTS MANAGEMENT
Goals:
• Establish, control & utilize a Requirements Baseline
• Ensure consistency of Requirements with project plans,
activities & Work products
Common understanding
with customer
PROJECT PLANNING
Goals:
•Estimate projects in writing for planning & tracking
purposes
•Plan & document project activities & commitments
•Ensure commitments are agreed upon between all
impacted groups
Engineering plan & risk management
PROJECT TRACKING & OVERSIGHT
Goals:
• Track actuals against plans
• Take & manage corrective actions on deviations to
closure
• Agree on (commitment) changes over the project’s life
across all impacted groups
Make progress against visible & actionable plan
QUALITY ASSURANCE
Goals:
• Plan Quality Assurance activities
• Objectively verify that work products & activities
comply with standards
• Communicate QA results & activities to all impacted
groups
• Upper management resolves noncompliance when
it cannot be resolved at the project level
CONFIGURATION MANAGEMENT
Goals:
•Plan Configuration Management activities
•Identify, control & make selected work products
available on time
•Control changes to work products
•Communicate systems, software and component
baseline statuses to all impacted groups
CONTRACT MANAGEMENT
Goals:
•Select qualified contractors & subcontractors
•Agree on mutual commitments with contractors
•Maintain ongoing communication with contractors
•Track contractors’ performance against commitments
Make progress & product quality visible
Maintain integrity of work products
over the project/service’s live
Choose & manage contractors effectively
CAPABILITY LEVEL 2
Consistent Process Repeatability
INSTITUTAIONALIZING REQUIREMENTS MANAGEMENT PROCESS AND ACTIVITIES
REQUIREMENTS MANAGEMENT
Goals:
• Establish, control & utilize a Requirements
Baseline
• Ensure consistency of Requirements with
project plans, activities & Work products
Commitment
Publish requirements analysis policy
SLA agreements with Service owners
Requirements Documentation
Impacted groups requirements review
Requirements change control & alignment of plans, activities & work products with changes
Establish
Requirements
Analysis
Responsibility
Ability
Responsibility for Managing & recording requirements & corresponding solutions
Requirements change control responsibility, Change control responsibility for ownership of solutions
Document Requirements
Document Commitments, Terms & Conditions
Document functional, non-functional & Technical requirements
Document acceptance criteria
Provide adequate resources & funds
Requirements Baseline
A formally agreed upon specification, under
change control, on which all development is based
Requirements allocated to managers with both Applications Domain & Technical expertise
Adequacy & access to requirements Management tools
Provide adequate expertise/training : Procedural, methodology, standards, tools & subject matter training
Establish,
control &
utilize a
Req.
Baseline
Measure & Analyze
Track requirements & corresponding activities’ status, statistics & anomalies
Monitor implementation
Periodic Upper Management review of Requirements Management & allocation activities
Periodic & event/exception triggered Project Manager review of Requirements Management & allocation activities
Quality Assurance review/audit of Requirements Management
& allocation activities & work products; Reports of results
KPA execution
(activities)
Assure problem resolution, review & Engineering group’s consent prior to commitment
Assure plans, activities & work products are revised when requirements (or solutions responsibilities) change
Assure changed commitments are negotiated with impacted groups
Review, resolve & obtain Engineering group’s
consent before committing to requirements
Ensure
consistency of
Requirements
with project
plans,
activities &
Work products
Have requirements drive
engineering plans,
activities & work products
Review & change
requirements & responsibilities
for solutions as needed
Resolve missing & incomplete requirements/responsibility for solutions
Resolve clarity, feasibility, consistency & testability of requirements & allocated responsibilities
Review & resolve exceptions with the group responsible for allocating ownership of solutions
Negotiate commitments with impacted groups
Negotiate SLA agreements and chargeback model with service owners
Manage & control requirements & allocation of responsibilities for solutions (baseline, versioning, configuration, archival)
Base plans, activities & work products on requirements
Base software requirements on those of other groups
Assess impact, and negotiate changes to commitments (internal- with impacted groups; external- with upper management first)
Identify, evaluate (including risk), record, plan and communicate to all impacted parties,
changes to plans, activities & work products caused by requirements changes
CAPABILITY LEVEL 2
Consistent Process Repeatability
INSTITUTIONALIZING
REQUIREMENTS MANAGEMENT
Goals:
•Establish, control & utilize a Requirements Baseline
•Ensure consistency of Requirements with project plans, activities &
Work products
Commitment
Ability
Plan &
document
project
activities
& commitments
PROJECT PLANNING
Baseline
A formally reviewed and agreed upon work
product or specification that can only be changed
through formal change control procedures, and is
the basis for further development
Designate Project (& subproject) Planning Manager(s)
Publish written project planning policy
Base plan on requirements & solution responsibilities allocated to each group
Control & manage the plan via a baseline (change, status, version, archive control & management)
Review estimated size, cost, schedule & other commitments with all impacted groups
Negotiate commitments between all impacted managers(software as well as other groups)
Review all external commitments with upper management
Document an approved
statement of work
Assign
project
planning
resp.
Establish scope, goals, constraints & assumptions (technical , schedule, budgetary, resource etc), sponsors & end
users of system, standards, responsibilities, impact & dependencies (internal & external organizations)
Review& consent of all impacted managers & groups (project, external & internal)
Manage & control the statement of work via the baseline
Project (Subproject) Manager(s)coordinate planning & are responsible for their own plans aligned with their commitments & delivery responsibilities
Partition & assign responsibilities, activities & work products between managers in a traceable & accountable manner
Provide adequate resources & funds
Planners have both Applications Domain & Technical expertise
Adequacy & access to planning & estimation tools
Estimate
projects in
writing for
planning &
tracking
purposes
Train planners (Management & staff) in estimating & planning (procedures, methodology, standards, tools & subject matter) aligned with their responsibilities
Measure & Analyze
Track project plan & planning activities status & statistics (milestone status, actuals vs. plan, changes etc.)
Monitor Implementation
Periodic Upper Management review of Project Planning activities
Periodic & event/exception triggered Project Manager review of planning
Ensure
commitments
are agreed
upon between
all impacted
groups
Quality Assurance review/audit
& report of Project Plans &
planning activities
KPA
execution
(activities)
Performance: Technical, cost, staffing, schedule
Address unresolved issues & conflicts
Address risks
Assign, review& track action items to closure
Prepare & distribute Review Summary to all impacted parties
Review & address risks
Involve all impacted groups
Review status & results against requirements & statement of work
Address inter-group dependencies
Address unresolved issues & conflicts
Assign, review& track action items to closure
Prepare & distribute Review Summary to all impacted parties
Plan content
Plan standards
Estimation activities
Planning activities
Plan review & commitment activities
Managed & Controlled Plan
A formally agreed upon project plan,
under change control, such that the
version utilized at any point in time,
past or present, is known
CAPABILITY LEVEL 2
PROJECT PLANNING ACTIVITIES
Consistent Process Repeatability KPA
PROJECT PLANNING
Managed & Controlled Plan
Execution
Goals:
A formally agreed upon project plan,
•Estimate projects in writing for (activities)
planning & tracking
under change control, such that the
purposes
version utilized at any point in time, past
•Plan & document project
activities & commitments
or present, is known
Involve in preparing, submitting, clarifying, negotiating
•Ensure commitments are agreed
upon between all
commitments
&
changes
that
impact
corresponding
groups
Include Engineering groups (including software
impacted groups
engineers) in the project proposal team
Resolve clarity, feasibility, consistency & testability of requirements & allocated responsibilities
Develop software project plans in parallel with, and as an integral part of, the overall project plan
Include all impacted groups(including software engineering
groups) in project planning over the project’s full life
Plan &
document
project
activities
& commitments
Establish a software development life cycle divided into predefined, manageably sized phases.
Develop systems project plans (&
overall project plan) consistent with a
documented procedure
Document the overall & software project plan
Identify items (including software work
products) needed to manage & control the
(software) project
Ensure
commitments
are agreed
upon
between all
impacted
groups
Each group, including Software Engineering, reviews & agrees on the
overall project plan thru the project’s full life
Consistent with requirements, solution(s) responsibilities, statement of work & standards (external & internal to the project)
Negotiate plans & inter-group commitments with corresponding groups, document agreements & budget for inter-group support
All impacted groups (including software & Project Managers) review the project plan
Manage & control the plan (software & overall)
Decide the Chargeback and costing model for services
Negotiate SLAs with service providers, if required
Evaluate existing services and consider service reuse while cost estimation
State scope & purpose, specific objectives
Describe software life cycle, reasons for selecting a specific type/methodology
Specify software & other development & maintenance standards, procedures, techniques & methods
Identify software & other engineering work products
Include (software)Project effort & cost estimate
Include software (& other) work products size estimates (size anticipated changes as well)
Estimate use of critical computer resources
Describe project schedules, milestones & planned reviews
Project (software) risk assessments
Include project (software) engineering facilities & tools plan
Upper management, following a documented procedure, reviews all commitments made to external parties (including software commitments).
CAPABILITY LEVEL 2
Consistent Process Repeatability KPA
PROJECT PLANNING
Execution
Goals:
•Estimate projects in writing for (activities)
planning & tracking
purposes
•Plan & document project
activities & commitments
•Ensure commitments are agreed
upon between all
impacted groups
PROJECT PLANNING ACTIVITIES
Use documented estimation procedures to:
Document, review & agree on estimates with impacted managers
Size software work product (& change)
Estimate
projects in
writing for
planning &
tracking
purposes
Estimate (software) project cost & effort
Size critical
computer
resources
Ensure
commitments
are agreed
upon
between all
impacted
groups
Managed & Controlled Plan
A formally agreed upon project plan,
under change control, such that the
version utilized at any point in time,
past or present, is known
Derive project cost & effort estimates from work product size (&
anticipated change) estimates (distributed over project’s life)
Use available productivity & cost data, documenting rationale, assumptions & sources
Base effort & staffing estimates on experience
Identify critical resources
Derive estimates from software work product size, processing load & communications traffic estimates
Estimate (software) project schedules
Plan &
document
project
activities
& commitments
Size all major work products & activities
State estimation/sizing objectives
Use available historical data
Document assumptions
Derive estimates from software effort, cost, change & work product size estimates
Actual schedules of similar past projects when available
Consistent with imposed timing of milestones, critical dependencies & other constraints
Are timelines (Activity length & gaps between milestones) appropriate for accurate tracking?
Document assumptions
Assess & record risks (technical,
cost, schedule, resource & other)
Analyze & prioritize risks based on potential impact on the project’s business objectives
Identify contingency plans& allowances
Plan software & Systems
engineering facilities & tools
Estimate facilities & tools capacity from estimated project & work product size
Negotiate commitments & responsibilities for procuring/developing facilities & tools
Document, review & agree on estimates & commitments with impacted managers
Assemble the plan, record, manage
& control it in a baseline
Include estimates, assumptions rationale & derivation
CAPABILITY LEVEL 2
Consistent Process Repeatability
PROJECT TRACKING & OVERSIGHT
Goals:
•Track actuals against plans
•Take & manage corrective actions on deviations to
closure
•Agree on (commitment) changes over the project’s
life across all impacted groups
INSTITUTIONALIZING PROJECT TRACKING & OVERSIGHT
Baseline
A formally reviewed and agreed upon work product or
specification that can only be changed through formal
change control procedures, and is the basis for further
development
Designate Project (& subproject) Manager(s)
Publish written project management policy
Commitment
Ability
Track
actuals
against
plan
Base the project on an approved
& documented project plan
Track project against a documented baseline plan that is appropriately maintained
Project/subproject Managers are aware of the status & issues of their portions of the project on time
When deviations from the plan occur, corrective actions are taken by adjusting either performance or the plan
Negotiate and consent to changes in commitments between all impacted managers(software as well as other groups)
Review all changes to external commitments with upper management
Assign ownership of work products & responsibility
Provide adequate
resources & funds
Take &
manage
corrective
actions on
deviations
to closure
Individual responsibility for providing work products & services envisioned in the project plan
Individual responsibility for work products & activity cost & schedules
Budgetary responsibility for activity cost
Assign managers & task leaders specific tracking responsibility
Adequacy & access to project tracking tools
Assumption
Organizations striving for
repeatable results are already
good at engineering, but need
Management & technical
infrastructure to stabilize their
engineering process against
perturbing factors
Train (software) managers in managing both project personnel & technology (Grow managers, rather than appoint good, but unprepared technical staff to management)
Orient first line managers to the project’s technology (Grow managers, rather than appoint good, but unprepared technical staff to management)
Measure & Analyze
Tracking oversight & change management activities performance: impact on schedule, cost, effort & resource utilization
Periodic Upper Management project review
Monitor Implementation
Periodic & event/exception triggered
Project Managers’ review
Performance: Technical, cost, staffing, schedule, tracking & oversight,
Address unresolved issues & conflicts
Address risks
Assign, review& track action items to closure
Prepare & distribute Review Summary to all impacted parties
Involve all impacted groups
Review project status (technical, cost, resource & schedule performance) against plan
Report & review current & projected utilization of critical computer resources against original plan
Address inter-group dependencies
Address unresolved issues & conflicts
Review & address risks
Assign, review& track action items to closure
Prepare & distribute Review Summary to all impacted parties
Agree on
(commitment)
changes over
the project’s
life across all
impacted
groups
Quality Assurance review/audit & report of Project tracking & oversight activities & work products’ status
KPA
Execution
(activities)
Commitment review & revision activities
Project plan revisions - activity
Revised plan content
Cost, schedule risk, functionality, performance & constraint (technical & design) tracking activities
Plan review & commitment activities
CAPABILITY LEVEL 2
Assumption
PROJECT TRACKING & OVERSIGHT ACTIVITIES
Consistent Process Repeatability
Organizations striving for repeatable results are already good at engineering,
KPA
PROJECT TRACKING &
but need Management & technical infrastructure to stabilize their engineering
OVERSIGHT
Execution
Goals:
process against perturbing factors
•Track actuals against plans
(activities)
•Take & manage corrective actions
Update the plan to reflect accomplishments, particularly when milestones are completed
on deviations to closure
Track project work & commitments against
•Agree on (commitment) changes
Ensure easy access to the same updated plan by all impacted groups, particularly upper management, project
a documented & approved project plan
over the project’s life across all
(& subproject) managers & (software) engineering groups
impacted groups
Revise the plan to reflect significant changes, particularly in requirements, design constraints, resources, cost or schedule
Revise software project plans (&
Reflect all new & changed commitments in the revised plan
overall project plan) consistent
All impacted groups (including software & Project Managers) review & consent to the revised project plan
with a documented procedure
Manage & control the plan (software & overall) in a baseline
Upper management, following a documented procedure, reviews all new & changed commitments to external parties (including software commitments).
Take &
manage
corrective
actions on
deviations
to closure
Changed commitments are communicated to all impacted groups after they are approved (including Quality Assurance, Configuration Management & Documentation)
Track & take necessary corrective actions:
Track commitments & actuals against plan - current & original baselines,
monitor deviations, refine & adjust plan & commitments regularly
Review & agree on revised estimates, commitments, plans & changes with all impacted managers. Document agreements & risks
Software work product Size (& change)
(Software & system)
project cost & effort
Critical (computer)
resources use
Agree on
(commitment)
changes over
the project’s life
across all
impacted
groups
Size of major work products & activities (or changes)
Size of fully tested & delivered code
Documents actually delivered
Effort, cost, time expended vs. work completed to identify potential overruns & under-runs
Cost - actual vs. plan
Effort & Staffing - actual vs. plan
Critical resource use for each major software component/deliverable in plan
Changes
Activity & Milestone completion; Meeting other commitments in plan
Evaluate impact of late/early completion of activities, milestones &
other commitments on future activities & milestones
(Software & system project schedules
(Software & system) Engineering
activities - Design, code, test
Technical team members report technical work product & activity status to first line managers regularly
Compare contents of successive software builds/releases against plan
Report & Document (software) work product defects & problems
Track problem reports to closure
Risks (technical, cost, schedule, resource & other)
Record actuals & re-planning information
Track
actuals
against
plan
Periodic internal (software) engineering group
review for tracking technical progress, plans,
performance & issues against software plan
Review results & accomplishments
formally at selected milestones
determined by a documented
procedure
Adjust prioritized risks & contingencies in step with new information
Regular project Manager’s review of high risk areas
Estimates, their assumptions, rationale & other information to reconstruct estimates
Use the plan baseline to manage & control revisions
Archive the original plan, its revisions & actuals for use by ongoing & future projects
Task leaders & first line managers
Appropriate (Software) project & sub project managers
Review at meaningful points in project schedule/lifecycle
Involve customers, end users & all impacted groups in organization
Review materials approved by the (software & business system) managers responsible for delivering corresponding work products
Address commitments, plans & (software & business system) activity status
Identify & record significant issues, action items & decisions
Address (software & business system) project risks
Refine/revise plan if necessary
CAPABILITY LEVEL 2
INSTITUTIONALIZING
Consistent Process Repeatability
QUALITY ASSURANCE
Goals:
•Plan Quality Assurance activities
•Objectively verify that work products & activities comply with
standards
•Communicate QA results & activities to all impacted groups
•Upper management resolves noncompliance when it cannot be
resolved at the project level
Commitment
QUALITY ASSURANCE
Publish Organization’s QA policy
Ability
QA must cover all (systems) projects
Periodic upper management project QA reviews - activities & results
QA organization & reporting channel are independent of project & other software & business systems organizations
Create a group for the project’s QA coordination & implementation
Provide adequate resources &
May be large or small group or even an individual with part time commitment focused on the project’s QA activities
funds for Quality Assurance
Plan
Quality
Assurance
activities
Objectively
verify that
work
products &
activities
comply with
standards
Communicate
QA results &
activities to
all impacted
groups
Assign a manager specific project QA activities responsibility
Ensure information & reports on noncompliance are escalated to the senior QA manager as necessary
Assign a senior, experienced QA manager overall authority to take appropriate QA oversight actions, especially noncompliant project items
Adequacy of, & access to, QA support tools (such as auditing tools, work stations, databases, spread sheets, repositories etc.)
Train/
acquire
team
members
Understand software & systems engineering skills/practices & QA involvement in software activities
Understand role-responsibilities of software/systems engineering & related groups, their interfaces &
protocols
Understand project/organization’s standards, methods & procedures,
Understand project’s application/business domain
Know QA objectives & procedures; can effectively use QA methods & tools;
Skilled in interpersonal communication & fostering collaboration
Orient (software & business systems) quality assurance team members in (software) QA group business value & charter, values, role-responsibilities & authority
Measure & Analyze
Monitor Implementation
Measure/derive QA activities performance: status, schedule & cost against baseline plan
Track QA milestone & work completion, effort & resource
utilization, volumes of work product & activity audits
Periodic Upper Management QA activity review
Periodic &
Performance: Technical, cost, staffing, schedule, tracking & oversight,
event/exception
Address unresolved QA issues & conflicts
triggered Project
Address QA risks
Managers’ QA
Assign review & track QA action items to closure
activity review
Prepare & distribute review summary to all impacted parties
Involve all impacted groups
Review QAtatus (technical, cost, resource & schedule performance) against plan
Report & review current & projected utilization of critical resources against original plan
Address inter-group QA dependencies
Address unresolved QA issues & conflicts
Review & address QA risks
Assign, review& track QA action items to closure
Prepare & distribute QA Review summary to all impacted parties
Upper
management
resolves noncompliance
when it cannot
be resolved at
the project level
KPA
Execution
(activities)
Periodic independent Quality Assurance expert review/audit & report of QA group activities & work products
Not always mandatory. It
may be needed for
sheltered markets, or
when QA is difficult to
implement:
• Large, expensive,
custom built systems for
large customers who
have their own QA
groups, or
• Customers subject to
regulation & regulatory
standards
CAPABILITY LEVEL 2
QUALITY ASSURANCE ACTIVITIES
Consistent Process Repeatability
Managed & Controlled Plan
KPA
QUALITY ASSURANCE
A formally agreed upon project QA plan, under change control, such that
Goals:
Execution
•Plan Quality Assurance activities
the version utilized at any point in time, past or present, is known
•Objectively verify that work
(activities)
products & activities
comply with standards
•Communicate QA results &
Develop the project’s QA plan in parallel with, or as an integral part of, the overall project plan
activities to all impacted groups
•Upper management resolves
All impacted groups (including software & Project Managers) review the project’s QA plan
Develop
project
QA
plans
consistent
with
a
documented
procedure
noncompliance when
Manage & control the project’s QA plan
it cannot be resolved at the project
level
QA group’s authority & responsibility
QA resource requirement (staff, tools, facilities)
QA activities’ schedule & funding
(Software & business systems) QA group’s participation in the developing the overall (software & business system) project plan
Activities, tools & work products(software & other - e.g. documentation) to be evaluated by QA
QA audits & reviews
Follow the QA plan
Plan
Project’s QA standards & procedures
Quality
Assurance
Procedures for recording & tracking noncompliance issues to closure
activities
Documents to be produced by QA group
QA activity & results feedback method & frequencies to each group
Objectively
verify that
work
products &
activities
comply with
standards
Upper
management
resolves noncompliance
when it cannot
be resolved at
the project level
Communicat
QA results &
activities to
all impacted
groups
Include (software) QA
group in developing &
reviewing the (software)
project plan, its standards
& procedures
Verify compliance
Consult & review plans, procedures & standards for complying with organizational policy, external & project standards, plan contents etc.
QA certifies that the (software & business system) project plan, standards & procedures have been deployed & can be used for QA reviews/audit
Verify compliance against plan, standards & procedures
Record deviations & track to closure
Verify corrections
(Systems) QA verifies (Systems) engineering activity compliance
(Systems) QA verifies (Systems) engineering work product compliance
Conform to a written procedure in recording & processing (software) activities
& work product deviations from the plan or its standards & procedures
Evaluate deliverables before delivery to customers
Resolve deviation as close as possible to its origin (task leader, subproject
or project manager) when possible
Record & escalate unresolved deviations to designated senior QA manager
Periodically review escalated items until they are resolved
Manage and control the non-compliance record in a baseline
Report QA findings back to software engineering & other participating groups periodically
Managed & Controlled Non-compliance Record
A formally agreed upon non-compliant item record,
under change control, such that the version utilized at any
point in time, past or present, is known
Periodically review QA activities & findings with customer’s QA personnel
Periodically review QA activities & findings with QA personnel across the extended enterprise
Not always mandatory & all customers may not have QA groups.
It is needed for sheltered markets:
• Large, expensive, custom built systems for large customers who
have their own QA groups, or
• Customers subject to regulation & regulatory standards
CAPABILITY LEVEL 2
Consistent Process Repeatability
CONFIGURATION MANAGEMENT
Goals:
•Plan Configuration Management activities
•Identify, control & make selected work products
available on time
•Control changes to work products
•Communicate systems, software and component
baseline statuses to all impacted groups
INSTITUTIONALIZING CONFIGURATION MANAGEMENT
The project’s operating environment
&tools (including CM tools) must comply
with standards in order to ensure
consistently repeatable results
Commitment
Control changes
to (software)
work products
selected &
made available
to the project
team(s)
Ability
Publish Organization’s CM policy
Assign the project’s Configuration Management responsibility explicitly
Implement Configuration Management through the project’s full life cycle
Give projects a repository(s) for storing configuration components
Implement Configuration Management for: (1) All (software/systems) products delivered externally (2)
Designated internal (software/systems) work products (3) Designated tools used by the project
The SCCB may be a formal
organization in large companies,
or merely the Project & QA
leaders for small projects. It
authorizes the establishment &
contents of the systems baseline
Create a Software Configuration Control Board (SCCB) to oversee the project’s (systems) baseline
Plan
Config.
Managemt
activities
Create a Software
Configuration Management
Group (SCM) to manage the
project’s (systems) baseline
Authorize systems baseline establishment & kinds of items it will contain
Represent the Project Manager & all groups impacted by (systems) baseline changes
Review & authorize (systems) baseline changes
Authorize product assembly (build) from the systems baseline
Manage the project’s component & software library
Develop, maintain & distribute SCM plans, standards & procedures
Identify the contents of the systems baseline
Manage systems baseline access
Update the baseline with specific work products
Build systems products/deliverables from the baseline
Record configuration management actions
Produce & distribute SCM reports
Select &
control
(software)
work products
& make them
available to
the project
team
Provide adequate resources & funds for SCM
Assign a manager specific project SCM responsibility
Adequacy of, & access to, SCM tools (such as repositories, work stations, databases & other configuration management tools.)
Train SCM group
Know SCM objectives & procedures; can effectively use methods & tools
Train software & systems engineering, QA, Documentation & other project groups in SCM activities they must perform
Inform all
impacted
groups of
(software)
baseline
contents &
status
Institutionalization
Understand SCM objectives, practice & involvement in software activities
Understand their group’s & individual SCM responsibilities
Understand role-responsibilities of SCM & related groups, their interfaces & protocols
Understand project/organization’s SCM standards, methods & procedures,
Can effectively use SCM methods & tools needed to fill their individual SCM responsibilities
CAPABILITY LEVEL 2
Consistent Process Repeatability
CONFIGURATION MANAGEMENT
Goals:
•Plan Configuration Management activities
•Identify, control & make selected work products
available on time
•Control changes to work products
•Communicate systems, software and component
baseline statuses to all impacted groups
INSTITUTIONALIZING CONFIGURATION MANAGEMENT
Measure & Analyze:
Monitor Implementation
Measure SCM performance: resources, milestones, activity status, schedule, cost, change request volumes etc. against baseline plan
Periodic Upper Management SCM review
Timely & adequate upper management insight into SCM process
Technical, cost, staffing, schedule, tracking performance
Address unresolved SCM issues
Address SCM risks
Assign review & track SCM action items to closure
Prepare & distribute review summary to all impacted parties
Inform all
impacted
groups of
(software)
baseline
contents &
status
Periodic & event/exception triggered Project Managers’ SCM activity review
Periodic SCM group’s baseline
audit to confirm compliance with
documentation
Control changes
to (software)
work products
selected &
made available
to the project
team(s)
Review SCM status (technical, cost, resource & schedule performance) against plan
Report & review current & projected utilization of critical resources against original plan
Address inter-group SCM dependencies
Address unresolved SCM issues
Review & address SCM risks
Involve
all impacted
groups
Assign, review&
track
SCM action items to closure
Prepare & distribute SCM Review summary to all impacted parties
QA group’s SCM work product & activity audit & feedback report to confirm compliance
Compliance with SCM, SCCB, Software/systems
Engineering & other groups’ standards & procedures
Periodic systems baseline audit
KPA
Execution
(activities)
CAPABILITY LEVEL 2
Consistent Process Repeatability
CONFIGURATION MANAGEMENT
Goals:
•Plan Configuration Management activities
•Identify, control & make selected work
products available on time
•Control changes to work products
•Communicate systems, software and
component baseline statuses to all impacted
groups
KPA
Execution
(activities)
CONFIGURATION MANAGEMENT ACTIVITIES
Develop project SCM plan consistent with a documented procedure
Base SCM activities on a
documented & approved SCM plan
Develop the SCM plan in parallel with, and as an integral part of, the overall project plan
All impacted groups (including software & Project Managers) review the SCM plan
Manage & control the SCM plan in a baseline
SCM activity schedule, resources(staff, tools, computer & infrastructure facilities) & individual responsibilities
Required SCM activities & support from Software & business systems Engineering, & other groups
Deploy a configuration management library
as the repository of systems baselines
Support for multiple levels of control (eg: production code may require stricter controls than development versions)
Store & retrieve configuration items
Share (or move) configuration components between project groups & the library’s control (security) levels subject to security rules
Facilitates enforcement or application of standards to configuration components
Configuration (component) archival, recovery & version management
Validate products configured from repository & facilitate creating the right deliverables from the baseline
Storage, retrieval & maintenance of SCM records
Supports SCM reports
Maintenance of repository structure & contents (including backup, recovery & library administration)
Plan
Config.
Managemt
activities
Control
changes to
work products
selected &
made available
to the project
team(s)
Identify items that will be placed under
configuration management (in the repository)
Select &
control work
products &
make them
available to
the project
team
Use documented procedures to:
Selection is based on written criteria
Assign an unique identifier to each item
Associate each item with specific baseline(s)
Specify when, in the item’s lifecycle, it will be put under configuration management
Specify the item’s owner over its lifecycle from the configuration management perspective
Record, review, approve & track configuration item change requests & problem reports
Control Baseline changes
Give all impacted groups
access to standard reports
describing SCM activity &
the baseline’s contents
Inform all
impacted
groups of
(systems)
baseline
contents &
status
Systems Baseline
A formally reviewed and agreed upon set of
software & business systems components or
specifications that can only be changed through
formal change control procedures, and is the basis
for further development
Build & release products/
deliverables from the baseline
Conduct reviews/regression tests to eliminate unintended effects of changes on the baseline
Baseline only configuration items approved by the SCCB
Component check in/out procedure maintains baseline accuracy & integrity
SCCB authorization to build products/deliverables from the baseline library
Both internal & external products/deliverables released from the
baseline are built purely from components stored in that baseline
Record the status of every configuration item
Comply with a written
procedure to audit
systems baselines
Store enough detail of configuration management actions to not
only maintain every configuration item’s current state & contents,
but also to recover its previous versions
Maintain each item’s current state & history (of changes & actions)
Prepare adequately for the audit
Assess the baseline’s integrity
Review the baseline library (automated or manual system) structure & facilities
Verify accuracy & completeness of (baseline) library contents
Verify compliance with SCM standards & procedures
Report audit results to the project’s software & business system managers
Track resulting action items to closure
Managed & Controlled Configuration Items
A formally agreed upon set of components (tools,
deliverables & interim work products), under
change control, such that the version utilized to
build a project deliverable at any point in time, past
or present, is known
CAPABILITY LEVEL 2
Consistent Process Repeatability
CONTRACT MANAGEMENT
Goals:
•Select qualified contractors & subcontractors
•Agree on mutual commitments with contractors
•Maintain ongoing communication with contractors
•Track contractors’ performance against commitments
Commitment
INSTITUTIONALIZING CONTRACTOR MANAGEMENT
Publish written contract management policy
Designate
Project Contract
Manager(s)
Select
qualified
contractor
Contractor
A vendor responsible for providing some (or all)
project deliverables. The vendor must be
responsible for planning, tracking & oversight of
contracted deliverables in order to be termed a
contractor. The organization outsourcing the work
(prime) is responsible for ensuring deliverables
accepted satisfy requisite criteria.
Use written standards & procedures for selecting contractors
Manage contract based on contractual agreements
Contractual changes cannot be made without the involvement & consent of both contracting parties
Is either an experienced (software/system) engineer or has experienced (software/system) engineer subordinates
Responsible for contract Terms & Conditions and technical scope of contract
Responsible for selecting contractor, managing contract & arranging post contract support
Ability
Internal organizations
may qualify under this
definition of contractor.
Processes herein can
support interfaces
between internal groups.
Provide adequate resources & funds
Maintain
ongoing
communica
tn with
contractor
Assign managers & other project team members specific contract management responsibility
Adequacy & access to contract management tools (estimation, tracking, scheduling, spreadsheet & other)
Train (software) managers & other involved project team members in managing contracts, selecting & managing contractors (Grow, rather than appoint good, but
unprepared technical staff to manage contractors - planning contracts, evaluating bidders, their estimates & plans, selecting & managing the contractor etc.)
Orient (software) managers & other involved project team members to the project’s technology (business domain,
tools, methodology, standards, procedures, technology platforms etc - Necessary to grow, rather than appoint staff )
Measure & Analyze
Monitor Implementation
Agree on
mutual
commitments
with
contractor
Track status of contract management activities
Track contract management activities against baseline plan: cost &
actual delivery dates of contracted items to & from the contractor
Periodic Upper Management contract activity review
Periodic & event/
exception triggered
Project Managers’
review
Performance: Technical, cost, staffing, schedule, tracking & oversight,
Address unresolved issues & conflicts
Address risks
Assign, review& track action items to closure
Prepare & distribute Review Summary to all impacted parties
Temporary Employees are not
considered contractors, rather they are
considered the prime’s staff
Involve contractor & all impacted groups
Review contract status (technical, cost, resource & schedule performance) against plan
Report & review current & projected utilization of critical computer resources against original plan
Address inter-group dependencies
Address unresolved issues & conflicts
Review & address risks
Assign, review& track action items to closure
Prepare & distribute Review Summary to all impacted parties
Track
contractor
performance
against
commitments
Quality Assurance review/audit & report of contract management activities & work products’ status
KPA
Execution
(activities)
Contractor selection activities
Contract management activities
Coordination of configuration management activities with contractor(s)
Conducting planned reviews with contractor
Key contract milestone/phase completion reviews
Contractors’ deliverables acceptance process
CAPABILITY LEVEL 2
CONTRACTOR MANAGEMENT ACTIVITIES
Consistent Process Repeatability
CONTRACT MANAGEMENT
Goals:
KPA
• Select qualified contractors &
subcontractors
• Agree on mutual commitments Execution
with contractors
• Maintain ongoing communication (activities)
with contractors
• Track contractors’ performance
against commitments
Comply with a written procedure to
determine work that will be outsourced
Select
qualified
contractor
Comply with a written
procedure to select
contractor(s) able to perform
Agree on
mutual
commitments
with
contractor
Manage
contracted work
against contract
Select outsourced activities/ deliverables based on technical & nontechnical
factors, contractor s’ capabilities & the right requirements & system partitions
Create contract’s statement of work, standards & procedures from the overall
requirements, project plan, statement of work, standards & procedures
Agree on the contractor’s statement of work after baselining, reviewing & revising it with all impacted groups
Create the contractor selection plan concurrently with the his statement of work
Contractor proposal
Contractor’s performance record & references for similar work
Location(s)
Contractor’s engineering & management capabilities
Available staff (able to perform)
(Contractor) team’s prior experience & expertise with similar work
Resources (facilities, hardware, software, training etc.) available
Statement of Work
Scope, goals, constraints & assumptions (technical ,
schedule, budgetary, resource etc), sponsors & end users of
system, standards, responsibilities, impact & dependencies
(internal & external organizations)
Scope & objectives
•Software & systems life cycle, reasons
•Standards & procedures
•Work products
•Effort & cost estimates
•Size estimates (anticipated changes as well)
•Use of critical computer (& other) resources
•Schedules, milestones & planned reviews
•Risk assessments
•(Software & systems) engineering facilities & tools
T&C
Statement of Work
Overall project deliverables & requirements
Mutual obligations & dependencies with contractor(s)
Contracted deliverables
Conditions for revising & submitting deliverables
Contractor performance evaluation procedures & criteria
Review contractor’s plan & approve contract
Included in overall project (software) plan, or linked to corresponding items therein
Track contract activities & commitments against the contractor’s approved (written) project plan; communicate status
Track
contractor
performance
against
commitments
Revise contract (statement of work, T&C & commitments) consistent with a documented procedure
All impacted groups (of all parties bound by
the contract) review & consent to revisions
CAPABILITY LEVEL 2
CONTRACTOR MANAGEMENT ACTIVITIES
Consistent Process Repeatability
Management review
CONTRACT MANAGEMENT
Cost, schedule, financial &
Goals:
other management Risks &
KPA
• Select qualified contractors &
dependencies
subcontractors
Tech review
• Agree on mutual commitments Execution
Meeting tech.
with contractors
Commitments & correct
• Maintain ongoing communication (activities)
implementation of tech.
with contractors
requirements
• Track contractors’ performance
against commitments
Provide contractor insight to customers’ (&end-users’) needs
Review contractor’s performance against his approved plan - technical, cost, staffing & schedule
Review critical computer (&other) resources against his approved plan - track current estimates against original plan
The prime organization’s
Address mutual (critical) dependencies & commitments with contractor
management, following a
documented procedure, periodically
Address noncompliance with contract
coordinates, & reviews status, with
Address project risks that involve contractor’s work
contractor’s management
Address issues
conflicts that&contractor
cannot
resolve
internallyorganization, especially those that impact (software) engineering
critical&dependencies
commitments
within
contractor’s
Assign & track action items to closure
Track
Periodically engage contractor in
contractor
Provide contractor insight to customers’ (&end-users’) needs
technical review & interchange
performance
against
Monitor contractor’s technical activities
commitments
Validate contractor’s interpretation & implementation of tech. requmts
Validate contractor is meeting commitments
Verify timely resolution of technical issues
Use documented procedures to:
Formally review(Software/systems) Engineering
accomplishments at selected milestones
Outsourcing organization’s QA
monitors contractor’s QA ability &
implementation for the project
Outsourcing organization’s
Configuration Management
(CM) group monitors
contractor’s CM activities for
the project
Maintain
ongoing
communic
with
contractor
Test contracted deliverables
before accepting them
Plan reviews in writing in the contractor’s statement of work
Address contractor’s activity status, plans & commitments
Record issues, decisions & action items
Address (software & systems) risks
Revise contractor’s (software/systems) plan as needed
Periodic ability review- Adequacy of contractor’s QA standards/
resources/plans to properly monitor project performance
Implementation spot check - Spot check contractor’s project activities &
deliverables, & audit contractor’s QA records as needed
Implementation periodic check - (Periodically audit contractor’s internal QA
activity records to verify compliance with QA standards, procedures &plans)
Periodic ability review- Adequacy of contractor’s CM standards/resources/plans
Coordinate CM activities with contractor for ready integration
into specified target (or outsourcer’s project) environment
Periodic CM implementation check - audit contractor’s baseline library
for compliance with CM standards & procedures & management
Mutually review & approve acceptance procedures & criteria before testing
Document results
Action plan for failed deliverables
Periodically evaluate contractor’s performance (across contracts) & review with contractor
CAPABILITY LEVEL 3
Standardized Best Practices in use
LEVEL 3 ANALYSIS HIERARCHY
Process Capability
GOALS OF KEY PROCESS AREAS (KPAs)
ORGANIZATIONAL PROCESS FOCUS
Goals:
• Coordinate systems development & improvement
across the organization
• Identify software & systems process strengths &
Weaknesses against a standard
• Plan process development & improvement across
the organization
ORGANIZATIONAL PROCESS DEFINITION
Goals:
• Develop & maintain standard software & systems
process(es)
• Monitor & communicate use of standard
software & systems process(es)
TRAINING PROGRAM
Goals:
•Plan training
•Offer technical & management training courses
•Train individuals
STANDARD PROCESS DEPLOYMENT
Goals:
• Tailor the standard software/systems process for
individual projects
• Follow the tailored process for project planning
& management
Focus the organization on standardizing processes
Develop & monitor use of
standard processes
Provide relevant
training
Deploy standard
processes
BUSINESS SYSTEMS & SOFTWARE
ENGINEERING
Goals:
• Define, integrate & consistently perform software
& systems engineering tasks
• Keep work products mutually consistent
Engineer
components, systems
& software accurately
INTERGROUP COORDINATION
Goals:
• All impacted groups mutually agree on customer
requirements
• All impacted group agree on mutual
commitments between themselves
• Engineering groups identify, track and resolve
intergroup issues
Coordinate between
software/ systems
engineering & other
impacted groups
PEER REVIEW
Goals:
• Conduct peer reviews of work products in a
planned manner
• Identify and remove defects in work products
Institute peer review of work products & rectify defects
CAPABILITY LEVEL 3
Standardized Best Practices in use
ORGANIZATIONAL PROCESS FOCUS
Goals:
• Coordinate systems development &
improvement across the organization
• Identify software & systems process strengths &
Weaknesses against a standard
• Plan process development & improvement
across the organization
INSTITUTIONALIZING ORGANIZATIONAL PROCESS FOCUS
The standard process must cover activities, work
products, procedures, techniques and functions (like
QA or configuration management), as well as the
relationships between these components of process
knowledge. Processes tailored from standard processes
must refer to these to describe specific ways in which
they have been customized.
Commit to following a published organization wide
policy for coordinating systems development
Commitment
Require Creation & empowerment of the SEPG
Require periodic process assessments of project level processes for building systems & software - strengths & weaknesses
Require that project level processes must be tailored from the standard process
Require communication of improvements and relevant information on processes, tools and methods of each project to every other
Plan process
development
&
improvement
across the
organization
Upper management sponsorship of the initiative to standardize the systems development process
Demonstrate commitment to the systems development process to staff & management
Upper management oversight of
Long term funding, staffing & resource plan
the initiative to standardize the
Management and implementation strategy for process improvement
systems development process
Ensure alignment of standard process(es) with business goals & strategies
Advise priorities for systems process development & improvement
Participate in planning for systems process development/improvement; coordinate requirements
and issues with managers & senior staff, secure support and participation from staff and managers
Ability
Create SEPG
Full time, dedicated professional systems staff, optional part time support staff
Staff represents business systems and software disciplines (requirements analysts,
systems/software designers & builders, testers, configuration Management and QA staff,etc.
Coordinate
systems
development
&
improvement
organizationwide
Provide adequate resources & funds for activities mandated by the systems process
Train SEPG
Assign experienced specialists (Component reuse, CASE, CAPE and metrics specialists, trainers & course developers etc.)
Provide the right tools and automation (statistical analysis tools, publishing
tools, database management systems, process modeling tools etc.)
Conform to performance requirements of Training KPA in software/business systems engineering, process control techniques, change management,
including organizational change and technology transition, planning, managing and monitoring the business systems/software methodology, etc.
Orient (brief) SEPG and other software and systems groups on their roles, responsibilities and activities to implement the software/systems process
Identify
software &
systems
process
strengths &
Weaknesses
against a
standards
Measure & Analyze
Track status of process development and improvement activities
Track milestone & work completion, effort & funds expended, resource utilization, etc against
plan; track results of process assessments against previous assessments & recommendations
Monitor Implementation
Periodic Upper Management process
development and improvement activity review
Report and analyze status of software/systems methodology development activities against plan
Resolve conflicts and issues left unresolved at lower levels
Assign, review and track action items to closure
Prepare & distribute review summary to all impacted parties
KPA
execution
(activities)
CAPABILITY LEVEL 3
Standardized Best Practices in use
ORGANIZATIONAL PROCESS
FOCUS
KPA
Goals:
• Coordinate systems development
Execution
& improvement across the
organization
(activities)
• Identify software & systems
process strengths & Weaknesses
against a standard
• Plan process development &
improvement across the
organization
ORGANIZATIONAL PROCESS FOCUS ACTIVITIES
Identify findings that will be addressed
Guidelines for changes that will address the findings
Groups and persons responsible for implementing changes
Assess software/systems process periodically and develop action plans to address findings
Plan process
development
&
improvement
across the
organization
Plan software/systems process development/improvement activities (and keep plan updated)
Based on action plans from periodic
assessments and other initiatives
Specify and schedule activities
Assign responsibilities for activities
Identify resources including staff and tools
Review releases and revisions
Agreement of software/systems engineering
managers & upper management
Coordinate software/process development & improvement activities organization wide
Identify
software &
systems
process
strengths &
Weaknesses
against a
standards
Coordinate the use of the systems process repository
Standard software & systems process
Project software & systems processes
Monitor use of, and share or transfer the right processes, methods and
tools between different projects and parts of the organization
Coordinate training organization wide
Training plans on business systems/software development process and related subjects
Training prepared and delivered by SEPG or the Training Group (see the Training KPA)
Keep the users of business systems/software methodology and processes updated on projects and activities for developing and improving current processes
Coordinate
systems
development
&
improvement
organizationwide
CAPABILITY LEVEL 3
Standardized Best Practices in use
ORGANIZATIONAL PROCESS DEFINITION
Goals:
• Develop & maintain standard software & systems process(es)
• Monitor & communicate use of standard software & systems
process(es)
INSTITUTIONALIZING ORGANIZATIONAL PROCESS DEFINITION
Publish policy for developing and maintaining standard processes for business systems and software development
Develop &
maintain
standard
software &
systems
process(es)
Commitment
Requires definition of requisite standard processes
Requires project level customization of standards
Requires maintenance, use and access to process assets
Requires obtaining, organizing & using project
level feedback to improve standard processes
Ability
Process and work product measurement
Lessons Learned
Other feedback
Provide adequate resources & funds for Systems process development & maintenance
SEPG made responsible for systems process development and maintenance
Provide the right tools and automation (statistical analysis tools, publishing
tools, database management systems, process modeling tools etc.)
Train SEPG
Conform to performance requirements of Training KPA for software/business systems engineering, process analysis& documentation techniques, etc.
Track status of process development and improvement activities
Monitor &
communicate use
of standard
software/systems
process(es)
Track milestone & work completion, effort & funds expended, resource utilization, etc against plan;
track results of process assessments against previous assessments & recommendations
Measure & Analyze
Monitor Implementation
Periodic QA review of process assets, activities & work products for developing & improving software and systems processes
Follow development, deployment, maintenance & documentation standards
Control & use assets appropriately
KPA
execution
(activities)
CAPABILITY LEVEL 3
Standardized Best Practices in use
ORGANIZATIONAL PROCESS
DEFINITION
KPA
Goals:
• Develop & maintain standard
software & systems process(es) Execution
• Monitor & communicate use of (activities)
standard software & systems
process(es)
ORGANIZATIONAL PROCESS DEFINITION ACTIVITIES
Conform to internal policies, process and product standards
Conform to customer, regulatory & other stakeholders policies, process and product standards if any
Integrate appropriate state-of-the-art business systems and software engineering tools and methods into the standard process
Specify interfaces, transitions and protocols between business systems and software engineering disciplines
How impacted groups will interface (use, feedback, customize, change etc.) with the systems process
SEPG records, reviews and approve/disapprove proposed changes to the software/systems process in writing
Plan for changes to the process in use by projects in progress
Peer review software/systems process when developed or significantly changed
Standard Process placed under Configuration Management
Peers: Process &
Software Engineers
and other users of the
Estimating items
standard process
Design items
Construction items
Conform to organizational standards
Standards based items (meta-components)
Peer Review items
when documenting standard process
Appropriate scope of each item
Other requisite items
Relationships and interactions
between items address their sequence,
interfaces and interdependence
Procedures, practices, methods, technology
Process & Product Standards
Role-responsibility standards
Tool & Resource standards
Input standards
Work Products
Work Products for peer review
Readiness/Completion criteria
Record and maintain, in writing, approved software/systems life cycles
Product & Process data that should be collected
Follow a written procedure
to develop and maintain
the standard process
Develop &
maintain
standard
software &
systems
process(es)
Monitor &
communicate use
of standard
software/systems
process(es)
Conform to organizational standards
Record, review, take SEPG Approval for proposed changes before inclusion
Peer review of software & systems life cycles when developed or significantly changed
Manage & Control Life Cycle description(s)
Create & maintain criteria & guidelines for tailoring
Standard Process(es) to fit different projects
Project Life Cycle Selection & Customization
Customizing the standard process for the project
Standards for documenting for the customized process
Establish scope
Record, review, SEPG Approval for proposed changes before inclusion
Manage and control guidelines & criteria
Create and Maintain the Process Assets repository
Create and maintain a library of documents about the
tailored process for each project: plans, procedures,
standards, measures, training materials etc
Managed & Controlled
Specification
A formally agreed upon
specification, under change
control, such that the version
utilized at any point in time, past or
present, is known. Note that this
does not require the full blown
configuration management
discipline such as planning,
baselining, periodic audits,
reporting etc.
Collect and disseminate process information with the repository
Review the information in the repository to ensure its integrity and quality
Manage and control the information in the repository
Control access rights to ensure information quality and integrity
Review and include the right items
Catalog documents to facilitate access
Review revisions and update library
Make library available to projects and other users
Periodically review use of each document and use the information to maintain the library
Manage and control the contents of the library
CAPABILITY LEVEL 3
Standardized Best Practices in use
TRAINING PROGRAM
Goals:
• Plan training
• Offer technical & management training courses
• Train individuals
Commitment
INSTITUTIONALIZING TRAINING AND ACTIVITIES
Publish organization wide training policy
Requires identification of role specific skills/knowledge
Requires identification & approval of training vehicles & methods
Requires development of organizational skills by training individuals to fill project needs
Requires right mix of appropriate in-house & external training; articulate the policy for this
Create Training Group
Ability
Provide adequate
resources & funds
for training
Assign a Manager
Provide the right tools and automation (such as work stations, training design & presentation equipment & software, database tools etc.)
Provide the right training facilities
Staff the training group with the right mix of skills/knowledge
Orient (brief) Managers of software and systems groups on the training program
Plan
training
Measure & Analyze
Monitor Implementation
KPA
Execution
(activities)
Track status of training activities & the overall training program
Measure the training program quality
Periodic Upper Management Training Program review
Periodic independent training program evaluation
Audit training activities and work products, and report results
Every project has a training plan it maintains,
which addresses its specific training needs
Offer
technical &
management
training
courses
Plan, and revise organization wide training plan
in compliance with a written, standard procedure
Conduct training in
compliance with organization
wide training plan
Create and use a procedure
to waive training if
individual(s) have requisite
skills/knowledge for their
envisioned role(s)
Train
individuals
Prepare organization
level training courses
in compliance with
organization wide
training standards
Verify compliance with the standard process for developing and revising training plans
Verify compliance with the standard process for developing and revising training courses
Maintain training records in compliance with requisite standards
Verify that identified training needs of individuals are being met
Verify compliance with the training plan
Skill requirements, and their timing
Skills that will be acquired through training and skills that will be acquired in other ways (specify how)
Timed training requirements,and who will train
Method of training & whether it will be done by the project team, the training group or external trainers
Consider the project level training needs from project training plans
Specify and schedule specific training based on timed organizational skill requirements
Revise training plan in step with changing requirements
Review training plan and significant revisions with impacted individuals
Manage & Control training plan
Ensure impacted groups and individuals can access the training plan conveniently and easily
Time specific training with organizational requirement
Comply with planned source of training: external Vs. training group
Comply with training resource plan: Funding, staff, tools & facilities to conduct,prepare and procure training
Comply with training material standards developed by the training group
Consider the training groups schedule for developing and revising training courses
Comply with the training schedule based on projected timings and estimated numbers of trainees
Comply with procedures
Describe each training course
Review training course materials
Manage & Control course materials
Maintain training records
Keep records of people who complete training courses & approved training activities
Keep records of individuals who successfully finish the training required of them
Provide convenient access to individuals’ training records for use in staff and management assignments
INSTITUTIONALIZING STANDARD PROCESS DEPLOYMENT AND ACTIVITIES
CAPABILITY LEVEL 3
Standardized Best Practices in use
STANDARD PROCESS DEPLOYMENT
Goals:
• Tailor the standard software/systems process for
individual projects
• Follow the tailored process for project planning &
management
Publish organization wide policy for using the standard process and process
assets for planning & managing software & systems engineering projects
Commitment
Tailor the
standard
software/syst
ems process
for individual
projects
Require each project level process be tailored from the standard process
Require that deviations from the standard process be documented & approved
Require that every project conforms to the process that it has tailored for itself
Require that every project store the requisite metrics in the organizational process repository
Ability
Provide adequate resources & funds for managing the project in compliance with the standard process
Train project staff responsible for tailoring the standard process and its assets on their use and customization (as described in the training KPA)
Train Managers of software and systems groups on management of the technology, people and requisite administration
Measure & Analyze
Track Effectiveness of integrated business process and software management
Monitor Implementation
Periodic Upper Management project activities review
Project Manager reviews activities periodically or when contingencies or other events occur
Conduct QA reviews and audits of both project activities & work products, and report the results
Verify compliance with the process for creating & revising the project level process
Verify compliance with the process for project planning & planning for management of consonant risks
Verify compliance with the project level project management process
Verify compliance with the process for supplying the right
information to the organization-wide process repository
Verify compliance with the process for using the organization
wide process repository to tailor the project level process
KPA
Execution
(activities)
Follow the
tailored
process for
project
planning &
management
Tailor the standard process
to create the project level
software/systems process
Comply with a published
procedure when revising
the project level process
Choose approved project life cycle,
Modify chosen life cycle, if need be in compliance with tailoring criteria & guidelines
Document modifications in compliance with organization wide standards
Establish project life cycle and document it
Describe the project level software & systems process
SEPG must review and approve the tailored process; Upper Management must approve SEPG waivers & approved deviations
Contractual waivers and deviations from contractual requirements must be documented
and approved by both upper management & the project’s customers when appropriate
Manage & control the project level software/systems process
Lessons learned from organization
wide project monitoring
Proposed project level changes
Systematically document & review changes
Process and product measurements
Review and approve proposed changes to the project level process
Comply with a published procedure to develop and revise the project plan
KPA
execution
(activities)
CAPABILITY LEVEL 3
Standardized Best Practices in use
STANDARD PROCESS
DEPLOYMENT
Goals:
• Tailor the standard
software/systems process for KPA
individual projects
Execution
• Follow the tailored process for
project planning & management (activities)
Tailor the
standard
software/syst
ems process
for individual
projects
Follow the
tailored
process for
project
planning &
management
STANDARD PROCESS DEPLOYMENT ACTIVITIES
Comply with the project
level process in
managing the project
Collect, analyze and report requisite measurements; include these activities in the project plan
Estimate, plan and track based on key project tasks and work products described by the project level process
Establish and document readiness and completion criteria; use them to trigger or end key tasks
Document project re-planning criteria/triggers
Store lessons learned (management & technical) in the organization’s process repository
Systematically review lessons learned to plan, estimate, track and replan the project
Staffing plan must address project’s needs for special skills and business domain knowledge
Identify and document the project’s specific training needs stakeholders
Use the process
Consider differences and potential problems, and adjust plans and processes for interacting with different stakeholders
repository for
Compare & record business
planning &
Use data from similar projects if available
application & design approaches
estimating
Compare parameters for sizing, effort, cost, schedule, use of critical computer (& other) resources
Consider & record reasons for differences
Store the project’s planning & re-planning data, and actual performance in the process repository
& similarities in project parameters
Record the reasons, judgments and risks
for the project estimates
An independent group must review the estimation procedures process engineer have
Manage work Product
used, and guide them on use of historical information in the process repository
size and complexity in
Reviewers
ensure right use of procedures & data
Inflate risky estimates by a contingency factor
compliance with a
Peer & experts review estimates that lack consensus
Identify reusable components
published procedure
Identify and closely monitor factors that might affect work product size & complexity
Document rationale for contingency
Establish a threshold of size and complexity for each
Assess & record risk of removing or reducing contingency
managed item, which will trigger action if crossed
Manage work Project
cost & effort in
compliance with a
published procedure
Manage use of
computer resources in
compliance with a
published procedure
Comply with a
published procedure in
managing critical
paths and critical task
dependencies in the
project’s task plan
Considerations would include
geographical locations &
spread of project groups &
contractors, size &
complexity, stability of
requirements, the
development environment, the
target operating environment,
staff experience with the
business & technology,
resource availability, etc.
Risk Management
Experience shows that non-communication of risk is the
biggest risk and failure of risk management. Risks may
involve schedules, costs, functionality, timely throughput or
response, process availability, information quality, adequacy
of critical computing resources etc. Early identification of
risky objectives, events and contingencies, in tandem with
close monitoring or early implementation and course
correction via prototypes or staged implementation
strategies may help manage or pre-empt risk
Comply with the
published procedure for
assessing, managing and
recording project risk
Adapt effort, cost & staffing profiles to fit the project; use historical data if available
Adjust the parameters used for estimating cost and productivity to fit the project profile
Estimate overall effort and cost from those of individual tasks to facilitate effective cost & effort management
Review the actual cost and work completion against the plan to revise estimates of remaining effort & cost
Establish a threshold of projected cost & effort for each task (activity or phase), which will trigger action if crossed
Update estimation parameters
& models when requirements
change significantly
Use actual productivity &
cost data when available
Estimates based on analysis, simulations, prototyping or pst experience
Record rationale & data sources
Record assessments of resemblance & differences in design &
application between the project and historical reference
Record the reasons (& risks for credible estimates
Collaborative Development
Incorporate collaborative principles from
Workforce Development
Obtain/tune critical computer resources to meet the project’s operational and development (& analysis) requirements
Meet computer resource requirements of software & business systems components
Inflate initial estimates of critical computer resources by a requisite risk factor; document it with reasons
Establish a threshold of projected use of critical computer resources, which will trigger action if crossed
Comply with the project level process in scheduling funds, tasks, milestones, commitments, reviews, critical dependencies & staffing
Identify, negotiate and flag critical dependencies in the project & software schedules
Flag critical paths in the project & software schedules
Regularly track critical paths and dependencies
Document a threshold estimate for each critical path, which will trigger action if crossed
Identify and manage risk in compliance with a published plan
Review and revise priorities
Comply with the project level process in developing contingency plans over its full life
and risk management plans at
Document alternatives and criteria for choosing each
checkpoints/incidents
Conduct peer reviews before releasing the the software/system, or its significant revisions/changes
Monitor risks to refine risk
Manage and control the risk management plan
assessment & risk management plans
Track & re-assess risks at select project checkpoints, or when
significant changes impact the project; revise plan if need be
Communicate risks, results of mitigation & risk management plan to software, business systems and all impacted groups
Review each project periodically to align it with projected user, customer and business need
Identify options, assess impact &
feasibility, consider providing
reserves, etc.
CAPABILITY LEVEL 3
Standardized Best Practices in use
BUSINESS SYSTEMS & SOFTWARE
ENGINEERING
Goals:
• Define, integrate & consistently perform
software & systems engineering tasks
• Keep work products mutually consistent
INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES
Publish the policy for performing prescribed activities in
software & business systems engineering projects
Commitment
Ability
Provide adequate funds
& resources to execute
software/business
engineering tasks
Require each project perform the tasks prescribed by the (project level) tailored process
Require that the right tools and methods be used to build the business system & software
Require that every plan task and product be traced back to a requirement it supports
Sufficient availability of adequately skilled persons for every task
Sufficient supply and availability of requisite tools for every task
Train technical project staff adequately to enable them to measure up to their roles in the project
Orient technical project staff adequately to enable them to measure up to their roles in the project
Orient Managers of software and systems groups, including project managers on the technology used by the project
Keep work
products
mutually
consistent
Measure the quality & functionality of the product delivered by the project
Measure & Analyze
Track status of business process/software engineering activities
Periodic Upper Management project activities review
Define,
integrate &
consistently
perform
software &
systems
engineering
tasks
Project Manager reviews activities periodically or when contingencies or other events occur
Conduct QA reviews and audits of both project activities & work products, and report the results
Monitor Implementation
KPA
Execution
(activities)
Integrate the right
methods & tools into
the project level
process
Comply with the
project level
process when
developing,
maintaining,
recording and
verifying
requirements.
KPA
Execution
(activities)
Focus on service reuse
for new service and
solution development
Integrate engineering tasks
in compliance with the
project level process
Choose the right methods &
tools for the project, and
document the reasons for each
Choose the right model for the project
Product development and
maintenance tools are also governed
by configuration management
Review & verify accuracy, consistency, completeness, feasibility & testability of requirements
Verify compliance with initiation & completion criteria for every software/systems engineering task
Verify product compliance with requisite standards and requirements
Verify compliance with requisite testing requirements
Verify compliance with published plans and procedures for systems acceptance testing
Verify that test acceptance criteria complies with the published test plan
Verify satisfactory test completion & record keeping
Verify problems & defects are recorded, tracked & addressed
Verify that requirements are traced through to design, code/knowledge component & testing
Verify compliance of published operating & maintenance instructions against
published baselines & requirements before releasing the product for use
Requirements analysts review requirements, identify and resolve issues.
Requirements analysis methods are effective (for example, Object Oriented Analysis, Knowledge Artifacts, etc.)
Record requirements,alternatives, and their rationale
Analyze clarity, feasibility, mutual consistency, testability and completeness of requirements; review & resolve issues with originators of problem reqirements
Record requirements for automating the business process
Systems and acceptance testers verify testability of each requirement
Validate the method(s) of ensuring that all mutually agreed upon requirements will be satisfied
Ensure peer review of consolidated & published requirements before finalizing it
Approve the consolidated requirements by requisite managers (for example, project managers, engineering & testing managers (business process, software, etc.)
Review the requirements document with end users (and customers where appropriate)
Put the requirements document under configuration management
Change requirements for automation whenever a changes in overall requirements impacts it
CAPABILITY LEVEL 3
INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES
Standardized Best Practices in use
BUSINESS
SYSTEMS &
KPA
SOFTWARE
Mutually consistent
ENGINEERING
Execution
plans, processes,
Goals:
• Define, integrate & (activities)
requirements, software,
consistently perform
test plans & procedures,
software & systems
engineering tasks
Comply with the project level
etc.
Develop and review design criteria (for example, verifiability, compliance with standards etc.)
• Keep work products
process when developing,
Business process & software designers review requirements, ensure issues, if any, are resolved
mutually consistent
maintaining, recording or
Establish and document readiness and completion criteria; use them to trigger or end key tasks
verifying the process design that
Comply with mandated & appropriate standards
will satisfy requirements and will
Use effective design methods to design software & business systems
be implemented by software
Develop the software & systems architecture early, within the constraints imposed by the chosen project life cycle
Review the architecture;resolve issues that may impact detailed design
Base detailed design on the architecture
Publish the detailed design and the architecture; cover components, hardware, actors (mechanical & human) & interfaces between them
Peers review the design document before finalizing it
Put the design document under configuration management
Comply with the
Change the design document whenever changes in requirements impact it
project level process
to code/assemble,
Builders of software/the business process (coders/assemblers) review requirements & the design to ensure that all issues that impact their work are resolved
maintain, document
Effective methods are used to build (code/assemble) the business system
& verify the
Account for customer/user needs, priorities, difficulty, integration & test issues when planning & sequencing work products (units of code/components)
software/ business
Peers review each unit of code/assembly of components (or Knowledge Artifacts) before the unit is finalized
process design that
Put the code/component assemblies under configuration management
will satisfy
requirements
Change the code/component assembly whenever requirement or design changes impact them
Define,
Right level & depth (for example, unit, integration, acceptance tests)
integrate &
Establish Testing environment for testing with existing services
Right test strategy & techniques (for example, black box, statistical etc.)
consistently
Develop and review test criteria with the right customers and end users
Right scope and coverage
perform
Use effective test methods
Comply with the
software &
project level process
Test adequately
systems
when testing the
Establish & use readiness criteria for each test level (for example completion of peer reviews, successful testing of individual components, etc.)
engineering
software or business
Conduct regression tests at appropriate levels when software, components or environments change
tasks
system
Peers review test plans, procedures and cases before they are considered complete
Manage & control test plans, procedures & cases
Change test plans, procedures & cases when the requirements, design, code or components being tested change
Publish integration test plans, based on the project plan
Staff responsible for requirements, design and acceptance testing review integration test cases & procedures
Test for integration with the right versions of published requirements & designs
Approach to testing & verification
Responsibilities of each stakeholder
Assign
timely
resources
for
testing
to
allow
adequate
time
to
prepare
Test facilities, equipment, tools
Plan & execute
Review & get approval of published acceptance & systems test plans from the right end users and customers
& other support requirements
acceptance tests to
The test group that plans test cases & procedures must be
Acceptance criteria
demonstrate requirements
independent
of
those
who
make
the
software
or
business
system
have been satisfied
Publish and review test cases and procedures with the right customers & end users before testing
Test against a baseline - published requirements, systems & software
Trace defects back to root causes - work
Record & track problems that emerge from testing to closure
Record test results and use them to determine if requirements have been satisfied
Comply with the
products & work steps. It will prepare the
project level
Manage & control test results
organization for quantitative analysis of
process to develop
& maintain
defects at Level 4
Use the right documentation tools & methods (word processors, graphics, document reuse tools, repositories etc.)
documents which
Documentation specialists actively participate in planning, developing & maintaining documents
will be used to
The right stakeholders (customers, designers etc) review early (draft) versions of documents, as early as possible in the project; record & act on their feedback
operate & maintain
Match & verify final documents against the software/business systems baseline for acceptance testing
the software/
Peer review documents
business system
Manage & control documents
The right stake holders (users, customers, systems maintenance staff etc.) review & approve the final documents that impact them directly
Comply with the project level process when
planning or executing integration tests
Keep work
products
mutually
consistent
Collect & analyze defect data from peer reviews in
compliance with the project level process
Keep work products
mutually consistent
Document work products & make the documents easy to get
Trace requirements, designs, components, code & test cases to their source, and also to subsequent projects
Manage and control documents that trace the connections above
Analyze & change work products, plans, activities & processes in step with growing understanding
Determine impact before changing
If requirements drive change,
change requirements first
Coordinate changes: products, plans,
process specs & activities
Negotiate with, and communicate
changes to all impacted groups
CAPABILITY LEVEL 3
Standardized Best Practices in use
INTERGROUP COORDINATION
Goals:
• All impacted groups mutually agree on customer
requirements
• All impacted group agree on mutual commitments
between engineering groups
• Engineering groups identify, track and resolve
intergroup issues
INSTITUTIONALIZING INTERGROUP COORDINATION AND ACTIVITIES
Commit to a following published organization wide policy that will establish cross functional
teams of stake holders with a mandate to produce the final deliverables of each project
Project objectives and requirements must be reviewed and agreed upon by all stakeholders in the team
Stakeholders coordinate plans and activities
Maintain a positive environment, encouraging teamwork, mutual support, interaction & coordination
Commitment
Ability
All impacted
groups
mutually
agree on
customer
requirements
Provide adequate resources & funds for
coordinating the activities of stakeholders
Coordinate tool compatibility between stake holders
Train all managers in team work
Orient (brief) the task leaders of each group on the processes, methods & standards of the others
Orient team members of the cross functional team on working as a team
Measure & Analyze
Track status of cross functional coordination
Monitor implementation
Periodic Upper Management process review
Project Manager’s Periodic or event based activity review
Periodic Upper Management process activity review
KPA
Execution
(activities)
Engineering
groups
identify,
track and
resolve
intergroup
issues
All impacted
group agree on
mutual
commitments
between
themselves
Customers & end users (or groups such as
marketing that speak for them) participate with
engineering groups to articulate clear requirements
Prioritize & identify critical requirements & characteristics
Negotiate critical dependencies & constraints
Record agreed upon acceptance criteria for the end product that will be delivered to customers
Track & review design & development activities for hardware, software
& components (including Knowledge Artifacts & their subassemblies)
Assess & track cross functional risk
Coordinate activities
Clarify requirements & design issues; address & resolve project level conflicts if any
Manage issues
Stakeholders work together to coordinate
Joint solutions & recommendations to address problems
activities & resolve technical issues/risks
Address cross functional issues
Project schedule
Contractual and technical issues
Communicate cross functional commitments, coordinate &
Responsibilities of each group
The plan is a baseline
track work done, in compliance with a published plan
The plan coordinates all stakeholder activity
The plan is easily accessible and available to all stakeholders
The plan includes all mutual commitments of all stakeholders & is kept up to date
A group that accepts work products produced by others
The plan reflects progress and project level changes; is updated
must review them to ensure that they meet their needs
especially when milestones are completed, or significant changes occur
The plan is reviewed by, and agreed upon by all stakeholders, especially the project manager
Explicitly define every
critical dependency
The work product(s) that will change hands
Mutually negotiate critical dependencies
Who will produce & accept the work product(s)
Resolve available Vs. required work product dates with the project schedule
When the work product(s) will be produced
Record,
review
&
mutually
agree
between
on
dependencies
between
Acceptance criteria for these work product(s)
Identify & track
producers
and
receivers
of
every
critically
dependent
work
product
critical inter-group
Regularly
track
critical
dependencies
and
take
requisite
corrective
actions
dependencies
Actual or expected status/completion
dates against the coordinated plan
Evaluate impact on future activities &
A published procedure is used to address unresolved cross functional issues
milestones of late or early completion
Report back problems, actual and
anticipated, to the right managers
Stake holders periodically exchange technical and other kinds of relevant information
Articulate customer wish lists & needs
Monitor status of technical activities
Align interpretation and implementation of requirements, as well as expectations across all stakeholders
Review commitments to ensure that they are being met
Review technical risks & issues
CAPABILITY LEVEL 3
Standardized Best Practices in use
PEER REVIEW
Goals:
• Conduct peer reviews of work products in a planned manner
• Identify and remove defects in work products
INSTITUTIONALIZING PEER REVIEW AND ACTIVITIES
Publish organization wide peer review policy
Commitment
Ability
Train
peer
review
leaders
Conduct peer
reviews of
work
products in a
planned
manner
Prepare and distribute peer review materials
Lead the peer review
Review distributed peer review materials
Participate in peer review, identify defects; participate in follow up reviews to rectify or follow up on defects
Monitor rework of work products that had to be rectified (based on its peer review)
Record & report peer review findings
Train peer review participants
Measure progress, & track status of peer review activities
Measure & Analyze
Monitor Implementation
QA audits or reviews
peer review activities
& work products;
reports its findings
KPA
Execution
(activities)
Identify and
remove
defects in
work
products
Require identification of a standard set of work products that must be reviewed by peers for all projects
Require each project identify its special work products that will be reviewed by peers
Require leaders be trained in leading peer reviews
Require that peer reviews focus on work products under review, not those responsible for producing them
Require that management does not use peer reviews to evaluate individual performance
Provide adequate
resources & funds for
peer review of each
work product that
must be so reviewed
Plan peer reviews;
publish plans
Conduct the peer
review in compliance
with the published
procedure
Number & frequency of reviews;
Defects discovered by peer review
Numbers & proportion of work products reviewed
Number of work products reviewed against plan
Actual Vs. planned effort spent on peer reviews
Rework & rectification measurements
Verify reviews are being conducted as planned
Verify adequate training of peer review leaders to fill their roles effectively
Verify adequate training of peer review participants to fill their roles effectively
Verify compliance with peer review preparation, conduct & follow up processes; verify follw up actions are being taken
Verify peer review reports are complete, accurate, and timely
Identify work products that must be reviewed; include the organization wide standard set of work products that must be peer reviewed.
Schedule work product reviews; identify trained review leaders and participants for each peer review expected in the near future
Trained leaders lead peer reviews
Distribute review materials with enough lead time before the review to give reviewers adequate time to prepare
Each reviewer knows the role assigned to him or her for the peer review session
Enforce readiness & completion criteria; report issues involved in satisfying these criteria to the right managers
Interpret and use review criteria checklists consistently
Track action items to resolution
Tailor checklist to fit the work product under review
Tasks are considered complete not only after finishing requisite
Peer review check lists; also review them with likely users
peer reviews, but also after all required rework is completed
Record peer review
information
To be fruitful, the review must be of work
products, not people or organizations. The
review leader must enforce & facilitate this
key principle
Defects must not be used to evaluate
individuals or organizations. It will
undermine the purpose & effectiveness of
the peer review
Examples of Checklist Items
Compliance with standards & procedures,
completeness, correctness, maintainability,
compliance with construction rules, etc.
CAPABILITY LEVEL 4
Quantitative Quality Management in Place
LEVEL 4 ANALYSIS HIERARCHY
Process Capability
GOALS OF KEY PROCESS AREAS (KPAs)
QUANTITATIVE PROCESS
MANAGEMENT
Goals:
•Plan activities to quantitatively manage
business systems & software development
processes
•Quantitatively control business systems &
software processes
• Establish & use requisite quantified
tolerances from the organization’s standard
process(es)
QUANTITATIVE PRODUCT QUALITY
MANAGEMENT
Goals:
•Plan activities to quantitatively manage the
quality of business systems & software
produced by software and systems engineering
projects.
•Define measurable goals and priorities for
business systems & software produced by
software and systems engineering projects.
• Quantify, track and manage progress towards
these goals
Assure process quality
Assure product quality
CAPABILITY LEVEL 4
Quantitative Quality Management in Place
QUANTITATIVE PROCESS MANAGEMENT
Goals:
• Plan activities to quantitatively manage business systems & software
development processes
• Quantitatively control business systems & software processes
• Establish & use requisite quantified tolerances from the
organization’s standard process(es)
Publish, & Commit to an organization wide
policy for measuring & quantitatively controlling
the project level software/systems process
Commitment
Require compliance with a published project level plan to quantitatively control the project level software/systems process
Require that individuals’ performance information be kept confidential, and access to it appropriately guarded
Publish, & Commit to an organization wide policy for measuring
tolerances in performance parameters of activities & work products of
the organization’s standard software/systems process(es)
Plan activities to
quantitatively
manage business
systems &
software
development
processes
Ability
Establish &
use requisite
quantified
tolerances
from the
organization’s
standard
process
“Quantitative Control” means any quantitative or statist
method that will analyze performance, identify reasons f
variation (for example, transient conditions such as
inadequate computer capacity, specific individuals or
organizational units taking unexpected actions, unexpect
factors in the business environment, etc.), and bring the
performance within well defined limits.
Assign responsibility for
coordinating quantitative process
management to the SEPG
Provide adequate resources & funds for
quantitative process management activities
Require analysis of process performance and maintenance of a
baseline of tolerances for performance parameters
Require projects use the baseline to set performance goals
Responsibility for quantitative process management
activities of projects sits with managers & task leaders
of groups responsible for the corresponding activity
Enable and institute an organization wide measurement program
Provide the right tools and automation (statistical & quantitative analysis tools, problem tracking tools, database management systems, etc.)
Commitment & support for requisite data collection & analysis
Train individuals & support staff engaged in quantitative process management appropriately
Orient those engaged in projects & related activities on the value and goals of quantitative process management
Measure & Analyze
Measure & track the status of quantitative process management activities
Monitor Implementation
Quantitatively
control
business
systems &
software
processes
Periodic Upper Management quantitative process management activity review
Periodic & event based Project Manager’s quantitative process management activity review
QA review/audit of quantitative process
management activities & work products
Verify that the plans for quantitative process management are being followed
Verify that the procedures for quantitative process management are being followed
Verify that requisite data for quantitative process
Requisite data exists
management is being collected & analyzed
Requisite data is collected
The collected data is needed
The data is aligned with the goals
of the measurement program
The cost of data collection is justified by its value
The data is tapped at the right place,
& the right point in the project’s life
The data is timely, accurate, valid & reliable
The confidentiality of the
data is adequately protected
KPA
execution
(activities)
CAPABILITY LEVEL 4
Quantitative Quality Management in Place
QUANTITATIVE PRODUCT QUALITY
MANAGEMENT
Goals:
•Plan activities to quantitatively manage the
quality of business systems & software
produced by software and systems
engineering projects.
•Define measurable goals and priorities for
business systems & software produced by
software and systems engineering projects.
• Quantify, track and manage progress
towards these goals
QUANTITATIVE PROCESS MANAGEMENT ACTIVITIES
KPA
Execution
(activities)
Comply with the published procedure
for formulating each project’s
quantitative process management plan
Stick to the project’s
published quantitative
process management plan
Plan activities
to
quantitatively
manage
business
systems &
software
development
processes
Quantitatively
control
business
systems &
software
processes
Activities must support plan objectives
Measure & analyze tasks & activities
Stick to planned activities & schedules
Measure and analyze Service Reuse
Conform to planned metrics & measurement procedures
Stick with planned individual & group responsibilities for activities
Use the planned staff, tools & other planned resources for each activity
Follow quantitative process management procedures
The project level process must prescribe the project’s
data acquisition & quantitative analysis strategies
Follow a published procedure
when collecting metrics data
Comply with a published
procedure and quantitatively
control the project level
software/systems process
Communicate results of
quantitative measurements
by distributing reports to
the right stakeholders
Establish &
use requisite
quantified
tolerances
from the
organization’s
standard
process
Align the plan
Peers review the plan
SEPG reviews the plan
Manage & Control the plan
Comply with a published
procedure to create &
maintain the baseline of
tolerances for the
organizations standard
process(es)
Align with the organization’s strategic product
quality, productivity & time to market goals
Align with the project’s product quality, productivity & time to develop goals
Derive the plan from the organization’s standard process
Base the plan on the project level software/systems process
Factor in the actual performance of similar project level software/systems processes
Plan for Business Activity Monitoring for identifying business process bottlenecks
Align with the organization’s measurement program
Consider task dependencies & relationships
Consider project work products and their mutual relationships,
as well as their relationships with the project level process
Consider points of process control and data acquisition
The data must support organizational and project objectives
Precisely define each metric & its use, and data items that must be collected,
their uses, analysis, and the process control points they will be tapped from
Consider the entire software/business system life, pre and post development
through retirement when determining what metrics will be needed
The scope of measurement must include the features of key activities and the
major work products of the software/systems process
All projects must collect the data prescribed by the organization’s standard software/systems process
Governing processes (control activities) must control the requisite parameters
being measured as a natural and integral part of the software/systems process
Metrics must support the analyses prescribed in the plan
The quality of metrics data (validity, reliability, accuracy & timeliness) must be assessed by an independent group
Preserve the metrics data in the process repository
The procedure defines data analysis activities, the inputs, processing, outputs, techniques, decision criteria & actions
The procedure restricts the scope of measurement to the activities of the project level software/systems process
The procedure specifies appropriate and valid measurements for the characteristics it purports to measure
The procedure specifies expected means and variances for each metric
The procedure defines tolerances for each metric and establishes it as the baseline
The procedure compares the actual value of each metric to its expected mean and variance
The procedure describes adjustments that will bring out-of-tolerance processes back into prescribed limits
The procedure establishes baselines for metrics definition, actual values and acceptable limits
Manage & control process performance baselines
Review results of the analysis with those who are affected by it, before reporting it to others
Managers (including upper management) and task leaders must get the regular reports they need
The Quality Assurance group must get the regular reports it needs
Managers and task leaders get specialized reports on request
The procedure requires that tolerances for process parameters be computed from corresponding performance
histories & expected statistical values of those parameters (which are stored in the process repository)
The procedure requires that tolerances of the organizations standard process be regularly updated based
on corresponding tolerances of individual projects
The procedure requires that the tolerances of the organization’s standard process be published & be easily
accessible to all those who will need and use it.
The procedure asks that trends in tolerances of the standard process be analyzed to predict likely
problems and to identify opportunities for process improvement
The procedure asks that the baseline tolerances in the standard process be Managed & Controlled
In a break from the past, when a substantially different kind of project is undertaken, the procedure asks that the project
establish a new tolerance baseline, and that this be an integral part of the project level customization of the standard process
The procedure asks that the impact of changes to the standard process on the tolerance baseline be
tracked,analyzed and assessed
CAPABILITY LEVEL 4
QUANTITATIVE PRODUCT QUALITY MANAGEMENT
Quantitative Quality Management in Place
QUANTITATIVE PRODUCT QUALITY MANAGEMENT
Goals:
• Plan activities to quantitatively manage the quality of business
Commit to a following published organization wide
systems & software produced by software and systems
software & business process quality management policy
engineering projects.
• Define measurable goals and priorities for business systems &
Each project’s quality management activities must support the firm’s
software produced by software and systems engineering projects.
commitment to enhance the quality of its business processes & software
• Quantify, track and manage progress towards these goals
Every project must define & measure quality metrics for key work products & the business process/software
Every project must define & measure progress towards quality goals
Provide adequate resources
for key work products & the business process/software it is creating.
& funds for managing the
Commitment
Assign role responsibilities for managing quality to stake holders; define the criteria
quality of work products
that each stakeholder will use to determine its success in the role assigned to it
Ability
Specialized quality engineers (such as those who specialize in work product reliability, safety etc. are on
Train project participants,
hand to participate in setting work product quality goals and in reviewing progress towards the goals set
especially engineers, writers,
Provide the right tools and automation (statistical tools, quality tracking & analysis tools, data collection tools, spread
QA & configuration
sheets, database management systems, process & life cycle simulators, process & code audit and analysis tools, etc.)
management staff in relevant
product quality management
activities
Define
Planning quality goals & commitments for work products
measurable goals
Measurement & control of quality with the project level software/systems process
and priorities for
Train project participants, especially engineers, writers, QA & configuration management staff in relevant product quality management
business systems
& software
Purpose & benefits of quantitatively managing product quality
produced by
Track status of software & business
Methods & techniques for collecting requisite information, measuring, controlling
software and
system quality management activities
Measure & Analyze
& planning the quality of the software & systems process and its work products
systems
engineering
Upper Managers’ periodic quality management review
Audit or review the project’s quality plan
projects
Project Manager’s periodic & event based quality management review
Monitor Implementation
Audit or review the process for setting & tracking quality goals
QA review of Quality Management activities & work products
KPA
Execution
(activities)
Follow the published procedure
to create & maintain the project
level quality plan
Plan activities to
quantitatively
manage the
quality of
business systems
& software
produced by
software and
systems
engineering
projects
Quantify, track
and manage
progress
towards these
goals
Base quality management
activities on the quality plan
Define, monitor & revise
quantitative quality goals
throughout the project’s
life
Appropriately
apportion
quantitative
quality goals
among the
project’s
contractors
Measure and analyze
actual work product
quality against goals
based on specific events
Understand customers’, end users’& producers quality needs (for example through focus groups, product evaluations, surveys etc.)
Trace customer, end user & producer quality needs & priorities back to software/systems requirements & goals)
Record an assessment of whether the project level process is capable of meeting work product quality goals
Align the project’s quality plan with that of the firm (or the part thereof in the scope of the change)
Derive the quality plan from plans of other projects, past or present
Update the quality plan at the start, and at every major milestone & whenever requirements change
Peer review the quality plan
Review the quality plan with stakeholders (or their representatives)
Upper management review of quality plans
Manage & control the quality plan
Everybody impacted by the quality plan can access it easily
Address quality measurement points in the process
Identify key quality goals, from customer & end user perspectives, for software & the business process
Identify planned actions to improve on past performance (quality)
Identify Quality measurement activities such as testing, peer reviews, simulations & iterative prototyping,etc.)
Address work product quality goals in terms of their planned features, especially those which will render
work products unusable or undesirable from the customer and end user perspectives if not satisfied
Address planned actions if projections show that work product quality will be short of that planned
Identify work product quality features(performance in functionality & information quality, usability, creatability & maintainability)
Identify specific quantified quality measures for (requisite) work product features
Specify quality goals in terms of acceptable ranges for each quantified measure
Publish the quality goals as an integral part of the project plan
Segregate and publish quality goals for each step of the software/system development life cycle
Revise quality goals in step with evolving understanding of customer, end user and
the producer’s needs, and also the software/business system that will be produced
At the beginning of each task, review quality goals
At the beginning of each task, identify
Plan & execute project tasks to address its work product quality goals
quality goals relevant to the task at hand
Measure the quality of work products of each stage of the
At the beginning of each task, identify
product life cycle, through development & retirement
task plans for reaching quality goals
Analyze quality measurements to determine if goals have been met
At the beginning of each task, review any
Act in compliance with the quality plan to align
changes made to address requisite quality goals
work product quality with corresponding goals
Resolve conflicts between quality goals
Analyze, & resolve conflict based on cost of achieving each conflicting goal
Consider alternative goals aligned with business strategies & short term priorities
Give users & customers (or their representatives)
a voice in balancing conflicting quality goals
Revise work products and plans to reflect compromises
LEVEL 5 ANALYSIS HIERARCHY
CAPABILITY LEVEL 5
Continuous Improvement and innovation Institutionalized
Process Capability
GOALS OF KEY PROCESS AREAS (KPAs)
DEFECT PREVENTION
Goals:
•Plan defect prevention
•Seek & Identify common causes of
defects
• Prioritize and systematically eliminate
causes of defects
TECHNOLOGY CHANGE
MANAGEMENT
Goals:
•Plan absorption of technological
changes.
•Evaluate the impact of new technology
on quality & productivity.
• Make the right new technologies the
norm in the right practices throughout
the organization
PROCESS CHANGE MANAGEMENT
Goals:
•Plan continuous process improvement.
•Organization-wide participation in
process improvement and innovation.
• Continuously improve the
organization’s standard
software/business systems development
process, and the project level processes
derived from it
Identify, anticipate & prevent defects &
their root causes
Integrate preventative processes into the
organization's standard software/systems
processes
Optimize the process of choosing
technology to upgrade quality,
productivity, & timeliness of
software/systems processes
Institutionalize & make routine processes
for the transfer of technology across
projects and organizational units
Deploy a formal & organization-wide
standard process for continual
technology process improvement &
innovation
INSTITUTIONALIZING DEFECT PREVENTION
CAPABILITY LEVEL 5
Continuous Improvement Institutionalized
DEFECT PREVENTION
Goals:
• Plan defect prevention
• Seek & Identify common causes of defects
• Prioritize and systematically eliminate causes for defects
Publish, & Commit to an organization
wide policy of defect prevention
Commitment
Every project
must publish, &
Commit to an
project specific
policy for defect
prevention
Plan defect
prevention
Require long term plans for funding defect prevention, staffing & allocating needed resources for it
Require that requisite resources be allocated for defect prevention activities
Require org. wide implementation of defect prevention activities to improve software, business systems, the processes that make them
Require that the results of defect prevention activities be reviewed to ensure that they are effective
Require that management & technical action items identified by defect prevention activities be recorded, addressed, tracked to resolution
Require that defect prevention activities be an integral part of the project plan
Require allocation of needed resources for defect prevention
Require project management & technical action items identified by defect prevention activities be recorded, addressed & tracked to resolution
Prioritize and
systematically
eliminate
causes for
defects
Ability
Assign responsibility for coordinating defect prevention activities organization wide to the SEPG
Assign responsibility for coordinating defect prevention in the project to a project level counterpart of the SEPG
Provide adequate resources & funds
for project & organization wide defect
Integrate appropriate responsibility for defect prevention into plans for individual role-responsibilities
prevention activities
Plan management participation in defect prevention activities
Represent every software project in the organization wide defect prevention team
Provide the right tools and automation (statistical & quantitative analysis tools,
defect tracking & causal analysis tools, database management systems, etc.)
Train individuals & support staff in discharging
their defect prevention responsibilities
Measure & Analyze Measure & track the status of defect prevention activities
Monitor Implementation
Periodic Upper Management
defect prevention activity review
Frequency distribution of defects by major defect class
Frequency distribution of defects prevention actions by major classes of actions
Significant defect prevention actions
Summary status of proposed open & closed actions
Summary of effectiveness, cost reductions aand benefits that may be attributed to defects prevented
Actual costs incurred by completed defect prevention activities versus projected future cost of (planned) defect prevention
Seek &
Identify
common
causes of
defects
Periodic & event based Project Manager’s defect prevention activity review
QA review/audit &
report of defect
prevention activities
& work products
KPA
execution
(activities)
Verify that staff are trained adequately to fulfill their defect prevention responsibilities
Verify that the proper conduct of kick-off & causal analysis meetings
Verify that the procedures for quantitative process management are being followed
CAPABILITY LEVEL 5
Continuous Improvement Institutionalized
DEFECT PREVENTION
Goals:
• Plan defect prevention
KPA
• Seek & Identify common causes
Execution
of defects
• Prioritize and systematically
(activities)
eliminate causes for defects
Plan defect prevention
Plan defect
prevention
Seek &
Identify
common
causes of
defects
DEFECT PREVENTION ACTIVITIES
Go beyond immediate
causes & determine why
the defect escaped
verification procedures, and
if other defects might have
been similarly missed
Identify defect prevention activities
Schedule defect prevention activities
Assign requisite responsibilities & resources, including staff & tools
Peer review the plan
Cover the project level process, standards, procedures, methods & relevant tools, emphasizing recent changes
Cover resources required (inputs) for the task
Cover work products (outputs) of the task, with examples when available
Start every task with a preparatory
Cover criteria & methods for evaluating work products
meeting of those involved in the
Cover criteria & methods for verifying compliance with the project level process
task to prepare for requisite
List common errors and recommended preventive measures for the current task/phase of the project life cycle
activities, including those required
Cover team assignments & role-responsibilities
to prevent defects
Cover the product quality objectives for the task, in the context of those for the project
Cover the task schedule
Meet soon after completing the task
Require each team performing a task conduct causal analysis meetings
If too many defects are discovered during
The leader/facilitator of cause-and-effect meetings must have been appropriately trained
the task convene a meeting right away
Comply with a
Identify defects & analyze root causes
Meet periodically even after the software/system
published procedure
is released for cause-and-effect analysis
Categorize
defects
by
root
cause
(or
kind
of
root
cause)
in conducting causal
Recommend
preventive
actions
&
put
it
on
record
For lengthy tasks, meet periodically to
analysis meetings
prevent defects even as the task progresses
Categorize & record defects by common causes
Record the meeting outcome for use by other projects & the organization as a whole
Consider causes of defects
Consider the impact of
Identify defect prevention recommendations (of causal analysis teams) that will be addressed
not addressing defects
Identify defect prevention action items requested by other defect prevention teams that will be addressed
Consider cost of process
Identify which defect prevention actions/practices of other defect prevention may be adopted (or adapted)
improvement to remove defects
Prioritize proposed actions (after preliminary analysis)
Periodically review,
Consider the impact on process, work
Reassign proposed actions to other teams where appropriate;communicate request(s)
coordinate & implement
products & information quality
Record
&
communicate
reasons
for
proposed
actions
(or
lack
thereof)
to
those
who
requested
them
defect prevention actions
Assign responsibility for implementing actions; the team may take some actions directly & arrange for implementing others thru groups outside the team
recommended by causal
analysis team; each defect Review results of defect prevention experiments; incorporate successful practices into the project/standard process across projects as applicable
prevention team meets
Track action item status (including the status of proposed action items)
periodically to do this.
Publish process improvement proposals for standard & project level processes; identify requestors/proposers
Review & verify finished action items before closing them
Recognize & reward significant defect prevention efforts & successes
Record & track defect
prevention information across
defect prevention teams
Record proposed actions of causal analysis meetings
Record proposed actions that will be implemented
Manage & control defect prevention information
Comply with a published procedure when amending the standard process to prevent defects
Comply with a published procedure to amend the project level process to prevent defects
Prioritize and
systematically
eliminate
causes for
defects
Inform stakeholders (or their representatives for example, marketing and sales groups may
represent customers or users) of the status &
results of defect prevention activities
Summarized information by kind of defect
Frequency distribution of defects by significant defect classes
Significant innovations & actions that address each kind of defect
Summarized status of defect prevention proposals & action items
Proactively hunt down defects (At Level 1,
the norm was reactive crisis management)
CAPABILITY LEVEL 5
INSTITUTIONALIZING
Continuous Improvement Institutionalized
TECHNOLOGY CHANGE MANAGEMENT
Goals:
• Plan absorption of technological changes.
• Evaluate the impact of new technology on quality & productivity.
• Make the right new technologies the norm in the right practices throughout the
organization
Commitment
Commit to following a published organization wide
policy for improving technological capabilities
Upper management
sponsorship of
technology
improvements
Plan
absorption of
technological
changes
TECHNOLOGY CHANGE MANAGEMENT
Require written objectives for technological changes
Require a published plan for changing technology in aligned with the published purpose of the change
Upper management input and assistance in formulating a strategy to address
product quality, productivity & product development cycle time objectives
Upper management input and assistance in formulating a strategy to address customer/end user needs
Upper management coordinates alignment of lower level goals and approaches with the organization’s strategy
Upper management makes its commitment to managing technological change visible across the organization
Upper management establishes long term funding, staffing & resource plans for managing technological change
Ability
Upper management oversight of technology improvement
Upper management input and assistance in formulating a technology change management policy
Upper management ensures adequate resource allocation for technology change management
Assign responsibility for
Upper management assistance in aligning technology change management strategies with organizational strategies
coordinating technology change
Upper management participation in formulating technological change management plans
management to the SEPG
Coordination of
requirements & issues
Explore what might benefit
A unit within the SEPG could take this responsibility, or it
across org. & all levels
from new technology
could also be a group that works very closely with the SEPG
Securing support of staff &
Upper management secures support of
The unit must coordinate and facilitate technology change
management & coordinates
staff & management & coordinates it
it across org. & all levels
across the organization & all its levels
Provide adequate resources & funds for a unit that
will coordinate technology change management
Assign experienced specialists (Hardware, Work Stations, Networks, programming
language, component reuse, CASE, CAPE and metrics specialists, etc.)
Provide the right tools and automation (subscriptions [on-line & paper publications], workstations, database & data analysis tools etc.)
Support information gathering & analysis needed to evaluate the impact of changes in technology
Automated recording of requisite process & product information
Ability to support requisite data analysis
The ability to appropriately present (display) selected data & analysis results
Evaluate the
impact of
new
technology
on quality &
productivity
Ensure that the process & work product information needed to analyze & evaluate the impact of technology changes & home in on the right technology is available
Train the (SEPG) unit responsible for it, in technology change management
Measure & Analyze
Monitor Implementation
Make the right
new
technologies the
norm in the
right practices
throughout the
organization
Track status of technology change management activities
Periodic Upper Management technology change management activity review
Summarize technology change management activities
Identify course corrections & strategy changes
Resolve issues that could not be resolved at lower organizational levels
Approve revised technology change management plans (if any)
QA review/audit of technology
change activities & work products
KPA
execution
(activities)
Technology Change Management Plan review
Technology selection, procurement & installation process review
CAPABILITY LEVEL 5
TECHNOLOGY CHANGE MANAGEMENT ACTIVITIES
Continuous Improvement Institutionalized
TECHNOLOGY CHANGE
MANAGEMENT
KPA
Goals:
• Plan absorption of technological changes. Execution
• Evaluate the impact of new technology on
(activities)
quality & productivity.
• Make the right new technologies the norm
in the right practices throughout the
Role-responsibilities & resource requirements including staff & tools
organization
Technology strategy for strengthening the
Plan technology change
firm’s market position & and automation of
Identify processes that might benefit from changes in technology
management
the standard systems development process
Determine the approach to identifying technology change opportunities
List technology change management procedures
Identify candidate technologies
Approach to new technology introductions in
Estimate life of technology from introduction to replacement
support of specific organizational or project needs
Record make/buy trade-off studies & recommendations
Identify technology
Peer review the plan
change candidates
Define approaches for assessing unproven or high risk (candidate ) technologies
Plan review by managers impacted by it
(processes/areas) in
Define technology acquisition & installation procedures
coordination with
Define training (initial/ongoing), support & consulting requirements
individual projects &
Plan
the SEPG unit
absorption of
responsible for
Solicit technology improvement suggestions
Periodically search for, & identify new technology that will support current & future needs
technological
technology change
Identify candidate technologies that might fit
Systematically keep abreast of trends in technology & relevant work in new technology
changes
management
Evaluate how well each will fit current &
Systematically review technology used outside the organization (including those used
future org. & project needs
by competitors) & compare them with the organization’s current & planned technology
Assess which technologies have been successful & where; review & record available
information & experience; assess which will fit the current & future needs
Identify and implement Business process improvement based on SOA using BAM results
Disseminate information on
new technologies appropriately
Keep management & technical staff
Disseminate information on advanced technologies in use in different parts of the organization appropriately
informed of new technologies
Disseminate information on the status of technologies being inducted into the organization appropriately
Make the right
new
technologies the
Identify points of maximum benefit from induction of new technology into the standard process
norm in the
Identify the technological changes that will help these areas, and the economic costs & benefits of these changes
Systematically analyze the
right practices
standard process; identify
Define the relationship between the chosen technology & the standard process; the places where the standard process will be impacted
throughout the
where it might benefit from
Project quantitative & qualitative results of the technological change
organization
new technology
Determine which changes must be piloted (if any)
(A SEPG task)
Prioritize technological changes
Where possible, estimate the life of the replacement or upgrade
Record & publish the technology analysis
Analyze the trade off between internal development Vs. external
Comply with
acquisition of the technology; publish & review the analysis
a published
Consider appropriate pilot technology installations
Record requests for technology acquisition, obtain requisite
procedure
to determine its effectiveness & economic value
management approvals for requisite expense thresholds
when
Review of technology induction requirements & plans by
Perform
preliminary
cost-benefit
analysis
of
candidate
technological
changes
choosing
&
Evaluate the
managers of impacted groups & the SEPG unit responsible for it
acquiring
Use selection criteria approved and predefined by the procedure
impact of
new
Record plans & requirements for the envisioned technological change
new
technology
technology
on quality &
productivity
Pilot & prove the feasibility & economic value
of new or untried advanced technologies
Publish pilot plans; cover objectives, evaluation criteria & activities
Managers of impacted groups review & approve the pilot
Pilot the technology
The pilot project consults, & gets implementation assistance from
where appropriate before
Record problems faced & lessons learned
SEPG (the unit charged with technology change management )
inducting it as the norm
Project the impact (& benefits) of broader or large scale use;
The development & maintenance environment
assess
uncertainty & risks inherent in the estimation
of the pilot will validate making it the norm
Collect, analyze & publish the results of the pilot project
Decide on broader use of the technology,
termination, continuation or replanning of the pilot
Comply with a published procedure when inducting new technology into the standard process
Proactively hunt
for technological
improvement
Comply with a published procedure to induct new technology into the project level process
Concentrate on
improving quality,
timeliness &
productivity
Use Pilot projects
to test & tune the
technology to
reduce risk
INSTITUTIONALIZING PROCESS CHANGE MANAGEMENT
CAPABILITY LEVEL 5
Continuous Improvement Institutionalized
PROCESS CHANGE MANAGEMENT
Goals:
• Plan continuous process improvement.
• Organization-wide participation in process improvement.
• Continuously improve the organization’s standard software/business
systems development process, and the project level processes derived from it
Recognize skilled &
motivated people as the
principle resource for
process improvement
Recognition &
reward from sponsors
are critical to success
Commit to following a published organization wide policy
of process improvement, including improving the
processes for developing software & business systems
Commitment\
Upper management
sponsorship of process
improvement activities
Plan
continuous
process
improvement
Require measurable quantitative goals & tracking of actual performance against them
Require goals address product quality improvement, productivity improvement or
software/systems development (& deployment) cycle times singly or in combination
Require participation of all managers & staff in improving the software/systems process
Upper management articulates long term process improvement objectives & plans
Upper management commits adequate resources for process improvement activities
Upper management coordinates process improvement goals of individual
managers & units; validates their feasibility, risk & requisite aggressiveness
Upper management monitors process improvement performance against goals
Upper management makes process improvement a priority area, and keeps
a stable focus on it even when products are under pressure or in crises
Upper management resolves process improvement issues in a timely manner
Upper management rewards & recognizes employee participation in process improvement activities
Provide adequate
resources & funds for
process improvement
Allocate resources for kinds of process improvement activities
Assign seasoned methodologists with experience in
software & systems process improvement
Provide the right tools and automation (process automation &
modeling tools, workstations, database & statistical analysis tools etc.)
Ability
Support, guidance & leadership
Process improvement Record maintenance
Control, development & dissemination of process changes
Communication, recognition & motivational activities needed for
maintaining employee participation; the requisite administrative &
human resources infrastructure to govern these activities
Train managers of units involved in software/business systems engineering in the
process of process improvement (including the process of software improvement)
Organization
-wide
participation
in process
improvement
Train stakeholders (or their representatives) in the process of process
improvement (including the process of software improvement)
Train the upper management in process change management
Measure & Analyze
Track status of process improvement activities
Periodic Upper Management process improvement activity review
Monitor Implementation
Continuously
improve the
organization’s
standard
software/business
systems development
process, and the
project level
processes derived
from it
KPA
execution
(activities)
QA review/audit of process
improvement activities &
work products
Summarize participation in process improvement activities
Assess process performance
Identify what changes (if any) are required in process improvement goals or objectives
Resolve issues that could not be resolved at lower levels
Approve revised process improvement plans (if any)
Verify that the process improvement plan is being prepared & followed
Verify compliance with the process for initiating, submitting, reviewing &
approving process improvement proposals, & planning process improvements
Verify how validly process measurements reflect actual performance of the process(es) in question
Verify compliance with the process for recording, reviewing, approving, controlling &
disseminating changes in the standard process & the project level processes tailored from it.
Verify the adequacy, extent & consistency of tracking process improvement activities
Verify how well actual improvements in the process (of developing software
& business processes) achieves the goals set, & the plans made for it
CAPABILITY LEVEL 5
Continuous Improvement Institutionalized
PROCESS CHANGE MANAGEMENT
Goals:
KPA
• Plan continuous process improvement.
Execution
• Organization-wide participation in
process improvement.
(activities)
• Continuously improve the
organization’s standard
software/business systems development
process, and the project level processes
Empower individual members of the
derived from it
organization to improve its processes
through a process improvement program
Plan
continuous
process
improvement
Organizationwide
participation
in process
improvement
Cross functional teams are key to process
improvement; processes often cross
organizational & functional boundaries,
integrating them to deliver external value
Always change from a
SEPG sets goals & plans for measuring the performance
stable & controlled base
of processes that create software & business systems
SEPG reviews these performance goals with upper management
SEPG participates in defining process improvement training needs;
assists in developing course materials & supports their presentation
Creates and updates procedures for processing process improvement proposals
SEPG reviews improvement proposals for the processes that
create software & business systems; coordinates requisite actions
SEPG tracks participation in, accomplishments & the status of process
Coordinate process improvement through the SEPG
improvement activities; reports back periodically to upper management
SEPG coordinates & tracks changes to the standard process
SEPG defines, creates & updates process improvement records
Align the plan with business & strategic plans, as well as customer satisfaction indicators
Plan process improvement in
Peer review the plan
compliance with the published
Review the plan with all managers impacted by it
procedure for it
Manage & control the plan
For upper management oversight of process improvement
For coordinating process improvement between managers involved
Role-responsibilities & resource requirements including staff & tools
For identifying, evaluating & introducing the right improvements
Process improvement priorities & footprints
For assembling & assigning teams/task forces to address
Short & long term process performance goals
Conform to
specific improvements and/or footprints
process
Teams assigned for specific improvement in specified footprints
improvement plan Procedures
Procedures for encouraging participation & facilitating process improvement activities
Administration & Support pans that will continue to
maintain & institutionalize process improvement
Inclusion of administrative staff in overseeing & reviewing process improvement activities
Plans for recognizing individual roles & contributions to process improvement
Comply with a published
procedure when processing
process improvement proposals
Secure active participation of
individuals in their assigned teams
Pilot the changed process
(where appropriate) before
making it the norm
Continuously improve
the organization’s
standard
software/business
systems development
process, and the
project level processes
derived from it
PROCESS CHANGE MANAGEMENT ACTIVITIES
Proposals may be submitted at any time for any part of any process
Evaluate each proposal; accept or reject it. Record the decision with reasons
Determine the benefits of each proposal
Prioritize (accepted) proposals; focus on high priority
Plan & assign responsibility for actions (for implementing proposal)
Assign high effort actions to teams; establish task forces, work groups & committees for specific process areas if need be
Track the status of each proposal
Act on proposals that have been outstanding for unusually long periods
Review high impact (in terms of customer satisfaction, product quality or
productivity) proposals with the right managers before implementing them
Review, verify and approve completed process improvement actions with the individual who asked for it before closing it out
Promptly acknowledge receipt of proposal & notify those who submitted them of their disposition with reasons
Fully fund each team; plan & schedule its activities
Define clear, and if possible, quantitative goals of each effort
Secure approval of plans from SEPG & managers of all impacted groups
Tune the process, and record any changes during the pilot
Record problems & lessons learned
Estimate impacts proposed changes if made the norm, their benefits& risks & the uncertainty of these estimates
Decide on broader deployment of the piloted process & on terminating, continuing or replanning the pilot project
Fund & provide all resources needed to change the process
All persons responsible
Record, review and agree upon the strategy for tracking changes in performance & requisite data collection
for implementing change
agree on strategy
Update requisite training in step with changes in the process; train before making the changed process the norm
Determine what to measure &
Before deploying change beyond a pilot project, enable requisite support &
how; collect data automatically
consultation to match the projected need for it; continue both as long as needed
Make requisite changes to the standard process
Make requisite changes to the project level processes
Keep records of initiating, implementing & the status of process improvement proposals These records chronicle
Provide easy access to these records
the organization’s
Keep records of process improvement activities
Keep process improvement histories & report improvement data
adaptability - its cycle
times & capacity for
A summary of major process improvement activities
change
Inform technical staff & their managers of changes in state and/or the
Significant innovations & actions in process improvement
results of process improvement activities when these changes occur
Summary of proposals submitted, open and completed
Comply with a
published
procedure
when making
changed
process the
norm