First, let’s consider two general properties of large scale, coordinated work:
- When a complex effort is split up, it’s no longer obvious in which piece any given task or concern should reside; it is normal for people to focus (focus is good, yes?), and to decide that, because we’re now focusing on something else, the concern that Charlie just brought up should be addressed elsewhere; but we can’t perform this evasion when there’s nowhere else to ship it off to.
To ignore any really difficult matter, however critical, all we need is even the provisional name of some other place to worry about it: but we’ll stop here, because this is beginning to sound like a web site 2.0 issue, isn’t it?
- In any complex effort, deferring the resolution of uncertainty from earlier to later phases of work will generally add cost and duration. It will do this for well known reasons that mostly relate to the question of “how much work do we have to do over when we finally realize that we have to change direction?”
Well, then:
- Any part of the whole ERP implementation effort that can be done early in the acquisition phase should be done early in the acquisition phase.
- But it won’t be if it’s already been relegated to a completely separate, subsequent project, will it?
Stand-alone acquisition projects often exclude activities that really should happen before any contracts are signed, usually by deferring them to the implementation phase. Stand-alone implementation projects often start before essential terms of reference have been established.
Both these general evils come with many ill effects, but there is one that repeated time and again. A company diligently pursues an ERP acquisition. The selected vendor successfully acquires an understanding of the requirements and demonstrates, by means of a successful proof of concept event, its grasp of the requirements, its product’s fitness to fulfill them and its own abilities to configure the product. Contracts are signed and the implementation phase begins: but, somehow, the hard-earned agreements and knowledge acquired in the presale simply fade away. The implementation team fails to build upon the success of the presale proof of concept; often, indeed, it fails even to remember what was agreed or how that agreement was demonstrated. What went wrong was not what occurred in the presale phase: it’s what didn’t occur, which should have been a detailed, contractually enforceable plan of transition from acquisition to implementation.
We should address something here: we are often told that time is the enemy of any project, and for this reason many short projects are better than fewer long ones. This can be true, in more than one sense, but it is not a reason for separating ERP acquisition and implementation activities.
- We are discussing the entire effort involved in acquiring and implementing a new ERP system. If we split it into separate acquisition and implementation projects,
- In what way could the elapsed time of the entire effort be shortened?
- In what sense could the acquisition phase be deemed successful if the implementation phase fails?
- Time most threatens project success where work drags on without apparent results. One way to prevent that is to split up long projects, but well planned, publicly celebrated periodic milestones work every bit as well.
Finally, two last thoughts:
First, if you must fail, fail as quickly as possible. This is no less unpleasant than failing after months of false hopes, but it is a whole lot cheaper. So bring the hard work and the hard risks to the forefront and either learn the hard lessons as cheaply as possible or coast home to victory.
Second, whatever it costs and however long it takes to successfully acquire and implement a new ERP system in a single, coordinated project, after-the-fact review will never show that it could have been done more quickly, less expensively or with less disruption to operations if the effort had been split into multiple projects.
