Software Contracting Process and
Guidance
Neil Potter, Mary Sakry
The Process Group
P.O. Box 700012
Dallas, TX 75370-0012
Tel. 972-418-9541
Fax. 972-618-6283
E-mail: help@processgroup.com
Web: http://www.processgroup.com
Licensed from Karl E. Wiegers
Version PBv3 contains Pitney Bowes templates and modifications
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
1
Course Objectives
At the end of this workshop you will be able to:
 Summarize the Software Contracting Process.
 Use the process templates, checklists, and other work aids.
 Identify and manage risks for a contracted project.
 Develop a Request for Proposal.
 Select a qualified vendor.
 Manage a contracted project.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
2
Agenda
 Introduction to Software Contracting
 software contracting to outside vendors
 selecting a project for software contracting
 The Software Contracting Process
 Process Steps and Tips for Successful Execution




requirements development
risk management
project management
key deliverables
 Statement of Work
 Request for Proposal
 Contract
 Contract Provision Tracking Matrix
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
3
What is Software Contracting?
 Contracting with an external vendors to develop or
maintain a system or software product
 Think of it as “partnering” or “collaboration”
 Not the same as staff-augmentation contracting
 With Software Contracting the agreement is between
Pitney Bowes and a Vendor to produce a series of
defined deliverables
 With Staff Augmentation the agreement is between a
manager and a specific individual to perform specific
tasks
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
4
Possible Motivations for
Software Contracting
 Insufficient resources available in house
 Parallel or joint development
 Reduce time to market
 Offload legacy or non-core competency work
 Exploit vendor’s technical or quality capabilities
 Control development costs
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
5
Some Key Software Contracting Issues
Cultural Differences
Communications
Infrastructure
Issue
Management
Intellectual
Property
Ownership
Time Zones
Active Project and
Risk Management
Use of Effective
Processes
Accurate and Complete
Requirements
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
Knowledge and Skills
Transfer
www.processgroup.com
Version 1.2 PGv2-PBv3
6
Our Mission
Work collaboratively with customers worldwide to
improve their software engineering process capability.
Provide assessments, training, and consulting to meet
their specific needs, resulting in improved software
quality and delighted customers.
help@processgroup.com
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
7
Your Class Expectations
• Your job.
• Contracting problems / issues?
• Expectations for this class (e.g., 5/5 score?)
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
8
Some Definitions
Contract
Legally binding agreement of project terms
Vendor
Organization that contracts to build product
Request for Proposal
Pitney Bowes (PB) description of project
and invitation to vendors to bid
Statement of Work
PB description of work to be performed by
vendor
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
9
Technical Issues with Outside Vendors
 Many are at high process maturity levels.
 You still need to get the requirements right.
 You still need to actively manage the relationship with the
vendor.
 You still need to ensure that they follow their stated process.
 Is it effective?
 Do they expect the process to replace people?
 Do they expect staff to be interchangeable?
 Their process won’t compensate for weaknesses in yours.
 They should have data from previous projects.
 Ask to see size, schedule, effort, defect data.
 Request status, quality, and peer review data
for project tracking.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
10
Group Discussions:
Software Contracting Issues
List contracting-related problems, concerns, and questions
that your project has. For each problem, also state the
impact of the problem and identify root causes.
Example
Problem:
Multiple PB individuals are identified
as points of contact.
Impact:
Time is wasted as vendor attempts to get
questions answered.
Root cause: Unclear project roles and responsibilities.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
11
Selecting a Project for Software Contracting
 Well-understood, stable requirements
 Well-defined scope, limitations, and interfaces
 Not highly innovative
 Not subject to critical design or integration constraints
 Core competency
 Proprietary knowledge or technology needed
 PB needs to develop internal technical expertise
 Emergent or exploratory projects
 Extensive, ongoing customer involvement needed
 Very short projects (weeks)
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
12
Software Contracting Process
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
13
Software Contracting Process
 Based on industry standards




Capability Maturity Model for Software
Software Acquisition CMM
CMMI/SE-SW
IEEE Std 1062-1998, “Recommended Practice
for Software Acquisition”
 Incorporates industry best practices for software contracting,
requirements engineering, project management
 Defines roles, responsibilities, process steps, deliverables
 Includes many PB templates
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
14
Process Roles
PB Staff:
Vendor Staff:
Software Contracting Mentor
Project Manager
Systems Engineer
Legal Department
Enterprise Procurement
Technical Staff
Senior Management
Test Lead
Software Configuration Manager (SCM)
Software Quality Engineer (SQE)
Project Manager
Senior Management
Legal Department
Technical Staff
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
15
Process Entry Criteria
 Senior management has approved the software contracting
decision.
 An overall project manager has been assigned.
 A software contracting mentor has been informed.
 A team has been assembled to prepare the RFP.
 A schedule has been defined for developing requirements,
preparing the RFP and selecting a vendor.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
16
Process Overview
Define Product
Requirements
A1
REQUIREMENTS
CAPTURE WORKFLOW
Prepare
Statement
of Work
A2
Execute
Contract
A4
Solicit and
Select
Vendor
A3
Manage
Contracted
Project
A5
IF VENDOR NOT ALREADY
IDENTIFIED FOR PROJECT
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Close Out
Contracted
Project
A6
Version 1.2 PGv2-PBv3
17
Process Overview
Prepare
Statement
of Work
A2
Define
Proposal
Evaluation
Criteria
A3.1
Select
Vendor
A3.4
Prepare
RFP
Package
A3.2
Solicit
Vendor
Proposals
A3.3
Execute
Contract
A4
Solicit and Select Vendor (ACTIVITY NOT REQUIRED IF VENDOR KNOWN)
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
18
Process Exit Criteria
 The vendor has delivered all contracted products to PB.
 The deliverables from the vendor have satisfied all
acceptance criteria.
 A vendor performance review has been performed.
 Enterprise Procurement has sent a Letter of Closure to the
vendor.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
19
Define Product Requirements
Define Product
Requirements
Process Entry
Criteria
Purpose:
Outputs:
Key Roles:
Prepare Statement
of Work
To identify and document the product’s functional and
nonfunctional requirements. Typically performed as part
for the Requirements Capture Workflow in PUP

Release Definition Document (RDD)

Product Requirements Document (PRD)

Use Cases

Project Manager and Systems Engineer
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
20
Prepare Statement of Work
Prepare
Statement of
Work
Define
Product
Requirements
Execute
Contract
OR
Solicit and
Select Vendor
Purpose:
To describe the work the vendor will perform, when
the work is due, how PB will evaluate the work, and
the working relationship between PB and vendor.
Outputs:


Key Roles:



Statement of Work
Risk analysis
PB Project Manager
Software Contracting Mentor
Engineering Services
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
21
Contents of the Statement of Work
1
Introduction
1.1 Purpose
1.2 Applicable Documents
2
Overall Product Description
2.1 Product Description
2.2 Scope of Work to be Performed
3
Artifacts
3.1 [Artifact Name]
4
Project Planning
5
Project Control
5.1
5.2
5.3
5.4
5.5
5.6
6
Meetings, Reviews, and Conferences
Scope Change Control
Artifact Configuration Control
Build Process
Acceptance Testing
Contract Provision Tracking Matrix
Evaluation Criteria
Appendix A – Roles and Responsibilities
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
22
Risk Analysis and Risk Management
 Both PB and vendor should perform risk analysis.
 Have multiple team members identify risks.






PB Project Manager
Software Contracting Mentor
Systems Engineer
Testers
Marketing/Product Managers
Team Leads
 Use the PUP Risk List template
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
23
What Is Risk Management?
Risk management is the process of
identifying, addressing, and
controlling potential problems before
they threaten the success of a
software or system project.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
24
Areas of Risk
Dependencies
 Customer-furnished items or information
 Inter-component or inter-group dependencies
 Availability of trained, experienced people
 Reuse from one project to the next
 External standards being issued
Refer to Appendix B
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
25
Areas of Risk
Requirements Issues
The
Spec
 Lack of clear product vision
 Requirements are not prioritized
 New customers with uncertain needs
 New applications with uncertain requirements
 Lack of agreement on product requirements
 Rapidly changing requirements
 Ineffective requirements change management process
 Inadequate impact analysis of requirements changes
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
26
Areas of Risk
Management Issues
 Inadequate planning and task identification
 Inadequate visibility into actual project status
 Unclear project ownership and decision making
 Managers or customers with unrealistic expectations
 Ill-defined project roles and responsibilities
 Staff personality conflicts
 Poor communication
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
27
Areas of Risk
Lack of Knowledge
 Inadequate training
 Lack of experience with languages, methods, or tools
 Inadequate application domain experience
 New technologies or development methods
 Ineffective, poorly documented, or neglected processes
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
28
Areas of Risk
 Professional attitude, strong focus on quality
 Reluctance to say “no” or “I don’t understand”




want to save face
might be too agreeable and eager to please
might not ask for help or clarification
can lead to misinterpretations, unresolved issues, and
unachievable commitments
 need to read between the lines
 Might not accept responsibility for problems
 Likely to interpret requirements literally
 Might be cultural differences in UI designs
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
29
Risk Mitigation
Communication
 Time to learn how to work together.
 meet on-site initially to begin building a relationship
 keep some staff at the vendor site if possible
 build long-term vendor relationships
 Times when both parties are available.




plan for national holidays, work schedules, vacations.
rotate the inconvenience for meetings and reviews
log questions and issues for overnight handling
schedule nightly handoffs carefully
 Common tools.
 change control, version control, issue tracking
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
30
Risk Mitigation
 Date formats vary, so use the name of the month.
 Watch out for English/metric system conversions.
 Learn about passport and visa issues for vendor staff.
 Going through Customs can delay shipping by weeks.
 learn Customs rules
 expect to pay high duties
 shipping by cargo can be faster than by courier
 Use “non-employee” to identify co-ops,
trainees, and apprentices.
 Check into staff turnover rates.
 Respect U.S. export control laws.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
31
An Approach for Risk Management
Identify
Track
• plan group session
• participants identify risks
• hold group session
Analyze
• individuals rate probability
and impact
• collate into single risk list
• identify top 10 risks
• track status
regularly
• take corrective
actions if needed
Control
Plan
• determine approaches
• assign responsibility
• implement mitigation approaches
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
32
Documenting Risks
#
Risk Description
P I
E
Impact Description
Mitigation Strategy and/or
Responsibility
Contingency Plan
Date
Submitted
Date
Resolved
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
P = probability of risk taking place (1-3)
I = impact if risk does happen (1-3)
E = total risk exposure from this risk item, = P * I




Quantify relative impact of each risk
Identify mitigation approaches for each risk
Assign responsibility and due dates
Record risks in the risk list
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
33
Exercise: Risk List
 List some risk categories that might threaten the success
of your contracted project. Select from the lists on the
previous slides.
 Identify several risks from each of your categories.
 Develop actions for the top 2 risks
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
34
Solicit and Select Vendor
 Activity only required if the vendor is not already known for
the project
 Consists of 4 sub-activities




Define Proposal Evaluation Criteria
Prepare RFP Package
Solicit Vendor Proposals
Select Vendor
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
35
Define Proposal Evaluation Criteria
Define Proposal
Evaluation
Criteria
Prepare
Statement of
Work
Prepare
Request for
Proposal
Purpose:
To determine how PB will evaluate vendor
proposals to select the best one.
Outputs:

Proposal evaluation criteria using template
Key Roles:



Software Contracting Mentor
PB Project Manager
Systems Engineer
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
36
Proposal Evaluation Template
Criteria
Architecture
Interfaces to External Functions
Proposed Hardware and Third Party Software
Proposed Middleware
Software Development Process
Project Planning
Change Management
Configuration Management
Design, Code and Test Review Process
Defect Tracking
Unit Test Plan and Process
System Test Procedures
Requirements Understanding
Acceptance Testing Methodology
Oversight Process
System Support
Maintenance Updates
Training
Post Deployment Support
Pricing
Vendor Experience
Release Processes
Transition Plan
TOTAL
RATED CRITERIA
Vendor A
Vendor B
Vendor C
Vendor D
Vendor E
Weight
Raw Rated
Raw Rated
Raw Rated
Raw Rated
Raw Rated
Score Score Score Score Score Score Score Score Score Score
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Refer to Proposal Evaluation
Template
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
37
Optional Exercise: Proposal Evaluation Criteria
 Select your own proposal evaluation criteria, starting with
the list given.
 Change or add individual criteria.
 Assign weights to the criteria.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
38
Prepare Request for Proposal
Prepare RFP
Package
Define Proposal
Evaluation
Criteria
Solicit Vendor
Proposals
Purpose:
To prepare an invitation to prospective vendors
to submit bids for the project.
Outputs:

Request for Proposal Package
Key Roles:

Software Contracting Mentor
PB Legal department
PB Project Manager
Enterprise Procurement



[Bud Porter-Roth, Request for Proposal, Addison-Wesley, 2002]
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
39
Request for Proposal Template
1
OVERVIEW
1.1
1.2
1.3
2
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
Purpose
Document Organization
Definitions
ADMINISTRATIVE INFORMATION
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
Proposal Due Date and Time Table
Issuing Office Contact Information
Oral presentation
Clarifications, Addenda and
Interpretations
Free and Open Competition
Vendor Representation
Mandatory Requirements
Reservation of Pitney Bowes
Rights
News Releases
Vendor Qualification
Changes in RFP
RFP Text Availability
Return Date
Technical Manuals
Alternate Responses
3
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
Response Duration
Product Support
Demonstration of Proposed Items
System Performance
Pricing Commitment
Discounts and Allowances
Direct Support
Tax Provisions
Vendor Evaluation
Gratuities
Contracting and Notification
Vendor Incurred Costs
RESPONSE FORMAT AND CONTENT
3.1
3.2
3.3
3.4
3.5
3.6
www.processgroup.com
Response Submission
Response Authority
General Appearance
Response Organization
Economy of Responses
Additional Recommendations
Version 1.2 PGv2-PBv3
40
Solicit Vendor Proposals
Prepare RFP
Package
Purpose:
Outputs:
Key Roles:
Solicit Vendor
Proposals
Select
Vendor
To send the RFP Package to potential vendors
and invite them to prepare a response with a
proposal that PB will evaluate.
 Nondisclosure agreements
 Proposals from vendors
 Addendum of clarifications to RFP



Enterprise Procurement
Project Manager
Software Contracting Mentor
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
41
Handling Communications With Vendors
 Send RFP Package to contact person on vendor
information sheet.
 Ask vendors to indicate if they intend to bid.
 identify single point of contact at vendor
 Vendor submits questions in writing.
 identify PB single point of contact (Enterprise Procurement)
 share all questions and answers with all
vendors who received RFP Package
 Vendor submits hardcopy proposal.
 specify final submission date
 identify proposal recipient
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
42
Select Vendor
Select
Vendor
Solicit Vendor
Proposals
Execute
Contract
Purpose:
To choose the most appropriate vendor to develop
the contracted software.
Outputs:



Accepted vendor proposal
Issues requiring vendor response
Proposal Evaluation, Due Diligence Investigation
Results, Award Letters, Rejection Letters
Key Roles:



Software Contracting Mentor
PB Project Manager
Enterprise Procurement
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
43
Guidance for Selecting Vendors
Management
Issues
Legal
Issues
Technical
Issues
Financial
Issues
Refer to Appendix C for further information
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
44
Evaluating Proposals
 Make sure every proposal is complete and in good form.
 could invite vendor to make modifications
 Assess proposals using Proposal Evaluation Template.
 use subteams for different categories
 understand the basis for vendor’s estimates
 Contact references that vendor provided.
 Arrange for site visit if possible.
 Select primary and alternate vendor.
 identify issues and questions for vendor
 confirm that vendor still wants a contract
 Notify rejected vendors.
 Complete Proposal Evaluation Template.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
45
Completed Evaluation Template
Criteria
Architecture
Interfaces to External Functions
Proposed Hardware and Third Party Software
Proposed Middleware
Software Development Process
Project Planning
Change Management
Configuration Management
Design, Code and Test Review Process
Defect Tracking
Unit Test Plan and Process
System Test Procedures
Requirements Understanding
Acceptance Testing Methodology
Oversight Process
System Support
Maintenance Updates
Training
Post Deployment Support
Pricing
Vendor Experience
Release Processes
Transition Plan
TOTAL
RATED CRITERIA
Vendor A
Vendor B
Vendor C
Vendor D
Vendor E
Weight
Raw Rated
Raw Rated
Raw Rated
Raw Rated
Raw Rated
Score Score Score Score Score Score Score Score Score Score
50%
7
3.5
0
0
0
0
100%
6
6
0
0
0
0
100%
5
5
0
0
0
0
50%
6
3
0
0
0
0
100%
7
7
0
0
0
0
100%
4
4
0
0
0
0
100%
6
6
0
0
0
0
100%
4
4
0
0
0
0
100%
4
4
0
0
0
0
50%
8
4
0
0
0
0
100%
7
7
0
0
0
0
100%
5
5
0
0
0
0
100%
7
7
0
0
0
0
100%
8
8
0
0
0
0
100%
8
8
0
0
0
0
50%
9
4.5
0
0
0
0
75%
6
4.5
0
0
0
0
100%
6
6
0
0
0
0
100%
7
7
0
0
0
0
100%
8
8
0
0
0
0
75%
8
6
0
0
0
0
100%
7
7
0
0
0
0
100%
10
10
0
0
0
0
0
0
0
0
0
134.5
0
0
0
0
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
46
Communicating With Your Vendor
 Establish communication plans with vendor.
 Address frequency and content of:
 regular teleconference meetings
 periodic status reports
 technical and management reviews
 Define conditions for senior management review.
 Agree on how to document risks, issues, decisions.
 Define communication methods.
 phone, e-mail, videoconference, face-to-face
 Web-based groupware tools
 plan for the additional costs
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
47
Software Development Plan Reality Check
 Do all the needed resources really exist?
 Does the plan address the agreed-upon scope?
 Are all expected deliverables in the plan?
 Are the estimates plausible at the 50% confidence level?
 Are contingency buffers included for growth and risks?
 Are any tasks missing?
 Are roles and responsibilities clear?
 Are there early milestones?
 Is the critical path clear?
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
48
Execute Contract
Execute
Contract
Select
Vendor
Purpose:
Manage
Contracted
Project
To document legal commitments PB and vendor are making to
each other.
 In some cases, a Master Services Agreement will be in place (MSA)
and the Statement of Work will form the contract.
 In other cases, both a Statement of Work (SOW) and separate
contract are required.
Outputs:


Executed Contract
Contract Provision Tracking Matrix
Key Roles:





PB legal department
Vendor legal department
PB Project Manager
Enterprise Procurement
Software Contracting Mentor
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
49
Contents of a Contract
 Statement of work and technical requirements
 Terms, conditions, and payment schedule
 License and confidentiality agreements
 Dependencies between vendor and PB
 Work products the vendor will deliver
 Milestones for formal management status reviews
 Performance monitoring and evaluation procedures
 Performance bonuses and penalties
 Conditions and procedures for changing the contract
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
50
Legal Aspects of Contracting
Pitney Bowes Legal Department
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
51
Negotiating Open Issues
 Think win-win.
 Consider long-term collaboration goals.
 Ensure that the point under dispute is mutually understood.
 Practice principled negotiation.
 Focus on interests, not positions.
 understand the underlying interests
 make sure you’re addressing the real issue
 deal with reality, not fantasy
 Separate the people from the problem.
 Invent options for mutual gain.
 Base discussions on objective data.
[Roger Fisher, et al., Getting to Yes: Negotiating Agreement Without Giving In, Penguin USA, 1991]
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
52
Contract Bonuses and Penalties
 Performance incentives
 monetary bonus for exceeding schedule and
quality requirements
 equity stake or shared IP ownership
 Performance penalties
 X% per month later than committed
 Risks of penalties and incentives
 don’t reward speed at the expense of quality
 penalties won’t motivate vendor who is already
losing money
 bonuses for time-and-materials contracts can
motivate excessive quality practices
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
53
Sample Performance Bonuses and Penalties
Contract: Supplier-tested code available: 12 months
Defects discovered in system test: <2.0/KLOC
Defects discovered after delivery: <0.2/KLOC
Bonus:
Penalty:
5%:
10%:
20%:
10%:
Supplier-tested code available 1 month early
Defects discovered in system test: 1.0-1.5/KLOC
Defects discovered in system test: 0.5-1.0/KLOC
Defects discovered after delivery: <0.1/KLOC
5%: For each month supplier-tested code is late
5%: For each additional 0.5 defects/KLOC discovered in
system test over 2.0 defects/KLOC
5%: For each additional 0.2 defects/KLOC discovered
after delivery to customers over 0.2 defects/KLOC
[from Neal Whitten, Managing Software Development Projects: Formula for Success, 1995]
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
54
Contingency Plans for Nonperforming Vendor
 Develop objective criteria for evaluating vendor progress.
 Deal with problems proactively and promptly.
 Attempt to resolve problems through negotiation first.
 follow your dispute-resolution process
 escalate if necessary
 Plan what actions you’ll take if you must terminate contract.




bring the work in-house
switch to a second vendor
re-scope the project
cancel or postpone the project
 Consider a second source for some work.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
55
Manage Contracted Project
Execute
Contract
Purpose:
Outputs:
Key Roles:
Manage
Contracted
Project
Close Out
Contracted
Project
To track actual progress against plans, resolve issues with
vendor, and manage change.
 Project status reports
 Review meeting summary reports
 Action items from status reports
 Accepted deliverables
 Updated Contract Provision Tracking Matrix
 Software Contracting Mentor
 Vendor and PB Project Managers
 Vendor and PB Senior Management
 Enterprise Procurement
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
56
Exercise: Project Management Problems
List several problems related to project planning or tracking you
have encountered. For each, describe the problem, its
impacts, and any root causes. Pick 1-2 problems and develop
improvement actions.
Example
Problem:
Vendor replaces key team member.
Impact:
Critical knowledge, skills, and time are lost.
Root cause:
You didn’t have management commitment to
keep key individuals on project.
Actions:
Train PB team members, invoke contract
provisions, replan project section for when
resource is available.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
57
Tracking Project Status
 Vendor project manager provides weekly or biweekly status report to PB
Project Manager.
 Software Contracting Mentor updates Contract Provision Tracking
Matrix
 Carefully review the status reports.
 Consider use of Team Services Project Websites, PUP Project Status
Assessment template
 Watch out for:






late, missing, or incomplete reports
unexplained cost, schedule, or effort deviations
reports that don’t jibe with reality
known risks that don’t appear
current issues being treated as risks
overdue action items, issues, or
dependencies by vendor or PB
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
58
A Possible Status Report Template
 Management summary
 Project performance assessment
 can use color () indicators
 include metrics summary to date
 examples: schedule, budget, resources, requirements status,
change management, staffing, training, technical infrastructure
 Major milestone table
 original plan, current plan, actual completion dates
 Progress against, and deviations from, plan
 Current risk list
 Current issues and action items
 status, who is responsible, target date for resolution
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
59
Some Metrics for Tracking Progress
 Size
 lines of code, function points, classes, size of executables
 Time
 planned and actual duration between milestones
 Cost
 planned and actual expenditures to date
 Defects
 number of defects found, open, and closed
 defect origin and classification
 Status
 percent of requirements implemented and verified
 satisfaction of performance or other quality goals
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
60
Monitoring Risks
 Assign ownership of each risk to an individual.
 Ensure that mitigation actions are implemented.
 Maintain a “Top 10” risk list.
 conduct periodic senior management review
 assess effectiveness of mitigation approaches
 watch for risks that persist on the Top 10 list
 Look for new risks.
10 tons
uh-oh...
 Retire obsolete risks.
 If risks materialize, treat them as issues.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
61
Managing Issues
 Maintain an issue log.
 ID, date identified, description, who’s responsible, target date
 track issues to closure
 resolve PB-side issues quickly
 Define a corrective action process.
 steps to take if issues aren’t resolved
 need a clear chain of command and scope of authority
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
62
Managing Changes
1. The Pitney Bowes Project Manager creates a scope change request
by completing the first page of the Scope Change Impact Analysis
Template.
2. The vendor provides an impact analysis by completing the Scope
Change Impact Analysis.
3. The Pitney Bowes Project Manager assembles a review team made
up of personnel appropriate for the changes being proposed.
4. Once the review team has approved the scope change request, the
Pitney Bowes Project Manager informs the vendor of the decision
by faxing the approved Scope Change Impact Analysis.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
63
Warning Signs of Trouble
 Uncompleted action items or failed dependencies
 Unqualified vendor or PB staff; staff turnover
 Missing, incomplete, or incorrect deliverables
 Processes that aren’t working well or are bypassed
 Unimplemented or unrequested functionality
 Reviews that aren’t performed
 Slow decision-making
 Missed early milestones
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
64
Deliverable Acceptance Criteria
 Pass means no major problems encountered.
 Fail means major problem encountered, such as:








installation or integration failure
GPF or similar abnormal termination
UI or control functions that don’t work correctly
violations of UI or interface standards, constraints, or
business rules
failure to achieve performance or other quality attribute goals
failure to build correctly in PB’s environment
unimplemented requirements
supporting deliverables or documentation missing
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
65
Deliverable Acceptance Procedures
 Define procedures to follow for evaluation.
 user acceptance test
 peer review
 standards check
 Determine who will accept and evaluate delivered products.
 Define how to report defects to vendor.
 defect origin might dictate who pays for correction
 Acceptance testing doesn’t replace a full system test!
 focus on high-probability usage scenarios
 check major exception conditions
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
66
Exercise: Acceptance Criteria
 Define several appropriate acceptance criteria for your
project.
 What documents to accept, acceptance criteria + how to
evaluate?
 What products to accept, acceptance criteria + how to
evaluate?
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
67
Skills and Knowledge Transfer
 Rely on multiple information exchange channels.
 Have a PB employee work alongside a criticalskilled vendor employee late in the project
 documentation
 design models
 peer reviews
 pair programming
 telephone coaching
 collaborative problem-solving
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
68
Manage Contracted Project
Refer to Appendices D, E and F for
further information
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
69
Close Out Contracted Project
Manage
Contracted
Project
Close Out
Contracted Project
Purpose:
To collect data and insights from completed
projects and record lessons learned for the
future.
Outputs:

Key Roles:

Vendor performance review
Letter of Closure to vendor



PB Project Manager
Software Contracting Mentor
Enterprise Procurement
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
70
Retrospectives: What and Why
 What’s a “retrospective”?
 a review conducted at the end of a project
or phase to consider how it went and identify
ways to perform future work more effectively
 also called post-project review, postmortem,
debriefing, after-action report
 Look for:




what went well? (repeat it!)
what didn’t go so well? (change it!)
what happened that surprised you? (manage risks!)
what still puzzles us? (figure it out!)
 Create action plans to address improvement items.
[Norman L. Kerth, Project Retrospectives, Dorset House, 2001]
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
71
Summary:
Software Contracting Traps to Avoid
 Poor requirements specification and scope management
 Selecting an inappropriate vendor
 Taking a fire-and-forget approach to the contract
 Gaining inadequate insight into the technical products
 Failing to respond quickly to vendor questions and needs
 Ignoring early warning signs of trouble
 Unsubstantiated assumptions
 Questions of intellectual property ownership
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
72
Software Contracting
Process and Guidance
NO
SURPRISES!
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
73
Contracting References - 1
Carnegie Mellon University/Software Engineering Institute. The Capability Maturity Model:
Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley, 1995.
Carnegie Mellon University/Software Engineering Institute. “Software Acquisition Capability
Maturity Model (SA-CMM) Version 1.03. Technical Report CMU/SEI-2002-TR-010, 2002.
Creating and Managing the Outsourcing Relationship. Arlington, MA: Cutter Consortium,
2001.
Hooks, Ivy F., and Kristin A. Farry. Customer-Centered Products: Creating Successful
Products Through Smart Requirements Management, New York: AMACOM, 2001.
IEEE Std 1062-1998, “IEEE Recommended Practice for Software Acquisition.” IEEE
Standards: Software Engineering, 1999 Edition, Volume One: Customer and Terminology
Standards. New York: The Institute of Electrical and Electronics Engineers, 1999.
IEEE Std 1058-1998, “IEEE Standard for Software Project Management Plans.” IEEE
Standards: Software Engineering, 1999 Edition, Volume Two: Process Standards. New York:
The Institute of Electrical and Electronics Engineers, 1999.
Kerth, Norman L. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset
House Publishing, 2001.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
74
Contracting References - 2
McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Redmond, Wash.:
Microsoft Press, 1996.
McConnell, Steve. Software Project Survival Guide. Redmond, Wash.: Microsoft Press, 1998.
Porter-Roth, Bud. Request for Proposal: A Guide to Effective RFP Development. Boston,
Mass.: Addison-Wesley, 2002.
Project Management Institute. A Guide to the Project Management Body of Knowledge.
Newtown Square, Penn.: Project Management Institute, 2000.
Whitten, Neal. Managing Software Development Projects: Formula for Success, 2nd Ed. New
York: John Wiley & Sons, 1995.
Wiegers, Karl E. Software Requirements, 2nd Ed. Redmond, Wash.: Microsoft Press, 2003.
Wiegers, Karl. “See You In Court.” Software Development, vol. 11, no. 1 (January 2003), pp.
36-40.
Wiegers, Karl E. Peer Reviews in Software: A Practical Guide. Boston, Mass.: AddisonWesley, 2002.
Wysocki, Robert K., Robert Beck Jr., and David B. Crane. Effective Project Management, 2nd
Ed. New York: Wiley, 2000.
Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group.
www.processgroup.com
Version 1.2 PGv2-PBv3
75