Here’s something you don’t hear everyday: “Our SAP implementation finished ahead of schedule.”
Sorry, let me rephrase that. Hearing about an SAP implementation that finished ahead of schedule is like hearing that someone captured the Loch Ness Monster and turned it into a kiddie ride. It’s as likely as Bigfoot singing “La Traviata” at Lincoln Center. It’s as if you called a software company’s tech support line and the voice on the other end didn’t insist you reboot your PC.
SAP implementations don’t finish ahead of schedule. Failed to finish is much more likely.
The company that made the pronouncement? Daiwa House Industry. Not only did Daiwa House complete its SAP implementation ahead of schedule, it did so despite being interrupted by the Tohuku earthquake — the one that measured 9.0 on the Richter scale and took several nuclear power plants offline.
Intrigued, I set up a meeting with Daiwa House’s SAP implementation team at the Realization Project Flow conference, and through two excellent interpreters, spoke with Kyoji Kato, executive officer and general manager of Daiwa House’s information systems division, Project Leader Ryuzo Matsuyama, and Isao Nakae, SAP solution division director at Fujitsu Kansai Systems, Daiwa House’s implementation partner on the project.
What follows are six valuable lessons they learned transforming a seriously challenged effort into a roaring success.
Consider this a practical supplement to my recent “13 tips for turbocharging projects” post.
Lesson No. 1: Having staff wait for work is better than having work wait for staff
All three interviewees were emphatic that moving from traditional project management techniques to critical-chain project management had a huge impact, resulting in 25 percent cycle time reductions for every phase of the effort.
This isn’t the place for a tutorial on the subject (among other reasons, I’m not qualified to provide it), but one of critical chain’s most important principles is that projects should never be delayed because staff are not available to work on the next task. Why? Because one such delay sets off a — no pun intended — chain reaction of late task starts.
In other words, chaos ensues, and each late start makes the expected time lines in every dependent chain of tasks increasingly unpredictable.
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.”)
Lesson No. 5: Be aggressive about business improvement
Regular Advice Line readers understand a core principle of next-generation IT: There are no IT projects. It’s a principle so important that my consulting company advises clients to never name a project after the technology. As Daiwa House’s project title was “SAP Implementation,” I was curious as to whether that was, in fact, the actual focus.
Interestingly enough, as initially chartered, this was very much a classic IT project. Its primary goal was to support management, particularly in accounting, human resources, and compliance by providing a more coherent view of the company’s information. The main expected business benefits were to close the books faster, improve HR management, and support international compliance requirements.
Over time, though, the project team became more aggressive in defining business improvements. Designing different and better processes and practices enabled by the new software became a formal part of the effort. It shifted, that is, from implementing SAP and figuring out how to take advantage of the additional capabilities it provided to implementing better business processes and practices as a central implementation deliverable.
One example the Daiwa team was willing to share was that prior to the SAP implementation, pricing mistakes alone totaled 0.5 percent of overall billing. As the company’s revenue hits $20 billion per year, that’s a number worth paying attention to.
There’s little doubt that fixing errors of this magnitude resulted in an enormous reduction in wasted effort. There’s even less doubt that the impact on customer relationships was immense.
Short version: Daiwa House’s experience validates the principle. In spite of the name, this project wasn’t an SAP implementation. It was a business improvement initiative that relied, in part, on implementing SAP.
Lesson No. 6: Provide a holistic view for all team members
On any project, it’s easy for participants to develop tunnel vision, focusing narrowly on their own task responsibilities. This can result in a collection of parts — each excellent when considered solely on its own merits — that don’t fit together into a coherent whole. The folks at Daiwa House were clear on the importance of making sure everyone on the team maintained a sense of the big picture while addressing their individual responsibilities.
ERP implementations have gained a bad reputation, in which merely late is considered very good, and spiraling out of control is considered common. There are always more ways of doing something wrong than doing something right. Beyond that, the act of defining an effort as an ERP implementation contributes to the likelihood of disappointing results.
Daiwa House’s experience demonstrates that while problem implementations are common, they’re far from inevitable. Even better, it demonstrates that success isn’t a statistical accident. It’s the result of good leadership, management, and technique.
By Bob Lewis – Follow Bob Lewis on Twitter @ITCatalysts
This story, “Six lessons from a lightning ERP rollout,” was originally published at InfoWorld.com
