Project Management Maturity Model

Project Management Maturity Model
12/22/14 © 2014 Amit Mitra and Larissa Zhurakovskaya

Evolution of Project Management Maturity
MATURITY OF PROJECT MANAGEMENT Level 1 (Initial) Unpredictable, poorly controlled processes Level 2 (Repeatable) Can consistently repeat previously mastered tasks Level 3 (Defined) Best Practices standardized for Organization Level 4 (Managed) Quantitative standards & controls in place Level 5 (Optimizing) Focus on continuous Process Improvement

LEVEL 2 ANALYSIS HIERARCHY
In moving from level 1 to 2, managing requirements will benefit the organization more than optimizing engineering methodology CAPABILITY LEVEL 2 Consistently Repeatable Process Process Capability GOALS OF KEY PROCESS AREAS (KPAs) REQUIREMENTS MANAGEMENT Goals: Establish, control & utilize a Requirements Baseline Ensure consistency of Requirements with project plans, activities & Work products Common understanding with customer Specific goals that will contribute the most to achieving consistently repeatable results PROJECT PLANNING Goals: Estimate projects in writing for planning & tracking purposes Plan & document project activities & commitments Ensure commitments are agreed upon between all impacted groups Engineering plan & risk management PROJECT TRACKING & OVERSIGHT Goals: Track actuals against plans Take & manage corrective actions on deviations to closure Agree on (commitment) changes over the project’s life across all impacted groups Make progress against visible & actionable plan QUALITY ASSURANCE Goals: Plan Quality Assurance activities Objectively verify that work products & activities comply with standards Communicate QA results & activities to all impacted groups Upper management resolves noncompliance when it cannot be resolved at the project level Make progress & product quality visible CONFIGURATION MANAGEMENT Goals: Plan Configuration Management activities Identify, control & make selected work products available on time Control changes to work products Communicate systems, software and component baseline statuses to all impacted groups Maintain integrity of work products over the project/service’s live CONTRACT MANAGEMENT Goals: Select qualified contractors & subcontractors Agree on mutual commitments with contractors Maintain ongoing communication with contractors Track contractors’ performance against commitments Choose & manage contractors effectively

Consistent Process Repeatability
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTAIONALIZING REQUIREMENTS MANAGEMENT PROCESS AND ACTIVITIES REQUIREMENTS MANAGEMENT Goals: Establish, control & utilize a Requirements Baseline Ensure consistency of Requirements with project plans, activities & Work products Publish requirements analysis policy SLA agreements with Service owners Establish Requirements Analysis Responsibility Requirements Documentation Commitment Impacted groups requirements review Requirements change control & alignment of plans, activities & work products with changes Ability Responsibility for Managing & recording requirements & corresponding solutions Requirements change control responsibility, Change control responsibility for ownership of solutions Document Requirements Document Commitments, Terms & Conditions Document functional, non-functional & Technical requirements Document acceptance criteria Requirements Baseline A formally agreed upon specification, under change control, on which all development is based Provide adequate resources & funds Requirements allocated to managers with both Applications Domain & Technical expertise Adequacy & access to requirements Management tools Establish, control & utilize a Req. Baseline Provide adequate expertise/training : Procedural, methodology, standards, tools & subject matter training Measure & Analyze Track requirements & corresponding activities’ status, statistics & anomalies Monitor implementation Periodic Upper Management review of Requirements Management & allocation activities Periodic & event/exception triggered Project Manager review of Requirements Management & allocation activities Quality Assurance review/audit of Requirements Management & allocation activities & work products; Reports of results KPA execution (activities) Assure problem resolution, review & Engineering group’s consent prior to commitment Assure plans, activities & work products are revised when requirements (or solutions responsibilities) change Assure changed commitments are negotiated with impacted groups Resolve missing & incomplete requirements/responsibility for solutions Resolve clarity, feasibility, consistency & testability of requirements & allocated responsibilities Ensure consistency of Requirements with project plans, activities & Work products Review, resolve & obtain Engineering group’s consent before committing to requirements Review & resolve exceptions with the group responsible for allocating ownership of solutions Negotiate commitments with impacted groups Negotiate SLA agreements and chargeback model with service owners Have requirements drive engineering plans, activities & work products Manage & control requirements & allocation of responsibilities for solutions (baseline, versioning, configuration, archival) Base plans, activities & work products on requirements Base software requirements on those of other groups Assess impact, and negotiate changes to commitments (internal- with impacted groups; external- with upper management first) Review & change requirements & responsibilities for solutions as needed Identify, evaluate (including risk), record, plan and communicate to all impacted parties, changes to plans, activities & work products caused by requirements changes

INSTITUTIONALIZING PROJECT PLANNING
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTIONALIZING PROJECT PLANNING REQUIREMENTS MANAGEMENT Goals: Establish, control & utilize a Requirements Baseline Ensure consistency of Requirements with project plans, activities & Work products Baseline A formally reviewed and agreed upon work product or specification that can only be changed through formal change control procedures, and is the basis for further development Commitment Designate Project (& subproject) Planning Manager(s) Publish written project planning policy Base plan on requirements & solution responsibilities allocated to each group Document an approved statement of work Control & manage the plan via a baseline (change, status, version, archive control & management) Plan & document project activities & commitments Review estimated size, cost, schedule & other commitments with all impacted groups Ability Negotiate commitments between all impacted managers(software as well as other groups) Review all external commitments with upper management Assign project planning resp. Establish scope, goals, constraints & assumptions (technical , schedule, budgetary, resource etc), sponsors & end users of system, standards, responsibilities, impact & dependencies (internal & external organizations) Review& consent of all impacted managers & groups (project, external & internal) Manage & control the statement of work via the baseline Project (Subproject) Manager(s)coordinate planning & are responsible for their own plans aligned with their commitments & delivery responsibilities Partition & assign responsibilities, activities & work products between managers in a traceable & accountable manner Provide adequate resources & funds Planners have both Applications Domain & Technical expertise Adequacy & access to planning & estimation tools Estimate projects in writing for planning & tracking purposes Train planners (Management & staff) in estimating & planning (procedures, methodology, standards, tools & subject matter) aligned with their responsibilities Measure & Analyze Track project plan & planning activities status & statistics (milestone status, actuals vs. plan, changes etc.) Monitor Implementation Periodic Upper Management review of Project Planning activities Performance: Technical, cost, staffing, schedule Address unresolved issues & conflicts Ensure commitments are agreed upon between all impacted groups Periodic & event/exception triggered Project Manager review of planning Address risks Assign, review& track action items to closure Review & address risks Prepare & distribute Review Summary to all impacted parties Involve all impacted groups Review status & results against requirements & statement of work Quality Assurance review/audit & report of Project Plans & planning activities Address inter-group dependencies Address unresolved issues & conflicts Assign, review& track action items to closure Prepare & distribute Review Summary to all impacted parties Managed & Controlled Plan A formally agreed upon project plan, under change control, such that the version utilized at any point in time, past or present, is known Plan content Plan standards Estimation activities Planning activities KPA execution (activities) Plan review & commitment activities CONTINUED ON NEXT PAGE

PROJECT PLANNING ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability PROJECT PLANNING ACTIVITIES KPA Execution (activities) Managed & Controlled Plan A formally agreed upon project plan, under change control, such that the version utilized at any point in time, past or present, is known PROJECT PLANNING Goals: Estimate projects in writing for planning & tracking purposes Plan & document project activities & commitments Ensure commitments are agreed upon between all impacted groups CONTINUED FROM PREVIOUS PAGE Involve in preparing, submitting, clarifying, negotiating commitments & changes that impact corresponding groups Include Engineering groups (including software engineers) in the project proposal team Resolve clarity, feasibility, consistency & testability of requirements & allocated responsibilities Develop software project plans in parallel with, and as an integral part of, the overall project plan Include all impacted groups(including software engineering groups) in project planning over the project’s full life Each group, including Software Engineering, reviews & agrees on the overall project plan thru the project’s full life Plan & document project activities & commitments Establish a software development life cycle divided into predefined, manageably sized phases. Develop systems project plans (& overall project plan) consistent with a documented procedure Consistent with requirements, solution(s) responsibilities, statement of work & standards (external & internal to the project) Negotiate plans & inter-group commitments with corresponding groups, document agreements & budget for inter-group support All impacted groups (including software & Project Managers) review the project plan Manage & control the plan (software & overall) Decide the Chargeback and costing model for services Negotiate SLAs with service providers, if required Document the overall & software project plan Evaluate existing services and consider service reuse while cost estimation State scope & purpose, specific objectives Describe software life cycle, reasons for selecting a specific type/methodology Identify items (including software work products) needed to manage & control the (software) project Specify software & other development & maintenance standards, procedures, techniques & methods Identify software & other engineering work products Include (software)Project effort & cost estimate Include software (& other) work products size estimates (size anticipated changes as well) Estimate use of critical computer resources Ensure commitments are agreed upon between all impacted groups Describe project schedules, milestones & planned reviews Project (software) risk assessments Include project (software) engineering facilities & tools plan Upper management, following a documented procedure, reviews all commitments made to external parties (including software commitments). CONTINUED ON NEXT PAGE

PROJECT PLANNING ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability PROJECT PLANNING ACTIVITIES KPA Execution (activities) PROJECT PLANNING Goals: Estimate projects in writing for planning & tracking purposes Plan & document project activities & commitments Ensure commitments are agreed upon between all impacted groups CONTINUED FROM PREVIOUS PAGE Use documented estimation procedures to: Document, review & agree on estimates with impacted managers Size software work product (& change) Size all major work products & activities State estimation/sizing objectives Use available historical data Document assumptions Estimate projects in writing for planning & tracking purposes Estimate (software) project cost & effort Derive project cost & effort estimates from work product size (& anticipated change) estimates (distributed over project’s life) Use available productivity & cost data, documenting rationale, assumptions & sources Size critical computer resources Base effort & staffing estimates on experience Identify critical resources Derive estimates from software work product size, processing load & communications traffic estimates Derive estimates from software effort, cost, change & work product size estimates Actual schedules of similar past projects when available Estimate (software) project schedules Plan & document project activities & commitments Consistent with imposed timing of milestones, critical dependencies & other constraints Are timelines (Activity length & gaps between milestones) appropriate for accurate tracking? Document assumptions Assess & record risks (technical, cost, schedule, resource & other) Analyze & prioritize risks based on potential impact on the project’s business objectives Identify contingency plans& allowances Plan software & Systems engineering facilities & tools Estimate facilities & tools capacity from estimated project & work product size Negotiate commitments & responsibilities for procuring/developing facilities & tools Document, review & agree on estimates & commitments with impacted managers Ensure commitments are agreed upon between all impacted groups Assemble the plan, record, manage & control it in a baseline Include estimates, assumptions rationale & derivation Managed & Controlled Plan A formally agreed upon project plan, under change control, such that the version utilized at any point in time, past or present, is known

INSTITUTIONALIZING PROJECT TRACKING & OVERSIGHT
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTIONALIZING PROJECT TRACKING & OVERSIGHT PROJECT TRACKING & OVERSIGHT Goals: Track actuals against plans Take & manage corrective actions on deviations to closure Agree on (commitment) changes over the project’s life across all impacted groups Baseline A formally reviewed and agreed upon work product or specification that can only be changed through formal change control procedures, and is the basis for further development Designate Project (& subproject) Manager(s) Commitment Publish written project management policy Track project against a documented baseline plan that is appropriately maintained Ability Project/subproject Managers are aware of the status & issues of their portions of the project on time Track actuals against plan Base the project on an approved & documented project plan When deviations from the plan occur, corrective actions are taken by adjusting either performance or the plan Negotiate and consent to changes in commitments between all impacted managers(software as well as other groups) Review all changes to external commitments with upper management Assumption Organizations striving for repeatable results are already good at engineering, but need Management & technical infrastructure to stabilize their engineering process against perturbing factors Assign ownership of work products & responsibility Individual responsibility for providing work products & services envisioned in the project plan Provide adequate resources & funds Individual responsibility for work products & activity cost & schedules Budgetary responsibility for activity cost Take & manage corrective actions on deviations to closure Assign managers & task leaders specific tracking responsibility Adequacy & access to project tracking tools Train (software) managers in managing both project personnel & technology (Grow managers, rather than appoint good, but unprepared technical staff to management) Orient first line managers to the project’s technology (Grow managers, rather than appoint good, but unprepared technical staff to management) Measure & Analyze Tracking oversight & change management activities performance: impact on schedule, cost, effort & resource utilization Performance: Technical, cost, staffing, schedule, tracking & oversight, Periodic Upper Management project review Address unresolved issues & conflicts Address risks Monitor Implementation Periodic & event/exception triggered Project Managers’ review Assign, review& track action items to closure Agree on (commitment) changes over the project’s life across all impacted groups Prepare & distribute Review Summary to all impacted parties Involve all impacted groups Review project status (technical, cost, resource & schedule performance) against plan Report & review current & projected utilization of critical computer resources against original plan Address inter-group dependencies Address unresolved issues & conflicts Review & address risks Assign, review& track action items to closure Prepare & distribute Review Summary to all impacted parties Quality Assurance review/audit & report of Project tracking & oversight activities & work products’ status KPA Execution (activities) Commitment review & revision activities Project plan revisions - activity Revised plan content Cost, schedule risk, functionality, performance & constraint (technical & design) tracking activities CONTINUED ON NEXT PAGE Plan review & commitment activities

PROJECT TRACKING & OVERSIGHT ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability PROJECT TRACKING & OVERSIGHT ACTIVITIES Assumption Organizations striving for repeatable results are already good at engineering, but need Management & technical infrastructure to stabilize their engineering process against perturbing factors KPA Execution (activities) PROJECT TRACKING & OVERSIGHT Goals: Track actuals against plans Take & manage corrective actions on deviations to closure Agree on (commitment) changes over the project’s life across all impacted groups Update the plan to reflect accomplishments, particularly when milestones are completed Track project work & commitments against a documented & approved project plan Ensure easy access to the same updated plan by all impacted groups, particularly upper management, project (& subproject) managers & (software) engineering groups Revise the plan to reflect significant changes, particularly in requirements, design constraints, resources, cost or schedule Revise software project plans (& overall project plan) consistent with a documented procedure Reflect all new & changed commitments in the revised plan All impacted groups (including software & Project Managers) review & consent to the revised project plan Manage & control the plan (software & overall) in a baseline Take & manage corrective actions on deviations to closure 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 commitments & actuals against plan - current & original baselines, monitor deviations, refine & adjust plan & commitments regularly Track & take necessary corrective actions: Review & agree on revised estimates, commitments, plans & changes with all impacted managers. Document agreements & risks Size of major work products & activities (or changes) Software work product Size (& change) Size of fully tested & delivered code Documents actually delivered (Software & system) project cost & effort Effort, cost, time expended vs. work completed to identify potential overruns & under-runs Cost - actual vs. plan Agree on (commitment) changes over the project’s life across all impacted groups Effort & Staffing - actual vs. plan Critical (computer) resources use Critical resource use for each major software component/deliverable in plan Changes (Software & system project schedules Activity & Milestone completion; Meeting other commitments in plan Evaluate impact of late/early completion of activities, milestones & other commitments on future activities & milestones (Software & system) Engineering activities - Design, code, test Technical team members report technical work product & activity status to first line managers regularly Compare contents of successive software builds/releases against plan Report & Document (software) work product defects & problems Track problem reports to closure Adjust prioritized risks & contingencies in step with new information Risks (technical, cost, schedule, resource & other) Regular project Manager’s review of high risk areas Record actuals & re-planning information Estimates, their assumptions, rationale & other information to reconstruct estimates Use the plan baseline to manage & control revisions Periodic internal (software) engineering group review for tracking technical progress, plans, performance & issues against software plan Archive the original plan, its revisions & actuals for use by ongoing & future projects Track actuals against plan Task leaders & first line managers Appropriate (Software) project & sub project managers Review at meaningful points in project schedule/lifecycle Review results & accomplishments formally at selected milestones determined by a documented procedure Involve customers, end users & all impacted groups in organization Review materials approved by the (software & business system) managers responsible for delivering corresponding work products Address commitments, plans & (software & business system) activity status Identify & record significant issues, action items & decisions Address (software & business system) project risks Refine/revise plan if necessary

INSTITUTIONALIZING QUALITY ASSURANCE
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTIONALIZING QUALITY ASSURANCE QUALITY ASSURANCE Goals: Plan Quality Assurance activities Objectively verify that work products & activities comply with standards Communicate QA results & activities to all impacted groups Upper management resolves noncompliance when it cannot be resolved at the project level QA must cover all (systems) projects Publish Organization’s QA policy Commitment Periodic upper management project QA reviews - activities & results QA organization & reporting channel are independent of project & other software & business systems organizations Ability Create a group for the project’s QA coordination & implementation Provide adequate resources & funds for Quality Assurance May be large or small group or even an individual with part time commitment focused on the project’s QA activities Train/ acquire team members Assign a manager specific project QA activities responsibility Ensure information & reports on noncompliance are escalated to the senior QA manager as necessary Plan Quality Assurance activities Assign a senior, experienced QA manager overall authority to take appropriate QA oversight actions, especially noncompliant project items Adequacy of, & access to, QA support tools (such as auditing tools, work stations, databases, spread sheets, repositories etc.) Understand software & systems engineering skills/practices & QA involvement in software activities Understand role-responsibilities of software/systems engineering & related groups, their interfaces & protocols Objectively verify that work products & activities comply with standards Understand project/organization’s standards, methods & procedures, Understand project’s application/business domain Know QA objectives & procedures; can effectively use QA methods & tools; Skilled in interpersonal communication & fostering collaboration Orient (software & business systems) quality assurance team members in (software) QA group business value & charter, values, role-responsibilities & authority Communicate QA results & activities to all impacted groups Measure/derive QA activities performance: status, schedule & cost against baseline plan Measure & Analyze Track QA milestone & work completion, effort & resource utilization, volumes of work product & activity audits Periodic Upper Management QA activity review Periodic & event/exception triggered Project Managers’ QA activity review Monitor Implementation Performance: Technical, cost, staffing, schedule, tracking & oversight, Address unresolved QA issues & conflicts 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 Address QA risks Assign review & track QA action items to closure Prepare & distribute review summary to all impacted parties Involve all impacted groups Review QAtatus (technical, cost, resource & schedule performance) against plan Upper management resolves non-compliance when it cannot be resolved at the project level Report & review current & projected utilization of critical resources against original plan Address inter-group QA dependencies Address unresolved QA issues & conflicts Review & address QA risks Assign, review& track QA action items to closure Prepare & distribute QA Review summary to all impacted parties Periodic independent Quality Assurance expert review/audit & report of QA group activities & work products KPA Execution (activities) CONTINUED ON NEXT PAGE

QUALITY ASSURANCE ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability QUALITY ASSURANCE ACTIVITIES Managed & Controlled Plan A formally agreed upon project QA plan, under change control, such that the version utilized at any point in time, past or present, is known KPA Execution (activities) QUALITY ASSURANCE Goals: Plan Quality Assurance activities Objectively verify that work products & activities comply with standards Communicate QA results & activities to all impacted groups Upper management resolves noncompliance when it cannot be resolved at the project level CONTINUED FROM PREVIOUS PAGE 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 Manage & control the project’s QA plan QA group’s authority & responsibility QA resource requirement (staff, tools, facilities) QA activities’ schedule & funding (Software & business systems) QA group’s participation in the developing the overall (software & business system) project plan Activities, tools & work products(software & other - e.g. documentation) to be evaluated by QA Plan Quality Assurance activities QA audits & reviews Follow the QA plan Project’s QA standards & procedures Procedures for recording & tracking noncompliance issues to closure Documents to be produced by QA group QA activity & results feedback method & frequencies to each group Include (software) QA group in developing & reviewing the (software) project plan, its standards & procedures Objectively verify that work products & activities comply with standards Consult & review plans, procedures & standards for complying with organizational policy, external & project standards, plan contents etc. QA certifies that the (software & business system) project plan, standards & procedures have been deployed & can be used for QA reviews/audit Verify compliance against plan, standards & procedures (Systems) QA verifies (Systems) engineering work product compliance Verify compliance (Systems) QA verifies (Systems) engineering activity compliance Record deviations & track to closure Verify corrections Upper management resolves non-compliance when it cannot be resolved at the project level Evaluate deliverables before delivery to customers Resolve deviation as close as possible to its origin (task leader, subproject or project manager) when possible Conform to a written procedure in recording & processing (software) activities & work product deviations from the plan or its standards & procedures Record & escalate unresolved deviations to designated senior QA manager Periodically review escalated items until they are resolved Manage and control the non-compliance record in a baseline Communicat QA results & activities to all impacted groups Managed & Controlled Non-compliance Record A formally agreed upon non-compliant item record, under change control, such that the version utilized at any point in time, past or present, is known Report QA findings back to software engineering & other participating groups periodically Periodically review QA activities & findings with customer’s QA personnel 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 Periodically review QA activities & findings with QA personnel across the extended enterprise

INSTITUTIONALIZING CONFIGURATION MANAGEMENT
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTIONALIZING CONFIGURATION MANAGEMENT The project’s operating environment &tools (including CM tools) must comply with standards in order to ensure consistently repeatable results CONFIGURATION MANAGEMENT Goals: Plan Configuration Management activities Identify, control & make selected work products available on time Control changes to work products Communicate systems, software and component baseline statuses to all impacted groups 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 Commitment Publish Organization’s CM policy Control changes to (software) work products selected & made available to the project team(s) Assign the project’s Configuration Management responsibility explicitly Ability Implement Configuration Management through the project’s full life cycle Give projects a repository(s) for storing configuration components Implement Configuration Management for: (1) All (software/systems) products delivered externally (2) Designated internal (software/systems) work products (3) Designated tools used by the project Create a Software Configuration Control Board (SCCB) to oversee the project’s (systems) baseline Plan Config. Managemt activities Authorize systems baseline establishment & kinds of items it will contain Represent the Project Manager & all groups impacted by (systems) baseline changes Create a Software Configuration Management Group (SCM) to manage the project’s (systems) baseline Review & authorize (systems) baseline changes Authorize product assembly (build) from the systems baseline Manage the project’s component & software library Develop, maintain & distribute SCM plans, standards & procedures Identify the contents of the systems baseline Manage systems baseline access Update the baseline with specific work products Build systems products/deliverables from the baseline Record configuration management actions Produce & distribute SCM reports Select & control (software) work products & make them available to the project team Provide adequate resources & funds for SCM Assign a manager specific project SCM responsibility Adequacy of, & access to, SCM tools (such as repositories, work stations, databases & other configuration management tools.) Train SCM group Know SCM objectives & procedures; can effectively use methods & tools Train software & systems engineering, QA, Documentation & other project groups in SCM activities they must perform Inform all impacted groups of (software) baseline contents & status Understand SCM objectives, practice & involvement in software activities Understand their group’s & individual SCM responsibilities Understand role-responsibilities of SCM & related groups, their interfaces & protocols Understand project/organization’s SCM standards, methods & procedures, Institutionalization Can effectively use SCM methods & tools needed to fill their individual SCM responsibilities CONTINUED ON NEXT PAGE

INSTITUTIONALIZING CONFIGURATION MANAGEMENT
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTIONALIZING CONFIGURATION MANAGEMENT CONFIGURATION MANAGEMENT Goals: Plan Configuration Management activities Identify, control & make selected work products available on time Control changes to work products Communicate systems, software and component baseline statuses to all impacted groups CONTINUED FROM PREVIOUS PAGE Measure & Analyze: Measure SCM performance: resources, milestones, activity status, schedule, cost, change request volumes etc. against baseline plan Monitor Implementation Periodic Upper Management SCM review Inform all impacted groups of (software) baseline contents & status Timely & adequate upper management insight into SCM process Technical, cost, staffing, schedule, tracking performance Address unresolved SCM issues Address SCM risks Assign review & track SCM action items to closure Prepare & distribute review summary to all impacted parties Periodic & event/exception triggered Project Managers’ SCM activity review Review SCM status (technical, cost, resource & schedule performance) against plan Report & review current & projected utilization of critical resources against original plan Address inter-group SCM dependencies Periodic SCM group’s baseline audit to confirm compliance with documentation Address unresolved SCM issues Review & address SCM risks Assign, review& track SCM action items to closure Involve all impacted groups Control changes to (software) work products selected & made available to the project team(s) Prepare & distribute SCM Review summary to all impacted parties QA group’s SCM work product & activity audit & feedback report to confirm compliance Compliance with SCM, SCCB, Software/systems Engineering & other groups’ standards & procedures Periodic systems baseline audit KPA Execution (activities) CONTINUED ON NEXT PAGE

CONFIGURATION MANAGEMENT ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability CONFIGURATION MANAGEMENT ACTIVITIES KPA Execution (activities) CONFIGURATION MANAGEMENT Goals: Plan Configuration Management activities Identify, control & make selected work products available on time Control changes to work products Communicate systems, software and component baseline statuses to all impacted groups CONTINUED FROM PREVIOUS PAGE 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 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 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) Plan Config. Managemt activities Store & retrieve configuration items Share (or move) configuration components between project groups & the library’s control (security) levels subject to security rules Facilitates enforcement or application of standards to configuration components Control changes to work products selected & made available to the project team(s) Configuration (component) archival, recovery & version management Validate products configured from repository & facilitate creating the right deliverables from the baseline Storage, retrieval & maintenance of SCM records Supports SCM reports Maintenance of repository structure & contents (including backup, recovery & library administration) Selection is based on written criteria Assign an unique identifier to each item Identify items that will be placed under configuration management (in the repository) Associate each item with specific baseline(s) Select & control work products & make them available to the project team 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 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 Conduct reviews/regression tests to eliminate unintended effects of changes on the baseline Baseline only configuration items approved by the SCCB Component check in/out procedure maintains baseline accuracy & integrity Give all impacted groups access to standard reports describing SCM activity & the baseline’s contents SCCB authorization to build products/deliverables from the baseline library Both internal & external products/deliverables released from the baseline are built purely from components stored in that baseline Inform all impacted groups of (systems) baseline contents & status Store enough detail of configuration management actions to not only maintain every configuration item’s current state & contents, but also to recover its previous versions Maintain each item’s current state & history (of changes & actions) Prepare adequately for the audit Assess the baseline’s integrity Review the baseline library (automated or manual system) structure & facilities Verify accuracy & completeness of (baseline) library contents Managed & Controlled Configuration Items A formally agreed upon set of components (tools, deliverables & interim work products), under change control, such that the version utilized to build a project deliverable at any point in time, past or present, is known Systems Baseline A formally reviewed and agreed upon set of software & business systems components or specifications that can only be changed through formal change control procedures, and is the basis for further development Comply with a written procedure to audit systems baselines Verify compliance with SCM standards & procedures Report audit results to the project’s software & business system managers Track resulting action items to closure

INSTITUTIONALIZING CONTRACTOR MANAGEMENT
CAPABILITY LEVEL 2 Consistent Process Repeatability INSTITUTIONALIZING CONTRACTOR MANAGEMENT Contractor A vendor responsible for providing some (or all) project deliverables. The vendor must be responsible for planning, tracking & oversight of contracted deliverables in order to be termed a contractor. The organization outsourcing the work (prime) is responsible for ensuring deliverables accepted satisfy requisite criteria. CONTRACT MANAGEMENT Goals: Select qualified contractors & subcontractors Agree on mutual commitments with contractors Maintain ongoing communication with contractors Track contractors’ performance against commitments Commitment Publish written contract management policy Designate Project Contract Manager(s) Manage contract based on contractual agreements Use written standards & procedures for selecting contractors Contractual changes cannot be made without the involvement & consent of both contracting parties Internal organizations may qualify under this definition of contractor. Processes herein can support interfaces between internal groups. Select qualified contractor Ability Is either an experienced (software/system) engineer or has experienced (software/system) engineer subordinates Responsible for contract Terms & Conditions and technical scope of contract Responsible for selecting contractor, managing contract & arranging post contract support Provide adequate resources & funds Maintain ongoing communicatn with contractor Assign managers & other project team members specific contract management responsibility Adequacy & access to contract management tools (estimation, tracking, scheduling, spreadsheet & other) Train (software) managers & other involved project team members in managing contracts, selecting & managing contractors (Grow, rather than appoint good, but unprepared technical staff to manage contractors - planning contracts, evaluating bidders, their estimates & plans, selecting & managing the contractor etc.) Orient (software) managers & other involved project team members to the project’s technology (business domain, tools, methodology, standards, procedures, technology platforms etc - Necessary to grow, rather than appoint staff ) Measure & Analyze Track status of contract management activities Track contract management activities against baseline plan: cost & actual delivery dates of contracted items to & from the contractor Monitor Implementation Periodic Upper Management contract activity review Agree on mutual commitments with contractor Performance: Technical, cost, staffing, schedule, tracking & oversight, Periodic & event/ exception triggered Project Managers’ review Address unresolved issues & conflicts Temporary Employees are not considered contractors, rather they are considered the prime’s staff Address risks Assign, review& track action items to closure Prepare & distribute Review Summary to all impacted parties Involve contractor & all impacted groups Review contract status (technical, cost, resource & schedule performance) against plan Report & review current & projected utilization of critical computer resources against original plan Address inter-group dependencies Track contractor performance against commitments Address unresolved issues & conflicts Review & address risks Assign, review& track action items to closure Prepare & distribute Review Summary to all impacted parties Quality Assurance review/audit & report of contract management activities & work products’ status Contractor selection activities Contract management activities KPA Execution (activities) Coordination of configuration management activities with contractor(s) Conducting planned reviews with contractor Key contract milestone/phase completion reviews CONTINUED ON NEXT PAGE Contractors’ deliverables acceptance process

CONTRACTOR MANAGEMENT ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability CONTRACTOR MANAGEMENT ACTIVITIES CONTRACT MANAGEMENT Goals: Select qualified contractors & subcontractors Agree on mutual commitments with contractors Maintain ongoing communication with contractors Track contractors’ performance against commitments KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Select outsourced activities/ deliverables based on technical & nontechnical factors, contractor s’ capabilities & the right requirements & system partitions Create contract’s statement of work, standards & procedures from the overall requirements, project plan, statement of work, standards & procedures Agree on the contractor’s statement of work after baselining, reviewing & revising it with all impacted groups Create the contractor selection plan concurrently with the his statement of work Comply with a written procedure to determine work that will be outsourced Select qualified contractor Comply with a written procedure to select contractor(s) able to perform Contractor proposal Location(s) Contractor’s performance record & references for similar work Contractor’s engineering & management capabilities Available staff (able to perform) (Contractor) team’s prior experience & expertise with similar work Resources (facilities, hardware, software, training etc.) available Statement of Work Scope, goals, constraints & assumptions (technical , schedule, budgetary, resource etc), sponsors & end users of system, standards, responsibilities, impact & dependencies (internal & external organizations) 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 T&C Statement of Work Overall project deliverables & requirements Mutual obligations & dependencies with contractor(s) Contracted deliverables Conditions for revising & submitting deliverables Contractor performance evaluation procedures & criteria Manage contracted work against contract Review contractor’s plan & approve contract Included in overall project (software) plan, or linked to corresponding items therein Track contract activities & commitments against the contractor’s approved (written) project plan; communicate status Track contractor performance against commitments All impacted groups (of all parties bound by the contract) review & consent to revisions Revise contract (statement of work, T&C & commitments) consistent with a documented procedure CONTINUED ON NEXT PAGE

CONTRACTOR MANAGEMENT ACTIVITIES
CAPABILITY LEVEL 2 Consistent Process Repeatability CONTRACTOR MANAGEMENT ACTIVITIES Management review Cost, schedule, financial & other management Risks & dependencies Tech review Meeting tech. Commitments & correct implementation of tech. requirements CONTRACT MANAGEMENT Goals: Select qualified contractors & subcontractors Agree on mutual commitments with contractors Maintain ongoing communication with contractors Track contractors’ performance against commitments KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Provide contractor insight to customers’ (&end-users’) needs Review contractor’s performance against his approved plan - technical, cost, staffing & schedule The prime organization’s management, following a documented procedure, periodically coordinates, & reviews status, with contractor’s management Review critical computer (&other) resources against his approved plan - track current estimates against original plan Address mutual (critical) dependencies & commitments with contractor Address noncompliance with contract Address project risks that involve contractor’s work Address issues & conflicts that contractor cannot resolve internally Address critical dependencies & commitments within contractor’s organization, especially those that impact (software) engineering Track contractor performance against commitments Assign & track action items to closure Periodically engage contractor in technical review & interchange Provide contractor insight to customers’ (&end-users’) needs Monitor contractor’s technical activities Validate contractor’s interpretation & implementation of tech. requmts Validate contractor is meeting commitments Verify timely resolution of technical issues Plan reviews in writing in the contractor’s statement of work Use documented procedures to: Address contractor’s activity status, plans & commitments Formally review(Software/systems) Engineering accomplishments at selected milestones Record issues, decisions & action items Address (software & systems) risks Revise contractor’s (software/systems) plan as needed Periodic ability review- Adequacy of contractor’s QA standards/ resources/plans to properly monitor project performance Outsourcing organization’s QA monitors contractor’s QA ability & implementation for the project Implementation spot check - Spot check contractor’s project activities & deliverables, & audit contractor’s QA records as needed Implementation periodic check - (Periodically audit contractor’s internal QA activity records to verify compliance with QA standards, procedures &plans) Outsourcing organization’s Configuration Management (CM) group monitors contractor’s CM activities for the project Periodic ability review- Adequacy of contractor’s CM standards/resources/plans Coordinate CM activities with contractor for ready integration into specified target (or outsourcer’s project) environment Periodic CM implementation check - audit contractor’s baseline library for compliance with CM standards & procedures & management Maintain ongoing communic with contractor Test contracted deliverables before accepting them Mutually review & approve acceptance procedures & criteria before testing Document results Action plan for failed deliverables Periodically evaluate contractor’s performance (across contracts) & review with contractor

CAPABILITY LEVEL 3 Standardized Best Practices in use Process Capability GOALS OF KEY PROCESS AREAS (KPAs) Specific goals that will contribute the most to standardizing and deploying best practices 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 Focus the organization on standardizing processes These goals utilize Level 2 TRAINING practices from the Workforce Maturity Model. Included here for IT Service evaluation, specifically. ORGANIZATIONAL PROCESS DEFINITION Goals: 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. TRAINING PROGRAM Goals: Plan training Offer technical & management training courses Train individuals Provide relevant training STANDARD PROCESS DEPLOYMENT Goals: Tailor the standard software/systems process for individual projects Follow the tailored process for project planning & management These goals utilize Level 2 COMMUNICATION & COORDINATION practices from the Workforce Maturity Model. Included here for IT Service evaluation, specifically. Deploy standard processes BUSINESS SYSTEMS & SOFTWARE ENGINEERING Goals: Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent Engineer components, systems & software accurately INTERGROUP COORDINATION Goals: All impacted groups mutually agree on customer requirements All impacted group agree on mutual commitments between themselves Engineering groups identify, track and resolve intergroup issues Coordinate between software/ systems engineering & other impacted groups PEER REVIEW Goals: Conduct peer reviews of work products in a planned manner Identify and remove defects in work products Institute peer review of work products & rectify defects

Standardized Best Practices in use
CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING ORGANIZATIONAL PROCESS FOCUS The standard process must cover activities, work products, procedures, techniques and functions (like QA or configuration management), as well as the relationships between these components of process knowledge. Processes tailored from standard processes must refer to these to describe specific ways in which they have been customized. 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 Commit to following a published organization wide policy for coordinating systems development Commitment Require Creation & empowerment of the SEPG Require periodic process assessments of project level processes for building systems & software - strengths & weaknesses Require that project level processes must be tailored from the standard process Require communication of improvements and relevant information on processes, tools and methods of each project to every other Plan process development & improvement across the organization Upper management sponsorship of the initiative to standardize the systems development process Demonstrate commitment to the systems development process to staff & management Long term funding, staffing & resource plan Management and implementation strategy for process improvement Upper management oversight of the initiative to standardize the systems development process Ensure alignment of standard process(es) with business goals & strategies Advise priorities for systems process development & improvement Ability Participate in planning for systems process development/improvement; coordinate requirements and issues with managers & senior staff, secure support and participation from staff and managers Create SEPG Full time, dedicated professional systems staff, optional part time support staff Staff represents business systems and software disciplines (requirements analysts, systems/software designers & builders, testers, configuration Management and QA staff,etc. Coordinate systems development & improvement organization-wide Provide adequate resources & funds for activities mandated by the systems process Train SEPG Assign experienced specialists (Component reuse, CASE, CAPE and metrics specialists, trainers & course developers etc.) Provide the right tools and automation (statistical analysis tools, publishing tools, database management systems, process modeling tools etc.) Conform to performance requirements of Training KPA in software/business systems engineering, process control techniques, change management, including organizational change and technology transition, planning, managing and monitoring the business systems/software methodology, etc. Orient (brief) SEPG and other software and systems groups on their roles, responsibilities and activities to implement the software/systems process Identify software & systems process strengths & Weaknesses against a standards Measure & Analyze Track status of process development and improvement activities Track milestone & work completion, effort & funds expended, resource utilization, etc against plan; track results of process assessments against previous assessments & recommendations Monitor Implementation Periodic Upper Management process development and improvement activity review Report and analyze status of software/systems methodology development activities against plan Resolve conflicts and issues left unresolved at lower levels Assign, review and track action items to closure Prepare & distribute review summary to all impacted parties KPA execution (activities) CONTINUED ON NEXT PAGE

CAPABILITY LEVEL 3 Standardized Best Practices in use ORGANIZATIONAL PROCESS FOCUS ACTIVITIES 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 KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Assess software/systems process periodically and develop action plans to address findings Identify findings that will be addressed Guidelines for changes that will address the findings Groups and persons responsible for implementing changes Plan process development & improvement across the organization Plan software/systems process development/improvement activities (and keep plan updated) Based on action plans from periodic assessments and other initiatives Specify and schedule activities Assign responsibilities for activities Identify resources including staff and tools Review releases and revisions Agreement of software/systems engineering managers & upper management Coordinate software/process development & improvement activities organization wide Identify software & systems process strengths & Weaknesses against a standards Standard software & systems process Project software & systems processes 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 Training plans on business systems/software development process and related subjects Training prepared and delivered by SEPG or the Training Group (see the Training KPA) Keep the users of business systems/software methodology and processes updated on projects and activities for developing and improving current processes Coordinate systems development & improvement organization-wide

CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING ORGANIZATIONAL PROCESS DEFINITION ORGANIZATIONAL PROCESS DEFINITION Goals: Develop & maintain standard software & systems process(es) Monitor & communicate use of standard software & systems process(es) Publish policy for developing and maintaining standard processes for business systems and software development Develop & maintain standard software & systems process(es) Commitment Requires definition of requisite standard processes Requires project level customization of standards Process and work product measurement Requires maintenance, use and access to process assets Lessons Learned Requires obtaining, organizing & using project level feedback to improve standard processes Other feedback Ability Provide adequate resources & funds for Systems process development & maintenance SEPG made responsible for systems process development and maintenance Provide the right tools and automation (statistical analysis tools, publishing tools, database management systems, process modeling tools etc.) Train SEPG Conform to performance requirements of Training KPA for software/business systems engineering, process analysis& documentation techniques, etc. Monitor & communicate use of standard software/systems process(es) 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 Measure & Analyze Monitor Implementation Periodic QA review of process assets, activities & work products for developing & improving software and systems processes Follow development, deployment, maintenance & documentation standards Control & use assets appropriately KPA execution (activities) CONTINUED ON NEXT PAGE

CAPABILITY LEVEL 3 Standardized Best Practices in use ORGANIZATIONAL PROCESS DEFINITION ACTIVITIES ORGANIZATIONAL PROCESS DEFINITION Goals: Develop & maintain standard software & systems process(es) Monitor & communicate use of standard software & systems process(es) KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Follow a written procedure to develop and maintain the standard process Conform to internal policies, process and product standards Conform to customer, regulatory & other stakeholders policies, process and product standards if any Integrate appropriate state-of-the-art business systems and software engineering tools and methods into the standard process Specify interfaces, transitions and protocols between business systems and software engineering disciplines How impacted groups will interface (use, feedback, customize, change etc.) with the systems process Develop & maintain standard software & systems process(es) SEPG records, reviews and approve/disapprove proposed changes to the software/systems process in writing Plan for changes to the process in use by projects in progress Peer review software/systems process when developed or significantly changed Standard Process placed under Configuration Management Peers: Process & Software Engineers and other users of the standard process Estimating items Design items Construction items Peer Review items Other requisite items Conform to organizational standards when documenting standard process Standards based items (meta-components) Appropriate scope of each item Relationships and interactions between items address their sequence, interfaces and interdependence Procedures, practices, methods, technology Process & Product Standards Role-responsibility standards Tool & Resource standards Input standards Work Products Monitor & communicate use of standard software/systems process(es) Work Products for peer review Record and maintain, in writing, approved software/systems life cycles Readiness/Completion criteria Product & Process data that should be collected Conform to organizational standards Record, review, take SEPG Approval for proposed changes before inclusion Peer review of software & systems life cycles when developed or significantly changed Manage & Control Life Cycle description(s) Managed & Controlled Specification A formally agreed upon specification, under change control, such that the version utilized at any point in time, past or present, is known. Note that this does not require the full blown configuration management discipline such as planning, baselining, periodic audits, reporting etc. Create & maintain criteria & guidelines for tailoring Standard Process(es) to fit different projects Project Life Cycle Selection & Customization Customizing the standard process for the project Standards for documenting for the customized process Establish scope Record, review, SEPG Approval for proposed changes before inclusion Manage and control guidelines & criteria Collect and disseminate process information with the repository Review the information in the repository to ensure its integrity and quality Manage and control the information in the repository Control access rights to ensure information quality and integrity Create and Maintain the Process Assets repository Review and include the right items Catalog documents to facilitate access Create and maintain a library of documents about the tailored process for each project: plans, procedures, standards, measures, training materials etc Review revisions and update library Make library available to projects and other users Periodically review use of each document and use the information to maintain the library Manage and control the contents of the library

CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING TRAINING AND ACTIVITIES TRAINING PROGRAM Goals: Plan training Offer technical & management training courses Train individuals Commitment Publish organization wide training policy Requires identification of role specific skills/knowledge Requires identification & approval of training vehicles & methods Requires development of organizational skills by training individuals to fill project needs Requires right mix of appropriate in-house & external training; articulate the policy for this Create Training Group Ability Provide adequate resources & funds for training Assign a Manager Provide the right tools and automation (such as work stations, training design & presentation equipment & software, database tools etc.) Provide the right training facilities Plan training Staff the training group with the right mix of skills/knowledge Orient (brief) Managers of software and systems groups on the training program Measure & Analyze Track status of training activities & the overall training program Measure the training program quality Monitor Implementation Periodic Upper Management Training Program review KPA Execution (activities) Periodic independent training program evaluation Audit training activities and work products, and report results Verify compliance with the standard process for developing and revising training plans Verify compliance with the standard process for developing and revising training courses Maintain training records in compliance with requisite standards Verify that identified training needs of individuals are being met Verify compliance with the training plan Every project has a training plan it maintains, which addresses its specific training needs Skill requirements, and their timing Skills that will be acquired through training and skills that will be acquired in other ways (specify how) Timed training requirements,and who will train Method of training & whether it will be done by the project team, the training group or external trainers Offer technical & management training courses Plan, and revise organization wide training plan in compliance with a written, standard procedure Consider the project level training needs from project training plans Specify and schedule specific training based on timed organizational skill requirements Revise training plan in step with changing requirements Review training plan and significant revisions with impacted individuals Manage & Control training plan Ensure impacted groups and individuals can access the training plan conveniently and easily Conduct training in compliance with organization wide training plan Time specific training with organizational requirement Comply with planned source of training: external Vs. training group Comply with training resource plan: Funding, staff, tools & facilities to conduct,prepare and procure training Comply with training material standards developed by the training group Consider the training groups schedule for developing and revising training courses Comply with the training schedule based on projected timings and estimated numbers of trainees Comply with procedures Create and use a procedure to waive training if individual(s) have requisite skills/knowledge for their envisioned role(s) Train individuals Prepare organization level training courses in compliance with organization wide training standards Describe each training course Review training course materials Manage & Control course materials Maintain training records Keep records of people who complete training courses & approved training activities Keep records of individuals who successfully finish the training required of them Provide convenient access to individuals’ training records for use in staff and management assignments

INSTITUTIONALIZING STANDARD PROCESS DEPLOYMENT AND ACTIVITIES
CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING STANDARD PROCESS DEPLOYMENT AND ACTIVITIES STANDARD PROCESS DEPLOYMENT Goals: Tailor the standard software/systems process for individual projects Follow the tailored process for project planning & management Publish organization wide policy for using the standard process and process assets for planning & managing software & systems engineering projects Commitment Require each project level process be tailored from the standard process Require that deviations from the standard process be documented & approved Require that every project conforms to the process that it has tailored for itself Require that every project store the requisite metrics in the organizational process repository Tailor the standard software/systems process for individual projects Ability Provide adequate resources & funds for managing the project in compliance with the standard process Train project staff responsible for tailoring the standard process and its assets on their use and customization (as described in the training KPA) Train Managers of software and systems groups on management of the technology, people and requisite administration Measure & Analyze Track Effectiveness of integrated business process and software management Monitor Implementation Periodic Upper Management project activities review Project Manager reviews activities periodically or when contingencies or other events occur Conduct QA reviews and audits of both project activities & work products, and report the results Verify compliance with the process for creating & revising the project level process Verify compliance with the process for project planning & planning for management of consonant risks Verify compliance with the project level project management process Verify compliance with the process for supplying the right information to the organization-wide process repository Verify compliance with the process for using the organization wide process repository to tailor the project level process KPA Execution (activities) Choose approved project life cycle, Modify chosen life cycle, if need be in compliance with tailoring criteria & guidelines Document modifications in compliance with organization wide standards Follow the tailored process for project planning & management Tailor the standard process to create the project level software/systems process Establish project life cycle and document it Describe the project level software & systems process SEPG must review and approve the tailored process; Upper Management must approve SEPG waivers & approved deviations Contractual waivers and deviations from contractual requirements must be documented and approved by both upper management & the project’s customers when appropriate Manage & control the project level software/systems process Lessons learned from organization wide project monitoring Proposed project level changes Process and product measurements Comply with a published procedure when revising the project level process Systematically document & review changes Review and approve proposed changes to the project level process Comply with a published procedure to develop and revise the project plan KPA execution (activities) CONTINUED ON NEXT PAGE

STANDARD PROCESS DEPLOYMENT ACTIVITIES
CAPABILITY LEVEL 3 Standardized Best Practices in use STANDARD PROCESS DEPLOYMENT ACTIVITIES Risk Management Experience shows that non-communication of risk is the biggest risk and failure of risk management. Risks may involve schedules, costs, functionality, timely throughput or response, process availability, information quality, adequacy of critical computing resources etc. Early identification of risky objectives, events and contingencies, in tandem with close monitoring or early implementation and course correction via prototypes or staged implementation strategies may help manage or pre-empt risk STANDARD PROCESS DEPLOYMENT Goals: Tailor the standard software/systems process for individual projects Follow the tailored process for project planning & management KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Tailor the standard software/systems process for individual projects Comply with the project level process in managing the project Establish and document readiness and completion criteria; use them to trigger or end key tasks Document project re-planning criteria/triggers Store lessons learned (management & technical) in the organization’s process repository Systematically review lessons learned to plan, estimate, track and replan the project Staffing plan must address project’s needs for special skills and business domain knowledge Identify and document the project’s specific training needs stakeholders Consider 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 process Collect, analyze and report requisite measurements; include these activities in the project plan Use the process repository for planning & estimating Use data from similar projects if available Compare parameters for sizing, effort, cost, schedule, use of critical computer (& other) resources Store the project’s planning & re-planning data, and actual performance in the process repository Compare & record business application & design approaches Consider & record reasons for differences & similarities in project parameters Record the reasons, judgments and risks for the project estimates Manage work Product size and complexity in compliance with a published procedure An independent group must review the estimation procedures process engineer have used, and guide them on use of historical information in the process repository Inflate risky estimates by a contingency factor Reviewers ensure right use of procedures & data Peer & experts review estimates that lack consensus Identify reusable components Identify and closely monitor factors that might affect work product size & complexity Establish a threshold of size and complexity for each managed item, which will trigger action if crossed Document rationale for contingency Assess & record risk of removing or reducing contingency Follow the tailored process for project planning & management Update estimation parameters & models when requirements change significantly Use actual productivity & cost data when available Manage work Project cost & effort in compliance with a published procedure Adapt effort, cost & staffing profiles to fit the project; use historical data if available Adjust the parameters used for estimating cost and productivity to fit the project profile Estimate overall effort and cost from those of individual tasks to facilitate effective cost & effort management Review the actual cost and work completion against the plan to revise estimates of remaining effort & cost Establish a threshold of projected cost & effort for each task (activity or phase), which will trigger action if crossed Manage use of computer resources in compliance with a published procedure Estimates based on analysis, simulations, prototyping or pst experience Collaborative Development Incorporate collaborative principles from Workforce Development Record rationale & data sources Record assessments of resemblance & differences in design & application between the project and historical reference Record the reasons (& risks for credible estimates Obtain/tune critical computer resources to meet the project’s operational and development (& analysis) requirements Meet computer resource requirements of software & business systems components Inflate initial estimates of critical computer resources by a requisite risk factor; document it with reasons Establish a threshold of projected use of critical computer resources, which will trigger action if crossed Comply with a published procedure in managing critical paths and critical task dependencies in the project’s task plan Comply with the project level process in scheduling funds, tasks, milestones, commitments, reviews, critical dependencies & staffing Identify, negotiate and flag critical dependencies in the project & software schedules Flag critical paths in the project & software schedules Regularly track critical paths and dependencies Document a threshold estimate for each critical path, which will trigger action if crossed 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. Comply with the published procedure for assessing, managing and recording project risk 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 plan Comply with the project level process in developing contingency plans over its full life Document alternatives and criteria for choosing each Conduct peer reviews before releasing the the software/system, or its significant revisions/changes Manage and control the risk management plan Communicate risks, results of mitigation & risk management plan to software, business systems and all impacted groups Review and revise priorities and risk management plans at checkpoints/incidents Monitor risks to refine risk assessment & risk management plans Review each project periodically to align it with projected user, customer and business need Identify options, assess impact & feasibility, consider providing reserves, etc.

CONTINUED ON NEXT PAGE KPA Execution (activities)
CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES BUSINESS SYSTEMS & SOFTWARE ENGINEERING Goals: Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent Commitment Publish the policy for performing prescribed activities in software & business systems engineering projects Require each project perform the tasks prescribed by the (project level) tailored process Require that the right tools and methods be used to build the business system & software Require that every plan task and product be traced back to a requirement it supports Ability Provide adequate funds & resources to execute software/business engineering tasks Sufficient availability of adequately skilled persons for every task Sufficient supply and availability of requisite tools for every task Train technical project staff adequately to enable them to measure up to their roles in the project Keep work products mutually consistent Orient technical project staff adequately to enable them to measure up to their roles in the project Orient Managers of software and systems groups, including project managers on the technology used by the project Measure the quality & functionality of the product delivered by the project Measure & Analyze Track status of business process/software engineering activities Periodic Upper Management project activities review Define, integrate & consistently perform software & systems engineering tasks Project Manager reviews activities periodically or when contingencies or other events occur Conduct QA reviews and audits of both project activities & work products, and report the results Review & verify accuracy, consistency, completeness, feasibility & testability of requirements Verify compliance with initiation & completion criteria for every software/systems engineering task Verify product compliance with requisite standards and requirements Verify compliance with requisite testing requirements Verify compliance with published plans and procedures for systems acceptance testing Verify that test acceptance criteria complies with the published test plan Verify satisfactory test completion & record keeping Verify problems & defects are recorded, tracked & addressed Verify that requirements are traced through to design, code/knowledge component & testing Verify compliance of published operating & maintenance instructions against published baselines & requirements before releasing the product for use Integrate engineering tasks in compliance with the project level process Choose the right methods & tools for the project, and document the reasons for each Choose the right model for the project Product development and maintenance tools are also governed by configuration management Focus on service reuse for new service and solution development Monitor Implementation KPA Execution (activities) Integrate the right methods & tools into the project level process 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 requirement Validate the method(s) of ensuring that all mutually agreed upon requirements will be satisfied Ensure peer review of consolidated & published requirements before finalizing it Approve the consolidated requirements by requisite managers (for example, project managers, engineering & testing managers (business process, software, etc.) Review the requirements document with end users (and customers where appropriate) Put the requirements document under configuration management Change requirements for automation whenever a changes in overall requirements impacts it Record requirements for automating the business process Analyze clarity, feasibility, mutual consistency, testability and completeness of requirements; review & resolve issues with originators of problem reqirements Record requirements,alternatives, and their rationale Comply with the project level process when developing, maintaining, recording and verifying requirements. KPA Execution (activities) CONTINUED ON NEXT PAGE

CONTINUED FROM PREVIOUS PAGE
CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES BUSINESS SYSTEMS & SOFTWARE ENGINEERING Goals: Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent KPA Execution (activities) Mutually consistent plans, processes, requirements, software, test plans & procedures, etc. CONTINUED FROM PREVIOUS PAGE 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 Establish and document readiness and completion criteria; use them to trigger or end key tasks Comply with mandated & appropriate standards Use effective design methods to design software & business systems Develop the software & systems architecture early, within the constraints imposed by the chosen project life cycle Review the architecture;resolve issues that may impact detailed design Base detailed design on the architecture Publish the detailed design and the architecture; cover components, hardware, actors (mechanical & human) & interfaces between them Business process & software designers review requirements, ensure issues, if any, are resolved Develop and review design criteria (for example, verifiability, compliance with standards etc.) Peers review the design document before finalizing it Put the design document under configuration management Change the design document whenever changes in requirements impact it Comply with the project level process to code/assemble, maintain, document & verify the software/ business process design that will satisfy requirements Builders of software/the business process (coders/assemblers) review requirements & the design to ensure that all issues that impact their work are resolved Effective methods are used to build (code/assemble) the business system Account 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 finalized Put the code/component assemblies under configuration management Define, integrate & consistently perform software & systems engineering tasks Change the code/component assembly whenever requirement or design changes impact them Develop and review test criteria with the right customers and end users Use effective test methods Test 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 change Peers review test plans, procedures and cases before they are considered complete Manage & control test plans, procedures & cases Change test plans, procedures & cases when the requirements, design, code or components being tested change Establish Testing environment for testing with existing services Right level & depth (for example, unit, integration, acceptance tests) Right test strategy & techniques (for example, black box, statistical etc.) Right scope and coverage 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 Publish integration test plans, based on the project plan Staff responsible for requirements, design and acceptance testing review integration test cases & procedures Test for integration with the right versions of published requirements & designs Approach to testing & verification Responsibilities of each stakeholder Test facilities, equipment, tools & other support requirements Acceptance criteria Plan & execute acceptance tests to demonstrate requirements have been satisfied Review & get approval of published acceptance & systems test plans from the right end users and customers Assign timely resources for testing to allow adequate time to prepare The test group that plans test cases & procedures must be independent of those who make the software or business system Publish and review test cases and procedures with the right customers & end users before testing Test against a baseline - published requirements, systems & software Record & track problems that emerge from testing to closure Record test results and use them to determine if requirements have been satisfied Manage & control test results Trace defects back to root causes - work products & work steps. It will prepare the organization for quantitative analysis of defects at Level 4 Comply with the project level process to develop & maintain documents which will be used to operate & maintain the software/ business system The right stakeholders (customers, designers etc) review early (draft) versions of documents, as early as possible in the project; record & act on their feedback Match & verify final documents against the software/business systems baseline for acceptance testing Peer review documents Manage & 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 documents Use the right documentation tools & methods (word processors, graphics, document reuse tools, repositories etc.) Keep work products mutually consistent 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 Collect & analyze defect data from peer reviews in compliance with the project level process Document work products & make the documents easy to get Trace requirements, designs, components, code & test cases to their source, and also to subsequent projects Manage and control documents that trace the connections above Analyze & change work products, plans, activities & processes in step with growing understanding Keep work products mutually consistent

KPA Execution (activities)
CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING INTERGROUP COORDINATION AND ACTIVITIES INTERGROUP COORDINATION Goals: All impacted groups mutually agree on customer requirements All impacted group agree on mutual commitments between engineering groups Engineering groups identify, track and resolve intergroup issues Commit to a following published organization wide policy that will establish cross functional teams of stake holders with a mandate to produce the final deliverables of each project Project objectives and requirements must be reviewed and agreed upon by all stakeholders in the team Stakeholders coordinate plans and activities Maintain a positive environment, encouraging teamwork, mutual support, interaction & coordination Commitment Provide adequate resources & funds for coordinating the activities of stakeholders Coordinate tool compatibility between stake holders All impacted groups mutually agree on customer requirements Ability Train all managers in team work Orient (brief) the task leaders of each group on the processes, methods & standards of the others Orient team members of the cross functional team on working as a team Measure & Analyze Track status of cross functional coordination Monitor implementation Periodic Upper Management process review Project Manager’s Periodic or event based activity review Periodic Upper Management process activity review KPA Execution (activities) Prioritize & identify critical requirements & characteristics Negotiate critical dependencies & constraints Record agreed upon acceptance criteria for the end product that will be delivered to customers Engineering groups identify, track and resolve intergroup issues Customers & end users (or groups such as marketing that speak for them) participate with engineering groups to articulate clear requirements Track & review design & development activities for hardware, software & components (including Knowledge Artifacts & their subassemblies) Assess & track cross functional risk Coordinate activities Manage issues Clarify requirements & design issues; address & resolve project level conflicts if any Joint solutions & recommendations to address problems Address cross functional issues Stakeholders work together to coordinate activities & resolve technical issues/risks Project schedule Contractual and technical issues Responsibilities of each group Communicate cross functional commitments, coordinate & track work done, in compliance with a published plan The plan is a baseline The plan coordinates all stakeholder activity The plan is easily accessible and available to all stakeholders The plan includes all mutual commitments of all stakeholders & is kept up to date The plan reflects progress and project level changes; is updated especially when milestones are completed, or significant changes occur The plan is reviewed by, and agreed upon by all stakeholders, especially the project manager A group that accepts work products produced by others must review them to ensure that they meet their needs Explicitly define every critical dependency Mutually negotiate critical dependencies Resolve available Vs. required work product dates with the project schedule Record, review & mutually agree between on dependencies between producers and receivers of every critically dependent work product Regularly track critical dependencies and take requisite corrective actions The work product(s) that will change hands Who will produce & accept the work product(s) When the work product(s) will be produced Acceptance criteria for these work product(s) All impacted group agree on mutual commitments between themselves Identify & track critical inter-group dependencies Actual or expected status/completion dates against the coordinated plan Evaluate impact on future activities & milestones of late or early completion Report back problems, actual and anticipated, to the right managers A published procedure is used to address unresolved cross functional issues Stake holders periodically exchange technical and other kinds of relevant information Articulate customer wish lists & needs Monitor status of technical activities Align interpretation and implementation of requirements, as well as expectations across all stakeholders Review commitments to ensure that they are being met Review technical risks & issues

INSTITUTIONALIZING PEER REVIEW AND ACTIVITIES
CAPABILITY LEVEL 3 Standardized Best Practices in use INSTITUTIONALIZING PEER REVIEW AND ACTIVITIES PEER REVIEW Goals: Conduct peer reviews of work products in a planned manner Identify and remove defects in work products Publish organization wide peer review policy Commitment Provide adequate resources & funds for peer review of each work product that must be so reviewed Require identification of a standard set of work products that must be reviewed by peers for all projects Require each project identify its special work products that will be reviewed by peers Require leaders be trained in leading peer reviews Require that peer reviews focus on work products under review, not those responsible for producing them Require that management does not use peer reviews to evaluate individual performance Ability Train peer review leaders Prepare and distribute peer review materials Lead the peer review Review distributed peer review materials Participate in peer review, identify defects; participate in follow up reviews to rectify or follow up on defects Monitor rework of work products that had to be rectified (based on its peer review) Record & report peer review findings Conduct peer reviews of work products in a planned manner Train peer review participants Measure progress, & track status of peer review activities Measure & Analyze 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 QA audits or reviews peer review activities & work products; reports its findings Monitor Implementation KPA Execution (activities) Verify reviews are being conducted as planned Verify adequate training of peer review leaders to fill their roles effectively Verify adequate training of peer review participants to fill their roles effectively Verify compliance with peer review preparation, conduct & follow up processes; verify follw up actions are being taken Verify peer review reports are complete, accurate, and timely Identify and remove defects in work products Plan peer reviews; publish plans Identify work products that must be reviewed; include the organization wide standard set of work products that must be peer reviewed. Schedule work product reviews; identify trained review leaders and participants for each peer review expected in the near future Trained leaders lead peer reviews Distribute review materials with enough lead time before the review to give reviewers adequate time to prepare Each reviewer knows the role assigned to him or her for the peer review session Enforce readiness & completion criteria; report issues involved in satisfying these criteria to the right managers Interpret and use review criteria checklists consistently Track action items to resolution Tasks are considered complete not only after finishing requisite peer reviews, but also after all required rework is completed Conduct the peer review in compliance with the published procedure Tailor checklist to fit the work product under review Peer review check lists; also review them with likely users Record peer review information Examples of Checklist Items Compliance with standards & procedures, completeness, correctness, maintainability, compliance with construction rules, etc. To be fruitful, the review must be of work products, not people or organizations. The review leader must enforce & facilitate this key principle Defects must not be used to evaluate individuals or organizations. It will undermine the purpose & effectiveness of the peer review

This is a close polymorphism of QUANTITATIVE PERFORMANCE MANAGEMENT from the Workforce Maturity Model. Included here for IT Service evaluation, specifically. LEVEL 4 ANALYSIS HIERARCHY CAPABILITY LEVEL 4 Quantitative Quality Management in Place Process Capability GOALS OF KEY PROCESS AREAS (KPAs) QUANTITATIVE PROCESS MANAGEMENT Goals: Plan activities to quantitatively manage business systems & software development processes Quantitatively control business systems & software processes Establish & use requisite quantified tolerances from the organization’s standard process(es) Specific goals that will contribute the most to quantitative quality management Assure process quality QUANTITATIVE PRODUCT QUALITY MANAGEMENT Goals: Plan activities to quantitatively manage the quality of business systems & software produced by software and systems engineering projects. Define measurable goals and priorities for business systems & software produced by software and systems engineering projects. Quantify, track and manage progress towards these goals Assure product quality

CONTINUED ON NEXT PAGE KPA execution (activities) CAPABILITY LEVEL 4
Quantitative Quality Management in Place QUANTITATIVE PROCESS MANAGEMENT Goals: Plan activities to quantitatively manage business systems & software development processes Quantitatively control business systems & software processes Establish & use requisite quantified tolerances from the organization’s standard process(es) “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. Publish, & Commit to an organization wide policy for measuring & quantitatively controlling the project level software/systems process Commitment Require compliance with a published project level plan to quantitatively control the project level software/systems process Require that individuals’ performance information be kept confidential, and access to it appropriately guarded Plan activities to quantitatively manage business systems & software development 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 analysis of process performance and maintenance of a baseline of tolerances for performance parameters Assign responsibility for coordinating quantitative process management to the SEPG Require projects use the baseline to set performance goals Provide adequate resources & funds for quantitative process management activities Ability Responsibility for quantitative process management activities of projects sits with managers & task leaders of groups responsible for the corresponding activity Enable and institute an organization wide measurement program Provide the right tools and automation (statistical & quantitative analysis tools, problem tracking tools, database management systems, etc.) Establish & use requisite quantified tolerances from the organization’s standard process Commitment & support for requisite data collection & analysis Train individuals & support staff engaged in quantitative process management appropriately Orient those engaged in projects & related activities on the value and goals of quantitative process management Measure & Analyze Measure & track the status of quantitative process management activities Monitor Implementation Periodic Upper Management quantitative process management activity review Quantitatively control business systems & software processes Periodic & event based Project Manager’s quantitative process management activity review QA review/audit of quantitative process management activities & work products Verify that the plans for quantitative process management are being followed Verify that the procedures for quantitative process management are being followed Verify that requisite data for quantitative process management is being collected & analyzed Requisite data exists Requisite data is collected The collected data is needed The data is aligned with the goals of the measurement program The cost of data collection is justified by its value The data is tapped at the right place, & the right point in the project’s life The data is timely, accurate, valid & reliable The confidentiality of the data is adequately protected KPA execution (activities) CONTINUED ON NEXT PAGE

QUANTITATIVE PROCESS MANAGEMENT ACTIVITIES
CAPABILITY LEVEL 4 Quantitative Quality Management in Place QUANTITATIVE PROCESS MANAGEMENT ACTIVITIES KPA Execution (activities) 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 CONTINUED FROM PREVIOUS PAGE Align with the organization’s strategic product quality, productivity & time to market goals Derive the plan from the organization’s standard process Align with the project’s product quality, productivity & time to develop goals Factor in the actual performance of similar project level software/systems processes Base the plan on the project level software/systems process Align with the organization’s measurement program Plan for Business Activity Monitoring for identifying business process bottlenecks Align the plan Peers review the plan SEPG reviews the plan Manage & Control the plan Comply with the published procedure for formulating each project’s quantitative process management plan Activities must support plan objectives Measure & analyze tasks & activities Conform to planned metrics & measurement procedures Stick to planned activities & schedules Stick with planned individual & group responsibilities for activities Use the planned staff, tools & other planned resources for each activity Follow quantitative process management procedures Measure and analyze Service Reuse Stick to the project’s published quantitative process management plan Plan activities to quantitatively manage business systems & software development processes Consider task dependencies & relationships Consider project work products and their mutual relationships, as well as their relationships with the project level process Consider points of process control and data acquisition The project level process must prescribe the project’s data acquisition & quantitative analysis strategies The data must support organizational and project objectives Precisely define each metric & its use, and data items that must be collected, their uses, analysis, and the process control points they will be tapped from Consider the entire software/business system life, pre and post development through retirement when determining what metrics will be needed The scope of measurement must include the features of key activities and the major work products of the software/systems process All projects must collect the data prescribed by the organization’s standard software/systems process Governing processes (control activities) must control the requisite parameters being measured as a natural and integral part of the software/systems process Metrics must support the analyses prescribed in the plan The quality of metrics data (validity, reliability, accuracy & timeliness) must be assessed by an independent group Preserve the metrics data in the process repository Follow a published procedure when collecting metrics data Quantitatively control business systems & software processes The procedure defines data analysis activities, the inputs, processing, outputs, techniques, decision criteria & actions The procedure restricts the scope of measurement to the activities of the project level software/systems process The procedure specifies appropriate and valid measurements for the characteristics it purports to measure The procedure specifies expected means and variances for each metric The procedure defines tolerances for each metric and establishes it as the baseline The procedure compares the actual value of each metric to its expected mean and variance The procedure describes adjustments that will bring out-of-tolerance processes back into prescribed limits The procedure establishes baselines for metrics definition, actual values and acceptable limits Manage & control process performance baselines 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 Review results of the analysis with those who are affected by it, before reporting it to others Managers (including upper management) and task leaders must get the regular reports they need The Quality Assurance group must get the regular reports it needs Managers and task leaders get specialized reports on request The procedure requires that tolerances for process parameters be computed from corresponding performance histories & expected statistical values of those parameters (which are stored in the process repository) The procedure requires that tolerances of the organizations standard process be regularly updated based on corresponding tolerances of individual projects The procedure requires that the tolerances of the organization’s standard process be published & be easily accessible to all those who will need and use it. The procedure asks that trends in tolerances of the standard process be analyzed to predict likely problems and to identify opportunities for process improvement The procedure asks that the baseline tolerances in the standard process be Managed & Controlled In a break from the past, when a substantially different kind of project is undertaken, the procedure asks that the project establish a new tolerance baseline, and that this be an integral part of the project level customization of the standard process The procedure asks that the impact of changes to the standard process on the tolerance baseline be tracked,analyzed and assessed Establish & use requisite quantified tolerances from the organization’s standard process Comply with a published procedure to create & maintain the baseline of tolerances for the organizations standard process(es)

QUANTITATIVE PRODUCT QUALITY MANAGEMENT
CAPABILITY LEVEL 4 Quantitative Quality Management in Place QUANTITATIVE PRODUCT QUALITY MANAGEMENT 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 Commit to a following published organization wide software & business process quality management policy Every project must define & measure quality metrics for key work products & the business process/software Every 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 Provide adequate resources & funds for managing the quality of work products Commitment Ability Train project participants, especially engineers, writers, QA & configuration management staff in relevant product quality management activities 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 set Provide 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.) Define measurable goals and priorities for business systems & software produced by software and systems engineering projects Measurement & control of quality with the project level software/systems process Planning quality goals & commitments for work products Train project participants, especially engineers, writers, QA & configuration management staff in relevant product quality management Track status of software & business system quality management activities 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 Measure & Analyze Upper Managers’ periodic quality management review Audit or review the project’s quality plan Audit or review the process for setting & tracking quality goals Monitor Implementation Project Manager’s periodic & event based quality management review QA review of Quality Management activities & work products Understand customers’, end users’& producers quality needs (for example through focus groups, product evaluations, surveys etc.) Trace customer, end user & producer quality needs & priorities back to software/systems requirements & goals) Record an assessment of whether the project level process is capable of meeting work product quality goals Align the project’s quality plan with that of the firm (or the part thereof in the scope of the change) Derive the quality plan from plans of other projects, past or present Update the quality plan at the start, and at every major milestone & whenever requirements change Peer review the quality plan Review the quality plan with stakeholders (or their representatives) Upper management review of quality plans Manage & control the quality plan Everybody impacted by the quality plan can access it easily KPA Execution (activities) Follow the published procedure to create & maintain the project level quality plan Address quality measurement points in the process Identify key quality goals, from customer & end user perspectives, for software & the business process Identify planned actions to improve on past performance (quality) Identify Quality measurement activities such as testing, peer reviews, simulations & iterative prototyping,etc.) Address work product quality goals in terms of their planned features, especially those which will render work products unusable or undesirable from the customer and end user perspectives if not satisfied Address planned actions if projections show that work product quality will be short of that planned Base quality management activities on the quality plan Plan activities to quantitatively manage the quality of business systems & software produced by software and systems engineering projects Define, monitor & revise quantitative quality goals throughout the project’s life Identify work product quality features(performance in functionality & information quality, usability, creatability & maintainability) Identify specific quantified quality measures for (requisite) work product features Specify quality goals in terms of acceptable ranges for each quantified measure Publish the quality goals as an integral part of the project plan Segregate and publish quality goals for each step of the software/system development life cycle Revise quality goals in step with evolving understanding of customer, end user and the producer’s needs, and also the software/business system that will be produced Appropriately apportion quantitative quality goals among the project’s contractors At the beginning of each task, review quality goals At the beginning of each task, identify quality goals relevant to the task at hand At the beginning of each task, identify task plans for reaching quality goals At the beginning of each task, review any changes made to address requisite quality goals Quantify, track and manage progress towards these goals Plan & execute project tasks to address its work product quality goals Measure the quality of work products of each stage of the product life cycle, through development & retirement Analyze quality measurements to determine if goals have been met Act in compliance with the quality plan to align work product quality with corresponding goals Resolve conflicts between quality goals Measure and analyze actual work product quality against goals based on specific events Analyze, & resolve conflict based on cost of achieving each conflicting goal Consider alternative goals aligned with business strategies & short term priorities Give users & customers (or their representatives) a voice in balancing conflicting quality goals Revise work products and plans to reflect compromises

CAPABILITY LEVEL 5 Continuous Improvement and innovation Institutionalized Process Capability GOALS OF KEY PROCESS AREAS (KPAs) DEFECT PREVENTION Goals: Plan defect prevention Seek & Identify common causes of defects Prioritize and systematically eliminate causes of defects Identify, anticipate & prevent defects & their root causes Integrate preventative processes into the organization's standard software/systems processes Specific goals that will contribute the most to stabilizing change and making it routine 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 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 This is a close polymorphism of CONTINUOUS CAPABILITY IMPROVEMENT from the Workforce Maturity Model. Included here for IT Service evaluation, specifically. PROCESS CHANGE MANAGEMENT Goals: Plan continuous process improvement. Organization-wide participation in process improvement and innovation. Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it Deploy a formal & organization-wide standard process for continual technology process improvement & innovation

INSTITUTIONALIZING DEFECT PREVENTION
CAPABILITY LEVEL 5 Continuous Improvement Institutionalized INSTITUTIONALIZING DEFECT PREVENTION DEFECT PREVENTION Goals: Plan defect prevention Seek & Identify common causes of defects Prioritize and systematically eliminate causes for defects Publish, & Commit to an organization wide policy of defect prevention Commitment Require long term plans for funding defect prevention, staffing & allocating needed resources for it Require that requisite resources be allocated for defect prevention activities Require org. wide implementation of defect prevention activities to improve software, business systems, the processes that make them Require that the results of defect prevention activities be reviewed to ensure that they are effective Require that management & technical action items identified by defect prevention activities be recorded, addressed, tracked to resolution Plan defect prevention Every project must publish, & Commit to an project specific policy for defect prevention Require allocation of needed resources for defect prevention Require project management & technical action items identified by defect prevention activities be recorded, addressed & tracked to resolution Require that defect prevention activities be an integral part of the project plan Prioritize and systematically eliminate causes for defects Assign responsibility for coordinating defect prevention activities organization wide to the SEPG Assign responsibility for coordinating defect prevention in the project to a project level counterpart of the SEPG Ability Provide adequate resources & funds for project & organization wide defect prevention activities Integrate appropriate responsibility for defect prevention into plans for individual role-responsibilities Plan management participation in defect prevention activities Represent every software project in the organization wide defect prevention team Provide the right tools and automation (statistical & quantitative analysis tools, defect tracking & causal analysis tools, database management systems, etc.) Train individuals & support staff in discharging their defect prevention responsibilities Measure & Analyze Measure & track the status of defect prevention activities Monitor Implementation Periodic Upper Management defect prevention activity review Seek & Identify common causes of defects Frequency distribution of defects by major defect class Frequency distribution of defects prevention actions by major classes of actions Significant defect prevention actions Summary status of proposed open & closed actions Summary of effectiveness, cost reductions aand benefits that may be attributed to defects prevented Actual costs incurred by completed defect prevention activities versus projected future cost of (planned) defect prevention Periodic & event based Project Manager’s defect prevention activity review QA review/audit & report of defect prevention activities & work products Verify that staff are trained adequately to fulfill their defect prevention responsibilities Verify that the proper conduct of kick-off & causal analysis meetings Verify that the procedures for quantitative process management are being followed KPA execution (activities) CONTINUED ON NEXT PAGE

DEFECT PREVENTION ACTIVITIES
CAPABILITY LEVEL 5 Continuous Improvement Institutionalized DEFECT PREVENTION ACTIVITIES DEFECT PREVENTION Goals: Plan defect prevention Seek & Identify common causes of defects Prioritize and systematically eliminate causes for defects Go beyond immediate causes & determine why the defect escaped verification procedures, and if other defects might have been similarly missed KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Identify defect prevention activities Schedule defect prevention activities Assign requisite responsibilities & resources, including staff & tools Peer review the plan Plan defect prevention Cover the project level process, standards, procedures, methods & relevant tools, emphasizing recent changes Cover resources required (inputs) for the task Cover work products (outputs) of the task, with examples when available Cover criteria & methods for evaluating work products Cover criteria & methods for verifying compliance with the project level process List common errors and recommended preventive measures for the current task/phase of the project life cycle Cover team assignments & role-responsibilities Cover the task schedule Cover the product quality objectives for the task, in the context of those for the project Start every task with a preparatory meeting of those involved in the task to prepare for requisite activities, including those required to prevent defects Plan defect prevention 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 Require each team performing a task conduct causal analysis meetings The leader/facilitator of cause-and-effect meetings must have been appropriately trained Identify defects & analyze root causes Categorize defects by root cause (or kind of root cause) Recommend preventive actions & put it on record Categorize & record defects by common causes Record the meeting outcome for use by other projects & the organization as a whole Comply with a published procedure in conducting causal analysis meetings 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 Seek & Identify common causes of defects Identify defect prevention recommendations (of causal analysis teams) that will be addressed Identify defect prevention action items requested by other defect prevention teams that will be addressed Identify 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 them Assign responsibility for implementing actions; the team may take some actions directly & arrange for implementing others thru groups outside the team Review results of defect prevention experiments; incorporate successful practices into the project/standard process across projects as applicable Track action item status (including the status of proposed action items) Publish process improvement proposals for standard & project level processes; identify requestors/proposers Review & verify finished action items before closing them Recognize & reward significant defect prevention efforts & successes 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 Record proposed actions of causal analysis meetings Record proposed actions that will be implemented Manage & control defect prevention information Proactively hunt down defects (At Level 1, the norm was reactive crisis management) Comply with a published procedure when amending the standard process to prevent defects Comply with a published procedure to amend the project level process to prevent defects Prioritize and systematically eliminate causes for defects Inform stakeholders (or their representatives - for example, marketing and sales groups may represent customers or users) of the status & results of defect prevention activities Summarized information by kind of defect Frequency distribution of defects by significant defect classes Significant innovations & actions that address each kind of defect Summarized status of defect prevention proposals & action items

INSTITUTIONALIZING TECHNOLOGY CHANGE MANAGEMENT
CAPABILITY LEVEL 5 Continuous Improvement Institutionalized INSTITUTIONALIZING TECHNOLOGY CHANGE MANAGEMENT TECHNOLOGY CHANGE MANAGEMENT Goals: Plan absorption of technological changes. Evaluate the impact of new technology on quality & productivity. Make the right new technologies the norm in the right practices throughout the organization Commitment Commit to following a published organization wide policy for improving technological capabilities Upper management sponsorship of technology improvements Require written objectives for technological changes Require a published plan for changing technology in aligned with the published purpose of the change Upper management input and assistance in formulating a strategy to address product quality, productivity & product development cycle time objectives Upper management input and assistance in formulating a strategy to address customer/end user needs Upper management coordinates alignment of lower level goals and approaches with the organization’s strategy Upper management makes its commitment to managing technological change visible across the organization Upper management establishes long term funding, staffing & resource plans for managing technological change Plan absorption of technological changes Upper management oversight of technology improvement Ability Upper management input and assistance in formulating a technology change management policy Upper management ensures adequate resource allocation for technology change management Upper management assistance in aligning technology change management strategies with organizational strategies Upper management participation in formulating technological change management plans Assign responsibility for coordinating technology change management to the SEPG Coordination of requirements & issues across org. & all levels Securing support of staff & management & coordinates it across org. & all levels Explore what might benefit from new technology Upper management secures support of staff & management & coordinates it across the organization & all its levels 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 Provide adequate resources & funds for a unit that will coordinate technology change management Assign experienced specialists (Hardware, Work Stations, Networks, programming language, component reuse, CASE, CAPE and metrics specialists, etc.) Provide the right tools and automation (subscriptions [on-line & paper publications], workstations, database & data analysis tools etc.) Support information gathering & analysis needed to evaluate the impact of changes in technology Automated recording of requisite process & product information Ability to support requisite data analysis The ability to appropriately present (display) selected data & analysis results Evaluate the impact of new technology on quality & productivity Ensure that the process & work product information needed to analyze & evaluate the impact of technology changes & home in on the right technology is available Train the (SEPG) unit responsible for it, in technology change management Measure & Analyze Track status of technology change management activities Monitor Implementation Periodic Upper Management technology change management activity review Make the right new technologies the norm in the right practices throughout the organization Summarize technology change management activities Identify course corrections & strategy changes Resolve issues that could not be resolved at lower organizational levels Approve revised technology change management plans (if any) QA review/audit of technology change activities & work products Technology Change Management Plan review Technology selection, procurement & installation process review KPA execution (activities) CONTINUED ON NEXT PAGE

TECHNOLOGY CHANGE MANAGEMENT ACTIVITIES
CAPABILITY LEVEL 5 Continuous Improvement Institutionalized TECHNOLOGY CHANGE MANAGEMENT ACTIVITIES 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 KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Role-responsibilities & resource requirements including staff & tools Technology strategy for strengthening the firm’s market position & and automation of the standard systems development process List technology change management procedures Approach to new technology introductions in support of specific organizational or project needs Peer review the plan Plan review by managers impacted by it Plan technology change management Identify processes that might benefit from changes in technology Identify candidate technologies Determine the approach to identifying technology change opportunities Estimate life of technology from introduction to replacement Record make/buy trade-off studies & recommendations Define approaches for assessing unproven or high risk (candidate ) technologies Define technology acquisition & installation procedures Define training (initial/ongoing), support & consulting requirements Identify technology change candidates (processes/areas) in coordination with individual projects & the SEPG unit responsible for technology change management Plan absorption of technological changes Solicit technology improvement suggestions Identify candidate technologies that might fit Evaluate how well each will fit current & future org. & project needs Periodically search for, & identify new technology that will support current & future needs Systematically 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 needs Identify and implement Business process improvement based on SOA using BAM results Disseminate information on new technologies appropriately Disseminate information on advanced technologies in use in different parts of the organization appropriately Disseminate information on the status of technologies being inducted into the organization appropriately Make the right new technologies the norm in the right practices throughout the organization Keep management & technical staff informed of new technologies Identify points of maximum benefit from induction of new technology into the standard process Identify the technological changes that will help these areas, and the economic costs & benefits of these changes Define the relationship between the chosen technology & the standard process; the places where the standard process will be impacted Project quantitative & qualitative results of the technological change Determine which changes must be piloted (if any) Prioritize technological changes Record & publish the technology analysis Systematically analyze the standard process; identify where it might benefit from new technology (A SEPG task) 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 choosing & acquiring new technology Record requests for technology acquisition, obtain requisite management approvals for requisite expense thresholds Perform preliminary cost-benefit analysis of candidate technological changes Use selection criteria approved and predefined by the procedure Record plans & requirements for the envisioned technological change Evaluate the impact of new technology on quality & productivity Pilot & prove the feasibility & economic value of new or untried advanced technologies Publish pilot plans; cover objectives, evaluation criteria & activities Managers of impacted groups review & approve the pilot 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 norm Collect, analyze & publish the results of the pilot project Pilot the technology where appropriate before inducting it as the norm 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 Comply with a published procedure when inducting new technology into the standard process Proactively hunt for technological improvement Comply with a published procedure to induct new technology into the project level process Concentrate on improving quality, timeliness & productivity Use Pilot projects to test & tune the technology to reduce risk

INSTITUTIONALIZING PROCESS CHANGE MANAGEMENT
CAPABILITY LEVEL 5 Continuous Improvement Institutionalized INSTITUTIONALIZING PROCESS CHANGE MANAGEMENT PROCESS CHANGE MANAGEMENT Goals: Plan continuous process improvement. Organization-wide participation in process improvement. Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it Recognize skilled & motivated people as the principle resource for process improvement Recognition & reward from sponsors are critical to success Commitment\ Commit to following a published organization wide policy of process improvement, including improving the processes for developing software & business systems Require measurable quantitative goals & tracking of actual performance against them Require goals address product quality improvement, productivity improvement or software/systems development (& deployment) cycle times singly or in combination Require participation of all managers & staff in improving the software/systems process Plan continuous process improvement Upper management sponsorship of process improvement activities Upper management articulates long term process improvement objectives & plans Upper management commits adequate resources for process improvement activities Upper management coordinates process improvement goals of individual managers & units; validates their feasibility, risk & requisite aggressiveness Upper management monitors process improvement performance against goals Upper management makes process improvement a priority area, and keeps a stable focus on it even when products are under pressure or in crises Upper management resolves process improvement issues in a timely manner Upper management rewards & recognizes employee participation in process improvement activities Provide adequate resources & funds for process improvement Control, development & dissemination of process changes Communication, recognition & motivational activities needed for maintaining employee participation; the requisite administrative & human resources infrastructure to govern these activities Support, guidance & leadership Process improvement Record maintenance Assign seasoned methodologists with experience in software & systems process improvement Provide the right tools and automation (process automation & modeling tools, workstations, database & statistical analysis tools etc.) Allocate resources for kinds of process improvement activities Ability Train managers of units involved in software/business systems engineering in the process of process improvement (including the process of software improvement) Organization-wide participation in process improvement Train stakeholders (or their representatives) in the process of process improvement (including the process of software improvement) Train the upper management in process change management Measure & Analyze Track status of process improvement activities Periodic Upper Management process improvement activity review Monitor Implementation Summarize participation in process improvement activities Assess process performance Identify what changes (if any) are required in process improvement goals or objectives Resolve issues that could not be resolved at lower levels Approve revised process improvement plans (if any) Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it QA review/audit of process improvement activities & work products Verify that the process improvement plan is being prepared & followed Verify compliance with the process for initiating, submitting, reviewing & approving process improvement proposals, & planning process improvements Verify how validly process measurements reflect actual performance of the process(es) in question Verify compliance with the process for recording, reviewing, approving, controlling & disseminating changes in the standard process & the project level processes tailored from it. Verify the adequacy, extent & consistency of tracking process improvement activities Verify how well actual improvements in the process (of developing software & business processes) achieves the goals set, & the plans made for it KPA execution (activities) CONTINUED ON NEXT PAGE

PROCESS CHANGE MANAGEMENT ACTIVITIES
CAPABILITY LEVEL 5 Continuous Improvement Institutionalized PROCESS CHANGE MANAGEMENT ACTIVITIES Cross functional teams are key to process improvement; processes often cross organizational & functional boundaries, integrating them to deliver external value PROCESS CHANGE MANAGEMENT Goals: Plan continuous process improvement. Organization-wide participation in process improvement. Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it KPA Execution (activities) CONTINUED FROM PREVIOUS PAGE Always change from a stable & controlled base SEPG defines, creates & updates process improvement records SEPG sets goals & plans for measuring the performance of processes that create software & business systems SEPG reviews these performance goals with upper management SEPG participates in defining process improvement training needs; assists in developing course materials & supports their presentation Creates and updates procedures for processing process improvement proposals SEPG reviews improvement proposals for the processes that create software & business systems; coordinates requisite actions SEPG tracks participation in, accomplishments & the status of process improvement activities; reports back periodically to upper management SEPG coordinates & tracks changes to the standard process Empower individual members of the organization to improve its processes through a process improvement program Plan continuous process improvement Coordinate process improvement through the SEPG Align the plan with business & strategic plans, as well as customer satisfaction indicators Peer review the plan Review the plan with all managers impacted by it Manage & control the plan Plan process improvement in compliance with the published procedure for it For upper management oversight of process improvement For identifying, evaluating & introducing the right improvements For coordinating process improvement between managers involved For assembling & assigning teams/task forces to address specific improvements and/or footprints Role-responsibilities & resource requirements including staff & tools Process improvement priorities & footprints Short & long term process performance goals Teams assigned for specific improvement in specified footprints Procedures Administration & Support pans that will continue to maintain & institutionalize process improvement Conform to process improvement plan Procedures for encouraging participation & facilitating process improvement activities Inclusion of administrative staff in overseeing & reviewing process improvement activities Plans for recognizing individual roles & contributions to process improvement Proposals may be submitted at any time for any part of any process Evaluate each proposal; accept or reject it. Record the decision with reasons Determine the benefits of each proposal Prioritize (accepted) proposals; focus on high priority Plan & assign responsibility for actions (for implementing proposal) Assign high effort actions to teams; establish task forces, work groups & committees for specific process areas if need be Track the status of each proposal Act on proposals that have been outstanding for unusually long periods Review high impact (in terms of customer satisfaction, product quality or productivity) proposals with the right managers before implementing them Review, verify and approve completed process improvement actions with the individual who asked for it before closing it out Promptly acknowledge receipt of proposal & notify those who submitted them of their disposition with reasons Organization-wide participation in process improvement Comply with a published procedure when processing process improvement proposals Secure active participation of individuals in their assigned teams Fully fund each team; plan & schedule its activities Define clear, and if possible, quantitative goals of each effort Secure approval of plans from SEPG & managers of all impacted groups Tune the process, and record any changes during the pilot Record problems & lessons learned Estimate impacts proposed changes if made the norm, their benefits& risks & the uncertainty of these estimates Decide on broader deployment of the piloted process & on terminating, continuing or replanning the pilot project Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it Pilot the changed process (where appropriate) before making it the norm Comply with a published procedure when making changed process the norm Fund & provide all resources needed to change the process Record, review and agree upon the strategy for tracking changes in performance & requisite data collection Update requisite training in step with changes in the process; train before making the changed process the norm Before deploying change beyond a pilot project, enable requisite support & consultation to match the projected need for it; continue both as long as needed Make requisite changes to the standard process Make requisite changes to the project level processes All persons responsible for implementing change agree on strategy Determine what to measure & how; collect data automatically Keep records of initiating, implementing & the status of process improvement proposals Provide easy access to these records Keep process improvement histories & report improvement data These records chronicle the organization’s adaptability - its cycle times & capacity for change Keep records of process improvement activities A summary of major process improvement activities Significant innovations & actions in process improvement Summary of proposals submitted, open and completed Inform technical staff & their managers of changes in state and/or the results of process improvement activities when these changes occur

Project Management Maturity Model

Similar presentations

Presentation on theme: "Project Management Maturity Model"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Project Management Maturity Model

Similar presentations

Presentation on theme: "Project Management Maturity Model"— Presentation transcript:

Similar presentations

About project

Feedback