The posts yesterday were the "patterns." I suppose the definitional material would help...
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
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.
The demand process captures requests for new or changed systems, consultations, even brainstorming. (The term “ideation” is used by some.) These requests are assessed, their preliminary scope established, and then prioritized against strategic objectives (coming from the portfolio management process and other forms of strategic planning), and the projected available resources. The proposed work may be assessed along several dimensions, such as projected benefit, complexity, and cost. Projected return on investment is established, and some form of ranking algorithm applied (hopefully subject to close human review).
Demand management in some organizations is tightly coupled to the annual IT planning process; however, many organizations do not wish to limit opportunities for new IT capabilities to a once-a-year window, which is why this framework sees Demand Management as an event-driven lifecycle.
Demand requests are usually seen as originating from the customer:
- New application service platforms
- Ongoing improvements to service functionality
- Ongoing improvements to service stability & performance
However, they also can originate from the IT organization itself. Typical examples of IT-driven demand include:
- New infrastructure services
- Technology refresh
- Patching and other required maintenance
- Proactive technology implementation
- IT enablement and continuous improvement
Technology refresh includes the basic capital depreciation cycle as well as things like replacing core technologies in the environment, for example due to a vendor sunsetting their support. Patching and even complete version upgrades may be necessary for security, operability, availability, and other continuous improvement dimensions.
Proactive technology implementation is a polite term for what many IT organizations did in the late 1990s, rushing to bring in new technologies in a sometimes misguided attempt to position themselves for anticipated business requirements in e-commerce.
A classic statement of this view comes from Lientz: “By waiting for user requests, IT is placed in a reactive mode…IT is not like a village fire department…[it should] seek out opportunities.”
It can be a valid approach but the failures here are sobering. Where IT is perhaps well placed to drive simplification, strategy alignment, and creative use of existing resources, too often IT-initiated “improvements” center around new and “cool” technologies with unclear business benefits.
And, of course, the IT enablement systems that are the subject of this book compete for the same resources as systems supporting revenue streams.
IT-driven demand is therefore a very sensitive issue, as it competes for the same resources as business-driven demand, and can easily degenerate into “IT for IT’s sake.” Nevertheless, it will always be a part of running any significant IT capability.
The Accept Demand process may have one or more major organizational homes. Both applications and infrastructure groups may need to track demand and may build independent capabilities for doing this.
Demand management implies a balance between supply and demand. Therefore, demand management, portfolio management, service request management, and the staffing process should be aligned so that required increases in support staff for new IT capabilities are correctly anticipated. More mature organizations would also integrate Capacity Management at the technical level.
In the most obvious sequence, prioritized and authorized demand requests may become projects. But the idea that demand always leads to a project is misleading. A project has a defined start and end date, but if it has created a new service with an indefinite lifecycle, demand for ongoing support will remain. The project is only a higher-intensity, more focused set of activities perhaps to initiate the new service. Further enhancements may not even merit full project governance, especially in an Agile framework.
This leads us to one of the ambiguities in Demand Management – which axis does it apply to? Is it purely and only about the service lifecycle? What is the relationship of Demand Management to ongoing service delivery? These questions will be explored further in the Accept Demand Patterns chapter.