We were working for a large software development company. One of the big operating concerns was the timely coordination of coding and testing. Being off-schedule can cause a serious breakdown in the critical path. To be able to follow up with software engineers to ensure they were staying on schedule (and getting the appropriate support they needed), managers needed to breakdown the projects into smaller, more manageable packages of work (from monthly increments to weekly or in some cases daily). The software engineers had a tendency to view this form of SMART* work assignment as a proxy for “micro-management,” and openly resisted the change. The problem with this stance is that it negates, or at best defers, any support management can provide. (An arguably bigger problem was that line management wasn’t very keen on the change either but that’s a different issue and a broader discussion).
SMART work assignment is more common in production environments, but even here we see many cases where work is not technically assigned with any specific time parameters. Employees, who have often been doing their job for many years, work off priority or “hot lists” which are posted for them. What’s often missing is the actual schedule indicating when the job needs to be completed. That can have many causes but a couple of the more common ones are basic planning standards aren’t trusted, and schedules are too often changed at the last minute to accommodate rush orders.
Many people resist the notion of time standards (it seems to conjure up the image of industrial engineers running around with clip boards and stop watches) but time standards are a vital link in any work or production schedule. Without being able to relate work to time it is virtually impossible for a manager to meaningfully schedule and follow up on work. It also makes it very difficult to uncover anything but the most obvious types of lost time.
* Specific, Measurable, Attainable, Realistic and Time-bound
