I have never worked an ERP gig. Let me share with you almost as much as I know about ERP, and it may explain why I haven’t.
I’ve never heard a first hand account of an ERP implementation that came in on time, under budget, and achieved its initial objectives.
I’ve never heard of an ERP system that wasn’t in some sort of transition. I only hear ERP discussed when people are either building it, migrating it, upgrading it, improving it, or replacing it.
I never hear how great they are, except in TV ads.
Maybe that’s why ERP companies need to advertise, because its difficult to find customer advocates of ERP.
Among technology people I know that have worked on ERP projects, it is the elephant in the room.
I have a feeling its a white elephant.
I would like to hear an ERP success story. One that lived up to its promises the business units were sold on.
Until then, whenever someone is pumping up anything ERP, I’m going to assume it has something to do with Early Retirement Planning.
Sarcasm aside, I’m not sure if this this a problem with ERP solutions specifically. Perhaps ERP is just a common target of derision that suffers problems symptomatic of greater IT project management issues that are uncovered in the complexity of an ERP implementation.
Three Rules of Innovation part 1
Continually successful Research, Development, and Implementation requires rules and processes, with business appropriate goals. But if I am pressed to choose which is most important, I would offer that the rules are most critical.
In the teams that I lead, you can ask the newest member and they can recite the rules. Why? Well, it’s not because I require recitation ability!
Its because we live by them. Anyone who contributes to our R&D projects is in a position to observe the day to day actions of the team and to judge its accomplishments. You can see the proof of adherence to the rules and interpret the R&D process in light of the rules.
So what are these rules?
1. Keep the Main Thing the Main Thing
I learned this rule from Jim Barksdale of FedEx and Netscape. Jim is a talented executive and frequently has great quotable sayings. Jim was pointing out that in the course of developing an “insanely great game changing” project or product, it is natural for other “insanely great game changing” things to rise. After all, it’s a new game in the new reality of the new project.
While simple in phrase, this rule can be applied to many applications. One manifestation of this rule is to not let a derivative goal eclipse the original goal. All too frequently, the derivative can take precedence over the main effort.
To prevent this pernicious effect as projects are developed, I usually deliver a historical review of “why we are, where we are.” The review sets the context for the meeting and reminds the team of the preceding developments to the current status in relation to the main thing. This review also helps keep the team focused on the main thing.
In future blog posts, we will revisit this rule. But to be brief, I want to introduce the other two rules for the next blog posts:
2. Little Steps for Little Feet.
3. Scope Creep Kills the Medic.
As a look to the latest patent filings – and what has my attention – check out it out