THE 6000 RULE

THE 6000 RULE

"The "6" means "6 months": implementation projects should be divided into
rapid incremental projects no more than six months in duration, each. Team
should start planning next phase during current phase. Well, the Six
Thousand Rule is something I've developed over time. The first part is the
six month project. I think it's really critical, once again, that you split
a project into small pieces, and get things done, get the results, get the
benefits from it, and see what you're doing. So these projects that are
mammoth projects that people get done in what we call "big bang" are rare.

[Note from Ahmad Syamil: Hershey Food, Whirlpool, etc. used "big bang" ERP
implementation approach and suffered greatly.
Hershey attempted to do too much at once. Installing SAP R/3 software is
complicated enough. Hershey wanted to install SAP R/3, customer-relations
management (CRM) program from Siebel Systems, and a supply chain management
(SCM) package from Manugistics all at the same time.

The first "0" means "0 interfaces": new software packages should have zero
interfaces to previously installed, legacy code because developing such
interfaces is prohibitively time and resource consuming. Studies showed that
2/3 of the time spent to implement package solution was due to interfaces.
Zero means zero. The old systems are not what you want to go to. They slow
you down, they hold you back. Team will sneak in simple interfaces later.

[Note from Ahmad Syamil: Dr. Landis, a noted consultant in ERP
implementation, also believes in "O" interfaces. He is a former APICS
president.
www.apics.org Old Name: The American Production and Inventory Control
Society. New Name: The Association of Operations Management - Advancing
Productivity, Innovation, and Competitive Success.]

The second "0" means "0 changes to code": developers should not make custom
alterations to code because the resulting code will be difficult to maintain
and upgrade. I went out one time with a package software that people sent me
to look at, and the company loved this package software. And I said, "Well,
what do you think of the new release?" And they basically said, "I love it,
but I can't use it." And I said, "Why can't you use the new release?" The
answer was, "We made so many changes to the code that my people would mutiny
if I asked them to mPOST http://www.blogger.com/post-create.do HTTP/1.0ake the same changes to the new one, test it, and then
implement it again." So we put a very strong case of-when I say zero, I mean
no changes to code.

The third "0" means "0 risk": software should be implemented incrementally,
beginning with a pilot, to prevent the software from putting the
organization's ability to function at risk. It's really important to me
that you don't hurt your company or your organization by implementing a new
system. We have ten billion dollars of orders in this environment. I don't
think I have the right to mess up ten billion dollars worth of HP's business
because I made a mistake in my systems implementation. And there's been
companies that have literally come close to bankruptcy because of a major
change. In this case, the concept of doing pilots and improving on them is
part of making sure that we don't make any big mistakes.

[Note from Ahmad Syamil: FoxMeyer, the fifth largest drug distributor in the
U.S., literally went out of business/bankrupt after spending more than $100
million on a failed ERP SAP R/3 implementation. FoxMeyer blamed SAP and
Andersen Consulting who oversold SAP R/3].

In the same interview with Schmickrath, the 6000 rule is contrasted to the
"Big Bang" approach to package implementation. A big bang project would be a
multi-year project implementing a major software implementation
simultaneously across much or all of a large organization. Schmickrath
states the big bang projects are very risky and usually unsuccessful."

Source: Management Information System (MIS) lecture note from Stanford
University.