Transcript SPI Project & Program Management: Lessons Learned

SPI Project & Program Management
Lessons Learned
Jack Crowley, PMP
Director, Program Office
Telcordia 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
Policy
Tier 1: Corporate Policy
Software
Development
Methodology
Local Practices
Tier 2: Thin, common sense,
standard methodology
Tier 3: Tailored for local
environment
•Align process goals with business drivers
•Maintain ease-of-use
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)
Capability Maturity Model v1.1 for
Software
Level 5 - Optimizing
Defect Prevention
Technology Change Management
Process Change Management
Quantitative Process Management
Software Quality Management
Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup Coordination
Peer Reviews
Requirements Management
Software Project Planning
Software Project Tracking and Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management
Level 4 - Managed
Level 3 - Defined
Level 2 - Repeatable
Level 1 - Initial
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
SPI Project Experience
Planning
• Alternative plans
• Clear mapping to business objectives
• Clear mapping to quantitative business
goals
• PMBOK® Knowledge Areas
SPI Project Experience
Execution
Knowing 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
Integration Management
• Development, Execution, Change Control
– Strategic Analysis
– Gap Analysis
– Process Customization
– Training
– Implementation Support
SPI Project Experience
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: 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
SPI Project Experience
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 you
Questions?