One more complaint from my students (see Monday/Tuesday posts) is: “I’m given other jobs, in addition to my coding, and asked to do them without impacting the main project I’m working on. Not just occasionally, in a crisis, but all the time.”
Some might say that this trait of trying to squeeze more out of Engineering is just human nature or even a good Management technique, and that you can’t blame Management for trying. But I say you can blame them for trying. They should know better.
Management believes engineers pad their estimates, and therefore they probably have a bunch of time available to get other work done. Or they think engineers love working until midnight every day. And on weekends.
Ironically, if engineers are always given additional (but unpredictable) work to do, they will pad their estimates.
This problem is similar to making project changes without assessing and including the impact, but it’s more insidious, because this bad behavior can be happening even when there is a change management system in place which is followed. These “extra tasks” are not for the primary project, and so the work they require may not be estimated and the primary project’s schedule is not modified to include it.
I think a large part of the solution to this problem lies in using a work tracking tool that can track all the work of Engineering, regardless of project. The work elements could be new development on Project A, enhancements due to changes on Project A, maintenance tasks or bugs on Project B, some requirement writing or analysis for potential Project C, etc. If each work element is estimated, the workload of each assignee can be added up and evaluated against deadlines.
This can be done with a spreadsheet or a more specialized tool. At my last job, we had such a tool that tracked all engineering work (and was used as our bug tracker as well). It was so liked by the engineers that they wouldn’t work on a task unless there was a work task opened for them to do the work against. Sounds bureaucratic and obstructive, but it wasn’t. It worked great. (If you’re curious, you can find out more about it on the Duck Pond Software consulting link below my name.)
But, once again, if Management does not buy into the process and tool, nothing will change. Selling Management on the benefits of work tracking is much like selling them on change management. Management must be made to understand:
· how many little extra tasks will result in missed deadlines, and how missing those deadlines will mean missing the turnover to testing, resulting in missing the release schedule.
· that engineers will eventually give up on their project deadlines after being given additional tasks with the inference that these new tasks are higher priority. And Management must understand how demoralizing this all can be.
· that the use of a work tracking process for all Engineering tasks will result in greater Management visibility into what everyone is doing and greater project control.
And, in the end, it has to involve Trust. Trust that Engineering is using legitimate estimates in their schedule, and not padding it to compensate for extra work they’ll be asked to do. Trust that Management won’t do end-arounds and task the engineers outside of the process. Trust is key.
Anita Wotiz
www.duckpondsoftware.com
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering (next class Aug 2008)
Software Project Planning, Monitoring, and Management (next class Nov 2008)
