Eat an elephantHow do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records. Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report. One way or the other.

ERP software is huge. It contains thousands of features potentially touching every single tiniest aspect of your business. Implementing ERP is about introducing change into your company, and change can be evolutionary, or revolutionary. Your pick.

The biggest pitfall of the waterfall model is that the longer it takes to cascade all the way downstream, the less chances of delivering valuable results. Why? Because of the change. The change is cranky. It doesn’t wait for your implementation to complete. It happens on its own. Market changes. People come and go. Business grows. Goals and priorities shift.

Deep into the project, change can cause total panic. As the deadline approaches, and budget is drained, tradeoffs are made in response to legitimate change requests. Late change requests raise difficult issues: if you don’t have enough time, or money, or both, to address them properly, you can ignore them and risk failure, or you can trade off. Neither results in anticipated value. The bigger the elephant, the riskier it all gets.

Furthermore, big bang deployment of whole ERP at once may have detrimental effect on morale and productivity. Users can get overwhelmed with the new solution, new user interface, new logic and new features; it may take a long time for them to come to terms with the ERP, causing lost productivity and more errors.

So, instead of trying to make a perfect solution for finances, sales, purchases, warehouse, manufacturing, service, human resources, project management, payroll, distribution, plant maintenance, with all industry specifics, all at once, you go step by step. You start by deploying financial management. Then you deploy sales. Then you deploy purchases. You get the gist.

Gradual doesn’t mean you need to deploy whole departments. You can narrow down your function focus as much as you want. You can deploy sales orders before you deploy ATP or CTP; you can deploy production orders before you deploy MRP or MPS.

Deploying gradually, department by department, or function by function, you allow your customer to gradually understand and master the principles of the solution.

ERP implementations usually define measurable goals: productivity increase, overhead decrease, higher inventory turnover, less inventory time, better insight into cost structure and whatnot. If you wait for big bang deployment, you also wait for your goals to start realizing. As achieved goals translate into earned value, the longer you wait to achieve the goals, the longer you wait for value to realize.

Gradual deployments have an overwhelming benefit: they start generating value quickly. As soon as you deploy a function, if it was properly aligned with a project goal, it starts generating value for you immediately. If you deploy 10 functions over 10-months period (a function a month), then by the time all of them are in production, you have 45 months of accumulated generated value. No matter how little value these functions generate individually, it is infinitely larger than zero, which is how much value is generated by a big-bang ERP before it goes live.

This approach isn’t without problems, though. The more distinctly you address the functions, the more temporary integration you have to build. Naturally, it costs money. But it shouldn’t scare you away. You need to take these integrations carefully into account, and handle them properly. Even though they cost, this can be significantly lower than the benefit you gain. And sometimes, the integration might be skipped altogether as you rearrange the process not to rely on the integration. I’ll talk more about integration in the last article of the agile series (scheduled for Saturday).

Tomorrow, with the next article, I focus on value, and value alone, and I’m looking forward to seeing you around. Meanwhile, please share your thoughts!

P.S. I expected my agile series to ignite discussion, but I didn’t anticipate it to spread to other blogs. Mark Polino at has contributed a couple of valuable ideas to the whole agile theory (and his ideas seem to have strong foundation in practice). Thanks, Mark!

Read this post at its original location at, or visit the original blog at