Challenges, Critical Success Factors and risks. With every undertaking there will be challenges or difficulties to face and to overcome


With every undertaking there will be challenges or difficulties to face and to overcome. This will be especially true when attempting to design new services and processes that meet the requirements of all stakeholders within the business. Experience has shown that the following will help to overcome the challenges:

  • Understanding the business requirements and the business priorities and ensuring that these are uppermost in mind when designing the processes and the services.
  • Communications will be vitally important both in explaining what is happening and how individuals will be affected and in listening to the requirements and needs of the individuals. Its vitally important to communicate with people about concerns that relate to their daily job.
  • Involve as many people as possible in the design. Setting up focus groups or steering groups can be very effective in getting the right solution as well as gaining wider support.
  • Gaining commitment from senior management as well as from all levels of staff.

Examples of challenges that may be faced include:

  • The need to ensure alignment with current architectural directions, strategy and policies. An example of this may be that the procured infrastructure may have poor monitoring and control features.
  • The use of diverse and disparate technologies and applications.
  • Documentation and adherence to agreed practices and processes.
  • Unclear or changing requirements from the business. This may be unavoidable in some cases because business needs are likely to change. The important thing is to ensure that there is a very close relationship between the IT service provider organization and the business customer of the service, so that any changing requirements can be identified as quickly as possible.
  • A lack of awareness and knowledge of service and business targets and requirements.
  • Linked to the above point, it may be that certain facilities are not built into the design. Again, it is imperative that representatives of every user of the designed service or process are involved throughout the process to reduce the chance of this happening. Details of service testing (an important element here) are contained within the Service Transition publication.
  • A resistance to planning, or a lack of planning leading to unplanned initiatives and unplanned purchases.
  • Inefficient use of resources causing wasted spend and investment.
  • As mentioned previously, a good knowledge and appreciation of the business impacts and priorities is imperative.
  • Poor relationships, communication or lack of cooperation between the IT service provider and the business may result in the design not achieving the business requirements.
  • Resistance to work within the agreed strategy.
  • Use of, and therefore the constraints of, old technology and legacy systems.
  • Required tools are too costly or too complex to implement or maintain with the current staff skills.
  • Lack of information, monitoring and measurements.
  • Unreasonable targets and timescales previously agreed in the SLAs and OLAs.
  • Over-commitment of available resources with an associated inability to deliver (e.g. projects always late or over budget).
  • Poor Supplier Management and/or poor supplier performance.
  • Lack of focus on service availability.
  • Lack of awareness and adherence to the operational aspects of security policies and procedures.
  • Ensuring normal daily operation or business as usual is considered as part of the design.
  • Cost and budgetary constraints.
  • Ascertaining the ROI and the realization of business benefit.


There are a number of risks directly associated with the Service Design phase of the Service Lifecycle. These risks need to be identified to ensure that they are not realized. They include the following:

  • If any of the PFSs for Service Design are not met, then the Service Design or Service Management process will not be successful.
  • If maturity levels of one process are low, it will be impossible to achieve full maturity in other processes.
  • Business requirements are not clear to IT staff.
  • Business timescales are such that insufficient time is given for proper Service Design.
  • Insufficient testing, resulting in poor design and therefore poor implementation.
  • An incorrect balance is struck between innovation, risk and cost while seeking a competitive edge, where desired by the business.
  • The fit between infrastructures, customers and partners is not sufficient to meet the overall business requirements.
  • A coordinated interface is not provided between IT planners and business planners.
  • The policies and strategies, especially the Service Management strategy, are not available from Service Strategy, or its content is not clearly understood.
  • There are insufficient resources and budget available for Service Design activities.
  • The risk of services developed in isolation using their own assets and infrastructure. This can appear to be cheaper in isolation, but can be much more costly in the long term because of the financial savings of corporate buying and the extra cost of supporting different architecture.
  • Insufficient time given to the design phase, or insufficient training given to the staff tasked with the design.
  • Insufficient engagement or commitment with the applications functional development, leading to insufficient attention to Service Design requirements.



Service Design, as described in this publication, covers the design of appropriate and innovative IT services to meet current and future agreed business requirements. Service Design develops a Service Design Package and looks at selecting the appropriate Service Design model. In this publication we have also examined the various sourcing models available and given some benefits and disadvantages to each.

The publication also discusses the fundamentals of the design processes and the five aspects of the design:

  • The design of the service solutions, including all of the functional requirements, resources and capabilities needed and agreed
  • The design of Service Management systems and tools, especially the Service Portfolio for the management and control of services through their lifecycle
  • The design of the technology architectures and management architectures and tools required to provide the services
  • The design or specification of the processes needed to design, transition, operate and improve the services, the architectures and the processes themselves
  • The design of the measurement systems, methods and metrics for the services, the architectures and their constituent components and the processes.

The definition of Service Design is:

The design of appropriate and innovative IT services, including their architectures, processes, policies and documentation, to meet current and future agreed business requirements.

The publication has explained that the better and more careful the design, the better the solution taken into live operation. It is also highly likely that the better the design, the less re-work time that will need to be undertaken during the transition and live phases.

The scope of this publication includes the design of services, as well as the design of Service Management systems and processes. Service Design is not limited to new services, but includes change necessary to increase or maintain value to customers over the lifecycle of services.

This publication explains that pragmatism sometimes overrides the perfect solution where we know what it would be, but the amount of effort and cost does not justify the perfect solution. As always it will depend on the business needs and the business requirements. As always it is imperative that whatever is done within IT has a direct benefit to the overall business

Appendix A: The Service Design Package

A Service Design Package or SDP should be produced during the design stage, for each new service, major change to a service or removal of a service or changes to the Service Design Package itself. This pack is then passed from Service Design to Service Transition and details all aspects of the service and its requirements through all of the subsequent stages of its lifecycle. The SDP should contain:

Category Sub-category Description of what is in the SDP
Requirements Business requirements The initial agreed and documented business requirements
  Service applicability This defines how and where the service would be used. This could reference business, customer and user requirements for internal services
  Service contacts The business contacts, customer contacts and stakeholders in the service
Service Design Service functional requirements The changed functionality of the new or changed service, including its planned outcomes and deliverables, in a formally agreed Statement of Requirements (SoR)
  Service Level Requirements The SLR, revised or new SLA, including service and quality targets
  Service and operational management requirements Management requirements to manage the new or changed service and its components, including all supporting services and agreements, control, operation, monitoring, measuring and reporting
  Service Design and topology The design, transition and subsequent implementation and operation of the service solution and its supporting components, including:
  • The service definition and model, for transition and operation
  • All service components and infrastructure (including H/W, S/W, networks, environments, data, applications, technology, tools, documentation), including version numbers and relationships, preferably within the CMS
  • All user, business, service, component, transition, support and operational documentation
  • Processes, procedures, measurements, metrics and reports
  • Supporting products, services, agreements and suppliers
Organizational Readiness Assessment Organizational Readiness Assessment Organizational Readiness Assessment report and plan, including: business benefit, financial assessment, technical assessment, resource assessment and organizational assessment, together with details of all new skills, competences, capabilities required of the service provider organization, its suppliers, supporting services and contracts
Service Lifecycle Plan Service Programme An overall programme or plan covering all stages of the lifecycle of the service, including the timescales and phasing, for the transition, operation and subsequent improvement of the new service including:
  • Management, coordination and integration with any other projects, or new or changed activities, services or processes
  • Management of risks and issues
  • Scope, objectives and components of the service
  • Skills, competences, roles and responsibilities
  • Processes required
  • Interfaces and dependencies with other services
  • Management of teams, resources, tools, technology, budgets, facilities required
  • Management of suppliers and contracts
  • Progress reports, reviews and revision of the programme and plans
  • Communication plans and training plans
  • Timescales, deliverables, targets and quality targets for each stage
  Service Transition Plan Overall transition strategy, objectives, policy, risk assessment and plans including:
  • Build policy, plans and requirements, including service and component build plans, specifications, control and environments, technology, tools, processes, methods and mechanisms, including all platforms
  • Testing policy, plans and requirements, including test environments, technology, tools, processes, methods and mechanisms
  • Testing must include:
    • Functional testing
    • Component testing, including all suppliers, contracts and externally provided supporting products and services
    • User acceptance and usability testing
    • System compatibility and integration testing
    • Service and component performance and capacity testing
    • Resilience and continuity testing
    • Failure, alarm and event categorization, processing and testing
    • Service and component, security and integrity testing
    • Logistics, release and distribution testing
    • Management testing, including control, monitoring, measuring and reporting, together with backup, recovery and all batch scheduling and processing
  • Deployment policy, release policy, plans and requirements, including logistics, deployment, roll-out, staging, deployment environments, cultural change, organizational change, technology, tools, processes, approach, methods and mechanisms, including all platforms, knowledge, skill and competence transfer and development, supplier and contract transition, data migration and conversion
  Service Operational Acceptance Plan Overall operational strategy, objectives, policy, risk assessment and plans including:
  • Interface and dependency management and planning
  • Events, reports, service issues, including all changes, releases, resolved incidents, problems and known errors, included within the service and any errors, issues or non-conformances within the new service
  • Final service acceptance
  Service Acceptance Criteria Development and use of Service Acceptance Criteria (SAC) for progression through each stage of the Service Lifecycle, including:
  • All environments
  • Guarantee and pilot criteria and periods

Table A.1 Contents of the Service Design Package

Appendix B: Service Acceptance Criteria (example)

The Service Acceptance Criteria (SAC) is a set of criteria used to ensure that the service meets its expected functionality and quality and that the service provider is ready to deliver the new service once it has been deployed.

Criteria Responsibility
Have the go-live date and the guarantee period been agreed with all concerned parties, together with final acceptance criteria? Change, Service level
Have the deployment project and schedule been documented agreed and made public to all affected personnel? Change, Incident
Has the SLA/SLR been reviewed, revised and agreed with all concerned parties? Service level
Has the service been entered/updated in the Service Catalogue/Service Portfolio within the CMS and appropriate relationships established for all supporting components? Service level, Configuration
Have all customers and stakeholders been identified and recorded in the CMS? Service level, Business Relationship
Have all operational risks associated with running the new service been assessed and mitigation actions completed where appropriate? Business Continuity, Availability
Have contingency and fail-over measures been successfully tested and added to the overall resilience test schedule? Business Continuity, Availability
Can all SLA/SLR targets be monitored, measured, reported and reviewed, including availability and performance? Service level, Availability
Have all users been identified/approved and their appropriate accounts created for them? Account Management
Can all workload characteristics, performance and capacity targets be measured and incorporated into Capacity Plans? Capacity
Have all operational processes, schedules and procedures been agreed, tested, documented and accepted (e.g. site documentation, backups, housekeeping, archiving, retention)? Operations, Business Continuity
Have all batch jobs and printing requirements been agreed, tested, documented and accepted? Operations
Have all test plans been completed successfully? Test Manager
Have all security checks and tests been competed successfully? Security Compliance
Are appropriate monitoring and measurement tools and procedures in place to monitor the new service, together with an out-of-hours support rota? Systems Management
Have all ongoing operational workloads and costs been identified and approved? Operations, IT Finance
Are all service and component operational costs understood and incorporated into financial processes and the cost model? IT Finance
Have incident and problem categories and processes been reviewed and revised for the new service, together with any known errors and deficiencies? Incident, Problem Reporting
Have all new suppliers been identified and their associated contracts drawn up accordingly? Contract and Supplier Management
Have all support arrangements been reviewed and revised SLAs, SLRs, OLAs and contracts agreed, with documentation accepted by all teams (including suppliers, support teams, Supplier Management, development teams and application support)? Project Manager
Has appropriate technical support documentation been provided and accepted by Incident, Problem and all IT support teams? Incident, Problem
Have all RFCS and Release Records been authorized and updated? Change
Have all service, SLA, SLR, OLA and contract details, together with all applications and infrastructure component details, been entered on the CMS? Project Management, Support Teams Configuration
Have appropriate S/W licences been purchased or reallocated licences used? Configuration
Have any new H/W components been stored in the DL with details recorded in the CMS? Configuration
Have all new S/W components been lodged in the DL with details recorded in the CMS? Configuration
Have all maintenance and upgrade plans been agreed, together with release policies, frequencies and mechanisms? Release and Deployment
Have all users been trained, and has user documentation been accepted and supplied to all users? Project Manager
Are all relationships, interfaces and dependencies with all other internal and external systems and services documented, agreed and supported? Project Manager
Have appropriate business managers signed off acceptance of new service? Project Manager

Table B.1 Service Acceptance Criteria

Appendix C: Process documentation templates (example)

sdamzavas.net - 2020 . ! , ...