1. CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M36 Slide 1 October 30, 2004 SMU CSE 7315 / NTU SE 584-N Planning and Managing a Software Project Module 36 Details of the SEI CMM

2. CSE7315M36 Slide # 2October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Objective of This Module To examine the SEI CMM (capability maturity model) in further detail Note: a thorough discussion of the CMM would require a half day or more - I have a short course on this, as do many other organizations.

3. CSE7315M36 Slide # 3October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Structure of the CMM Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

4. CSE7315M36 Slide # 4October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Structure (continued) “Each level comprises a set of process goals that, when satisfied, stabilize an important component of the software process. “Achieving each level of the maturity framework establishes a different component in the software process, resulting in an increase in the process capability of the organization.” As one moves up the levels, one exhibits greater maturity and capability and one EXPECTS to achieve better performance

5. CSE7315M36 Slide # 5October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Effects of Higher Levels At higher levels, one expects the following characteristics: Better visibility into what is happening Less variability in outcomes Less risk associated with software development, due to more accurate planning and better management

6. CSE7315M36 Slide # 6October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Better Visibility Level 1 InputOutput Level 2 Process Step Level 2 Process Step Level 2 Process Step InputOutput Level 3 Process Step

7. CSE7315M36 Slide # 7October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Lower Variability / Less Risk Level 1 Level 2 Level 3 etc.

8. CSE7315M36 Slide # 8October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved What kind of Model is the CMM? The CMM is a descriptive model and a normative model A descriptive model acts as an example or a paradigm or an ideal – A model home – A fashion model A normative model acts as a way to compare two or more instances of something – A model of the human body – A model of an automobile engine

9. CSE7315M36 Slide # 9October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CMM as a Descriptive Model The CMM describes essential (or key) attributes that would be expected to characterize an organization at a particular maturity level. – Example: an organization at level 3 has documented its process for configuration management One can use these attributes to evaluate one’s organization or to establish goals for an organization – Example: if we do not document our process for CM, we are probably not at level 3 – If we want to be at level 3, we should probably document our process for CM

10. CSE7315M36 Slide # 10October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Uses of the Model  Appraisal teams will use the CMM to identify strengths and weaknesses in the organization. – The SEI has defined a process for doing self- assessments and other forms of appraisals  Evaluation teams will use the CMM to identify the risks of selecting among different contractors for awarding business and to monitor contracts. – The SEI has defined a process for doing capability evaluations – There are many less extensive ways the CMM can be used to evaluate contractors

11. CSE7315M36 Slide # 11October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Uses (continued)  Managers and technical staff will use the CMM to understand the activities necessary to plan and implement a software process improvement program for their organization – The CMM is sometimes followed too rigidly, but the goals tend to be universally applicable  Process improvement groups, such as an SEPG [software engineering process group], will use the CMM as a guide to help them define and improve the software process in their organization.

12. CSE7315M36 Slide # 12October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved The CMM as A Normative Model The detailed practices in the CMM characterize the normal types of behavior that would be expected in an organization doing large-scale projects in a government contracting context. A given organization can compare itself with the CMM to determine how it “stacks up” with what is considered an example of best practices.

13. CSE7315M36 Slide # 13October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Does the CMM Fit a Small Organization? There is considerable debate about the extent to which these practices should be expected in other kinds of organizations. Watts Humphrey (1) has shown that the principles, if not always the specific practices, are applicable to individual, single-person projects (very small scale) that are not in a government contracting mode (1) Humphrey, Watts, A Discipline of Software Engineering, Addison Wesley, 1994.

14. CSE7315M36 Slide # 14October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved The Principles Seem to Be Universally Applicable The intent is that the CMM is at a sufficient level of abstraction that it does not unduly constrain how the software process is implemented by an organization Rather, it describes what the essential attributes of a software process would normally be expected to be One must keep this in mind when applying the CMM

15. CSE7315M36 Slide # 15October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Structure of the CMM Maturity Levels Key Process Areas Common Features Key Practices Goals Implementation Infrastructure or Activities Process Capability Address Describe Achieve Contain Organized by Contain Indicate Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

16. CSE7315M36 Slide # 16October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Example Level 2: Repeatable Level 2: Repeatable SW Project Planning Activities Performed Documented Procedure for Size Estimates Documented Procedure for Size Estimates Goal: SW Estimates are Documented... Implementation: Implementation Activities Infrastructure or Activities Process Capability: Disciplined Process Address Describe Achieve Contains Organized by Contains Indicate

17. CSE7315M36 Slide # 17October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Process Areas Except for Level 1, each level of the CMM is defined in terms of a series of Key Process Areas or KPAs Key process areas indicate the areas an organization should focus on to improve its software process. Key process areas identify the issues that must be addressed to achieve a maturity level. – Level 2 KPAs are what you focus on when you are at level 1 – Level 3 KPAs are what you focus on when you are at level 2 – And so forth. Key Process Areas

18. CSE7315M36 Slide # 18October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Structure of KPAs Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. – Note that KPAs are artificially associated with specific levels in the CMM – In actual fact, each KPA evolves as an organization moves up the maturity scale Key Process Areas

19. CSE7315M36 Slide # 19October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved KPA Definition Each KPA is defined in terms of the following: Goals - why you do it - what you hope to achieve – The goals signify the scope, boundaries, and intent of each key process area. Key Practices - what you (typically) do to achieve the goals – Infrastructure elements, such as policies or practices or resources – Activities, such as reviews or processes Key Process Areas

20. CSE7315M36 Slide # 20October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Five Common Features of KPAs Certain features or attributes are common to each KPA These attributes indicate whether the implementation and institutionalization of a key process area are effective, repeatable, and lasting. The five common features are: – Commitment to Perform – Ability to Perform – Activities Performed – Measurement and Analysis – Verifying Implementation Key Process Areas

21. CSE7315M36 Slide # 21October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Commitment to Perform Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure – Example: establishing a policy that mandates a particular activity We WILL do this! Key Process Areas Commitment to Perform typically involves establishing organizational policies and demonstrating senior management sponsorship.

22. CSE7315M36 Slide # 22October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Ability to Perform Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently Key Process Areas Boss SEPG SW Manager Ability to Perform typically involves resources, organizational structures, and training

23. CSE7315M36 Slide # 23October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Activities Performed Activities Performed describes the roles and procedures necessary to implement a key process area Key Process Areas Activities Performed typically involve: -- Establishing plans and procedures, -- Performing the work, -- Tracking it, and -- Taking corrective actions as necessary Activities Performed typically involve: -- Establishing plans and procedures, -- Performing the work, -- Tracking it, and -- Taking corrective actions as necessary

24. CSE7315M36 Slide # 24October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Measurement and Analysis Measurement and Analysis describes the need to measure the process and analyze the measurements Key Process Areas Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed.

25. CSE7315M36 Slide # 25October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Verifying Implementation Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established Key Process Areas Verification typically encompasses reviews and audits by management and software quality assurance.

26. CSE7315M36 Slide # 26October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Practices The key practices describe "what" is to be done -- Example: a key practice for risk management might be periodic evaluation of risks and the status of known risk areas But they should not be interpreted as mandating "how" the goals should be achieved Key Practices

27. CSE7315M36 Slide # 27October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Alternative Practices Alternative practices may accomplish the goals of the key process area The key practices should be interpreted rationally to judge whether the goals of the key process area are effectively, although perhaps differently, achieved. Key Practices Key Practice per CMM Example Key Practice for Our Situation

28. CSE7315M36 Slide # 28October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Reviewing the Five Levels The five levels correspond to Humphrey’s five levels (see text) But the CMM provides additional detail and many “best practices” Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

29. CSE7315M36 Slide # 29October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Level 1- Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort (heroes). Unstable environment is subject to catastrophe if key people leave – “Bus sensitive projects” Planning is ineffective -- reaction is the order of the day Plans are routinely ignored or abandoned Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity “You can be very successful, but you cannot count on it.”

30. CSE7315M36 Slide # 30October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Level 2 - Repeatable Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. Stability is present, even when heroes leave, so long as the overall environment is consistent Everyone knows how to do it, although they do not always know why Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity “You can expect consistent behavior.”

31. CSE7315M36 Slide # 31October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Process Areas for Level 2 Configuration Management Software Project Planning Quality Assurance Requirements Management Subcontractor Management (*) Project Tracking and Oversight (**) (*) Acquisition Management in V 2.0 (**) Project Control in V 2.0

32. CSE7315M36 Slide # 32October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Level 3 - Defined The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. People know why, not just how to do the job Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity “You can expect stability in a changing environment.”

33. CSE7315M36 Slide # 33October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Process Areas for Level 3 Organizational Process Focus Organization Process Definition Organizational Training Program Integrated Software Management – All activities are linked together Intergroup Coordination (*) Software Product Engineering – Good software engineering techniques; effectively used Peer Reviews – Defect removal at all steps of the process (*) Product Interface Coordination in V 2.0

34. CSE7315M36 Slide # 34October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Level 4 - Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. Decisions are based on fact Process behavior is quantified Processes are instrumented to facilitate data collection Measurements are applied across the organization so that norms and exceptions can be identified Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

35. CSE7315M36 Slide # 35October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Process Areas for Level 4 Quantitative Process Management (*) -- Metrics are defined, collected, analyzed and acted upon Software Quality Management (**) -- Quality is managed, not just controlled (*) Statistical Process Management in V 2.0 (**) Organization Process Performance in V 2.0 Organization Software Asset Commonality (new KPA for V 2.0)

36. CSE7315M36 Slide # 36October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Level 5 - Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

37. CSE7315M36 Slide # 37October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Process Areas for Level 5 Defect Prevention – You not only find defects, you correct or remove the process steps that cause them Technology Change Management (*) – You insert technology in an orderly and managed fashion – New methods and tools do not disrupt performance … continued

38. CSE7315M36 Slide # 38October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Key Process Areas for Level 5 Process Change Management (*) – Not only do you change the process, but you do so in a managed way, so the outcome is predictable within narrow limits (*) Merged into Organization Process and Technology Innovation in V 2.0 Organization Improvement Deployment (new KPA for V 2.0)

39. CSE7315M36 Slide # 39October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved A Closer Look at a Few Parts of SEI Level 2 (CMM 1.1) (See Note) Configuration Management Project Planning Quality Assurance  Requirements Management  Subcontractor Management Project Tracking and Oversight Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity Note: V2.0 document shows differences from V1.1 via notations in margin.

40. CSE7315M36 Slide # 40October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved We Will Review Two of the KPAs Requirements Management and Subcontractor Management have not been discussed very much in the course up until now So we will examine what the CMM has to say about them The other four KPAs have been discussed in the course

41. CSE7315M36 Slide # 41October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Requirements Management TYPICAL SYMPTOMS The product is “perfect,” but the customer doesn’t like it – Often because the developers “know what’s best for the customer” Finger pointing – Multiple versions of the requirements – Multiple interpretations of the requirements The system will not integrate – The parts do not fit together – Some functions are duplicated in software & hardware – Some functions are missing entirely

42. CSE7315M36 Slide # 42October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Requirements Management KPA Purpose: To establish a common understanding between the customer and the software project Practices: – Reaching agreement on the requirements – Documenting the requirements – Controlling changes to the requirements – Communicating changes to the requirements – Allocating requirements - to software, hardware, etc. - in a clear, unambiguous manner

43. CSE7315M36 Slide # 43October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Requirements Management Goals I 1.System requirements allocated to software are controlled to establish a baseline – Requirements may come directly from the customer on a software-only project – Requirements may come from a system engineering function on a hardware & software project – “Controlled” means you don’t change without approval and communication

44. CSE7315M36 Slide # 44October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Requirements Management Goals II 2.Software plans, products and activities are kept consistent with the requirements – If you change the requirements, you must consider changing the plans, etc.

45. CSE7315M36 Slide # 45October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Behaviors System engineer or project lead: – Allocates requirements to all parts of the system Don’t forget support, installation, documentation, etc. Include platform selection, network configuration, and other tasks that are not part of software development – Controls and communicates changes May use a system configuration control board – Listens to understand the impact of changes

46. CSE7315M36 Slide # 46October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Behaviors (continued) Software manager: – Participates in system configuration control process – Determines the impact of changes on software cost and schedule – Communicates the impact to affected parties (system engineers, customers, program managers, etc.)

47. CSE7315M36 Slide # 47October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Behaviors (continued) Software engineers: – Review requirements (and changes) – Communicate the cost/impact of requirements/changes – For example, which modules need to be redesigned, recoded, retested, etc. – (This works best if the software engineer can document the estimated cost and schedule impact of each change.)

48. CSE7315M36 Slide # 48October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Special Issues - I The basic responsibility for requirements management may lie outside of the software engineering function – Software may be only part of a larger system product – Many large projects use a system engineer responsible for design, control and integration of the whole system Subsystem (segment) Subsystem (segment) Subsystem (segment) Product or Item (configuration item) Product or Item (configuration item) Product or Item (configuration item) System Subsystem (segment) Requirements Management Responsibility Requirements Implementation Responsibility } }

49. CSE7315M36 Slide # 49October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Special Issues - II The symptoms of poor requirements management tend to show up toward the end of the project -- when it costs the most to fix the problems – Often the fixes require extensive software changes, but the “fault” may lie outside the software function

50. CSE7315M36 Slide # 50October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Special Issues - III The cost of proper requirements management comes at the front end of the project Integrate & Test Design the Architecture & Allocate Requirements Build the System Analyze Requirements The penalty for improper requirements management comes at the back end

51. CSE7315M36 Slide # 51October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Software Subcontract Management TYPICAL SYMPTOMS They were supposed to deliver it today. They just called and told us they have a three month delay! They always delivered on time in the past!

52. CSE7315M36 Slide # 52October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved More Typical Symptoms We’ve been hit by a $25,000 fine because our user interface does not meet EPA standards. The subcontractor did not know about the regulations. The big cost will be the recall - about $200,000

53. CSE7315M36 Slide # 53October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Further Typical Symptoms They delivered the software module, but no test cases and no documentation The contract was vague on this point. They thought that was our responsibility.

54. CSE7315M36 Slide # 54October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Software Subcontract Management Purpose: – To select qualified subcontractors – To manage subcontractors effectively Practices: – Establish policies for software subcontract management – Select subcontractors based on ability to do the job – Communicate effectively with subcontractors – Document commitments – Flow down standards, processes, etc. – Track and review subcontractor performance and results.

55. CSE7315M36 Slide # 55October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Subcontract Management -- Goals 1.Select qualified subcontractors – Include software management in selection process 2.Agree to commitments – Get them in writing 3.Maintain ongoing communication 4.Track performance against commitments – Reviews, audits, etc.

56. CSE7315M36 Slide # 56October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Behaviors Program manager: – Includes software manager in subcontractor selection process – Establishes policies and procedures for managing subcontracts Software manager and subcontract manager: – Track subcontractor schedule, effort, size, risks, etc. – Take corrective action when there are significant deviations from plan – Hold periodic reviews of subcontract project status

57. CSE7315M36 Slide # 57October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Special Issues Subcontractors may not like to be reviewed and audited – Diplomacy, tact, and firm management skills are needed – A cooperative approach based on mutual goals for quality can lead to more openness and more accurate information – Standards and regulations can provide leverage in negotiations “We trust you, but ISO 9000 requires that we do an audit”

58. CSE7315M36 Slide # 58October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Special Issues Other parts of your own company are subcontractors too! – They may not require all the formality, but the principles are still the same: Statement of work, commitment, tracking, etc.

59. CSE7315M36 Slide # 59October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Module Summary The CMM can be used as a descriptive or a normative model Each level has key process areas and other common elements The level 2 key process areas are fundamental to good management and correspond to major sections of this course

60. CSE7315M36 Slide # 60October 30, 2004 CSE 7315 - SW Project Management / Module 36 - Details of the SEI CMM Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved END OF MODULE 36