Producing a new IT service in order to generate a specific value in the business can be very complex. There are often several different organizations involved in the work, with each one having its own perspective on what is important.
One example is whether a new application should be developed, and the project concentrating all its energies on the functionality in the application. On completion of the application the realization dawns that it does not fit with the rest of the IT infrastructure, the tools we use for all other applications don’t work, and the Operation department’s staff do not have the expertise required to manage it.
In this example, a major cost is created which was not included in the calculation from the outset and in the worst case, the total cost becomes so great that the project should not have been implemented at all if all costs had been known.
Creating a process which regulates the activities facilitates the challenge of including all aspects of a new IT service throughout its life cycle. Furthermore, it establishes a prerequisite of continually improving the quality of new services and streamlining the work of producing them.
Purpose
The purpose of Service Design is to ensure that all different aspects of the design work are taken into account so that objectives and purpose are achieved for the new IT service.
The purpose is achieved through:
- Providing uniform activities when designing new and changed services
- Producing complete design packages
- Ensuring that sufficient design work is undertaken before handover to the Change Management process
- Ensuring that all new IT services are in line with policy documents and strategies
- Measuring and improving the quality and efficiency of the design activities
Scope
In a small IT organization that does not perform its own development, can the process in its simplest form consist of a checklist describing which different areas must be taken into account in production of a new IT service.
For larger organizations with their own development and frequent introduction of new IT services, Service Design needs to be an explicit process which is clearly linked with the processes used to manage requirements in the development model.
The scope of Service Design consequently differs greatly between different IT organizations depending on the size and number of internally developed applications. Each IT organization must therefore decide which level of ambition and scope the process should have.
As a starting point, Service Design comprises the activities required to ensure the quality and functionality in new or changed IT services.
Managing all changes through Service Design is not efficient. A trigger must therefore be inserted in the Change Management process to indicate when a change should be managed by Service Design. The level at which this trigger is set is naturally different for each organization. However, new services, high risk changes or those which affect several different services can be a good starting point. To facilitate this, it is beneficial if the trigger for Service Design is the same as the trigger for which changes should be managed by CAB in the Change Management process.
Regardless of the size of the organization, Service Design includes:
- Developing and administering policy and method for design work
- Streamlining Service Design
- Producing complete design packages for CCB
Value for the business
Service Design ensures that the IT organization takes into account all different aspects of a new service and thereby reduces the risk of unforeseen costs for the business.
In addition, Service Design enables:
- Desired value for the business at acceptable risks and costs
- Reduction of unplanned work during Transition
- Uniform design of all services, which facilitates deployment
Design aspects
It is important to try to have an overall view in relation to design of services. Regardless of their role, people with different backgrounds have different views on what needs to be done and what is important. It is easy to get stuck in one’s own specialist area, one’s own aspect, and in the worst case, design solutions that do not function together with the rest of the IT environment. To facilitate the overall perspective, five different aspects are used for design work:
Design of the service – This aspect comprises in part the requirements for which value the service should fulfil and in part how the service’s architecture is constructed. This includes links and dependencies on existing services, parameters to be found in policies and controlling documents. In addition to this, all requirements for functional capacity and value must be obtained and documented.
Information and tools – Existing information systems and tools should be analyzed in order to ascertain whether they can manage the requirements from the new service. What should be analyzed is the service portfolio’s structure, including the method for cost calculation and service structure and the tools used for knowledge management and to measure the service.
Architecture – Both the technical and the organizational architecture must be analyzed to ascertain whether they meet the requirements from the new service. The technical architecture includes the infrastructure platform, but also the tools used for tasks such as monitoring and deployment. The organizational architecture comprises functions and roles, as well as the methods used.
Processes and functions – A new service entails new information and new procedures for existing processes. Functions need to be analyzed in order to identify any new skills required to manage the new service.
Measurement and reports – Existing tools and report structures need to be analyzed to ascertain whether the new service can be measured and followed up or whether new tools are needed.
Design package
A design package should be created under Service Design for each new or changed service. The design package contains all information needed to build, test and establish the service in the IT environment. A design package usually consists solely of documents, but in certain issues can also contain simple forms of applications and systems in order to display concepts and functionality prior to a decision to develop a full-scale service.
As a minimum, a design package should contain:
- Contact details
- Business requirements
- The service’s prospective value in the business
- Service Design
- Functional requirements
- Non-functional requirements
- Service levels
- Operational requirements in the IT operation
- Design and architecture for the service
- Organizational analysis
- The service
- Plan for transition
- Plan for IT operation
- Acceptance criteria
Activities
Plan design – each new design project should be planned in detail. This is particularly important in large projects where the development department’s requirement model should potentially be coordinated with external suppliers and the internal operational organization. As the working method matures within the IT organization, the activity becomes easier as the aim is to have procedures and templates in place which make it easy for the project manager to perform the job.
Build design – This step is performed as an activity in conjunction with minor design assignments, or as a project in accordance with the IT organization’s project model. One of the most important activities is to schedule and timetable both internal resources and the business’s resources at an early stage in order to minimize unnecessary waiting times. The result of this activity is a service package which describes all aspects of the design.
Test design – All development projects or activities are concluded with a review of the design to ensure that the required value is achieved, that all aspects have been taken into account and that applicable regulations and policies are followed. Everything that consciously deviates should be documented as a part of the design package.
Hand over design package – When everything is documented in the service package, it can be sent back to the Change Management process. The next step is for the Change Control Board (CCB) to take decisions regarding the completed design. Resources that have participated in the design should be present at the decision meeting to present the design and answer questions.
Documentation
With major changes, all information about new or changed services should be included in the service package. The information is saved as a part of the service documentation for traceability. Minor changes are documented directly in the change record or in documents linked to the issue.
The following documentation should be included within the framework of Service Design:
- Design policy
- Template for design package
- Procedure for planning design
- Procedure for testing design
Relationships with other processes and functions
Service Design has links to many other processes. The most common are listed here:
Trigger
Service Design is triggered through one of the set criteria being met in the Change Management process. Examples of these criteria are:
- A completely new service
- Major change to an existing service
- Change which includes several services
- A change with a high risk of disturbances in the business
Input
The following inputs are needed for Service Design:
- Change record (RFC)
- Information about the operation which will use the service
- Documentation of architecture (information, application, technology, services)
- Service documentation of existing services
- IT strategy
- Policy document and other controlling documents
- Service structure
Output
The following outputs are generated by Service Design:
- Design package
- Revised architecture
- Revised measuring system and methods
- Revised processes
- Updated service portfolio
- Updated service catalogue
- Decision data for a new or changed service
Measurement
This is how Service Design can be measured:
- Number of changes that have to go back to Service Design to be reworked
- The number of times that the design project comes to a standstill due to lack of resources
- The number of incidents resulting from poor design
Challenges
The following elements require specific attention when implementing the process:
- Maintaining a high level of quality in the content of the design package, even for minor changes
- Producing common methods and templates for design which are accepted by all parties involved
- Incorporating and utilizing the methods and templates that already exist in the organization for, for example, development and administration
- Setting a reasonable level of ambition from the outset, complex and extensive regulations with controlled procedures can lead to the organization avoiding the process
