(Chapter Two in an eBook titled the same)
By Phillip G. Perkins, ACUMEN Corporation, President and CEO
|I’m going to start of this chapter of Epic Fail with an excerpt from my 2003 book “Points of Productivity; Turning Corporate Pain to Gain”. I know that may seem self-serving, but bear with me a moment. I’ll relate this to our subject matter shortly.||
That wasn’t so difficult was it? Hopefully by now you know that the answer to all of the questions is … people!
After years of study and millions spent on research it finally became clear that “computers don’t kill productivity, people kill productivity.” Now (if you had read the book), you already know that I hate computers. They’re dumb as a stump. But much of our problem rests with the way we use computers and we use them incorrectly because our expectations have been improperly set. Many times those expectations are set by the software vendor. After all, they’re there to sell you something. Just as many times, however, incorrect expectations are set by the decision makers in our companies who write the checks.
It goes sort of like this. The software vendor demonstrates a new ERP system. Typically those attending the demonstration are the executive-level management team who make decisions on how money is spent. Will they actually use the system? Probably not. Have they asked the actual users what sort of functionality should be included? Not so much. No, they are there to be sold to … to be told that this new system will reduce lead time by 25 percent, ensure customer satisfaction by anticipating needs and slice and dice your data so that you can basically stay on the boat and phone in for results. Sure.
And here’s the real disconnect. Some software vendors soft-sell the importance of proper implementation and training (the people stuff) because it increases the total cost of ownership of the system. They’re used to hearing business managers say, “Our people know our business and we’ve had a computer system for years. Just give us some training and we’ll be okay. Project management? No … no … we’ll handle that.” At this point, if I knew how to spell the sound of the “raspberry” you would see it in print.
Yep, that came from a book I wrote 12 years ago, and not much has changed since then. As you imagine we have been introduced to hundreds of companies in our nearly 25 years in business and seldom find one who fully understands the importance of allocating the human resources necessary to successfully implement an end to end business system. I’ve been in this business a good while and this fact still surprises me.
I could go on blaming my own industry for the disconnect (as I did above and in 2003) but I think it is a simpler matter than that. I think it goes all the way back to the claims (and sometimes even promises) made by computer and software manufacturers back in the earliest days of business software. If you were around back then you will recall that a picture was painted of a lightened workload since the computers and software that drives them would be doing a bulk of the work. I think the misperception is exacerbated by the relative ease of use of desk top tools.
After all, how many times have you heard a software package described as having the “Microsoft Office look and feel”? Well truthfully that on screen configuration does cut the learning curve since most white collar workers, students and many others have a great deal of experience with Excel, Word and other Microsoft personal computer software.
Planning, Planning and More Planning
Here’s the real crux of the matter. Any successful ERP project begins with very detailed planning. Of course the computers and software can’t do the planning. Stakeholders at the company implementing the software spend the time it takes setting forth the goals and objectives of the project and work with computer professionals to put together a realistic time pegged project plan to realize those objectives.
I’m a firm believer that any project plan must include at a minimum these critical elements:
• A time pegged project plan with milestones along the critical path clearly identified
• A list of dependencies (human, organizational …whatever)
• A list of assumptions (“stakeholders from each functional area will be available for the sessions indicated on the project plan”)
I think it is also important that the consequences of missing milestones, failure of dependencies and incorrect assumptions be outlined for both the client and the information systems professionals. When done properly the project plan is agreed upon by all involved.
You can clearly see that the planning process is labor intensive, people intensive and too often undervalued. Never has the phrase “if you fail to plan you plan to fail” been more appropriate. And if you have spent many thousands of dollars on new software this can be the first road to an Epic Fail.
…and the Fun Has Just Begun
Once a plan is in place the appropriate resources must be allocated by both the client and the software provider. We always recommend an “internal project manager” to work with our ACUMEN project manager. Generally this resource should be one who understands the predetermined goals as set forth in the project plan and has the requisite “tribal knowledge” of the company to represent its’ best interests at all times.
If selected carefully, the internal project manager and the software project manager become a cohesive and focused team unto themselves. It is important to understand that the client’s project manager is the one resource in the company whose day to day work may need to be reexamined so that the appropriate amount of time can be allocated to the success of the project. Any less than 50% allocation to the project is likely going to create downstream pain.
Yes I know it’s really a difficult proposition to assign an important resource to the implementation project for 20 or 30 hours a week. But the consequences of NOT allocating at that level can prove daunting.
So to avoid the pitfalls of under-allocating human resources be sure to discuss this aspect of any project with your provider early (starting before you sign on the dotted line) and often.
Next chapter we’ll spend time discussing two key areas of “buy in”. One is executive sponsorship and the other user/stakeholder vision and commitment.