I've been thinking about the concept of too much a lot recently. Specifically the problem I have is with too much email.Last year I watched this great video about the concept of Inbox Zero by Merlin Mann. Willing to try anything I started to enact the recommendations and before I knew it I was down to zero every night.
I won't lie - it was liberating. The relief of ending each day with no email was amazing.
Too much ...
Yes, I admit, there were the odd days when I fell off the wagon. A customer trip here or too many meetings there. But it was fairly easy to catch up, and the motivation was huge. But then I started to slip. Over Christmas I took a vacation. Despite lightly checking email, when I returned there was over 2,000 emails.So here I am. It's a daily struggle to stay on top of the volume of incoming email, and it's hard to find hours in the day to stay on top of meetings, urgent actions and keep up with the rising tide.
Is there such a thing as too much change?
The challenge comes when the backlog exceeds the time available to process. I never seem to get ahead. And I'm never sure what time bomb is left in the unread emails.And so it is with Change Requests. If we're behind on the processing requests, then not only do we have to continue as fast as we can to catch up but there's also the extra work of scanning the queue to see if there's anything more urgent.
As the queue backlog builds, so does the amount of effort spent simply scanning the queue and not actually processing anything.
What can we do about it?
The first step is to recognize the problem. Realize that until we understand the problem it's impossible to fix it.
Here are a couple of options we should consider for the initial problem:
The Change DMZ
Declare all change requests Pending and require that critical requests be resubmitted.
Downsides - not popular but you should see some reduction in re-requests
OK at some point we will want to process them, but we may want a more refined process to do so more efficiently.
Defining a Change
To reduce the chances of being back in the same hole within a week, we should take some time to define a Change. That way simple Requests may be processed quickly with minimal overhead.
Example criteria - if the Request doesn't require new functionality or a CMDB update then maybe it's not a Change after all.
Standardizing Changes
Before we open the flood gates to all the new Requests, we should create templates for common Requests. This should reduce the effort to submit a Change, and templates should define how the Request is implemented to minimize failure. Minimizing rework is one key way to stay ahead as the volume of work increases.
Automating Changes
Having defined what the common Changes are, we should now be able to track more accurately how many such Requests we're getting. Some simple analysis of effort applied will allow us to identify where we're spending most time and the candidates for automation.
The brakes
Now that we've regained some control of standard Changes, it's time to look at more complex Requests. Not all Changes are created equal (yes - I hear you breathe a sigh of relief).More significant Changes benefit from a little more analysis before proceeding. Lets call them Releases. Defining Releases will help us identify which Changes should be subject to more advanced review.
Example criteria - if the Change needs coordination across multiple disciplines (eg application, database and storage) or requires additional budget then we should call it a Release.
The key shift here is that we should hold the business accountable for prioritizing which Changes are in which Release, and which order Releases are sequenced.
The win
So now we should have a fairly efficient Change process, with standard Changes defined and automation behind the common, time consuming ones. We've got a Release process designed to ensure complex Changes are implemented with minimal risk, whilst also ensuring that they're aligned with Business priorities.By doing this, we should have reduced our Change backlog and increased our Change velocity - while ensuring that we're aligned with the Business on critical decisions about major projects.
How are you keeping up with Change? Share your views in the comments.
Some thoughts around Change as i think about email:
ReplyDelete1. Who is the Change assigned to and can it be assigned to someone with more expertise or who is less busy. Can this be automated?
2. Can a Change be auto-identified as a Release (multi-part) and then automatically recreated as multiple Change items where each Change item is assigned a different person or priority?
3. Can "responses" to many Changes be automated and involve no person. E.g. standing up a new web server on a new VM.
4. Can invalid Changes be trapped at the point of input and the user entering the Change be told to do something else?
Good questions.
ReplyDelete1. Tracking workload on individuals is a little tricky. You can track backlog of assigned requests, but unless you know how long they take (hint: use more templates) then it's hard to assess workload.
2. Defining criteria for what is a Change vs a Release. My starting point for a Release is
- needs budget
- changes current functionality
- requires multiple service owners to coordinate
If you can establish any of these, then you could auto create a Release.
3. Automation is a key way to take work out of the system. Best way is to define templates for Changes and track the volume / approx effort and use that to prioritize automation.
4. How would you define an 'invalid request'?
Before you know it you'll be spending more time at the golf course!