Demand, Supply, Execution vs Plan, Build, Run

Charles Betz had several wonderful posts on the EMA blog’s but since he no longer works there EMA has seen fit to remove access to his work.

Fortunately for me, one my many habits is to open up about a billion tabs (much to the annoyance of my wife and to the amusement of my coworkers). I had noticed that EMA was no longer allowing access to Betz’s work but I happened to have several of them still open on some tabs! So, I just copied them and saved them to Evernote.

Sadly for the rest of the world we’ve all lost out on some really good information.

Demand, Supply, Execution

Luckily, one of Charles Betz’s blog entries was also posted at Nimsoft located here.

The basic premise of this work and some of this other writing is that IT does not do a good job of prioritizing all work from a universal standpoint.

Sure, we prioritize Incidents (against other Incidents), and we prioritize projects (against other projects) and maybe we prioritize day to day tasks (again, just against other day to day tasks) but we don’t really prioritize all of our work

Here is a direct quote from one of the now lost EMA blogs from Charles Betz:

“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?”

When I read this I thought my concept for how Change, Project and Release management would fit nicely with what he is talking about – a better way to manage all of IT Demand from a universal perspective. But that still leaves out Incident, Problem, and other routine tasking.

The traditional Plan Build Run methodology basically only considers projects or efforts of significant size. All other efforts are just not “planned” – they are just done, often behind the scenes or under the covers.

Often, as Charles Betz describes, leaving it up to individual engineers, administrators or team leads to prioritize and track this other work is inefficient and sometimes even ineffective.

It seems to make sense that a good way to solve this issue is to track all work and prioritize all work against all other work and not in silos  – silos of type of work or often silos by department or team.

Great Idea but…

Can you imagine IT Managers actually wanting to prioritize and track all this work every day? Well, maybe they will want to…but will they actually do it?

Typically IT Managers are not only as reactive as staff but often are the cause of the reactive nature of the environment. How many times have you seen an IT Manager forgo putting in an Incident ticket and instead just call the engineer directly and task her with work? How many times have you seen an IT Director or a CIO put in a Problem Candidate to be reviewed, prioritized and assigned properly and instead just call the IT Manager and tell them they want to see an RCA and some fix actions by tomorrow? Happens all the time doesn’t it?

So, if we really do want to better manage our resources and really do want to better prioritize our work effectively how on earth can we do it?

Consolidate work types

Start by at least consolidating work types together.

As I mentioned before – I think all changes requests should be tracked – which would include projects. That is everything from wanting to patch a server to create a new service is tracked in a single Change Management tool and managed by a single overarching Change Management process.

What about Incidents, Problems and “tasks” (things like audits, capacity planning, or CSI efforts)? This is more of a challenge because most IT shops:

  • Only use Incidents for “end user” issues
  • Don’t separate Requests from Incidents
  • Even if they do have a separate Request system – it is only used for “end user” requests
  • Do not have any formalized Problem Management process – therefore are not tracking it today
  • Do not have a formalized CSI registry
  • Do not have any particular way to track tasks for such activities like “capacity planning” or “audits”

Somehow we need to be able to separate the requests and incidents/interruptions that are internal only from those that are end user/customer based. Hopefully we can use the same ‘tool’ but with a different flag or something that precludes it from any customer SLA or customer reporting.

Also, more IT shops need to develop a better understanding and implement more processes around Problem and CSI. We can’t prioritize all work efforts if all work efforts are not being first recorded somewhere!

Finally, we (as in the IT community) need to develop some sort of terminology and framework that captures the non Incident, non Problem, non CSI type tasking that happens all the time.

And however we do this…it has to be easy. : – )

No one is going to bother doing any of this if the system of record takes more than about 10 seconds to create a task, a Problem Candidate, or a CSI candidate or more than 5 seconds to find one you’ve already created. I can send an email in that amount of time and I can search my email sent folder fairly quickly.

We have to do better than email.