Bill is a database administrator in a large enterprise. Or a Unix administrator, or a security architect, or any of a number of similar positions providing shared services. There are three primary ways that demand for Bill’s services appears:
- Project managers come to his boss and ask for a percentage of his time. Once he is designated as a project “resource” he has deliverables: requirements and design assessments, perhaps actual construction of infrastructure. He also finds himself responding to lightweight project workflow for “issues and risks” and “action items.”
- He is assigned incidents, service requests, work orders, changes, and the like through various enterprise workflow systems, especially the integrated IT service management system.
- He also is tasked by his manager with responding to various “initiatives” that occupy a middle ground between projects and workflow: audits, compliance efforts, capacity assessments, root cause analyses, key system reviews, and more.
On Wednesday, he gets called into a Tier 2 incident involving the organization’s marketing campaign system. On Thursday, he has a deadline of responding to an audit finding for the organization’s payroll system. And on Friday, he has a critical path deliverable due for a strategic enterprise project. Fun life!
Stories of such overburden pervade the IT industry. Ask yourself: how many people in my company accept both project and service request work (e.g. Incidents, Service Requests, Changes, perhaps “Work Orders” if distinct from Service Requests or Changes)? And are they also assigned to the less formalized initiatives (which we’ll call “continuous improvement”)? Do their line management and their project manager at least have visibility into this aggregate demand and its consequences?
Staff time is a precious resource, and there is always more demand than supply. Is Bill “working on the right thing?” Or is he just “working the thing right” – from the shareholder’s perspective, doing perhaps the wrong thing efficiently and effectively?
There are two responses to this. The Agile and Lean communities seem to be very big on killing off shared services. Every team needs to have its own DBA, in this view. But I am skeptical that this is a complete answer. Enterprises establish shared services for sound business reasons. Is the model really that broken? What if the service is simply too infrequently used and expensive? Does everyone get their own electrician? If not, then where do we draw the boundary between product ownership of a resource vs. the requirement to use shared services? And if we are unavoidably going to use shared services, can we improve them? How do they solve this in other industry segments?
Certainly, cloud services are shared. In order to make such products work financially, cloud vendors cannot simply dedicate resources wholly to each client – this is obvious with physical IT capacity, but also applies to those operating that capacity. And if the service includes higher-value-add offerings, these questions unavoidably emerge.
If we want to improve shared services, the first step in answering these questions is understanding demand for the service. As above, for many infrastructure resources, project, service desk, and continuous improvement are the three legs of the demand stool. And we, as an industry, are a long ways from having a holistic view into all these sources. Look at the historic walls between project management and the IT service management systems. It is only in the last few years that we have seen vendors addressing this. They are either building new integrated solutions supporting both project and service management as modules, or they are integrating their legacy products together more tightly so that both kinds of demand are visible in a common.
What would unified demand management ideally look like? All project work integrated with all service desk work, and every continuous improvement initiative — every “bright idea” — also registered as a demand request. Project issues, risks, and action items captured using the same platform as service request management. Agile pipelines are part of the same mix… just more demand.
[Proposed: whether an Agile story to enhance a continuously iterated product is “project” or “continuous improvement” has more to do with funding models, in any event.]
And each individual would have a single pipeline for work, combining all these different flavors, and those individuals’ managers would have much greater transparency into how their teams are supporting enterprise objectives, and how to support them in setting optimal priorities.
It would have to be a culture shift. Those who are used to working in the old way may view unified demand management as an imposition – depending on how it is implemented. Lean philosophy, and modern Kanban practice, would caution against an overly top-down approach. There are important questions of autonomy, morale, and motivation. It can’t be about burdensome “dollars chasing dimes” time tracking systems.
But how can an enterprise ensure that resources are optimally allocated for value? How can we alleviate the ongoing overburden of IT staff? It starts with cleaning house — for example, minimizing and centralizing your tracking systems. How many different workflow systems are you running for internal IT? Can you consolidate them? If you’re not ready for a common platform for both your PMO and Service Desk, can you at least report after the fact on their combined demand and activity? Can you encourage the continuous improvement initiatives to either register as projects or as some appropriate ITSM work (e.g. Problem)?
And finally, demand management is only the first step. Once we consolidate the demand, how do we make better decisions about it? That is the role of execution management... a term heretofore little used in IT management circles, but critical to mature conceptions of industrial operations. One initial note: we have GOT to get away from simple FIFO (first in, first out) queuing models in responding to demand requests.
As above, the Agile alternative is to break apart shared service teams: systems administrators, DBAs, and so on. This may need to happen in certain areas in any event; if the demand within a given product or project merits a full time resource, then the assignment should be made. However, the reality I have seen is that even 100% dedicated resources (especially if they are good and knowledgeable) unavoidably get pulled back into the occasional “out of scope” but urgent matter for which they are uniquely suited. And then we are back to heterogeneous demand against a shared resource.