Skip to main content

Author: Terry Longo

Business Cases, Budgets and Bear Markets

ITIL v3 presents a definition of value that may improve our ability to judge the impact on IT Service quality of certain common cost-cutting measures.

ITIL v3 defines the value of a service in terms of Utility (functional requirements) and Warranty (non-functional or supplemental or Quality of Service requirements).  Warranty is expressed in terms of the security, capacity, availability (normal operational circumstances), and continuity (involving the implementation of recovery plans).

The two underlying drivers for determining the appropriate level of Warranty are the Business Case for building the service and the Service Level Agreement for actual delivery of the service.

The point of Utility is to ensure that the business can make use of the functionality provided by the IT Service to drive desired business outcomes.  The point of Warranty is to ensure the delivery of service within certain bounds of variability.  In other words:

  • High Utility and low Warranty means the service is fit for purpose but is not reliable
  • High Warranty and low Utility means the service is very reliable but of little value in driving business outcomes

ITIL v3 also draws the distinction between resources within IT (infrastructure components, documentation, information, people, etc.) and the capability the organization has to make use of those resources, efficiently and effectively, for optimal service delivery.  Capabilities include the processes, functions, and the people acting in specific roles, all making use of resources to deliver services.

One disconnect I see time and time again when enterprises take cost-cutting measures, is a broad reduction in training activities, as sort of a policy – in other words, a horizontal impact on capability (people acting in specific roles).  [Full disclosure: I manage HP Education’s ITIL, PM and BA curriculums in the US.]

To what extent does such a decision impact Warranty – the variability in the quality of the services being delivered?  Would it not be better to approach a cost-cutting decision from a portfolio point of view, reducing capability for lower-priority services?  Should not cost-cutting measures be related back to Business Cases and Service Level Agreements? 

Are you and your BA colleagues routinely involved in such broad cost-cutting decisions?

Defining Roles Cycle in the BA Life

Last time I asked “Can a senior BA really be skilled in all aspects of the solution life cycle?”. My humblest apologies to those of you who have shown such capability – hats off to you! I did not mean to imply impossibility, just that it is a long haul to get to that point.

I’ve always thought end-to-end ownership of an initiative, by a single person, results in a high level of “conceptual integrity” – having a single BA own a set of requirements and its corresponding solution(s) has great benefits. However, finding those BAs who are strong in all areas of the BABOK poses a challenge for many organizations, especially when so many BAs (by other names, to be certain) have specialized in a particular solution area.

It is easy to envision multiple roles with the BA life cycle, allowing someone to focus on a particular set of tasks/techniques, for example: 

  • Enterprise Analyst 
  • Business Case Specialist 
  • Elicitation Specialist 
  • Survey Designer and Psychometric Analyst 
  • Validation Specialist

If those activities and others were carried out by BAs with special focus, there would still be value (indeed, a need) for a BA with overarching responsibility for the team of BA specialists.

What about your organization? Do you have BAs who specialize in a particular aspect of the requirements life cycle? If so: 

  • What are the specialties? 
  • What is in place to ensure continuity in their handoffs from one phase of the life cycle to another, and how sophisticated are the tools underpinning that process? 
  • Has your organization defined career paths that manifest those specialties?

Even if your organization does not distinguish such specialties but you have given it some consideration, we’d love to hear your thoughts.

Random Thoughts on Service Management

  • Google suits my impulsive mind perfectly and is a great first step in discovering whether an idea is “out there” yet. Yesterday I searched for “service-oriented business analysis” and was not disappointed with the results – only seven hits, but this one points to an excellent six-part treatment of SOA and BA.

  • Can a senior BA really be skilled in all aspects of the solution life cycle? As I ponder the scope of BA, I grow more convinced that business requirements elicitation alone could be a fulfilling and challenging career.
  • And speaking of elicitation, if you peel back the first layer of the “agile business analysis” onion, one of the things you would see is agile elicitation. What does that mean in terms of the day-to-day relationship between the BA and the business stakeholders? Would it border on pestering? (Just kidding, kind of….) But what a magnificent way to help drive change management into the core of that relationship.
  • Service modeling in the true SOA sense takes a common concept – refactoring – and applies it to a broader context – the enterprise. There are clearly application refactoring techniques that can be leveraged in an organization’s SOA, service modeling, and BPM initiatives.
  • And speaking of SOA and services, their value arises out of what I have always believed to be the most important and fundamental notion coming out of the Object Oriented fury of the 1990s: that of encapsulation. Inheritance? Polymorphism? Frequently, copy-and-paste is the better technique. But nothing beats encapsulation – it’s the heart of separating the What from the How.
  • SOA and ITIL v3 are a perfect match – BAs involved in business architecture and IT-based solutions would do well to become fluent in both.
  • And speaking of the What vs. the How, it is only a matter of time before nearly every discipline in the enterprise will be modeled as a service, with service level agreements, metrics and measures, reporting and reviewing, and a context of continual service improvement and alignment to targeted business outcomes. Today the focus is on IT via ITIL, because IT really needed to get its house in order ever since the PC and LANs in the 1980s, client/server in the 1990s, security in the 2000s, etc. It will be very interesting to witness the extent to which the practice of ITIL within an enterprise will influence the application of the concept of services in non-IT disciplines.

ITIL v3 and Service Management

Back in April I introduced the subject of ITIL and its contribution to an increasingly successful BA/IT relationship.  At that time, most ITIL-based IT organizations were using ITIL v2, with implementations focusing primarily on operational IT efficiency.  The necessity of strong IT/business alignment is emphasized in ITIL v2, but ITIL v2 lacks a compelling framework within which that alignment can be understood and materialized.  This can actually be deduced from the organization of the ITIL v2 books and chapters, with the ITIL processes themselves (Incident Management, Problem Management, Change Management, etc.) as the main topics.

 

 

ITIL v3, introduced in May 2007 (you can find a good starting point for additional ITIL information here), not only subsumes the IITL v2 content but

  1. Reframes it entirely, presenting the material within the business life cycle phases of Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement
  2. Introduces Service Management as a generalization of IT Service Management (with very interesting implications for BAs – to be covered in my next article)

 

Have you looked into ITIL v3?  Do you work with an IT organization that is adopting ITIL v3?  Do you have plans yourself to become ITIL Expert certified, to complement your CBAP certification plans?

20-20 Vision

I have always been intrigued by the organizational structure based on two reporting hierarchies, in which each employee has an “HR” manager and a “business” manager.  While I do not claim to understand all of the implications of such an arrangement, I did work very closely with a client using that structure, and a couple of dynamics were very clear:

  1. The business managers are able to really focus on vision, strategy, and execution
  2. Employees in general had a keen sense of ownership of their own careers and roles in the organization, supported enthusiastically by their HR managers

No doubt you have heard (and even harrumphed yourself in a fit of frustration) the adage “If you want something done right, you have to do it yourself”.  Though this is taken as a comment on quality (“done right”), I think it is more a comment on fulfillment of vision.  This is why the BA and his or her elicitation, analysis and documentation skills are so valuable – they are about extracting, reconciling, and revealing the stakeholders’ vision.

It is the dual-hierarchy management model I observed that prompted me to wonder: Is it not the case, axiomatically, that the business manager (the role, not the person) really is the business analyst?  Well, maybe that’s putting it too strongly.  But what if, by design, business managers were also business analysts?  It is common practice for the business manager, who is accountable for business results, to envision the to-be state and then delegate the business case development to a BA.  Imagine the efficiency to be gained if the business manager was also the BA – and what that means in terms of the potential for fulfillment of vision?

It seems the dual-hierarchy organization implicitly embraces the value and importance of the Business Analyst.  I wonder too whether there are other organizational idioms that give the BA role the space it needs.

Have you had experience with the dual-hierarchy management approach, or for that matter with other organizational design elements that are explicitly favorable to the practice of BA?