SPI Project & Program Management Lessons Learned Jack Crowley, PMP Director, Program Office Telcordia Technologies, Inc. 908-797-8421 Co-author: Eric Byrne,

SPI Project & Program Management

Lessons LearnedJack Crowley, PMPDirector, Program OfficeTelcordia Technologies, Inc.908-797-8421

Co-author: Eric Byrne, Ph. D.

What Are SPI Projects

• Kickoff to overall Software Process Improvement (SPI) program

• Software Process Improvement– Strategic (tier 1)– Tactical (tier 2)– Local (tier 3)

• Process– Business– Managerial– Engineering

Quality Management System

•Align process goals with business drivers

•Maintain ease-of-use

Tier 3: Tailored for local environment

Tier 1: Corporate Policy

Tier 2: Thin, common sense, standard methodology

Local Practices

Policy

SoftwareDevelopmentMethodology


• We start off with significant inputs from– SEI SW-CMMSM version 1.1– PMI’s PMBOK®

– Our experience


• SEI SW-CMMSM version 1.1– 5 Levels of Maturity

• Initial (not stable & chaotic)

• Repeatable (project management focused)

• Defined (software engineering focused)

• Managed (quantitatively focused)

• Optimizing (continuous process improvement)

Level 1 - Initial

Level 2 - Repeatable

Level 3 - Defined

Level 4 - Managed

Level 5 - Optimizing

Requirements ManagementSoftware Project PlanningSoftware Project Tracking and OversightSoftware Subcontract ManagementSoftware Quality AssuranceSoftware Configuration Management

Organization Process FocusOrganization Process DefinitionTraining ProgramIntegrated Software ManagementSoftware Product EngineeringIntergroup CoordinationPeer Reviews

Quantitative Process ManagementSoftware Quality Management

Defect PreventionTechnology Change ManagementProcess Change Management

Capability Maturity Model v1.1 for Software


• PMI PMBOK® ©1996– Process Groups

• Initiating, Planning, Executing, Controlling, Closing

– Knowledge Areas• Integration, Scope, Time, Cost, Quality, Human

Resources, Communications, Risk, Procurement

SPI Project Experience

Initiating• Strategic

– Developing & maintaining support– Strategic interview sessions– Strategic relationship management

• Tactical– Gap Analysis– Project delivery pressure vs. SPI project

• Local• Support outside IT organization

Planning• Alternative plans• Clear mapping to business objectives• Clear mapping to quantitative

business goals• PMBOK® Knowledge Areas


ExecutionKnowing what to do is not the same as

understanding how to do it! – Eric Byrne, Ph. D.

• Resource coordination– People– Logistics

• Approaches– Multiple teams in parallel– Single team


Execution• Customization of our process framework

– More efficient– Easier to focus– Compliant with business objectives & goals– Thin & simple– Client’s language, process and culture


Control• Reporting• Passionate teams• Facilitation skills• Team size• Execution of alternative plans• Execution of corrective action plans


Close• Training complete• Support and coaching begin• Process feedback & improvement• Lessons learned• Project closure celebration• Program begins



Integration Management• Development, Execution, Change

Control– Strategic Analysis– Gap Analysis– Process Customization– Training– Implementation Support

Scope Management• Define the scope of the SPI project• Plan for scope creep

– Some scope creep is ok

• Utilize your contracts management team• Explain, educate, verify and obtain

signatures


Time Management• High level schedule first

– Followed by a detailed schedule

• Duration estimation can be difficult– Corporation & team size factors

• Develop plans for schedule problems• Review weekly


Cost Management• Estimate non-human resources• Based off the schedule, estimate

people costs• Develop cost mitigation plans• Review weekly


Quality Management• Do as I say, not as I do!!!• Develop a quality plan• Assign a quality assurance resource• Use configuration management tools• Maintain security• Take corrective actions when necessary


Human Resource Management• Based on skill set needs

– Leadership, respected in the organization, believers

• Consultants as facilitators and guides• Forming, storming, norming• Kickoffs & celebrations


Communication Management• Top priority• Develop the communication plan

– Who needs what, when, how and in what format

– Back up plans: sickness, vacation, emergencies

• Develop quick contact sheets


Risk Management• Identify• Determine probability• Determine cost• Quantify• Risk reserve• Risk response plan• Update weekly


SPI: Common Risks

Include a lack of:

• Senior management commitment

• Management understanding

• Practitioner skills

• SEPG member skills and knowledge

• Understanding of the organization (culture)

• Communication

SPI: Common Risks

• Funding for process improvement < 6%

• SPI Program – Approved, launched, and forgotten by management

– Announced with lots of fanfare and not mentioned again (until process is ready)

• First objective to identify and purchase tools

• Organization to be trained on the CMM (and then sent back to their jobs)

SPI: Common Risks

• Buried in the depths of the org chart• Headed by powerless manager• Staffed with failed developers and

managers• Too few members

SPI: Common Risks

• Business goals not known or considered

• Process viewed as the goal, rather than a means to an end

• Someone else’s process to be used without review

• CMM is dogma

• First step is to document the as-is, already-broken process in great detail

• Process defined for other groups outside of the organization to follow

SPI: Common Risks

• Practitioners not involved in process definition

– SEPG members know what practitioners need

• Large working groups formed to create the process

• SQA group created before there is a process

• No reviews of process documents by organization

• No pilots of process

SPI: Common Risks

• Process is ideal and ignores reality of projects

• A one-size fits all process for use on every project

• No process architecture (structure of description)

• KPA by KPA (organization of description)

• Process description fills a honkin’ binder– Attempts to address all possible situations

– Full of tutorial and training materials

• Templates contain lengthy tutorial text

SPI: Common Risks

• Process not approved by management

• Confusion between process defined roles and

current organizational responsibilities

• Require all existing projects to start using

the new process going forward

• Declare victory and end the SPI program

once training is completed

SPI: Common Risks

• Process documentation distributed via e-mail

• Organization not trained on the new process

• Practitioners asked to review process on

their own and start using it

• Assume everyone understands the process

after attending training

SPI: Common Risks

• Middle managers do not understand the process

• Senior management not engaged in the program

• Failure to use the process is ignored

• Practitioners asked to ignore process in a crisis

• Project failures are blamed on the process

• Critical skill sets are not grown within the organization

• SQA seen as process cop

SPI: Common Risks

• Use of the new process is optional

• Requests to waive usage of the process are always approved

• There is no waiver request procedure

• Waiver procedure is incredibly bureaucratic

SPI: Common Risks

• Gaps exist between process and how

projects are really conducted

• Release of new processes poorly

communicated

• Focus on perfecting the processes rather

than meeting business objectives

• Focus solely on achieving next CMM Level

SPI: Common Risks

• SEPG is the official owner of the process

• Practitioners not viewed as the SEPG’s

client

• Feedback, complaints, and suggestions

are ignored or discounted

• Impact of re-orgs on process and its usage

not addressed

Procurement Management• Procurement / Subcontract Management

– Develop criteria– Select– Obtain non-disclosure agreements

• Contracts– Development, execution, review, control,

close


SPI Lessons Learned

• Obtain management commitment• Establish responsibility for process

improvement• Focus on business goals, not level X• Involve practitioners• Don’t try to skip levels• Build your SPI program with multiple

projects

SPI verses SDP(Software Development

Process)

Similarities• Senior IT management sponsorship• Project priority• Focus across groups• Project plan with associated budget• Scope control – with a twist

SPI verses SDP

Differences• The whole organization• Corporate culture• Evolvement into a program with

continuous improvement

SPI verses SDP

Differences• SEPG

– Creation– Transition

• Process pushback• Unique challenges• Middle management sponsorship

About the Author

Jack is the Program Director for the Software Process Improvement Practice at Telcordia Technologies and Principal Consultant In his role, he has been deeply involved in virtually every aspect of software process improvement, business process re-engineering, software development, quality assurance and customer support.

His vertical industry experiences include investment banking, finance, insurance, Internet operations, manufacturing, telecommunications, public transportation maintenance and operations. He is a PMP (Project Manager Professional) certified by the Project Management Institute. Prior to his COO position, his twenty years experience includes program office director, project manager, software process lead, teacher and consultant. His process improvement experience includes the development and implementation of processes for project management, process compliance (SQA), joint application development practices, metrics collection and analysis.

Jack earned a Masters of Science degree in Management Science: Management of Information Systems from New Jersey Institute of Technology, Summa Cum Laude. He also earned a Masters Certificate in Information Technology Project Management from George Washington University.

He earned a Bachelor of Science degree in Management Science: Finance with a collateral in Training and Development from Kean University in New Jersey, also graduating with Summa Cum Laude honors.

Jack continues to enhance his knowledge through courses by the Software Engineering Institute, Project Management Institute and Telcordia Technologies.

Jack is active within the project management profession, serving as a member of the NJ Chapter of the Project Management Institute. He is also active within the software profession, serving as a member of the NJ Software Process Improvement Network and SEI Subscriber.

Additional honors include: a Citation for Academic Distinction from the State of New Jersey Senate & General Assembly, Certificate of Academic Distinction from Kean University, and is a member of Phi Kappa Phi, Alpha Sigma Lambda, Lambda Alpha Sigma, and Alpha Epsilon Lambda honor societies. He has also been included in the Gibraltar Who’s Who Directory.

Thank youQuestions?

Documents

SPI Project & Program Management Lessons Learned Jack Crowley, PMP Director, Program Office Telcordia Technologies, Inc. 908-797-8421 Co-author: Eric Byrne,