Developing an Acquisition Centre of Excellence for Effective Sourcing and Supplier Management

2,458 views

Published on

Acquisition skills are necessary to support move from in-sourcing to outsourcing of projects, solutions and services. Effective and appropriate sourcing allows organisations react quickly while reducing costs, ensuring repeatability and improving returns on sourcing activities. Acquisition includes sourcing of suppliers, defining services, awarding contracts to supplier agreements, managing the delivery of contracted services, Getting good at acquisition is a very worthwhile investment for any organisation. Acquisitions skills are essential for implementing sourcing strategy effectively. It ensures consistent and cost-effective outcomes from sourcing activities. Use CMMI for Acquisition maturity model structure to develop an acquisition capability programme. This provides a structured approach with a set of activities and tasks.

Published in: Business, Technology

Developing an Acquisition Centre of Excellence for Effective Sourcing and Supplier Management

  1. 1. Developing an AcquisitionCentre of Excellence forEffective Sourcing and SupplierManagementAlan McSweeney
  2. 2. June 17, 2013 2Importance of Acquisition Skills• Acquisitions skills are essential for implementing sourcingstrategy effectively• Effective and appropriate sourcing allows organisationsreact quickly while reducing costs• Acquisition includes sourcing of suppliers, definingservices, awarding contracts to supplier agreements,managing the delivery of contracted services• Acquisition skills enable effective sourcing and suppliermanagement throughout the entire sourcing lifecycle• Acquisition skills ensure success of project, solution andservice delivery to end-users
  3. 3. June 17, 2013 3Importance of Acquisition Skills• Getting good at acquisition is a very worthwhileinvestment for any organisation• Acquisition skills are necessary to support move from in-sourcing to outsourcing of projects, solutions and services• Allows risks to be managed• Ensures consistent and cost-effective outcomes fromsourcing activities
  4. 4. June 17, 2013 4Managing the Complexity of Acquisition – Sourcingand Supplier Management
  5. 5. June 17, 2013 5Avoiding Sourcing and Supplier ManagementProblemsIneffectiveContractPlanningContractRigidity andInflexibilityIneffectiveContractand ServiceGovernanceHidden,Unforeseenor IgnoredCostsSources ofAcquisitionChallengesandProblems
  6. 6. June 17, 2013 6Designing an Acquisition Capability Programme• Use CMMI for Acquisition maturity model structure todevelop an acquisition capability programme• Provides a structured approach with a set of activities andtasks• Enable management of complexity• Enable repeatability• Reduce cost of acquisition and improve returns onsourcing activities• Get it right first time, all the time
  7. 7. June 17, 2013 7Designing an Acquisition Capability ProgrammeAcquisition TechnicalManagement (ATM)Organisational ProcessPerformance (OPP)Organisational PerformanceManagement (OPM)Acquisition Validation(AVAL)Quantitative ProjectManagement (QPM)Causal Analysis andResolution (CAR)Acquisition Verification(AVER)Organisational ProcessDefinition (OPD)Organisational ProcessFocus (OPF)Organisational Training (OT)Integrated ProjectManagement (IPM)Risk Management (RSKM)Decision Analysis andResolution (DAR)Acquisition RequirementsDevelopment (ARD)Agreement Management(AM)Project Monitoring andControl (PMC)Project Planning (PP)Requirements Management(REQM)Solicitation and SupplierAgreement Development(SSAD)Configuration Management(CM)Measurement and Analysis(MA)Process and Product QualityAssurance (PPQA)Level 1 Skills Level 2 Skills Level 3 Skills Level 4 SkillsAcquisition Skills and Capabilities
  8. 8. June 17, 2013 8Acquisition Excellence Implementation ApproachGoal(s)Practice(s)ProcessesSub-Practice(s)Achieve ProcessCompetencyImplement PracticesImplement Sub-PracticesImplement Goals• Use sub-practices and practices to assess current state of key acquisitioncapabilities and identify gaps• Allows effective decisions to be made on capabilities that need improvementAssess Current Status andAssign ScoreAssess Current Status andAssign ScoreAssign Overall CapabilityStatus ScoreAssess Current Status andAssign Score
  9. 9. June 17, 2013 9Assess Current Status of Key Acquisition CapabilitiesAcquisition TechnicalManagement (ATM)Organisational ProcessPerformance (OPP)Organisational PerformanceManagement (OPM)Acquisition Validation(AVAL)Quantitative ProjectManagement (QPM)Causal Analysis andResolution (CAR)Acquisition Verification(AVER)Organisational ProcessDefinition (OPD)Organisational ProcessFocus (OPF)Organisational Training (OT)Integrated ProjectManagement (IPM)Risk Management (RSKM)Decision Analysis andResolution (DAR)Acquisition RequirementsDevelopment (ARD)Agreement Management(AM)Project Monitoring andControl (PMC)Project Planning (PP)Requirements Management(REQM)Solicitation and SupplierAgreement Development(SSAD)Configuration Management(CM)Measurement and Analysis(MA)Process and Product QualityAssurance (PPQA)Level 1 Skills Level 2 Skills Level 3 Skills Level 4 SkillsAcquisition Skills and CapabilitiesFully/Nearly Fully ImplementedPartially ImplementedNot Implemented
  10. 10. June 17, 2013 10Designing an Acquisition Capability Programme –Implementation ApproachesAcquisition TechnicalManagement (ATM)Organisational ProcessPerformance (OPP)Organisational PerformanceManagement (OPM)Acquisition Validation(AVAL)Quantitative ProjectManagement (QPM)Causal Analysis andResolution (CAR)Acquisition Verification(AVER)Organisational ProcessDefinition (OPD)Organisational ProcessFocus (OPF)Organisational Training (OT)Integrated ProjectManagement (IPM)Risk Management (RSKM)Decision Analysis andResolution (DAR)Acquisition RequirementsDevelopment (ARD)Agreement Management(AM)Project Monitoring andControl (PMC)Project Planning (PP)Requirements Management(REQM)Solicitation and SupplierAgreement Development(SSAD)Configuration Management(CM)Measurement and Analysis(MA)Process and Product QualityAssurance (PPQA)Stage 1 Skills Stage 2 Skills Stage 3 Skills Stage 4 SkillsAcquisition Skills and CapabilitiesPossible Implementation Phase 1Capability AreasPossible Implementation Phase 2Capability AreasPossible Implementation Phase 3Capability Areas
  11. 11. June 17, 2013 11Designing an Acquisition Capability Programme –Implementation Approaches• Define an acquisition capability improvement programmethat will give the best return in the shortest interval
  12. 12. June 17, 2013 12Acquisition Excellence Implementation ApproachGoal(s)Practice(s)ProcessesSub-Practice(s)Achieve ProcessCompetencyImplement PracticesImplement Sub-PracticesImplement Goals• Use sub-practices and practices to define programme ofwork guide the development of capabilities in order toachieve operational effectiveness in acquisition processesDevelop Templatesand ChecklistsDevelop Templatesand ChecklistsDevelop Templatesand ChecklistsDevelop Templatesand Checklists
  13. 13. June 17, 2013 13Example - Acquisition Requirements Development(ARD) – Practices and ActivitiesAnalyse stakeholder needs, expectations, constraints, and external interfaces to organise into related subjects and remove conflictsAnalyse requirements to determine whether they satisfy higher level requirementsAnalyse requirements to ensure that they are complete, feasible, realisable, and verifiableAnalyse and propose the allocation of requirements.Identify key requirements that have a strong influence on cost, schedule, performance, or riskIdentify technical performance measures to be tracked during the acquisitionAnalyse operational concepts and scenarios to refine customer needs, constraints, and interfaces and to discover new requirementsPractice 3.2 -AnalyseRequirementsDevelop operational concepts and scenarios that include operations, installation, maintenance, support and disposal as appropriateDefine the environment in which the product will operate, including boundaries and constraintsReview operational concepts and scenarios to refine and discover requirementsDevelop a detailed operational concept, as candidate solutions are identified and product and product component solutions are selected by the supplier,that defines the interaction of the product, the end user, and the environment, and that satisfies operational, maintenance, support, and disposal needsPractice 3.1 -EstablishOperationalConcepts andScenariosAllocate requirements to supplier deliverablesAllocate design constraints to supplier deliverablesDocument relationships among allocated requirements and design constraintsAllocate requirements to suppliersDevelop an approach to address requirements that by their nature are shared among multiple stakeholders (e.g., the acquirer, multiple suppliers,customers, end usersPractice 2.2 -AllocateContractualRequirementsDevelop functional and quality attribute requirements necessary for the determination of alternative solutions and the development of the product by thesupplierDevelop requirements for the interfaces between the acquired product and other products in the intended environmentDevelop design considerations and constraints necessary for supplier activities that include: determination of alternative solutions, development andevaluation of architectures, and the development of the productDevelop requirements for verification and validation of the product to be developed by the supplierEstablish and maintain relationships among the requirements under consideration during change management and requirements allocationIdentify nontechnical requirementsEstablish and maintain a prioritisation of contractual requirementsPractice 2.1 -EstablishContractualRequirementsTranslate stakeholder needs, expectations, constraints, and interfaces into documented customer requirementsEstablish and maintain a prioritisation of customer functional and quality attribute requirementsDefine constraints for verification and validationPractice 1.2 -Develop andPrioritise CustomerRequirementsEngage relevant stakeholders using methods for eliciting needs, expectations, constraints and external interfacesPractice 1.1 - ElicitStakeholder Needs
  14. 14. June 17, 2013 14Acquisition Centre of Excellence (ACoE)• Develop ACoE to ensure processes are implemented andoperated consistently and effectively
  15. 15. June 17, 2013 15Acquisition Centre of Excellence (ACoE)• Acquisition Issues− No methodology or common practices or approach− Inconsistently defined role of procurement/acquisition− Skill set not sufficient to support implementing a structured acquisition− methodology− Disparate knowledge and experience− Inconsistent implementation and operation− Project failures and problems due to acquisition defects− Short acquisition cycles− Acquisition value hard to measure− Suppliers not being measured and management consistently• Desired State− Robust acquisition methodology has become the way to perform acquisition across theorganisation− Procurement/acquisition role clearly defined and supported through the AcquisitionCentre of Excellence− Procurement/acquisition demonstrating proficiency in key competencies− Cost savings being achieved through appropriate sourcing activities− Consistent approach to sourcing and supplier management
  16. 16. June 17, 2013 16Structure of Acquisition MaturityAcquisitionMaturityMaturity Level 1 Maturity Level 2 Maturity Level NProcess Area 1 Process Area 2 Process Area NProcess 1 Process N Process N Process NProcess 1 Process NGeneric Goals Specific GoalsSpecific PracticesGeneric PracticesSpecific Practice 1 Specific Practice NGeneric Practice 1 Generic Practice NSub-Practice 1.1 Sub-Practice N.1Sub-Practice N.MSub-Practice 1.M
  17. 17. June 17, 2013 17Structure of Acquisition Maturity• Set of maturity levels on an ascending scale− 5 - Optimising process− 4 - Predictable process− 3 - Established process− 2 - Managed process− 1 - Initial process• Each maturity level has a number of process areas/categories/groupings− Maturity is about embedding processes within an organisation• Each process area has a number of processes• Each process has generic and specific goals and practices− Specific goals describes the unique features that must be present to satisfy the processarea− Generic goals apply to multiple process areas− Generic practices are applicable to multiple processes and represent the activitiesneeded to manage a process and improve its capability to perform− Specific practices are activities that are contribute to the achievement of the specificgoals of a process area
  18. 18. June 17, 2013 18Maturity Models Attempt To Measure Maturity OfProcesses And Their Implementation and Operation• Processes breathe life into the organisation• Effective processes enable the organisation to operateefficiently• Good processes enable efficiency and scalability• Processes must be effectively and pervasivelyimplemented• Processes should be optimising, always seekingimprovement where possible• Processes must be embedded within the organisation
  19. 19. June 17, 2013 19Hierarchy of Acquisition Practices, Goals, Processesand Maturity LevelsGoal(s)ProcessesPractice(s)Maturity LevelProcess Contributes ToAchievement OfMaturity LevelDefined Goals Must BeAchieved to EnsureFulfilment of ProcessPractices Contribute tothe Achievement ofGoalsImplement PracticesEvolutionTo GreaterMaturitySub-Practice(s) Implement Sub-Practices
  20. 20. June 17, 2013 20Achieving an Acquisition Maturity LevelGoalProcessPracticeMaturity LevelGoalProcessPracticeMaturity LevelGoalProcessPracticeMaturity LevelImprovementSub-Practice Sub-Practice Sub-Practice
  21. 21. June 17, 2013 21Maturity Levels• Maturity levels are intended to be a way of defining ameans of evolving improvements in processes associatedwith what is being measured
  22. 22. June 17, 2013 22Means of Improving and Measuring Improvements• Staged or continuous− Staged method uses the maturity levels of the overall model tocharacterise the state of an organisation’s processes• Spans multiple process areas• Focuses on overall improvement• Measured by maturity levels− Continuous method focuses on capability levels to characterisethe state of an organisation’s processes for process areas• Looks at individual process areas• Focuses on achieving specific capabilities• Measured by capability levels
  23. 23. June 17, 2013 23Staged and Continuous ImprovementsOptimisingLevel 5Quantitatively ManagedLevel 4DefinedDefinedLevel 3ManagedManagedLevel 2InitialPerformedLevel 1IncompleteLevel 0Staged ImprovementMaturity LevelsContinuous ImprovementCapability LevelsLevel
  24. 24. June 17, 2013 24Continuous Improvement Capability LevelsNot performed or only partially performedSpecific goals of the process area not being satisfiedProcess not embedded in the organisationIncompleteLevel 0Process achieves the required workSpecific goals of the process area are satisfiedPerformedLevel 1Planned and implemented according to policyOperation is monitored, controlled and reviewedEvaluated for adherence to process documentationThose performing the process have required training, skills, resources andresponsibilities to generate controlled deliverablesManagedLevel 2Process consistency maintained through specific process descriptions andprocedures being customised from set of common standard processes usingcustomisation standards to suit given requirementsDefined and documented in detail – roles, responsibilities, measures, inputs,outputs, entry and exit criteriaImplementation and operational feedback compiled in process repositoryProactive process measurement and managementProcess interrelationships definedDefinedLevel 3Key CharacteristicsCapability LevelsLevel
  25. 25. June 17, 2013 25Achieving Capability Levels For Process AreasLevel 0IncompleteLevel 1PerformedLevel 2ManagedLevel 3DefinedProcessesArePerformedPolicies ExistForProcessesProcess ArePlanned AndMonitoredCommonStandardsExist ThatAreCustomisedEnsuringConsistency
  26. 26. June 17, 2013 26Staged Improvement Maturity LevelsAd hoc, inconsistent, unstable, disorganised, not repeatableAny success achieved through individual effortInitialLevel 1Key CharacteristicsMaturityLevelsLevelOptimisingQuantitativelyManagedDefinedManagedEmphasis on continual improvement based on understanding of organisation businessobjectives and performance needsPerformance objectives are continually updated to reflect changing business objectives andorganisational performanceFocus on overall organisational performance and defined feedback loop betweenmeasurement and process changeLevel 5Planned and managedSufficient resources assigned, training provided, responsibilities allocatedLimited performance evaluation and checking of adherence to standardsLevel 2Standardised set of process descriptions and procedures used for creating individual processesDefined and documented in detail – roles, responsibilities, measures, inputs, outputs, entryand exit criteriaProactive process measurement and managementProcess interrelationships definedLevel 3Quantitative objectives defined for quality and process performancePerformance and quality defined and managed throughout the life of the processProcess-specific measures definedPerformance is controlled and predictableLevel 4
  27. 27. June 17, 2013 27Achieving Maturity LevelsLevel 1InitialLevel 2ManagedLevel 3DefinedLevel 4Quantitat-ivelyManagedDisciplinedApproachToProcessesProcesses AreControlledandPredictableCommonStandardsExist That AreCustomisedEnsuringConsistencyStandardApproach ToMeasurementLevel 5OptimisingProcess Linkto OverallOrganisationObjectivesContinual Self-Improvement
  28. 28. June 17, 2013 28Staged Improvement Measurement andRepresentationMaturity ModelMaturity Level 1 Maturity Level 2 Maturity Level NProcess Area 1 Process Area 2 Process Area NProcess 1 Process N Process N Process NProcess 1 Process NGeneric Goals Specific GoalsSpecific PracticesGeneric PracticesSpecific Practice 1Specific PracticeNGeneric Practice 1Generic PracticeNSub-Practice 1.1 Sub-Practice 1.M Sub-Practice N.1 Sub-Practice N.MSeeks to Gauge OverallOrganisation Maturity Across AllProcess Areas
  29. 29. June 17, 2013 29Maturity Model• To be at MaturityLevel N meansthat all processesin previousmaturity levelshave beenimplementedMaturityModelMaturityLevel 1MaturityLevel 2MaturityLevel 3MaturityLevel 4MaturityLevel 5Process 2.1Process 2.2Process 3.1Process 3.2Process 3.3Process 2.3Process 4.1Process 4.2Process 4.3Process 4.4Process 2.4Process 5.1Process 5.2
  30. 30. June 17, 2013 30Achieving Maturity LevelsLevel 1InitialLevel 2ManagedLevel 3DefinedLevel 4Quantitat-ivelyManagedLevel 5OptimisingProcessProcessProcessProcessProcessProcessProcessProcessProcessProcessProcessProcessProcessProcessProcess ProcessProcess Process+++Process ProcessProcessProcess
  31. 31. June 17, 2013 31Continuous Improvement Measurement andRepresentationMaturity ModelMaturity Level 1 Maturity Level 2 Maturity Level NProcess Area 1 Process Area 2 Process Area NProcess 1 Process N Process N Process NProcess 1 Process NGeneric Goals Specific GoalsSpecific PracticesGeneric PracticesSpecific Practice1Specific PracticeNGeneric Practice1Generic PracticeNSeeks to GaugeThe Condition OfOne Or MoreIndividualProcess Areas
  32. 32. June 17, 2013 32Basis for Maturity Models• Greater process maturity should mean greater businessbenefit(s)− Reduced cost− Greater efficiency− Reduced risk
  33. 33. June 17, 2013 33Key Acquisition Processes and Capabilities• Agreement Management• Acquisition RequirementsDevelopment• Configuration Management• Measurement and Analysis• Project Monitoring and Control• Project Planning• Process and Product QualityAssurance• Requirements Management• Solicitation and Supplier AgreementDevelopment• Acquisition Technical Management• Acquisition Validation• Acquisition Verification• Decision Analysis and Resolution• Integrated Project Management• Organisational Process Definition• Organisational Process Focus• Organisational Training• Risk Management• Organisational Process Performance• Quantitative Project Management• Causal Analysis and Resolution• Organisational PerformanceManagement
  34. 34. June 17, 2013 34Process Areas Within Acquisition Maturity ModelAcquisition Maturity ModelMaturity Level 2 Maturity Level 3 Maturity Level 4 Maturity Level 5Acquisition RequirementsDevelopment (ARD)Agreement Management(AM)Acquisition TechnicalManagement (ATM)Acquisition Validation(AVAL)Acquisition Verification(AVER)Project Monitoring andControl (PMC)Organisational ProcessPerformance (OPP)Quantitative ProjectManagement (QPM)Project Planning (PP)OrganisationalPerformance Management(OPM)Causal Analysis andResolution (CAR)RequirementsManagement (REQM)Solicitation and SupplierAgreement Development(SSAD)Configuration Management(CM)Measurement and Analysis(MA)Process and ProductQuality Assurance (PPQA)Organisational ProcessDefinition (OPD)Organisational ProcessFocus (OPF)Organisational Training(OT)Integrated ProjectManagement (IPM)Risk Management (RSKM)Decision Analysis andResolution (DAR)
  35. 35. June 17, 2013 35Acquisition Process Groupings and RelationshipsConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  36. 36. June 17, 2013 36Acquisition Process Groupings and Relationships –Maturity Level 2ConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  37. 37. June 17, 2013 37Acquisition Process Groupings and Relationships –Maturity Level 3ConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  38. 38. June 17, 2013 38Acquisition Process Groupings and Relationships –Maturity Level 4ConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  39. 39. June 17, 2013 39Acquisition Process Groupings and Relationships –Maturity Level 5ConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)OrganisationalTraining (OT)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)
  40. 40. June 17, 2013 40Acquisition Project Processes Grouping• Contains processes and associated practices relating to activitiesconcerned with to establishing, executing, and ensuring thetransition of an acquisition project− Project Planning (PP)− Requirements Management (REQM)− Solicitation and Supplier Agreement Development (SSAD)− Agreement Management (AM)− Project Monitoring and Control (PMC)− Integrated Project Management (IPM)− Risk Management (RSKM)− Acquisition Requirements Development (ARD)− Acquisition Technical Management (ATM)− Acquisition Verification (AVER)− Acquisition Validation (AVAL)
  41. 41. June 17, 2013 41Acquisition Organisational Processes Grouping• Consists of cross-project activities related to defining,planning, deploying, implementing, monitoring,controlling, appraising, measuring and improvingprocesses− Organisational Process Definition (OPD)− Organisational Process Focus (OPF)− Organisational Training (OT)
  42. 42. June 17, 2013 42Acquisition Support Processes Grouping• Provide support functions that help implement genericpractices and assist processes and work productsdescribed in more than one other process areas− Configuration Management (CM)− Decision Analysis and Resolution (DAR)− Measurement and Analysis (MA)− Process and Product Quality Assurance (PPQA)
  43. 43. June 17, 2013 43Acquisition High Maturity Processes Grouping• Process that include practices that align organisational,project and support processes with the business objectives• Concerned with setting-up objectives for quality andprocess performance, monitoring variation in processes,evaluating the impacts of proposed process changes, andsystematically deploying processes across the organisation• To effectively implement these practices, maturemeasurement and analysis processes are needed− Organisational Process Performance (OPP)− Quantitative Project Management (QPM)− Causal Analysis and Resolution (CAR)− Organisational Performance Management (OPM)
  44. 44. June 17, 2013 44Acquisition Process Groupings and Relationships –Maturity Level 2 – Key Process Skill Areas• Acquisition Requirements Development (ARD)• Agreement Management (AM)• Project Monitoring and Control (PMC)• Project Planning (PP)• Requirements Management (REQM)• Solicitation and Supplier Agreement Development (SSAD)• Configuration Management (CM)• Measurement and Analysis (MA)• Process and Product Quality Assurance (PPQA)
  45. 45. June 17, 2013 45Process - Acquisition Requirements Development(ARD) - Overview• Elicit, develop, and analyse customer and contractual requirements• Requirements are the basis for the selection and design orconfiguration of the acquired product or service− Customer requirements - address the needs of relevant stakeholders for whichproducts and services will be acquired− Contractual requirements - addressed through the acquirer’s relationship withsuppliers and other relevant organisations• Requirements included in the solicitation package form the basis forevaluating proposals by suppliers and for further negotiations withsuppliers and communication with the customer• Contractual requirements for the supplier are baselined in thesupplier agreement
  46. 46. June 17, 2013 46Process - Acquisition Requirements Development(ARD) - Overview• Development of requirements includes− Elicitation, analysis, and validation of stakeholder needs, expectations,constraints, and interfaces to establish customer requirements that constitutean understanding of what will satisfy stakeholders− Development of the lifecycle requirements of the product or service− Establishment of contractual requirements consistent with customerrequirements to a level of detail that is sufficient to be included in thesolicitation package and supplier agreement− Development of the operational concept− Analysis of needs and requirements, the operational environment, and factorsthat reflect overall customer and end-user needs and expectations for quality− Identification of quality attributes - non-functional properties of a product orservice (e.g., responsiveness, availability, security) and are critical to customersatisfaction and to meeting the needs of relevant stakeholders
  47. 47. June 17, 2013 47Process - Acquisition Requirements Development(ARD) - Overview• Requirements are refined throughout the project lifecycle• Design decisions, subsequent corrective actions, andfeedback during each phase of the project’s lifecycle areanalysed for their impact on contractual requirements• Involvement of relevant stakeholders in both requirementsdevelopment and analyses gives them visibility into theevolution of requirements• Participation continually assures stakeholders thatrequirements are being properly defined
  48. 48. June 17, 2013 48Acquisition Requirements Development (ARD)AcquisitionMaturityModelMaturityLevel 2AcquisitionRequirementsDevelopment(ARD)AgreementManagement(AM)ProjectMonitoringand Control(PMC)ProjectPlanning (PP)RequirementsManagement(REQM)Solicitationand SupplierAgreementDevelopment(SSAD)ConfigurationManagement(CM)Measurementand Analysis(MA)Goal 1 -SatisfySupplierAgreementsPractice 1.1 -ElicitStakeholderNeedsPractice 1.2 -Develop andPrioritiseCustomerRequirementsGoal 2 -DevelopContractualRequirementsGoal 3 -Analyse andValidateRequirementsPractice 2.1 -EstablishContractualRequirementsPractice 2.2 -AllocateContractualRequirementsPractice 3.1 -EstablishOperationalConcepts andScenariosPractice 3.2 -AnalyseRequirementsPractice 3.3 -AnalyseRequirementsto AchieveBalancePractice 3.4 -ValidateRequirementsProcess andProductQualityAssurance(PPQA)
  49. 49. June 17, 2013 49Acquisition Requirements Development (ARD) -Related Process AreasConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  50. 50. June 17, 2013 50Acquisition Requirements Development (ARD) -Specific Goals and Practices• Goal 1 - Develop Customer Requirements− Practice 1.1 - Elicit Stakeholder Needs− Practice 1.2 - Develop and Prioritise Customer Requirements• Goal 2 - Develop Contractual Requirements− Practice 2.1 - Establish Contractual Requirements− Practice 2.2 - Allocate Contractual Requirements• Goal 3 - Analyse and Validate Requirements− Practice 3.1 - Establish Operational Concepts and Scenarios− Practice 3.2 - Analyse Requirements− Practice 3.3 - Analyse Requirements to Achieve Balance− Practice 3.4 - Validate Requirements
  51. 51. June 17, 2013 51Goal 1 - Develop Customer Requirements• Gather stakeholder needs, expectations, constraints and interfacesand translate into customer requirements• Requirements are derived from the needs of stakeholders (e.g.,customers, end users, suppliers, testers, integrators, maintainers,operators, supplier agreement management staff, manufacturers,support staff)• Analyse, harmonise, refine and elaborate needs, expectations,constraints, interfaces, operational concepts, and product conceptsand translate into a set of customer requirements• Often stakeholder needs, expectations, constraints, and interfacesare poorly identified or conflicting• Since these needs, expectations, constraints and interfaces need tobe clearly identified and understood throughout the projectlifecycle, an iterative process is frequently used throughout the lifeof the project to accomplish this objective
  52. 52. June 17, 2013 52Practice 1.1 - Elicit Stakeholder Needs• Scope− Elicit stakeholder needs, expectations, constraints and interfacesfor all phases of the solution lifecycle− Eliciting goes beyond collecting needs by proactively identifyingadditional needs not explicitly provided by stakeholders− Include business as well as technical functions− Use analysis of business processes to provide a source ofstakeholder needs, expectations, constraints, and interfaces
  53. 53. June 17, 2013 53Practice 1.1 - Elicit Stakeholder Needs• Work Products− Stakeholder needs, expectations,constraints, and interfaces• Subpractices− Engage relevant stakeholders usingmethods for eliciting needs,expectations, constraints andexternal interfaces
  54. 54. June 17, 2013 54Practice 1.2 - Develop and Prioritise CustomerRequirements• Scope− Transform stakeholder needs, expectations, constraints, andinterfaces into prioritised customer requirements− Customer typically describes requirements as capabilitiesexpressed in broad operational terms concerned with achieving adesired effect under specified standards and regulations− Requirements can also include needs, expectations, constraintsand interfaces with regard to verification and validation− Inputs from the customer and other stakeholders should bealigned to the acquisition strategy− Missing information should be obtained and conflicts should beresolved
  55. 55. June 17, 2013 55Practice 1.2 - Develop and Prioritise CustomerRequirements• Work Products− Prioritised customer requirements− Customer constraints on theconduct of verification− Customer constraints on theconduct of validation• Subpractices− Translate stakeholder needs,expectations, constraints, andinterfaces into documentedcustomer requirements− Establish and maintain aprioritisation of customerfunctional and quality attributerequirements− Define constraints for verificationand validation
  56. 56. June 17, 2013 56Goal 2 - Develop Contractual Requirements• Analyse customer requirements in conjunction with thedevelopment of the operational concept to derive more detailed andprecise sets of requirements, called contractual requirements, to beincluded in the solicitation package for potential suppliers andeventually in the supplier agreement• Level of detail of contractual requirements is based on theacquisition strategy and project characteristics• Contractual requirements arise from constraints, consideration ofissues implied but not explicitly stated in the customer requirementsbaseline and factors introduced by design constraints and suppliercapabilities• Requirements are allocated to supplier deliverables
  57. 57. June 17, 2013 57Practice 2.1 - Establish Contractual Requirements• Scope− Customer requirements can be expressed in the customer’s termsand can be nontechnical descriptions− Contractual requirements are the expression of theserequirements in technical terms that can be used for designdecisions− Contractual requirements cover nontechnical stakeholder needs,expectations, constraints and interfaces
  58. 58. June 17, 2013 58Practice 1.2 - Develop and Prioritise CustomerRequirements• Work Products− External interface requirements− Prioritised contractual requirements• Subpractices− Develop functional and quality attributerequirements necessary for thedetermination of alternative solutions andthe development of the product by thesupplier− Develop requirements for the interfacesbetween the acquired product and otherproducts in the intended environment− Develop design considerations andconstraints necessary for supplier activitiesthat include: determination of alternativesolutions, development and evaluation ofarchitectures, and the development of theproduct− Develop requirements for verification andvalidation of the product to be developedby the supplier− Establish and maintain relationships amongthe requirements under considerationduring change management andrequirements allocation− Identify nontechnical requirements− Establish and maintain a prioritisation ofcontractual requirements
  59. 59. June 17, 2013 59Practice 2.2 - Allocate Contractual Requirements• Scope− Customer requirements can be expressed in the customer’s termsand can be nontechnical descriptions− Contractual requirements are the expression of theserequirements in technical terms that can be used for designdecisions− Contractual requirements cover nontechnical stakeholder needs,expectations, constraints and interfaces
  60. 60. June 17, 2013 60Practice 2.2 - Allocate Contractual Requirements• Work Products− Requirement allocation sheets• Subpractices− Allocate requirements to supplierdeliverables− Allocate design constraints tosupplier deliverables− Document relationships amongallocated requirements and designconstraints− Allocate requirements to suppliers− Develop an approach to addressrequirements that by their natureare shared among multiplestakeholders (e.g., the acquirer,multiple suppliers, customers, endusers)
  61. 61. June 17, 2013 61Goal 3 - Analyse and Validate Requirements• Perform analysis to determine the impact the intended operationalenvironment will have on the ability to satisfy stakeholder needs,expectations, constraints and interfaces• Determine candidate requirements for solution concepts that willsatisfy stakeholder needs, expectations, constraints and interfaces• Translate these concepts into requirements• Determine the parameters to be used to evaluate the effectivenessof the solution based on customer input and the preliminary productconcept• Validate requirements increase the probability that the resultingsolution will perform as intended in the acquirer’s intendedenvironment
  62. 62. June 17, 2013 62Practice 3.1 - Establish Operational Concepts andScenarios• Scope− Establish and maintain operational concepts and associated scenarios− Operational concepts and scenarios can assist in the elicitation of needs andthe analysis and refinement of requirements− Can be further refined as solution decisions are made and more detailedrequirements are developed− Operational concepts are overall descriptions of the problems to be solved inoperational terms and the ways in which the products to be acquired areintended to be used or operated, deployed, supported (including maintenanceand sustainment) and disposed− Scenarios are descriptions of a sequence of events that might occur in the use,transition or sustainment of the product to be acquired and makes explicitsome stakeholder functionality and quality attribute needs
  63. 63. June 17, 2013 63Practice 3.1 - Establish Operational Concepts andScenarios• Work Products− Operational, maintenance, support,and disposal concepts− Use cases, user stories− New requirements• Subpractices− Develop operational concepts andscenarios that include operations,installation, maintenance, support anddisposal as appropriate− Define the environment in which theproduct will operate, includingboundaries and constraints− Review operational concepts andscenarios to refine and discoverrequirements− Develop a detailed operationalconcept, as candidate solutions areidentified and product and productcomponent solutions are selected bythe supplier, that defines theinteraction of the product, the enduser, and the environment, and thatsatisfies operational, maintenance,support, and disposal needs
  64. 64. June 17, 2013 64Practice 3.2 - Analyse Requirements• Scope− Analyse requirements to ensure they are necessary and sufficient− As contractual requirements are defined, their relationship tocustomer requirements should be understood− In light of the operational concepts and scenarios, the contractualrequirements are analysed to determine whether they arenecessary and sufficient to meet customer requirements
  65. 65. June 17, 2013 65Practice 3.2 - Analyse Requirements• Work Products− Requirements defects reports− Proposed requirements changes toresolve defects− Key requirements− Technical performance measures• Subpractices− Analyse stakeholder needs,expectations, constraints, and externalinterfaces to organise into relatedsubjects and remove conflicts− Analyse requirements to determinewhether they satisfy higher levelrequirements− Analyse requirements to ensure thatthey are complete, feasible, realisable,and verifiable− Analyse and propose the allocation ofrequirements.− Identify key requirements that have astrong influence on cost, schedule,performance, or risk− Identify technical performancemeasures to be tracked during theacquisition− Analyse operational concepts andscenarios to refine customer needs,constraints, and interfaces and todiscover new requirements
  66. 66. June 17, 2013 66Practice 3.3 - Analyse Requirements to AchieveBalance• Scope− Analyse requirements to balance stakeholder needs andconstraints− Analyse requirements to determine whether they reflect anappropriate balance among cost, schedule, performance andother factors of interest to relevant stakeholders− If the risks are considered unacceptable, the requirements can berevised or reprioritised to improve the balance of cost, schedule,and performance
  67. 67. June 17, 2013 67Practice 3.3 - Analyse Requirements to AchieveBalance• Work Products− Assessment of risks related torequirements− Proposed requirements changes• Subpractices− Use proven models, simulations,and prototyping to analyse thebalance of stakeholder needs andconstraints− Perform a risk assessment onrequirements and designconstraints− Examine product lifecycle conceptsfor impacts of requirements onrisks.− Perform a cost benefit analysis toassess impact of the requirementson the overall acquisition strategyand acquisition project costs andrisks
  68. 68. June 17, 2013 68Practice 3.4 - Validate Requirements• Scope− Validate requirements to ensure the resulting product performsas intended in the end user’s environment− Validate requirements early in the acquisition with end users ortheir representatives to gain confidence that the requirementsare capable of guiding a development that results in successfulfinal validation− Integrate with risk management activities
  69. 69. June 17, 2013 69Practice 3.4 - Validate Requirements• Work Products− Records of analysis methods andresults• Supplier Deliverables− Requirements and validation methods(e.g., prototypes, simulations)• Subpractices− Analyse the requirements todetermine the risk that the resultingproduct will not perform appropriatelyin its intended-use environment− Explore the adequacy andcompleteness of requirements bydeveloping product representations(e.g., prototypes, simulations, models,scenarios, storyboards) and byobtaining feedback about them fromrelevant stakeholders− Assess product and productcomponent solutions as they aredeveloped by the supplier in thecontext of the validation environmentto identify issues and expose unstatedneeds and customer requirements
  70. 70. June 17, 2013 70Process - Agreement Management (AM) - Overview• Purpose− To ensure that the supplier and the acquirer perform according tothe terms of the supplier agreement• Activities− Executing the supplier agreement− Monitoring supplier processes− Accepting the delivery of acquired products− Managing supplier invoices
  71. 71. June 17, 2013 71Agreement Management (AM)AcquisitionMaturity ModelMaturity Level 2AcquisitionRequirementsDevelopment(ARD)AgreementManagement(AM)ProjectMonitoring andControl (PMC)Project Planning(PP)RequirementsManagement(REQM)Solicitation andSupplierAgreementDevelopment(SSAD)ConfigurationManagement(CM)Measurementand Analysis(MA)Process andProduct QualityAssurance(PPQA)Goal 1 - SatisfySupplierAgreementsPractice 1.1 -Execute theSupplierAgreementPractice 1.2 -MonitorSelectedSupplierProcessesPractice 1.3 -Accept theAcquiredProductPractice 1.4 -ManageSupplierInvoices
  72. 72. June 17, 2013 72Agreement Management (AM) - Related ProcessAreasConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  73. 73. June 17, 2013 73Agreement Management (AM) - Related ProcessAreas• Acquisition Technical Management (ATM) – evaluatetechnical solutions• Acquisition Validation (AV) - validate selected productsand product components.• Measurement and Analysis (MA) - specify measures andcommunicating results.• Project Monitoring and Control (PMC) - monitor theproject against the plan and taking corrective action• Solicitation and Supplier Agreement Development (SSAD) -establish supplier agreements
  74. 74. June 17, 2013 74Agreement Management (AM) - Specific Goals andPractices• Goal 1 - Satisfy Supplier Agreements− Practice 1.1 - Execute the Supplier Agreement− Practice 1.2 - Monitor Selected Supplier Processes− Practice 1.3 - Accept the Acquired Product− Practice 1.4 - Manage Supplier Invoices
  75. 75. June 17, 2013 75Practice 1.1 - Execute the Supplier Agreement• Scope− Covers internal and external communication as well as the use ofinformation by the acquirer and supplier regarding therelationship, performance, results, and impact to the business− Acquirer manages the relationship with the supplier to maintaineffective communication on key issues (e.g., changes in theacquirer’s business), new supplier products and technologies, andchanges in the organisational structure
  76. 76. June 17, 2013 76Practice 1.1 - Execute the Supplier Agreement• Work Products− Integrated list of issues− Acquisition project progress andperformance reports− Supplier review materials and reports− Action items tracked to closure− Records of product and documentdeliveries• Supplier Deliverables− Supplier project progress andperformance reports− Corrective action results for supplierissues− Correspondence with the acquirer• Subpractices− Monitor supplier project progress andperformance (e.g., schedule, effort,cost) as defined in the supplieragreement− Conduct management reviews withthe supplier as specified in the supplieragreement− Identify issues and determinecorrective actions necessary to resolveand track them to closure− Use the results of reviews to improvethe supplier’s performance and toestablish and nurture long-termrelationships with preferred suppliers− Monitor risks involving the supplierand take corrective action as necessary
  77. 77. June 17, 2013 77Practice 1.2 - Monitor Selected Supplier Processes• Scope− Acquirer monitoring of supplier and acquirer processes to ensurealignment and help prevent interface problems.− Selection of processes for monitoring based on the likely impactof the supplier’s processes on the project− Overall risk should be considered when selecting processes to bemonitored
  78. 78. June 17, 2013 78Practice 1.2 - Monitor Selected Supplier Processes• Work Products− List of processes selected formonitoring or rationale for non-selection− Activity reports− Process performance reports− Process performance curves− Discrepancy reports• Supplier Deliverables− Supplier process quality assurancereports• Subpractices− Identify supplier processes criticalto the success of the project− Monitor selected supplierprocesses for compliance withrequirements of the agreement− Analyse results of monitoringselected processes to detect issuesas early as possible that may affectthe supplier’s ability to satisfyrequirements of the agreement
  79. 79. June 17, 2013 79Practice 1.3 - Accept the Acquired Product• Scope− Ensure that the acquired product meets all requirements and thatcustomers agree before acceptance of the product− Ensure that all acceptance criteria have been satisfied and that alldiscrepancies have been corrected or otherwise addressed− Exercise remedies if the supplier fails to perform− Provide the supplier with formal written notice that supplierdeliverables have been accepted or rejected− Acquirer assumes ownership of existing identified supplierproducts or deliverables or approves services− Ensure transition to operations and provision of support in thetransition to operations and support
  80. 80. June 17, 2013 80Practice 1.3 - Accept the Acquired Product• Work Products− Stakeholder approval reports− Discrepancy reports− Product acceptance review report withapproval signatures• Supplier Deliverables− Work products as defined in thesupplier agreement− Services as defined in the supplieragreement• Subpractices− Review the validation results, reports,logs, and issues for the acquiredproduct− Review supplier verification results,reports, logs, and issues for theacquired product− Confirm that all contractualrequirements for the acquired productare satisfied− Confirm that all discrepancies havebeen corrected and all acceptancecriteria have been satisfied− Communicate to relevant stakeholdersthat the supplier agreement has beensatisfied− Communicate to relevant stakeholdersthe product’s readiness for transitionto operations and support
  81. 81. June 17, 2013 81Practice 1.4 - Manage Supplier Invoices• Scope− Ensure that payment terms defined in the supplier agreement aremet− Ensure that supplier compensation is linked to supplier progressas defined in the supplier agreement− Ensure that final payment should not be made to the supplieruntil it has been certified that all supplier deliverables meetcontractual requirements and all acceptance criteria have beensatisfied
  82. 82. June 17, 2013 82Practice 1.4 - Manage Supplier Invoices• Work Products− Invoices approved for payment• Supplier Deliverables− Invoices• Subpractices− Receive invoices− Review invoices and relatedsupporting material− Resolve errors and manage issueswith the supplier as required− Approve invoices
  83. 83. June 17, 2013 83Process – Project Monitoring and Control (PMC) -Overview• Provide an understanding of the project’s progress so that appropriate correctiveactions can be taken when the project’s performance deviates significantly fromthe plan• Project plan is the basis for monitoring activities, communicating status, andtaking corrective action• Progress is primarily determined by comparing actual work product and taskattributes, effort, cost, and schedule to the plan• Monitoring and control functions are established early in the project as theproject’s planning is performed and the acquisition strategy is defined• As the acquisition of technology solutions unfolds, monitoring and controlactivities are essential to ensure that appropriate resources are being applied andthat acquirer activities are progressing according to plan• Aupplier project progress and performance reporting requirements areestablished in the supplier agreement consistent with the needs of the project
  84. 84. June 17, 2013 84Process – Project Monitoring and Control (PMC)AcquisitionMaturityModelMaturity Level2AcquisitionRequirementsDevelopment(ARD)AgreementManagement(AM)ProjectMonitoringand Control(PMC)ProjectPlanning (PP)RequirementsManagement(REQM)Solicitationand SupplierAgreementDevelopment(SSAD)ConfigurationManagement(CM)Measurementand Analysis(MA)Process andProductQualityAssurance(PPQA)Goal 1 -Monitor theProject Againstthe PlanGoal 2 -ManageCorrectiveAction toClosurePractice 1.1 -MonitorProjectPlanningParametersPractice 2.1 -Analyse IssuesPractice 1.2 -MonitorCommitmentsPractice 1.3 -MonitorProject RisksPractice 1.4 -Monitor DataManagementPractice 1.5 -MonitorStakeholderInvolvementPractice 1.6 -ConductProgressReviewsPractice 1.7 -ConductMilestoneReviewsPractice 1.8 -MonitorTransition toOperationsand SupportPractice 2.2 -TakeCorrectiveActionPractice 2.3 -ManageCorrectiveActions
  85. 85. June 17, 2013 85Process – Project Monitoring and Control (PMC) -Related Process AreasConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  86. 86. June 17, 2013 86Project Monitoring and Control (PMC) - SpecificGoals and Practices• Goal 1 - Monitor the Project Against the Plan− Practice 1.1 - Monitor Project Planning Parameters− Practice 1.2 - Monitor Commitments− Practice 1.3 - Monitor Project Risks− Practice 1.4 - Monitor Data Management− Practice 1.5 - Monitor Stakeholder Involvement− Practice 1.6 - Conduct Progress Reviews− Practice 1.7 - Conduct Milestone Reviews− Practice 1.8 - Monitor Transition to Operations and Support• Goal 2 - Manage Corrective Action to Closure− Practice 2.1 - Analyse Issues− Practice 2.2 - Take Corrective Action− Practice 2.3 - Manage Corrective Actions
  87. 87. June 17, 2013 87Goal 1 - Monitor the Project Against the Plan• Monitor actual project progress and performance againstthe project plan• Acquirer is responsible for monitoring the progress andoutput of the project• After a supplier is selected and a supplier agreement put inplace, the acquirer’s monitoring and control activitiesextend to the supplier and its activities• Acquirer monitors supplier progress, includingachievement of requirements established in the supplieragreement and using specified process, product, andservice level measures
  88. 88. June 17, 2013 88Practice 1.1 - Monitor Project Planning Parameters• Scope− Monitor actual values of project planning parameters against theproject plan− Involves measuring actual values of project planning parameters,comparing actual values to estimates in the plan, and identifyingsignificant deviations
  89. 89. June 17, 2013 89Practice 1.1 - Monitor Project Planning Parameters• Work Products− Records of project performance− Cost performance reports• Supplier Deliverables− Supplier project progress andperformance reports− Records of significant deviations− Cost performance reports• Subpractices− Monitor progress against theschedule− Monitor the project’s costs andexpended effort− Monitor the attributes of workproducts and tasks− Monitor resources provided andused− Monitor the knowledge and skillsof project staff− Document significant deviations inproject planning parameters
  90. 90. June 17, 2013 90Practice 1.2 - Monitor Commitments• Scope− Monitor commitments against those identified in the project plan
  91. 91. June 17, 2013 91Practice 1.2 - Monitor Commitments• Work Products− Records of commitment reviews• Subpractices− Regularly review commitments(both external and internal)− Identify commitments that havenot been satisfied or are atsignificant risk of not beingsatisfied− Document the results ofcommitment reviews
  92. 92. June 17, 2013 92Practice 1.3 - Monitor Project Risks• Scope− Monitor risks against those identified in the project plan− Acquirer monitors the overall project risk− Internal risks not be shared with the supplier• Source selection sensitive, re-competition, internal staffing)− Shared risks that require coordination with suppliers
  93. 93. June 17, 2013 93Practice 1.3 - Monitor Project Risks• Work Products− Records of project risk monitoring• Supplier Deliverables− Records of supplier risk monitoring• Subpractices− Periodically review thedocumentation of risks in thecontext of the project’s currentstatus and circumstances− Revise the documentation of risksas additional information becomesavailable− Communicate the risk status torelevant stakeholders
  94. 94. June 17, 2013 94Practice 1.4 - Monitor Data Management• Scope− Monitor the management of project data against the project plan− Ensure that data management requirements are being satisfied− May be necessary to re-plan the project’s data managementactivities
  95. 95. June 17, 2013 95Practice 1.4 - Monitor Data Management• Work Products− Records of data management• Supplier Deliverables− Records of supplier datamanagement• Subpractices− Periodically review datamanagement activities againsttheir description in the projectplan− Identify and document significantissues and their impacts− Document results of datamanagement activity reviews
  96. 96. June 17, 2013 96Practice 1.5 - Monitor Stakeholder Involvement• Scope− Monitor stakeholder involvement against the project plan− Ensure appropriate interactions occur− Involvement of owners, acquirers, and customers of othersystems in the system of systems is crucial to the success of thesolution
  97. 97. June 17, 2013 97Practice 1.5 - Monitor Stakeholder Involvement• Work Products− Records of stakeholderinvolvement• Supplier Deliverables− Records of supplier involvement• Subpractices− Periodically review the status ofstakeholder involvement− Identify and document significantissues and their impacts− Document the results ofstakeholder involvement statusreviews
  98. 98. June 17, 2013 98Practice 1.6 - Conduct Progress Reviews• Scope− Periodically review the project’s progress, performance, andissues− Determine if there are significant issues or performance shortfallsthat need to be addressed− Keep relevant stakeholders informed
  99. 99. June 17, 2013 99Practice 1.6 - Conduct Progress Reviews• Work Products− Documented project review results• Supplier Deliverables− Supplier project progress andperformance reports− Supplier review materials andreports− Documentation of product anddocument deliveries• Subpractices− Regularly communicate status onassigned activities and workproducts to relevant stakeholders− Review the results of collectingand analyzing measures forcontrolling the project− Identify and document significantissues and deviations from theplan− Document change requests andproblems identified in workproducts and processes− Document the results of reviews− Track change requests andproblem reports to closure
  100. 100. June 17, 2013 100Practice 1.7 - Conduct Milestone Reviews• Scope− Review the project’s accomplishments and results at selectedproject milestones− Milestones are pre-planned events or points in time at which athorough review of status is conducted to understand how wellstakeholder requirements are being met
  101. 101. June 17, 2013 101Practice 1.7 - Conduct Milestone Reviews• Work Products− Documented milestone reviewresults• Supplier Deliverables− Documented measurement results− Measurement analysis reports• Subpractices− Conduct milestone reviews withrelevant stakeholders atmeaningful points in the project’sschedule, such as the completionof selected phases− Review commitments, the plan,status, and risks of the project− Identify and document significantissues and their impacts− Document results of the review,action items, and decisions− Track action items to closure
  102. 102. June 17, 2013 102Practice 1.8 - Monitor Transition to Operations andSupport• Scope− Acquirer monitors and controls the transition of the acceptedproduct or service against the plan for transition to operationsand support
  103. 103. June 17, 2013 103Practice 1.8 - Monitor Transition to Operations andSupport• Work Products− Transition readiness report− Records of transition to supportreviews− Transition analysis report• Supplier Deliverables− Training materials and supportingartifacts− Site readiness report− Verification reports− Training records− Operational readiness reports− Test results− Pilot results• Subpractices− Monitor the operations andsupport organisation’s capabilityand facilities designated to receive,store, use, and maintain acquiredproducts− Monitor the delivery of training forthose who are involved inreceiving, storing, using, andmaintaining acquired products− Review pilot results, if any, andoperational readiness reports forthe acquired product− Review and analyse the results oftransition activities
  104. 104. June 17, 2013 104Goal 2 - Manage Corrective Action to Closure• Manage corrective actions to closure when the project’sperformance or results deviate significantly from the plan• When the acquirer determines that supplier progress doesnot appear to be sufficient to meet a service level definedin the supplier agreement, then the acquirer initiates andmanages corrective action with the supplier
  105. 105. June 17, 2013 105Practice 2.1 - Analyse Issues• Scope− Collect and analyse issues and determine corrective actions toaddress them− Corrective action is taken for both acquirer deviations and whensupplier execution does not align with project planning
  106. 106. June 17, 2013 106Practice 2.1 - Analyse Issues• Work Products− List of issues requiring correctiveactions• Supplier Deliverables− List of supplier issues needingcorrective action by the acquirer• Subpractices− Gather issues for analysis− Analyse issues to determine theneed for corrective action
  107. 107. June 17, 2013 107Practice 2.2 - Take Corrective Action• Scope− Take corrective action on identified issues
  108. 108. June 17, 2013 108Practice 2.2 - Take Corrective Action• Work Products− Corrective action plans• Supplier Deliverables− Corrective action plans for supplierissues• Subpractices− Determine and document theappropriate actions needed toaddress identified issues− Review and get agreement withrelevant stakeholders on theactions to be taken− Negotiate changes to internal andexternal commitments
  109. 109. June 17, 2013 109Practice 2.3 - Manage Corrective Actions• Scope− Manage corrective actions to closure
  110. 110. June 17, 2013 110Practice 2.3 - Manage Corrective Actions• Work Products− Corrective action results• Supplier Deliverables− Corrective action results forsupplier issues• Subpractices− Monitor corrective actions fortheir completion− Analyse results of correctiveactions to determine theeffectiveness of the correctiveactions− Determine and documentappropriate actions to correctdeviations from planned resultsfrom performing corrective actions
  111. 111. June 17, 2013 111Process - Project Planning (PP) - Overview• Establish and maintain plans that define project activities• Key to effectively managing a project is project planning− Developing the project plan− Interacting with relevant stakeholders appropriately− Getting commitment to the plan− Maintaining the plan• Project planning is based on the acquisition strategy• Acquisition strategy specifies acquisition objectives and constraints,availability of assets and technologies, consideration of acquisitionmethods, potential supplier agreement types and terms,accommodation of end-user considerations, considerations of risk,and support for the project throughout the project lifecycle
  112. 112. June 17, 2013 112Process - Project Planning (PP) - Overview• Involves the development and maintenance of plans for allacquirer processes, including plans required for effectiveacquirer-supplier interaction• Includes establishing and maintaining a plan for theorderly, smooth transition of the acquired solution from asupplier to its use by the acquirer or its customers• Acquirer takes the supplier estimations for the project intoaccount at an appropriate level of detail in its project plan• Project plan is revised as the project progresses to addresschanges in requirements and commitments, inaccurateestimates, corrective actions, and process changes
  113. 113. June 17, 2013 113Process – Project Planning (PP)AcquisitionMaturityModelMaturity Level2AcquisitionRequirementsDevelopment(ARD)AgreementManagement(AM)ProjectMonitoringand Control(PMC)ProjectPlanning (PP)RequirementsManagement(REQM)Solicitationand SupplierAgreementDevelopment(SSAD)ConfigurationManagement(CM)Measurementand Analysis(MA)Process andProductQualityAssurance(PPQA)Goal 1 -EstablishEstimatesGoal 2 -Develop aProject PlanGoal 3 -ObtainCommitmentto the PlanPractice 1.1 -Establish theAcquisitionStrategyPractice 1.2 -Estimate theScope of theProjectPractice 1.3 -EstablishEstimates ofWork Productand TaskAttributesPractice 1.4 -Define ProjectLifecyclePhasesPractice 1.5 -EstimateEffort andCostPractice 2.1 -Establish theBudget andSchedulePractice 2.2 -IdentifyProject RisksPractice 2.3 -Plan DataManagementPractice 2.4 -Plan theProject’sResourcesPractice 2.5 -Plan NeededKnowledgeand SkillsPractice 2.6 -PlanStakeholderInvolvementPractice 2.7 -PlanTransition toOperationsand SupportPractice 2.8 -Establish theProject PlanPractice 3.1 -Review PlansThat Affectthe ProjectPractice 3.2 -ReconcileWork andResourceLevelsPractice 3.3 -Obtain PlanCommitment
  114. 114. June 17, 2013 114Project Planning (PP) - Related Process AreasConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  115. 115. June 17, 2013 115Project Planning (PP) - Specific Goals and Practices• Goal 1 - Establish Estimates− Practice 1.1 - Establish the Acquisition Strategy− Practice 1.2 - Estimate the Scope of the Project− Practice 1.3 - Establish Estimates of Work Product and Task Attributes− Practice 1.4 - Define Project Lifecycle Phases− Practice 1.5 - Estimate Effort and Cost• Goal 2 - Develop a Project Plan− Practice 2.1 - Establish the Budget and Schedule− Practice 2.2 - Identify Project Risks− Practice 2.3 - Plan Data Management− Practice 2.4 - Plan the Project’s Resources− Practice 2.5 - Plan Needed Knowledge and Skills− Practice 2.6 - Plan Stakeholder Involvement− Practice 2.7 - Plan Transition to Operations and Support− Practice 2.8 - Establish the Project Plan• Goal 3 - Obtain Commitment to the Plan− Practice 3.1 - Review Plans That Affect the Project− Practice 3.2 - Reconcile Work and Resource Levels− Practice 3.3 - Obtain Plan Commitment
  116. 116. June 17, 2013 116Goal 1 - Establish Estimates• Establish and maintain estimates of project planning parameters• Develops estimates for project work based on the acquisitionstrategy, including high-level estimates for the work to be done bysuppliers. Initial estimates can be revised based on supplierestimates in response to the solicitation package• Estimates of planning parameters should have a sound basis to instillconfidence that plans based on these estimates are capable ofsupporting project objectives• Documentation of the estimating rationale and supporting data isneeded for stakeholder review and commitment to the plan and formaintenance of the plan as the project progresses
  117. 117. June 17, 2013 117Practice 1.1 - Establish the Acquisition Strategy• Scope− Establish and maintain the acquisition strategy− Business and technical management framework for planning,executing, and managing agreements for a project− Relates to the objectives for the acquisition, the constraints,availability of resources and technologies, consideration ofacquisition methods, potential supplier agreement types, termsand conditions, accommodation of business considerations,considerations of risk, and support for the acquired product overits lifecycle− Basis for formulating solicitation packages, supplier agreements,and project plans
  118. 118. June 17, 2013 118Practice 1.1 - Establish the Acquisition Strategy• Work Products− Acquisition strategy• Subpractices− Identify the capabilities andobjectives the acquisition isintended to satisfy or provide− Identify the acquisition approach− Document business considerations− Identify major risks and which riskswill be addressed jointly with thesupplier− Identify the preferred type ofsupplier− Identify the solution supportstrategy− Review and obtain agreement withsenior management on theacquisition strategy
  119. 119. June 17, 2013 119Practice 1.2 - Estimate the Scope of the Project• Scope− Establish a top-level work breakdown structure (WBS) to estimatethe scope of the project− Initial set of requirements and project objectives form the basisfor establishing the WBS− WBS evolves with the project− A top-level WBS serves to structure initial estimates− Establishes the objectives of the project in the acquisition strategy− Acquisition strategy drives how much work, and what work, togive to a supplier
  120. 120. June 17, 2013 120Practice 1.2 - Estimate the Scope of the Project• Work Products− Task descriptions− Work package descriptions− WBS• Subpractices− Develop a WBS based on theproduct architecture− Define the work packages insufficient detail so that estimatesof project tasks, responsibilities,and schedule can be specified− Identify products and productcomponents to be externallyacquired− Identify work products to bereused
  121. 121. June 17, 2013 121Practice 1.3 - Establish Estimates of Work Productand Task Attributes• Scope− Establish and maintain estimates of work product and taskattributes− Estimation methods include using historical acquirer and supplierdata and standard estimating models to compare projects ofsimilar complexity− Estimates should be consistent with project requirements todetermine the project’s effort, cost, and schedule− A relative level of difficulty or complexity should be assigned foreach size attribute
  122. 122. June 17, 2013 122Practice 1.3 - Establish Estimates of Work Productand Task Attributes• Work Products− Size and complexity of tasks andwork products− Estimating models− Attribute estimates− Technical approach• Subpractices− Determine the technical approachfor the project− Use appropriate methods todetermine the attributes of thework products and tasks to beused to estimate resourcerequirements− Estimate the attributes of workproducts and tasks
  123. 123. June 17, 2013 123Practice 1.4 - Define Project Lifecycle Phases• Scope− Define project lifecycle phases on which to scope the planningeffort− Phases provide for planned periods of evaluation and decisionmaking− Phases defined to support logical decision points at which theappropriateness of continued reliance on the project plan andstrategy is determined and significant commitments are madeconcerning resources− Complex project can involve managing multiple supplieragreements simultaneously or in sequence
  124. 124. June 17, 2013 124Practice 1.4 - Define Project Lifecycle Phases• Work Products− Project lifecycle phases
  125. 125. June 17, 2013 125Practice 1.5 - Estimate Effort and Cost• Scope− Estimate the project’s effort and cost for work products and tasksbased on estimation rationale− Estimates address all processes and activities performed by theproject for the project lifecycle, including an estimate of effortand cost for supplier work− Estimates include detailed estimates for activities performed bythe acquirer and its stakeholders− As the project evolves, these estimates can be revised based onchanged conditions
  126. 126. June 17, 2013 126Practice 1.5 - Estimate Effort and Cost• Work Products− Estimation rationale− Project effort estimates− Project cost estimates• Subpractices− Collect models or historical data tobe used to transform theattributes of work products andtasks into estimates of labor hoursand costs− Include supporting infrastructureneeds when estimating effort andcost− Estimate effort and cost usingmodels, historical data, or acombination of both
  127. 127. June 17, 2013 127Practice 1.5 - Estimate Effort and Cost• Scope− Estimate the project’s effort and cost for work products and tasksbased on estimation rationale− Estimates address all processes and activities performed by theproject for the project lifecycle, including an estimate of effortand cost for supplier work− Estimates include detailed estimates for activities performed bythe acquirer and its stakeholders− As the project evolves, these estimates can be revised based onchanged conditions
  128. 128. June 17, 2013 128Practice 1.5 - Estimate Effort and Cost• Work Products− Estimation rationale− Project effort estimates− Project cost estimates• Subpractices− Collect models or historical data tobe used to transform theattributes of work products andtasks into estimates of labor hoursand costs− Include supporting infrastructureneeds when estimating effort andcost− Estimate effort and cost usingmodels, historical data, or acombination of both
  129. 129. June 17, 2013 129Goal 2 - Develop a Project Plan• Establish and maintain a project plan as the basis formanaging the project• Formal, approved document used to manage and controlthe execution of the project• Based on project requirements and established estimates• Should consider all phases of the project lifecycle
  130. 130. June 17, 2013 130Practice 2.1 - Establish the Budget and Schedule• Scope− Establish and maintain the project’s budget and schedule− Budget and schedule are based on developed estimates andensure that budget allocation, task complexity, and taskdependencies are appropriately addressed− The supplier’s efforts and efforts of supporting organisations andother stakeholders are established, tracked, and maintained forthe duration of the project
  131. 131. June 17, 2013 131Practice 2.1 - Establish the Budget and Schedule• Work Products− Project schedules− Schedule dependencies− Project budget• Subpractices− Identify major milestones− Identify schedule assumptions− Identify constraints− Identify task dependencies− Establish and maintain the budgetand schedule− Establish corrective action criteria
  132. 132. June 17, 2013 132Practice 2.2 - Identify Project Risks• Scope− Risks are identified or discovered and analysed to support projectplanning− Ensure that appropriate interfacing takes place among all relevantstakeholders on identified risks− Risks are identified from multiple perspectives (e.g., acquisition,technical, management, operational, supplier agreement,industry, support, end user) to ensure all project risks areconsidered comprehensively in planning activities− Applicable regulatory and statutory requirements with respect tosafety and security should be considered while identifying risks− As the project evolves, risks can be revised based on changedconditions
  133. 133. June 17, 2013 133Practice 2.2 - Identify Project Risks• Work Products− Identified risks− Risk impacts and probability ofoccurrence− Risk priorities• Subpractices− Identify risks− Document risks− Review and obtain agreement withrelevant stakeholders on thecompleteness and correctness ofdocumented risks− Revise risks as appropriate
  134. 134. June 17, 2013 134Practice 2.3 - Plan Data Management• Scope− Plan for the management of project data− Data are forms of documentation required to support a project inall of its areas− Data requirements for the project should be established for bothdata items to be created and their content and form, based on acommon or standard set of data requirements− The reason for collecting each document should be clear− The acquirer should consider how data will be shared betweenacquirer and supplier as well as across relevant stakeholders− Implications of controlling access to classified and sensitive datashould be considered
  135. 135. June 17, 2013 135Practice 2.3 - Plan Data Management• Work Products− Data management plan− Master list of managed data− Data content and format description− Lists of data requirements foracquirers and suppliers− Privacy requirements− Security requirements− Security procedures− Mechanisms for data retrieval,reproduction, and distribution− Schedule for the collection of projectdata− List of project data to be collected• Subpractices− Establish requirements and proceduresto ensure privacy and the security ofdata− Establish a mechanism to archive dataand to access archived data− Determine the project data to beidentified, collected, and distributed− Determine the requirements forproviding access to and distribution ofdata to relevant stakeholders− Decide which project data and plansrequire version control or other levelsof configuration control and establishmechanisms to ensure project data arecontrolled
  136. 136. June 17, 2013 136Practice 2.4 - Plan the Project’s Resources• Scope− Plan for resources to perform the project− Defining project resources and quantities needed to performproject activities builds on initial estimates and providesadditional information that can be applied to expand the WBSused to manage the project− Top-level WBS developed earlier as an estimation mechanism isexpanded by decomposing these top levels into work packagesthat represent single work units that can be separately assigned,performed, and tracked− Should include planning for staff with appropriate training andexperience to evaluate supplier proposals and participate innegotiations with suppliers
  137. 137. June 17, 2013 137Practice 2.4 - Plan the Project’s Resources• Work Products− Work packages− WBS task dictionary− Staffing requirements based onproject size and scope− Critical facilities and equipment list− Process and workflow definitionsand diagrams− Project administrationrequirements list− Status reports• Subpractices− Determine process requirements− Determine communicationrequirements− Determine staffing requirements− Determine facility, equipment, andcomponent requirements− Determine other continuingresource requirements
  138. 138. June 17, 2013 138Practice 2.5 - Plan Needed Knowledge and Skills• Scope− Plan for knowledge and skills needed to perform the project− Knowledge delivery to projects involves training project staff andacquiring knowledge from outside sources− The acquirer plans for knowledge and skills required by theproject team to perform their tasks− Orientation and training in acquirer processes and the domainknowledge required to execute the project are also required− Ensure that costs and funding sources to pay for training areavailable and lead times to obtain the funding are identified
  139. 139. June 17, 2013 139Practice 2.5 - Plan Needed Knowledge and Skills• Work Products− Inventory of skill needs− Staffing and new hire plans− Databases (e.g., skills, training)− Training plans• Subpractices− Identify the knowledge and skillsneeded to perform the project− Assess the knowledge and skillsavailable− Select mechanisms for providingneeded knowledge and skills− Incorporate selected mechanismsinto the project plan
  140. 140. June 17, 2013 140Practice 2.6 - Plan Stakeholder Involvement• Scope− Plan the involvement of identified stakeholders− Identify the people and functions that should be represented inthe project and describing their relevance and the degree ofinteraction for project activities− Careful selection of relevant stakeholders is necessary
  141. 141. June 17, 2013 141Practice 2.6 - Plan Stakeholder Involvement• Work Products− Stakeholder involvement plan
  142. 142. June 17, 2013 142Practice 2.7 - Plan Transition to Operations andSupport• Scope− Plan transition to operations and support− Transition and support plans include:• Processes and procedures for the transition to operations and support• Evaluation methods and acceptance criteria for ensuring the transition ofthe product to operations and support• Readiness criteria for the product• Readiness criteria for the operations organisation• Readiness criteria for the product support organisation• Expectations for supplier execution of the transition• Warranty expectations for the acquired product• Identification of the maintenance organisation• Transition of intellectual property or other acquirer assets to the acquirer’sdesignated repository• Resolution steps if any problems are encountered
  143. 143. June 17, 2013 143Practice 2.7 - Plan Transition to Operations andSupport• Work Products− Transition to operations andsupport plans• Subpractices− Determine the transition scopeand objectives− Determine transition requirementsand criteria− Determine transitionresponsibilities and resources toinclude post-transition supportenhancements and lifecycleconsiderations− Determine configurationmanagement needs of thetransition− Determine training needs foroperations and support
  144. 144. June 17, 2013 144Practice 2.8 - Establish the Project Plan• Scope− Establish and maintain the overall project plan− Includes• Project lifecycle considerations• Project tasks• Budgets and schedules• Milestones• Data management• Risk identification• Resource and skill requirements• Stakeholder identification and interaction• Infrastructure considerations− Project plan can include multiple plans such as staffing plans, stakeholderinvolvement plans, measurement and analysis plans, monitoring and controlplans, solicitation plans, agreement management plans, risk mitigation plans,transition plans, quality assurance plans, and configuration management plans
  145. 145. June 17, 2013 145Practice 2.8 - Establish the Project Plan• Work Products− Overall project plan
  146. 146. June 17, 2013 146Goal 3 - Obtain Commitment to the Plan• Establish and maintain commitments to the project plan• To be effective, plans require commitment by those whoare responsible for implementing and supporting the plan
  147. 147. June 17, 2013 147Practice 3.1 - Review Plans That Affect the Project• Scope− Review all plans that affect the project to understand projectcommitments− Plans developed in other process areas typically containinformation similar to that called for in the overall project plan− All plans that affect the project should be reviewed to ensure theycontain a common understanding of the scope, objectives, roles,and relationships that are required for the project to besuccessful
  148. 148. June 17, 2013 148Practice 3.1 - Review Plans That Affect the Project• Work Products− Record of the reviews of plans thataffect the project
  149. 149. June 17, 2013 149Practice 3.2 - Reconcile Work and Resource Levels• Scope− Adjust the project plan to reconcile available and estimatedresources− During supplier selection and negotiation of the supplieragreement, the acquirer reconciles overall project work andresource levels based on proposals from the supplier− Following completion of the supplier agreement, the acquirerincorporates supplier plans at an appropriate level of detail intothe project plan to support the alignment of plans
  150. 150. June 17, 2013 150Practice 3.2 - Reconcile Work and Resource Levels• Work Products− Revised methods andcorresponding estimatingparameters (e.g., better tools, theuse of off-the-shelf components)− Renegotiated budgets− Revised schedules− Revised requirements list− Renegotiated stakeholderagreements
  151. 151. June 17, 2013 151Practice 3.3 - Obtain Plan Commitment• Scope− Obtain commitment from relevant stakeholders responsible forperforming and supporting plan execution− Involves interaction among all relevant stakeholders, bothinternal and external to the project− Individual or group making a commitment should have confidencethat the work can be performed within cost, schedule, andperformance constraints
  152. 152. June 17, 2013 152Practice 3.3 - Obtain Plan Commitment• Work Products− Documented requests forcommitments− Documented commitments• Subpractices− Identify needed support andnegotiate commitments withrelevant stakeholders− Document all organisationalcommitments, both full andprovisional, ensuring theappropriate level of signatories− Review internal commitments withsenior management as appropriate− Review external commitmentswith senior management asappropriate− Identify commitments regardinginterfaces between projectelements and other projects andorganisational units so that thesecommitments can be monitored
  153. 153. June 17, 2013 153Process – Requirements Management (REQM) -Overview• Manage requirements of the project’s products and productcomponents• Ensure alignment between those requirements and the project’splans and work products• Process manages all requirements received or generated by theproject, including both technical and nontechnical requirements aswell as requirements levied on the project by the organisation• Project receives requirements from approved requirementsproviders which are reviewed with the provider to resolve issues andprevent misunderstanding before requirements are incorporatedinto project plans• Part of managing requirements is documenting requirementschanges and their rationale and maintaining their traceability• All projects have requirements. In the case of maintenance activities,changes are based on changes to the existing requirements, design,or implementation
  154. 154. June 17, 2013 154Process – Requirements Management (REQM)AcquisitionMaturity ModelMaturity Level 2AcquisitionRequirementsDevelopment(ARD)AgreementManagement(AM)ProjectMonitoring andControl (PMC)Project Planning(PP)RequirementsManagement(REQM)Solicitation andSupplierAgreementDevelopment(SSAD)ConfigurationManagement(CM)Measurementand Analysis(MA)Process andProduct QualityAssurance(PPQA)Goal 1 - ManageRequirementsPractice 1.1UnderstandRequirementsPractice 1.2ObtainCommitment toRequirementsPractice 1.3ManageRequirementsChangesPractice 1.4MaintainBidirectionalTraceability ofRequirementsPractice 1.5EnsureAlignmentBetween ProjectWork andRequirements
  155. 155. June 17, 2013 155Process – Requirements Management (REQM) -Related Process AreasConfigurationManagement (CM)Process andProduct QualityAssurance (PPQA)Measurement andAnalysis (MA)Decision Analysisand Resolution(DAR)QuantitativeProjectManagement(QPM)OrganisationalPerformanceManagement(OPM)OrganisationalProcessPerformance (OPP)Causal Analysis andResolution (CAR)OrganisationalProcess Definition(OPD)OrganisationalProcess Focus (OPF)Project Planning(PP)RequirementsManagement(REQM)AgreementManagement (AM)Solicitation andSupplier AgreementDevelopment(SSAD)AcquisitionRequirementsDevelopment (ARD)AcquisitionTechnicalManagement (ATM)AcquisitionVerification (AVER)Risk Management(RSKM)AcquisitionValidation (AVAL)Integrated ProjectManagement (IPM)Acquisition HighMaturityProcessesAcquisition Project ProcessesAcquisition Support ProcessesAcquisitionOrganisationalProcessesProject Monitoringand Control (PMC)OrganisationalTraining (OT)
  156. 156. June 17, 2013 156Requirements Management (REQM) - Specific Goalsand Practices• Goal 1 - Manage Requirements− Practice 1.1 Understand Requirements− Practice 1.2 Obtain Commitment to Requirements− Practice 1.3 Manage Requirements Changes− Practice 1.4 Maintain Bidirectional Traceability of Requirements− Practice 1.5 Ensure Alignment Between Project Work andRequirements
  157. 157. June 17, 2013 157Goal 1 - Manage Requirements• Manage requirement and identify inconsistencies withproject plans and work products• Directly manage changes to customer and contractualrequirements developed by the acquirer and overseeingthe supplier’s requirements management process• Involves:− Managing all changes to requirements− Maintaining relationships among requirements, project plans, andwork products− Ensuring alignment among requirements, project plans, and workproducts− Taking corrective action• Requirements changes can result in changes to thesupplier agreement
  158. 158. June 17, 2013 158Practice 1.1 - Understand Requirements• Scope− Develop an understanding with the requirements providers onthe meaning of the requirements− To avoid requirements creep, establish criteria to designateappropriate channels or official sources from which to receiverequirements− Analyse requirements with the provider to ensure that acompatible, shared understanding is reached on the meaning ofrequirements