During the solicitation phase requests for proposals are sent out to potential contractors, proposals are received and evaluated, and a contractor is selected with which a contract is negotiated and signed.
5.2.1 Request for proposal
The purpose of the request for proposal, RFP, is to communicate the scope of the work and the contractual conditions to poten-tial bidders.
Contents checklist
Describe the customer’s company.
State the acquisition project’s goal and vision.
Describe the target domain of the software product.
List the deliverables of the project.
Include the requirements specification (see page 44).
State any issues regarding security, nondisclosure, and confidentiality.
Specify any support, training, installation, and mainte-nance requirements.
Give instructions for bidders regarding the proposal such as: date for reply, number of copies, contents and struc-ture of proposal, etc. See the Proposal on page 50.
State any requirements regarding development practices, quality assurance procedures, standards compliance, con-figuration management, communication and reporting progress and problems, etc.
Specify the contract type (see page 88).
Cost and schedule estimates.
Describe any investment issues, such as facilities and equipment.
Specify the customer’s rights to inspect the bidder’s facili-ties to investigate and evaluate financial position, techni-cal capability, experience, quality practices, etc.
State any legal issues regarding warranties, licenses, own-ership rights, copyright, patent, usage rights, and other intellectual property issues.
Determine use and control of subcontractors and suppli-ers.
Describe identified risks and issues that need to be dealt with.
State any other significant contractual terms and condi-tions, such as constraints. See the Contract on page 51.
5 Artifacts
© Daniel Svennberg 2001 49
5.2.2 Contractor evaluation criteria
The purpose of the contractor evaluation criteria is to give a set of criteria against which the bidding contractors’ proposals will be compared in order to be able to select the most appropriate con-tractor. Be explicit about the minimum standard for each crite-rion. The set of criteria can cover the following issues:
Contents checklist
Technical approach, suggested solution, and understand-ing of the problem.
Proposed mitigation and management of certain risks.
Cost and schedule estimates.
Company and owner history. Any bankruptcies or litiga-tions? How long has the company been in business? What previous customers has the company had?
Contractor stability. Is the organization undergoing any major change, such as changing ownership or moving of-fice, etc?
Outcome of contractor’s previous projects regarding cost, schedule, performance, and quality as well as staffing levels, error rates etc. See Project status metrics on page 100. Comments from customers to previous projects.
Contractor’s financial status. Eventual independent finan-cial rating.
The staff’s experience, competence, constitution, and per-formance.
Technical capabilities.
Management qualifications.
Resources: equipment, tools, facilities, etc.
Location.
Adequacy of software development processes and quality practices.
Previous experience with contractor.
Legal issues regarding warranties, licenses, intellectual property rights, etc.
Adherence to eventual standards.
5.2.3 Proposal
The purpose of the proposal given by the bidding contractor(s) is to present their company, capabilities, suggested solution, esti-mates, advantages, etc.
Contents checklist
Company description. Its background and history.
Previous and current customers. Outcome and data on previous projects.
Financial position.
Understanding of problem, technical approach, solution suggestion, description on how the different requirements will be met.
Technical and managerial capabilities.
Working methods and development processes.
Quality practices.
Resources: equipment, tools, facilities, etc.
Compliance with standards (such as ISO 9000).
Technical and domain experience.
Cost and schedule estimates.
Mitigation and management of risks.
Organization and staffing. Key personnel. The staff’s ex-perience and constitution.
Contact persons and addresses.
Charges, prices, fees and payment issues.
Use of subcontractors and suppliers.
Needed investments in facilities and tools, etc.
Legal issues regarding warranties, licenses, intellectual
5 Artifacts
© Daniel Svennberg 2001 51
5.2.4 Contract
The purpose of the contract is to define the relationship obliga-tions and promises that the customer and contractor make to each other. The contents checklist is based upon Oskarsson (n.d.
a, b), Marciniak and Reifer (1990), and the frameworks in appen-dix A.
Contents checklist
State the purpose of the contract.
Define the terminology used.
State the scope of work. Refer to the requirements specifica-tion (see page 44), which should be attached to the con-tract. Address software and documentation deliverables, support, installation, and training.
Specify the acceptance procedures and criteria such as the following: acceptance test completed with a satisfactory result, installation completed, user training completed, all deliverables received, correction for errors found a de-termined period after delivery are corrected. Specify the quality measures by which the contractor’s work will be evaluated. Describe what constitutes a satisfactory per-formance of the contractor.
Specify procedures and conditions for making modifica-tions or amendments to the scope of work.
Specify who is authorized to make changes in the contract and answer questions from the contractor. Also specify contract change control procedures.
Describe payment conditions, considerations, and amounts. Determine allowable costs, expenses, charges and their variation. Determine when payments are to be made linked to deliverables and milestones. Specify con-cerns regarding taxes, late payments, and interests.
Specify use of incentives for earlier delivery, reduced costs, significant results and achievements, or for use of certain “best practices,” etc. See page 88 for more on in-centives.
Specify any penalties or payment reductions for delays or for not meeting certain requirements, etc. Ran (2000) says that you shouldn’t have penalties unless the risk is
shared, i.e. both sides should lose something. Marciniak and Reifer (1990) state that penalties should only be used to correct a situation in the project or to prevent a similar situation from occurring in the future.
Determine allowable royalty and license fees.
State the timeframe of the contract and issues regarding a final delivery date if that is applicable.
State conditions, provisions and obligations concerning contract termination. The contractor should deliver all material and deliverables that are associated with the con-tract if the concon-tract is terminated and the customer should pay for the work performed so far.
Describe responsibilities for maintenance undertakings.
State ownership rights, copyright, patent, trade secrets, usage rights, licenses, and other intellectual property is-sues.
Describe legal concerns on warranties, representation, in-fringement, limitation of liability, indemnification, non-disclosures, etc.
Describe security policies, nondisclosure, access to infor-mation, and confidentiality issues.
Specify how public relations issues will be handled.
Specify the contractor’s rights and obligations to assign its duties, partition the work, and use subcontractors.
Determine how and where disputes will be solved, and whether an arbitrator should be used.
Specify the relationship between the parties in the con-tract such as joint venture, partnership, employer and employee relationship, etc.
Describe the commitments by the involved parties and the division of responsibilities, obligations, and tasks.
Determine the amount and conditions of customer
in-5 Artifacts
© Daniel Svennberg 2001 53
Specify relationships to other parties involved in the pro-ject, such as IV&V and SETA.
Specify use and replacement of key personnel.
Specify use of facilities and equipment. Also determine any investment issues regarding facilities and equipment.
Establish means for monitoring progress, through WBS, short iterations, milestones, or other means.
Specify the allowable requirements change rate (for fixed price contracts).
Specify procedures for reporting problems and progress.
Determine what status metrics should be reported by the contractor and how often. See the Project status metrics on page 100.
Specify any requirements on the contractor’s software de-velopment, management and quality assurance processes.
Specify any requirements on a software development plan for the project and a latest date to receive the plan from the contractor and what it should contain.
Specify any requirements on the use of COTS or hard-ware or any restrictions on what suppliers to use.
Determine the customer’s inspection rights and proce-dures for audits.
Signatures.
5.3 Monitoring
During the monitoring phase the progress and performance of the contractor is monitored and the software product is evalu-ated on a regular basis.
5.3.1 Artifacts from the contractor
During the monitoring phase some of the communication from the contractor can consist of the following artifacts, depending on the actual project:
• Project plans.
• Test reports.
• Problem reports.
• Payment requests.
• Progress and status reports.
• Change requests.
• Quality reports.
5.3.2 Product evaluation plan
The purpose of the product evaluation plan is to specify the objec-tives, scope, and activities of the different product evaluations.
See Product evaluation approaches on page 109 for a list of differ-ent kinds of evaluations that can be performed.
Contents checklist
Specify who will participate in the evaluation and the re-sponsibilities of each participant.
Describe the objectives and scope of the evaluation.
Give instructions for preparing for, carrying out, and evaluating the results of the product evaluation.
Give a schedule for the evaluation.
Specify what resources are required regarding equipment, tools, materials, documents, facilities, etc.
Determine the test configuration, technical environment, and other prerequisite conditions.
Describe each test case in the evaluation. What require-ments are addressed during each test case? Specify input and expected results for each test case.
Describe the coverage of the test cases in the evaluation.
For instance, for an acceptance test it should be shown that all implemented requirements are covered by the test cases in the evaluation.
5 Artifacts
© Daniel Svennberg 2001 55
State criteria for evaluating and reporting evaluation re-sults. See the Product evaluation report on page 55.
5.3.3 Product evaluation report
The purpose of the product evaluation report is to document the outcomes of a performed product evaluation. See Product evaluation approaches on page 109 for a list of different kinds of evaluations that can be performed.
Contents checklist
Describe the objectives and scope of the evaluation.
State the time for the evaluation, the participants and their responsibilities.
Identify the test configuration, technical environment, and other prerequisite conditions.
Describe any special considerations, simplifications, and assumptions.
List the outcomes of each test case.
Determine whether the coverage of the test cases in the evaluation was sufficient or not.
Summarize all errors and problems encountered.
Analyze the most common errors and identify trends.
State how the errors and problems will be followed-up.
Give recommendations for decisions, such as changes to requirements, acceptance, etc.
5.3.4 Change request
The purpose of the change request is to provide motivation and relevant information to enable an informed decision on whether to approve a change to requirements, contract or plans.
Contents checklist
State what should be changed.
State who originated the request.
Give a justification for the proposed change.
State the priority of the change request.
Describe any assumptions and constraints that affect the change request.
State the impact on cost, time, quality, scope, and risks.
5.3.5 Project status report
The purpose of the project status report is to summarize the status of the project so that it can be used as a basis for a deci-sion on whether to continue the project or cancel it.
Contents checklist
List the status of the risks in the risk list. Any changes?
Any problems that need to be dealt with?
Report results from product evaluations and the contrac-tor’s testing efforts.
Analyze the technical feasibility of the contractor’s ap-proach. State any technical problems or changes in the technical approach.
State any changes to the requirements.
Describe the available resources regarding equipment, tools, materials, documents, facilities, etc. Are the origi-nally planned resources available? Are the resources ap-propriate?
List measurements regarding schedule and budget, etc.
See section 6.9.1, Project status metrics, on page 100.
Identify and analyze trends regarding schedule and budget, etc. Is the project on schedule? Forecast delivery date. How much of the funding have been expended? Is the current funding appropriate? Will the project reach its budget goals?
List the results achieved since the last report. What mile-stones have been accomplished?
Describe ongoing activities.
5 Artifacts
© Daniel Svennberg 2001 57
What actions need to be taken within the project? What actions need to be taken by the sponsor or steering group?
Does the benefits, short-term or long-term, outweigh the predicted remaining costs for acquiring the software?
Give conclusions and recommendations and relate them to project objectives. Should the project continue or be canceled? Any changes to the project direction?