Professional Documents
Culture Documents
MANAGEMENT GUIDELINES
by
Daniel Svennberg
A Thesis
submitted for the Degree of
Master of Science
LiTH-IDA-Ex-01/32
LiTH-IDA-Ex-01/32
Linköpings Universitet,
Institutionen för Datavetenskap
Linköping University
Fraunhofer, Maryland,
Fraunhofer, Inc.
Center for Experimental Software Engineering
i
Acknowledgements
D.S.
ii
Table of Contents
Abstract.................................................................................i
Acknowledgements ............................................................ii
1 Introduction ...............................................................1
1.1 Background.............................................................................1
1.2 Target audience......................................................................2
1.3 Objective .................................................................................2
1.4 Problems .................................................................................2
1.5 Scope ........................................................................................3
1.6 Approach.................................................................................3
1.7 Outline.....................................................................................4
3 Customization .........................................................20
3.1 Customization levels ..........................................................20
3.2 Customization factors.........................................................21
3.2.1 Product characteristics............................................................22
3.2.2 Effort........................................................................................24
3.2.3 Contracting environment .......................................................26
3.2.4 Other factors ...........................................................................28
iii
Table of Contents
4 Roles ........................................................................29
4.1 Sponsor roles........................................................................29
4.1.1 Sponsor....................................................................................29
4.1.2 Collaborating customer...........................................................30
4.1.3 Product manager.....................................................................30
4.2 Managing roles ....................................................................30
4.2.1 Acquisition manager...............................................................30
4.2.2 Technical manager ..................................................................32
4.2.3 Contract manager ...................................................................32
4.2.4 Administrator .........................................................................32
4.3 Assisting roles......................................................................33
4.3.1 Acquisition expert...................................................................33
4.3.2 Technical expert ......................................................................33
4.3.3 Domain expert.........................................................................33
4.3.4 Legal expert .............................................................................34
4.3.5 Translator................................................................................34
4.3.6 End user ..................................................................................34
4.3.7 Maintenance and support staff ...............................................34
4.3.8 Independent verification and validation .................................35
4.3.9 System engineering and technical assistance .........................35
4.4 Executing roles.....................................................................36
4.4.1 Contractor ...............................................................................36
4.4.2 Collaborating contractor .........................................................37
4.4.3 Subcontractor..........................................................................37
4.4.4 Supplier ...................................................................................37
5 Artifacts ...................................................................38
5.1 Inception ...............................................................................39
5.1.1 Acquisition proposal ...............................................................39
5.1.2 Project specification ................................................................40
5.1.3 Acquisition plan......................................................................41
5.1.4 Risk list....................................................................................43
5.1.5 Requirements specification .....................................................44
5.1.6 Maintenance plan ...................................................................46
5.2 Solicitation............................................................................47
5.2.1 Request for proposal ................................................................47
5.2.2 Contractor evaluation criteria ................................................49
5.2.3 Proposal...................................................................................50
5.2.4 Contract...................................................................................51
5.3 Monitoring............................................................................53
6 Processes................................................................60
6.1 Overview...............................................................................60
6.2 Project steering ....................................................................66
6.3 Project management ...........................................................69
6.4 Planning and organizing ...................................................72
6.5 Acquisition training ...........................................................74
6.6 Requirements management ..............................................76
6.7 Risk management................................................................78
6.7.1 Risk identification ...................................................................80
6.8 Contractor selection ............................................................85
6.8.1 Contract types .........................................................................88
6.9 Contract management.........................................................96
6.9.1 Project status metrics............................................................100
6.9.2 Earned value..........................................................................102
6.10 Product evaluation ............................................................106
6.10.1 Product evaluation approaches .............................................109
6.11 Transition to support........................................................110
6.12 Post partum.........................................................................113
8 Bibliography..........................................................124
A Frameworks coverage..........................................129
A.1 SA-CMM .............................................................................129
A.2 FAA-iCMM.........................................................................130
A.3 IEEE 1062.............................................................................131
A.4 ISO 9000-3 ...........................................................................132
Index.......................................................................137
1.1 Background
Many organizations have a need to acquire customized soft-
ware products that meet special demands that no commercial
off-the-shelf product can meet. Many times the most efficient
and economically viable solution to obtain the software is to
outsource the development to a contractor instead of develop-
ing the software in-house.
1.3 Objective
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.
1.4 Problems
The objective stated above can be broken down into seeking an-
swers to the following problems:
1.5 Scope
The management of custom-made software product acquisi-
tions will be examined – not services. Fully or partially devel-
oped products are the main concern – not commercial off-the-
shelf products. The acquirer’s point of view is mainly ad-
dressed – not the contractor’s. Legal aspects will not be exam-
ined further than contract contents. The issues will be examined
from a business perspective instead of a governmental or mili-
tary perspective.
1.6 Approach
An introductory study of the subject was performed by reading
the thesis of the German student (Assmann, 2000), the different
frameworks listed in section 2.6, Frameworks, on page 16, web
pages, and articles on software acquisition, and performing in-
terviews with Jaak Urmi, Östen Oskarsson, and Mats Ran. This
gave an understanding of the concepts of software acquisition
management and a number of ideas on how to formulate the
guidelines and provide answers to the problems stated above.
The guidelines described in this thesis are not a new model for
software acquisition management, but an attempt to extract, as-
semble, and integrate advice from the existing models and
frameworks and present them as management processes, check-
lists for artifacts, descriptions of roles, and customization fac-
tors. The option would have been to describe the guidelines in a
more prosaic fashion, but that would have made the sugges-
tions for customization less logical and to the point.
1.7 Outline
The following is a description of the contents of each chapter in
the report:
6
2 Software Acquisition Environment
Waterfall Spiral XP
Analysis
Design
Coding
Testing
Scope
2.4 Outsourcing
There are many different reasons for outsourcing a software
development project, such as the following examples:
• You don’t get any indirect labor hours since you don’t
have your own development staff.
Haimes, et al. (1997) states that there are three groups of partici-
pants in a software acquisition project, each with separate goals:
Participant Objective
C V C V
One V
Client
Simple Dyadic Multi-Vendors
C C V
C V C V
Many
C C V
Clients
Co-Sourcing Complex
Successful
Canceled 16%
31%
Challenged
53%
2.6 Frameworks
The following is a list of frameworks that in some way gives
guidance on software acquisition management. Apart from
standards, books and collections of guidelines are mentioned.
20
3 Customization
Requirements volatility
Since software development is a creative process, and it is diffi-
cult to anticipate all technical problems beforehand, change of
requirements occur more or less in all software development
projects. However, due to the nature of the problem the soft-
ware is to solve, the total set of requirements can be more or
less change-prone.
Program size
The estimated program size indicates the effort that is needed
to build the software. The values given in the table below are to
be considered as suggestions since program size depends on
what language is used and other factors.
Criticality
Criticality is the impact malfunctioning software will have on
people’s safety and the magnitude of financial loss that can re-
sult, according to Oskarsson and Glass (1996).
Minimal proc- People’s safety is not at risk, nor will any signifi-
esses suffi- cant amount of money be lost if the software mal-
cient functions.
Innovation
Oskarsson and Glass (1996) define innovative projects as those
in which the problem is new and different and hasn’t been
solved with computer programs before. Less innovative pro-
jects use mature and proven technology.
Transformational impact
Transformational impact is the depth of change that the deliv-
ered software product will have on the user’s behavior and the
user organization’s processes and products.
3.2.2 Effort
The effort customization factors delivery time, total cost, and de-
velopment team size are implied by the estimated effort to build
the software. The estimate is based on the product characteris-
tics. The larger the effort is the higher formality is required to
avoid unnecessary chaos.
Delivery time
Delivery time is the estimated calendar time for delivery of the
finished software product. With a longer project there is a
higher likelihood that new people will join the development
team and others leave. Change in the requirements is also more
likely. The values given in the table below are to be considered
as suggestions.
Controlled 12 – 36 months.
processes
recommended
Total cost
Total cost is the estimated total cost to acquire the software in
order of magnitude. The value ranges of low, medium, and
high in the table below are difficult to specify since these values
may change over time and are only given as suggestions.
Controlled 10 – 30 developers.
processes
recommended
Organizations involved
The more organizations, such as stakeholders, supporting con-
tractors, consultants, independent testing organizations, etc. are
involved, the more communication is needed to coordinate the
work.
Geographic dispersion
Management becomes more difficult with customer and con-
tractor on different geographical sites.
4.1.1 Sponsor
The sponsor initiates and supports the software acquisition pro-
ject enthusiastically but also has the power to cancel it if it will
cost more to finish than will be gained from finishing the pro-
ject. The responsibilities of the project sponsor are:
29
4 Roles
• To manage the budget for the project within the limits set
by the sponsor.
4.2.4 Administrator
The administrative burden depends on the size and type of pro-
ject. One should be careful not to over-administrate. Other
members of the acquisition team perform the tasks of the ad-
ministrator role, but for some projects a specific person can be
assigned this role. The responsibilities of the administrator role
include:
4.3.5 Translator
A translator is, according to Salwin (1998), a role that can be
played by a person that is good at translating layman’s terms
into technical terms and vice versa. This can be useful in speci-
fying the requirements and transferring the requirements to the
technical staff of the contractor. This person should be skilled at
translating the needs of the customer into something that the
developers can use to build the system.
• Technical risk.
• Independent testing.
• Management support.
• Integration.
4.4.1 Contractor
The contractor can be a sole contractor or a prime contractor in
case several collaborating contractors are used. Choose contrac-
tor carefully – the contractor with the lowest bid or most opti-
mistic schedule and budget estimates isn’t always the best
choice. No management practices can make up for having a bad
contractor. Once selected, the contractor should be seen as a
team member and not an adversary. The responsibilities of the
contractor are:
4.4.3 Subcontractor
The contractor can use subcontractors to deliver parts of the
software. The competence and capabilities of the subcontractor
needs to be evaluated, and you as a customer should have the
right to decide which subcontractor should be used. If the con-
tractor is using subcontractors, make sure that they are in-
volved as soon as possible in the project.
4.4.4 Supplier
It might be necessary to deal with a supplier of COTS and/or
hardware during the course of the project.
Many of the artifacts are documents, and there are many rea-
sons to document something, such as the following:
38
5 Artifacts
5.1 Inception
During the inception phase the needs of the software are identi-
fied, the requirements are elicited, risks are analyzed, and the
acquisition processes are planned.
Contents checklist
Describe the organization’s needs for the software prod-
uct and how they are related to the organization’s objec-
tives. What is the background of the needs? What is the
current situation? What justifies the needs for the soft-
ware?
Contents checklist
Describe the organization’s needs.
Conceptualize the software product and give operational
scenarios. What will the software have done?
Define the purpose of the project. State the acquisition
project’s goal and vision in specific, measurable, accepted,
realistic, and time-based terms. Specify the expected out-
come of the project in terms of total cost, delivery time,
product scope, and product quality, etc.
Specify the initially identified product requirements and
their relative priorities.
Describe any identified risks.
Specify funding and time bounds.
Identify and give instructions regarding interfaces and
collaborations with other projects.
Identify legal issues, such as intellectual property rights,
etc.
Specify any external constraints, such as standards, regu-
lations, interfacing systems, etc.
Give instructions on security, access to information, and
confidentiality issues.
List potential contractors and/or capabilities that can be
used for identifying potential contractors, such as re-
quired competence, etc.
Describe routines for reporting project status. See the
Project status report on page 56.
Contents checklist
Describe the project’s background. Why is the project
done? What is its purpose? State the project’s objectives.
State the project funding and schedule bounds.
Define the terminology that will be used in the acquisition
project.
Describe what tools, techniques, and methods will be
used.
Describe any standards, laws, practices, and conventions
that are to be followed.
Determine problem resolution procedures.
Specify documentation requirements and procedures.
Specify configuration and change management proce-
dures.
Describe collaborations and interfaces with external or-
ganizations, support contractors, etc. and how the respon-
sibilities are divided between the involved organizations.
Specify communication and reporting channels. List im-
portant addresses, etc.
Determine acquisition project team inter-group coordina-
tion and division of responsibilities.
Outline a master budget for the different processes.
Outline a master schedule describing the chosen acquisi-
tion life cycle and appropriate milestones.
Specify security, access to information and confidentiality
procedures.
Describe how public relations issues will be handled.
Describe routines for reporting project status
Describe how measurements will be collected, analyzed
and used.
Contents checklist
Risk identification.
Risk classification.
Date of last update.
Risk description, i.e. condition and consequences.
Probability of risk occurring.
© Daniel Svennberg 2001 43
5 Artifacts
Contents checklist
State the project goals. Which goal is the most important
one in case a trade-off decision needs to be made?
Describe the software product in general terms; what is
the background for acquiring the software, what is its us-
age domain, what type of product is it, etc.
Contents checklist
Identify the members of the support and maintenance or-
ganization, their respective responsibilities, and how they
are organized.
Describe any collaborations and interfaces with other
groups and organizations.
5.2 Solicitation
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.
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.
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.
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
property rights, etc.
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.
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.
• Project plans.
• Test reports.
• Problem reports.
• Payment requests.
• Progress and status reports.
• Change requests.
• Quality reports.
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.
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.
Contents checklist
State what should be changed.
State who originated the request.
© Daniel Svennberg 2001 55
5 Artifacts
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.4 Finalization
During the finalization phase the product and other deliverables
are delivered to the support and maintenance organization and
a post partum review is held.
5.4.1 Deliverables
The deliverables received from the contractor could consist of
some of the following artifacts, depending on the actual project:
• Software executables.
• Source code.
• Technical documentation.
• User training material.
• Rest list – lists requirements not implemented and known
errors.
• User manual.
• Support publications.
Contents checklist
Determine who should attend the post partum. Preferably
representatives from all involved organizations and roles
should participate.
Determine when to hold the post partum. Preferably
within 7-14 days after project completion.
Select an appropriate location for the post partum. Pref-
erably away from the office.
Determine the length of the post partum. 2-4 hours may
be sufficient for minimal projects while 3 days could be
needed for robust projects.
Determine the rules for the post partum in order to create
a non-threatening environment.
Contents checklist
Give the background for the project and the time of
events in the project.
Document the customization factors values (see the
Customization factors on page 21) for the project.
Compare project goals to actual outcome regarding the
deliverables, time schedule, costs, etc. Indicate deviations
and the reasons for them.
Document what processes and methods were used and
how the project was organized. Document how the pro-
ject was customized.
Document special difficulties and measures taken and the
effect of these measures.
Document the performance of the contractor and other
involved organizations – their strengths and weaknesses.
If earned value was used – document SPI, CPI, etc.
6.1 Overview
The different aspects of managing a software acquisition project
have been divided into the following eleven processes:
• Project steering
• Project management
• Planning and organizing
• Acquisition training
• Requirements management
• Risk management
60
6 Processes
• Contractor selection
• Contract management
• Product evaluation
• Transition to support
• Post partum
Process name
Possible start condition for the Possible end condition for the
process. process.
Process group
Project steering
Project management
Planning and organizing
Acquisition training
Requirements management
Risk management
Contractor selection
Contract management
Product evaluation
Transition to support
Post partum
Inception Solicitation Monitoring Finalization
Figure 5 below shows how the processes are related to the dif-
ferent roles and major artifacts. The numbers in the figure refer
to the following example of a sequence of major activities from
all process customization levels:
Acquisition
proposal
Sponsor Domain expert Technical
8 7 expert
1
Project Risk Requirements
steering management management 15
2 18 End user
10
Contractor Maintenance
Legal expert evaluation plan
Contractor selection
criteria
5
Acquisition 20
expert
Figure 5. Overview of the software acquisition processes, major roles
and artifacts.
10. The proposals from the bidding contractors along with data
gathered from audits and background checks are compared
Starts when the idea of the Ends when the project is ter-
project is established. minated.
None.
Input: Output:
Spread knowledge.
For long-term projects it might be of value to arrange semi-
nars where different team members share their knowledge to
the other team members.
Starts when the needs for the Ends when the software has
software have been identified. been transitioned to the sup-
port and maintenance organi-
zation.
None.
A. External risks
Risk category Problem examples Possible impact
A.1 Natural hazards Storm, flood, earth- Destruction of equip-
and accidents quake, fire, etc. ment and stored data.
A.2 Crime Vandalism, sabotage, Destruction and theft
theft, hacking, crack- of property and data.
ing, etc.
A.3 Political unrest Revolution, war, etc. Cancellation of project.
Starts when the initial set of Ends when the contract has
requirements has been elicited. been awarded.
Select contractor.
Select the winning contractor based upon all available data
on the contractors such as the proposals (see page 50), even-
tual audits, previous customer comments, previous data on
contractor performance, etc. Remember that the lowest bid
doesn’t necessarily mean the lowest total cost.
Administration Moderate
Administration High
Administration High
Administration High
Administration High
should be determined.
Administration Low
MT – (Fa + Fc + Fd)
SMI=
MT
• Developmental progress. Function points completed, re-
quirements completed, incremental releases, modules
completed, etc. (Marciniak and Reifer, 1990)
• Milestones completed. Actual vs. planned, see the figure
below. (Oskarsson, 2000)
Time
Replan 2
Replan 1
1 2 3 4 Time
Milestones
Figure 6. Milestone tracking and trend diagram, Oskarsson (2000).
d. Responsible person.
e. Responsible department.
An example
Assume you have a one-year $100,000 project scheduled with
an expenditure rate of $25,000 per quarter. At the end of the
first quarter the actual expenditures are $22,000 and thus $3,000
under the planned effort. From these values you can’t really tell
whether the project is behind schedule or underrunning costs.
Testable requirements
Peter B. Wilson (2000) suggests the use of testable requirements
with earned value. A testable requirement is defined as a re-
quirement that someone is able to write one or more test cases
for that would validate whether the requirement has or has not
been implemented correctly.
Earned Value
SPI =
Planned Value
This value tells you how much of the work planned to be ac-
complished actually was accomplished. A SPI < 1.0 is a warning
signal. The SPI can be a valuable tool for use in conjunction
with critical path analysis to forecast the expected completion
date for the project.
Earned Value
CPI =
Actual Costs
This value tells you how much work was accomplished for
every project dollar spent. A CPI < 1.0 is a warning signal. The
CPI can be used to forecast a statistical range of estimated final
costs to complete the project.
© Daniel Svennberg 2001 105
6 Processes
Recovery tests forces the software to fail and verifies that the
system recovers properly. (Ibid.)
Starts when the software re- Ends when the software and
quirements are being devel- other deliverables have been
oped. turned over to the support or-
ganization.
are to install, maintain and support the product such as the fol-
lowing roles: acquisition manager, technical manager, contract
manager, administrator, technical expert, domain expert, legal
expert, maintenance and support staff, and contractor, collabo-
rating contractor, and subcontractor.
Starts when the project has Ends when the project has
been finalized. been sufficiently reviewed and
documented for future refer-
ence.
1Post partum means “after birth” in Latin. I find this to be a more appro-
priate name for the process instead of the more common term post mortem,
which means “after death.”
next time?
None.
116
7 Results and summary
• Project steering
• Project management
• Planning and organizing
• Acquisition training
• Requirements management
• Risk management
• Contractor selection
• Contract management
• Product evaluation
© Daniel Svennberg 2001 117
7 Results and summary
• Transition to support
• Post partum
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.
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.
The thesis suggests what activities are appropriate for the dif-
ferent customization levels, and also gives some suggestions for
customization of roles and artifacts.
7.2 Outlook
Software acquisition management involves a wide variety of
topics ranging from general management theory to special is-
sues regarding software testing, contract types, risk manage-
ment, etc. It isn’t possible for a single document to cover any of
these topics completely. Therefore, the reader probably needs to
study texts that cover these topics in depth to gain a better un-
derstanding on how to carry out a successful software acquisi-
tion project.
122 Software Acquisition Management Guidelines
7 Results and summary
A.1 SA-CMM
Guidelines SA-CMM
129
A Frameworks coverage
A.2 FAA-iCMM
Guidelines FAA-iCMM
tion’s process
A.7 Euromethod
Guidelines Euromethod
tract completion
CMMI ...........................................17
A code and fix .....................................8
Acquisition expert......................... 33 Collaborating contractor................37
Acquisition manager..................... 30 Collaborating customer .................30
Acquisition plan............................ 41 Commercial-off-the-shelf..............7
Acquisition proposal..................... 39 Common problems ........................13
Acquisition training ...................... 74 communications ...........................16
Administrative overload............. 15 configuration management.........71
Administrator................................ 32 Contract .........................................51
Alpha tests ................................. 109 Contract management....................96
Approach......................................... 3 Contract manager ..........................32
Artifacts ........................................ 38 Contract types................................88
Assisting roles............................... 33 Contracting environment...............26
Assmann ........................... 2, 3, 4, 85 contractor ... i, 2, 3, 9, 10, 11, 18, 33,
Audit....................................... 87, 98 34, 35, 36, 47, 50, 56, 57, 58, 59,
auditor ......................................... 100 64, 65, 73, 74, 81, 94, 97, 109
award incentives ........................... 88 Contractor development team
characteristics ............................27
B Contractor development team size 25
baseline ....................................... 103 Contractor evaluation criteria........49
best practices................................. 89 Contractor selection.......................85
Beta tests .................................... 109 Controlled processes ...................21
co-sourcing....................................12
C Cost and cost share.......................92
C/SCSC....................................... 102 cost incentives ...............................88
Capability Maturity Model ........... 17 Cost performance index ..............105
Capability Maturity Model Cost plus award fee.......................95
Integration ................................ 17 Cost plus fixed fee.........................93
Change request ............................. 55 Cost plus incentive fee..................94
Chaos” report ................................ 13 Cost plus percentage fee...............93
characteristics of software .............. 6 cost-reimbursable ..........................88
137
Index