Print Page   |   Sign In   |   Join
Search
Calendar

19/01/2017
Masterclass: Major Incident Management

02/02/2017
Workshop: Change and Release Management

21/02/2017
Workshop: Continual Service Improvement

  Discussion forum  
 
Share your views on ITSM on our Member Discussion Forum
 
  Social Media  
 
Follow us on...
 
 
 
 

YOUR AD COULD BE HERE.
FIND OUT MORE...


The Importance of Early Life Support

The Importance of Early Life Support


Organisations spend millions for projects to go live on time and on budget, but what does that mean for support? Support costs are those that will go on for the life of the application. Priscilla Smith of BP explains how to reduce that risk through proper transitioning from project to support focusing on the importance of Early Life Support.

 

When organisations begin to implement Service Management they typically concentrate on Incident, Problem and Change.  Support teams and management often grow weary before getting to other processes after seeing the initial quick wins with the first three.  Service Transition allows an organization to be proactive with regard to what is to be supported and what support costs might be; ultimately reducing the risk of high priority incidents when projects go live. A key component of Service Transition is the introduction into operational service through Early Life Support (ELS).  

 

Description

 

The tendency in project work is to save money and time on project deployments by eliminating or modifying requirements for critical elements for transition to operations.  ELS is often overlooked in the rush to operations despite being critical to lowering risk.  Typically, ELS is the accountability of the Project team to provide the right level of technical expertise and documentation for an effective management of change.  Understanding and addressing operational costs and risk up front can save companies double or triple the cost of the project as operational costs can live on as the applications are many times in production for years.  Having a build to operate approach can create a culture of reduced costs rather than continuous service improvement reviews for operational cost cutting.  


The ELS period should be a targeted period of time within the lifecycle of the project and should only be exited once the business stakeholders, project team and the operational  service owner have agreed that all the criteria have been met and the system is stable.  This should provide ample time to verify the deployment of the approved and tested service (pre- production) that is now in production since go live.  This period should also allow time to validate and verify the service meets the business needs and is sustainable as completed in this period.  

 

Entering into Early Life Support

 

Before an application enters into production for the start of ELS it is important to determine the criterion by which it will enter and exit.  Entering into ELS should happen only when the application has been fully on-boarded into the Service Management tool so proper metrics can be recorded. Checks should be conducted to determine if business functionality has been delivered along with any engagement, or build to operate requirements. Testing, which includes interfaces with other internal and external systems should be signed off as completed.  


The exit criterion contains the specific metrics and criteria for ELS and the documentation required for knowledge transfer and handover.  This criterion should be agreed upon by stakeholders prior to the project commencing, when discussions around business requirements and service needs are decided.  It is important to include any standard production requirements for underlying infrastructure and vendor contractual agreements which might impact handover.


All incidents and service requests should be recorded in the standard Incident Management tool to ensure accurate reporting.  Therefore applications or infrastructure should be appropriately on boarded in the tool before ELS begins.

This will ensure that:

  • All data is captured correctly.
  • Ability to manage a Priority 1 or Priority 2 incident effectively is reflected.
  • Support performance metrics are captured.
  • Proper production support processes and security processes can be followed.
  • Connectivity with other IT services can be assessed.

 

Early Life Support in review

 

ELS gives operations and the project the opportunity to respond to elements of the applications that could increase support costs and complete thorough knowledge transfer to ensure operations is well prepared to deliver the agreed services. 


During ELS, the project team resolves problems that help to stabilize the service. The project resources will gradually back out from providing the additional support as the users and operational teams become familiar with the changes and the incidents and risks reduce.

 

Potential metrics for the target deployment group are; measure of service performance, performance of the Service Management processes, operations processes, the number of incidents and problems by type. The deployment team’s aim is to stabilize the service for the target deployment group or environment as quickly and effectively as possible. Keep in mind a variation in performance between different deployment groups and service units should be analysed and lessons learned from one deployment should be documented and used to improve subsequent deployments.


During ELS, the project team should ensure that the documentation and knowledge base are updated with additional diagnostics, known errors, workarounds and frequently asked questions. The team should also resolve any knowledge transfer or support training gaps within the production support teams receiving the service.  At agreed milestones during ELS, it is important to assess the issues and risks, particularly those that impact the handover schedule and costs. 


Handover considerations may include:

  • Users can use the service effectively and efficiently for their business activities.
  • Service owners and process owners are committed to manage and operate the service in accordance with the service model, performance standards and processes.
  • Service delivery is managed and controlled across any service provider interfaces.
  • Consistent progress is being made towards delivering the expected benefits and value at each milestone in early life support.
  • Service levels and service performance standards are being consistently achieved without unexpected variation before formal handover to Service Operations.
  • SLAs are finalized and signed off by senior management and business stakeholders.
  • Unexpected variations in the performance of the service and customer assets such as changes in residual risks are monitored, reported and managed appropriately.
  • Confirmed support group training and knowledge transfer activities are completed by obtaining positive confirmation from the target audience. This may be in the form of competency tests.
  • The service release, the SLA, other agreements and any contractual deliverables are signed off.

 

Early Life Support Framework:

 

Early Life Support responsibilities

 

It is often believed that ELS starts when the service has actually been transitioned into operational use. This is not the case. Early Life Support should be considered as an integral role within the release and deployment phase of the project in execution.  Those involved in ELS support should have the following key responsibilities and should be the accountability of the project team:

  • Provide IT service and business functional support prior to final acceptance by Service Operations.
  • Ensure delivery of appropriate support documentation as per service readiness.
  • Provide release acceptance for provision of initial support.
  • Provide initial support in response to incidents and errors detected within a new or changed service.
  • Adapt and perfect elements that evolve with initial usage, such as:
  • User documentation
  • Support documentation including service desk scripts
  • Data management, including archiving
  • Embed activities for a new or changed service
  • Monitor incidents and problems, and undertake problem management during release and deployment, raising requests for change as required.
  • Provide initial performance reporting and undertake service risk assessment based on performance.

Reviewing and entering into Production Support

 

Before an application enters production it is essential that testing is complete and both the project team and the support team agree the application is ready to enter into a pre- production type support environment.  Testing criterion should be based on operational as well as user specified requirements.  It is also essential that the application and infrastructure have been properly on boarded to the Service Management tool so metrics can be captured and operational workflows can be followed during ELS.  When reviewing a deployment for production the following activities should be included:

 

  • Capture experiences and feedback on customer, user and service provider satisfaction with the deployment, e.g. through feedback surveys.
  • Highlight quality criteria that were not met via the service readiness. 
  • Check that any actions, necessary fixes to known errors are complete or have remediation pans approved and in place.
  • Review open changes and ensure that funding and responsibility for open changes are agreed prior to handover.
  • Review performance targets and achievements, including resource use and capacity such as user accesses, transactions and data volumes.

 

Knowledge transfer

 

Knowledge transfer from the project team to the support team should include a list of knowledge items that have been agreed by both teams and should be part of a Knowledge Transfer Plan which includes supporting documentation for the application and knowledge articles customized for each transition. Documents should be delivered 3 to 4 weeks ahead of handover to support, depending on the size of the project.

  • During the Knowledge Transfer stage the project team will provide full support.  
  • The project team will provide a plan to have the Knowledge Transfer including the business processes of the various business functions with supporting documentation
  • Project replay sessions should be done to ensure the knowledge has been received correctly and is understood by the receiving production support areas.

 

The phases of Knowledge transfer are described below:

 

Project Primary Support – ‘Project Team Member resolves, Support Team watches’


During this phase the project team will resolve support tickets raised in the incident management tool.  

  • The support team will work with the project team to bridge any gap in knowledge. 
  • The support team will go through structured discussions with project team to understand design considerations and dependencies.  
  • The set up for the initial support process and systems are put into place. 
  • Support documentation should also be verified.

 

Parallel Support – ‘Support Team resolves, Project Team watches’

 

During this phase the support team will act as secondary support during this phase.

  • The support team will work the ticket, however the project team will be accountable for resolution of the issues as this is a new deployment.
  • Resolutions from support team will be validated by project team before sending to requestor. 
  • Identify gaps in knowledge and manage accordingly.
  • Updates to system documentation should continue to reflect feedback during ELS.  
  • Track and measure the support metrics

 

Production Primary Support – ‘Support Team resolves, Project Team catches  if
they fall’

 

During this phase the support team will act as the primary support.

  • The support team will act as the primary point of contact while the project team will only play a supporting role.
  • The support team will seek inputs from project team wherever necessary.
  • The identified gaps in knowledge will be resolved or agreed production work arounds will be documented and applied as part of production support. 
  • Updates to system documents are finalized in the appropriate archived location.
  • The support metrics have been shared with both the project and support leadership. 

 

Typical Timeline flow diagram

 

 

Exiting from Early Life Support

 

Criterion for exiting ELS should be based upon business functional requirements as defined by the project team at the beginning of the project as well as IT operational requirements for support.  All criteria for exiting ELS and entering into Operations should be included in closing documentation for the project.  This allows for reflection during lessons learned meetings and as historical documentation as to what was agreed if there are challenges after operational support begins.

 

Final closing and exit from ELS:

 

In order to exit ELS and enter into operational production support, the following components should be considered;

 

  • Agreed Exit Criterion from Early Life Support:
  • Include confirmation of known errors and bug fixes
  • All knowledge transfer sessions have been completed between the Project Resources and End Users and Operational Support teams
  • Documentation completed as per Service Readiness requirements
  • Confirmation of Production environment access has been revoked for project resources
  • The Business stakeholders are in agreement to release Early Life Support project resources.
  • Performance Reporting of the service and stability has been presented and the results agreed upon by all stakeholders.
  • The user communities have used the service to cover the full business process that the service compliments.
  • Early Life Support Resources and business community have proven the performance to a level that can be deemed as ‘Business as Usual’ as defined and agreed in the initial scope of the project
  • Any outstanding items / exit criteria that have not been met have a remediation plan in place which is acceptable to all parties.
  • Any decommissioning that was agreed as part of the initial scope of the project has been completed or is in flight. 

 

In closing:

 

In today’s cost cutting culture there may be pressure to close projects without properly testing the real time support environment.  Early Life Support allows the project, operations and the business to know and understand what will be required to support the application in question in perpetuity, reflecting true total cost of ownership.  Early Life Support documentation allows organizations to learn from the past and improve both project deployments and operations for future endeavours. 

 


Priscilla Smith is Global Service Delivery Capability Lead at BP.


Sign In


Forgot your password?

Not a Member Yet?

  Service Talk Newsletter  
 
Download the latest Service Talk and browse recent back-issues