SRT Software Acquisition Best Practices

1. ISO/IEC 14598—Software Product Evaluation
2. IEEE 1062-1998—Recommended Practice for Software Acquisition
3. Control Objectives for Information and Related Technology (COBIT)
4. Capability Maturity Model Integration for Acquisition (CMMI-ACQ)
5. Information Technology Infrastructure Library (ITIL)

One of the difficulties faced by front-line IT executives is the challenge of converting these theoretical frameworks for software acquisition into practice through the use of hands-on software procurement tools.

With that in mind, I'll point you toward practical software acquisition tools and approaches that will help you meet requirements set forth in these best software acquisition practices.

On this page:

• Overview of Leading Software Acquisition Practices and Standards
• Reconciling the Principles of Software Acquisition Practices and Standards
• Tools for Implementing Software Acquisition Practices and Standards: Converting Theory into Practice

Before we get into the leading software acquisition practices and standards, note that they all owe a debt of gratitude to Herbert A. Simon (1916-2001), a pioneer in the field of artificial intelligence (AI) and recipient of the 1978 Nobel Prize in Economics. In 1977, Simon divided the rational decision-making process into the 4 following steps known as IDC-R:

• Intelligence: a first step involving research, discovery, collection, classification, processing, and presentation of the information, the facts and the problems.
• Design: the next step, which covers formalization, modeling, simulation of alternatives and forecasting of potential outcomes.
• Choice: selection of the best alternative by seeking to maximize expected utility (UE).
• Review: implementation of the chosen alternative, generation of status reports, and measurement of results.

The first step, intelligence, is responsible for structuring, or framing, the problem, while the remaining steps (design, choice, and review) address the solution to the problem. Together, the 4 steps comprise Simon's IDCR framework. (This framework is sometimes referred to as the "IDC-R" framework, to connote the fact that Simon himself saw the review portion as something of an optional afterthought.)

The software acquisition practices we examine below are simply elaborations and reformulations (and in some cases, subsets) of the IDCR framework.

Overview of Leading Software Acquisition Practices and Standards

For background on methods and tools for implementing software acquisition practices and standards, I'll provide a brief description of the frameworks, along with the components of software acquisition practices as described by these documents.

Software acquisition practices standard #1: ISO/IEC 14598—Software Product Evaluation

About ISO/IEC 14598 (from the Introduction to ISO/IEC 14598):

The ISO/IEC 14598 series of standards give methods for measurement, assessment and evaluation of software product quality. They describe neither methods for evaluating software production processes nor methods for cost prediction (software product quality measurements may, of course, be used for both these purposes).

Note that ISO/IEC 14598 was created by a joint technical committee comprised of ISO and IEC (ISO/IEC JTC1).

Best-practice components of ISO/IEC software acquisition practices:

• Evaluation process
• Establish evaluation requirements
  • Establish the purpose of evaluation
  • Identify types of product(s) to be evaluated
  • Specify quality model
• Specification of the evaluation
  • Select metrics
  • Establish rating levels for metrics
  • Establish criteria for assessment
• Design of the evaluation
  • Produce evaluation plan
• Execution of the evaluation
  • Take measures
  • Compare with criteria
  • Assess results

Software acquisition practices standard #2: IEEE 1062-1998—Recommended Practice for Software Acquisition

Executive Overview of IEEE 1062-1998

IEEE 1062-1998 is a set of useful quality practices that can be selected and applied during one or more steps in a software acquisition process is described. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.

Selected IEEE components of software acquisition practices:

• Software acquisition process
  • Planning organizational strategy
  • Implementing organization's process
  • Defining the software requirements
  • Identifying potential suppliers
  • Preparing contract requirements
  • Evaluating proposals and selecting supplier
  • Managing for supplier performance
  • Accepting the software
  • Using the software

Software acquisition practices standard #3: Control Objectives for Information and related Technology (COBIT)

Module 2: Acquire and Implement

Executive Overview of COBIT

COBIT is a framework and supporting tool set that allow managers to bridge the gap with respect to control requirements, technical issues and business risks, and communicate that level of control to stakeholders. COBIT enables the development of clear policies and good practice for IT control throughout enterprises… COBIT has become the integrator for IT good practices and the umbrella framework for IT governance that helps in understanding and managing the risks and benefits associated with IT.

Selected COBIT components of software acquisition practices (from Module 2: Acquire and Implement):

• Identify automated solutions
  • Definition and maintenance of business functional and technical requirements
  • Risk analysis report
  • Feasibility study and formulation of alternative courses of action
  • Requirements and feasibility decision and approval
• Acquire and maintain application software
  • High-level design
  • Detailed design
  • Application control and auditability
  • Application security and availability
  • Configuration and implementation of acquired application software
  • Major upgrades to existing systems
  • Development of application software
  • Software quality assurance
  • Applications requirements management
  • Application software maintenance
• Acquire and maintain technology infrastructure
  • Technological infrastructure acquisition plan
  • Infrastructure resource protection and availability
  • Infrastructure maintenance
  • Feasibility test environment
• Enable operation and use
  • Planning for operational solutions
  • Knowledge transfer to business management
  • Knowledge transfer to end users
  • Knowledge transfer to operations and support staff
• Procure IT resources
  • Procurement control
  • Supplier contract management
  • Supplier selection
  • IT resources acquisition
• Manage changes
  • Change standards and procedures
  • Impact assessment, prioritization, and authorization
  • Emergency changes
  • Change status tracking and reporting
  • Change closure and documentation
• Install and accredit solutions and changes
  • Training
  • Test plan
  • Implementation plan
  • Test environment
  • System and data conversion
  • Testing of changes
  • Final acceptance test
  • Promotion to production
  • Post-implementation review

Software acquisition practices standard #4: Capability Maturity Model Integration for Acquisition (CMMI-ACQ)

CMMI (Capability Maturity Model Integration) for Acquisition: (SSAD) (Level-2 Acquisition Capability) / (DAR) (Level-3 Support Capability)

Executive Overview of CMMI-ACQ

CMMI-ACQ provides a comprehensive set of best practices for acquiring products and services. CMMI for Development (CMMI-DEV) may be treated as a reference for supplier-executed activities for systems engineering, software development, and hardware design work in an acquisition initiative [SEI 2006a]. In those cases where the acquirer also has a role as a product or service developer (e.g., taking responsibility for the first few layers of product development and integration), CMMI-DEV (in particular the Requirements Development, Technical Solution, and Product Integration process areas) should also be used to improve the acquirer's product or service development processes.

Key takeaway for software acquisition practices:

Acquisition Planning—i.e., defining an acquisition strategy and writing an acquisition plan—is a basic requirement of project management (PM)—a key process area (KPA) defined in CMMI-ACQ under Project Planning (PP).

Following the acquisition plan template suggested ensures the acquisition plan is repeatable—which is mandatory for the project management key process area to reach capability level 2, which in turn will help the organization reach maturity level 2.

It's worth mentioning that the acquisition plan template helps also the acquisition process reach higher capability levels (and helps the organization reach correspondingly higher maturity levels) as the acquisition process becomes standardized and institutionalized (level 3), quantitatively measured (level 4), and continuously improved (level 5).

Selected process areas of the CMMI model for software acquisition practices:

Solicitation and Supplier Agreement Development (SSAD) (Level-2 Acquisition Capability)

• Prepare for solicitation and supplier agreement development
  • Identify potential suppliers
  • Establish a solicitation package
  • Review the solicitation package
  • Distribute and maintain the solicitation package
• Select suppliers
  • Evaluate proposed solutions
  • Establish negotiation plans
  • Select suppliers
• Establish supplier agreements
  • Establish an understanding of the agreement
  • Establish the supplier agreement

Decision Analysis and Resolution (DAR) (Level-3 Support Capability):

• Evaluate alternatives
  • Establish guidelines for decision analysis
  • Establish evaluation criteria
  • Identify alternative solutions
  • Select evaluation methods
  • Evaluate alternatives
  • Select solutions

Software acquisition practices standard #5: Information Technology Infrastructure Library (ITIL)

ITIL does not contain a software acquisition practices module as such. For software acquisition practices, it is preferable to refer the frameworks mentioned above. Note, however, that the research think tank IT Governance Institute has mapped the crossover between ITIL and COBIT in its document COBIT Mapping: Mapping of ITIL v3 With COBIT 4.1 (see page 19) [ITGI membership required].

Tools for Implementing Software Acquisition Practices and Standards: Converting Theory into Practice

We'll turn now to tools for implementing software acquisition practices and standards.

Because best software acquisition practices involve the management of large amounts of information, manual manipulation of this data is really not feasible. But how do you use tools and computational support to implement these best software acquisition practices?

In accordance with Simon's IDCR framework, the first mandate of software selection tools is to absorb complexity and guide you through the correct decision process towards the right specific decision. Software selection tools, also called decision support systems (DSS), are computer-based tools that can help you make a better decision by combining large amounts of data with sophisticated analytical models.

Ready-to-use software selection tools are available, at various levels of efficiency, to provide proportional savings in cost and time.

As with any tool, however, software selection tools simply provide support. Their role is to structure and present information to you can make an enlightened decision. They do not, however, make the decision for you.

That's why you should always challenge any conclusions.

Well-designed software selection tools address this situation. Some tools with advanced features allow you to create what-if scenarios, robustness analysis and sensitivity analysis. With these features, you can quickly determine which criteria have the most impact on your decision. You can then focus on mitigating the specific risks associated with the most important factors.

One last thought:

In order to convert theories about software acquisition practices into actionable acquisition plans that meet best-practice requirements, you must ensure all the ingredients are in place:

Framework + Tools + Data + People

Together, these ingredients comprise a formal methodology for software acquisition practices.

Well-thought software acquisition methodologies incorporate Simon's IDCR framework and accommodates acquisition framework standards by providing a variety of tools and resources that can save time and reduce the manual intervention that so often brings the software selection process to a grinding halt:

Phase	Resources and tools	How they help	Software acquisition practices framework reference
Intelligence	RFP Templates	Obtain clear information about the facts and problems organizations like yours face during the software acquisition process. Determine which software vendors are likely to provide software that will meet your organizational requirements.	ISO/IEC 14598 Establish evaluation requirements IEEE 1062-1998 Defining the software requirements COBIT (Module 2: Acquire and Implement) Definition and maintenance of business functional and technical requirements CMMI (SSAD/Level-2 Acquisition Capability) Establish a solicitation package
Design	Software Evaluation Reports	Use hierarchical models of software features and functions to create the software model that is most appropriate for your organization.	ISO/IEC 14598 Specification of the evaluation Select metrics Establish rating levels for metrics Establish criteria for assessment IEEE 1062-1998 Identifying potential suppliers COBIT (Module 2: Acquire and Implement) Identify automated solutions CMMI (SSAD/Level-2 Acquisition Capability) Select suppliers Evaluate proposed solutions
Choice	Decision Support Systems (DSS) [comparison, sensitivity analyses, what-if scenarios]	Compare and select the best alternative, using data provided by enterprise software vendors.	ISO/IEC 14598 Execution of the evaluation Take measures Compare with criteria Assess results IEEE 1062-1998 Preparing contract requirements Evaluating proposals and selecting supplier COBIT (Module 2: Acquire and Implement) Identify automated solutions Definition and maintenance of business functional and technical requirements CMMI (DAR/Level-3 Support Capability) Evaluate alternatives Establish guidelines for decision analysis Establish evaluation criteria Identify alternative solutions Select evaluation methods Evaluate alternatives Select solutions
Review	Implementation Review and Auditing	Audit each implementation milestone and provide detailed reports to brief stakeholders on the progress of the implementation, and coordinate resources to keep the project on track and prevent scope creep.	ISO/IEC 14598 Execution of the evaluation Assess results COBIT (Module 2: Acquire and Implement) Install and accredit solutions and changes Training Test plan Implementation plan Test environment System and data conversion Testing of changes Final acceptance test Promotion to production Post-implementation review

Back to Table of Contents

Get free enterprise software comparisons