copyright © 2003 by karl e. wiegers. modifications & additions copyright © 2004 the process...

Copyright © 2003 by Karl E. Wiegers. Modifications & additions Copyright © 2004 The Process Group. www.processgroup.com Version 1.2 PGv2-PBv3 1

Software Contracting Process and Guidance

Neil Potter, Mary SakryThe Process Group

P.O. Box 700012Dallas, TX 75370-0012

Tel. 972-418-9541Fax. 972-618-6283

E-mail: [email protected]: http://www.processgroup.com

Licensed from Karl E. Wiegers

Version PBv3 contains Pitney Bowes templates and modifications


Course Objectives

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.

At the end of this workshop you will be able to:


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


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


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


Some Key Software Contracting Issues

Cultural Differences

Knowledge and Skills Transfer

Use of Effective Processes

Accurate and Complete Requirements

Communications

Active Project and Risk Management

Issue Management

IntellectualProperty

Ownership

Infrastructure

Time Zones


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.

[email protected]


• Your job.• Contracting problems / issues?• Expectations for this class (e.g., 5/5 score?)

Your Class Expectations


Some Definitions

Legally binding agreement of project terms

Organization that contracts to build product

Pitney Bowes (PB) description of project and invitation to vendors to bid

PB description of work to be performed by vendor

Request for Proposal

Vendor

Statement of Work

Contract


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.


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 identifiedas points of contact.

Impact: Time is wasted as vendor attempts to getquestions answered.

Root cause: Unclear project roles and responsibilities.


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)


Software Contracting Process


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


Process Roles

PB Staff: Vendor Staff:

Project ManagerSenior ManagementLegal DepartmentTechnical Staff

Software Contracting MentorProject ManagerSystems EngineerLegal DepartmentEnterprise ProcurementTechnical StaffSenior ManagementTest LeadSoftware Configuration Manager (SCM)Software Quality Engineer (SQE)


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.


Process Overview

A2

PrepareStatementof Work

A3

Solicit andSelectVendor

A4

ExecuteContract

A5

ManageContracted

Project

A6

Close OutContracted

Project

A1

Define ProductRequirements

IF VENDOR NOT ALREADYIDENTIFIED FOR PROJECT

REQUIREMENTSCAPTURE WORKFLOW


Process Overview

A3.1

DefineProposal

EvaluationCriteria

A3.2

PrepareRFP

Package

A3.3

SolicitVendor

Proposals

A3.4

SelectVendor

A2

PrepareStatementof Work

A4

ExecuteContract

Solicit and Select Vendor (ACTIVITY NOT REQUIRED IF VENDOR KNOWN)


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.


Define Product Requirements

Define Product Requirements

Purpose: To identify and document the product’s functional and nonfunctional requirements. Typically performed as part for the Requirements Capture Workflow in PUP

Outputs: Release Definition Document (RDD)

Product Requirements Document (PRD)

Use Cases

Key Roles: Project Manager and Systems Engineer

Process Entry Criteria

Prepare Statement of Work


Prepare Statement of Work

Prepare Statement of

Work

Define Product

Requirements

Execute Contract

ORSolicit 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: Statement of Work Risk analysis

Key Roles: PB Project Manager Software Contracting Mentor Engineering Services


Contents of the Statement of Work

1 Introduction1.1 Purpose1.2 Applicable Documents

2 Overall Product Description2.1 Product Description2.2 Scope of Work to be Performed

3 Artifacts3.1 [Artifact Name]

4 Project Planning

5 Project Control5.1 Meetings, Reviews, and Conferences5.2 Scope Change Control5.3 Artifact Configuration Control5.4 Build Process5.5 Acceptance Testing5.6 Contract Provision Tracking Matrix

6 Evaluation Criteria

Appendix A – Roles and Responsibilities

SOW


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


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.


Areas of Risk

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

Dependencies


Areas of Risk

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

Requirements IssuesTheSpec


Areas of Risk

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

Management Issues


Areas of Risk

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

Lack of Knowledge


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


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


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.


An Approach for Risk Management

IdentifyIdentify

• plan group session• participants identify risks• hold group session

AnalyzeAnalyze

• individuals rate probabilityand impact

• collate into single risk list• identify top 10 risks

PlanPlan

• determine approaches• assign responsibility

ControlControl

• implement mitigation approaches

TrackTrack

• track statusregularly

• take correctiveactions if needed


Documenting Risks

Quantify relative impact of each risk Identify mitigation approaches for each risk Assign responsibility and due dates Record risks in the risk list

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

# Risk Description P I E Impact Description Mitigation Strategy and/or

Contingency Plan

Responsibility DateSubmitted

DateResolved

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.


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


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


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


Proposal Evaluation Template

Raw Score

Rated Score

Raw Score

Rated Score

Raw Score

Rated Score

Raw Score

Rated Score

Raw Score

Rated Score

Architecture 0 0 0 0 0Interfaces to External Functions 0 0 0 0 0Proposed Hardware and Third Party Software 0 0 0 0 0Proposed Middleware 0 0 0 0 0Software Development Process 0 0 0 0 0Project Planning 0 0 0 0 0Change Management 0 0 0 0 0Configuration Management 0 0 0 0 0Design, Code and Test Review Process 0 0 0 0 0Defect Tracking 0 0 0 0 0Unit Test Plan and Process 0 0 0 0 0System Test Procedures 0 0 0 0 0Requirements Understanding 0 0 0 0 0Acceptance Testing Methodology 0 0 0 0 0Oversight Process 0 0 0 0 0System Support 0 0 0 0 0Maintenance Updates 0 0 0 0 0Training 0 0 0 0 0Post Deployment Support 0 0 0 0 0Pricing 0 0 0 0 0Vendor Experience 0 0 0 0 0Release Processes 0 0 0 0 0Transition Plan 0 0 0 0 0

0 0 0 0 0TOTAL 0 0 0 0 0

RATED CRITERIA

CriteriaVendor E

WeightVendor A Vendor B Vendor C Vendor D

Refer to Proposal Evaluation Template


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.


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]


Request for Proposal Template

1 OVERVIEW1.1 Purpose1.2 Document Organization1.3 Definitions

2 ADMINISTRATIVE INFORMATION2.1 Proposal Due Date and Time Table2.2 Issuing Office Contact Information2.3 Oral presentation2.4 Clarifications, Addenda and

Interpretations2.5 Free and Open Competition2.6 Vendor Representation2.7 Mandatory Requirements2.8 Reservation of Pitney Bowes

Rights2.9 News Releases2.10 Vendor Qualification2.11 Changes in RFP2.12 RFP Text Availability2.13 Return Date2.14 Technical Manuals2.15 Alternate Responses

2.16 Response Duration2.17 Product Support2.18 Demonstration of Proposed Items2.19 System Performance2.20 Pricing Commitment2.21 Discounts and Allowances2.22 Direct Support2.23 Tax Provisions2.24 Vendor Evaluation2.25 Gratuities2.26 Contracting and Notification2.27 Vendor Incurred Costs

3 RESPONSE FORMAT AND CONTENT3.1 Response Submission3.2 Response Authority3.3 General Appearance3.4 Response Organization3.5 Economy of Responses3.6 Additional Recommendations




Prepare RFP Package Select

Vendor

Purpose: To send the RFP Package to potential vendors and invite them to prepare a response with a proposal that PB will evaluate.

Outputs: Nondisclosure agreements Proposals from vendors

Addendum of clarifications to RFP

Key Roles: Enterprise Procurement Project Manager Software Contracting Mentor


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


Select Vendor

Select Vendor

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


Guidance for Selecting Vendors

ManagementIssues

FinancialIssues

LegalIssues

TechnicalIssues

Refer to Appendix C for further information


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.


Completed Evaluation Template

Raw Score

Rated Score

Raw Score

Rated Score

Raw Score

Rated Score

Raw Score

Rated Score

Raw Score

Rated Score

Architecture 50% 7 3.5 0 0 0 0Interfaces to External Functions 100% 6 6 0 0 0 0Proposed Hardware and Third Party Software 100% 5 5 0 0 0 0Proposed Middleware 50% 6 3 0 0 0 0Software Development Process 100% 7 7 0 0 0 0Project Planning 100% 4 4 0 0 0 0Change Management 100% 6 6 0 0 0 0Configuration Management 100% 4 4 0 0 0 0Design, Code and Test Review Process 100% 4 4 0 0 0 0Defect Tracking 50% 8 4 0 0 0 0Unit Test Plan and Process 100% 7 7 0 0 0 0System Test Procedures 100% 5 5 0 0 0 0Requirements Understanding 100% 7 7 0 0 0 0Acceptance Testing Methodology 100% 8 8 0 0 0 0Oversight Process 100% 8 8 0 0 0 0System Support 50% 9 4.5 0 0 0 0Maintenance Updates 75% 6 4.5 0 0 0 0Training 100% 6 6 0 0 0 0Post Deployment Support 100% 7 7 0 0 0 0Pricing 100% 8 8 0 0 0 0Vendor Experience 75% 8 6 0 0 0 0Release Processes 100% 7 7 0 0 0 0Transition Plan 100% 10 10 0 0 0 0

0 0 0 0 0TOTAL 134.5 0 0 0 0

RATED CRITERIA

CriteriaVendor E

WeightVendor A Vendor B Vendor C Vendor D


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


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?


Execute Contract

Execute Contract

ManageContracted

Project

Purpose: 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

Select Vendor


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


Legal Aspects of Contracting

Pitney Bowes Legal Department


[Roger Fisher, et al., Getting to Yes: Negotiating Agreement Without Giving In, Penguin USA, 1991]

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.


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


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: 5%: Supplier-tested code available 1 month early

10%: Defects discovered in system test: 1.0-1.5/KLOC

20%: Defects discovered in system test: 0.5-1.0/KLOC

10%: Defects discovered after delivery: <0.1/KLOC

Penalty: 5%: For each month supplier-tested code is late

5%: For each additional 0.5 defects/KLOC discovered insystem test over 2.0 defects/KLOC

5%: For each additional 0.2 defects/KLOC discoveredafter delivery to customers over 0.2 defects/KLOC

[from Neal Whitten, Managing Software Development Projects: Formula for Success, 1995]


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.


Manage Contracted Project

Manage Contracted

Project

Execute Contract

Purpose: To track actual progress against plans, resolve issues with vendor, and manage change.

Outputs: Project status reports Review meeting summary reports Action items from status reports Accepted deliverables Updated Contract Provision Tracking Matrix

Key Roles: Software Contracting Mentor Vendor and PB Project Managers Vendor and PB Senior Management Enterprise Procurement

Close Out Contracted

Project


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.

ExampleProblem: 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.


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


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


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


10 tons

uh-oh...

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.

Retire obsolete risks.

If risks materialize, treat them as issues.


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


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.


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


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


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


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?


Skills and Knowledge Transfer

Rely on multiple information exchange channels. Have a PB employee work alongside a critical-

skilled vendor employee late in the project documentation design models peer reviews pair programming telephone coaching collaborative problem-solving


Manage Contracted Project

Refer to Appendices D, E and F for further information


Close Out Contracted Project

Close Out Contracted Project

Manage Contracted

Project

Purpose: To collect data and insights from completed projects and record lessons learned for the future.

Outputs: Vendor performance review Letter of Closure to vendor

Key Roles: PB Project Manager Software Contracting Mentor Enterprise Procurement


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 identifyways 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]


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


Software Contracting Process and Guidance

NONOSURPRISES!SURPRISES!

NONOSURPRISES!SURPRISES!


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.


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.: Addison-Wesley, 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...

Documents

process group

wiegers version pbv3

process templates

key software

uthe software

process uprocess steps

software product uthink

project management