Software Contracting Process and Guidance

1. 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 Software Contracting Process and Guidance

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

3. 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

4. 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

5. 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

6. Some Key Software Contracting Issues Communications Cultural Differences Infrastructure Issue Management IntellectualProperty Ownership Time Zones Active Project and Risk Management Use of Effective Processes Knowledge and Skills Transfer Accurate and Complete Requirements

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

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

9. 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 Contract Vendor Request for Proposal Statement of Work

10. 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 datafor project tracking.

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

12. 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)

13. Software Contracting Process

14. Software Contracting Process • Based on industry standards • Capability Maturity Model for Software • Software Acquisition CMM • CMMI/SE-SW • IEEE Std 1062-1998, “Recommended Practicefor Software Acquisition” • Incorporates industry best practices for software contracting, requirements engineering, project management • Defines roles, responsibilities, process steps, deliverables • Includes many PB templates

15. Process Roles Vendor Staff: PB 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

16. 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.

17. Process Overview

18. Process Overview

19. 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.

20. Process Entry Criteria Prepare Statement of Work 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 Define Product Requirements

21. Execute Contract OR Solicit and Select Vendor Define Product Requirements Prepare Statement of Work Prepare Statement of Work 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

22. SOW Contents of the Statement of Work 1Introduction 1.1Purpose 1.2Applicable Documents 2Overall Product Description 2.1 Product Description 2.2 Scope of Work to be Performed 3Artifacts 3.1[Artifact Name] 4Project Planning 5Project Control 5.1Meetings, Reviews, and Conferences 5.2Scope Change Control 5.3Artifact Configuration Control 5.4Build Process 5.5Acceptance Testing 5.6Contract Provision Tracking Matrix 6Evaluation Criteria Appendix A – Roles and Responsibilities

23. 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

24. 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.

25. 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

26. The Spec 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 Issues

27. 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

28. 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

29. 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

30. 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

31. 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.

32. Identify • plan group session • participants identify risks • hold group session Track Analyze • individuals rate probabilityand impact • collate into single risk list • identify top 10 risks • track statusregularly • take correctiveactions if needed Control Plan • determine approaches • assign responsibility • implement mitigation approaches An Approach for Risk Management

33. 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

34. 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

35. 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

36. Prepare Statement of Work Prepare Request for Proposal Define Proposal Evaluation Criteria Define Proposal Evaluation Criteria 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

37. Proposal Evaluation Template Refer to Proposal Evaluation Template

38. 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.

39. Define Proposal Evaluation Criteria Solicit Vendor Proposals Prepare Request for Proposal 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 Prepare RFP Package [Bud Porter-Roth, Request for Proposal, Addison-Wesley, 2002]

40. Request for Proposal Template 2.16 Response Duration 2.17 Product Support 2.18 Demonstration of Proposed Items 2.19 System Performance 2.20 Pricing Commitment 2.21 Discounts and Allowances 2.22 Direct Support 2.23 Tax Provisions 2.24 Vendor Evaluation 2.25 Gratuities 2.26 Contracting and Notification 2.27 Vendor Incurred Costs 3 RESPONSE FORMAT AND CONTENT 3.1 Response Submission 3.2 Response Authority 3.3 General Appearance 3.4 Response Organization 3.5 Economy of Responses 3.6 Additional Recommendations 1 OVERVIEW 1.1 Purpose 1.2 Document Organization 1.3 Definitions 2 ADMINISTRATIVE INFORMATION 2.1 Proposal Due Date and Time Table 2.2 Issuing Office Contact Information 2.3 Oral presentation 2.4 Clarifications, Addenda and Interpretations 2.5 Free and Open Competition 2.6 Vendor Representation 2.7 Mandatory Requirements 2.8 Reservation of Pitney Bowes Rights 2.9 News Releases 2.10 Vendor Qualification 2.11 Changes in RFP 2.12 RFP Text Availability 2.13 Return Date 2.14 Technical Manuals 2.15 Alternate Responses

41. Prepare RFP Package Select Vendor Solicit Vendor Proposals 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 Solicit Vendor Proposals

42. 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 allvendors who received RFP Package • Vendor submits hardcopy proposal. • specify final submission date • identify proposal recipient

43. Solicit Vendor Proposals Select Vendor 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 Select Vendor Execute Contract

44. ManagementIssues LegalIssues FinancialIssues TechnicalIssues Guidance for Selecting Vendors Refer to Appendix C for further information

45. 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.

46. Completed Evaluation Template

47. 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

48. 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?

49. Manage Contracted Project Select Vendor Execute Contract 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 Execute Contract

50. 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