Author: Terry Longo

ITIL for BAs – Part XI; BAs and ITIL Service Transition Processes

Written by Terry Longo on May 12, 2009. Posted in Articles.

In our two earlier posts we considered Service Transition from a policy point of view, and the significant extent to which those policies support the BA’s objectives in terms of keeping requirements management and solution development bound together tightly.

When looking at Service Transition from a process point of view, the relationship between ITIL and business analysis is as evident as could be. The ITIL processes most associated with Service Transition are:

Transition Planning and Support	Plan appropriate capacity and resources to build, test, release, deploy, implement, and place into operation new or changed services, while minimizing adverse impact on services; manage release-related risks
Change Management	Use standardized methods and procedures to efficiently and promptly handle changes that deepen business/IT alignment, and in such a way as to maximize value and minimize incidents, rework, and disruption
Service Asset and Configuration Management	Identify, control, record, report, audit, and vary service assets and configuration items (IT components); protect the integrity of the assets and components as well as the information about them; provide asset and configuration item information to other processes in order to increase the efficiency and effectiveness of those processes
Release and Deployment Management	Plan the release packages and obtain agreement with stakeholders; ensure releases can be tracked, installed, tested, verified, and/or uninstalled or backed out if necessary; manage the risks associated with releases; ensure that necessary communications and knowledge transfer take place with stakeholders and users
Service Validation and Testing	Plan and implement a structured validation and test process that yields objective evidence that a new or changed service meets the functional and Quality of Service requirements of the stakeholders
Evaluation	Provide a consistent and standardized approach to determining the performance of a service change, relative to the predicted as well as agreed to performance targets, with the purpose of understanding and managing deviations
Knowledge Management	Ensure that the right information is delivered to the appropriate place or person at the right time, in the format desired, in order to contribute to effective decision making

BAs familiar with the BABOK and with typical activities around testing, quality assurance, verification and validation would certainly be at home working within the above processes.

After all, the goals of both business analysis and ITIL, certainly from an IT point of view, are the same: develop, implement, and operate IT-based solutions that meet business needs.

We’re approaching the home stretch! There will be three more articles in this series:

Service Operation
Continual Service Improvement
What It All Means (or Should Mean?) to You

Until then, I hope that wherever you are, you are enjoying a pleasant month of May!

ITIL for BAs – Part X; BAs and ITIL Service Transition (continued)

Written by Terry Longo on April 14, 2009. Posted in Articles. 1 Comment on ITIL for BAs – Part X; BAs and ITIL Service Transition (continued)

In our last post we began reviewing the Service Transition phase of the IT Service lifecycle, specifically looking at the first seven of 14 policies:

3.2.1 Define and implement a formal policy for Service Transition
3.2.2 Implement all changes to services through Service Transition
3.2.3 Adopt a common framework and standards, and
3.2.4 Maximize re-use of established processes and systems
3.2.5 Align Service Transition plans with the business needs
3.2.6 Establish and maintain relationships with stakeholders
3.2.7 Establish effective controls and disciplines

Without further ado, let’s look at the remaining seven, keeping in mind the business/IT relationship and how these policies ought to be supported by your BA practice:

3.2.8 Provide systems for knowledge transfer and decision support
Constant change, the iterative refinement of a solution, traceability, test and acceptance activities – all of these, and many others, are underpinned by the need for information. Organizations that rely on knowledge retained in contributors’ heads are at a serious disadvantage and introduce significant risk, delay, and probable loss of business value. Furthermore, the requirements management and solution design/development team should ensure that the operations/support teams are equipped with all relevant knowledge about the requirements and the solution.

3.2.9 Plan release and deployment packages
IT organizations rarely rely on a one-to-one relationship between a solution and a release. For the sake of efficiency, releases frequently comprise multiple solutions, or even parts of multiple solutions. Solution developers and testers are not necessarily familiar with the tools and processes used in the release process, so a smooth transition to operation depends in large part upon the release team’s ability to plan, test, and document a specific release plan that minimizes disruption to the business.

3.2.10 Anticipate and manage course corrections
“The best laid schemes o’ mice an’ men/Gang aft agley.” Managing variations gracefully is of course a cultural challenge. With the BA in the middle of it all, the BA practices are a significant driver behind the nurturing of such a culture.

3.2.11 Proactively manage resources across service transitions
In other words, be not passive in the formation of the release teams. Formulate teams from individuals who specialize in the risks, procedures, and skills needed for smooth transition. Every glitch in a transition to operation takes a chink out of the business value of that solution.

3.2.12 Ensure early involvement in the service lifecycle
This is a really great policy for, and admonition to, the IT organization. Especially in organizations with software development teams hosted by the lines of business (LOBs), there is a tendency for those teams to operate independently and then initiate transition with the shared services organization to implement a solution. To remedy this, it is really important for the IT team to take the IT Service Management message to those LOB development teams and work together early. (Similarly, it is important for the BA to stay involved with the solution through its entire lifecycle, rather than handing the requirements off to the project team and then moving on to a different requirements effort.)

3.2.13 Assure the quality of the new or changed service
This is such a core part of BA that not much comment needs to be added here.

3.2.14 Proactively improve quality during service transition
In other words, do not ignore incidents, problems and other deficiencies detected during transition activities. It’s easy to recognize the sense in this, but when push comes to shove and a release deadline is looming, this policy is frequently disregarded.

Hopefully this policy summary has adequately suggested that the BA/IT relationship can be greatly empowered through the development of and adherence to these policies, in order to drive desired business outcomes.

Next time we’ll look at the specific processes related to Service Transition.

Meanwhile, please leave your thoughts/comments: what does this all mean to you?

And thanks again for visiting!

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

Written by Terry Longo on March 17, 2009. Posted in Articles. 1 Comment on 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.

ITIL for BAs – Part VIII; What is Design?

Written by Terry Longo on February 24, 2009. Posted in Articles.

A colleague of mine who is much wiser than I (that could be pretty much anyone!) defined “design” as “the art of tradeoffs”.

It is easy to “design” an IT solution for 100% availability, more than enough capacity, extremely secure, with all the functionality currently desired, etc. – and such a design would surely meet business needs! But in most cases such designs are neither practical nor feasible and are thus empty exercises. True design replaces thoughtless overkill with a prioritization of the dimensions of a solution in a way that reflects the solution’s intent. That prioritization informs tradeoff decisions driven by the realities of cost and schedule.

In earlier posts I had discussed ITIL’s general coverage of Quality of Service (QoS) requirements. In ITIL V3, the Service Design book covers five specific QoS-related processes that should be considered during design. (The book also covers Service Catalog Management and Service Level Management, which we discussed earlier). During elicitation, analysis, and solution investigation, it is quite important for the BA to engage IT, through these processes, to ensure that

those QoS characteristics are properly prioritized relative to the solution’s desired business outcome (not just the business requirements, but the outcomes that ought to be realized by meeting those requirements), and
tradeoffs between these various QoS requirements, functional scope, cost, schedule, and risk are rigorously rationalized

Capacity Management ensures “that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner”. The consideration of “current and future needs” is at the level of specific applications and solutions as well as the overall IT infrastructure and organization itself (e.g., the possibility of mergers and acquisitions).

Availability Management ensures “that the level of availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner.”

IT Service Continuity Management supports “the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, data repositories, communications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales.”

Information Security Management seeks to “align IT security with business security and ensure that information security is effectively managed in all service and Service Management activities.”

Supplier Management’s goal is “to manage suppliers and the services they supply, to provide seamless quality of IT Service to the business, ensuring value for money is obtained.”

ITIL V3 defines a “manager” role for each of the above processes. The more mature these processes and roles are in IT, the more IT is able to participate effectively with BA in

requirements elicitation and analysis
negotiation (since there will undoubtedly be times when the business asks for more than IT is presently capable of delivering)
solution rationalization

Furthermore, IT in and of itself is not in a position to make tradeoff decisions but needs the BA’s involvement in and knowledge of the requirements and desired business outcomes, in order to make those tradeoffs.

There is of course much more to design than is covered here, such as designing for manageability and supportability, planning the solution’s retirement, etc., and the Service Design book covers all of that and more.

The key takeaway from today’s post is (a) QoS requirements can and should be reflected in the IT’s organizational structure and capabilities and (b) omitting consideration of these QoS characteristics can open the business to significant risks.

How mature is your IT organization with respect to these design activities? Do you and your fellow BAs engage IT early on in the requirements process? Are there past cases where in retrospect that did not happen but should have?

Please feel free to share your comments with your fellow readers.

ITIL for BAs – Part VII; What Makes a Service Valuable?

Written by Terry Longo on February 3, 2009. Posted in Articles. 1 Comment on ITIL for BAs – Part VII; What Makes a Service Valuable?

So much of a BA’s life revolves around functional requirements that the non-functional aka supplemental aka Quality of Service (QoS) requirements do not receive the necessary attention.

ITIL V3 defines the value of an IT Service as consisting of:

Utility – the degree to which the service’s attributes have a positive effect on the execution of the customers’ tasks (e.g., steps in a business process), either by providing needed performance (functionality) or removing constraints; and
Warranty – the robustness of the service with respect to availability, capacity, security, and continuity (that is, availability as a result of a catastrophic incident)

The diagram below depicts the relationships between warranty, utility, and their respective elements:

How useful is a service that is very fit for purpose but not fit for use? The answer is that the service may have limited usefulness if its overall availability, security and responsiveness characteristics are either unpredictable or predictably very inconsistent. What about a service that is highly available, secure and responsive, but does not offer the necessary functionality? It is easier to see in this case the limited value, for the stakeholders’ primary interest is the solution’s functionality.

This model of a service’s value suggests:

Elicitation must address both sides of the “fit for use” questions – for example:
- Not only “how available must the service be”, but also “what is the cost to the business when it is unavailable” and “what is the cost if we cannot recover the service quickly enough as the result of a catastrophic failure”
- Not only how secure, but what are the costs and risks to the business without that level of security
- Not only “what is the expected demand” but “what if the solution’s response time degrades with the specified demand parameters”
Full understanding of warranty requirements can only be gained relative to the stakeholders’ desired outcomes (this is in fact implied by the question “what are the costs/risks if the solution fails”).
Fit-for-use requirements are met through some combination of (a) the architecture that will accommodate the solution and (b) various design elements of the solution that are necessary to make up for deficiencies in the architecture relative to those fit-for-use requirements.
Early identification of fit-for-use requirements can help the solution team leverage as much as possible from the existing architecture and then include in the design only what is necessary to close any gap.

It is vitally important to capture the “costs and risks if it fails” for use by Service Owners and the IT support team once the solution is in operation, as that information is the basis for IT’s prioritization of pending Incidents.

As I noted in the previous post, the BABOK first takes on QoS requirements explicitly in the Requirements Analysis coverage (Chapter 6). Hopefully you will interpret the above to mean that there is a lot of value in addressing those requirements (a) much earlier in the elicitation activities and (b) with the involvement of a core leadership team including the IT architect and lead software engineer (among others).

Here’s hoping that your 2009 is off to a great start!