In the last month I’ve added quite a few blogs to my reading list. One new one is “Movin’ Meat,” written by an ER doctor out of the Pacific Northwest. Besides just being interesting, some of his blog posts support my theory that IT folks can often learn things from people in other fields. The post from June 25, 2010, part four of his “Advice for Interns,” is one of these cases. When you read it (link is at the end because I want to get to my actual point before you leave to read it), I think substituting “customer/system” for “patient” in his list works nicely.
My real point is this: one thing in his list really stood out for me. It’s something that seems really obvious when it’s said, but also done wrong a lot:
“Determine the rate-limiting step and make it priority #1 in the work-up”
Figuring out what the slowest step in a project is going to be and getting to work on it right away is often key to getting a project done in a timely fashion. Especially if a large chunk of that time will be waiting for something. When you know it’s going to take six weeks for a request to make it through your purchasing department you should start that right away, especially since all you’ll be doing is waiting.
As kids we were told by our teachers to read all the instructions first, then start working on whatever we were doing. Determining the rate-limiting steps is the same sort of thing. By taking a few minutes at the beginning to look at the whole project first, rather than just starting on step #1 and going one by one until you’re done, you can often optimize things so that the longest parts of the project are done in parallel with the rest.
Links:
– Movin’ Meat: Friday Flashback – Advice for Interns Part Four
I agree that this is often done wrong. I never had the vocabulary express this idea concisely. I would also expand it to include use of support contracts. I have seen fellow sys admins spend hours on an essoteric hardware/software problem even when there is sparse documentation, lack of expertise and a support contract in place. Then only after hours of wasted effort, they will call support, then they have to wait for a call back, creating a longer delta from start to finish.
Sometimes the problem will be simple and fixed by support in five minutes which is bad enough, but other times it will be so difficult that takes support another callback from higher level engineer. This adds to the delta.
If the sysadmin wouldhave spent five minutes on the problem declared it difficult enough to call support, then worked on something else (we have infinate work) while he/she waited for a call back, their productivity would have been much greater.
Also, this applies even if the sys admin does figure out the problem, but it takes him/her too long. Sometimes the shortest amount of time spent is not the shortest over all path, but still more efficient in the long run.
Scott M