Skip to main content

ITIL for BAs – Part IX; BAs and ITIL Service Transition

So now we’re following good practices in both the BA space and the IT space around IT solution design. We’re taking into account not only the functional requirements but also the Quality of Service requirements represented by the ITIL Service Design processes.

One approach to understanding the importance of the BA’s involvement in Service Transition is to review its underlying policies.  First, though, before we dive into those details, I’d like to emphasize (again, probably!) the following philosophical points:

  • IT’s focus is on the IT Service and its lifecycle, but the business solution that the IT Service is a part of undoubtedly comprises other elements that may be outside of IT’s scope (for example, internal or external marketing requirements, customer-facing collateral development, end-user training, etc.)
  • The BA would do well to consider the application of Service Management principles to domains outside of IT, as indeed, those non-IT elements of a business solution are as subject to lifecycle forces as the IT Services are.

My use of “BA” henceforth is referring to a business BA, one who is responsible for the entire business solution rather than just the IT portion.  (The notion of where a BA is hosted in an organization has been treated, perhaps ad nauseam, in earlier columns and by other BAs.)

To this point in our ITIL for BAs series, we’ve looked at the specific ITIL processes within specific lifecycle phases.  For Service Transition, we’ll first look at the policies upon which transition processes are based, as understanding those policies will greatly enrich our understanding of the value of those processes in delivering services that are valuable to the business.  Let’s take a look at the first seven of 14 Service Transitions (the section number from the Service Transition book is included with each policy):

3.2.1 Define and implement a formal policy for Service Transition
At the core of both Business Analysis and Service Transition, we find the common element of managing change.  The business and IT must work in lockstep in marshalling those changes from conception to operation. This synchronization is necessary to ensure that IT’s deliverables do indeed drive desired business outcomes.

3.2.2 Implement all changes to services through Service Transition
In days of yore, IT organizations began to recognize that a significant portion (I’ve heard figures as high as 80%) of incidents could be attributed to changes made to the infrastructure.  One fundamental objective of Service Transition is to control changes in order to maintain a sufficiently high level of quality, both of the service being transitioned as well as of the services already in operation.  The BA needs to be familiar with change procedures and policies to ensure that the constraints imposed by those procedures accommodate the business’s needs.

3.2.3 Adopt a common framework and standards, and
3.2.4 Maximize re-use of established processes and systems

The BA will producing artifacts that are inputs into various Service Transition processes.  Furthermore, the BA is an important source of input to ensure that IT frameworks and standards are consistent with business frameworks and standards.

3.2.5 Align Service Transition plans with the business needs
I keep thinking about the issue of BAs “throwing the requirements over the fence” to the project team and then moving on to another BA activity.  It is easy to find project post-mortems indicating that there was little or no match between the project’s deliverables and the business’s needs.  (It is possible for a project to succeed in terms of scope, schedule and budget, yet fail from the business stakeholders’ point of view.)  I envision BA and PM being the two sides of a zipper which, if not continuously drawn together results in a disconnect between the solution and the requirements.  (The Zipper of the Jacket of Solution Integrity?  Sorry, that’s the best I can do right now!)

3.2.6 Establish and maintain relationships with stakeholders
Now, the term stakeholders as used here refers to any stakeholder in the service, but certainly the BA is a pivotal character in the IT/business relationships, and this policy (as well as others) manifests itself in the design of transition processes that encourage, indeed require, such relationship management.

3.2.7 Establish effective controls and disciplines
These controls and disciplines include controls and disciplines directly involving the BA. These include defining roles, responsibilities, and handoff protocols and verification during all build, test, release and deployment activities.

In the next installment we will cover the remaining seven Service Transition policies, and in the subsequent installment we’ll move into the specific Service Transition processes of

  • Transition Planning and Support
  • Change Management
  • Service Asset and Configuration Management
  • Release and Deployment Management
  • Service Validation and Testing
  • Evaluation
  • Knowledge Management

Thanks again for visiting!  And during the next couple of weeks, consider sharing your thoughts about the above as well as your perspective on how ITIL and BA can help organizations weather our current economic challenges.