The following processes would probably be considered tightly related to Accept Demand, as Demand Management is traditionally understood from a project portfolio management approach:
- Execute Project
- Deliver Release
- Complete Change
- Retire Service
But the relationship of Accept Demand to these processes is less clear:
- Fulfill Service Request
- Deliver Transactional Service
- Restore Service
- Improve Service
These are more about ongoing operational capacity, and less about fundamentally new/changed services. Yet service delivery competes with service development and evolution, and the two need to be understood in tandem.
Demand management therefore has a special role with respect to the other IT processes; at its most mature it provides a common view of all calls for IT resources.
Demand management can be seen as a governing capability thus:
(click for larger)
Notice the containment of processes within processes; this is to show that smaller processes are really sub-states of the larger processes and the larger grained Demand process cannot be considered complete until the smaller grained process is. Alternately, one could view the Demand process as complete when the work is authorized and assigned to the Execute Project process:
The actual approach here may be dictated by the system implementation, and either form can work equally well. It should be very clearly understood on a cultural level however whether the demand request ends at the point of routing onward, or logically encompasses all the work implied. This book in general will use the second pattern. In this approach, the Demand Request should carry a clear ID into the downstream processes. See the Justify Change pattern.
The above patterns represent a very typical project-centric understanding of demand and project management. However, the Lean dynamics towards more agile, demand pull IT development may mean the diminution of formal IT projects.
This can already be seen in reporting and simple Web site environments, where significant new functionality may be requested without a full project lifecycle. Similarly, even “major” applications may have an initial project to set up the core platform, and then move into a non-project “business as usual” cycle of iterative enhancements.
Notice that in the above example the demand requests do not all route to a Project. New functionality may simply be handled as a Release, or even a reporting Service Request. This may become more and more the pattern, with the increasing penetration of Agile methods.
Similarly, service restoration can also result in demand:
The flow from Restore Service back to Release and Change shows the essentially circular nature of the IT processes. In considering the above flow, where does Accept Demand fit? Is it invoked only after the identification of an Improvement Opportunity?
Or has demand actually been accepted at the point of identified need to restore the service? Or both?
This last pattern would appear unusual from the point of view of a traditional incident manager, as one key aspect of demand management does not usually enter into incident management: whether or not to accept the demand. Service restorations by definition are in general pre-approved.
However, as established in the “Manage entitled vs. discretionary demand” pattern, the demand management capability needs visibility into the ongoing volume of preapproved requests and its forecasted trending, so that larger scale demand requests can be prioritized against the resources available. And, the ongoing organizational commitment to the service, to fulfill requests against it, run it, restore it, and improve it, IS fundamentally demand!
To put tersely: the existence of a service IS demand.