ERP package as a short-cut to bypass risks
On one hand, ERP projects are based on packaged software, so huge amount of risks usually related to IT systems build is avoided automatically. There is no risk of getting the package completed as it already is. Also ERP products have very precisely described requirements for hardware, operating systems, versions, utility software and so on, so project simply needs to follow these guidelines.
One can think that the software vendor has done all this preparation or ground work prior to customer project and its value is included in the software price. Also, as already said, the basic features are already ready - and even if new features are needed, they can simply use the same technology and tools as the main package. So technology risk is minimal.
In short, the technical type risks get minimised with the cost of getting unfit features to organisation, which may ruin the business or at least confuse it severely
Technology risk remains in best-of-breed approach
Unfortunately, all of the technology risk is not eliminated, though, as integrated systems (if ERP complemented/integrated to other systems) may have conflicting requirements. Of course each system can be isolated into its own environment to reduce these dependencies, but then you get the integration risks in return. To decrease the risks related to custom integrations then one needs to minimise the number of systems. This is in conflict with the idea of picking features with best-of-breed approach. One has to choose!
It is also a strong factor in favour of integrated ERP packages in general, as one package easily functionally replaces several older ones. This reduction is further multiplied by geography, as the physical sites usually share the same common global system. The non-ERP solutions used to be typically site (or country or product group or business) specific. Lots of cross-system integration, with related work to design, implement, run and support them, is avoided if these features are all in the same system. Which is kind of free lunch both cost and risk wise, as long as the features in the package are adequete.
Project scope as factor
One quite common note is that ERP system projects are usually much larger than typical other IT-system projects, which might focus only in certain narrower aspect, e.g. CAD-system, intranet pages or such. Firstly, the amount of processes included in scope is larger than in IT-projects generally, basically logically all those related to supply chain. Secondly, majority of the processes that ERP system covers are multi-functional (cross-organizational).
It may not be clear to all that scope drives both the risk and schedule exponentially! It may be possible to implement three ERP modules by three people in three months, giving you the efficiency or three months work per module. But then if you want to get six modules you could need six people for six months. So it will not increase linearly but at least relative to second power, in this example the six modules will cost six months per module.
If it is possible it would be way more efficient to break the project to several smaller ones, just to optimise the efficiency. It wouldn't even take more calendar time, as smaller projects take less time. The only problem is that there is some limit how much you can out-scope without destroying the integrated nature of the system. For instance there is no point running purchase and sales modules, without running the inventory module as well. Business cannot be run with "half system", it needs to include those modules that are needed! So scope is difficult topic and should be planned carefully for each ERP case.
Project schedule as a source of risk
A distinctive feature of ERP projects (or programs) is their lengthiness. Typical pilot implementation is several months to some years, and adding some rollouts easily at least doubles the time to 2 to 5 years. Rollout refers to the idea to implement the package to one organisational unit or physical location first, and after that take next unit/location and copy/paste (or roll it out) there. One could also rollout between business divisions. It is often estimated that if first pilot takes e.g. nine months to implement, then the rollout might only take 3-4 months, simply because there is so much repetition and copy/paste involved.
The enormous time needed by ERP project is considerably long compared with the pace of business done these days, hence the risk of major business discontinuity is relatively big. Mergers and acquisitions may happen, product lines or types launched or discontinued, plants shut down or new ones started etc.
Project team size as source of risks
This aspect is worsened if project team is kept minimal. It is common knowledge that the efficiency of project is basically higher the fewer people there are involved. Only maybe max ten people can work as an effective single team, after that adding new people will reduce the team cohesion and add management workload potentially more than those people will contribute. So running a big project with too simple setup includes a risk of getting stuck in the project, things simply fall out-of-hand at some point.
Larger than ten people projects are therefore usually organised by adding one hierarchy level. For instance by creating several smaller teams (each less than ten) and then a new higher level organizational unit consisting of these team leads steered by project manager. This will create silos within the project and information flows much slower and unreliable between the silos, and to counter that project then starts to follow strict administrative protocols, more formal meetings and communication etc. to keep things under control. But that is the only way to manage larger projects if the headcount is big. Risk is of course related to different people building conflicting features, as information is not flowing so efficiently. Or alternatively there is risk of losing time and work effort into secondary administrative tasks instead of getting the project forward.
Risk of choking the project
But if the project scope is large and team is kept relatively small for efficiency reasons, the schedule will get really long and hard to keep. It is bad for the project even of its own, but it will also increase the risk of major business continuity to happen during project execution time. The small team simply cannot push it through fast enough!
Sometimes this slowness is caught in the middle of project and people are getting pushed hard to keep the pace. This can lead either to people "cheating" so that they simply skip some important tasks (like testing) to keep managers happy and things in schedule. Or people burn-off, or ditch the project creating more issues to the project. In short, project gets choked: the manpower is simply not enough to run the thing any faster.
Summing it up
So the practical options for project management to tackle these large projects are:
keep the project scope as minimal as possible. Add the "bells and whistles" later. Apply this approach to the limit where it hurts!
use standard features as much as possible. Switch to enhanced version later. So to save time, only enhance initially the critical things, not the nice-to-haves
use max ten people to execute the project, to keep it efficient. But if this approach causes the project to last too long, (say more than year,) then:
accept the bigger project team and simply get it done with an "army" rather than "task force". So balance the schedule risk with money
or accept the long implementation time with the involved risks to keep the efficiency high
or split the bigger project to smaller parts. Even if it is not feasible to run business with "half system" you can still build such thing and call it proof-of-concept or pilot or company template or whatever, and use it as kick-starter for the real project. Doing two "half systems" in two projects gets cheaper than building the complete system in one go. That is, if you buy the idea that effort increases to the power of two with scope! And you should!
