1 / 26

Process Definition and Rollout A Better Approach

Process Definition and Rollout A Better Approach. pragma S YSTEMS C ORPORATION 849 Lincoln Avenue Glen Rock NJ 07452 201-612-7451 Business 201-612-6117 Facsimile cbuchman@pragmasystems.com. 1998 pragma S YSTEMS C ORPORATION. SW-CMM. Software Development and Maintenance Organization.

lyn
Download Presentation

Process Definition and Rollout A Better Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Process Definition and Rollout A Better Approach pragmaSYSTEMS CORPORATION 849 Lincoln Avenue Glen Rock NJ 07452 201-612-7451 Business 201-612-6117 Facsimile cbuchman@pragmasystems.com • 1998 pragmaSYSTEMS CORPORATION

  2. SW-CMM Software Development and Maintenance Organization Auditor SW-CMM Characteristics Written in passive voice to support auditors

  3. SW-CMM Characteristics • Examples: • Software Project Planning(a Level 2 Key Process Area) • Activity 6 • The project’s software development plan is developed according to a documented procedure. • One of 25 key practices • Software Configuration Management(a Level 2 Key Process Area) • Activity 10 • Software baseline audits are conducted according to a documented procedure. • One of 21 key practices

  4. 3 19 3 19 3 18 3 13 3 18 2 9 17 3 20 2 19 2 3 16 2 11 3 16 21 4 4 17 22 4 24 3 3 25 12 2 SW-CMM Size Characteristics Maturity Level No. of Goals per KPA No. of Key Practices per KPA Key Process Areas (KPA) Process change management 5 Technology change management Subtotal Subtotal Defect prevention 56 9 4 Software quality management Subtotal Subtotal Quantitative process management 31 6 Peer reviews Intergroup coordination 3 Software product engineering Integrated software management Training program Subtotal Subtotal Organization process definition Organization process focus 108 17 Software configuration management Software quality assurance 2 Software subcontract management Software project tracking and oversight Software project planning Subtotal Subtotal Requirements management 121 20 316 52 TOTALS TOTALS

  5. Key Process Areas • 18 Key Process Areas • 5 major sections in each Key Process Area • Several people are required to initiate action in each Key Process Area • No one person can fully satisfy any one Key Process Area

  6. SW-CMM Characteristics • Especially not written to support software development and maintenance project personnel • Not written to support process definers/ documenters

  7. Process Improvement Industry • Solution space for Internal Business Challenges People Process Technology

  8. Process Improvement Industry • Usual approach: • Internal staff, facilitated sessions, and the SW-CMM, starting with page 1 of Level 2 • Result: • Many false starts and if successful, a Key Process Area by Key Process Area solution

  9. KPA by KPA Approach • Customized Key Process Area solutions are more familiar and easier to understand than the SW-CMM, but still require a significant study and interpretation effort by each project. Easy to define, hard to rollout

  10. Scenario of the 1990s • 1998 pragmaSYSTEMS CORPORATION

  11. SPI Project Initiation • Process-oriented informal group begins meeting over brown bag lunches. At least one of them has an urgent proposal deadline and 2 or 3 have been to a process-related conference. • One of them gets appointed SEPG Leader and is allowed to charge 1 day per week for this work. • Process Action Teams (PAT) are formed, with Key Process Area-type names and PAT Leaders are appointed. • PATs are allowed to meet and charge overhead 4 hours per week per person usually on Friday afternoons.

  12. Wild Enthusiasm • Appoint a full-time SEPG Leader. • Increase the budget for the PATs. • Write the charters for the PATs and the SEPG. • Replace some of the PAT Leaders and some of the PAT membership. • Exit Criteria for Wild Enthusiasm: • $250K to $1M must have been spent and • 6 to 18 months must have past.

  13. Mild Enthusiasm • A Software Process Improvement Plan is developed (revised) by the SEPG Leader. • Reform the PATs with 1 or 2 full-time people on each PAT and replace some of the PAT Leaders and membership. • SEPG Leader tracks progress against the Plan. • One or two strong PAT leaders get promoted into line management or otherwise get pulled back onto project or proposal work. • The SEPG Leader leaves or is removed. • Exit Criteria for Mild Enthusiasm: • $500K to $2M must have been spent and • At least 24 months must have past.

  14. Disillusionment • Pressure intensifies from the sponsor to get an official assessment. • Panic sets in. No one has actually used the processes yet. • Get PAT members to pilot the processes on their projects. Hopefully, these projects have a compelling business need to achieve Level 2. • Conduct brown bag lunches to teach the CMM to potential assessment interviewees. • Conduct a pre-assessment.

  15. Chaos • Panic intensifies. The processes are not fully compliant with the CMM, even if they are used. • Rework and reinstall the processes on the pilot projects. • Accelerate the CMM lunches for potential assessment interviewees.

  16. Gaming the Assessment • We no longer talk about how much money has been spent or how much time has past. We are solely focused on the impending assessment. • Stack the assessment team with PAT members and the SEPG Leader. • Overwhelm the assessment team with paper and interviewees who “speak” the CMM. • At the Findings Briefout the sponsor congratulates everyone on the great work and says s/he wants Level 3 in fewer than 12 months.

  17. Post-Assessment Fallout–Part 1 • After the assessment, the pilot projects go back to business as usual and all other projects are not interested in the agony the pilot projects endured. • Twelve months later, can’t conduct an assessment because organization would probably fail Level 2.

  18. Post-Assessment Fallout –Part 2 • Search for the guilty. • Punish the innocent. • Promote the nonparticipants. • If the business need for the SW-CMM still exists, define the requirements.

  19. The Project Perspective • Process people consume a lot of overhead $$. • Process people produce a lot of binders filled with pictures of boxes and arrows.

  20. Pithy (but not useful or accurate)Sayings from the Field • You can’t buy a process for intellectual work, you must create it yourself. • You must document the as-is process first. • Document what you do and you are a Level 2.

  21. KPA by KPA Approach Role KPAs Process Requirements Management Senior Manager Requirements Management Software Project Planning Project Manager Software Project Planning Software Project Tracking and Oversight Project Software Manager Software Project Tracking and Oversight Software Subcontract Management Standards Compliance Manager Software Subcontract Management Software Quality Assurance SCM Manager Software Quality Assurance Software Configuration Management Software Subcontract Manager Software Configuration Management . . . . . . . . .

  22. Role Based Approach Role KPAs Process Requirements Management Senior Manager Senior Manager Responsibilities Software Project Planning Project Manager Project Manager Responsibilities Software Project Tracking and Oversight Project Software Manager Project Software Manager Responsibilities Software Subcontract Management Standards Compliance Manager Standards Compliance Manager Responsibilities Software Quality Assurance SCM Manager SCM Manager Responsibilities Software Configuration Management Software Subcontract Manager Software Subcontract Manager Responsibilities . . . . . . . . .

  23. Role of the SEPG ABC Corporation’s Organization Standard Process SEPG advises SEPG captures Lesson Learned Project’s Defined Process ABC’s External Customer Requirements SEPG advises SEPG captures Lesson Learned Project’s Plan project activities ABC’s Customer project products

  24. Software Engineering Process Group • Develop the SPI Project Plan • Monitor Progress in Preparation for Progress and Strategic Reviews with the Sponsor • Provide Consulting to Project Personnel in the Use of the Processes • Identify Needs for New Tools and Processes • Document Requirements for New Tools and Processes • Evaluate New Tools and Processes • Evaluate and Select Good Worked Examples of Software Work Products for Reference by Other Projects • Prepare Process Change Requests • Implement Approved Change Requests to the Processes

  25. Software Process Improvement Sponsor • Approve the Software Process Improvement Plan • Approve Organizational Software Process Policies • Conduct SPI Project Strategic Reviews • Conduct SPI Project Progress Reviews • Communicate SPI Objectives • Create Incentives for use of the Processes • Approve Changes to the Organization’s Process • Enforce the use of Processes with his/her Direct Reports

  26. Lessons Learned from the Role-Based Approach • Study and interpretation of the SW-CMM is removed from the critical path for project personnel. • Processes look familiar and business-oriented. • Learning curve for role-based processes is much shorter and less frustrating than for KPA-based processes. • Individual and organizational resistance is much less than with the KPA-based approach.

More Related