Posted by Joe Taylor on Tue, Apr 21, 2009
In my last post I discussed the difference between successful ERP system implementations and those not so successful, and the impact the client's project manager (who I call the "System Administrator" in my Seven Elements in a Successful System).
Here's a definition of the various characteristics I've seen in people who were assigned this position and the typical results achieved in the projects. I've graded them from A (the best) to F (the total failures).
A - Amazing Achiever
This is the best kind of project manager. This person loves to achieve and can't wait to sink her teeth in the project. A client with an Amazing Achiever will save thousands of dollars in consulting fees because the project will be done - and amazingly successful - in record time.
B - Bullish Believer
This optimist bull-in-a-china-shop will get it done, even if it kills him and the others on the project. It might not be pretty, and some of it might need to be re-done, but at the end, the job is done, and the system works.
C - Challenging Compromiser
This person challenges every suggestion, from the sequence of the tasks to the make-up of the team, from the implementation time line to the selection of the software itself. These projects get done, but only after blowing up the budget due to delays and mistakes, and this person will blame everybody but herself.
D - Demanding Do-Nothing
This guy is a project killer. He totally avoids personal responsibility for the project - loves to point out "that's the reason I hired you." He has never been involved with this type of project before, but he was born with the talent and knowledge to do it better than anyone else ever did. These projects usually don't get finished at all - at least not until the Demanding Do-Nothing is replaced.
F - Fact-less Fabricator
This character is the worst of all. This guy loudly and forcefully tells everybody what to do during the project, blames others when something doesn't work, and files a lawsuit when everybody finally quits. Always an owner, otherwise he'd be fired early on. These projects are total failures.
Now wasn't that fun? You've met these people, haven't you? Help me come up with more alliterative characters you've met during software implementation projects. Which are you? Or if you're not in that position, which character is your company's system administrator?
Posted by Joe Taylor on Wed, Apr 15, 2009
I have been doing ERP system implementations for 35 years, and I'm still discovering new variations that can significantly affect a project's success. Early in my career, I wrote a paper called the "Seven Elements in a Successful Computer System." It is still a relevant paper today, but with all kinds of variations.
The most important element in the system is still what I call the "System Administrator" or the person who is responsible for and committed to the success of the project. Without a dedicated and competent project manager working for the client, the project has virtually no possibility of success.
Over the years I've taken a different approach to the element of "Training and Implementation Support." I've changed the word "Training" to "Learning" to emphasize where the bulk of the responsibility resides. It's like a college class - out of a class of 30 will be 5 or 6 kids that will earn an "A," 4 or 5 who will earn an "F" and some in between. But the "trainer" is the same person for all of them. So I like to focus on providing an environment in which client personnel can readily learn and make it clear that it's their responsibility to do so.
A third element is the dramatic difference between a "fixed price" implementation project and one priced by the hour. In a fixed price implementation, the client team often has insufficient motivation to take the necessary responsibility for the success of the project. And the owner, unless s/he is deeply involved in the project, often doesn't care or even want to hear about it. S/he just wants the project done, done right, on time and on budget. No chance. In these situations, the client will never end up happy.
But the hardest part is determining before the project begins whether the "client system administrator" will be effective. It's not enough that the client has a Controller - in the early years that was our primary determining factor. The key is the acceptance of responsibility by a competent client project manager - in the terminology of scrum software development methodology, a "pig" - a person committed to the success of the project and competent to do the work. (As with a bacon-and-egg breakfast, a "chicken" is "involved" in the project, but a pig is committed.) This structure and concept can be made clear before the project begins and everyone can agree on it, but how can his/her level of competence and commitment be pre-determined? It's not easy, that much I've learned.
What's your experience? Have you known pigs and chickens in your company? How can a pig's competence and commitment be measured before the project begins?