The Othello Effect : Analyzing ERP Scope Creep

By Posted September 11th, 2012

The purpose of this blog post is to get you to think about ERP implementation project scope and the massive decisions that take place on choosing what functionality to put in. Most people would relate to this process as a simple punch list of items to accomplish. But when you apply the math to the number of options you have in front of you – and the time that you spend on figuring out what to implement and in what order – you will come to find that the complexity is higher than what you may have thought.

The Othello Effect, as I call it, has to do with the Infinite Monkey Theorem. The theorem suggests that if you have an infinite number of monkeys randomly banging keys on a keyboard, they will eventually produce an exact copy of a work of Shakespeare, perhaps Othello. I’m going to simplify this and say that our project is simply to spell the word “Othello” and we can only use one monkey. The monkey will have 26 keys on a keyboard and we have to figure out the correct combination and timing to spell “Othello”. The monkey can use all the letters on the keyboard at any time and he must get them in the right order OTHELLO.

This process is much like planning an ERP implementation. An ERP application such as SAP has well more that 26 different parts that we can put in. We would love to put them in all at the same time, but the room for error is formidable. The more parts we attempt to put in at the same time, the greater our chances for failure. To assist in stopping scope creep on the project, we should set the standard of establishing a limited scope up-front to help carry that paradigm forward.

Lets show how complicated the decision making process can be using our monkey as an example. Let’s say we leave our monkey to his bidding, but instead of spelling Othello he has to pick the right 7 modules as opposed to letters at implementation and the correct order they get implemented. He’s got 26 different modules and features of SAP to choose from, so he can only put in 7 and the order at which he does it matters. Our poor monkey would have 8.03181017e+9 different permutations, where only 1 is the correct one. For most of us, including myself, that number is unfathomable. Now we all know with time and money anything is possible. However I’m sure our CFO has an idea about timing and money for our ERP project, so lets cut it down.

Of all the modules in SAP, take all but three or four off the table. It is okay to implement SAP slowly contrary to what your consultant may tell you. It may take a little longer, but depending on the size and knowledge of your company, it may be the right decision. We now are saying we are putting in four modules only. The math says we have four, so we choose four. Order matters and no repeats. That leaves us with 256 permutations of putting the system in. A SIGNIFICANTLY smaller window of error and a better chance that we get the right one on the first try. I can comprehend the number 256!

Of course there is very little chance to get the right combination of on the first try, but we are not monkeys. We are capable of rational thought, so we can adjust throughout the project to fix the mistakes or reorder things if we didn’t get our choices right the first time. We also typically have experience on our side. Although we have the ability to think, I would still prefer my chances of 256 choices then 8.03181017e+9

One last thought. We put this in the context of starting an ERP project and deciding what to put in, but think of the task list after your first project kick-off meeting. Say we kept it simple, applied our logic and decided to go small. As a project progresses, the scope will however creep. Sure we planned on only putting in the 4 modules, but as you learn more, you inevitably choose more features within the module to add. When this happens, think of our monkey. We were only talking about 26 different options where we had to choose 7. How many times have we been in a position where the numbers are significantly larger? I would say in every implementation, the client is asking for 50+ additional items and I only have time for 12.

Remember the monkey!