David Anderson recently posted an interesting paper on how Theory of Constraints can be used to improve an IT department at Microsoft.
What struck me was the amount of time used to do estimates. David states that 40% of the capacity was used - he doesn't say if this was hours, dollars or in what units this capacity is measured - but I'll assume it was hours of productive work for the entire team.
David states "doing estimates is muda." If you spend 40% of your resources estimating the work, then you're doing more than "muda," you're behaving very poorly as an IT manager and should look for work elsewhere.
Using 40% of any resource to do estimates is down right wasteful. Simply improving the estimating process alone would result in dramatic improvement in productivity. David has used this example in the past to suggest we "stop estimating." While this is likely stated for effect (espically if you're spending 40% of the time doing it), the estimating process provides several important pieces of information for a enterprise type project:
- Is this request going to be worth the investment?
- How would we know this if we did not have some sort of estimate of the sunk cost to deploy the fix?
- When will this fix be available for deployment?
- What resources will be needed to deliver this fix?
The paper makes an assumption about maintenance activities that might be questionable outside the narrow confines of this example:
- If it is worth scheduling for delivery within the next 25 days it would be delivered - regardless the cost. Does it really not matter what the cost of the maintenance fix is? Seems cost woudl play some role in the selection process.
- The 5 day processes time seems long for simple maintenance fixes. If these are bugs, how did they get there in the first place?
- The assumption that all maintenance requests be treated equally for cost purposes greatly simplified the decision processes. Does this actually reflect real maintenance activities?
I'm always put off a bit by these types of case studies. They are single point examples. They are not likely representative of a broader family of problems found in the IT maintenance portfolio domain. They are used - in this case - to generalize about the usefulness of the process.
Too small a sample, too large a conjecture
The paper brings up some other important questions outside the scheduling of work within the group.
- How does a business application get release with "bugs"?
- How does the owner of the application selection which fixes to do and how much are they worth?
- If the cost of each maintenance action is normalized, how does the application owner make choices about the "real" cost?
David's paper and all the questions is answers and asks anew are important for any enterprise application domain.
