erp4it

Business intelligence for IT White Paper

Quick cross-post - I am very pleased with how this report for HP on their IT data warehouse turned out:

http://h10124.www1.hp.com/campaigns/downloads/EMA_HP-ITPS-1011_WP.pdf

-Charlie

Kindle confusion and other Amazon woes

I've been telling everybody and their sister that the Kindle version of my 2nd edition was only $9.99.

Boy, was I wrong. That's the price only for the 1st edition. (Why, oh why, do I so often believe things  too good to be true?) The price for the 2nd edition Kindle was not released until today, and it is a much steeper $42.67.

Not only that, it's really confusing to get the Kindle 2nd edition. If you first go to Amazon you get this (click for larger):

 

Disregard the $9.99. That's the first edition. You don't want that (unless you're a scholar interested in what I changed between editions). Trust me, the 2nd edition is better.

Notice the tiny little "+" icon I've circled on the screenshot above. Click that:

(click for larger)

There's the real 2nd edition Kindle, with the price circled. Sorry for the price misinformation. Really not sure why they are burying it that way.

On another topic, if you do the "Click to LOOK INSIDE" you'll get this surprising result:

(click for larger)

Bet you didn't know I was also an expert in the oil and gas industry! And only that cover is wrong, if you scroll down you'll see my book.

We're trying to get this straightened out, needless to say. But the interactions between my publisher and Amazon are a bit opaque to me. 

Anyways, what matters is you can get the book. Please let me know how you like it.

Charlie

 

Second edition of Architecture and Patterns for IT

This week marked an event I’ve been anticipating for a long time: the general availability of the revised edition of my book, Architecture and Patterns for IT: Service Management, Portfolio Management, and Governance (Making Shoes for the Cobbler’s Children).

(Amazon is now live, including the Kindle version of BOTH editions) - but see my clarifying post.

Leave the "IT" in "ITSM"

Ada Lovelace, Image via Wikipedia

A recurring idea in IT management discussions is that we need to lose the “IT” ("Information Technology") in "IT Service Management." Or maybe just the “T” or just the “I” -- I’ve heard all variations. The argument goes something like this:

“The IT label is killing us! They think we’re a bunch of geeks that don’t understand The Business! They are outsourcing us! They don’t understand us! We’re just a cost center! We have to kill the IT label and then they will think we are a Strategic Partner!"

That, in a nutshell, is the argument I’ve been hearing for years. I have some concerns. I think it is a negation of our fundamental identity as computing professionals.

A career update, and the future of erp4it.com

As many of you may know, I have accepted a position with Enterprise Management Associates as Research Director for IT Portfolio Management.

I have a blog site there where I will be posting frequently, especially with regard to industry and vendor trends. That site is where I will talk specifically about companies and their software offerings.

I will keep this blog. It will remain more theoretical and postings here are likely to be less frequent and more essay-like. So, no real change, but if you want to hear from me more often, subscribe to my new blog's RSS feed.

-Charlie

 

Chapter abstracts

Here are the draft abstracts for the major Second Edition chapters:

Chapter 1. IT in a world of continuous improvement

Abstract: Discussions of IT management struggle when they are not grounded in fundamental principles. This chapter sets forth working definitions of “Information Technology,” “IT Service,” “Lean,” and “Lean IT.” Basics of Lean and related continuous improvement are presented, with cautions as to their applicability in an IT services context. Proposed is the concept of two axes of IT value (product versus transactional). Establishing a correct analogy between IT and manufacturing operation is discussed, and the equation of IT transactional delivery with an assembly line is proposed and contrasted with the failed concept of software assembly line. Quality management in IT is summarized from a Lean perspective, and IT waste is discussed. Current trends in IT management are examined from a Lean light and a “TPS house” for IT is proposed. The Lean concepts of flow, small batches, kanban, and other terminology is presented.

Chapter 2. Architecture approach

Abstract: A generic enterprise architecture analysis approach is presented at an IT generalist level, based on the concepts of catalogs, matrices, and diagrams. The catalogs are enumerated, mutually exclusive and comprehensive lists of value streams, processes, functions, data entities, and IT management systems. Practical basics of IT transactional value are presented within an overall context informed by value chain and process management theory. Using entity lifecycle analysis, the IT value chain is decomposed into four major value streams: application service, infrastructure service, asset, and technology product. Also based on the entity analysis, nine cross cutting processes are proposed: demand, project, release, change, request, transaction, restore, improve, retire. Grounded in principles of functional and data architecture, forty IT functions and twenty-nine IT conceptual entities are defined. MRP and ERP origins, value, and challenges are discussed with reference to industrial literature, the idea of “ERP for IT” is introduced, and nineteen major classes of IT management systems are defined. Finally, each major catalog is matrixed to each other to show interactions.

Chapter 3. Patterns for the IT processes

Abstract: The concept of design patterns is introduced: named nuggets of insight addressing particular recurring problems in large scale IT management. The patterns in this book focus greatly on questions of integration and enabling processes and lifecycles to flow across the functions, via shared data. In this chapter, patterns for each of the nine major IT processes are discussed. Examples include Understand Aggregate Demand, Clarify Service Entry Points, Integrate Project Management, Integrated Release Management, Justify Change, Integrate Drift Management, Clarify Service Semantics, Integrated Continuous Improvement, Integrated Service Retirement and more. Extensive discussion of patterns surrounding Configuration Management is presented, including Distinguish between Element and Enterprise Configuration Management, Capture CMS Data at Appropriate Level, Mature the Configuration Management System Iteratively, and more.

Chapter 4. Patterns for the IT Lifecycles

Abstract: Continuing with the discussion of design patterns, this chapter focuses on the longest lived IT concepts, the multi-year lifecycles of application service, infrastructure service, asset, and technology product. The challenges of identifying these concepts are covered in detail, and overall lifecycles are examined in depth, with attention to data, function, and enabling systems. Patterns include Identify applications in the portfolio, Application semantics in detail, Integrate Application Portfolio and Configuration Management, Integrate Metadata Management; Applications, Infrastructure, and the ‘Hosting Zone of Contention;’ Solve the Vendor/Product Master Data Problem, Technology Product Lifecycle as Demand, Distinguish IT Asset Management from Configuration Management, Establish Traceability via Overlapping Identifiers, Portfolio Management Overview, and more.

 

 

Wordle just for fun

Wordle of my book manuscript (all 139,000 words)

Click to enlarge

 

 

Generalizing the "Improve Service" process: emergent idea?

Alert readers may have have noticed in my overall process architecture the idea of a generic process "Improve Service," and corresponding concepts of Improvement Opportunity in the data architecture and Continuous Improvement System in the systems architecture.

This is the outcome of a long standing conundrum in considering ITIL as a process architecture: I can count Changes and Incidents, but I cannot count Capacities or Availabilities. And if I have initiatives to improve capacity or availability, those initiatives compete for the same resources answering service requests and resolving incidents, and prioritization across these activities is typically ad-hoc and local. Service improvements (under which I also include process improvements) can take many forms, and be driven from many uncoordinated directions in the enterprise.

These are important themes in the new edition, which goes into the problem of cross-queue prioritization in the large IT shop from a few different angles.

A new preface

I'm struggling with a new preface and introduction for my 2nd edition. So here goes with new writing. Comments greatly appreciated. If you read the passage below, would you buy the book?

==============================================================

Around 2003, when I was leading an application team at Best Buy, I met a senior business executive. The conversation went something like this:

Exec: "So, what do you do?"

Me: "I'm building a metadata repository."

Exec: "Boy, that sounds like a business we shouldn't be in."

Demoralizing! Yet this interaction, and others like it, sowed the seeds of this book.

The “business of IT”...?

Some excerpts from my 2nd edition, relevant to current debates

=======================================================

[excerpt 1]

IT service development activities parallel those of commercial R&D organizations. IT service delivery and operations activities parallel those of corporate manufacturing and customer service departments. IT governance activities parallel corporate governance activities. IT is dynamic, but so are other disciplines, such as finance and logistics. IT is complex and uncertain, but no more complex or uncertain than engineering and demand forecasting. Get over IT! In concept, the fundamental management principles of all the disciplines are identical. We just need to do a little translation.[i]

                                                                                                                Jeff Kaplan

A well known thought experiment (dating back to at least 1971) in discussions of IT management is “run IT like a business.”[ii] Pragmatically, IT as a management domain can be viewed as a complex system of sustained economic activity, thus “a business” in significant respects. As implied by the excellent Jeff Kaplan quote at the start of the section, large IT organizations are subject to emergent dynamics that can be understood using tools from finance, operations research and industrial theory.

The idea is that if an IT organization (even one run as an internal “shared service” cost center) is managed “as if” it were a profit making entity, more disciplined and optimal allocation of IT resources will result.

Weaker forms of this concept also exist. Less emphasis may be placed on cost accounting and recovery, with more focus on operational issues. 

For example, IT portfolio management draws inspiration from portfolio theory in financial management. Demand management, a critical concern in manufacturing supply chains, is emerging as a prominent concept in IT project portfolio discussions. Infrastructure service provisioning bears similarity to Make to Order production processes.  And so forth.

However, the concept can be problematic. “IT like a business” may raise unintended red flags if perceptions are not carefully managed.

Captive cost centers may be in fact prohibited from attempting to become profit centers; such assumptions are typically fundamental to the enterprise business model. This does not preclude “running as a business” if the intent is to increase efficiency and effectiveness.

Other criticisms may arise in viewing internal IT service sponsors as “customers.” The customer is the person walking into the store with money in their pocket, the viewpoint goes, and any other use of the term is problematic.

Despite these concerns, this book relies on this thought experiment. As Terence Quinlan of the IT Financial Management association notes, “Managing lS financially as a business does not require a profit center structure. lS can remain a cost center.”[iii] Womack and Jones note that enterprise value streams often contain miniature versions of themselves, that is, they are fractal, an insight that also supports the “IT as a business” model.[iv]

It is difficult to reason about large scale IT, including the application of Lean concepts, outside of an “IT as a business” framework. Concepts in this book such as IT Value Chain and IT Value Stream rely on this foundation. “Customer-provider” relationships are found throughout the discussion, regardless of money changing hands. If this bothers you, substitute the term “sponsor,” “requestor,” or “user” as appropriate.

[excerpt 2]....claiming any “value” as “IT value” may be problematic. A claim to value is a political statement and often the managers of profit centers (or line managers more generally, e.g. program managers in a not for profit) compete for who receives credit for any increases in organization results (financial or non-financial).

IT, as a back office cost center, is in general not competitive in this fray, any more than peers in HR or Operations. Any claims to “value” from the IT organization may not be well received. And yet, there seems little choice in the matter, as IT is called on to account for its never-ending high costs. Such is the IT manager’s dilemma.

---

[i] (Kaplan 2005), p. 12

[ii] The concept of considering IT as a business within a business was conceived as early as (Ditri, Shaw et al. 1971) and (IBM Corporation 1981).  See also (Van Schaik 1985; Cunningham 1992; Curley 2004; Lientz and Larssen 2004; Lutchen 2004; Hunter and Westerman 2009; Ryan and Raducha-Grace 2010)

[iii] (Quinlan and Quinlan 2003), p.6

[iv] (Womack and Jones 2003), p. 322.

Curley, M. (2004). Managing Information Technology for Business Value, IT Best Practices Series. Hillsboro, OR, Intel Press.

Ditri, A. E., J. C. Shaw, et al. (1971). Managing the EDP function, The Touche Ross Management Series. N.Y., McGraw-Hill.

Hunter, R. and G. Westerman (2009). The real business of IT : how CIOs create and communicate business value. Boston, Mass., Harvard Business School Press ; London : McGraw-Hill [distributor].

Lientz, B. P. and L. Larssen (2004). Manage IT as a business : how to achieve alignment and add value to the company. Amsterdam ; Boston, Elsevier Butterworth Heinemann.

Kaplan, J. D. (2005). Strategic IT portfolio management : governing enterprise transformation. United States, Pittiglio Rabin Todd & McGrath Inc.

IBM Corporation (1981). A Management System for the Information Business, Volume I, Management Overview, 2nd ed. A Management System for the Information Business. White Plains, NY.

Lutchen, M. (2004). Managing IT as a business : a survival guide for CEOs. Hoboken, N.J., J. Wiley.

Quinlan, T. A. and S. J. Quinlan (2003). Readings in IT Financial Management. Santa Barbara, CA, IT Financial Management Association.

Ryan, R. and T. Raducha-Grace (2010). The business of IT : how to improve service and lower costs. Upper Saddle River, NJ, IBM Press.

Van Schaik, E. A. (1985). A management system for the information business : organizational analysis. Englewood Cliffs ; London, Prentice-Hall.

Womack, J. P. and D. T. Jones (2003). Lean thinking : banish waste and create wealth in your corporation. New York, Free Press.

 

 See also (Van Schaik 1985; Cunningham 1992; Curley 2004; Lientz and Larssen 2004; Lutchen 2004; Hunter and Westerman 2009; Ryan and Raducha-Grace 2010)

IT as a business: a 40 year old thought experiment

Reacting to some debate over at IT Skeptic:

"Run IT as a business". What a mantra. It is of course rubbish.

Well....

Just going through some references on the "IT as a business" topic. It is a thought experiment with a long pedigree and has less to do with the Wallys of the world fantasizing, Walter Mitty-like about their little kingdoms, and more to do with attacking IT exceptionalism and obfuscation.

While Cary King notes that Dean Myer (www.fullcost.org) has been using it for about a decade, the history goes way back... the earliest cite I can find is from 1971:

DATA PROCESSING AS A BUSINESS ENTERPRISE
In management terms, the EDP function can be looked at as a cross section of the business as a whole. Definite parallels can be drawn between the medium-to-large-sized EDP organization and an overall company. This book will cite several examples comparing the EDP function as a business-in-miniature with comparable functions in a typical manufacturing company. However, it should be stressed that similar comparisons exist and can be made between the EDP function and virtually any type of business organization. To illustrate:

■ The computer as a unit of production equipment parallels large machine tools or other units of factory equipment.
■ Systems analysis and engineering are comparable skills.
■ Programming and drafting are functions of similar position within and importance to the overall processes of which they are a part.
■ Technical services for EDP and manufacturing engineering are parallel functions.
■ Scheduling, line supervision, personnel, payroll, budgeting, and accounting functions all have direct counterparts between the EDP function and a manufacturing business as a whole.

In management terms, then, the EDP function is a business-in-miniature.

Ditri, A. E., J. C. Shaw, et al. (1971). Managing the EDP function, The Touche Ross Management Series. N.Y., McGraw-Hill.

Similarly from 1981:

We believe that the solution to this "image" problem lies in the disciplined application to data processing of the same general management principles that have been used successfully for many years in the management of other similar business operations in, for instance, the manufacturing and processing industries. In other words, a management system needs to be established that provides a sound basis for control of the data processing operation, provides a proper mechanism for effective communication between all parties concerned with data processing, and encourages a businesslike attitude in the individuals involved.

To emphasize this business approach, we will expand the traditional view of data processing into an Information Systems (i/s) business within the overall enterprises business environment. This business within a business concept will allow us to identify the role of corporate and user management in guiding and monitoring this l/s business.

IBM Corporation (1981). A Management System for the Information Business, Volume I, Management Overview, 2nd ed. A Management System for the Information Business. White Plains, NY. (Famous "Yellow Book" series)

And my favorite quote:

IT service development activities parallel those of commercial R&D organizations. IT service delivery and operations activities parallel those of corporate manufacturing and customer service departments. IT governance activities parallel corporate governance activities. IT is dynamic, but so are other disciplines, such as finance and logistics. IT is complex and uncertain, but no more complex or uncertain than engineering and demand forecasting. Get over IT! In concept, the fundamental management principles of all the disciplines are identical. We just need to do a little translation.

Kaplan, J. D. (2005). Strategic IT portfolio management : governing enterprise transformation. United States, Pittiglio Rabin Todd & McGrath Inc.

Other citations along these lines, either with a title clearly indicating the "IT as a business" meme or significant internal content discussing it:

Van Schaik, E. A. (1985). A management system for the information business : organizational analysis. Englewood Cliffs ; London, Prentice-Hall.

Curley, M. (2004). Managing Information Technology for Business Value, IT Best Practices Series. Hillsboro, OR, Intel Press.

Lientz, B. P. and L. Larssen (2004). Manage IT as a business : how to achieve alignment and add value to the company. Amsterdam ; Boston, Elsevier Butterworth Heinemann.

Lutchen, M. (2004). Managing IT as a business : a survival guide for CEOs. Hoboken, N.J., J. Wiley.

Hunter, R. and G. Westerman (2009). The real business of IT : how CIOs create and communicate business value. Boston, Mass., Harvard Business School Press ; London : McGraw-Hill [distributor].

Ryan, R. and T. Raducha-Grace (2010). The business of IT : how to improve service and lower costs. Upper Saddle River, NJ, IBM Press.

Finally, if one chooses to disregard the IT authors, then there are still Womack & Jones to consider, in Lean Thinking:

Finally, we've discovered that these value stream and product line managers, like so much in the lean world, are 'fractal'.

That is, a product line manager overseeing an entire product may work with a number of value stream managers at lower levels taking responsibility for different courses of the value stream. For example, a chief engineer (to use Toyota's term for a product line manager overseeing an entire automotive platform) works with a development leader in design, a value stream manager in the assembly plant, and value stream managers in each of the component plants working on major items assembled into the finished product. Each manager is essentially doing the same job but with varying scope—wide at the top and narrow at the bottom.

Womack, J. P. and D. T. Jones (2003). Lean thinking : banish waste and create wealth in your corporation. New York, Free Press.

I think such approaches represent a valuable and necessary thought experiment, fundamental to my own writings as well. I also think it scales to IT problems in the small as well as large. Certainly, it doesn't imply turning IT into a profit center.

So, I guess my question is whether someone wants to attempt a more systematic statement, e.g. "'IT as a business' considered harmful." I think that debunking the concept will take a little more than invoking Wally. Are all these authors misguided?

 Updated: some relevant excerpts from my book on the next post.

 

Integrated Service Request Management

There are many possible integrations for a Service Request Management system. Figure 66 is presented as a reference model with a number of possibilities to consider.

• The core of a service request system can be decomposed into the catalog – the means for publishing the services – and the fulfillment mechanisms.
• There may be multiple fulfillment mechanisms, depending on the requirements of what is being done. General purpose BPM engines are common in service request management tools, but may also be found in problem domains such as Access Management.
• Depending on how Demand Management is structured, some service requests may originate there.
• As previously discussed, the Change Management system may generate Service Requests as work orders. (This may in turn be driven by Release Management.)
• A common form of Service Request is for software installation and in mature environments this is aligned with Software Asset Management so that entitlements are correctly managed.
• Access Management may be a common Service Request and (as above) is actually a key link between the Application Portfolio and the Service Catalog.
• Element Management systems may interact in various ways with service requests and their fulfillment systems. For example, in the new forms of dynamic provisioning architectures, a virtualized development environment might be offered and requested, with a BPM engine actually interacting with the virtual server manager to create the new resource.
• The Configuration Management system may be updated as a result of Element Management activity, and may also provide various inventories of CIs to the Service Request management system against which people can file requests.
• Incident Management of course must be tightly integrated with Service Request Management, due to the basic ambiguity of “is it an Incident or a Service Request” – a question which the requestor may not understand when initiating Service Desk contact.
• Projects may rely heavily on Service Requests. Project identifiers may be used as funding channels and valid IDs in such cases are required to flow from the Project Management system to the Service Request system.
• Finally, the IT Data Warehouse should receive summary and perhaps detail information on service request traffic and performance, for integration with other IT management data.

 

(click for larger)

 

A simple failure demand metric for the Service Desk

British management consultant John Seddon emphasizes the centrality of understanding “Failure Demand” for services organizations. Failure Demand is when Service Requests or Incidents (or perhaps other processes) are repeated due to the fact that they weren’t done right the first time.

For example, a user calls in a request for Microsoft Excel to be installed, which is done. The user then has to call back however because the Excel PowerPack extensions were not installed, which the user requires to do their job.

Or the user calls in an incident but then is ill for a couple of days, and unable to respond to Service Desk queries. Because the Service Desk is incented on closing tickets quickly, the user’s incident is closed out and they must re-open the ticket when they come back into work.

A simple design pattern for addressing this: instead of reporting only on the Service Request and/or Incident ticket closure durations, also report the average and peak #s of tickets called in by each user. Slightly more formally, frame a query thus:

For each user calling in at least one Incident or Service request, how many called in more than one within a four week period?

Recurring incidents or service requests for particular users is a clear and relatively tamper-proof means of identifying failure demand. Certainly, complaint-prone users, or new employees with multiple needs, also show up in these metrics, but they would still be useful.

Thoughts? Anyone doing this?

=========================

further thoughts: This of course seems similiar to the well understood concept of First Call Resolution. But scanning some references, I'm concerned exactly *how* FCR is asserted... is it too prone to self serving interpretation by Help Desk analysts? Similarly, % of tickets re-opened is sometimes tracked, but that assumes that the help desk allows/encourages re-opening of tickets - some don't, in my experience. One study of typical help desk metrics.

=========================

8/4/2011 Even more - after I wrote this, I then encountered this HBR article, counterintuitively titled "Stop Trying to Delight Your Customers." Don't let the title turn you off, it's all about the issues here.

Release management integration pattern - seeking devops comments

 (click for larger)

The above shows a comprehensive reference integration for release management, suitable for large environments and based on a combination of ITIL, Dev/Ops, data center automation, and event management . The above component diagram supports the following sequence and variations:

1. The software checked into source control is built, and tests (automated and/or manual) applied.
2. Passing the tests, the software is checked into the definitive software library.
3. The Release Management system registers a Change with the Change Management System.
4. The deployment system pulls it and associated configurations from the definitive software library and passes it to the data center automation tool (a special class of Business Process Management system optimized for interacting with element management systems).
5. The Data Center Automation tool raises events as appropriate as it feeds code and configuration files to element managers for application to production.
6. The Element Management systems notify the Configuration Management System of updated CIs and dependencies, as appropriate.
7. (Failure scenario) The element managers (in particular their monitoring components) raise events indicating errors or performance issues to the event management system. If unexpected behavior is violating defined thresholds (SLAs or internal limits, including dynamically managed thresholds), the event management system automatically contacts the automation system for rollback of the change. The event manager and change management system are notified of the rollback.

Would really appreciate feedback from you devops folks.

Defining Demand Management

The posts yesterday were the "patterns." I suppose the definitional material would help...

Accept Demand

The most successful firms we've found have learned how to “deselect” projects, despite the enthusiasm of parts of the organization, in order to bring the number of projects into line with the available resources.

Womack and Jones, Lean Thinking

Far from being the rational and structured process we would like it to be, demand management is usually a nebulous combination of decibel management and organizational politics

Michael Gentle, CIO Magazine

The request (or demand) for IT services is managed through an intake function known appropriately as demand management. Leveling demand and balancing it with the supply of productive capacity is an essential management principle, yet too often the IT services organization struggles badly with this.

Demand management patterns

The weekend's work... and a rough 15 pages it was.

Posted my Accept Demand Patterns section, broken down thus:

• Understand aggregate demand
• The promise of Critical Chain for IT demand management
• Clarify Accept Demand relationship to other processes
• Clarify service entry points
• Integrate Demand Management System
• Accept Demand - IT Lifecycle implications

This was a hard section. IT demand management is not a well understood process area, and there are still major differences of interpretation between the project management derived views and ITSM.

Comments on these drafts are GREATLY appreciated.

Charlie

Accept Demand - IT Lifecycle implications

The IT process of Accept Demand is core to the Application Service Lifecycle. The demand for new functionality may arise with particular urgency from business partners recognizing a new revenue opportunity, or responding to environmental forces. The ability to quickly capture, assess, and prioritize dynamic demand is essential as the speed of business accelerates, as is the ability to understand what is truly essential for business value in a new service and how to deliver this in smaller, more iterative chunks.

Demand management should track the ordered and delivered IT service through what can be called the “inspire to retire” lifecycle of IT solutions/services. Silos are often seen between

• Governance, architecture, planning and authorization,
• systems development and integration, and
• systems operation functions.

Novel applications may impose net new demand on the infrastructure service lifecycle, but that is only part of the equation. Existing services may see gradual increase or sudden spikes in demand, which do not affect the application lifecycle per se (no software need be rewritten), but do impose new demands for infrastructure. Demand management is essentially equivalent to the concept of Capacity management when considered for the infrastructure lifecycle.

The IT operations area in too many organizations does not have visibility into “what’s coming,” and the result is sub-optimized from an operations point of view.

Dialog: Advance notice

Pat: Why would you need this?

Kelly: Have you ever heard of “over the wall”?

Pat: Yes, our data center and applications support people are always mumbling this.

Pat: Right – because they don’t have enough warning that a new system is coming, and aren’t able to influence its development sufficiently to meet their needs: application architectures that are compatible with data center operations, re-use of existing platforms and skills, instrumentation for availability, support documentation and procedures, and all the rest.

Most of this gets sorted out sooner or later, but it seems like we’re always painfully re-inventing the wheel here, and when you dig into the root cause the fundamental issue always seems to be one of visibility.

Sometimes, demands for increasing infrastructure service capacity can be met in house. Other times, they require the acquisition of new physical assets. A key concern is how backup capacity, also known as “white space,” is managed and in particular funded – a common topic in discussions of IT Financial Management. Such capacity can be construed as a buffer and therefore waste from a Lean perspective, but IT service demand spikes can be instantaneous and insufficient capacity installed and ready “on the wire” can lead directly to service degradation and even loss of revenue.

The Asset Lifecycle may also drive demand, if a large contingent of assets is approaching a refresh date, that effort itself may be handled as a project. The impacts on Applications need to be considered but the effort is not driven by functional Application needs.

Technology products – reproducible combinations of hardware and/or software, not yet acquired or pressed into service – are also subject to demand. Demand for increased processing power translates into demand for new kinds of infrastructure capabilities. Demand for ongoing platform services translates into demand for current, well supported versions of key infrastructure technologies (OS, data management, middleware).

New forms of security hazards translate into demand for new technical solutions. And new application services may require new technical products developed and marketed by specialist firms. All of this demand translates into value engineering kinds of activities, as the technical requirements are translated into functions and candidate solutions assessed for best fit at lowest cost.

The Technology Product Lifecycle may also drive demand; product obsolescence (e.g. due to a new version) is a frequent demand driver, as noted elsewhere.

The promise of Critical Chain for IT demand management

Eli Goldratt has written many novels beyond The Goal. One of the most important for IT professionals is his book Critical Chain.

Critical Chain is ostensibly about project management, but in reality it’s about all of demand management in a services context. The book identifies and examines key causes of project failure:

Bad multitasking. This is the frequently remarked upon churn experienced when tasks cannot be completed but instead must be juggled, with attendant “context-switching” costs.

Student syndrome. This is the tendency for work to get done at the last minute. A corollary is Parkinson’s law that “work expands so as to fill the time available for completion.” In a project context, it means that (for example) a task truly requiring three days may be estimated at fifteen days, with the task not starting in reality until day 12.

When considered as a systemic, cultural practice, student syndrome is hugely wasteful and an obstacle to execution success in many areas. Because of it, delays propagate while early deliveries do not.

Conservative local estimation, and local buffer control. Task durations are typically variable. For example, provisioning a new Unix server may typically take an average of 1.5 days effort, but 20% of the time may take four days effort. However, because of overly strong incentives in many cultures for “on time delivery!,” the server engineer will always estimate a full week to provision the server.

Then, because of student syndrome, they wait until day 3 to start, because the majority of the time they can get it done.  In the meantime, the “buffer” or valuable lead time is lost to the project. Even if the server is turned over early, typically rigid project plans will still not take advantage of this. Again, negative variation propagates but positive variation does not (a key insight of The Goal as well).

Critical Chain addresses these problems through accepting variability in task execution, and capitalizing on early deliveries by centralizing buffers under project management. The concept of project critical path is extended to include the resources working on the key tasks, and the Critical Chain is the critical path combined with resource availability. The critical chain resource is expected to work on nothing but the task at hand and deliver it as soon as possible, with no local buffer management. It’s not “due by the end of the week;” the server is due NOW. And there must be a strong defense against any other demands being placed on that resource (prevent bad multitasking) until that critical chain task is completed, as fast as reasonably possible.

Ongoing re-planning of the project is therefore also needed, since taking advantage of early delivery may mean that timelines across the project need to shift. This is a complex challenge and true Critical Chain project software needs to solve a thorny non-linear problem known as the Resource-Constrained Scheduling Problem.

Critical Chain is especially applicable to environments with large numbers of small, semi-repeatable projects competing for skilled resources – very typical of a large, service request-driven IT environment, especially across the “hosting zone of contention.”

In an environment where these same resources may get called into service requests, incidents, changes, and continuous improvement efforts, the concept is promising indeed and few if any IT organizations to this author’s knowledge have extended their demand and service catalog practices to handle this challenging general case. Instead, resources find themselves at the receiving end of multiple queues with little or no guidance for prioritization.

Integrate Demand Management System

The previous patterns lead to a more technical, system level pattern. They call for implementing some or all of the possible interactions below:

 

(click for larger)

There are many variations on how these integrations might be implemented. In this version, the demand system feeds the service request, project management, and continuous improvement systems, all of which in turn feed the consumption of employee time or indication of effort to the time tracking system.

This resource consumption is then replicated to the IT data warehouse and combined with other activity indicators that typically do not originate out of a demand management system: Change and Incident Management for activities that may not go through any demand qualification, and IT Finance and Capacity for resource views.

Having the Demand system drive Service Requests might surprise some Service Desk managers. This pattern does not preclude end users interacting directly with the service request system for prequalified services. But (as discussed in previous sections) if Agile methods imply a move away from formal Project management, it is reasonable that enhancement requests might be tracked as a pipeline of specialized Service Requests (methods such as Scrumban imply this, while not using the term Service Request Management per se). In such cases, these perhaps-discretionary requests do go through some form of demand qualification prior to acceptance.

Patterns like this illustrate how gray the boundaries between these systems can be. But whether it is called an Agile workflow system or a Service Request Management system, there is a common core of workflow and in the interests of parsimony this book sees them more the same than different.

Clarify service entry points

When viewing IT as a single value chain, the incoming stimuli that initiate the end to end process are of primary concern. They need to be captured as early and systematically as possible, to eliminate missed handoffs, redundancy, and rework.

A challenging aspect of demand management is therefore the service entry point, an interface or avenue of contact between IT and its customers and/or users. There are three major types by which customers (internal and external) experience value with these processes:

• Professional service
• End user service
• Application service interface

The processes map to the entry points as follows:

  
Table 4. IT processes and Service Entry Points

All of the services may be represented in a modern service catalog, but the fundamental differences between Professional Services, Service Desk services, and Application services must be reflected in the structure of any Service Catalog.

The high profile activities of Project, Release, and Change have specialized entry points requiring trained professionals and sometimes longer standing relationships on both sides of the interaction. Service Requests and requests for service restoration may be more commoditized. And Demand, while often seen as entry to professional services, needs to encompass the other types of services as well.

From the senior executive down, the business/IT interactions can be defined:

Business	What	IT entry point
Senior executive	Discussions of largest-grained needs; final escalation of most serious issues. Ideation/ exploration.	Senior IT leader (Customer Relationship Management function)
Unit executive	Requests for major new systems. Large project level.	Accept Demand
Functional area owner	Requests for new systems, additional functionality, improvements	Accept Demand, Execute Project, Deliver Release, Improve Service
User	Requests for orderable IT services; reporting of incidents	Fulfill Service Request, Restore Service

Service consumers and entry points

These service entry points need to be broadly understood in the IT organization and every IT staff person should be educated that any contact with business customers or users should be assignable to one of these categories.

Software development is an interesting service entry point. The primary service entry point of concern to the software development capability is requirements capture. The Agile movement in particular sees this as an ongoing interaction.

Such requests for enhancement are still demand requests, and depending on the service model for the application service, might be prequalified or discretionary. As noted elsewhere, this book views Agile pipeline systems as compatible with a Service Request Management system platform.

	Professional Services	Service Desk	Application Service interface
Accept Demand	X
Execute Project	X
Deliver Release	X
Complete Change	X
Fulfill Service Request		X
Deliver Core Transactional Services			X
Restore Service		X
Improve Service	X
Retire Service	X