Last update PvD

Project Aspects

Application Note

This document describes all kinds of aspects of a project to develop and deliver a fictitious system (hardware & software) to a customer. The objective of this document is to identify the necessary tasks for this project, so the responsibility for the work can be assigned to some organisation/department, and the necessary work can be estimated/budgetted.
The completed list –with an organisation filled-in for each of the aspects– should serve as an agreement for the scope of work and for the distribution of responsibilities. It will also serve as a checklist to ensure that no major aspect is overlooked, and as a starting point to determine financial and manpower budgets (e.g. by adding an extra column to the tables below).

Types of development
The list covers different types of development/engineering; it assumes a large system requiring:

the development of a Generic System; and(/or)
Customer Adaptation development ('customer design engineering')

for turn-key delivery (over-the-shelve delivery has less steps – e.g. the developing organisation is not involved in Installation).
Site Engineering ('customer application engineering') is considered part of Regular Delivery.
See Projects & Contracts for more on this.

Because of the different types of developement and delivery, some aspects might not be relevant for your current specific case. Also, for other domains of development you may have to modify and/or extend the list.
Note also that when a system is developped specifically for a single customer ('design on order') or it concerns a single instance (no follow-on deliveries), the phasing is probably slightly different (e.g. there will be no Qualification test by the developing organisation, but an elaborate Acceptance test by the customer).

Application of this list
Go through the list and determine/fill-in for each aspect whether it is applicable and if so, which Organisation will be responsible for that aspect (in agreement with that particular organisation). Be specific: use company departments, units or business divisions, a named third party, or define the aspect Not Applicable (preferably obtain confirmation for that).
Only a single organisation can be responsible for a single aspect. If more organisations have responsibility for a particular aspect, the separation should be made clearly discernible. You may have to repeat sections and/or adapt the text.

Notes:

The development of a Generic System and the Customer Adaptation development of such a system for an application area are distinct projects. So you have to use distinct lists of Project Aspects.
You will never need all of this list — its scope is to broad for a single project. You will either use most of the first part, or most of the last part.
A potential Pilot project has its own functionality, effort, planning and responsibilities: it is considered a separate project (so use a separate list).
Marketing, Sales and Contract Acquisition are not in the scope of a project.

Initial Phase

Scope

Short description of your project (narrative, objectives, …), or reference to such a description. To avoid future discussions, define what is in the scope and what not.
Create a separate section regarding References to all relevant documents, e.g. requirements, and a section regarding Specific Issues (bottlenecks, risks).

System Definition

Definition of –the functionality of– the overall system. This is either done

by a customer for a specific system, or
by the (multi-national) marketing department for a Generic system, or
by a joint team of the customer's and the developer's organisation for Customer Project.

System Definition	Org.
System description Describe the goal of the system and its discriminating features, and provide a context diagram (scope & interfaces). Define the main components i.e. a *System Architecture* (preliminary System design).
Business case Make a basic business case for the system. What is the market potential, how is the system changing operational practices, what are critical cost- and gain areas.
Analyse the proposed system What are critical components regarding the required performance and the system's business case.
Future developments Analyse the trends in technology, economy and market: understand how the proposed system (& business case) affects and interacts with existing businesses, operational practices, market position, etc. It should also indicate in what area the system should be flexible.
Requirement Specification Specification of what the system is to achieve.

For a Generic system, initially not all requirements will be 'hard'; many points are desirable or optional, open for discussion with the customer(s), or potential demands for a later releases (i.e. a 'roadmap'). During the Initial Phase the Requirement Specification (for the first release) should become concrete and fixed. See Architecture - Specifics for Requirement Specifications.

Consultancy

Consultancy may occur during the whole project, but the emphasis is likely to be in the initial phase (e.g. analysis, estimating, contract negotiations). It involves most departments (Sales, System Engineering, Logistics, Legal) and probably all parties (units, subcontractors, vendors). The completion of this Project Aspects List is part of that. It serves to describe the right conditions for the project.

Consultancy Org.
Requirements Analysis
Analysis of all requirements (System Requirements Specifications, formal and informal specs, functional, performance) for the system to be developed. Special attention to complex areas and risks.
Statement of Compliance (SoC)
A Statement of Compliance is a point-to-point answer on the Requirement Specification.
Feasibility Studies
Specific studies to investigate specific problems, to consider the feasibility of solutions (prototyping), to estimate and optimise cost (i.e. sizing, configuration planning, alternate solutions).
Contract Negotiations
Negotiations on the consequences of contract terms, including assistance by technical and operational departments.
Marketing Assistance
Assistance to Marketing/Sales takes a continuous effort, with a peak during System Design (Bid Support).
Factory Acceptance Test (FAT)
This is an audit of development, manufacturing and (in particular) test procedures at the developer (the 'factory'). It is a quality assurance test to show to the customer that the development organisation is capable of developing the product. The customer may ask to demonstrate specific (test) procedures.
The Factory Acceptance Test Report is made by the customer, and usually shared with the development organisation.
See Testing for more on this subject.

Consultancy	Org.
Requirements Analysis Analysis of all requirements (System Requirements Specifications, formal and informal specs, functional, performance) for the system to be developed. Special attention to complex areas and risks.
Statement of Compliance (SoC) A Statement of Compliance is a point-to-point answer on the Requirement Specification.
Feasibility Studies Specific studies to investigate specific problems, to consider the feasibility of solutions (prototyping), to estimate and optimise cost (i.e. sizing, configuration planning, alternate solutions).
Contract Negotiations Negotiations on the consequences of contract terms, including assistance by technical and operational departments.
Marketing Assistance Assistance to Marketing/Sales takes a continuous effort, with a peak during System Design (Bid Support).
Factory Acceptance Test (FAT) This is an audit of development, manufacturing and (in particular) test procedures at the developer (the 'factory'). It is a quality assurance test to show to the customer that the development organisation is capable of developing the product. The customer may ask to demonstrate specific (test) procedures. The Factory Acceptance Test Report is made by the customer, and usually shared with the development organisation. See Testing for more on this subject.

System Design

Design & documentation of the whole system, definition of subsystems/components with their functionality, separation of functionality between components (in hardware and in software, including their interfaces). The other activities are related as they may impact the requirements for components. Scoping of all the work.
The purpose of the System Design is to obtain a work break-down (list of all components), and a basic development plan, so it is possible to estimate the costs (& risks) and time to build the total product (within ≈10% margin). To reach this purpose one does not need a fully completed design (that is only required after the go-ahead for product development), but one has to assure that all technical issues can be adequately solved, and the design must be sufficiently detailed to make reliable estimates.
System Design Org.
System Design
Description/documentation of the solution in terms of components with their respective functionality and interfaces (external & internal). For performance critical systems, the component specifications should include expected performance indications.
Test Strategy
How are all development tests (Integration & Qualification) and operational tests (Acceptance & Maintenance) envisioned. What test tools will be required.
This document should be superseded by the Test Plan.

Customer/Market Adaptation Strategy (Customer Design Engineering)
How is customer/market adaptation envisioned, what facilities must be available (how to create extensions & variants, e.g. Sw packaging).
Site Engineering Strategy (Customer Application Engineering)
How is site engineering envisioned, what facilities (dimensioning rules, tools) must be available to determine the required components (Hw & Sw, data) to configure/deliver a system instance for a specific site.
This document should be superseded by the Site Engineering Manual.
End-of-Life Activities
At the end-of-life of the system, it should be taken down and scrapped (environmental & commercial aspects). These should be considered during design, and responsibility assigned to an organisation.

System Design	Org.
System Design Description/documentation of the solution in terms of components with their respective functionality and interfaces (external & internal). For performance critical systems, the component specifications should include expected performance indications.
Test Strategy How are all development tests (Integration & Qualification) and operational tests (Acceptance & Maintenance) envisioned. What test tools will be required. This document should be superseded by the Test Plan.
Customer/Market Adaptation Strategy (Customer Design Engineering) How is customer/market adaptation envisioned, what facilities must be available (how to create extensions & variants, e.g. Sw packaging).
Site Engineering Strategy (Customer Application Engineering) How is site engineering envisioned, what facilities (dimensioning rules, tools) must be available to determine the required components (Hw & Sw, data) to configure/deliver a system instance for a specific site. This document should be superseded by the Site Engineering Manual.
End-of-Life Activities At the end-of-life of the system, it should be taken down and scrapped (environmental & commercial aspects). These should be considered during design, and responsibility assigned to an organisation.

Above table is for the development of a Generic System; when for Customer Adaptation Engineering the following applies:

System Architecture defines the required additions (adaptations) to the generic architecture;
Customer Adaptation Engineering Strategy document should already be there (now applied, and potentially specialised for this customer);
Site Engineering should be adapted specifically for this (adapted) system and for this customer/market (procedures, work instructions); and
a Back-to-back Agreement with the organisation responsible for the Generic System is required (in fact you acquire the existing generic system).

Component Acquisition

All activities required to buy major (sub-)systems from some supplier (this is not considering the basic components for manufacturing like nuts & bolts, resistors, etc; those are assumed to be qualified).

Component Acquisition Org.
Component Selection
Evaluation & Selection of candidate subsystems & components.
Acceptance Testing
Testing whether a proposed component performs as required. When this component (and its vendor) are accepted, it includes the definition of the Confidence Test procedure/manual to be carried out on this component by manufacturing/assembly for Regular Delivery.
Vendor Evaluation
Check whether the vendor is capable of delivering sufficient quantities at sufficient quality of that subsystem.
Back-to-Back Agreement
When particular products/aspects are subcontracted to other company units or external organisations, contracts are required ensuring sustaining support by those organisations for those products/aspects.
Know-how Transfer / Training
The effort required to transfer system- and product area knowledge and documentation from the supplier (in particular for maintenance and diagnostics).

Component Acquisition	Org.
Component Selection Evaluation & Selection of candidate subsystems & components.
Acceptance Testing Testing whether a proposed component performs as required. When this component (and its vendor) are accepted, it includes the definition of the Confidence Test procedure/manual to be carried out on this component by manufacturing/assembly for Regular Delivery.
Vendor Evaluation Check whether the vendor is capable of delivering sufficient quantities at sufficient quality of that subsystem.
Back-to-Back Agreement When particular products/aspects are subcontracted to other company units or external organisations, contracts are required ensuring sustaining support by those organisations for those products/aspects.
Know-how Transfer / Training The effort required to transfer system- and product area knowledge and documentation from the supplier (in particular for maintenance and diagnostics).

Project Management

When the project will be carried-out (after the contract/'go-ahead'), co-ordination and support of all required development activities will be required (potentially at distributed sites). The main issue for Project Management is the scope of the project. Regular (follow-on) deliveries are commonly not part of Project Management (but of Logistics; see overthere), but the initial delivery usually is.
Project Support Org.
Project Management Plan
How the development and introduction of the system is going to be managed (procedures, rules, methods). What status reports need to be made at which interval, etc. See Project Management.
Subcontract Management
Covers the management of subcontractors (for development).
Documentation Management Plan
Definition of what type of documents must be created for each type of component, and how to manage all documents (i.e. documentation rules, archiving). See Documentation.
Quality Management Plan
A document assuring sufficient quality of the product to be developed (i.e. including project procedures). See Quality Management Plan.
Development Plan
Scope of all engineering work (work break-down: list of all components and work involved, e.g. documentation), and the development schedule.
Configuration Control
How can one discern versions of components and their corresponding documentation, how will versions of system components and their mutual dependancies be handeled. For management of delivered configurations see Regular Delivery - Site Engineering.
Change Management
Definition how to handle Change Requests, Change Proposals and Change Notes regarding the funtionality of the system. It includes Problem Management until the Acceptance Test has passed successfully. See Change Procedure.
Escalation Procedure
When a conflict arises between parties (not only for customer/developer, but any customer/supplier relationship like developer/component supplier) which can evidently not be solved in normal meetings, there should be a planned strategy to resolve such a conflict. It involves the next higher level of management at both parties, and ultimately both CEO's. It may involve Change Management.

Project Support	Org.
Project Management Plan How the development and introduction of the system is going to be managed (procedures, rules, methods). What status reports need to be made at which interval, etc. See Project Management.
Subcontract Management Covers the management of subcontractors (for development).
Documentation Management Plan Definition of what type of documents must be created for each type of component, and how to manage all documents (i.e. documentation rules, archiving). See Documentation.
Quality Management Plan A document assuring sufficient quality of the product to be developed (i.e. including project procedures). See Quality Management Plan.
Development Plan Scope of all engineering work (work break-down: list of all components and work involved, e.g. documentation), and the development schedule.
Configuration Control How can one discern versions of components and their corresponding documentation, how will versions of system components and their mutual dependancies be handeled. For management of delivered configurations see Regular Delivery - Site Engineering.
Change Management Definition how to handle Change Requests, Change Proposals and Change Notes regarding the funtionality of the system. It includes Problem Management until the Acceptance Test has passed successfully. See Change Procedure.
Escalation Procedure When a conflict arises between parties (not only for customer/developer, but any customer/supplier relationship like developer/component supplier) which can evidently not be solved in normal meetings, there should be a planned strategy to resolve such a conflict. It involves the next higher level of management at both parties, and ultimately both CEO's. It may involve Change Management.

Development Phase

Software Development

Development of all the software.

Software Development Org.
Top Level Design (Sw)
Potentially some additional design for the overall software architecture.
Software Design Specification [DS]
Test Plan [QP]
Detailed Design (Sw)
Design (/adaptations) of each Sw component.
Detailed Design Specification [DS]
Coding & Module Test
Module Test Specification [QT]
Module Test Report [QZ]
Software Integration & Test (optional)
Integrate software in artificial environment (hosted, simulated hardware)
Software Integration Test Specification [QT] (potentially part of the overall Integraton Test Specification).
Sw Development Environment
For proper software development equipment, tools and procedures (software engineering rules, Configuration Management).
Development Engineers Training
Software engineers have to be trained on the Development Environment (tools) and in the problem area with its specific constraints.

Software Development	Org.
Top Level Design (Sw) Potentially some additional design for the overall software architecture. Software Design Specification [DS] Test Plan [QP]
Detailed Design (Sw) Design (/adaptations) of each Sw component. Detailed Design Specification [DS]
Coding & Module Test Module Test Specification [QT] Module Test Report [QZ]
Software Integration & Test (optional) Integrate software in artificial environment (hosted, simulated hardware) Software Integration Test Specification [QT] (potentially part of the overall Integraton Test Specification).
Sw Development Environment For proper software development equipment, tools and procedures (software engineering rules, Configuration Management).
Development Engineers Training Software engineers have to be trained on the Development Environment (tools) and in the problem area with its specific constraints.

Hardware Development

Development of all the hardware.

Hardware Development Org.
Top Level Design (Hw)
Potentially some additional design for the overall hardware architecture.
Detailed Design (Hw)
Design (/adaptations) of each hardware components, design of circuits & boards and corresponding documentation.
Hardware Implementation
Layout, prototyping, testing and documentation of hardware components (i.e. for the manufacturing of PBA's).
Hardware Integration
Integrating and testing all the hardware (as much as feasible without software integration).
Hw Development Environment
For proper hardware development equipment and tools are to be acquired. It includes hardware engineering rules.
Equipment Practice
Selection of board sizes, shelve & rack types, connectors, configuration rules,etc.
Prototyping
Production of prototype hardware

Hardware Development	Org.
Top Level Design (Hw) Potentially some additional design for the overall hardware architecture.
Detailed Design (Hw) Design (/adaptations) of each hardware components, design of circuits & boards and corresponding documentation.
Hardware Implementation Layout, prototyping, testing and documentation of hardware components (i.e. for the manufacturing of PBA's).
Hardware Integration Integrating and testing all the hardware (as much as feasible without software integration).
Hw Development Environment For proper hardware development equipment and tools are to be acquired. It includes hardware engineering rules.
Equipment Practice Selection of board sizes, shelve & rack types, connectors, configuration rules,etc.
Prototyping Production of prototype hardware

Integration Test

The Integration Test is in fact 2 activities in 1 step: putting components together (integration), and test their interworking. Subsystems are already tested individually during subsystem development. And it is not only testing the interworking between components (modules), but also diagnosing the cause when it fails.

Integration Test Org.
Integration Strategy
This is the strategy for step-wise integrating and testing components. It reflects the availability of components in time (i.e. the Schedule in the Development Plan). Initial version to be created during Project Management.
Integration Test Specification [QT]
A document decribing the individual tests to be executed during integration.
Integration Test
Execution of the integration test.
Integration Test Report [QZ]
The report on the results of the Integration Test (what test have beeen executed, and with what results).
Note that for a large system there are often a myriad of potential tests; doing all of them takes an extraordinary amount of time & effort while the usefulness is marginal. So commonly only a subset of the tests are executed, depending of the results of previous tests. See Smart Testing for more on this.

Integration Test	Org.
Integration Strategy This is the strategy for step-wise integrating and testing components. It reflects the availability of components in time (i.e. the Schedule in the Development Plan). Initial version to be created during Project Management.
Integration Test Specification [QT] A document decribing the individual tests to be executed during integration.
Integration Test Execution of the integration test.
Integration Test Report [QZ] The report on the results of the Integration Test (what test have beeen executed, and with what results).

Qualification Test

This in-depth test verifies whether the developed system conforms to its Requirement Specification (potentially including specifics required by authorities); passing this test concludes the development of the system, and the system is now suitable for general delivery.
See Testing for more on this subject.

Qualification Test Org.
Qualification Test Specification
Description of all tests to be executed. Derived from the Requirements Specification.
Qualification Test
Execution of the Qualification Test Specification.
Qualification Test Report [QZ]
Report on all qualification tests

Qualification Test	Org.
Qualification Test Specification Description of all tests to be executed. Derived from the Requirements Specification.
Qualification Test Execution of the Qualification Test Specification.
Qualification Test Report [QZ] Report on all qualification tests

Introduction Phase

Customer Location Test / System Acceptance Test

This is an in-depth System Acceptance test by the customer to verify whether the system conforms to the customer's requirements (i.e. system qualification by the customer). Commonly the test is held in the customer's lab with live interfaces, and supported by the development organisation (corrective engineering possible).
This is not an Alpha test, nor is it the Delivery Acceptance Test done at Regular Delivery; for that see Installation.

Customer Location Test Org.
Customer Location Test Support
Development support to the overall test by the customer to check whether the product conforms to the customer's requirement.

Customer Location Test	Org.
Customer Location Test Support Development support to the overall test by the customer to check whether the product conforms to the customer's requirement.

Initial Application

A limited number of systems applied as an operational pilot to experience the 'real world' and to smooth out operational procedures. Most documents and procedures for Regular Delivery are completed here. In some environments this corresponds to a Beta test.

Initial Application Org.
System Delivery
Delivery, Installation & Test at the customer premises (however, procedures and documents are not yet complete). See Regular Delivery – Installation.
System Introduction / Migration
Assistance to various local departments and to the client to introduce the system. It includes other start-up effort such as interfacing with existing systems and migration from old systems.
Customer Training
Training the customer on how to use the system (various audiences, e.g. operators, users), and how to set-up system environment.
Installation & Test Manuals
Creation of Installation Manual & Installation Test Manual
Customer Documentation
Creation of System descriptions, Manuals, Guides, Tutorials and Training manuals for the customer on how to plan, install, maintain, operate and use the system.
Installed Base
How to keep track of delivered systems and their configuration (later by Site Engineering).

Initial Application	Org.
System Delivery Delivery, Installation & Test at the customer premises (however, procedures and documents are not yet complete). See Regular Delivery – Installation.
System Introduction / Migration Assistance to various local departments and to the client to introduce the system. It includes other start-up effort such as interfacing with existing systems and migration from old systems.
Customer Training Training the customer on how to use the system (various audiences, e.g. operators, users), and how to set-up system environment.
Installation & Test Manuals Creation of Installation Manual & Installation Test Manual
Customer Documentation Creation of System descriptions, Manuals, Guides, Tutorials and Training manuals for the customer on how to plan, install, maintain, operate and use the system.
Installed Base How to keep track of delivered systems and their configuration (later by Site Engineering).

Regular Delivery

Various documents & procedures required for Regular Delivery (normal Roll-out) will be made during Initial Application.

Logistics

Logistics takes care of all material and resource planning for regular delivery of a product.
Logistics Org.
Order Intake
Accept, verify and confirm incoming orders.
Logistic Planning
Plan manufacturing/acquisition of material involved; plan Site Engineering & Installation effort and resources.
Subcontract Management
Management of all subcontractors used in regular delivery (equipment & services).
Transport
Arrange transport for delivery.
Invoice & tracking
Send out bill and see that you get your money.

Logistics	Org.
Order Intake Accept, verify and confirm incoming orders.
Logistic Planning Plan manufacturing/acquisition of material involved; plan Site Engineering & Installation effort and resources.
Subcontract Management Management of all subcontractors used in regular delivery (equipment & services).
Transport Arrange transport for delivery.
Invoice & tracking Send out bill and see that you get your money.

Site Engineering

Site Engineering (Customer Application Engineering, CAE) is all engineering required for a delivery of an existing -rather complex- system.

Site Engineering Org.
Acquire Site Dependant Data
Get all relevant data concerning a particular location. This may involve site visits and meetings with the customer and/or documents (forms) per site from the customer.
Site Planning
Determine material (subsystems, hardware and software), configuration and effort (planning, installation, test) involved for this delivery.
Software Generation / Data Production
Assemble all software parts (possibly conditional build) and/or generate data for this particular delivery. This may involve database population.
Site Specific Customer Documentation
Floorplan, equipment distribution, cabling, power supply, cooling, software configuration, numbering/addressing, routing tables, etc.
Installed Base Management
Keep track of composition of delivered systems quantities and versions of items (deliveries and repairs).
Site Engineering Environment
For proper Site Engineering probably tools are required (as this is a repeating job, efficiency and quality are issues).
Site Engineering Manual
This manual should be created by the development department, but is possibly adapted to suit the client (CDE) and general operating procedures.
Site Engineers Training
Engineers have to be trained for good quality Site Engineering results.

Site Engineering	Org.
Acquire Site Dependant Data Get all relevant data concerning a particular location. This may involve site visits and meetings with the customer and/or documents (forms) per site from the customer.
Site Planning Determine material (subsystems, hardware and software), configuration and effort (planning, installation, test) involved for this delivery.
Software Generation / Data Production Assemble all software parts (possibly conditional build) and/or generate data for this particular delivery. This may involve database population.
Site Specific Customer Documentation Floorplan, equipment distribution, cabling, power supply, cooling, software configuration, numbering/addressing, routing tables, etc.
Installed Base Management Keep track of composition of delivered systems quantities and versions of items (deliveries and repairs).
Site Engineering Environment For proper Site Engineering probably tools are required (as this is a repeating job, efficiency and quality are issues).
Site Engineering Manual This manual should be created by the development department, but is possibly adapted to suit the client (CDE) and general operating procedures.
Site Engineers Training Engineers have to be trained for good quality Site Engineering results.

Manufacturing

Manufacturing	Org.
Manufacturing Mass production of individual components & subsystems, including production tests.
Validate Buy-in Components Confidence testing of bought components.
Assembly Assembly & confidence testing of components/subsystems to obtain the ordered system in shippable blocks.

Installation

All activities to get a system in the field in working order. The tests involved should only provide confidence that equipment is correctly manufactured, delivered & installed, not whether the system fulfills some Requirement Specification (it is no System Acceptance Test).

Installation Org.
Hardware Installation & Test
Software Installation & Test
Migration
Migration of data/applications/users from the old system to the newly delivered system.
Commisioning or Delivery Acceptance Test
Formal test that should verify whether this particular configuration is operating correctly. For Commissioning the equipment is also put into active use for the customer (otherwise the customer is assumed to put the system into operation).
Now the system is assumed to be delivered and should be billed.
Engineers Training
Training of engineers for Installation & Test (Hw & Sw, Commissioning).

Installation	Org.
Hardware Installation & Test
Software Installation & Test
Migration Migration of data/applications/users from the old system to the newly delivered system.
Commisioning or Delivery Acceptance Test Formal test that should verify whether this particular configuration is operating correctly. For Commissioning the equipment is also put into active use for the customer (otherwise the customer is assumed to put the system into operation). Now the system is assumed to be delivered and should be billed.
Engineers Training Training of engineers for Installation & Test (Hw & Sw, Commissioning).

Sustaining Activities

All activities to support the product in the field.

Sustaining Engineering Org.
First Level Maintenance
Simple preventive and corrective maintenance (exchanging dust filters, fans, faulty boards, etc). Quite often performed by the customer.
Second Level Maintenance
More sophisticated maintenance for more complex and obscure problems or major renovations. Also fall-back for level-1 maintenance. Performed by dedicated team (potentially by customer).
Last Resort / Third Level Maintenance
When first and second level maintenance can not solve a problem (in particular when these are performed by the customer), a fall-back on the expertise of the development engineers should be available.
Escalation
When normal error correction procedures do not satisfy the customer, an escalation procedure should be activated (involving management). This may also involve other organisations/units through the Back-to-back agreements (i.e. with development organisations).
Service Management, Complaint tracking
Registration of calls to invoke corrective maintenance/complaints and completion of maintenance/complaint.
Help Desk
Facility for clients to call for telephonic support to (software) problems.
Spares
Keep spare stock, administer use, and replenish.
Repair
Repair faulty equipment from the field.
Retro-fit
Replace out-dated (bugged) components in the field (and stock) by their up-to-date replacements.
Maintenance Training
Training of maintenance engineers; that is the own people and potentially the clients maintenance crews (ongoing business).
Operator Training
Training of the customer’s operators, provision of manuals.
User Training
Training of the customer’s users, provision of manuals.

Sustaining Engineering	Org.
First Level Maintenance Simple preventive and corrective maintenance (exchanging dust filters, fans, faulty boards, etc). Quite often performed by the customer.
Second Level Maintenance More sophisticated maintenance for more complex and obscure problems or major renovations. Also fall-back for level-1 maintenance. Performed by dedicated team (potentially by customer).
Last Resort / Third Level Maintenance When first and second level maintenance can not solve a problem (in particular when these are performed by the customer), a fall-back on the expertise of the development engineers should be available.
Escalation When normal error correction procedures do not satisfy the customer, an escalation procedure should be activated (involving management). This may also involve other organisations/units through the Back-to-back agreements (i.e. with development organisations).
Service Management, Complaint tracking Registration of calls to invoke corrective maintenance/complaints and completion of maintenance/complaint.
Help Desk Facility for clients to call for telephonic support to (software) problems.
Spares Keep spare stock, administer use, and replenish.
Repair Repair faulty equipment from the field.
Retro-fit Replace out-dated (bugged) components in the field (and stock) by their up-to-date replacements.
Maintenance Training Training of maintenance engineers; that is the own people and potentially the clients maintenance crews (ongoing business).
Operator Training Training of the customer’s operators, provision of manuals.
User Training Training of the customer’s users, provision of manuals.

=O=