EMA Blog Community

Why IT staff work 70 hour weeks…

Jane is a systems administrator in a large enterprise. Or a DBA, or a security architect, or any of a number of similar positions providing shared services.

There are three primary ways that demand for Jane’s services appears:

1. Project managers come to her boss and ask for a percentage of her time. Once she is designated as a project “resource” she has deliverables: requirements and design assessments, perhaps actual construction of infrastructure. She also finds herself responding to lightweight project workflow for “issues and risks” and “action items.”
2. She is assigned incidents, service requests, work orders, changes, and the like through various enterprise workflow systems, especially the integrated IT service management system.
3. She also is tasked by her 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, she gets called into a Severity 2 incident involving the organization’s supply chain system. On Thursday, she has a deadline of responding to a security audit finding for the organization’s general ledger system. And on Friday, she has a critical path deliverable due for a strategic enterprise project. Fun life!

There is often no specific prioritization across these tasks beyond “who is screaming loudest.” The Sev 2 incident may command her attention until it is resolved, but is this really the correct priority? What if it’s only a partial outage, and the project manager is ramping up the pressure for her deliverable? Jane may be attempting to do a “little bit of each” – switching her attention across the various tasks competing for her time, a very inefficient way to get work done.

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?

It’s scenarios like this that have made unified demand management an increasingly hot IT management topic lately. IT staff time is a precious resource, and there is always more demand than supply. Is Jane “working on the right thing?” Or is she just “working the thing right” – from the shareholder’s perspective, doing perhaps the wrong thing efficiently and effectively?

The first step in answering these questions is understanding IT demand. Project, service desk, and continuous improvement have emerged for me as 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 (e.g. ServiceNow). Or they are integrating their legacy products together more tightly so that both kinds of demand are visible in a common view (BMC’s IT Business Management).

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. 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’s going 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)?

Then, if you want to really go to gemba, start thinking about your email and calendaring system. It’s the default queuing system and represents a vast variety of demand in any enterprise context. How can you get a better understanding of it? I’m not aware of any company offering demand analytics based on email and calendaring, but with some creative application of text analytics it would seem to be a possibility… if you’ve got some thoughts on this, please contact me.

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… stay tuned.