The objective of this master’s thesis is to provide guidelines from the viewpoint of the customer for managing an acquisition project concerning an outsourced development of a software product customized for the specific needs of the customer. The objective is further broken down into seeking answers to the following problems:
• What problems are common?
• What activities should be performed?
• What roles are conceivable?
• What artifacts are conceivable?
• How can the activities, roles, and artifacts be customized for different kinds of projects?
7 Results and summary
© Daniel Svennberg 2001 117
The guidelines presented in this thesis can be used as a basis for planning an acquisition project or be read as an overview over the many issues that concern software acquisitions.
The following summarizes the answers to each of the above stated questions briefly:
What problems are common?
The most common problems with software acquisition projects are the following:
• Development costs exceeds budget.
• Time schedule is overrun.
• Outcome does not meet expectations.
According to the Standish Group (1995) Chaos report, which surveyed over 8 000 software development projects, only 16%
of the examined projects were completed on time, within budget, and with all features and functions as initially speci-fied.
What activities should be performed?
There are many activities that can and should be performed for software acquisition projects. In this thesis they have been col-lected into the following eleven processes:
• Project steering
• Project management
• Planning and organizing
• Acquisition training
• Requirements management
• Risk management
• Contractor selection
• Contract management
• Product evaluation
• Transition to support
• Post partum
The activities and guidelines presented in the processes can be summarized into the following high-level activities and guide-lines:
1. Define and communicate a goal and vision for the pro-ject.
2. Appoint an acquisition manager that has the ultimate re-sponsibility for the success of the project. The role of the project sponsor is to set the outer limits for the project, provide stable and adequate funding and to support the project enthusiastically or cancel it.
3. Adapt and customize the acquisition approach and strat-egy according to the characteristics of the project.
4. Avoid having too much administration, but as a mini-mum: have written requirements and agreements, docu-ment important decisions and why they were taken, also measure progress, software quality, and requirements changes quantitatively.
5. Know what you want. Have as stable, complete, feasible, and validated requirements as possible. It is important to have a defined scope so that you and the contractor
know when you are done and when the contract needs to be changed.
6. Define how the fulfillment of each requirement will be evaluated.
7. Ensure end user involvement in the definition of the product requirements and in the evaluation of the prod-uct.
8. Tell the contractor what you want and not how to do it.
Jointly review the requirements before the development starts to sort out misunderstandings and ambiguities.
9. Choose contractor carefully. The contractor with the low-est bid or most optimistic schedule and budget low-estimates
7 Results and summary
© Daniel Svennberg 2001 119
isn’t always the best choice. No management practices can make up for having a bad contractor.
10. Create an effective, functional, supporting, and collabora-tive culture in the relationship with the contractor based on trust and mutual benefit. Both parties should realize that they have a mutual responsibility for the success of the project. The involved parties should work as a team, jointly solve problems, and refrain from blaming each other.
11. Establish effective communication channels and break down barriers between people and departments in the organizations involved in the project. Ensure that you understand each other.
12. Don’t take advantage of the contractor. Create a win-win situation. Have a mutually beneficial contract that you would be comfortable signing as either party.
13. Expect the best, but be proactive and prepare for all even-tualities. Jointly discuss possible risks and how they should be mitigated with the contractor.
14. Employ the best and most competent people that is pos-sible, train them, plan and organize their work. Provide necessary assistance and resources.
15. Plan for maintenance and identify the maintenance and support organization before issuing request for propos-als.
16. Evaluate the evolving software product early and often prior to final acceptance evaluation to reduce risk of get-ting a software product that won’t meet the needs of the end user.
17. Perform reality checks periodically. Take necessary ac-tions if the answers to the following quesac-tions aren’t sat-isfactory:
o Are we acquiring the right software?
o Are we acquiring the software right?
o Is the contractor building the right software?
o Is the contractor building the software right?
18. Be realistic and reassess your expectations as you learn more about the problem domain and the technical feasi-bility of the program as the project progresses. The initial estimates and specifications of the following four pa-rameters are likely to change to some degree during the course of the project:
o Delivery time o Development costs o Product scope o Product quality
You may therefore need to make trade-offs to achieve the most important goal of the project.
What roles are conceivable?
The roles that are conceivable for a software acquisition project can be divided into four categories:
The sponsor roles provide the funding for the project and have the power to cancel the project. The sponsor roles presented in this thesis are the following: sponsor, collaborating customer, and product manager.
The managing roles plans, manages, monitors, and administers the project. The managing roles presented in this thesis are the following: acquisition manager, technical manager, contract manager, and administrator.
The assisting roles are played by different experts and support contractors that can assist and give advise to the managing, steering and executing roles. The assisting roles presented in this thesis are the following: acquisition expert, technical expert, domain expert, legal expert, translator, end user, maintenance and support staff, independent verification and validation, and system engineering and technical assistance.
The executing roles are played by representatives from the con-tractors side, i.e. those developing the actual software product.
7 Results and summary
© Daniel Svennberg 2001 121
The executing roles presented in this thesis are the following:
contractor, collaborating contractor, and subcontractor.
What artifacts are conceivable?
There are many artifacts that are conceivable for a software quisition project. The artifacts in this thesis are presented ac-cording to which phase of the project they are most likely to appear for the first time:
During the inception phase the needs of the software are iden-tified, the requirements are elicited, risks are analyzed, and the acquisition processes are planned. The artifacts presented in this thesis for the inception phase are the following: acquisition proposal, project specification, acquisition plan, risk list, re-quirements specification, and maintenance plan.
During the solicitation phase requests for proposals are sent out to potential contractors, proposals are received and evalu-ated, and a contractor is selected with which a contract is nego-tiated and signed. The artifacts presented in this thesis for the solicitation phase are the following: request for proposal, con-tractor evaluation criteria, proposal, and contract.
During the monitoring phase the progress and performance of the contractor is monitored and the software product is evalu-ated on a regular basis. The artifacts presented in this thesis for the monitoring phase are the following: project management plans, test reports, problem reports, payment requests, progress reports, change requests, quality reports, software demonstra-tions and incremental releases, product evaluation plan, prod-uct evaluation report, change request, and project status report.
During the finalization phase the product and other deliver-ables are delivered to the support and maintenance organiza-tion and a post partum review is held. The artifacts presented in this thesis for the finalization phase are the following: software executables, source code, technical documentation, user train-ing material, rest list, user manual, support publications, post partum plan, and post partum.
How can the activities, roles, and artifacts be customized for different kinds of projects?
To answer that question we must first find a way to differenti-ate projects. This thesis examines a number of customization fac-tors that are used to suggest an appropriate formality level of the acquisition processes based upon the project’s complexity and risk.
By examining these factors you can determine which customiza-tion level is appropriate for your project. Three different cus-tomization levels are given in the thesis:
Minimal processes: suitable for small projects with stable, well-defined and attainable requirements, developed by a small, ef-ficient team from a well-known contractor, etc.
Controlled processes: suitable for somewhat lengthier me-dium-sized projects with somewhat volatile requirements, de-veloped by an average contractor, etc.
Robust processes: suitable for large, long-term projects, with innovative, critical, and volatile requirements, and with a com-plex set of contractors and subcontractors involved in the de-velopment effort, etc.
The thesis suggests what activities are appropriate for the dif-ferent customization levels, and also gives some suggestions for customization of roles and artifacts.