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
6 Processes
© Daniel Svennberg 2001 61
• Contractor selection
• Contract management
• Product evaluation
• Transition to support
• Post partum
Each process contain suggestions on what activities to perform for the different project customization levels suggested in chap-ter 3, Customization, on page 20. The process template in the ta-ble below explains how to interpret the process descriptions.
Keep in mind that the activities given in the different customi-zation levels are only suggestions. When planning for an acqui-sition project you can use the suggestions as a basis but you have to remain flexible and adapt to the specific circumstances of the actual project. For instance, if you have a project where all of the factors described in chapter 3, Customization, on page 20, are suggesting minimal processes except for requirements volatility, which suggest robust processes, then you have to consider having most processes minimal, but a higher customi-zation level for requirements management, and as a conse-quence a higher customization level on product evaluation, or other adaptations that fit your needs. And remember: following a process requires discipline.
Process name
Possible start condition for the process.
Possible end condition for the process.
Possible inputs to the process. Possible outputs from the process.
Process group
Roles that could be considered as participants in the process group. The roles that are in bold face are roles that should par-ticipate as a recommended minimum.
Minimal process activities
Activities suitable to perform in a project with minimal pro-ject characteristics.
Additional controlled process activities
Additional activities suitable to perform in a project with controlled project characteristics.
Additional robust process activities
Additional activities suitable to perform in a project with ro-bust project characteristics.
Table 3. Process template explaining the elements of the process de-scriptions.
As an illustration, Figure 4 below depicts at what point in time of the acquisition lifecycle the processes occur.
Figure 4. Timeline of the acquisition processes.
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:
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
6 Processes
© Daniel Svennberg 2001 63
Figure 5. Overview of the software acquisition processes, major roles and artifacts.
management Reports,
requests, etc. Domain expert Technical
expert
1. The sponsor initiates the project steering process. The needs of the organization, and other project concerns are elicited, analyzed, and documented in the acquisition proposal, which serves as a decision basis.
2. If the sponsor decides to initiate the project, the project goal, funding and time bounds, etc. are specified in the project specification.
3. An acquisition manager is appointed.
4. The acquisition manager customizes, plans, and organizes the acquisition project based upon the project specification, possibly with the assistance of an acquisition expert and others. The plan is documented in the acquisition plan.
5. The maintenance and support organization is identified and the maintenance plan is drafted.
6. The acquisition team performs the necessary acquisition training activities.
7. The requirements management process is initiated. The product requirements are elicited with the help from end users, maintenance and support staff, translator, domain experts, and technical experts, etc. The requirements are documented in the requirements specification.
8. The risk management process is initiated. Identified risks are documented in the risk list by the acquisition manager and others.
9. The contractor selection process is initiated with the contrac-tor evaluation criteria being written followed by writing and sending out request for proposals to potential contractors.
The acquisition manager is responsible for this with assis-tance from acquisition expert, legal expert, etc.
10. The proposals from the bidding contractors along with data
6 Processes
© Daniel Svennberg 2001 65
with the contractor evaluation criteria and the most appro-priate contractor is selected.
11. The contract is negotiated, reviewed and signed between the acquisition manager and the manager on the contractor’s side, with the legal expert advising the proceedings.
12. A joint review and discussion of the requirements specifica-tion and each of the parties risk lists is performed prior to commencing development.
13. During the development of the product the contractor deliv-ers project plans, test reports, progress reports, payment re-quests etc. and the software acquisition team gives feedback and takes necessary action.
14. The contractor submits deliverables for evaluation by the software acquisition team on a regular basis. Feedback is given to the contractor through an evaluation report. Possi-bly the software is evaluated by and independent verifica-tion and validaverifica-tion organizaverifica-tion.
15. Changes to requirements are handled and possibly the con-tract is renegotiated.
16. The acquisition team and the contractor collaborate to solve problems, and jointly reviews project status, plans, risk lists, etc. on a regular basis.
17. For lengthier projects it might be necessary to audit the con-tractor with the assistance of a technical expert, etc.
18. The acquisition manager regularly briefs the project spon-sors on the status of the project through a project status re-port. The sponsors use this as a basis for a decision to con-tinue or cancel the project.
19. After the final evaluation and acceptance of the software product it is transitioned to the maintenance and support
organization. The contract is settled, open items are resolved and final payment is made.
20. A post partum is planned and performed. Celebrate a pro-ject well done and document experiences and lessons learned. Remember not to make it a blame session.
A more detailed description of the different activities that can be performed in a software acquisition project are given in the process descriptions that follow.