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. It’s 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 application’s 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:
|| Description of what is in the SDP
|| 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.
| 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?
| 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?
| 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?
| 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?
| Have any new H/W components been stored in the DL with details recorded in the CMS?
| Have all new S/W components been lodged in the DL with details recorded in the CMS?
| 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)