Identifying and documenting business requirements and drivers
IT must retain accurate information on business requirements and drivers if it is to provide the most appropriate catalogue of services with an acceptable level of service quality that is aligned to business needs. Business drivers are the people, information and tasks that support the fulfilment of business objectives. This requires that IT develops and maintains close, regular and appropriate relationships and exchange of information in order to understand the operational, tactical and strategic requirements of the business. This information needs to be obtained and agreed in two main areas to maintain service alignment:
- Information on the requirements of existing services – what changes will be required to existing services with regard to:
- New facilities and functionality requirements
- Changes in business processes, dependencies, priorities, criticality and impact
- Changes in volumes of service transactions
- Increased service levels and service level targets due to new business driver, or reduced for old services, lowering priority for those due for replacement
- Additional needs for Service Management information.
- Information on the requirements of new services:
- Facilities and functionality required
- Management information required and management needs
- Business processes supported, dependencies, priorities, criticality and impact
- Business cycles and seasonal variations
- Service level requirements and service level targets
- Business transaction levels, service transaction levels, numbers and types of users and anticipated future growth
- Business justification, including the financial and strategic aspects
- Predicted level of change, e.g. known future business requirements or enhancement
- Level of business capability or support to be provided, e.g. local business-based support.
This collection of information is the first and most important stage for designing and delivering new services or major changes to existing services. The need for accurate and representative information from the business is paramount. This must be agreed and signed off with senior representatives within the business. If incorrect or misleading information is obtained and used at this stage, then all subsequent stages will be delivering services that do not match the needs of the business. Also, there must be some formal process for the agreement and acceptance of changes to the business requirements, as these will often change and evolve during the Service Lifecycle. The requirements and the design must evolve with the changing business environment to ensure that the business expectations are met. However, this must be a carefully managed process to ensure that the rate of change is kept at an agreed and manageable level, and does not ‘swamp’ and excessively delay the project or its implementation.
In order to design and deliver IT services that meet the needs of the customers and the business, clear, concise, unambiguous specifications of the requirements must be documented and agreed. Time spent in these activities will prevent issues and discussion from arising later with regard to variances from customer and business expectation. This business requirements stage should consist of:
- Appointment of a project manager, the creation of a project team and the agreement of project governance by the application of a formal, structured project methodology
- Identification of all stakeholders, including the documentation of all requirements from all stakeholders and stakeholder benefits they will obtain from the implementation
- Requirements analysis, prioritization, agreement and documentation
- Determination and agreement of outline budgets and business benefits. The budget must be committed by management, because it is normal practice to decide next year’s budget in the last quarter of the previous year, so any plans must be submitted within this cycle
- Resolution of the potential conflict between business units and agreement on corporate requirements
- Sign-off processes for the agreed requirements and a method for agreeing and accepting changes to the agreed requirements. Often the process of developing requirements is an iterative or incremental approach that needs to be carefully controlled to manage ‘scope creep’
- Development of a customer engagement plan, outlining the main relationships between IT and the business and how these relationships and necessary communication to wider stakeholders will be managed.
Where service requirements are concerned, they sometimes come with a price tag (which might not be entirely known at this stage), so there always needs to be a balance between the service achievable and the cost. This may mean that some requirements may be too costly to include and may have to be dropped during the financial assessment involved within the design process. If this is necessary, all decisions to omit any service requirements from the design of the service must be documented and agreed with the representatives of the business. There is often a difficulty when what the business wants and the budget allocated for the solution do not take into account the full service costs, including the ongoing costs
All design activities are triggered by changes in business needs or service improvements. A structured and holistic approach to the design activities should be adopted, so that all available information is considered to ensure consistency and integration is achieved throughout the IT service provider organization, within all design activities.
Architectures and designs should be kept, clear, concise, simple and relevant. All too often, designs and architectures are complex and theoretical and do not relate to the ‘real world’.
The main problem today is that organizations often only focus on the functional requirements. A design or architecture by definition needs to consider all design aspects. It is not a smaller organization that combines these aspects, it is a sensible one.
The design processes activities are:
- Requirements collection, analysis and engineering to ensure that business requirements are clearly documented and agreed
- Design of appropriate services, technology, processes, information and process measurements to meet business requirements
- Review and revision of all processes and documents involved in Service Design, including designs, plans, architectures and policies
- Liaison with all other design and planning activities and roles, e.g. solution design
- Production and maintenance of IT policies and design documents, including designs, plans, architectures and policies
- Revision of all design documents, and planning for the deployment and implementation of IT strategies using ‘roadmaps’, programmes and project plans
- Risk assessment and management of all design processes and deliverables
- Ensuring alignment with all corporate and IT strategies and policies.
The inputs to the various design activities are:
- Corporate visions, strategies, objectives, policies and plans, business visions, strategies, objectives and plans, including Business Continuity Plans (BCPs)
- Constraints and requirements for compliance with legislated standards and regulations
- IT strategies and strategic documents (from Service Strategy):
- All IT strategies, policies and strategic plans
- Details of business requirements
- All constraints, financial budgets and plans
- The Service Portfolio
- Service Management visions, strategies, policies, objectives and plans
- IT and Service Management processes, risks and issues registers
- Service Transition plans (Change, Configuration and Release and Deployment Management Plans)
- Security policies, handbooks and plans
- The procurement and contract policy, supplier strategy and Supplier Management processes
- The current staff knowledge, skills and capability
- IT business plans, Business and IT Quality Plans and policies
- Service Management plans, including Service Level Management Plans, SLAs and SLRs, Service Improvement Plan (SIP), Capacity Plans, Availability Plans, IT Service Continuity Plans
- Measurement tools and techniques
The deliverables from the design activities are:
- Suggested revisions to IT strategies and policies
- Revised designs, plans and technology and management architectures, including:
- The IT infrastructure and infrastructure management and environmental strategy, designs, plans, architectures and policies
- The applications and data strategies, designs, plans, architectures and policies
- Designs for new or changed services, processes and technologies
- Process review and analysis reports, with revised and improved processes and procedures
- Revised measurement methods and processes
- Managed levels of risk, and risk assessment and management reports
- Business cases and feasibility studies, together with Statements of Requirements (SORs) and Invitations to Tender (ITTs)
- Comments and feedback on all other plans
- Business benefit and realization reviews and reports.
An overall, integrated approach should be adopted for the design activities documented in the previous section and should cover the design of:
- Service solutions, including all of the functional requirements, resources and capabilities needed and agreed
- Service Management systems and tools, especially the Service Portfolio for the management and control of services through their lifecycle
- Technology architectures and management architectures and tools required to provide the services
- Processes needed to design, transition, operate and improve the services
- Measurement systems, methods and metrics for the services, the architectures and their constituent components and the processes.
The key aspect is the design of new or changed service solutions to meet changing business needs. Every time a new service solution is produced, it needs to be checked against each of the other aspects to ensure that it will integrate and interface with all of the other services already in existence. These five aspects of Service Design are covered in more detail in the following sections. The plans produced by Service Design for the design, transition and subsequent operation of these five different aspects should include: