In high school, I worked at the gas station on Vashon, a small island in Puget Sound. Local philosophers would gather there and discuss how the world was going to hell in a handbasket. It was during such a lecture by my boss Dale Quickenberner after one of my many mechanical learning experiences (i.e., screwups) that I first heard this wise advice: "Don't assume, Johnson. Because when you do, you make an ASS out of U and ME."
These words came back to me recently as I reflected on our ERP project delays and realized how many assumptions my team had made along the way.
Assumption 1: That despite signs to the contrary, we could carry on according to the plan.
Our project plan was aggressive. During our initial meeting, I watched our vendor's project manager raise his right eyebrow when we told him when we wanted to go live. But we were all committed to making it happen.
My mistake was ignoring the warning signs that we were falling behind. We wasted precious time revisiting issues that had previously been resolved. Yet I assumed everything was OK and kept the team marching toward our go-live date.
Assumption 2: That making our deadline, or not making it, was solely up to us.
Our slipping task completion dates told us long before our scheduled project meeting that we'd never make it. Then I received a call from my vendor peer at Eclipse, telling me that his team had discovered a bug. We pushed back the date
Without recriminations, we removed the slack between phases. What we had planned to do in four phases we now considered doing in three. What we had planned to do serially, such as developing operating procedures for subsequent phases after the first phase had been implemented, would now be done in parallel. Still, to make it all work, we had to fix other issues.
Assumption 3: That everyone was working from the same set of assumptions.
When we announced the delay, we discovered quality-control flaws. We were missing a consistent work product from those who wrote up standard operating procedures (SOPs). Some had assumed the audience would consist of users who were already trained, so they wrote down only the basics; others assumed the documents would be used as both reference and training materials, so they included keystroke-by-keystroke instructions.
So we clarified the target audience: new users who had received four hours of training but would need the documents to perform their jobs. Training manuals would be developed not by us but by our software provider.
Assumption 4: That "someone else" would do the testing.
During our review, we learned that our procedure-writing teams were approving SOPs without testing them against the software. Everyone assumed that someone else was responsible for process-proofing the procedures, which explained the seemingly endless cycle of rewrites. As a result, we created a testing process.
Americans hate delays, and project misfires are no different. But the lessons we've learned over the past few months will stand us in good stead when we move on to the meat of the project: our front-line operations. The time lost can be used to infuse our back-office associates with knowledge through mini-training classes. Our front-line business process design teams will have the benefit of clear instructions on how to transform their knowledge into our new procedures.
All this brings me to a final assumption: that I've learned the Quickenberner lesson at last.
Les Johnson is CIO at North Coast Electric Co., a wholesale electrical distributor in Bellevue, Wash. Write to him at ERPJourney@ciodecisions.com. This story originally appeared in the January 2006 issue of CIO Decisions magazine.