Skip to main content

Author: Terry Longo

ITIL for BAs. Part VI; “Non-functional Requirements”

Written by Terry Longo on . Posted in Articles.

The two most recent posts about ITIL for BAs emphasized the roles of the IT Service, the Service Catalog, Service Level Management, and the Service Owner in encapsulating IT as a Service Provider.

It would be natural at this point to explore the ITIL/BA relationship from the Service life cycle point of view.  Much of both Service Strategy and Service Design address what are typically referred to as non-functional or supplemental requirements.  ITIL refers to them as Quality of Service (QoS) requirements.

Other BAs have rightfully pointed out (here is a good example) that QoS requirements frequently do not get the attention they deserve.  There are a number of contributing factors:

  • Stakeholders in QoS requirements are generally not the same as the functional requirements stakeholders
  • The negotiations involved in QoS requirements and functional requirements are different:
    • Functional requirements are normally negotiated by reconciling scope, schedule, and cost factors with development/test/release resources.
    • QoS requirements need to be negotiated by reconciling quality characteristics (availability, capacity, continuity, etc.) with IT infrastructure capabilities (assets), constraints (architecture), and even policy (especially in the area of information security management)
  • Elicitation techniques such as brainstorming, focus groups, interface identification, prototyping, requirements workshops, and reverse engineering are primarily used for functional requirements elicitation.
  • QoS requirements traceability is evasive; it’s one matter to trace the relationship between a function point in a software library to a step in a business process; it’s quite another matter to trace, say, the specific capacity characteristics of a particular IT component to the variety of business demands relying on that capacity.

It is also interesting to note that the BABOK addresses non-functional requirements most fully in Requirements Analysis rather than in Elicitation. 

ITIL’s coverage of QoS requirements is explicit, robust, and effective at contributing to deep business/IT integration.  This is evident particularly in the processes defined (Demand Management, Capacity Management, etc.), the extent to which those processes are embedded in the early stages of the IT Service life cycle, and the way in which ITIL defines “utility” (what the IT Service can do) and “warranty” (how well it does it) and then relates utility and warranty directly to their role in business strategy.  In my next post, we’ll cover that in more detail and then move into specific QoS-related processes and roles.

If you have any good stories to share about your BA experiences and the challenges around QoS requirements, please share them – your comments are great food for thought for your fellow BAs.

Meanwhile, Happy New Year to you and yours!

ITIL for BAs. Part V; Service Level Management

Written by Terry Longo on . Posted in Articles. 1 Comment on ITIL for BAs. Part V; Service Level Management

Our previous post discussed the value of the Service Catalog in representing IT’s general capabilities, expressed in terms of IT Services, described in the language of IT’s customers.  To quickly recap:

  • the Service Catalog represents the current state, and committed-to-future state, of IT’s capabilities,
  • Service Level Agreements (SLAs) represent the current state of the relationships between IT and its customers in terms of service delivery commitments, and
  • the Service Catalog Manager is responsible for ensuring the completeness, accuracy, and fitness for purpose of the catalog

 

The service catalog manager, however, is not responsible for ensuring that the right services are being cataloged – that responsibility belongs to the Service Level Manager, the key liaison between IT and its customers.

 

It can be easily argued that the service level manager is the IT business Aaalyst.  Just as the “business” business analyst is responsible for the entire life cycle of the business requirements and the suitability of overall business solution, so the service level manager is responsible for the entire life cycle of the IT Service requirements and the suitability of the overall IT Service solution as a contribution to the overall business solution.

 

Note that, as I have proposed numerous times in the past, there is a basic assumption that the overall business solution includes non-IT components as well (internal/external marketing, training, Both the business BA and the IT BA (the service level manager) follow a rigorous life cycle based process of managing requirements, and the distinction is a matter of scope only.  The Business Requirements Document (BRD) from the business BA will contain the requirements for the IT service as well as the requirements for the non-IT solution components.  The service level manager will run with the IT service requirements (and in fact will have ideally been engaged with the business BA early in the process of developing that BRD, identifying the appropriate solution, and formulating the supporting business case).

 

From a process point of view, the service level manager and business BA work together through all aspects of the IT service life cycle: strategy, architecture, design, development, release and deployment, operation, continual improvement, and retirement.  The types of inputs from the business BA into the service level management process are too numerous to list here but can be generally categorized as

  • functional requirements
  • non-functional aka supplemental aka Quality of Service requirements (ITIL’s preferred term), including availability, capacity, continuity, security, and manageability requirements (each of which essentially has a corresponding owner within IT, e.g., Capacity Manager, etc.)
  • service monitoring, reporting, and reviewing requirements

 

The parallels between the service level manager as defined by ITIL V3 and the business analyst as defined by the BABOK, and the business BA – service level manager relationship, are significant.  For the enterprise grappling with the question as to whether the BA should be hosted by the business or the IT organization seems likely to become fairly settled once an IT organization adopts ITIL.  It seems sometimes that the distinction between the two roles becomes clouded by the magnitude of the complexities and risks of the IT components of the business solutions.  And indeed those complexities and risks merit a lot of attention!

 

Does your IT shop practice ITIL V3?  Does your enterprise have some form of a BA Center of Excellence?  If yes to both, does your enterprise Business Analysis model recognize the Service Level Manager as a “business analyst” with an IT specialty?  I hope to see your comments below.

 

In the meantime, may you and yours have a long, relaxing and love-filled Holiday!

ITIL for BAs. Part III

Written by Terry Longo on . Posted in Articles. 2 Comments on ITIL for BAs. Part III

 

How ITIL Can Help Solve the BA Identity Crisis

 

This post is a slight digression from but still very relevant to the series we started a couple of posts ago regarding the interdependencies between BA and ITIL.  But I want to take this digression to establish a fundamental aspect of ITIL that can greatly simplify the BA’s job in working with IT-based solutions in an ITIL world.

 

 

In a May 2008 post I raised the question of where in the organization – IT or the business – a BA should be hosted.  Some great comments were posted pointing out the complexities of the issue, in terms of lines of reporting, experience, variations in the definition of the BA role, the presence or absence of the Center of Excellence, etc. 

 

My  answer to the question is that the BA – as a role – should be defined in both business and in IT.  Furthermore:

  • The BABOK is the best source for defining the responsibilities of the “Business BA” (and believe it or not, in at least one organization I know of, “Business Business Analyst” is an actual title!)
  • the role of the IT Service Owner, as defined by ITIL V3, is in fact the “IT BA”

 

In attending the PMI Global Congress, Project World, BA World, and itSMF Fusion events during the last six months, I have had discussions with numerous PMs and BAs who have heard of ITIL and wanted to know what it was all about, in 20 words or less – to which I typically respond: “ITIL is to IT management what the PMBOK is to Project Management and the BABOK is to Business Analysis”.  They pretty much get it right away.

 

Back to my reason for this digression, though, to take that analogy a bit deeper: ITIL is a practice through which the IT organization is encapsulated by a layer of IT Services, and in which:

  • the IT Service Catalog describes what IT’s capabilities are, in the Customers’ language,
  • the Service Level Agreement (SLA) defines how specific IT Services are to be delivered to specific customers, and
  • the IT Service Owner embodies those IT Service capabilities, marshals the IT Service through its entire life cycle, owns the SLAs, and is measured according to the degree to which actual IT Service delivery meets the terms and conditions of the SLA.

 

(Actually, the practice of encapsulating IT in this way – the “what” that IT is striving for – is known as IT Service Management, with ITIL being a best practice in “how” IT Service Management can be accomplished.)

 

Now, getting directly back to the purpose of this “ITIL and BA” series….  The process of identifying business requirements and solutions is iterative and hierarchical – a process of elaboration, as the PMBOK so eloquently points out.  At some point in that process of elaboration, the BA encounters the IT part of the overall solution.  Here is where the BA meets the IT Service Owner and why an understanding of the BA/ITIL touchpoints is so important:

  • Without ITIL and the presence of the role of the IT Service Owner, it is typically the BA who is expected to know the ins and outs of the IT infrastructure and IT’s capabilities, risks, etc.
  • With an ITIL-based IT organization, the IT Service Owner is expected to know the ins and outs of the IT organization, and the costs and risks related to the IT Service required in the solution.

 

To put it another way, the BA can depend on the IT Service Owner to elicit, analyze, and document, in the form of a Service Level Agreement, what is needed from the IT Service, while the IT Service Owner is responsible for understanding the how – that is, the IT infrastructure and IT’s capabilities to satisfy the what.

 

With this in mind, the BA’s view of an ITIL-based IT organization, and the IT Services IT is providing, becomes a matter of understanding IT in terms of

  • the ITIL processes that take an IT Service through its life cycle of Design, Transition, Operation, and Continual Service Improvement, specifically
    • inputs needed from the BA
    • outputs consumed by or of interest to the BA
    • activities that the BA can contribute to
  • the Service Catalog and Service Level Agreements as the basis for understanding IT’s capabilities

 

In the May 2008 post mentioned above, one reader comment pointed out that it is very challenging for BAs to manage solutions that embrace multiple systems.  Encapsulating those various system components as IT Services, managed by the IT Service Owner, can go a very long way toward empowering the BA to deal with those complex solutions more effectively.

 

If you have any reactions to this concept – pro or con – it would be great to hear them.  I hope you take a minute to mull this over and leave a comment below.  Many thanks!

ITIL for BAs. Part II

Written by Terry Longo on . Posted in Articles. 1 Comment on ITIL for BAs. Part II

Service Strategy

If one purpose of any strategy is to express a consolidated, comprehensive view of mission and direction, then the BA should expect that an IT organization’s IT Service Strategy is embodied within the IT organization’s structure and the roles defined.

In ITIL V3 that embodiment of IT Strategy is realized through the role of the product manager, whose responsibilities include: 

  • driving service strategy 
  • managing services across their entire life cycle (concept, design, transition, operation, retirement) 
  • ownership and maintenance of the service catalog, an essential document that describes IT’s service capabilities in the customers’ terms
  • understanding IT’s service models and how to drive changes and improvements effectively through those models
  • knowing the costs and risks associated with the lines of Service they represent
  • evaluating new technologies and operating models that can be leveraged for greater efficiency and effectiveness
  • providing financial analysis of existing, planned, and proposed services
  • supporting the business in building business cases for new services or improvements to existing services

The above responsibilities are only half of the story, as they are primarily inward-focused.  On whose behalf is the product manager carrying out those activities?  In ITIL V3 it is the primary relationship the product manager has with the business s through the Business Relationship Manager (BRM), who represents the customers and their IT service requirements.  Together the product manager and the BRM work to 

  • understand the financial elements of IT Service delivery
  • express the demand the customers will have on IT Services (new and existing)
  • build business cases from a life cycle point of view
  • manage the resulting service(s) within the context of their respective IT service and business solution portfolios

In BA terms, the BRM is the business analyst.

It is interesting to note that the definition of the product manager directly addresses (I think) the question of whether a business analyst should be part of the business or part of IT – the answer is both, for the ITIL V3 product manager is, in essence, a “business analyst”, with a specific focus on IT Services.

For more information, ITIL Service Strategy Appendix B section B2 presents a concise summary of the nature and value of those two roles.  ITIL V3 books are available from most major booksellers and also from the IT Service Management Forum (itSMF) at the publications section of their Web site at http://www.itsmfusa.org/.

ITIL for BAs. Part I

Written by Terry Longo on . Posted in Articles. 2 Comments on ITIL for BAs. Part I

If you are a regular reader of this blog, you know of my deep interest in both ITIL and BA, and particularly their interdependencies.  One driver behind that interest is my observation (validated by numerous colleagues) that, all too often, people in specific practices (PM, software development, IT operations, BPE, SOA, BA, etc.) are strong and focused in their domain but neglect the touchpoints and integrations with other practices.  It is a sort of “best practice” silo phenomenon analogous to the technology silos in IT organizations.

There is a significant amount of overlap between the BABOK and ITIL, with lots to sort out.  Furthermore, the differences between the two practices in terms of activities, inputs, outputs, roles, metrics, and organizational structure are noteworthy, and because of ITIL’s significant dependence on strong BA, those differences will need to be reconciled to get the most out of our BA/ITIL integration efforts.

In this post I would like to kick off a deeper treatment of the BA/ITIL connections, starting with a description of ITIL v3’s overall structure in terms of the service life cycle and key processes.  Future posts will then cover specific touchpoints between BA and IT.

So, let’s begin at the beginning.  ITIL is all about encapsulating IT (the infrastructure and the organization) such that the users and customers view IT as a service provider that is integrated into the business.  ITIL’s definition of a service is:

a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks

In other words, by adopting ITIL, an IT organization is saying to its customers, “tell us what you need, in your terms, and we’ll take care of the nuts and bolts”.  This means that the business sets the context that defines the value of IT’s contribution, which is, delivering solutions that satisfy requirements that facilitate desired business outcomes.

When you add up (a) the complexities of IT-based solutions, (b) the increased rate of change in business and IT, and (c) management’s need for monitoring and control, it is clear that a BA needs to be tightly involved with IT throughout the life cycle of an IT-based solution.

ITIL v3 is especially well-suited to accommodate such involvement.  In its simplest terms, the core of ITIL v3 is a set of five books reflecting the IT Service life cycle phases of

  • Service Strategy
  • Service Design
  • Service Transition
  • Service Operation
  • Continual Service Improvement

At this level it is easy to see that the service life cycle is a very effective context for the BA’s activities.  Let’s look one level deeper now, into the specific processes associated with each of those life cycles – the process names alone are sufficient to suggest the breadth of opportunities BAs have to drive BA/ITIL integration:

  • Service Strategy
    • Strategy Generation
    • Service Portfolio Management
    • Demand Management
    • Financial Management
  • Service Design 
    • Service Catalog Management
    • Information Security Management
    • Supplier Management 
    • IT Service Continuity Management
    • Service Level Management
    • Capacity Management
    • Availability Management
  • Service Transition
    • Transition Planning and Support
    • Change Management
    • Service Asset and Configuration Management
    • Release and Deployment Management
    • Service Validation and Testing
    • Evaluation
    • Knowledge Management
  • Service Operation
    • Event Management
    • Incident Management
    • Request Fulfillment 
    • Access Management
    • Problem Management
  • Continual Service Improvement

For the BA, several of the above processes, such as Service Validation and Testing, Change Management, and Financial Management, jump off the page because of their relevance to BA.

Beginning with our next post, we’ll start to tackle the above processes individually in terms of their overall purpose and their relevance to BA as defined in the BABOK.

Meanwhile, I encourage you to post your comments/thoughts!