ITIL and the end of IT
Originally posted on 2/12/2008
There’s a lot that’s been written on the problem of “aligning IT with the business”, and it’s a problem I’ve been thinking about quite a bit lately (see Who needs IT?). A Google search a few minutes ago returned over 2.5M hits for “information technology business alignment”, so it’s clearly something that is top of mind for folks both in and out of IT.
One of the more concerted attempts to improve the alignment between IT and the wider organization is the Information Technology Infrastructure Library (ITIL). ITIL is a complex subject that, like CMM, inspires passionate sentiments for and against – a quick look at the discussion postings on Wikipedia gives a good idea of the tenor of debates that can go on over ITIL.
Without delving into a detailed summary of ITIL, here’s one way to think about what it is:
1. Make a list of all the activities that a well-run, world-class IT department must do to be effective, efficient, and successful.
2. Ask IT professionals from lots of other organizations across all industries to do the same.
3. Take all the lists, reconcile and merge them, and then organize the resulting activities into process groups.
4. Document the inputs, outputs, controls, and owners of each process group.
What would result is a large-scale framework for an idealized IT organization, i.e., the processes that such an organization would need in theory to be successful, regardless of size, structure, location, or industry.
This is pretty much, at its most basic level, what ITIL is: a set of guidelines or suggestions for each of the processes that should be a part of an IT organization. But because ITIL is only a framework, it is not concerned to prescribe how these processes should be implemented, nor is it meant to be implemented whole cloth – it is up to each organization to determine which parts of ITIL make sense to adopt and then to decide how to do so.
One of the core tenets of ITIL, more fundamental than all the processes that make it up, is the view that an IT department is at its heart a service provider – all of its technology and engineering work is not first and foremost about the software, hardware, data, and so on that are generated, but rather about services provided to customers, whether internal (“the business”) or external (“the customer”).
ITIL helps an IT organization become a service provider by encouraging it, more implicitly than explicitly, to view itself as a stand-alone entity that has the rest of its organization (“the business”) as a customer. Looked at from this perspective, ITIL succeeds because it pushes an IT organization to operate as an IT consulting firm must: if it had to peddle its wares on the street (rather than being a “sure thing” shared service), what would it take to stay in business?
There’s an interesting paradox in the way ITIL works, however: it effects better alignment between IT and the larger organization not by more closely integrating the two, but by pushing them farther apart. ITIL takes the typical IT organization, which is often only half-heartedly or partially integrated with the rest of the company (see Figure 1), and severs it completely, externalizing IT (at least conceptually) so that it will see itself as competing to provide services to a customer rather than as a shared service cost center with a guaranteed existence (see Figure 2).
FIGURE 1
FIGURE 2
Whatever you do or don’t think about how ITIL articulates the processes and activities that should make up a successful IT organization, there’s little doubt (to my mind at least) that encouraging an IT organization to view itself as an external service provider will improve its chances at being successful in meeting the needs of the larger organization it’s a part of. Despite this, I have doubts whether externalizing IT (and ITIL is just one way of achieving externalization) is a desirable long-term solution to the challenges of “aligning IT and the business”.
Instead, I wonder whether what’s really needed – in the long term – isn’t a centripetal dynamic to drive the activities of an IT organization closer to the activities of the larger organization rather than farther away.
Really, at the most basic level, IT activities are business activities (product development, customer service, operations, marketing), so another way to “align IT with the business” could be to do away with a dedicated IT department altogether. In its place, you would just have IT folks working alongside their non-IT counterparts to deliver services to customers. They might be focused on web analytics while their counterparts are concerned with response rate to a collateral mailing, but both are involved in marketing activities; or they might be conceptualizing and building a website instead of developing a product offering, but both are involved in product development. And so on.
In some sense, the most recent version of ITIL (v3) is already moving in this direction by embedding the processes needed by a successful IT organization within the life cycle of a service:
1. Service Strategy – Determine what service to offer
2. Service Design – Determine what the service will look like
3. Service Transition – Release the service into production
4. Service Operation – Support the service in production
5. Service Improvement – Improve the delivery of the service
Leaving aside the ITIL-specific terminology, these are basically the steps any organization should take (IT or otherwise) when deciding to provide a service to customers. And so ITIL v3 can be seen as a way to encourage IT to function the way the rest of the organization already does, although it still, for the most part, exerts an externalizing influence on IT. I’ve just been coming more and more to think that the true solution to the problem of “aligning IT with the business” is to end IT, which presents another, potentially more difficult problem in its place: what exactly would (could, should) an organization with a fully-integrated IT function look like?
Who needs IT?
Originally posted on 2/7/2008
A few months ago I was having a discussion with a colleague about the difficulties of running an effective IT organization. During the conversation, it struck both of us just how peculiar a statement like, “IT needs to be aligned with the business”, is. Replace “IT” with “marketing”, “sales”, “operations”, or “customer service”, and you begin to wonder if maybe the first step in “aligning IT with the business” is in not framing the problem in these terms.
Although we had difficulty at the time coming to any firm conclusions about what new terms we could use to frame the problem, since then I’ve given a lot of thought to this issue. The following are some propositions that I’ve adopted to help guide my thoughts on this subject.
#1: IT is fundamentally a part of the business, just as much as and just as naturally as marketing, sales, customer service, finance, HR, and so on, are.
#2: IT is fundamentally a collection of business activities that occur elsewhere in an organization, for example, product development, operations, customer service, and production/manufacturing.
One possibility that occurred to me on the basis of these first two propositions is that IT as a standalone department may not strictly speaking be necessary, i.e., the business actors and activities we currently segregate in an IT department could very well be relocated out to the functional areas in the larger organization they map to (web developers to product development, network and infrastructure to operations, and so on).
Which brings me to my third proposition…
#3: IT as a distinct entity within an organization is not a self-evident organizational principle, but only one possibility among many for structuring these business activities.
On the basis of this, I’ve been wondering whether one reason that organizations so frequently have trouble “aligning IT and the business” is that the folks in the IT department and the work that they do have been fenced off from the rest of the organization, which encourages the organization-within-an-organization that IT departments so often are.
Imagining a modern corporation without an IT department is difficult…I have trouble picturing what it would look like and how it would function exactly. But often the best candidates for creative re-imagining are what seem to be the most self-evident truths…
Stakeholder Participation (Part 2)
Originally posted on 1/27/10
In Part 1, we looked at what happens when balanced stakeholder participation isn’t present on a project. In this post, we’ll examine what balanced stakeholder participation looks like and how securing it can improve the chances for project success at an organization.
Balance in this context means securing participation and input from three broad categories of stakeholders:
- IT Functions – These encompass the traditional technology disciplines, such as system analysis, architecture, application development, network operations, help desk/service desk, end user computing, and quality assurance, and may also include business analysis and project management (depending on how these functions are structured at an organization).
- Corporate Governance Functions – These encompass disciplines involved in monitoring and controlling the activity of an organization, such as legal, records management, information management, ethics and compliance, audit, internal investigations, master data management, human resources, and aspects of finance
- Business Functions – These are all functions (front- and back-office) not included in IT and corporate governance functions.
Because each of these groups has distinctive (and often competing) interests, motivations, and goals, the project team is forced to find a middle-ground acceptable to all…and to consider the issues from a viewpoint that transcends the more narrow view of any one group and considers corporate-level concerns.
In the shared drive example from Part 1, balanced stakeholder participation would have changed the outcome considerably.
Although there are many ways this participation could be activated (depending on a host of organizational factors), at a minimum, the request for a new shared drive would be triaged to determine whether its likely impact to the organization warrants a review by a cross-functional team of SMEs drawn from IT and corporate governance functions. Such a review would typically be a 60 minute meeting to discuss the proposed initiative with representatives from the business unit in question.
At the very least, having this kind of discussion about the goals of the initiative with a group drawn from IT, the business unit, and a cross-section of governance functions (legal, records management, audit, compliance) would likely have brought some of the key issues to light from the start:
- What will get moved to the new drive and what will not?
- What will the division of labor between the new and old drives be?
- What is the risk profile of the documents the business unit proposes to move (from the perspectives of litigation, records management, compliance, and audit)?
Whether or not this cross-functional group has the authority to tell the business unit how to settle these issues, they are now at least surfaced—so if the business unit decides (against the counsel of the group) to make a mess of the new drive, legal, records management, IT, etc. can note it as a risk. When a future event involves this shared drive (like a litigation), the folks involved will still have a mess on their hands, but it will be a known mess.
Unless something goes horribly wrong in the cross-functional meeting, however, in most cases the business unit will be glad to have input from these other players. “We’d like to do the right thing, but no one can tell us what that is” or “we get mixed messages on what the right thing to do is”—two complaints I hear frequently in my practice from business units regarding corporate policies and procedures (e.g., legal, records management, compliance, audit).
Balanced stakeholder participation of the kind described here works because of the competing (yet ultimately complementary) interests of the three groups involved. The solution that emerges from a project with balanced stakeholder participation does not meet the needs of any one party 100%—but if done properly, it will meet the needs of each group 75% and be a fitting solution for the organization as a whole because it has been crafted in light of the needs of these three core groups.
Stakeholder Participation (Part 1)
Originally posted on 1/26/10
For nearly every client I’ve worked with, securing balanced stakeholder participation is the most often overlooked aspect of projects. Normally, the stakeholders involved are chosen as much by chance as any other factor: they’re the folks who absolutely must be involved, combined with a smattering of others who happen to be organizationally or functionally related to the sponsor (or who have a personal relationship with them).
What results is equally up to chance: if the organization has processes in place to ensure that the right resources are involved or the sponsor has successfully engaged them (or both) the project has a higher likelihood of success. If, however, such processes are not in place or the sponsor has not engaged the right resources, the project is very likely to fail, if not in terms of completing on time and on budget, then certainly in terms of meeting the needs of the larger organization.
Let’s look at a simple example that occurs regularly at organizations: requisitioning a shared drive.
The implementation team at a health care provider has a shared drive that’s getting out of control, both in terms of size and how content is organized. Folks in the department have so much trouble finding documents that they resort to “phoning a friend” to find out where the document they’re looking for is, new hires need constant hand holding to navigate the drive to learn their jobs, IT is unable to meet their backup and disaster recovery SLAs because of the sheer size of the drive…and anyone outside the department (such as legal, compliance, audit, or internal investigations) has to work one-on-one with implementation resources to begin to find anything at all.
Implementation decides that the answer is a new shared drive where they can “start fresh” with a better organizational structure. Because it’s impractical and undesirable to bring over all the old content, they plan to bring over only final-form documents required for the implementation process–the rest of their documents will remain on the old drive for now. They fill out the required forms, a line-level IT operations resource sets up the new drive for them, and they are up and running.
Let’s assume that the implementation team (1) defines a workable content organization for the new drive and (2) follows through nearly 100% on their plan bring over all the old, final-form documents to the new drive and to store only final-form documents there. The initiative will have failed to meet the needs of the larger organization in one significant way: E-discovery. The Federal Rules of Civil Procedure allow for opposing counsel to request more than just final-form documents, so the drafts, working docs, etc., that remain on the old drive are discoverable if the final-form docs are–the new drive has thereby increased the cost and risk of e-discovery at the organization.
Now, this is assuming that the implementation team followed through almost perfectly on their plans…something that we know rarely happens. More often than not in this situation documents would be missed and left on the old drive, not all documents moved from the old drive would be deleted from it, and multiple “final” versions of documents would be kept on the new drive as last-minute changes got made during implementations. In this case, there are additional negative side-effects for the organization:
- Records Management. Final-form documents are not the only ones subject to corporate records retention schedules, so the division across drives combined with inconsistent application of the plan for the new drive makes it more difficult for records management to ensure that documents on the drives subject to the retention schedule are retained and (especially) disposed according to it.
- IT. The unintended duplication of documents across drives will eventually reverse any storage reductions gained and make backup and disaster recovery more difficult than with the old drive alone.
This is a relatively benign example. In the case of more serious ones–such as acquiring a SaaS application (e.g., sales/CRM or e-discovery tools)–the potential for risk and cost to the organization can be enormous.
In part two, we’ll examine what balanced stakeholder participation looks like and how securing it can improve the chances for project success at an organization.
agile ramblings 