powerpoint presentationseidenberg.pace.edu/eta/project management maturity fr… · ppt file ·...

Project Management Maturity Model

12/22/14

© 2014Amit Mitra and Larissa Zhurakovskaya

Evolution of Project Management Maturity

Level 2(Repeatable)

Can consistentlyrepeat previously

mastered tasks

Level 1(Initial)

Unpredictable, poorlycontrolled processes

Level 3(Defined)

Best Practicesstandardized

for Organization

Level 4(Managed)

Quantitative standards& controls in place

Level 5(Optimizing)

Focus on continuousProcess Improvement

MATURITY OF PROJECT MANAGEMENT

LEVEL 2 ANALYSIS HIERARCHY CAPABILITY LEVEL 2Consistently Repeatable Process

REQUIREMENTS MANAGEMENTGoals:•Establish, control & utilize a Requirements Baseline•Ensure consistency of Requirements with project plans, activities & Work products

PROJECT PLANNINGGoals:•Estimate projects in writing for planning & tracking purposes•Plan & document project activities & commitments•Ensure commitments are agreed upon between all impacted groups

PROJECT TRACKING & OVERSIGHTGoals:•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

QUALITY ASSURANCEGoals:•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 MANAGEMENTGoals:•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 MANAGEMENTGoals:•Select qualified contractors & subcontractors•Agree on mutual commitments with contractors•Maintain ongoing communication with contractors•Track contractors’ performance against commitments

GOALS OF KEY PROCESS AREAS (KPAs)

Process Capability

Specific goals that will

contribute the most to

achieving consistently

repeatable results

In moving from level 1 to 2, managing requirements will benefit the organization more than optimizing engineering methodology

Common understanding with customer

Engineering plan & risk management

Make progress against visible & actionable plan

Make progress & product quality visible

Maintain integrity of work products over the project/service’s live

Choose & manage contractors effectively

CAPABILITY LEVEL 2Consistent Process Repeatability

REQUIREMENTS MANAGEMENTGoals:• Establish, control & utilize a

Requirements Baseline• Ensure consistency of Requirements with

project plans, activities & Work products

CommitmentRequirements Documentation

Impacted groups requirements reviewRequirements change control & alignment of plans, activities & work products with changes

Ability

Measure & Analyze

Monitor implementation

KPA execution (activities)

Establish Requirements Analysis Responsibility

Document Requirements

Responsibility for Managing & recording requirements & corresponding solutionsRequirements change control responsibility, Change control responsibility for ownership of solutions

Document Commitments, Terms & ConditionsDocument functional, non-functional & Technical requirementsDocument acceptance criteria

Assure plans, activities & work products are revised when requirements (or solutions responsibilities) change

Track requirements & corresponding activities’ status, statistics & anomalies

Provide adequate resources & funds

Provide adequate expertise/training : Procedural, methodology, standards, tools & subject matter training

Requirements allocated to managers with both Applications Domain & Technical expertiseAdequacy & access to requirements Management tools

Periodic Upper Management review of Requirements Management & allocation activitiesPeriodic & event/exception triggered Project Manager review of Requirements Management & allocation activitiesQuality Assurance review/audit of Requirements Management & allocation activities & work products; Reports of results

Assure problem resolution, review & Engineering group’s consent prior to commitment

Assure changed commitments are negotiated with impacted groups

Review, resolve & obtain Engineering group’s consent before committing to requirements

Resolve missing & incomplete requirements/responsibility for solutionsResolve clarity, feasibility, consistency & testability of requirements & allocated responsibilitiesReview & resolve exceptions with the group responsible for allocating ownership of solutionsNegotiate commitments with impacted groups

Have requirements drive engineering plans, activities & work products

Review & change requirements & responsibilities for solutions as needed

Manage & control requirements & allocation of responsibilities for solutions (baseline, versioning, configuration, archival) Base plans, activities & work products on requirementsBase 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

Establish, control & utilize a

Req. Baseline

Ensure consistency of Requirements with project

plans, activities &

Work products

INSTITUTAIONALIZING REQUIREMENTS MANAGEMENT PROCESS AND ACTIVITIES

Requirements BaselineA formally agreed upon specification, under change control, on which all development is based

Publish requirements analysis policy

SLA agreements with Service owners

Negotiate SLA agreements and chargeback model with service owners


REQUIREMENTS MANAGEMENTGoals:•Establish, control & utilize a Requirements Baseline•Ensure consistency of Requirements with project plans, activities & Work products

Commitment Designate Project (& subproject) Planning Manager(s)

Base plan on requirements & solution responsibilities allocated to each group

Negotiate commitments between all impacted managers(software as well as other groups)Ability

Measure & Analyze

Monitor Implementation


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)

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

Plan standards

Train planners (Management & staff) in estimating & planning (procedures, methodology, standards, tools & subject matter) aligned with their responsibilities

Periodic Upper Management review of Project Planning activities

Periodic & event/exception triggered Project Manager review of planning

Quality Assurance review/audit & report of Project Plans & planning activities

Plan content

Planning activities

Plan & document project activities & commit-ments

Estimate projects in writing for planning & tracking purposes

INSTITUTIONALIZING PROJECT PLANNING

Ensure commitments are agreed upon between all impacted groups

Publish written project planning policy

Review estimated size, cost, schedule & other commitments with all impacted groups

Review all external commitments with upper management

Control & manage the plan via a baseline (change, status, version, archive control & management)

Managed & Controlled PlanA formally agreed upon project plan, under change control, such that the version utilized at any point in time, past or present, is known

Manage & control the statement of work via the baseline


Planners have both Applications Domain & Technical expertiseAdequacy & access to planning & estimation tools

Performance: Technical, cost, staffing, scheduleAddress unresolved issues & conflictsAddress risksAssign, review& track action items to closurePrepare & distribute Review Summary to all impacted parties

Involve all impacted groupsReview status & results against requirements & statement of work Address inter-group dependencies Address unresolved issues & conflicts

Review & address risks

Assign, review& track action items to closurePrepare & distribute Review Summary to all impacted parties

Plan review & commitment activities

Estimation activities

BaselineA 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

Track project plan & planning activities status & statistics (milestone status, actuals vs. plan, changes etc.)

CAPABILITY LEVEL 2Consistent Process RepeatabilityPROJECT PLANNINGGoals:•Estimate projects in writing for planning & tracking purposes•Plan & document project activities & commitments•Ensure commitments are agreed upon between all impacted groups

KPA Execution (activities)

Include Engineering groups (including software engineers) in the project proposal team

Involve in preparing, submitting, clarifying, negotiating commitments & changes that impact corresponding groupsResolve 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

Each group, including Software Engineering, reviews & agrees on the overall project plan thru the project’s full life

PROJECT PLANNING ACTIVITIESManaged & Controlled PlanA formally agreed upon project plan, under change control, such that the version utilized at any point in time, past or present, is known

Upper management, following a documented procedure, reviews all commitments made to external parties (including software commitments).

Establish a software development life cycle divided into predefined, manageably sized phases.

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

Develop systems project plans (& overall project plan) consistent with a documented procedure All impacted groups (including software & Project Managers) review the project plan

Manage & control the plan (software & overall)

Document the overall & software project plan

State scope & purpose, specific objectivesDescribe software life cycle, reasons for selecting a specific type/methodology

Specify software & other development & maintenance standards, procedures, techniques & methodsIdentify software & other engineering work products

Include software (& other) work products size estimates (size anticipated changes as well)Estimate use of critical computer resourcesDescribe project schedules, milestones & planned reviewsProject (software) risk assessmentsInclude project (software) engineering facilities & tools plan

Identify items (including software work products) needed to manage & control the (software) project Include (software)Project effort & cost estimate

Plan & document project activities & commit-ments


Decide the Chargeback and costing model for servicesNegotiate SLAs with service providers, if required

Evaluate existing services and consider service reuse while cost estimation

Size all major work products & activities

Assess & record risks (technical, cost, schedule, resource & other)

Plan software & Systems engineering facilities & tools

State estimation/sizing objectives Use available historical dataDocument assumptions

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 & sourcesBase effort & staffing estimates on experience

Document, review & agree on estimates with impacted managers

Identify critical resourcesDerive estimates from software work product size, processing load & communications traffic estimates

Derive estimates from software effort, cost, change & work product size estimatesActual schedules of similar past projects when availableConsistent with imposed timing of milestones, critical dependencies & other constraintsAre timelines (Activity length & gaps between milestones) appropriate for accurate tracking?Document assumptions

Analyze & prioritize risks based on potential impact on the project’s business objectivesIdentify contingency plans& allowances

Estimate facilities & tools capacity from estimated project & work product size Negotiate commitments & responsibilities for procuring/developing facilities & toolsDocument, review & agree on estimates & commitments with impacted managers

Include estimates, assumptions rationale & derivation

Use documented estimation procedures to:

Size software work product (& change)

Estimate (software) project cost & effort

Size critical computer resources

Estimate (software) project schedules Plan & document project activities & commit-ments

Estimate projects in writing for planning & tracking purposes


Assemble the plan, record, manage & control it in a baseline

Managed & Controlled PlanA 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 2Consistent Process RepeatabilityPROJECT PLANNINGGoals:•Estimate projects in writing for planning & tracking purposes•Plan & document project activities & commitments•Ensure commitments are agreed upon between all impacted groups


PROJECT PLANNING ACTIVITIES


PROJECT TRACKING & OVERSIGHTGoals:•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

Commitment Designate Project (& subproject) Manager(s)

Track project against a documented baseline plan that is appropriately maintained

Negotiate and consent to changes in commitments between all impacted managers(software as well as other groups)

Ability

Measure & Analyze



Base the project on an approved & documented project plan

Assign ownership of work products & responsibility

Individual responsibility for providing work products & services envisioned in the project planIndividual responsibility for work products & activity cost & schedules

Project plan revisions - activity

Train (software) managers in managing both project personnel & technology (Grow managers, rather than appoint good, but unprepared technical staff to management)

Periodic Upper Management project review

Periodic & event/exception triggered Project Managers’ review

Quality Assurance review/audit & report of Project tracking & oversight activities & work products’ status

Commitment review & revision activities

Cost, schedule risk, functionality, performance & constraint (technical & design) tracking activities

Track actuals against plan

Take & manage corrective actions on deviations to closure

INSTITUTIONALIZING PROJECT TRACKING & OVERSIGHT

Publish written project management policy

When deviations from the plan occur, corrective actions are taken by adjusting either performance or the plan

Review all changes to external commitments with upper management

Project/subproject Managers are aware of the status & issues of their portions of the project on time


Assign managers & task leaders specific tracking responsibilityAdequacy & access to project tracking tools

Performance: Technical, cost, staffing, schedule, tracking & oversight,Address unresolved issues & conflictsAddress risksAssign, review& track action items to closurePrepare & distribute Review Summary to all impacted parties

Involve all impacted groupsReview project status (technical, cost, resource & schedule performance) against plan

Address inter-group dependencies Address unresolved issues & conflictsReview & address risksAssign, review& track action items to closurePrepare & distribute Review Summary to all impacted parties

Plan review & commitment activities

Revised plan content

Budgetary responsibility for activity cost

Orient first line managers to the project’s technology (Grow managers, rather than appoint good, but unprepared technical staff to management)

Report & review current & projected utilization of critical computer resources against original plan

Tracking oversight & change management activities performance: impact on schedule, cost, effort & resource utilization

AssumptionOrganizations striving for repeatable results are already good at engineering, but need Management & technical infrastructure to stabilize their engineering process against perturbing factors

BaselineA 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

Agree on (commitment) changes over the project’s life across all impacted groups

CAPABILITY LEVEL 2Consistent Process RepeatabilityPROJECT TRACKING & OVERSIGHTGoals:•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


Track project work & commitments against a documented & approved project plan

Update the plan to reflect accomplishments, particularly when milestones are completedEnsure easy access to the same updated plan by all impacted groups, particularly upper management, project (& subproject) managers & (software) engineering groups

AssumptionOrganizations striving for repeatable results are already good at engineering, but need Management & technical infrastructure to stabilize their engineering process against perturbing factors

Size of major work products & activities (or changes)

Risks (technical, cost, schedule, resource & other)

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

Size of fully tested & delivered codeDocuments actually delivered

Effort, cost, time expended vs. work completed to identify potential overruns & under-runs

Effort & Staffing - actual vs. planCost - actual vs. plan

Track commitments & actuals against plan - current & original baselines, monitor deviations, refine & adjust plan & commitments regularly

Critical resource use for each major software component/deliverable in planChanges

Activity & Milestone completion; Meeting other commitments in planEvaluate impact of late/early completion of activities, milestones & other commitments on future activities & milestones

Technical team members report technical work product & activity status to first line managers regularlyCompare contents of successive software builds/releases against planReport & Document (software) work product defects & problems

Adjust prioritized risks & contingencies in step with new informationRegular project Manager’s review of high risk areas

Task leaders & first line managers Appropriate (Software) project & sub project managers

Review at meaningful points in project schedule/lifecycle

Revise the plan to reflect significant changes, particularly in requirements, design constraints, resources, cost or scheduleReflect all new & changed commitments in the revised planRevise software project plans (&

overall project plan) consistent with a documented procedure

All impacted groups (including software & Project Managers) review & consent to the revised project planManage & 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).

Changed commitments are communicated to all impacted groups after they are approved (including Quality Assurance, Configuration Management & Documentation)

Track & take necessary corrective actions:

Software work product Size (& change)

(Software & system) project cost & effort

Critical (computer) resources use

(Software & system project schedules

(Software & system) Engineering activities - Design, code, test

Review & agree on revised estimates, commitments, plans & changes with all impacted managers. Document agreements & risks

Track problem reports to closure

Record actuals & re-planning information

Estimates, their assumptions, rationale & other information to reconstruct estimatesUse the plan baseline to manage & control revisionsArchive the original plan, its revisions & actuals for use by ongoing & future projects

Involve customers, end users & all impacted groups in organizationReview materials approved by the (software & business system) managers responsible for delivering corresponding work productsAddress commitments, plans & (software & business system) activity statusIdentify & record significant issues, action items & decisionsAddress (software & business system) project risksRefine/revise plan if necessary

Track actuals against plan

Take & manage corrective actions on deviations to closure

Agree on (commitment) changes over the project’s life across all impacted groups

PROJECT TRACKING & OVERSIGHT ACTIVITIES


QUALITY ASSURANCEGoals:•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

CommitmentQA must cover all (systems) projects

Ability

Measure & Analyze



Create a group for the project’s QA coordination & implementation

Train/ acquire team members

Periodic Upper Management QA activity reviewPeriodic & event/exception triggered Project Managers’ QA activity review

Periodic independent Quality Assurance expert review/audit & report of QA group activities & work products

Plan Quality Assurance activities

INSTITUTIONALIZING QUALITY ASSURANCE

Upper management resolves non-compliance when it cannot be resolved at the project level

Publish Organization’s QA policy Periodic upper management project QA reviews - activities & resultsQA organization & reporting channel are independent of project & other software & business systems organizations

Provide adequate resources & funds for Quality Assurance

Assign a manager specific project QA activities responsibility

Adequacy of, & access to, QA support tools (such as auditing tools, work stations, databases, spread sheets, repositories etc.)

Performance: Technical, cost, staffing, schedule, tracking & oversight,Address unresolved QA issues & conflictsAddress QA risksAssign review & track QA action items to closurePrepare & distribute review summary to all impacted parties

Involve all impacted groupsReview QAtatus (technical, cost, resource & schedule performance) against plan

Address inter-group QA dependencies Address unresolved QA issues & conflictsReview & address QA risksAssign, review& track QA action items to closurePrepare & distribute QA Review summary to all impacted parties

Orient (software & business systems) quality assurance team members in (software) QA group business value & charter, values, role-responsibilities & authority

Report & review current & projected utilization of critical resources against original plan

Measure/derive QA activities performance: status, schedule & cost against baseline plan

May be large or small group or even an individual with part time commitment focused on the project’s QA activities

Assign a senior, experienced QA manager overall authority to take appropriate QA oversight actions, especially noncompliant project items Ensure information & reports on noncompliance are escalated to the senior QA manager as necessary

Understand software & systems engineering skills/practices & QA involvement in software activitiesUnderstand role-responsibilities of software/systems engineering & related groups, their interfaces & protocolsUnderstand project/organization’s standards, methods & procedures, Understand project’s application/business domainKnow QA objectives & procedures; can effectively use QA methods & tools; Skilled in interpersonal communication & fostering collaboration

Track QA milestone & work completion, effort & resource utilization, volumes of work product & activity audits

Objectively verify that work products & activities comply with standards

Communicate QA results & activities to all impacted groups

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

Manage & control the project’s QA plan

CAPABILITY LEVEL 2Consistent Process Repeatability QUALITY ASSURANCEGoals:•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


Develop the project’s QA plan in parallel with, or as an integral part of, the overall project plan Develop project QA plans consistent with a documented procedure All impacted groups (including software & Project Managers) review the project’s QA plan

Follow the QA plan

QA group’s authority & responsibilityQA 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

QA audits & reviewsProject’s QA standards & proceduresProcedures for recording & tracking noncompliance issues to closureDocuments to be produced by QA groupQA activity & results feedback method & frequencies to each group

Include (software) QA group in developing & reviewing the (software) project plan, its standards & procedures

Evaluate deliverables before delivery to customers

Periodically review QA activities & findings with customer’s QA personnel

Activities, tools & work products(software & other - e.g. documentation) to be evaluated by QA

Verify compliance against plan, standards & proceduresRecord deviations & track to closureVerify corrections

Resolve deviation as close as possible to its origin (task leader, subproject or project manager) when possibleRecord & escalate unresolved deviations to designated senior QA managerPeriodically review escalated items until they are resolvedManage and control the non-compliance record in a baseline

Report QA findings back to software engineering & other participating groups periodically

Conform to a written procedure in recording & processing (software) activities & work product deviations from the plan or its standards & procedures

QUALITY ASSURANCE ACTIVITIES

Plan Quality Assurance activities

Objectively verify that work products & activities comply with standards

Communicat QA results & activities to all impacted groups

Managed & Controlled PlanA formally agreed upon project QA plan, under change control, such that the version utilized at any point in time, past or present, is known

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

Managed & Controlled Non-compliance RecordA 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

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

Upper management resolves non-compliance when it cannot be resolved at the project level

(Systems) QA verifies (Systems) engineering work product compliance

Verify compliance

(Systems) QA verifies (Systems) engineering activity compliance

Periodically review QA activities & findings with QA personnel across the extended enterprise

CAPABILITY LEVEL 2Consistent Process Repeatability CONFIGURATION MANAGEMENTGoals:•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

Commitment

Assign the project’s Configuration Management responsibility explicitlyAbility

Create a Software Configuration Control Board (SCCB) to oversee the project’s (systems) baseline

Train SCM group

Plan Config. Managemt activities

INSTITUTIONALIZING CONFIGURATION MANAGEMENT

Publish Organization’s CM policy

Implement Configuration Management through the project’s full life cycle

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

Create a Software Configuration Management Group (SCM) to manage the project’s (systems) baseline

Manage the project’s component & software library

Manage systems baseline access

Authorize systems baseline establishment & kinds of items it will contain

Identify the contents of the systems baselineDevelop, maintain & distribute SCM plans, standards & procedures

Know SCM objectives & procedures; can effectively use methods & tools

Select & control (software) work products & make them available to the project team

Inform all impacted groups of (software) baseline contents & status

Give projects a repository(s) for storing configuration components

The project’s operating environment &tools (including CM tools) must comply with standards in order to ensure consistently repeatable results

Represent the Project Manager & all groups impacted by (systems) baseline changesReview & authorize (systems) baseline changesAuthorize product assembly (build) from the systems baseline

Update the baseline with specific work productsBuild systems products/deliverables from the baselineRecord configuration management actionsProduce & distribute SCM reports

Provide adequate resources & funds for SCM

Assign a manager specific project SCM responsibilityAdequacy of, & access to, SCM tools (such as repositories, work stations, databases & other configuration management tools.)

Train software & systems engineering, QA, Documentation & other project groups in SCM activities they must perform

Understand SCM objectives, practice & involvement in software activities

Understand role-responsibilities of SCM & related groups, their interfaces & protocolsUnderstand project/organization’s SCM standards, methods & procedures, Can effectively use SCM methods & tools needed to fill their individual SCM responsibilities

Understand their group’s & individual SCM responsibilities

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

Institutionalization

Control changes to (software) work products selected & made available to the project team(s)


Measure & Analyze:

Monitor Implementation Periodic Upper Management SCM review

Periodic & event/exception triggered Project Managers’ SCM activity review

Periodic SCM group’s baseline audit to confirm compliance with documentation

INSTITUTIONALIZING CONFIGURATION MANAGEMENT

Technical, cost, staffing, schedule, tracking performanceAddress unresolved SCM issuesAddress SCM risksAssign review & track SCM action items to closurePrepare & distribute review summary to all impacted parties

Involve all impacted groups

Review SCM status (technical, cost, resource & schedule performance) against plan

Address inter-group SCM dependencies Address unresolved SCM issuesReview & address SCM risksAssign, review& track SCM action items to closurePrepare & distribute SCM Review summary to all impacted parties

Report & review current & projected utilization of critical resources against original plan

Measure SCM performance: resources, milestones, activity status, schedule, cost, change request volumes etc. against baseline plan

Inform all impacted groups of (software) baseline contents & status

Timely & adequate upper management insight into SCM process

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

Control changes to (software) work products selected & made available to the project team(s)




CONFIGURATION MANAGEMENT ACTIVITIES

Develop the SCM plan in parallel with, and as an integral part of, the overall project plan Develop project SCM plan consistent with a documented procedure All impacted groups (including software & Project Managers) review the SCM plan

Manage & control the SCM plan in a baseline

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 itemsShare (or move) configuration components between project groups & the library’s control (security) levels subject to security rulesFacilitates enforcement or application of standards to configuration components

Validate products configured from repository & facilitate creating the right deliverables from the baselineStorage, retrieval & maintenance of SCM recordsSupports SCM reportsMaintenance of repository structure & contents (including backup, recovery & library administration)

Identify items that will be placed under configuration management (in the repository)

Give all impacted groups access to standard reports describing SCM activity & the baseline’s contents

Configuration (component) archival, recovery & version management

Conduct reviews/regression tests to eliminate unintended effects of changes on the baselineBaseline only configuration items approved by the SCCBComponent check in/out procedure maintains baseline accuracy & integrity

SCCB authorization to build products/deliverables from the baseline libraryBoth internal & external products/deliverables released from the baseline are built purely from components stored in that baseline

Store enough detail of configuration management actions to not only maintain every configuration item’s current state & contents, but also to recover its previous versionsMaintain each item’s current state & history (of changes & actions)

Use documented procedures to:Record, review, approve & track configuration item change requests & problem reports

Control Baseline changes

Build & release products/ deliverables from the baseline

Record the status of every configuration item

Plan Config. Managemt activities

Select & control work products & make them available to the project team

Inform all impacted groups of (systems) baseline contents & status

Base SCM activities on a documented & approved SCM plan SCM activity schedule, resources(staff, tools, computer & infrastructure facilities) & individual responsibilities

Required SCM activities & support from Software & business systems Engineering, & other groups

Selection is based on written criteriaAssign an unique identifier to each itemAssociate 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

Systems BaselineA 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

Managed & Controlled Configuration ItemsA 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

Comply with a written procedure to audit systems baselines

Prepare adequately for the auditAssess the baseline’s integrityReview the baseline library (automated or manual system) structure & facilities

Verify compliance with SCM standards & proceduresReport audit results to the project’s software & business system managersTrack resulting action items to closure

Verify accuracy & completeness of (baseline) library contents

Control changes to work products selected & made available to the project team(s)


CONTRACT MANAGEMENTGoals:•Select qualified contractors & subcontractors•Agree on mutual commitments with contractors•Maintain ongoing communication with contractors•Track contractors’ performance against commitments

Commitment

Designate Project Contract Manager(s)

Responsible for contract Terms & Conditions and technical scope of contractAbility

Measure & Analyze


Contract management activities

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.)

Periodic Upper Management contract activity review

Periodic & event/ exception triggered Project Managers’ review

Quality Assurance review/audit & report of contract management activities & work products’ status

Contractor selection activities

Conducting planned reviews with contractor

INSTITUTIONALIZING CONTRACTOR MANAGEMENT

Publish written contract management policy

Manage contract based on contractual agreementsUse written standards & procedures for selecting contractors

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

Provide adequate resources & fundsAssign managers & other project team members specific contract management responsibilityAdequacy & access to contract management tools (estimation, tracking, scheduling, spreadsheet & other)

Performance: Technical, cost, staffing, schedule, tracking & oversight,Address unresolved issues & conflictsAddress risksAssign, review& track action items to closurePrepare & distribute Review Summary to all impacted parties

Involve contractor & all impacted groupsReview contract status (technical, cost, resource & schedule performance) against plan

Address inter-group dependencies Address unresolved issues & conflictsReview & address risksAssign, review& track action items to closurePrepare & distribute Review Summary to all impacted parties

Key contract milestone/phase completion reviews

Coordination of configuration management activities with contractor(s)

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 )

Report & review current & projected utilization of critical computer resources against original plan

Track contract management activities against baseline plan: cost & actual delivery dates of contracted items to & from the contractor

Select qualified contractor

Agree on mutual commitments with contractor

Maintain ongoing communicatn with contractor

Track contractor performance against commitments

ContractorA 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.

Responsible for selecting contractor, managing contract & arranging post contract support

Contractors’ deliverables acceptance process

Temporary Employees are not considered contractors, rather they are considered the prime’s staff

Track status of contract management activities

Internal organizations may qualify under this definition of contractor. Processes herein can support interfaces between internal groups.




Track contract activities & commitments against the contractor’s approved (written) project plan; communicate status

Revise contract (statement of work, T&C & commitments) consistent with a documented procedureAll impacted groups (of all parties bound by the contract) review & consent to revisions

Included in overall project (software) plan, or linked to corresponding items therein

Comply with a written procedure to determine work that will be outsourced

Comply with a written procedure to select contractor(s) able to perform

Manage contracted work against contract

Review contractor’s plan & approve contract

CONTRACTOR MANAGEMENT ACTIVITIES

CONTRACT MANAGEMENTGoals:• Select qualified contractors &

subcontractors• Agree on mutual commitments

with contractors• Maintain ongoing

communication with contractors• Track contractors’ performance

against commitments

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 & proceduresAgree on the contractor’s statement of work after baselining, reviewing & revising it with all impacted groupsCreate the contractor selection plan concurrently with the his statement of work

Contractor proposal

Location(s)Contractor’s performance record & references for similar work

Contractor’s engineering & management capabilitiesAvailable staff (able to perform)(Contractor) team’s prior experience & expertise with similar workResources (facilities, hardware, software, training etc.) available

T&CStatement of WorkOverall project deliverables & requirementsMutual obligations & dependencies with contractor(s)Contracted deliverablesConditions for revising & submitting deliverablesContractor performance evaluation procedures & criteria

Select qualified contractor

Agree on mutual commitments with contractor


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

Statement of WorkScope, goals, constraints & assumptions (technical , schedule, budgetary, resource etc), sponsors & end users of system, standards, responsibilities, impact & dependencies (internal & external organizations)



CONTRACTOR MANAGEMENT ACTIVITIES

CONTRACT MANAGEMENTGoals:• Select qualified contractors &

subcontractors• Agree on mutual commitments

with contractors• Maintain ongoing

communication with contractors• Track contractors’ performance

against commitments

Plan reviews in writing in the contractor’s statement of work

Address (software & systems) risksRecord issues, decisions & action itemsAddress contractor’s activity status, plans & commitments

Periodic ability review- Adequacy of contractor’s QA standards/ resources/plans to properly monitor project performanceImplementation spot check - Spot check contractor’s project activities & deliverables, & audit contractor’s QA records as neededImplementation periodic check - (Periodically audit contractor’s internal QA activity records to verify compliance with QA standards, procedures &plans)

Mutually review & approve acceptance procedures & criteria before testing

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

Periodically evaluate contractor’s performance (across contracts) & review with contractor

Revise contractor’s (software/systems) plan as needed

Periodic ability review- Adequacy of contractor’s CM standards/resources/plansCoordinate CM activities with contractor for ready integration into specified target (or outsourcer’s project) environmentPeriodic CM implementation check - audit contractor’s baseline library for compliance with CM standards & procedures & management

Test contracted deliverables before accepting them Document results

Action plan for failed deliverables

Maintain ongoing communic with contractor


The prime organization’s management, following a documented procedure, periodically coordinates, & reviews status, with contractor’s management

Provide contractor insight to customers’ (&end-users’) needsReview contractor’s performance against his approved plan - technical, cost, staffing & scheduleReview critical computer (&other) resources against his approved plan - track current estimates against original plan

Address critical dependencies & commitments within contractor’s organization, especially those that impact (software) engineering

Address mutual (critical) dependencies & commitments with contractor

Address noncompliance with contractAddress project risks that involve contractor’s workAddress issues & conflicts that contractor cannot resolve internallyAssign & track action items to closure

Periodically engage contractor in technical review & interchange Provide contractor insight to customers’ (&end-users’) needs

Monitor contractor’s technical activitiesValidate contractor’s interpretation & implementation of tech. requmtsValidate contractor is meeting commitmentsVerify timely resolution of technical issues

Management reviewCost, schedule, financial & other management Risks & dependenciesTech review Meeting tech. Commitments & correct implementation of tech. requirements

LEVEL 3 ANALYSIS HIERARCHY CAPABILITY LEVEL 3Standardized Best Practices in use

TRAINING PROGRAMGoals:•Plan training•Offer technical & management training courses•Train individuals

STANDARD PROCESS DEPLOYMENTGoals:•Tailor the standard software/systems process for individual projects

•Follow the tailored process for project planning & management

BUSINESS SYSTEMS & SOFTWARE ENGINEERING

Goals:•Define, integrate & consistently perform software & systems engineering tasks

•Keep work products mutually consistent

INTERGROUP COORDINATIONGoals:•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

Process Capability

Provide relevant training

Deploy standard processes

Engineer components, systems & software accurately

Coordinate between software/ systems engineering & other impacted groups

PEER REVIEWGoals:•Conduct peer reviews of work products in a planned manner

•Identify and remove defects in work productsInstitute peer review of work products & rectify defects

GOALS OF KEY PROCESS AREAS (KPAs) ORGANIZATIONAL PROCESS FOCUSGoals:•Coordinate systems development & improvement across the organization

•Identify software & systems process strengths & Weaknesses against a standard

• Plan process development & improvement across the organization

Focus the organization on standardizing processes

ORGANIZATIONAL PROCESS DEFINITIONGoals:•Develop & maintain standard software & systems process(es)

•Monitor & communicate use of standard software & systems process(es)

Develop & monitor use of standard processes

This is a close polymorphism

of WORKGROUP

DEVELOPMENT in the

Workforce Maturity Model.

Included here for IT Service

evaluation, specifically.

These goals utilize Level 2

TRAINING practices from

the Workforce Maturity

Model. Included here for IT

Service evaluation,

specifically.

These goals utilize Level 2

COMMUNICATION &

COORDINATION

practices from the


Included here for IT

Service evaluation,

specifically.

Specific goals that will

contribute the most to

standardizing and

deploying best practices

CAPABILITY LEVEL 3Standardized Best Practices in use

ORGANIZATIONAL PROCESS FOCUSGoals:• Coordinate systems development &

improvement across the organization• Identify software & systems process strengths &

Weaknesses against a standard• Plan process development & improvement

across the organization

Commitment

Ability

Create SEPG

Train SEPG

Coordinate systems

development &

improvement organization-

wide

INSTITUTIONALIZING ORGANIZATIONAL PROCESS FOCUS

Plan process development

& improvement


Commit to following a published organization wide policy for coordinating systems development

Provide adequate resources & funds for activities mandated by the systems process

Staff represents business systems and software disciplines (requirements analysts, systems/software designers & builders, testers, configuration Management and QA staff,etc.

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.

Identify software &

systems process

strengths & Weaknesses

against a standards

Upper management sponsorship of the initiative to standardize the systems development process

Require Creation & empowerment of the SEPGRequire periodic process assessments of project level processes for building systems & software - strengths & weaknessesRequire that project level processes must be tailored from the standard processRequire communication of improvements and relevant information on processes, tools and methods of each project to every other

Demonstrate commitment to the systems development process to staff & managementLong term funding, staffing & resource planManagement and implementation strategy for process improvement

Advise priorities for systems process development & improvement

Full time, dedicated professional systems staff, optional part time support staff

Upper management oversight of the initiative to standardize the systems development process

Ensure alignment of standard process(es) with business goals & strategiesParticipate in planning for systems process development/improvement; coordinate requirements and issues with managers & senior staff, secure support and participation from staff and managers

Measure & Analyze

Monitor Implementation Periodic Upper Management process development and improvement activity review

Report and analyze status of software/systems methodology development activities against planResolve conflicts and issues left unresolved at lower levelsAssign, review and track action items to closurePrepare & distribute review summary to all impacted parties

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

Orient (brief) SEPG and other software and systems groups on their roles, responsibilities and activities to implement the software/systems process

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.


Coordinate the use of the systems process repository

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

Keep the users of business systems/software methodology and processes updated on projects and activities for developing and improving current processes

Training plans on business systems/software development process and related subjectsTraining prepared and delivered by SEPG or the Training Group (see the Training KPA)

Assess software/systems process periodically and develop action plans to address findings Identify findings that will be addressedGuidelines for changes that will address the findingsGroups and persons responsible for implementing changes

Plan software/systems process development/improvement activities (and keep plan updated) Based on action plans from periodic assessments and other initiativesSpecify and schedule activitiesAssign responsibilities for activitiesIdentify resources including staff and toolsReview releases and revisionsAgreement of software/systems engineering managers & upper management

Coordinate software/process development & improvement activities organization wide

Standard software & systems processProject software & systems processes

Coordinate systems

development &

improvement organization-

wide

Plan process development

& improvement


Identify software &

systems process

strengths & Weaknesses

against a standards


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 FOCUS ACTIVITIES



ORGANIZATIONAL PROCESS DEFINITIONGoals:• Develop & maintain standard software & systems process(es)• Monitor & communicate use of standard software & systems

process(es)

Commitment

Ability

Train SEPG

Develop & maintain standard

software & systems

process(es)

Publish policy for developing and maintaining standard processes for business systems and software development

Provide adequate resources & funds for Systems process development & maintenance

SEPG made responsible for systems process development and maintenanceProvide the right tools and automation (statistical analysis tools, publishing tools, database management systems, process modeling tools etc.)

Conform to performance requirements of Training KPA for software/business systems engineering, process analysis& documentation techniques, etc.

Monitor & communicate

use of standard software/systems

process(es) Measure & Analyze

Monitor ImplementationPeriodic QA review of process assets, activities & work products for developing & improving software and systems processes

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

Requires definition of requisite standard processesRequires project level customization of standardsRequires maintenance, use and access to process assets Requires obtaining, organizing & using project level feedback to improve standard processes

Process and work product measurementLessons LearnedOther feedback

INSTITUTIONALIZING ORGANIZATIONAL PROCESS DEFINITION


Follow development, deployment, maintenance & documentation standardsControl & use assets appropriately

Create & maintain criteria & guidelines for tailoring Standard Process(es) to fit different projects

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

Follow a written procedure to develop and maintain the standard process

Conform to organizational standards when documenting standard process

Standards based items (meta-components)Appropriate scope of each item

Record and maintain, in writing, approved software/systems life cycles

Peers: Process & Software Engineers and other users of the standard process

Conform to internal policies, process and product standardsConform to customer, regulatory & other stakeholders policies, process and product standards if anyIntegrate appropriate state-of-the-art business systems and software engineering tools and methods into the standard processSpecify interfaces, transitions and protocols between business systems and software engineering disciplinesHow impacted groups will interface (use, feedback, customize, change etc.) with the systems processSEPG records, reviews and approve/disapprove proposed changes to the software/systems process in writingPlan for changes to the process in use by projects in progressPeer review software/systems process when developed or significantly changedStandard Process placed under Configuration Management

Estimating itemsDesign itemsConstruction itemsPeer Review itemsOther requisite items

Procedures, practices, methods, technologyProcess & Product StandardsRole-responsibility standardsTool & Resource standardsInput standardsWork ProductsWork Products for peer reviewReadiness/Completion criteriaProduct & Process data that should be collected

Relationships and interactions between items address their sequence, interfaces and interdependence

Conform to organizational standardsRecord, review, take SEPG Approval for proposed changes before inclusionPeer review of software & systems life cycles when developed or significantly changedManage & Control Life Cycle description(s)

Establish scopeRecord, review, SEPG Approval for proposed changes before inclusionManage and control guidelines & criteria

Project Life Cycle Selection & CustomizationCustomizing the standard process for the projectStandards for documenting for the customized process

Collect and disseminate process information with the repositoryReview the information in the repository to ensure its integrity and qualityManage and control the information in the repositoryControl access rights to ensure information quality and integrity

Review and include the right itemsCatalog documents to facilitate accessReview revisions and update libraryMake library available to projects and other users

Periodically review use of each document and use the information to maintain the libraryManage and control the contents of the library

Managed & Controlled SpecificationA 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.

Develop & maintain standard

software & systems

process(es)

Monitor & communicate

use of standard software/systems

process(es)


ORGANIZATIONAL PROCESS DEFINITION

Goals:• Develop & maintain standard

software & systems process(es)• Monitor & communicate use of

standard software & systems process(es)

ORGANIZATIONAL PROCESS DEFINITION ACTIVITIES



TRAINING PROGRAMGoals:• Plan training• Offer technical & management training courses• Train individuals

Commitment

Ability


Create Training Group

Staff the training group with the right mix of skills/knowledge

Plan training

INSTITUTIONALIZING TRAINING AND ACTIVITIES

Train individuals

Publish organization wide training policy

Provide adequate resources & funds for training

Offer technical & management

training courses

Measure & Analyze

Monitor Implementation Periodic Upper Management Training Program review

Track status of training activities & the overall training program

Orient (brief) Managers of software and systems groups on the training program

Prepare organization level training courses in compliance with organization wide training standards

Create and use a procedure to waive training if individual(s) have requisite skills/knowledge for their envisioned role(s)

Maintain training records

Every project has a training plan it maintains, which addresses its specific training needs

Plan, and revise organization wide training plan in compliance with a written, standard procedure

Conduct training in compliance with organization wide training plan

Requires identification of role specific skills/knowledgeRequires identification & approval of training vehicles & methodsRequires development of organizational skills by training individuals to fill project needsRequires right mix of appropriate in-house & external training; articulate the policy for this

Assign a ManagerProvide the right tools and automation (such as work stations, training design & presentation equipment & software, database tools etc.)Provide the right training facilities

Measure the training program quality

Periodic independent training program evaluationAudit training activities and work products, and report results

Verify compliance with the standard process for developing and revising training plansVerify compliance with the standard process for developing and revising training coursesMaintain training records in compliance with requisite standardsVerify that identified training needs of individuals are being met Verify compliance with the training planSkill 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 trainMethod 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 plansSpecify and schedule specific training based on timed organizational skill requirementsRevise training plan in step with changing requirementsReview training plan and significant revisions with impacted individualsManage & Control training planEnsure impacted groups and individuals can access the training plan conveniently and easily

Describe each training courseReview training course materialsManage & Control course materials

Time specific training with organizational requirementComply with planned source of training: external Vs. training groupComply with training resource plan: Funding, staff, tools & facilities to conduct,prepare and procure trainingComply with training material standards developed by the training groupConsider the training groups schedule for developing and revising training courses Comply with the training schedule based on projected timings and estimated numbers of traineesComply with procedures

Keep records of people who complete training courses & approved training activitiesKeep records of individuals who successfully finish the training required of themProvide convenient access to individuals’ training records for use in staff and management assignments


STANDARD PROCESS DEPLOYMENTGoals:• Tailor the standard software/systems process for

individual projects• Follow the tailored process for project planning &

management

Commitment

Ability

Train project staff responsible for tailoring the standard process and its assets on their use and customization (as described in the training KPA)

Tailor the standard software/systems process for individual projects

INSTITUTIONALIZING STANDARD PROCESS DEPLOYMENT AND ACTIVITIES

Publish organization wide policy for using the standard process and process assets for planning & managing software & systems engineering projects

Provide adequate resources & funds for managing the project in compliance with the standard process

Follow the tailored process for project planning & management

Measure & Analyze

Monitor Implementation Periodic Upper Management project activities review

Track Effectiveness of integrated business process and software management

Train Managers of software and systems groups on management of the technology, people and requisite administration

Require each project level process be tailored from the standard processRequire that deviations from the standard process be documented & approvedRequire that every project conforms to the process that it has tailored for itselfRequire that every project store the requisite metrics in the organizational process repository

Project Manager reviews activities periodically or when contingencies or other events occurConduct 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 processVerify compliance with the process for project planning & planning for management of consonant risksVerify compliance with the project level project management processVerify compliance with the process for supplying the right information to the organization-wide process repositoryVerify compliance with the process for using the organization wide process repository to tailor the project level process



Tailor the standard process to create the project level software/systems process

Choose approved project life cycle,Modify chosen life cycle, if need be in compliance with tailoring criteria & guidelinesDocument modifications in compliance with organization wide standardsEstablish project life cycle and document it

Describe the project level software & systems processSEPG 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 appropriateManage & control the project level software/systems process

Comply with a published procedure when revising the project level process

Systematically document & review changesReview and approve proposed changes to the project level process

Lessons learned from organization wide project monitoringProposed project level changesProcess and product measurements

Comply with a published procedure to develop and revise the project plan


Tailor the standard software/systems process for individual projects

Follow the tailored process for project planning & management

Comply with the project level process in managing the project

Use the process repository for planning & estimating

Manage work Product size and complexity in compliance with a published procedure

Use data from similar projects if availableCompare parameters for sizing, effort, cost, schedule, use of critical computer (& other) resourcesStore the project’s planning & re-planning data, and actual performance in the process repository

Establish and document readiness and completion criteria; use them to trigger or end key tasksDocument project re-planning criteria/triggersStore lessons learned (management & technical) in the organization’s process repositorySystematically review lessons learned to plan, estimate, track and replan the projectStaffing plan must address project’s needs for special skills and business domain knowledgeIdentify and document the project’s specific training needs stakeholdersConsider differences and potential problems, and adjust plans and processes for interacting with different stakeholders

Estimate, plan and track based on key project tasks and work products described by the project level processCollect, analyze and report requisite measurements; include these activities in the project plan

Compare & record business application & design approachesConsider & record reasons for differences & similarities in project parametersRecord the reasons, judgments and risks for the project estimates

Manage work Project cost & effort in compliance with a published procedure

Manage use of computer resources in compliance with a published procedure

Comply with the published procedure for assessing, managing and recording project risk

Review each project periodically to align it with projected user, customer and business need

An independent group must review the estimation procedures process engineer have used, and guide them on use of historical information in the process repositoryInflate risky estimates by a contingency factorIdentify reusable componentsIdentify and closely monitor factors that might affect work product size & complexityEstablish a threshold of size and complexity for each managed item, which will trigger action if crossed

Adapt effort, cost & staffing profiles to fit the project; use historical data if availableAdjust the parameters used for estimating cost and productivity to fit the project profileEstimate overall effort and cost from those of individual tasks to facilitate effective cost & effort managementReview the actual cost and work completion against the plan to revise estimates of remaining effort & costEstablish a threshold of projected cost & effort for each task (activity or phase), which will trigger action if crossed

Reviewers ensure right use of procedures & dataPeer & experts review estimates that lack consensus

Document rationale for contingencyAssess & record risk of removing or reducing contingency

Update estimation parameters & models when requirements change significantlyUse actual productivity & cost data when available

Estimates based on analysis, simulations, prototyping or pst experience

Obtain/tune critical computer resources to meet the project’s operational and development (& analysis) requirementsMeet computer resource requirements of software & business systems componentsInflate initial estimates of critical computer resources by a requisite risk factor; document it with reasonsEstablish 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 & staffingIdentify, negotiate and flag critical dependencies in the project & software schedulesFlag critical paths in the project & software schedulesRegularly track critical paths and dependenciesDocument a threshold estimate for each critical path, which will trigger action if crossed

Record rationale & data sourcesRecord assessments of resemblance & differences in design & application between the project and historical referenceRecord the reasons (& risks for credible estimates

Comply with a published procedure in managing critical paths and critical task dependencies in the project’s task plan

Track & re-assess risks at select project checkpoints, or when significant changes impact the project; revise plan if need be

Identify and manage risk in compliance with a published planComply with the project level process in developing contingency plans over its full lifeDocument alternatives and criteria for choosing eachConduct peer reviews before releasing the the software/system, or its significant revisions/changesManage and control the risk management plan

Communicate risks, results of mitigation & risk management plan to software, business systems and all impacted groups

Risk ManagementExperience 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

Identify options, assess impact & feasibility, consider providing reserves, etc.

Review and revise priorities and risk management plans at checkpoints/incidentsMonitor risks to refine risk assessment & risk management plans

Collaborative DevelopmentIncorporate collaborative principles from Workforce Development

CAPABILITY LEVEL 3Standardized Best Practices in useSTANDARD PROCESS

DEPLOYMENTGoals:• Tailor the standard

software/systems process for individual projects

• Follow the tailored process for project planning & management

STANDARD PROCESS DEPLOYMENT ACTIVITIES

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.



Goals:• Define, integrate & consistently perform

software & systems engineering tasks• Keep work products mutually consistent

Commitment

Ability

Train technical project staff adequately to enable them to measure up to their roles in the project

INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES

Publish the policy for performing prescribed activities in software & business systems engineering projects

Provide adequate funds & resources to execute software/business engineering tasks

Keep work products mutually consistent

Measure & Analyze


Periodic Upper Management project activities review

Measure the quality & functionality of the product delivered by the project

Orient Managers of software and systems groups, including project managers on the technology used by the project

Require each project perform the tasks prescribed by the (project level) tailored processRequire that the right tools and methods be used to build the business system & softwareRequire that every plan task and product be traced back to a requirement it supports

Project Manager reviews activities periodically or when contingencies or other events occurConduct QA reviews and audits of both project activities & work products, and report the results

Sufficient availability of adequately skilled persons for every taskSufficient supply and availability of requisite tools for every task

Orient technical project staff adequately to enable them to measure up to their roles in the project

Track status of business process/software engineering activities

Review & verify accuracy, consistency, completeness, feasibility & testability of requirementsVerify compliance with initiation & completion criteria for every software/systems engineering taskVerify product compliance with requisite standards and requirementsVerify compliance with requisite testing requirementsVerify compliance with published plans and procedures for systems acceptance testingVerify that test acceptance criteria complies with the published test planVerify satisfactory test completion & record keepingVerify problems & defects are recorded, tracked & addressedVerify that requirements are traced through to design, code/knowledge component & testingVerify compliance of published operating & maintenance instructions against published baselines & requirements before releasing the product for use

Integrate the right methods & tools into the project level process

Integrate engineering tasks in compliance with the project level processChoose the right methods & tools for the project, and document the reasons for eachChoose the right model for the projectProduct development and maintenance tools are also governed by configuration management

Focus on service reuse for new service and solution development


Define, integrate & consistently perform software & systems engineering tasks

Comply with the project level process when developing, maintaining, recording and verifying requirements.

Requirements analysis methods are effective (for example, Object Oriented Analysis, Knowledge Artifacts, etc.)Requirements analysts review requirements, identify and resolve issues.

Systems and acceptance testers verify testability of each requirementValidate the method(s) of ensuring that all mutually agreed upon requirements will be satisfiedEnsure peer review of consolidated & published requirements before finalizing itApprove 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 managementChange requirements for automation whenever a changes in overall requirements impacts it

Record requirements for automating the business processAnalyze clarity, feasibility, mutual consistency, testability and completeness of requirements; review & resolve issues with originators of problem reqirements Record requirements,alternatives, and their rationale


Mutually consistent plans, processes, requirements, software, test plans & procedures, etc.


Define, integrate & consistently perform software & systems engineering tasks


Comply with the project level process when developing, maintaining, recording or verifying the process design that will satisfy requirements and will be implemented by software

Comply with the project level process to code/assemble, maintain, document & verify the software/ business process design that will satisfy requirements

Comply with the project level process when testing the software or business system

Comply with the project level process when planning or executing integration tests

Plan & execute acceptance tests to demonstrate requirements have been satisfied

Collect & analyze defect data from peer reviews in compliance with the project level process


Publish integration test plans, based on the project planStaff responsible for requirements, design and acceptance testing review integration test cases & proceduresTest for integration with the right versions of published requirements & designs

Comply with the project level process to develop & maintain documents which will be used to operate & maintain the software/ business system

Document work products & make the documents easy to getTrace requirements, designs, components, code & test cases to their source, and also to subsequent projectsManage and control documents that trace the connections aboveAnalyze & change work products, plans, activities & processes in step with growing understanding

Effective methods are used to build (code/assemble) the business systemAccount for customer/user needs, priorities, difficulty, integration & test issues when planning & sequencing work products (units of code/components)Peers review each unit of code/assembly of components (or Knowledge Artifacts) before the unit is finalizedPut the code/component assemblies under configuration managementChange the code/component assembly whenever requirement or design changes impact them

Right level & depth (for example, unit, integration, acceptance tests)Right test strategy & techniques (for example, black box, statistical etc.)Right scope and coverage

The test group that plans test cases & procedures must be independent of those who make the software or business systemPublish and review test cases and procedures with the right customers & end users before testingTest against a baseline - published requirements, systems & softwareRecord & track problems that emerge from testing to closureRecord test results and use them to determine if requirements have been satisfiedManage & control test results

Review & get approval of published acceptance & systems test plans from the right end users and customersAssign timely resources for testing to allow adequate time to prepare

Approach to testing & verificationResponsibilities of each stakeholderTest facilities, equipment, tools & other support requirementsAcceptance criteria

Establish and document readiness and completion criteria; use them to trigger or end key tasksComply with mandated & appropriate standardsUse effective design methods to design software & business systemsDevelop the software & systems architecture early, within the constraints imposed by the chosen project life cycleReview the architecture;resolve issues that may impact detailed designBase detailed design on the architecture

Publish the detailed design and the architecture; cover components, hardware, actors (mechanical & human) & interfaces between them

Business process & software designers review requirements, ensure issues, if any, are resolvedDevelop and review design criteria (for example, verifiability, compliance with standards etc.)

Peers review the design document before finalizing itPut the design document under configuration managementChange the design document whenever changes in requirements impact it

The right stakeholders (customers, designers etc) review early (draft) versions of documents, as early as possible in the project; record & act on their feedbackMatch & verify final documents against the software/business systems baseline for acceptance testingPeer review documentsManage & control documents

The right stake holders (users, customers, systems maintenance staff etc.) review & approve the final documents that impact them directly

Documentation specialists actively participate in planning, developing & maintaining documentsUse the right documentation tools & methods (word processors, graphics, document reuse tools, repositories etc.)

Determine impact before changing

Coordinate changes: products, plans, process specs & activities

If requirements drive change, change requirements first

Negotiate with, and communicate changes to all impacted groups

Builders of software/the business process (coders/assemblers) review requirements & the design to ensure that all issues that impact their work are resolved

Trace defects back to root causes - work products & work steps. It will prepare the organization for quantitative analysis of defects at Level 4

Develop and review test criteria with the right customers and end usersUse effective test methodsTest adequately

Establish & use readiness criteria for each test level (for example completion of peer reviews, successful testing of individual components, etc.)Conduct regression tests at appropriate levels when software, components or environments changePeers review test plans, procedures and cases before they are considered completeManage & control test plans, procedures & casesChange test plans, procedures & cases when the requirements, design, code or components being tested change

Establish Testing environment for testing with existing services



Goals:• Define, integrate &

consistently perform software & systems engineering tasks

• Keep work products mutually consistent

INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES

Commitment

AbilityCoordinate tool compatibility between stake holders

All impacted groups

mutually agree on customer

requirements

Engineering groups

identify, track and resolve

intergroup issues

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

Provide adequate resources & funds for coordinating the activities of stakeholders

All impacted group agree on

mutual commitments

between themselves

Project objectives and requirements must be reviewed and agreed upon by all stakeholders in the teamStakeholders coordinate plans and activitiesMaintain a positive environment, encouraging teamwork, mutual support, interaction & coordination

Measure & Analyze

Monitor implementation Periodic Upper Management process review

Track status of cross functional coordination

Train all managers in team work

Identify & track critical inter-group dependencies

A group that accepts work products produced by others must review them to ensure that they meet their needs

A published procedure is used to address unresolved cross functional issues

Customers & end users (or groups such as marketing that speak for them) participate with engineering groups to articulate clear requirements

Prioritize & identify critical requirements & characteristicsNegotiate critical dependencies & constraintsRecord agreed upon acceptance criteria for the end product that will be delivered to customers

Stakeholders work together to coordinate activities & resolve technical issues/risks

Coordinate activitiesManage issues

Communicate cross functional commitments, coordinate & track work done, in compliance with a published plan

Orient (brief) the task leaders of each group on the processes, methods & standards of the othersOrient team members of the cross functional team on working as a team

Periodic Upper Management process activity reviewProject Manager’s Periodic or event based activity review


Track & review design & development activities for hardware, software & components (including Knowledge Artifacts & their subassemblies)Assess & track cross functional risk

Clarify requirements & design issues; address & resolve project level conflicts if any Joint solutions & recommendations to address problemsAddress cross functional issues

Project scheduleContractual and technical issuesResponsibilities of each groupThe plan is a baseline

The plan coordinates all stakeholder activityThe plan is easily accessible and available to all stakeholdersThe plan includes all mutual commitments of all stakeholders & is kept up to dateThe plan reflects progress and project level changes; is updated especially when milestones are completed, or significant changes occurThe plan is reviewed by, and agreed upon by all stakeholders, especially the project manager

The work product(s) that will change handsWho will produce & accept the work product(s)When the work product(s) will be producedAcceptance criteria for these work product(s)

Actual or expected status/completion dates against the coordinated planEvaluate impact on future activities & milestones of late or early completionReport back problems, actual and anticipated, to the right managers

Articulate customer wish lists & needsMonitor status of technical activitiesAlign interpretation and implementation of requirements, as well as expectations across all stakeholdersReview commitments to ensure that they are being metReview technical risks & issues

Stake holders periodically exchange technical and other kinds of relevant information

Explicitly define every critical dependencyMutually negotiate critical dependenciesResolve available Vs. required work product dates with the project scheduleRecord, review & mutually agree between on dependencies between producers and receivers of every critically dependent work productRegularly track critical dependencies and take requisite corrective actions


INTERGROUP COORDINATIONGoals:• 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


PEER REVIEWGoals:• Conduct peer reviews of work products in a planned manner• Identify and remove defects in work products

Commitment

Ability


Train peer review leaders

Conduct peer reviews of work products in a planned manner

INSTITUTIONALIZING PEER REVIEW AND ACTIVITIES

Publish organization wide peer review policy

Provide adequate resources & funds for peer review of each work product that must be so reviewed

Identify and remove defects in work products

Measure & Analyze


Measure progress, & track status of peer review activities

Plan peer reviews; publish plans

Conduct the peer review in compliance with the published procedure

Record peer review information

QA audits or reviews peer review activities & work products; reports its findings

Verify reviews are being conducted as planned Verify adequate training of peer review leaders to fill their roles effectivelyVerify adequate training of peer review participants to fill their roles effectivelyVerify 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

Examples of Checklist ItemsCompliance with standards & procedures, completeness, correctness, maintainability, compliance with construction rules, etc.

Defects must not be used to evaluate individuals or organizations. It will undermine the purpose & effectiveness of the peer review

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 peersRequire leaders be trained in leading peer reviewsRequire that peer reviews focus on work products under review, not those responsible for producing themRequire that management does not use peer reviews to evaluate individual performance

Prepare and distribute peer review materialsLead the peer reviewReview distributed peer review materialsParticipate in peer review, identify defects; participate in follow up reviews to rectify or follow up on defectsMonitor rework of work products that had to be rectified (based on its peer review)Record & report peer review findings

Train peer review participants

Trained leaders lead peer reviewsDistribute review materials with enough lead time before the review to give reviewers adequate time to prepareEach reviewer knows the role assigned to him or her for the peer review sessionEnforce readiness & completion criteria; report issues involved in satisfying these criteria to the right managersInterpret and use review criteria checklists consistentlyTrack action items to resolutionTasks are considered complete not only after finishing requisite peer reviews, but also after all required rework is completed

Tailor checklist to fit the work product under reviewPeer review check lists; also review them with likely users

Number & frequency of reviews;

Number of work products reviewed against plan

Defects discovered by peer review Numbers & proportion of work products reviewed

Rework & rectification measurements Actual Vs. planned effort spent on peer reviews

To be fruitful, the review must be of work products, not people or organizations. The review leader must enforce & facilitate this key principle

LEVEL 4 ANALYSIS HIERARCHY CAPABILITY LEVEL 4Quantitative 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

Process Capability

Specific goals that will contribute the most to quantitative quality management

Assure product quality

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)

Assure process quality

This is a close polymorphism

of QUANTITATIVE

PERFORMANCE

MANAGEMENT from the


Included here for IT Service

evaluation, specifically.

CAPABILITY LEVEL 4Quantitative Quality Management in PlaceQUANTITATIVE PROCESS MANAGEMENTGoals:• 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)

Commitment

Assign responsibility for coordinating quantitative process management to the SEPG

Commitment & support for requisite data collection & analysis

Plan activities to quantitatively manage business systems & software development processes

Establish & use requisite quantified tolerances from the organization’s standard process

Publish, & Commit to an organization wide policy for measuring & quantitatively controlling the project level software/systems process

Provide adequate resources & funds for quantitative process management activities

Quantitatively control business systems & software processes

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)

Require compliance with a published project level plan to quantitatively control the project level software/systems processRequire that individuals’ performance information be kept confidential, and access to it appropriately guarded

Measure & Analyze

Monitor Implementation Periodic Upper Management quantitative process management activity review

Verify that the plans for quantitative process management are being followedVerify that the procedures for quantitative process management are being followedVerify that requisite data for quantitative process management is being collected & analyzed

Measure & track the status of quantitative process management activities

Train individuals & support staff engaged in quantitative process management appropriately

“Quantitative Control” means any quantitative or statistical method that will analyze performance, identify reasons for variation (for example, transient conditions such as inadequate computer capacity, specific individuals or organizational units taking unexpected actions, unexpected factors in the business environment, etc.), and bring the performance within well defined limits.

Require analysis of process performance and maintenance of a baseline of tolerances for performance parametersRequire 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 activityEnable and institute an organization wide measurement programProvide the right tools and automation (statistical & quantitative analysis tools, problem tracking tools, database management systems, etc.)

Periodic & event based Project Manager’s quantitative process management activity reviewQA review/audit of quantitative process management activities & work products

Orient those engaged in projects & related activities on the value and goals of quantitative process management

Requisite data existsRequisite data is collectedThe collected data is neededThe data is aligned with the goals of the measurement programThe cost of data collection is justified by its valueThe data is tapped at the right place, & the right point in the project’s lifeThe data is timely, accurate, valid & reliableThe confidentiality of the data is adequately protected

Ability


CAPABILITY LEVEL 4Quantitative Quality Management in PlaceQUANTITATIVE PRODUCT QUALITY MANAGEMENTGoals:•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

Plan activities to quantitatively manage business systems & software development processes

Establish & use requisite quantified tolerances from the organization’s standard process

Quantitatively control business systems & software processes

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

Comply with a published procedure to create & maintain the baseline of tolerances for the organizations standard process(es)

Comply with the published procedure for formulating each project’s quantitative process management plan

Stick to the project’s published quantitative process management plan

The project level process must prescribe the project’s data acquisition & quantitative analysis strategies

Align the planPeers review the planSEPG reviews the planManage & Control the plan

Consider task dependencies & relationshipsConsider project work products and their mutual relationships, as well as their relationships with the project level processConsider points of process control and data acquisition

The data must support organizational and project objectivesPrecisely define each metric & its use, and data items that must be collected, their uses, analysis, and the process control points they will be tapped fromConsider the entire software/business system life, pre and post development through retirement when determining what metrics will be neededThe 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 processGoverning processes (control activities) must control the requisite parameters being measured as a natural and integral part of the software/systems processMetrics must support the analyses prescribed in the planThe quality of metrics data (validity, reliability, accuracy & timeliness) must be assessed by an independent groupPreserve the metrics data in the process repository

The procedure defines data analysis activities, the inputs, processing, outputs, techniques, decision criteria & actionsThe procedure restricts the scope of measurement to the activities of the project level software/systems processThe procedure specifies appropriate and valid measurements for the characteristics it purports to measureThe procedure specifies expected means and variances for each metricThe procedure defines tolerances for each metric and establishes it as the baselineThe 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 limitsThe procedure establishes baselines for metrics definition, actual values and acceptable limitsManage & control process performance baselines

Review results of the analysis with those who are affected by it, before reporting it to othersManagers (including upper management) and task leaders must get the regular reports they needThe Quality Assurance group must get the regular reports it needsManagers 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 projectsThe 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 improvementThe procedure asks that the baseline tolerances in the standard process be Managed & ControlledIn 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 processThe procedure asks that the impact of changes to the standard process on the tolerance baseline be tracked,analyzed and assessed

Align with the organization’s strategic product quality, productivity & time to market goals

Derive the plan from the organization’s standard processAlign with the project’s product quality, productivity & time to develop goals

Factor in the actual performance of similar project level software/systems processesBase the plan on the project level software/systems process

Align with the organization’s measurement programPlan for Business Activity Monitoring for identifying business process bottlenecks

Activities must support plan objectivesMeasure & analyze tasks & activities

Conform to planned metrics & measurement procedures

Stick to planned activities & schedules

Stick with planned individual & group responsibilities for activitiesUse the planned staff, tools & other planned resources for each activityFollow quantitative process management procedures

Measure and analyze Service Reuse

QUANTITATIVE PROCESS MANAGEMENT ACTIVITIES


CAPABILITY LEVEL 4Quantitative Quality Management in Place

QUANTITATIVE PRODUCT QUALITY MANAGEMENTGoals:• 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

Commitment

Ability

Provide adequate resources & funds for managing the quality of work products

Plan activities to quantitatively manage the quality of business systems & software produced by software and systems engineering projects

QUANTITATIVE PRODUCT QUALITY MANAGEMENT

Define measurable goals and priorities for business systems & software produced by software and systems engineering projects

Commit to a following published organization wide software & business process quality management policy

Quantify, track and manage progress towards these goals

Measure & Analyze

Monitor ImplementationUpper Managers’ periodic quality management review

Track status of software & business system quality management activities

Train project participants, especially engineers, writers, QA & configuration management staff in relevant product quality management activities

Measure and analyze actual work product quality against goals based on specific events

Appropriately apportion quantitative quality goals among the project’s contractors

Follow the published procedure to create & maintain the project level quality plan

Base quality management activities on the quality plan

Define, monitor & revise quantitative quality goals throughout the project’s life

Train project participants, especially engineers, writers, QA & configuration management staff in relevant product quality management

QA review of Quality Management activities & work products

Project Manager’s periodic & event based quality management review

Identify work product quality features(performance in functionality & information quality, usability, creatability & maintainability)Identify specific quantified quality measures for (requisite) work product featuresSpecify quality goals in terms of acceptable ranges for each quantified measurePublish the quality goals as an integral part of the project planSegregate and publish quality goals for each step of the software/system development life cycleRevise 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 quality goals relevant to the task at handAt the beginning of each task, identify task plans for reaching quality goalsAt the beginning of each task, review any changes made to address requisite quality goals

Plan & execute project tasks to address its work product quality goalsMeasure the quality of work products of each stage of the product life cycle, through development & retirementAnalyze quality measurements to determine if goals have been metAct in compliance with the quality plan to align work product quality with corresponding goalsResolve conflicts between quality goals

Every project must define & measure quality metrics for key work products & the business process/softwareEvery project must define & measure progress towards quality goals for key work products & the business process/software it is creating.

Each project’s quality management activities must support the firm’s commitment to enhance the quality of its business processes & software

Assign role responsibilities for managing quality to stake holders; define the criteria that each stakeholder will use to determine its success in the role assigned to it

Specialized quality engineers (such as those who specialize in work product reliability, safety etc. are on hand to participate in setting work product quality goals and in reviewing progress towards the goals setProvide the right tools and automation (statistical tools, quality tracking & analysis tools, data collection tools, spread sheets, database management systems, process & life cycle simulators, process & code audit and analysis tools, etc.)

Audit or review the project’s quality planAudit or review the process for setting & tracking quality goals

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 goalsAlign 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 presentUpdate the quality plan at the start, and at every major milestone & whenever requirements changePeer review the quality planReview the quality plan with stakeholders (or their representatives)Upper management review of quality plansManage & control the quality planEverybody impacted by the quality plan can access it easilyAddress 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 satisfiedAddress planned actions if projections show that work product quality will be short of that planned

Analyze, & resolve conflict based on cost of achieving each conflicting goalConsider alternative goals aligned with business strategies & short term prioritiesGive users & customers (or their representatives) a voice in balancing conflicting quality goalsRevise work products and plans to reflect compromises

Measurement & control of quality with the project level software/systems processPlanning quality goals & commitments for work products

Methods & techniques for collecting requisite information, measuring, controlling & planning the quality of the software & systems process and its work products

Purpose & benefits of quantitatively managing product quality


LEVEL 5 ANALYSIS HIERARCHY CAPABILITY LEVEL 5Continuous Improvement and innovation 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

Process Capability

Specific goals that will contribute the most to stabilizing change and making it routine

GOALS OF KEY PROCESS AREAS (KPAs)

DEFECT PREVENTIONGoals:•Plan defect prevention•Seek & Identify common causes of defects• Prioritize and systematically eliminate causes of defects

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

PROCESS CHANGE MANAGEMENTGoals:•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

Deploy a formal & organization-wide standard process for continual technology process improvement & innovation

This is a close polymorphism of CONTINUOUS CAPABILITY IMPROVEMENT from the Workforce Maturity Model. Included here for IT Service evaluation, specifically.

CAPABILITY LEVEL 5Continuous Improvement Institutionalized

DEFECT PREVENTIONGoals:• Plan defect prevention• Seek & Identify common causes of defects• Prioritize and systematically eliminate causes for defects

Commitment

Assign responsibility for coordinating defect prevention activities organization wide to the SEPG

Plan defect prevention

INSTITUTIONALIZING DEFECT PREVENTION

Prioritize and systematically eliminate causes for defects

Publish, & Commit to an organization wide policy of defect prevention

Provide adequate resources & funds for project & organization wide defect prevention activities

Seek & Identify common causes of defects

Every project must publish, & Commit to an project specific policy for defect prevention

Measure & Analyze

Monitor Implementation Periodic Upper Management defect prevention activity review

Verify that staff are trained adequately to fulfill their defect prevention responsibilitiesVerify that the proper conduct of kick-off & causal analysis meetingsVerify that the procedures for quantitative process management are being followed

Measure & track the status of defect prevention activities

Train individuals & support staff in discharging their defect prevention responsibilities

Periodic & event based Project Manager’s defect prevention activity review

QA review/audit & report of defect prevention activities & work products

Ability

Require long term plans for funding defect prevention, staffing & allocating needed resources for itRequire that requisite resources be allocated for defect prevention activitiesRequire org. wide implementation of defect prevention activities to improve software, business systems, the processes that make themRequire that the results of defect prevention activities be reviewed to ensure that they are effectiveRequire that management & technical action items identified by defect prevention activities be recorded, addressed, tracked to resolution

Require allocation of needed resources for defect preventionRequire project 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

Assign responsibility for coordinating defect prevention in the project to a project level counterpart of the SEPG

Integrate appropriate responsibility for defect prevention into plans for individual role-responsibilitiesPlan management participation in defect prevention activitiesRepresent every software project in the organization wide defect prevention teamProvide the right tools and automation (statistical & quantitative analysis tools, defect tracking & causal analysis tools, database management systems, etc.)

Frequency distribution of defects by major defect classFrequency distribution of defects prevention actions by major classes of actionsSignificant defect prevention actionsSummary status of proposed open & closed actionsSummary of effectiveness, cost reductions aand benefits that may be attributed to defects preventedActual costs incurred by completed defect prevention activities versus projected future cost of (planned) defect prevention



Prioritize and systematically eliminate causes for defects

Seek & Identify common causes of defects

Comply with a published procedure in conducting causal analysis meetings

Periodically review, coordinate & implement defect prevention actions recommended by causal analysis team; each defect prevention team meets periodically to do this.

Record & track defect prevention information across defect prevention teams


Start every task with a preparatory meeting of those involved in the task to prepare for requisite activities, including those required to prevent defects

Identify defect prevention activitiesSchedule defect prevention activitiesAssign requisite responsibilities & resources, including staff & toolsPeer review the plan

Cover the project level process, standards, procedures, methods & relevant tools, emphasizing recent changesCover resources required (inputs) for the taskCover work products (outputs) of the task, with examples when availableCover criteria & methods for evaluating work productsCover criteria & methods for verifying compliance with the project level processList common errors and recommended preventive measures for the current task/phase of the project life cycleCover team assignments & role-responsibilities

Cover the task scheduleCover the product quality objectives for the task, in the context of those for the project

Require each team performing a task conduct causal analysis meetingsThe leader/facilitator of cause-and-effect meetings must have been appropriately trainedIdentify defects & analyze root causesCategorize defects by root cause (or kind of root cause)Recommend preventive actions & put it on recordCategorize & record defects by common causesRecord the meeting outcome for use by other projects & the organization as a whole

Record proposed actions of causal analysis meetingsRecord proposed actions that will be implementedManage & control defect prevention information

Meet soon after completing the task

Meet periodically even after the software/system is released for cause-and-effect analysis

If too many defects are discovered during the task convene a meeting right away

For lengthy tasks, meet periodically to prevent defects even as the task progresses

Identify defect prevention recommendations (of causal analysis teams) that will be addressedIdentify defect prevention action items requested by other defect prevention teams that will be addressedIdentify which defect prevention actions/practices of other defect prevention may be adopted (or adapted)Prioritize proposed actions (after preliminary analysis)Reassign proposed actions to other teams where appropriate;communicate request(s)Record & communicate reasons for proposed actions (or lack thereof) to those who requested themAssign responsibility for implementing actions; the team may take some actions directly & arrange for implementing others thru groups outside the teamReview results of defect prevention experiments; incorporate successful practices into the project/standard process across projects as applicableTrack action item status (including the status of proposed action items)Publish process improvement proposals for standard & project level processes; identify requestors/proposersReview & verify finished action items before closing themRecognize & reward significant defect prevention efforts & successes

Consider causes of defects

Consider cost of process improvement to remove defects

Consider the impact of not addressing defects

Consider the impact on process, work products & information quality

Comply with a published procedure when amending the standard process to prevent defects

Summarized information by kind of defectFrequency distribution of defects by significant defect classesSignificant innovations & actions that address each kind of defectSummarized status of defect prevention proposals & action items

Comply with a published procedure to amend the project level process to prevent 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

Proactively hunt down defects (At Level 1, the norm was reactive crisis management)

Go beyond immediate causes & determine why the defect escaped verification procedures, and if other defects might have been similarly missed

CAPABILITY LEVEL 5Continuous Improvement InstitutionalizedDEFECT PREVENTIONGoals:• Plan defect prevention• Seek & Identify common

causes of defects• Prioritize and systematically

eliminate causes for defects

DEFECT PREVENTION ACTIVITIES



TECHNOLOGY CHANGE MANAGEMENTGoals:• 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

Ability

Assign responsibility for coordinating technology change management to the SEPG

Support information gathering & analysis needed to evaluate the impact of changes in technology

Plan absorption of technological changes

INSTITUTIONALIZING TECHNOLOGY CHANGE MANAGEMENT

Make the right new technologies the norm in the right practices throughout the organization

Commit to following a published organization wide policy for improving technological capabilities

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.)

Evaluate the impact of new technology on quality & productivity

Upper management sponsorship of technology improvements

Require written objectives for technological changesRequire a published plan for changing technology in aligned with the published purpose of the change

The unit must coordinate and facilitate technology change

A unit within the SEPG could take this responsibility, or it could also be a group that works very closely with the SEPG

Upper management oversight of technology improvement

Measure & Analyze

Monitor Implementation Periodic Upper Management technology change management activity review

Track status of technology change management activities

Ensure that the process & work product information needed to analyze & evaluate the impact of technology changes & home in on the right technology is available

Upper management input and assistance in formulating a strategy to address product quality, productivity & product development cycle time objectivesUpper 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 strategyUpper management makes its commitment to managing technological change visible across the organizationUpper management establishes long term funding, staffing & resource plans for managing technological change

Upper management input and assistance in formulating a technology change management policyUpper management ensures adequate resource allocation for technology change managementUpper management assistance in aligning technology change management strategies with organizational strategiesUpper management participation in formulating technological change management plans

Coordination of requirements & issues across org. & all levelsSecuring support of staff & management & coordinates it across org. & all levels

Explore what might benefit from new technologyUpper management secures support of staff & management & coordinates it across the organization & all its levels

Automated recording of requisite process & product informationAbility to support requisite data analysisThe ability to appropriately present (display) selected data & analysis results

Train the (SEPG) unit responsible for it, in technology change management

QA review/audit of technology change activities & work products

Technology Change Management Plan reviewTechnology selection, procurement & installation process review

Summarize technology change management activitiesIdentify course corrections & strategy changesResolve issues that could not be resolved at lower organizational levelsApprove revised technology change management plans (if any)


Keep management & technical staff informed of new technologies

Comply with a published procedure when choosing & acquiring new technology

Pilot the technology where appropriate before inducting it as the norm

Plan technology change management

Identify technology change candidates (processes/areas) in coordination with individual projects & the SEPG unit responsible for technology change management

Solicit technology improvement suggestionsIdentify candidate technologies that might fitEvaluate how well each will fit current & future org. & project needs

Disseminate information on new technologies appropriately

Disseminate information on advanced technologies in use in different parts of the organization appropriatelyDisseminate information on the status of technologies being inducted into the organization appropriately

Record requests for technology acquisition, obtain requisite management approvals for requisite expense thresholdsPerform preliminary cost-benefit analysis of candidate technological changesUse selection criteria approved and predefined by the procedureRecord plans & requirements for the envisioned technological change

Where possible, estimate the life of the replacement or upgrade

Consider appropriate pilot technology installations to determine its effectiveness & economic value

Analyze the trade off between internal development Vs. external acquisition of the technology; publish & review the analysis

Review of technology induction requirements & plans by managers of impacted groups & the SEPG unit responsible for it

Comply with a published procedure when inducting new technology into the standard process

Comply with a published procedure to induct new technology into the project level process

Plan absorption of technological changes

Make the right new technologies the norm in the right practices throughout the organization

Evaluate the impact of new technology on quality & productivity

Role-responsibilities & resource requirements including staff & toolsTechnology strategy for strengthening the firm’s market position & and automation of the standard systems development process List technology change management proceduresApproach to new technology introductions in support of specific organizational or project needsPeer review the planPlan review by managers impacted by it

Identify processes that might benefit from changes in technology

Identify candidate technologiesDetermine the approach to identifying technology change opportunities

Estimate life of technology from introduction to replacementRecord make/buy trade-off studies & recommendationsDefine approaches for assessing unproven or high risk (candidate ) technologiesDefine technology acquisition & installation proceduresDefine training (initial/ongoing), support & consulting requirements

Systematically analyze the standard process; identify where it might benefit from new technology(A SEPG task)

Identify points of maximum benefit from induction of new technology into the standard processIdentify the technological changes that will help these areas, and the economic costs & benefits of these changesDefine the relationship between the chosen technology & the standard process; the places where the standard process will be impactedProject quantitative & qualitative results of the technological changeDetermine which changes must be piloted (if any)Prioritize technological changesRecord & publish the technology analysis

Pilot & prove the feasibility & economic value of new or untried advanced technologiesPublish pilot plans; cover objectives, evaluation criteria & activitiesManagers of impacted groups review & approve the pilot The pilot project consults, & gets implementation assistance from SEPG (the unit charged with technology change management )The development & maintenance environment of the pilot will validate making it the normCollect, analyze & publish the results of the pilot project

Record problems faced & lessons learned

Decide on broader use of the technology, termination, continuation or replanning of the pilot

Project the impact (& benefits) of broader or large scale use; assess uncertainty & risks inherent in the estimation

Concentrate on improving quality, timeliness & productivity

Periodically search for, & identify new technology that will support current & future needsSystematically review technology used outside the organization (including those used by competitors) & compare them with the organization’s current & planned technology

Systematically keep abreast of trends in technology & relevant work in new technology

Assess which technologies have been successful & where; review & record available information & experience; assess which will fit the current & future needsIdentify and implement Business process improvement based on SOA using BAM results


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

TECHNOLOGY CHANGE MANAGEMENT ACTIVITIES


Use Pilot projects to test & tune the technology to reduce risk

Proactively hunt for technological improvement

CAPABILITY LEVEL 5Continuous Improvement InstitutionalizedPROCESS 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

Commitment\

Train managers of units involved in software/business systems engineering in the process of process improvement (including the process of software improvement)

Plan continuous process improvement

INSTITUTIONALIZING PROCESS CHANGE MANAGEMENT

Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it

Commit to following a published organization wide policy of process improvement, including improving the processes for developing software & business systems

Provide adequate resources & funds for process improvement

Organization-wide participation in process improvement

Upper management sponsorship of process improvement activities

Measure & Analyze


Periodic Upper Management process improvement activity review

Track status of process improvement activities

Train stakeholders (or their representatives) in the process of process improvement (including the process of software improvement)

Recognize skilled & motivated people as the principle resource for process improvement

Control, development & dissemination of process changesCommunication, recognition & motivational activities needed for maintaining employee participation; the requisite administrative & human resources infrastructure to govern these activities

Support, guidance & leadershipProcess improvement Record maintenance

Train the upper management in process change management

QA review/audit of process improvement activities & work products

Upper management articulates long term process improvement objectives & plansUpper management commits adequate resources for process improvement activitiesUpper management coordinates process improvement goals of individual managers & units; validates their feasibility, risk & requisite aggressivenessUpper management monitors process improvement performance against goalsUpper management makes process improvement a priority area, and keeps a stable focus on it even when products are under pressure or in crisesUpper management resolves process improvement issues in a timely manner

Upper management rewards & recognizes employee participation in process improvement activities

Require measurable quantitative goals & tracking of actual performance against themRequire goals address product quality improvement, productivity improvement or software/systems development (& deployment) cycle times singly or in combinationRequire participation of all managers & staff in improving the software/systems process

Ability Assign seasoned methodologists with experience in software & systems process improvementProvide the right tools and automation (process automation & modeling tools, workstations, database & statistical analysis tools etc.)

Allocate resources for kinds of process improvement activities

Summarize participation in process improvement activitiesAssess process performanceIdentify what changes (if any) are required in process improvement goals or objectivesResolve issues that could not be resolved at lower levelsApprove revised process improvement plans (if any)

Verify that the process improvement plan is being prepared & followedVerify compliance with the process for initiating, submitting, reviewing & approving process improvement proposals, & planning process improvementsVerify how validly process measurements reflect actual performance of the process(es) in questionVerify 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 activitiesVerify how well actual improvements in the process (of developing software & business processes) achieves the goals set, & the plans made for it

Recognition & reward from sponsors are critical to success


Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it

Plan process improvement in compliance with the published procedure for it

Comply with a published procedure when processing process improvement proposals

Secure active participation of individuals in their assigned teams

Empower individual members of the organization to improve its processes through a process improvement program

Coordinate process improvement through the SEPG

Pilot the changed process (where appropriate) before making it the norm

Comply with a published procedure when making changed process the norm

Plan continuous process improvement

Organization-wide participation in process improvement

Conform to process improvement plan

Fully fund each team; plan & schedule its activitiesDefine clear, and if possible, quantitative goals of each effortSecure approval of plans from SEPG & managers of all impacted groups

Role-responsibilities & resource requirements including staff & toolsProcess improvement priorities & footprintsShort & long term process performance goalsTeams assigned for specific improvement in specified footprintsProceduresAdministration & Support pans that will continue to maintain & institutionalize process improvement

For upper management oversight of process improvement

For identifying, evaluating & introducing the right improvementsFor coordinating process improvement between managers involved

For assembling & assigning teams/task forces to address specific improvements and/or footprints

Procedures for encouraging participation & facilitating process improvement activitiesInclusion of administrative staff in overseeing & reviewing process improvement activitiesPlans for recognizing individual roles & contributions to process improvement

SEPG defines, creates & updates process improvement records

SEPG sets goals & plans for measuring the performance of processes that create software & business systemsSEPG reviews these performance goals with upper managementSEPG participates in defining process improvement training needs; assists in developing course materials & supports their presentationCreates and updates procedures for processing process improvement proposalsSEPG reviews improvement proposals for the processes that create software & business systems; coordinates requisite actionsSEPG tracks participation in, accomplishments & the status of process improvement activities; reports back periodically to upper managementSEPG coordinates & tracks changes to the standard process

Align the plan with business & strategic plans, as well as customer satisfaction indicatorsPeer review the planReview the plan with all managers impacted by itManage & control the plan

Proposals may be submitted at any time for any part of any processEvaluate each proposal; accept or reject it. Record the decision with reasonsDetermine the benefits of each proposalPrioritize (accepted) proposals; focus on high priorityPlan & 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 beTrack the status of each proposalAct on proposals that have been outstanding for unusually long periodsReview high impact (in terms of customer satisfaction, product quality or productivity) proposals with the right managers before implementing themReview, 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

Tune the process, and record any changes during the pilotRecord problems & lessons learnedEstimate impacts proposed changes if made the norm, their benefits& risks & the uncertainty of these estimatesDecide on broader deployment of the piloted process & on terminating, continuing or replanning the pilot project

Fund & provide all resources needed to change the processRecord, review and agree upon the strategy for tracking changes in performance & requisite data collectionUpdate requisite training in step with changes in the process; train before making the changed process the normBefore deploying change beyond a pilot project, enable requisite support & consultation to match the projected need for it; continue both as long as neededMake requisite changes to the standard processMake requisite changes to the project level processes

All persons responsible for implementing change agree on strategyDetermine what to measure & how; collect data automatically

Keep records of process improvement activitiesKeep records of initiating, implementing & the status of process improvement proposalsProvide easy access to these recordsKeep process improvement histories & report improvement data

Inform technical staff & their managers of changes in state and/or the results of process improvement activities when these changes occur

A summary of major process improvement activitiesSignificant innovations & actions in process improvementSummary of proposals submitted, open and completed

Always change from a stable & controlled base

These records chronicle the organization’s adaptability - its cycle times & capacity for change

Cross functional teams are key to process improvement; processes often cross organizational & functional boundaries, integrating them to deliver external value


PROCESS CHANGE MANAGEMENTGoals:• 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

PROCESS CHANGE MANAGEMENT ACTIVITIES
