Here’s a typical IT scenario: each quarter, you need to check audit user access to a critical application. Your internal security standards require that you revoke access for those who haven’t been on the system for over 90 days. I’ve seen this before, and the process (at the time) had many challenges:
- It’s manual; we did a quick-and-dirty set of steps years ago to cover the minimum requirements, that involves extracts from application logs, file transfers MS Access and MS Excel, and some emails
- It’s not drop-dead simple, because there is a list of exceptions – user IDs that were always kept active, even if they haven’t been used
- The overall process was never documented
Coupled with the fact that this only happened once per quarter, and involved less than five total effort hours to take care of, the easy response was to just get the task done and move on. But I think this is penny wise and pound foolish; there are long-term quality Problems to be avoided, and short-term Opportunities for internal staff development that we were passing up!
Problem: If we continued to just do the minimum, to satisfy the requirement, it was no surprise that over time, steps were omitted. The lack of documentation forced folks to repeat steps from memory, and pass along the process word-of-mouth as roles rotated and/or people turned over.
Opportunity: Simplifying things required some automation; nothing too difficult, but definitely interesting and non-trivial; for example, we needed a custom table for the exceptions. For staff members looking to build technical skills, this was a perfect training opportunity; small risk, small time requirement – a perfect filler when you are burnt out on the big project and need a bit of an escape.
Of course, the push-back was always the same: I Have No Time For This. Most can easily envision a total solution that is simple, uses familiar technology, gets rid of the multiple platforms and manual processes, and is sustainable. In this case, however, it would take about 16-32 effort hours to get done, and who has the time?
The solution was to attack the problem in baby steps; make the overall process a little better each time. For issues like this, you don’t need to solve all of your problems now, and it’s OK to leave the work unfinished until next time. However, the key is that you must commit to making a small improvement each time you “touch” the thing.
For example – back to the user access audit. For a first pass …
- The current task owners walked through the process with me, and I took scratchy notes on paper and in a Notepad text file – stashed on my hard disk
- I got the Access database extract and Excel spreadsheet that counted the days. I iterated on the spreadsheet, automating the counts and the formulas for computing days since last log in.
- I returned the list of users who hadn’t signed in for 90 days, which were then manually matched against the list of exception user IDs.This work was a one-time add of about three effort hours – a small start, but a teeny platform on which to build.
A few months go by, and it’s time for pass two …
- I moved my scratchy notes into a shared document and iterated on the process, mostly just cleaning them up to be somewhat legible
- I still received the list of users and their last access date, but this time I got the list of exceptions. I iterated on the spreadsheet to take this into account
- I still sent the results back, but note that now (and never again) does the next person in the process need to edit out the exceptions
This work was another one-time add of two or three hours; but we’d already simplified the overall process, and we saw the total effort (including process improvements) starting to decline.
Next iteration …
- We teed up a programming project to build an exception table and automate the log extracts – nothing more than a couple hours of effort
- I took a final cut at the process documentation in the shared area, then turned it over to the operational support team
Note that each time you iterate on something like this, you need to feel comfortable with the idea that these works in process, these “interim deliverables”, are clearly unfinished, even raggedy. It shouldn’t matter, because each time you touch it, it gets a little bit better. Plus, the priority was originally low enough that a totally manual effort was OK, so what’s wrong with documentation that is incomplete?
Incremental improvements on the primary goal (automated user audits) with tasty side benefits along the way (mini side projects to keep stretching your tech chops) … win-win.