Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Project Management Maturity Model 12/22/14 © 2014 Amit Mitra and Larissa Zhurakovskaya."— Presentation transcript:

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

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

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

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

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

6 CAPABILITY LEVEL 2 Consistent Process Repeatability 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 KPA Execution (activities) Include Engineering groups (including software engineers) in the project proposal team Involve in preparing, submitting, clarifying, negotiating commitments & changes that impact corresponding groups 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 PROJECT PLANNING 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 Upper management, following a documented procedure, reviews all commitments made to external parties (including software commitments). Establish a software development life cycle divided into predefined, manageably sized phases. Consistent with requirements, solution(s) responsibilities, statement of work & standards (external & internal to the project) Negotiate plans & inter-group commitments with corresponding groups, document agreements & budget for inter-group support Develop systems project plans (& overall project plan) consistent with a documented procedure All impacted groups (including software & Project Managers) review the project plan Manage & control the plan (software & overall) Document the overall & software project plan State scope & purpose, specific objectives Describe software life cycle, reasons for selecting a specific type/methodology Specify software & other development & maintenance standards, procedures, techniques & methods Identify software & other engineering work products Include software (& other) work products size estimates (size anticipated changes as well) Estimate use of critical computer resources Describe project schedules, milestones & planned reviews Project (software) risk assessments Include project (software) engineering facilities & tools plan Identify items (including software work products) needed to manage & control the (software) project Include (software)Project effort & cost estimate Plan & document project activities & commit- ments Ensure commitments are agreed upon between all impacted groups Decide the Chargeback and costing model for services Negotiate SLAs with service providers, if required Evaluate existing services and consider service reuse while cost estimation

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

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

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

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

11 Manage & control the project’s QA plan CAPABILITY LEVEL 2 Consistent Process Repeatability QUALITY ASSURANCE Goals: Plan Quality Assurance activities Objectively verify that work products & activities comply with standards Communicate QA results & activities to all impacted groups Upper management resolves noncompliance when it cannot be resolved at the project level KPA Execution (activities) Develop the project’s QA plan in parallel with, or as an integral part of, the overall project plan Develop project QA plans consistent with a documented procedure All impacted groups (including software & Project Managers) review the project’s QA plan Follow the QA plan QA group’s authority & 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 QA audits & reviews 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 Evaluate deliverables before delivery to customers Periodically review QA activities & findings with customer’s QA personnel Activities, tools & work products(software & other - e.g. documentation) to be evaluated by QA Verify compliance against plan, standards & procedures Record deviations & track to closure Verify corrections Resolve deviation as close as possible to its origin (task leader, subproject or project manager) when possible Record & escalate unresolved deviations to designated senior QA manager Periodically review escalated items until they are resolved Manage and control the non-compliance record in a baseline Report QA findings back to software engineering & other participating groups periodically Conform to a written procedure in recording & processing (software) activities & work product deviations from the plan or its standards & procedures QUALITY ASSURANCE ACTIVITIES Plan Quality Assurance activities Objectively verify that work products & activities comply with standards Communicat QA results & activities to all impacted groups Managed & Controlled 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 Consult & review plans, procedures & standards for complying with organizational policy, external & project standards, plan contents etc. QA certifies that the (software & business system) project plan, standards & procedures have been deployed & can be used for QA reviews/audit Managed & Controlled Non-compliance 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 Not always mandatory & all customers may not have QA groups. It is needed for sheltered markets: Large, expensive, custom built systems for large customers who have their own QA groups, or Customers subject to regulation & regulatory standards Upper management resolves non- compliance when it cannot be resolved at the project level (Systems) QA verifies (Systems) engineering work product compliance Verify compliance (Systems) QA verifies (Systems) engineering activity compliance Periodically review QA activities & findings with QA personnel across the extended enterprise

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

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

14 CAPABILITY LEVEL 2 Consistent Process Repeatability CONFIGURATION MANAGEMENT Goals: Plan Configuration Management activities Identify, control & make selected work products available on time Control changes to work products Communicate systems, software and component baseline statuses to all impacted groups KPA Execution (activities) CONFIGURATION MANAGEMENT ACTIVITIES Develop the SCM plan in parallel with, and as an integral part of, the overall project plan Develop project SCM plan consistent with a documented procedure All impacted groups (including software & Project Managers) review the SCM plan Manage & control the SCM plan in a baseline Deploy a configuration management library as the repository of systems baselines Support for multiple levels of control (eg: production code may require stricter controls than development versions) Store & retrieve configuration 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 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) Identify items that will be placed under configuration management (in the repository) Give all impacted groups access to standard reports describing SCM activity & the baseline’s contents Configuration (component) archival, recovery & version management Conduct reviews/regression tests to eliminate unintended effects of changes on the baseline Baseline only configuration items approved by the SCCB Component check in/out procedure maintains baseline accuracy & integrity SCCB authorization to build products/deliverables from the baseline library Both internal & external products/deliverables released from the baseline are built purely from components stored in that baseline 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) Use documented procedures to: Record, review, approve & track configuration item change requests & problem reports Control Baseline changes Build & release products/ deliverables from the baseline Record the status of every configuration item Plan Config. Managemt activities Select & control work products & make them available to the project team Inform all impacted groups of (systems) baseline contents & status Base SCM activities on a documented & approved SCM plan SCM activity schedule, resources(staff, tools, computer & infrastructure facilities) & individual responsibilities Required SCM activities & support from Software & business systems Engineering, & other groups Selection is based on written criteria Assign an unique identifier to each item Associate each item with specific baseline(s) Specify when, in the item’s lifecycle, it will be put under configuration management Specify the item’s owner over its lifecycle from the configuration management perspective 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 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 Comply with a written procedure to audit systems baselines Prepare adequately for the audit Assess the baseline’s integrity Review the baseline library (automated or manual system) structure & facilities Verify compliance with SCM standards & procedures Report audit results to the project’s software & business system managers Track resulting action items to closure Verify accuracy & completeness of (baseline) library contents Control changes to work products selected & made available to the project team(s)

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

16 CAPABILITY LEVEL 2 Consistent Process Repeatability KPA Execution (activities) Track contract activities & commitments against the contractor’s approved (written) project plan; communicate status Revise contract (statement of work, T&C & commitments) consistent with a documented procedure All impacted groups (of all parties bound by the contract) review & consent to revisions Included in overall project (software) plan, or linked to corresponding items therein Comply with a written procedure to determine work that will be outsourced Comply with a written procedure to select contractor(s) able to perform Manage contracted work against contract Review contractor’s plan & approve contract CONTRACTOR MANAGEMENT ACTIVITIES CONTRACT MANAGEMENT Goals: Select qualified contractors & subcontractors Agree on mutual commitments with contractors Maintain ongoing communication with contractors Track contractors’ performance against commitments Select outsourced activities/ deliverables based on technical & nontechnical factors, contractor s’ capabilities & the right requirements & system partitions Create contract’s statement of work, standards & procedures from the overall requirements, project plan, statement of work, standards & procedures Agree on the contractor’s statement of work after baselining, reviewing & revising it with all impacted groups Create the contractor selection plan concurrently with the his statement of work Contractor proposal 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 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 Select qualified contractor Agree on mutual commitments with contractor Track contractor performance against commitments Scope & objectives Software & systems life cycle, reasons Standards & procedures Work products Effort & cost estimates Size estimates (anticipated changes as well) Use of critical computer (& other) resources Schedules, milestones & planned reviews Risk assessments (Software & systems) engineering facilities & tools Statement of Work Scope, goals, constraints & assumptions (technical, schedule, budgetary, resource etc), sponsors & end users of system, standards, responsibilities, impact & dependencies (internal & external organizations)

17 CAPABILITY LEVEL 2 Consistent Process Repeatability KPA Execution (activities) 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 Plan reviews in writing in the contractor’s statement of work Address (software & systems) risks Record issues, decisions & action items Address contractor’s activity status, plans & commitments Periodic ability review- Adequacy of contractor’s QA standards/ resources/plans to properly monitor project performance Implementation spot check - Spot check contractor’s project activities & deliverables, & audit contractor’s QA records as needed Implementation periodic check - (Periodically audit contractor’s internal QA activity records to verify compliance with QA standards, procedures &plans) Mutually review & approve acceptance procedures & criteria before testing Use documented procedures to: Formally review(Software/systems) Engineering accomplishments at selected milestones Outsourcing organization’s QA monitors contractor’s QA ability & implementation for the project Outsourcing organization’s Configuration Management (CM) group monitors contractor’s CM activities for the project Periodically evaluate contractor’s performance (across contracts) & review with contractor Revise contractor’s (software/systems) plan as needed Periodic ability review- Adequacy of contractor’s CM standards/resources/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 Test contracted deliverables before accepting them Document results Action plan for failed deliverables Maintain ongoing communic with contractor Track contractor performance against commitments The prime organization’s management, following a documented procedure, periodically coordinates, & reviews status, with contractor’s management Provide contractor insight to customers’ (&end-users’) needs Review contractor’s performance against his approved plan - technical, cost, staffing & schedule Review critical computer (&other) resources against his approved plan - track current estimates against original plan Address critical dependencies & commitments within contractor’s organization, especially those that impact (software) engineering 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 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 Management review Cost, schedule, financial & other management Risks & dependencies Tech review Meeting tech. Commitments & correct implementation of tech. requirements

18 LEVEL 3 ANALYSIS HIERARCHY CAPABILITY LEVEL 3 Standardized Best Practices in use TRAINING PROGRAM Goals: Plan training Offer technical & management training courses Train individuals STANDARD PROCESS DEPLOYMENT Goals: Tailor the standard software/systems process for individual projects Follow the tailored process for project planning & management BUSINESS SYSTEMS & SOFTWARE ENGINEERING Goals: Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent 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 Process Capability Provide relevant training Deploy standard processes Engineer components, systems & software accurately 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 GOALS OF KEY PROCESS AREAS (KPAs) ORGANIZATIONAL PROCESS FOCUS Goals: Coordinate systems development & improvement across the organization Identify software & systems process strengths & Weaknesses against a standard Plan process development & improvement across the organization Focus the organization on standardizing processes 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. These goals utilize Level 2 TRAINING practices from the Workforce Maturity Model. Included here for IT Service evaluation, specifically. These goals utilize Level 2 COMMUNICATION & COORDINATION practices from the Workforce Maturity Model. Included here for IT Service evaluation, specifically. Specific goals that will contribute the most to standardizing and deploying best practices

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

20 Coordinate the use of the systems process repository Monitor use of, and share or transfer the right processes, methods and tools between different projects and parts of the organization Coordinate training organization wide Keep the users of business systems/software methodology and processes updated on projects and activities for developing and improving current processes Training plans on business systems/software development process and related subjects Training prepared and delivered by SEPG or the Training Group (see the Training KPA) Assess software/systems process periodically and develop action plans to address findings Identify findings that will be addressed Guidelines for changes that will address the findings Groups and persons responsible for implementing changes Plan software/systems process development/improvement activities (and keep plan updated) Based on action plans from periodic assessments and other 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 Standard software & systems process Project software & systems processes Coordinate systems development & improvement organization- wide Plan process development & improvement across the organization Identify software & systems process strengths & Weaknesses against a standards CAPABILITY LEVEL 3 Standardized Best Practices in use ORGANIZATIONAL PROCESS FOCUS Goals: Coordinate systems development & improvement across the organization Identify software & systems process strengths & Weaknesses against a standard Plan process development & improvement across the organization ORGANIZATIONAL PROCESS FOCUS ACTIVITIES KPA Execution (activities)

21 CAPABILITY LEVEL 3 Standardized Best Practices in use ORGANIZATIONAL PROCESS DEFINITION Goals: Develop & maintain standard software & systems process(es) Monitor & communicate use of standard software & systems process(es) Commitment Ability Train SEPG Develop & maintain standard software & systems process(es) Publish policy for developing and maintaining standard processes for business systems and software development Provide adequate resources & funds for Systems process development & maintenance SEPG made responsible for systems process development and maintenance 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 for software/business systems engineering, process analysis& documentation techniques, etc. Monitor & communicate use of standard software/systems process(es) Measure & Analyze Monitor Implementation Periodic QA review of process assets, activities & work products for developing & improving software and systems processes Track status of process development and improvement activities Track milestone & work completion, effort & funds expended, resource utilization, etc against plan; track results of process assessments against previous assessments & recommendations Requires definition of requisite standard processes Requires project level customization of standards Requires maintenance, use and access to process assets Requires obtaining, organizing & using project level feedback to improve standard processes Process and work product measurement Lessons Learned Other feedback INSTITUTIONALIZING ORGANIZATIONAL PROCESS DEFINITION KPA execution (activities) Follow development, deployment, maintenance & documentation standards Control & use assets appropriately

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

23 CAPABILITY LEVEL 3 Standardized Best Practices in use TRAINING PROGRAM Goals: Plan training Offer technical & management training courses Train individuals Commitment Ability KPA Execution (activities) Create Training Group Staff the training group with the right mix of skills/knowledge Plan training INSTITUTIONALIZING TRAINING AND ACTIVITIES Train individuals Publish organization wide training policy Provide adequate resources & funds for training Offer technical & management training courses Measure & Analyze Monitor Implementation Periodic Upper Management Training Program review Track status of training activities & the overall training program Orient (brief) Managers of software and systems groups on the training program Prepare organization level training courses in compliance with organization wide training standards Create and use a procedure to waive training if individual(s) have requisite skills/knowledge for their envisioned role(s) Maintain training records Every project has a training plan it maintains, which addresses its specific training needs Plan, and revise organization wide training plan in compliance with a written, standard procedure Conduct training in compliance with organization wide training plan Requires identification of role specific skills/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 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 Measure the training program quality 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 Skill requirements, and their timing Skills that will be acquired through training and skills that will be acquired in other ways (specify how) Timed training requirements,and who will train Method of training & whether it will be done by the project team, the training group or external trainers Consider the project level training needs from project training plans Specify and schedule specific training based on timed organizational skill requirements Revise training plan in step with changing requirements Review training plan and significant revisions with impacted individuals Manage & Control training plan Ensure impacted groups and individuals can access the training plan conveniently and easily Describe each training course Review training course materials Manage & Control course materials 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 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

24 CAPABILITY LEVEL 3 Standardized Best Practices in use STANDARD PROCESS DEPLOYMENT Goals: Tailor the standard software/systems process for individual projects Follow the tailored process for project planning & management Commitment Ability Train project staff responsible for tailoring the standard process and its assets on their use and customization (as described in the training KPA) Tailor the standard software/syst ems process for individual projects INSTITUTIONALIZING STANDARD PROCESS DEPLOYMENT AND ACTIVITIES Publish organization wide policy for using the standard process and process assets for planning & managing software & systems engineering projects Provide adequate resources & funds for managing the project in compliance with the standard process Follow the tailored process for project planning & management Measure & Analyze Monitor Implementation Periodic Upper Management project activities review Track Effectiveness of integrated business process and software management Train Managers of software and systems groups on management of the technology, people and requisite administration Require each project level process be tailored from the standard 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 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) KPA Execution (activities) Tailor the standard process to create the project level software/systems process Choose approved project life cycle, Modify chosen life cycle, if need be in compliance with tailoring criteria & guidelines Document modifications in compliance with organization wide standards Establish project life cycle and document it Describe the project level software & systems process SEPG must review and approve the tailored process; Upper Management must approve SEPG waivers & approved deviations Contractual waivers and deviations from contractual requirements must be documented and approved by both upper management & the project’s customers when appropriate Manage & control the project level software/systems process 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 Lessons learned from organization wide project monitoring Proposed project level changes Process and product measurements Comply with a published procedure to develop and revise the project plan

25 KPA Execution (activities) Tailor the standard software/syst ems process for individual projects Follow the tailored process for project planning & management Comply with the project level process in managing the project Use the process repository for planning & estimating Manage work Product size and complexity in compliance with a published procedure Use data from similar projects if 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 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 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 Project cost & effort in compliance with a published procedure Manage use of computer resources in compliance with a published procedure Comply with the published procedure for assessing, managing and recording project risk Review each project periodically to align it with projected user, customer and business need An independent group must review the estimation procedures process engineer have used, and guide them on use of historical information in the process repository Inflate risky estimates by a contingency factor 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 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 Reviewers ensure right use of procedures & data Peer & experts review estimates that lack consensus Document rationale for contingency Assess & record risk of removing or reducing contingency Update estimation parameters & models when requirements change significantly Use actual productivity & cost data when available Estimates based on analysis, simulations, prototyping or pst experience Obtain/tune critical computer resources to meet the project’s operational and development (& analysis) requirements Meet computer resource requirements of software & business systems components Inflate initial estimates of critical computer resources by a requisite risk factor; document it with reasons Establish a threshold of projected use of critical computer resources, which will trigger action if crossed Comply with the project level process in scheduling funds, tasks, milestones, commitments, reviews, critical dependencies & staffing Identify, negotiate and flag critical dependencies in the project & software schedules Flag critical paths in the project & software schedules Regularly track critical paths and dependencies Document a threshold estimate for each critical path, which will trigger action if crossed 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 Comply with a published procedure in managing critical paths and critical task dependencies in the project’s task plan Track & re-assess risks at select project checkpoints, or when significant changes impact the project; revise plan if need be Identify and manage risk in compliance with a published 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 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 Identify options, assess impact & feasibility, consider providing reserves, etc. Review and revise priorities and risk management plans at checkpoints/incidents Monitor risks to refine risk assessment & risk management plans Collaborative Development Incorporate collaborative principles from Workforce Development CAPABILITY LEVEL 3 Standardized Best Practices in use STANDARD PROCESS DEPLOYMENT Goals: Tailor the standard software/systems process for individual projects Follow the tailored process for project planning & management STANDARD PROCESS DEPLOYMENT ACTIVITIES Considerations would include geographical locations & spread of project groups & contractors, size & complexity, stability of requirements, the development environment, the target operating environment, staff experience with the business & technology, resource availability, etc.

26 CAPABILITY LEVEL 3 Standardized Best Practices in use BUSINESS SYSTEMS & SOFTWARE ENGINEERING Goals: Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent Commitment Ability Train technical project staff adequately to enable them to measure up to their roles in the project INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES Publish the policy for performing prescribed activities in software & business systems engineering projects Provide adequate funds & resources to execute software/business engineering tasks Keep work products mutually consistent Measure & Analyze Monitor Implementation Periodic Upper Management project activities review Measure the quality & functionality of the product delivered by the project Orient Managers of software and systems groups, including project managers on the technology used by the project Require each project perform the tasks prescribed by the (project level) tailored 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 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 Sufficient availability of adequately skilled persons for every task Sufficient supply and availability of requisite tools for every task Orient technical project staff adequately to enable them to measure up to their roles in the project Track status of business process/software engineering activities Review & verify accuracy, consistency, completeness, feasibility & testability of 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 the right methods & tools into the project level process 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 KPA Execution (activities) Define, integrate & consistently perform software & systems engineering tasks Comply with the project level process when developing, maintaining, recording and verifying requirements. Requirements analysis methods are effective (for example, Object Oriented Analysis, Knowledge Artifacts, etc.) Requirements analysts review requirements, identify and resolve issues. Systems and acceptance testers verify testability of each 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 KPA Execution (activities)

27 Mutually consistent plans, processes, requirements, software, test plans & procedures, etc. KPA Execution (activities) Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent Comply with the project level process when developing, maintaining, recording or verifying the process design that will satisfy requirements and will be implemented by software Comply with the project level process to code/assemble, maintain, document & verify the software/ business process design that will satisfy requirements Comply with the project level process when testing the software or business system Comply with the project level process when planning or executing integration tests Plan & execute acceptance tests to demonstrate requirements have been satisfied Collect & analyze defect data from peer reviews in compliance with the project level process Keep work products mutually consistent 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 Comply with the project level process to develop & maintain documents which will be used to operate & maintain the software/ business system Document work products & make the documents easy to 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 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 Change the code/component assembly whenever requirement or design changes impact them Right level & depth (for example, unit, integration, acceptance tests) Right test strategy & techniques (for example, black box, statistical etc.) Right scope and coverage The test group that plans test cases & procedures must be independent of those who make the software or business 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 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 prepareApproach to testing & verification Responsibilities of each stakeholder Test facilities, equipment, tools & other support requirements Acceptance criteria 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 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.)Determine impact before changing Coordinate changes: products, plans, process specs & activities If requirements drive change, change requirements first Negotiate with, and communicate changes to all impacted groups Builders of software/the business process (coders/assemblers) review requirements & the design to ensure that all issues that impact their work are resolved Trace defects back to root causes - work products & work steps. It will prepare the organization for quantitative analysis of defects at Level 4 Develop and review test criteria with the right customers and end 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 CAPABILITY LEVEL 3 Standardized Best Practices in use BUSINESS SYSTEMS & SOFTWARE ENGINEERING Goals: Define, integrate & consistently perform software & systems engineering tasks Keep work products mutually consistent INSTITUTIONALIZING BUSINESS SYSTEMS & SOFTWARE ENGINEERING AND ACTIVITIES

28 Commitment Ability Coordinate tool compatibility between stake holders All impacted groups mutually agree on customer requirements Engineering groups identify, track and resolve intergroup issues Commit to a following published organization wide policy that will establish cross functional teams of stake holders with a mandate to produce the final deliverables of each project Provide adequate resources & funds for coordinating the activities of stakeholders All impacted group agree on mutual commitments between themselves Project objectives and requirements must be reviewed and agreed upon by all stakeholders in the team Stakeholders coordinate plans and activities Maintain a positive environment, encouraging teamwork, mutual support, interaction & coordination Measure & Analyze Monitor implementation Periodic Upper Management process review Track status of cross functional coordination Train all managers in team work Identify & track critical inter-group dependencies A group that accepts work products produced by others must review them to ensure that they meet their needs A published procedure is used to address unresolved cross functional issues Customers & end users (or groups such as marketing that speak for them) participate with engineering groups to articulate clear requirements Prioritize & identify critical requirements & characteristics Negotiate critical dependencies & constraints Record agreed upon acceptance criteria for the end product that will be delivered to customers Stakeholders work together to coordinate activities & resolve technical issues/risks Coordinate activities Manage issues Communicate cross functional commitments, coordinate & track work done, in compliance with a published plan Orient (brief) the task leaders of each group on the processes, methods & standards of the others Orient team members of the cross functional team on working as a team Periodic Upper Management process activity review Project Manager’s Periodic or event based activity review KPA Execution (activities) Track & review design & development activities for hardware, software & components (including Knowledge Artifacts & their subassemblies) Assess & track cross functional risk Clarify requirements & design issues; address & resolve project level conflicts if any Joint solutions & recommendations to address problems Address cross functional issues Project schedule Contractual and technical issues Responsibilities of each group 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 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) 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 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 Stake holders periodically exchange technical and other kinds of relevant information 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 CAPABILITY LEVEL 3 Standardized Best Practices in use INTERGROUP COORDINATION Goals: All impacted groups mutually agree on customer requirements All impacted group agree on mutual commitments between engineering groups Engineering groups identify, track and resolve intergroup issues INSTITUTIONALIZING INTERGROUP COORDINATION AND ACTIVITIES

29 CAPABILITY LEVEL 3 Standardized Best Practices in use PEER REVIEW Goals: Conduct peer reviews of work products in a planned manner Identify and remove defects in work products Commitment Ability KPA Execution (activities) Train peer review leaders Conduct peer reviews of work products in a planned manner INSTITUTIONALIZING PEER REVIEW AND ACTIVITIES Publish organization wide peer review policy Provide adequate resources & funds for peer review of each work product that must be so reviewed Identify and remove defects in work products Measure & Analyze Monitor Implementation Measure progress, & track status of peer review activities Plan peer reviews; publish plans Conduct the peer review in compliance with the published procedure Record peer review information QA audits or reviews peer review activities & work products; reports its findings Verify reviews are being conducted as planned Verify adequate training of peer review leaders to fill their roles effectively Verify adequate training of peer review participants to fill their roles effectively Verify compliance with peer review preparation, conduct & follow up processes; verify follw up actions are being taken Verify peer review reports are complete, accurate, and timely Identify work products that must be reviewed; include the organization wide standard set of work products that must be peer reviewed. Schedule work product reviews; identify trained review leaders and participants for each peer review expected in the near future Examples of Checklist Items Compliance with standards & procedures, completeness, correctness, maintainability, compliance with construction rules, etc. Defects must not be used to evaluate individuals or organizations. It will undermine the purpose & effectiveness of the peer review Require identification of a standard set of work products that must be reviewed by peers for all projects Require each project identify its special work products that will be reviewed by 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 Prepare and distribute peer review materials Lead the peer review Review distributed peer review materials Participate in peer review, identify defects; participate in follow up reviews to rectify or follow up on defects Monitor rework of work products that had to be rectified (based on its peer review) Record & report peer review findings Train peer review participants 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 Tailor checklist to fit the work product under review Peer review check lists; also review them with likely users Number & frequency of reviews; Number of work products reviewed against plan Defects discovered by peer review Numbers & proportion of work products reviewed Rework & rectification measurements Actual Vs. planned effort spent on peer reviews To be fruitful, the review must be of work products, not people or organizations. The review leader must enforce & facilitate this key principle

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

31 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) Commitment Assign responsibility for coordinating quantitative process management to the SEPG Commitment & support for requisite data collection & analysis Plan activities to quantitatively manage business systems & software development processes Establish & use requisite quantified tolerances from the organization’s standard process Publish, & Commit to an organization wide policy for measuring & quantitatively controlling the project level software/systems process Provide adequate resources & funds for quantitative process management activities Quantitatively control business systems & software processes Publish, & Commit to an organization wide policy for measuring tolerances in performance parameters of activities & work products of the organization’s standard software/systems process(es) Require compliance with a published project level plan to quantitatively control the project level software/systems process Require that individuals’ performance information be kept confidential, and access to it appropriately guarded Measure & Analyze Monitor Implementation Periodic Upper Management quantitative process management activity review Verify that the plans for quantitative process management are being followed Verify that the procedures for quantitative process management are being followed Verify that requisite data for quantitative process management is being collected & analyzed Measure & track the status of quantitative process management activities Train individuals & support staff engaged in quantitative process management appropriately “Quantitative Control” means any quantitative or statistical method that will analyze performance, identify reasons for variation (for example, transient conditions such as inadequate computer capacity, specific individuals or organizational units taking unexpected actions, unexpected factors in the business environment, etc.), and bring the performance within well defined limits. Require analysis of process performance and maintenance of a baseline of tolerances for performance parameters Require projects use the baseline to set performance goals Responsibility for quantitative process management activities of projects sits with managers & task leaders of groups responsible for the corresponding activity Enable and institute an organization wide measurement program Provide the right tools and automation (statistical & quantitative analysis tools, problem tracking tools, database management systems, etc.) Periodic & event based Project Manager’s quantitative process management activity review QA review/audit of quantitative process management activities & work products Orient those engaged in projects & related activities on the value and goals of quantitative process management Requisite data 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 Ability KPA execution (activities)

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

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

34 LEVEL 5 ANALYSIS HIERARCHY CAPABILITY LEVEL 5 Continuous Improvement and innovation Institutionalized TECHNOLOGY CHANGE MANAGEMENT Goals: Plan absorption of technological changes. Evaluate the impact of new technology on quality & productivity. Make the right new technologies the norm in the right practices throughout the organization Process Capability Specific goals that will contribute the most to stabilizing change and making it routine GOALS OF KEY PROCESS AREAS (KPAs) DEFECT 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 Optimize the process of choosing technology to upgrade quality, productivity, & timeliness of software/systems processes Institutionalize & make routine processes for the transfer of technology across projects and organizational units PROCESS CHANGE 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 This is a close polymorphism of CONTINUOUS CAPABILITY IMPROVEMENT from the Workforce Maturity Model. Included here for IT Service evaluation, specifically.

35 CAPABILITY LEVEL 5 Continuous Improvement Institutionalized DEFECT PREVENTION Goals: Plan defect prevention Seek & Identify common causes of defects Prioritize and systematically eliminate causes for defects Commitment Assign responsibility for coordinating defect prevention activities organization wide to the SEPG Plan defect prevention INSTITUTIONALIZING DEFECT PREVENTION Prioritize and systematically eliminate causes for defects Publish, & Commit to an organization wide policy of defect prevention Provide adequate resources & funds for project & organization wide defect prevention activities Seek & Identify common causes of defects Every project must publish, & Commit to an project specific policy for defect prevention Measure & Analyze Monitor Implementation Periodic Upper Management defect prevention activity review Verify that staff are trained adequately to fulfill their defect prevention responsibilities Verify that the proper conduct of kick-off & causal analysis meetings Verify that the procedures for quantitative process management are being followed Measure & track the status of defect prevention activities Train individuals & support staff in discharging their defect prevention responsibilities Periodic & event based Project Manager’s defect prevention activity review QA review/audit & report of defect prevention activities & work products Ability Require long term plans for funding defect prevention, staffing & allocating needed resources for it Require that requisite resources be allocated for defect prevention activities Require org. wide implementation of defect prevention activities to improve software, business systems, the processes that make them Require that the results of defect prevention activities be reviewed to ensure that they are effective Require that management & technical action items identified by defect prevention activities be recorded, addressed, tracked to resolution Require 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 Assign responsibility for coordinating defect prevention in the project to a project level counterpart of the SEPG Integrate appropriate responsibility for defect prevention into plans for individual role-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.) 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 KPA execution (activities)

36 Plan defect prevention Prioritize and systematically eliminate causes for defects Seek & Identify common causes of defects Comply with a published procedure in conducting causal analysis meetings Periodically review, coordinate & implement defect prevention actions recommended by causal analysis team; each defect prevention team meets periodically to do this. Record & track defect prevention information across defect prevention teams Plan defect prevention Start every task with a preparatory meeting of those involved in the task to prepare for requisite activities, including those required to prevent defects Identify defect prevention activities Schedule defect prevention activities Assign requisite responsibilities & resources, including staff & tools Peer review the plan Cover the project level process, standards, procedures, methods & relevant tools, emphasizing recent changes Cover resources required (inputs) for the task Cover work products (outputs) of the task, with examples when available 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 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 Record proposed actions of causal analysis meetings Record proposed actions that will be implemented Manage & control defect prevention information Meet soon after completing the task Meet periodically even after the software/system is released for cause-and-effect analysis If too many defects are discovered during the task convene a meeting right away For lengthy tasks, meet periodically to prevent defects even as the task progresses Identify defect prevention recommendations (of causal analysis teams) that will be 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 Consider causes of defects Consider cost of process improvement to remove defects Consider the impact of not addressing defects Consider the impact on process, work products & information quality Comply with a published procedure when amending the standard process to prevent defects Summarized information by kind of 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 Comply with a published procedure to amend the project level process to prevent defects Inform stakeholders (or their representatives - for example, marketing and sales groups may represent customers or users) of the status & results of defect prevention activities Proactively hunt down defects (At Level 1, the norm was reactive crisis management) Go beyond immediate causes & determine why the defect escaped verification procedures, and if other defects might have been similarly missed CAPABILITY LEVEL 5 Continuous Improvement Institutionalized DEFECT PREVENTION Goals: Plan defect prevention Seek & Identify common causes of defects Prioritize and systematically eliminate causes for defects DEFECT PREVENTION ACTIVITIES KPA Execution (activities)

37 CAPABILITY LEVEL 5 Continuous Improvement Institutionalized TECHNOLOGY CHANGE MANAGEMENT Goals: Plan absorption of technological changes. Evaluate the impact of new technology on quality & productivity. Make the right new technologies the norm in the right practices throughout the organization Commitment Ability Assign responsibility for coordinating technology change management to the SEPG Support information gathering & analysis needed to evaluate the impact of changes in technology Plan absorption of technological changes INSTITUTIONALIZING TECHNOLOGY CHANGE MANAGEMENT Make the right new technologies the norm in the right practices throughout the organization Commit to following a published organization wide policy for improving technological capabilities Provide adequate resources & funds for a unit that will coordinate technology change management Assign experienced specialists (Hardware, Work Stations, Networks, programming language, component reuse, CASE, CAPE and metrics specialists, etc.) Provide the right tools and automation (subscriptions [on-line & paper publications], workstations, database & data analysis tools etc.) Evaluate the impact of new technology on quality & productivity Upper management sponsorship of technology improvements Require written objectives for technological changes Require a published plan for changing technology in aligned with the published purpose of the change The unit must coordinate and facilitate technology change A unit within the SEPG could take this responsibility, or it could also be a group that works very closely with the SEPG Upper management oversight of technology improvement Measure & Analyze Monitor Implementation Periodic Upper Management technology change management activity review Track status of technology change management activities Ensure that the process & work product information needed to analyze & evaluate the impact of technology changes & home in on the right technology is available Upper management input and assistance in formulating a strategy to address product quality, productivity & product development cycle time 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 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 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 Automated recording of requisite process & product information Ability to support requisite data analysis The ability to appropriately present (display) selected data & analysis results Train the (SEPG) unit responsible for it, in technology change management QA review/audit of technology change activities & work products Technology Change Management Plan review Technology selection, procurement & installation process review Summarize technology change management activities Identify course corrections & strategy changes Resolve issues that could not be resolved at lower organizational levels Approve revised technology change management plans (if any) KPA execution (activities)

38 Keep management & technical staff informed of new technologies Comply with a published procedure when choosing & acquiring new technology Pilot the technology where appropriate before inducting it as the norm Plan technology change management Identify technology change candidates (processes/areas) in coordination with individual projects & the SEPG unit responsible for technology change management Solicit technology improvement suggestions Identify candidate technologies that might fit Evaluate how well each will fit current & future org. & project needs Disseminate information on new technologies appropriately Disseminate information on advanced technologies in use in different parts of the organization appropriately Disseminate information on the status of technologies being inducted into the organization appropriately 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 Where possible, estimate the life of the replacement or upgrade Consider appropriate pilot technology installations to determine its effectiveness & economic value Analyze the trade off between internal development Vs. external acquisition of the technology; publish & review the analysis Review of technology induction requirements & plans by managers of impacted groups & the SEPG unit responsible for it Comply with a published procedure when inducting new technology into the standard process Comply with a published procedure to induct new technology into the project level process Plan absorption of technological changes Make the right new technologies the norm in the right practices throughout the organization Evaluate the impact of new technology on quality & productivity Role-responsibilities & resource requirements including staff & 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 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 Systematically analyze the standard process; identify where it might benefit from new technology (A SEPG task) Identify points of maximum benefit from induction of new technology into the standard 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 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 Record problems faced & lessons learned Decide on broader use of the technology, termination, continuation or replanning of the pilot Project the impact (& benefits) of broader or large scale use; assess uncertainty & risks inherent in the estimation Concentrate on improving quality, timeliness & productivity Periodically search for, & identify new technology that will support current & future 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 CAPABILITY LEVEL 5 Continuous Improvement Institutionalized TECHNOLOGY CHANGE MANAGEMENT Goals: Plan absorption of technological changes. Evaluate the impact of new technology on quality & productivity. Make the right new technologies the norm in the right practices throughout the organization TECHNOLOGY CHANGE MANAGEMENT ACTIVITIES KPA Execution (activities) Use Pilot projects to test & tune the technology to reduce risk Proactively hunt for technological improvement

39 CAPABILITY LEVEL 5 Continuous Improvement Institutionalized PROCESS CHANGE MANAGEMENT Goals: Plan continuous process improvement. Organization-wide participation in process improvement. Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it Commitment\ Train managers of units involved in software/business systems engineering in the process of process improvement (including the process of software improvement) Plan continuous process improvement INSTITUTIONALIZING PROCESS CHANGE MANAGEMENT Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it Commit to following a published organization wide policy of process improvement, including improving the processes for developing software & business systems Provide adequate resources & funds for process improvement Organization -wide participation in process improvement Upper management sponsorship of process improvement activities Measure & Analyze Monitor Implementation Periodic Upper Management process improvement activity review Track status of process improvement activities Train stakeholders (or their representatives) in the process of process improvement (including the process of software improvement) Recognize skilled & motivated people as the principle resource for process improvement Control, development & dissemination of process 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 Train the upper management in process change management QA review/audit of process improvement activities & work products Upper management articulates long term process improvement objectives & 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 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 Ability 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 activitiesSummarize participation in process improvement activities Assess process performance Identify what changes (if any) are required in process improvement goals or objectives Resolve issues that could not be resolved at lower levels Approve revised process improvement plans (if any) Verify that the process improvement plan is being prepared & followed Verify compliance with the process for initiating, submitting, reviewing & approving process improvement proposals, & planning process improvements Verify how validly process measurements reflect actual performance of the process(es) in question Verify compliance with the process for recording, reviewing, approving, controlling & disseminating changes in the standard process & the project level processes tailored from it. Verify the adequacy, extent & consistency of tracking process improvement activities Verify how well actual improvements in the process (of developing software & business processes) achieves the goals set, & the plans made for it Recognition & reward from sponsors are critical to success KPA execution (activities)

40 Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it Plan process improvement in compliance with the published procedure for it Comply with a published procedure when processing process improvement proposals Secure active participation of individuals in their assigned teams Empower individual members of the organization to improve its processes through a process improvement program Coordinate process improvement through the SEPG Pilot the changed process (where appropriate) before making it the norm Comply with a published procedure when making changed process the norm Plan continuous process improvement Organization- wide participation in process improvement Conform to process improvement plan Fully fund each team; plan & schedule its activities Define clear, and if possible, quantitative goals of each effort Secure approval of plans from SEPG & managers of all impacted groups 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 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 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 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 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 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 Tune the process, and record any changes during the pilot Record problems & lessons learned Estimate impacts proposed changes if made the norm, their benefits& risks & the uncertainty of these estimates Decide on broader deployment of the piloted process & on terminating, continuing or replanning the pilot project Fund & provide all resources needed to change the process 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 process improvement activities Keep records of initiating, implementing & the status of process improvement proposals Provide easy access to these records Keep process improvement histories & report improvement data Inform technical staff & their managers of changes in state and/or the results of process improvement activities when these changes occur A summary of major process improvement activities Significant innovations & actions in process improvement Summary of proposals submitted, open and completed Always change from a stable & controlled base These records chronicle the organization’s adaptability - its cycle times & capacity for change Cross functional teams are key to process improvement; processes often cross organizational & functional boundaries, integrating them to deliver external value CAPABILITY LEVEL 5 Continuous Improvement Institutionalized PROCESS CHANGE MANAGEMENT Goals: Plan continuous process improvement. Organization-wide participation in process improvement. Continuously improve the organization’s standard software/business systems development process, and the project level processes derived from it PROCESS CHANGE MANAGEMENT ACTIVITIES KPA Execution (activities)


Download ppt "Project Management Maturity Model 12/22/14 © 2014 Amit Mitra and Larissa Zhurakovskaya."

Similar presentations


Ads by Google