Information Services Procurement Library

Figure 4 displays a model of the ISPL acquisition process. The acquisition process consists of three sequential process steps.

1. Acquisition initiation
2. Procurement (one or more)
3. Acquisition completion

These individual process steps are discussed in more detail in the paragraphs below.

In ISPL the terms target domain and service domain are used quite frequently.

Target domain The target domain is the part of the customer organization that is affected by the service.

Service domain The service domain is the service organization that delivers the service, i.e. the supplier.

The first process to be executed by the customer contract authority within an acquisition is the acquisition initiation process. It consists of two sequential process steps: acquisition goal definition and acquisition planning. The final result of the process is an acquisition plan reflecting an acquisition strategy, along with a clear understanding of systems and services requirements defining the acquisition goal. The acquisition initiation process is illustrated in Figure 5.

A more detailed description of the Acquisition Initiation phase can be found here.

The result of this step is a sufficiently clear understanding of the requirements to the systems and services that are the goal of the acquisition and the costs and benefits for the business and its various stakeholders. This process step consists of four activities:

1. Define the target domain.
2. Refine the definition of the acquisition goal in terms of systems and services requirements.
3. Analyse costs and benefits.
4. Analyse stakes and stakeholders.

The input of business needs is ideally provided by Requirements management processes.

The goal of this phase is to define an acquisition strategy adapted to the situation, plan the main decision points of the acquisition, and establish the acquisition organisation. The acquisition planning phase consists of the following activities:

1. Determine overall service delivery scenarios.
2. Analyse risks.
3. Design acquisition strategy within the risk management framework:
4. Plan the main decision points of the acquisition.
5. Setting-up the customer organisation within the acquisition

Steps two to four are discussed in detail in the chapter #Managing Risks and Planning Deliveries.

Both the acquisition goal definition and acquisition planning are activities within the phase of Acquisition Initiation. A more thorough entry of this phase can be found here.

The procurement step of the ISPL acquisition process embodies the obtaining of one single contract. Note that the acquisition itself can contain multiple procurements. Such a contract consists of one or more projects or ongoing services. The procurement step consists of three sequencing processes:

1. Tendering
2. Contract monitoring
3. Contract completion

The aim of the tendering process is to select a supplier and a proposal for the considered services and systems and to agree with the chosen supplier on a contract in which both parties’ deliveries and responsibilities are defined. A very important aspect of such a contract is the planning of the decision points. The tendering process consists of four different steps:

1. preparation of request for proposal
2. response preparation
3. supplier selection
4. contract preparation and signing

This process aims to monitor the services defined in the contract. It has to ensure that the deliverable and services conform to the requirements in the contract. The most important activity of the contract monitoring process is the execution of the decision points. In the decision point execution the customer organization makes judgments and decisions based on the status of the procurement at any given time.

The aim of this process is to ensure that all outstanding technical and commercial requirements in the procurement contract (that was written and signed in the tendering phase) have been met.

This is the formal completion of all the contracts of the acquisition. The acquisition manager (often this is the customer company's contract authority) has to verify the successful conclusion of all contracts and the achievement of the acquisition goal. The acquisition completion process consists of four activities:

1. Check that all contracts have been completed
2. Assess the achievement of the acquisition goal
3. Decide whether the acquisition is complete
4. Write an acquisition report

The following paragraphs elaborate on the different activities of acquisition completion.

The acquisition manager has to check the completion of the different contracts by checking if each individual contract's completion phase has been achieved and the required reports are written. If necessary the acquisition manager has to trigger the contract completion process for contracts that need it.

Unfortunately, when all individual contracts’ goals are reached this does not automatically mean that the acquisition goal is achieved. In this activity of the acquisition completion the acquisition manager has to verify the customer company's business objectives have been met and there are no missing parts in the acquisition that have been overlooked.

Based on the assessment of the contract completions and the achievement of the acquisition goal the decision whether the acquisition is complete is made. This decision is generally made by the acquisition manager together with representatives of all the organizational authorities concerned with the acquisition. When one or more contracts are not completed or the acquisition goal is not reached this decision requires the involvement of the customer company's organizational authorities.

The acquisition manager has to write an acquisition report. This report's purpose is to record all decisions made during the acquisition process, the level of acquisition completion, and lessons-to-be-learned for future acquisitions. Interesting data to be included in the acquisition report:

• Real costs and duration versus budget and planning
• Problems and their solution
• Risks and an assessment of the used actions and strategies to mitigate them
• Required expertise
• Effectiveness of the delivery pans
• Quality of the suppliers

The whole idea behind the extensive acquisition report is that an enterprise can only learn from its faults and experiences when these are well documented available in relevant future situations.

The process of managing risks and planning deliveries is illustrated in Figure 6. All the different steps in the process are described in detail in the paragraphs below.

The first step of the process is describing the service that is to be procured. It is important to note the differences between a project and an ongoing service. Both types of services are described differently. ISPL provides the user with two separate sets of guidelines

There are two steps in describing an ongoing service. I will briefly elaborate on each of these steps in the following paragraphs.

ISPL proposes two methods for identifying the type of service:

• ISO Life Cycle Processes (ISO-LCP)
• Public domain service packages

These methods can be used in a successive way where the ISO-LCP standard is used to identify the different process types and public domain service packages are used to refine the ISO-LCP processes. An example of a publicly available description of service packages is the one that is present in ITIL. Note that in ITIL, service packages are referred to as processes. More info on the ISO-LCP standard can be found in the Wikipedia entry on ISO/IEC 12207.

The service can be described in more detail by its service properties. All service properties can be divided into three groups:

• Investment properties
• Functional properties
• Quality properties

ISPL provides methods for describing all three groups of properties.

Projects are described by an initial and a final state, i.e. the current and the desired situation. This is done by specifying the operation items (the actual parts of the Information service to be procured), and specifying the descriptive items (documentation). A short outline of documenting the initial and final state is given in the paragraphs below. More information on describing operation and descriptive items is given in the chapter #Specifying Deliverables.

For each component of the Information Service, contents and quality of the operation items have to be described. Secondary, an assessment has to be made on which already present descriptions of future operational items are relevant to use in the project.

All the operational items that will be in use at the final state have to be documented. When describing these operation items the focus should be on:

• The difference between new operational items and ones that are adapted from initial operational items
• Specification of manuals and support documentation
• Conversion and migration of existing data into new operational items
• Specification of interfaces with new and already present operation items

Not only the operational items have to be described: Descriptions of the documentation of the Information Service that is to be procured are also necessary. The client has to describe the profiles of the documentation needed for maintenance on, and further development of the Information service.

The service planning process consists of three sub-processes. These are:

• Situation and risk analysis
• Delivery strategy design
• Decision point planning

In practice, these three sub-processes are followed by a process of risk monitoring that can give input to the situation and risk analysis process.

The terms complexity and uncertainty are used quite often in this chapter.

Complexity In the context of ISPL, complexity can be regarded as the difficulty encountered in managing the available knowledge.

Uncertainty In the context of ISPL, uncertainty can be regarded as the lack of available knowledge.

The analysis sub-process is divided into a situation analysis followed by a risk analysis.

The situation of both the customer and supplier organizations has a lot of influence in the success of the Information Service acquisition process. The situation analysis is all about identifying situational factors and their values. A situational factor value says something about the relative contribution to the overall complexity or uncertainty of the service to be delivered. For both complexity and uncertainty it can have one of the following values: high, low or medium. The ISPL method provides a set of tables which aids the user in determining the situational factor values. An example of a part of such a table can be found in Table 1.

The risk management strategy depends on the situation as is displayed in Figure 7.

When all the situational factor values are determined it is possible to determine the overall complexity and uncertainty of the service. These two factors can be used by the manager for the Design of the service delivery strategy.

In the #Situation analysis, complexity and uncertainty values have been attributed to each of the situational factors. In the Risk Analysis, these values are used to identify the possible risks and their probability. Examples of possible risks for the customer business are unpredictable/increased costs for the business, delays in system delivery and poor quality of service or system. Examples of possible risks affecting the quality of the service to be delivered are demotivate of service actors, unclear requirements and uncertain interfaces with other services or systems. ISPL provides tables that map situational factors to risks. An example of such a table can be found in Table 2.

For each of the risks found, both the probability and impact, i.e. the consequence, are assessed. The product of these two values is called the risk exposure. The risk exposure value is used to identify the risks that are critical to service delivery. The critical risks influence the #Delivery strategy design and the #Decision point planning.

This process uses the service description, the situation analysis and the risk analysis as inputs to define an optimal service delivery strategy. The resulting service delivery strategy consists of three elements:

• A list of actions to mitigate risks
• Service execution approach
• Service control approach.

ISPL provides heuristics on how to mitigate risks and change the individual situational factors that cause them. An excerpt of these heuristics can be found in Table 3.

The service execution approach determines how the service is executed. For projects, the service execution approach is referred to as the development approach. It consists of a description approach, a construction approach and an installation approach. ISPL provides the user with heuristics on what type of description, construction and installation approach fits best to the situational factors and critical risks found in the #Situation analysis and #Risk analysis. For example, ISPL advises to use an evolutionary construction and installation approach when both overall complexity and uncertainty are high.

The selection of a service control approach is based on the situational factors and overall complexity and uncertainty found in the #Situation analysis. ISPL provides heuristics on which types of control are most suitable for various situational factors. In total there are six types of control: development, quality and configuration in a formal and frequent variant.

After defining a complete service strategy the consistency between the chosen strategy options has to be checked and possibly some choices have to be adjusted. The impact of the chosen strategy should also be analysed by checking that all critical risks have been addressed. It is also that some strategies cause new critical risks.

The goal of decision point planning is to determine a sequence of decision points and give a clear description on each of the decision points, using the #Delivery strategy design as input. The sequence and contents of the decision points should reflect the chosen service delivery strategy. The decision point planning is made in the following order:

1. Derive basic sequence of decision points.
2. Adapt basic sequence to accommodate actions.
3. Describe decision points.

The basic sequence of decision points is based on the #Delivery strategy design. ISPL provides heuristics on what basic sequences should be used for different delivery strategy options.

The basic sequence found is adapted to the list of actions to mitigate risks of the #Delivery strategy design.

ISPL gives information on what information elements should be in a decision point. Think of for instance purpose and the pre-conditions. For every decision has to be determined which deliverables are required. General rule is that the deliverables must contain the right amount of information to be able to make the decision but no more than that. Too much information is costly and blurs the focus of the decision makers. More information about this topic can be found in the chapter on #Specifying Deliverables.

Risk monitoring takes place after the #Decision point planning phase. Its results can serve as input for the #Situation and risk analysis phase of service planning if necessary. It involves the tracking, controlling and monitoring of risks and risk mitigating actions.

ISPL divides deliverables in various types, each with a defined set of properties. These properties characterise the knowledge that is captured by each type of deliverable. Figure 8 illustrates the different types of deliverables.

Contract domain deliverables are used to define and control all contracts in a procurement. There are two types of contract domain deliverables: the tendering deliverable and the decision point deliverable. In the following paragraphs each of these types is discussed in detail.

Tendering deliverables are used in the tendering process to place requirements on all of the services within a procurement. There are four types of tendering deliverables:

• Request for proposal
• Response
• Supplier evaluation report
• Contract

ISPL provides the customer and supplier organisations with templates for each of the different types. It is important to note that all of the tendering deliverables include the delivery plan in which all delivery and decision points are fixed.

Decision point deliverables support the decision making during the execution of the delivery plan in the #Contract Monitoring phase. There are two types of decision point deliverables:

• Decision point proposal
• Decision point report

Each of these types has its own, more specified subtype. The contract status report is a subtype of decision point proposal that describes the current status of a contract. The contract completion report, a subtype of the decision point proposal, records whether the contract has successfully achieved its business goals. ISPL provides the tables of content of each of the decision point deliverable types and subtypes.

Service domain deliverables describe the service domain (see paragraph #Target domain and service domain for more information). They are delivered by both customer and supplier organisations to plan and control services. There are two types of service domain deliverables: service plans and service reports.

A service plan provides information on how to meet identifies goals in terms of service levels, deliverables, schedules, resources and costs. It can for instance give guidance on how to reach targets. ISPL describes the different properties that can be included in the service plan.

In contrast to the service plan, the service reports controls the service status by reviewing service levels and results. It records the service's productivity and proposes corrective actions. ISPL gives guidance on which information should be included for each property that is described in the service report.

The target domain is described using target domain deliverables. There are two different types of target domain deliverables: operational items and descriptive items. Both will be discussed in the following paragraphs.

An operation item is a delivered system or system component that is or will be installed as part of the acquisition. They contribute to the functioning of the target domain. Some examples of different operational item types are listed below.

• facilities
• hardware devices
• application software
• physical data
• user and operator manuals
• trained actors

In practice, descriptions of operational items often already present. It is important to make the distinction between functional and quality properties.

A descriptive item captures knowledge about the target domain. They can be used to describe business organisations, business processes, information services et cetera. ISPL gives guidance on describing descriptive items by providing a descriptive item profile in which all properties of the descriptive item can easily be ordered.