1. ISPL® Basic definitions
1.1. Acquisition goal
1.1.1. The acquisition goal is defined by a consistent set of system and service requirements that satisfy the selected business needs of the target domain.
1.1.2. e.g.
1.1.2.1. an improved business process, a new organisational structure, a new computerised application, an improved computerised system operation service, etc.
1.2. Acquisition plan
1.2.1. The acquisition plan documents the acquisition strategy, defines the organisation and co-ordination of the various procurements and schedules the main decision points of the acquisition process.
1.3. Acquisition strategy
1.3.1. The acquisition strategy will determine the number and the kinds of services and contracts that are needed to achieve the acquisition goal; their sequencing constraints; the types of customer-supplier relationships and the approach to manage the risks.
1.4. Contract
1.4.1. A contract is a binding agreement between two parties for the supply of services or products enforceable by law or a similar internal agreement wholly within an organisation, . Several contracts may be required for the acquisition of the services needed by an organisation.
1.5. Deliverable
1.5.1. A deliverable is a product that is exchanged between the supplier and the customer to fulfil a defined purpose within an acquisition.
1.6. Procurement
1.6.1. Procurement is the process of preparing a contract and obtaining the services that are defined within contract.
1.7. Service domain
1.7.1. The service domain is the service organization that delivers the service, i.e. the supplier.
1.8. Target domain
1.8.1. The target domain is the part of the customer organization that is affected by the service.
1.9. The acquisition process
1.9.1. The acquisition process (or acquisition for short) is the process of obtaining a system or a service, or any combination thereof, to achieve some goal contributing to the business objectives.
2. The acquisition process model (5 phases)
2.1. 1. Acquisition initiation
2.1.1. Steps
2.1.1.1. Acquisition goal definition
2.1.1.1.1. 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.
2.1.1.1.2. Input
2.1.1.1.3. Activities
2.1.1.1.4. Output
2.1.1.2. Acquisition planning
2.1.1.2.1. 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.
2.1.1.2.2. Input
2.1.1.2.3. Activities
2.1.1.2.4. Output
2.2. (for each procurement)
2.2.1. The procurement step of the ISPL® acquisition process embodies the obtaining of one single contract.
2.2.2. Note that the acquisition itself can contain multiple procurements.
2.2.2.1. Such a contract consists of one or more projects or ongoing services.
2.2.3. 2. Tendering
2.2.3.1. Steps
2.2.3.1.1. 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.
2.2.3.1.2. A very important aspect of such a contract is the planning of the decision points.
2.2.3.1.3. Preparation of Request for Proposal (RfP)
2.2.3.1.4. Response preparation
2.2.3.1.5. Supplier selection
2.2.3.1.6. Contract preparation and signing
2.2.4. 3. Contract Monitoring
2.2.4.1. 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.
2.2.4.2. The most important activity of the contract monitoring process is the execution of the decision points.
2.2.4.3. In the decision point execution the customer organization makes judgments and decisions based on the status of the procurement at any given time.
2.2.4.4. Output
2.2.4.5. Activities
2.2.4.6. Input
2.2.5. 4. Contract Completion
2.2.5.1. 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.
2.2.5.2. Output
2.2.5.3. Activities
2.2.5.4. Input
2.3. 5. Acquisition completion
2.3.1. 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.
2.3.2. Output
2.3.3. Activities
2.3.3.1. Check that all contracts have been completed
2.3.3.2. Assess the achievement of the acquisition goal
2.3.3.3. Decide whether the acquisition is complete
2.3.3.4. Write an acquisition report
2.3.3.5. Review the lessons learned
2.3.4. Input
3. Roles in Acquisitions and Procurements
3.1. Organisational Authority
3.1.1. The person or group of people with the power to resolve or conclude an open issue with regard to the strategic requirements of the organisation. Therefore, at one level any decision made by a contract authority may be affected by a number of organisational authorities within his/her organisation. The implication of this is that a decision can be imposed upon the contract authority by one of the organisational authorities. Examples of organisational authority are: senior management, financial authority, legal authority, quality management authority.
3.2. Operational Expert
3.2.1. The person or group of people performing a task or acting as an opinion maker based upon their expertise, skills or knowledge with regard to a specific topic. When performing their work, the service authorities make use of various skilled resources within their organisations, that is, they make use of operational expertise. Examples of operational experts are: business experts, information system experts, technical experts, user experts, quality assurance experts, configuration management experts, system operation experts, network management experts, etc.
3.3. Two key roles:
3.3.1. contract authority
3.3.1.1. The person, or persons with the power to resolve or conclude an open issue with regard to a specific contract. One contract authority represents the customer organisation and another represents the supplier organisation. It is not necessary, or necessarily desirable, that the same person acts as the contract authority throughout the acquisition process.
3.3.1.2. Customer Contract Autohrity
3.3.1.3. Supplier Contract Autohrity
3.3.2. service authority
3.3.2.1. The person, or persons with the power to resolve or conclude an open issue with regard to a specific service. Again, one service authority represents the customer organisation and another represents the supplier organisation. It is not necessary, or necessarily desirable, that the same person acts as the service authority throughout the acquisition process
3.3.2.2. Supplier Service Authority
3.3.2.3. Customer Service Authority
4. ISPL® Deliverables
4.1. Contract domain deliverables
4.1.1. What is it?
4.1.1.1. Used to define and control the contractual process of a procurement.
4.1.1.2. Contract domain deliverables are used to define and control all contracts in a procurement.
4.1.2. 2 types:
4.1.2.1. Tendering deliverable
4.1.2.1.1. Tendering deliverables are used in the tendering process to place requirements on all of the services within a procurement.
4.1.2.1.2. 4 types:
4.1.2.2. Decision point deliverable
4.1.2.2.1. Decision point deliverables support the decision making during the execution of the delivery plan in the Contract Monitoring phase.
4.1.2.2.2. 2 types:
4.2. Target domain deliverables
4.2.1. What is it?
4.2.1.1. Systems or documents related to the target domain.
4.2.2. 2 types:
4.2.2.1. Operational items
4.2.2.1.1. 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.
4.2.2.1.2. e.g.
4.2.2.2. Descriptive items
4.2.2.2.1. A descriptive item captures knowledge about the target domain. They can be used to describe business organisations, business processes, information services et cetera.
4.2.2.2.2. 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.
4.2.2.2.3. defined by a descriptive item profile
4.3. Service domain deliverables
4.3.1. What is it?
4.3.1.1. Used to plan and control service execution.
4.3.1.2. Service domain deliverables describe the service domain.
4.3.2. 2 types:
4.3.2.1. Service plans
4.3.2.1.1. 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.
4.3.2.1.2. ISPL® describes the different properties that can be included in the service plan.
4.3.2.2. Service reports
4.3.2.2.1. 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.
4.3.2.2.2. ISPL® gives guidance on which information should be included for each property that is described in the service report.
5. ISPL® - is a best practice library for the management of Information Technology related acquisition processes. It helps both the customer and supplier organization to achieve the desired quality using the corresponded amount of time and money by providing methods and best practices for risk management, contract management, and planning.
5.1. ISPL® v1.0 was developed and published in 1999 by a consortium of five European companies: EXIN and ID Research (ORDINA) from the Netherlands, FAST from Germany, SEMA from France and TIEKE from Finland.
6. 4 main benefits of using ISPL®
6.1. The customer can take advantage of the competitive market.
6.2. Proposals of suppliers become comparable.
6.3. The use of a strategy that really fits the situation.
6.4. The contract can be used as a control instrument.
7. ISPL® Official publications
7.1. Introduction to ISPL
7.1.1. ISBN 90.76304.85.8
7.2. Managing Acquisition Processes
7.2.1. ISBN 90.76304.81.5
7.3. Managing Risks and Planning Deliveries
7.3.1. ISBN 90.76304.83.1
7.4. Specifying Deliverables
7.4.1. ISBN 90.76304.82.3
7.5. Dictionary
7.5.1. ISBN 90.76304.84.X
7.6. ISPL in the European Public Sector: guidelines
7.6.1. ISBN 90.76304.86.6
7.7. ISPL for Web Engineering
7.7.1. ISBN 90.76304.87.4
7.8. ISPL for Large-Scale Migrations
7.8.1. ISBN 90.76304.88.2
7.9. ISPL for IT Service Management
7.9.1. ISBN 90.76304.90.4