Monday afternoon, I have the honor of being part of a meeting to discuss “Project Executio.” The bosses complain that engineers in our department aren't getting our cost reduction effort closed out fast enough. It's true. We aren't making fast enough progress toward our goals and it's a good sign, in my view, that we're taking some time out to focus on the process itself, rather than having another typical “status” session.
Looking through a Lean lens, I see the problem in very simplistic terms. Essentially, we're applying batch and queue to engineering tasks. We spent January and February “building a pipeline” of projects for the entire year. Brainstorming took all of our time. Execution wasn't on our radar screen. Now, instead of a handful of projects to work in a focused effort, we have dozens. We pick away, and finish nothing.
It's a paradoxical truth, in lean manufacturing as well as a lean office, that you finish more projects faster by working on as few projects as possible. Multi-tasking reduces effectiveness and therefore results. Indeed, studies have shown that engineers, much like production machinery, lose efficiency when loaded to greater than 85% capacity. Y et the same studies show product development staffs typically face workloads around 200-300% of their capacity. That's certainly true in my company.
While production machines can be budgeted, ordered, and purchased within a year to ramp up manufacturing throughput, skilled engineers (and skilled production workers), cannot simply be ordered and paid for. They must be developed over several years. This process doesn't meet our mad dash schedule for cost reductions. With capacity limited in this way, our only choice for improving throughput is improving productivity. We can tinker on the fringes of productivity with better software, improved coordination between departments, and process improvements, but I believe the best productivity gain we can hope for comes from a shift to single-piece or near single-piece workflow, focusing our limited personnel resources on the projects with with greatest impact and stepping up the takt time on each individual piece.
The challenge that we face in the engineering department is the same as that on the factory floor. Our culture and reward system cater to batch and queue operations. How do you convince management that it's more effective to work otherwise?
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
“How do you convince management that it’s more effective to work otherwise?”
You don’t have to….just replace them with those that “get it”…….
I’ve been in similar situations, once or twice, and found that engineering organizations that are “strong on planning but weak on execution” usually have few or no feedback loops; engineers know they’re overloaded, but management has no view into the current status and predicted future of the programs. Setting up these feedback loops–selecting appropriate metrics and developing the much-needed processes–is, I believe, the solution. The approach that I’ve developed is a combination of standard (and usually very basic) project management tools and monitoring queue sizes. However, this usually meets with resistance at all levels, because recording tasks and monitoring their status is “extra work.” I’ll be interested in reading how things go for your effort.
I think you need to be careful with the manufacturing analogies here, especially if you want engineering management to listen to you.
A plant manager who overloaded the plant to 300% wouldn’t last long, because the drops in productivity would become immediately visible: piles of rework and unfinished inventory, etc.
In product development, managers think the engineers can just “suck it up.” Appeals to shorten “takt time” and move to “single piece flow” aren’t going to resonate with an engineering manager who sees his resources as much more flexible than a machine tool. Instead, talk about speeding time to market, lowering product costs throughout the lifecycle and more effectively executing product strategy. In short, you have to put it in terms that are meaningful for them.
I’d challenge the drive to go to pure single-piece flow. The research shows that engineers are most productive when they have two or three projects – when they get stuck on one they can move to the other one for awhile. But I”ve seen organizations with ten or more projects per engineer – who then wonder why they can’t seem to get anything done.
Thanks for the comments all.
Joe,
I don’t think replacing my boss and his boss is an option at present. ;)
Katherine,
You’re absolutely right that literal “single-piece” flow doesn’t make sense for engineers. Unfortunately, we’ve got a handful of folks working dozens of projects. I’ve got a file organizer on my desk (visual control) that holds my “top five” projects. It works well, when I’m able to fend off interruptions.
Thomas,
You’ve got me the most curious.
I spend a lot of time on status reports that don’t seem to be providing the appropriate feedback up the chain. I’d be thrilled to find the right feedback to management. I’ll have to think about that and see what we can come up with.
Thanks again!
-Andy Wagner
A common scenario is: a pooled engineering organization serving multiple product lines. The product line managers have conflicting priorities drawing on the same resource pool. There is a tie-breaker somewhere, but he may be several levels up and not particularly conversant with the product/technology issues: hence, the formal tie-breaking is done only once per year, as part of an elaborate planning process. Any high-priority requrest for new work *during* the year will tend to be at the practical discretion of the engineering manager, who may not have the proper business context to be making the decisions.