Lesson No. 2: Multitasking is more prevalent and more harmful than anyone thinks
Companies that don't understand the importance of Lesson No. 1 inevitably attempt to maximize staff utilization. It would seem to make sense. After all, any time you pay an employee for doing nothing sure sounds like waste -- and it is waste. The problem is that most attempts to maximize staff utilization do more harm than good.
We've already mentioned one problem: cascading project chaos. Beyond that, keeping employees busy means insisting that they multitask.
Employees never multitask, of course. What the word actually means is having to switch from one task to another, unpredictably and often. Ask anyone whose work requires concentrated effort what impact this has and they'll give you the same answer: It's all bad. Every switch means getting one's head out of one task, reorienting, and getting it back into the other task.
This process is neither effortless nor instantaneous. The lesson is clear: Let employees finish what they start, even if that means they occasionally find themselves with nothing to do. All in all, they'll be far more effective and productive.
Lesson No. 3: Eliminate "apple polishing"
Last week's column mentioned the importance of making sure everyone knows when they've "reached the exalted state of 'good enough.'"
Daiwa House's project leadership team recognized this issue -- they call it "apple polishing" -- and hit it head on. They provided clear exit criteria for every task. They communicated the importance of avoiding apple polishing often. Then they communicated it more, because if there is anything to be said about the shared culture of engineers, it's that they constantly strive to find ways to make whatever they're working on even better.
It should come as little surprise that Mr. Matsuyama chuckled when I asked how readily his team members accepted the need to stop polishing their apples. The answer: While it's vital to project success, it takes constant, active management.
Lesson No. 4: Don't overdefine the tasks
"Defining details," the team explained, "doesn't help understanding. It causes misunderstanding."
By "details" they weren't referring to specifications. They were referring to task definition. They were emphatic that there comes a point of diminishing returns, below which the project manager is micromanaging instead of allowing team members to use their experience and good judgment to get the job done.
In this vein, they also mentioned extensive use of prototyping as a way to determine implementation details. "Prototyping" isn't a word commonly used in conjunction with "SAP implementation" -- it's about as common as the phrase "ahead of schedule."
With the right team, though, it turns out to be entirely feasible and well worth the effort. (For more on this subject, check out "A surefire bet for IT job security.")