spi project & program management lessons learned jack crowley, pmp director, program office...
Post on 19-Dec-2015
218 views
TRANSCRIPT
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
What Are SPI Projects
• We start off with significant inputs from– SEI SW-CMMSM version 1.1– PMI’s PMBOK®
– Our experience
What Are SPI Projects
• 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
What Are SPI Projects
• 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
SPI Project Experience
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
SPI Project Experience
Execution• Customization of our process framework
– More efficient– Easier to focus– Compliant with business objectives & goals– Thin & simple– Client’s language, process and culture
SPI Project Experience
Control• Reporting• Passionate teams• Facilitation skills• Team size• Execution of alternative plans• Execution of corrective action plans
SPI Project Experience
Close• Training complete• Support and coaching begin• Process feedback & improvement• Lessons learned• Project closure celebration• Program begins
SPI Project Experience
SPI Project Experience
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
SPI Project Experience
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
SPI Project Experience
Cost Management• Estimate non-human resources• Based off the schedule, estimate
people costs• Develop cost mitigation plans• Review weekly
SPI Project Experience
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
SPI Project Experience
Human Resource Management• Based on skill set needs
– Leadership, respected in the organization, believers
• Consultants as facilitators and guides• Forming, storming, norming• Kickoffs & celebrations
SPI Project Experience
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
SPI Project Experience
Risk Management• Identify• Determine probability• Determine cost• Quantify• Risk reserve• Risk response plan• Update weekly
SPI Project Experience
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 Project Experience
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?