Over the forty years that Fenwick Software has been implementing systems, the same factors appear and re-appear as risks to an implementation project. Some are client risks and some are implementation risks. Now that packaged software are the preferred choice, the system software risks are diminished, normally limited to any requested enhancements.
So, what are the predictable risks that we regularly encounter?
- Requirements not completely defined or captured or stable
- Overstretched client resources resulting in inability to complete required tasks satisfactorily or on time
- A myriad of modification/enhancement requests
- Complex interfaces to other systems
- Significant data conversion requirements
- Inadequate preparation for testing and inadequate testing
The same factors appear and re-appear as risks in Dynamics NAV implementation projects.
There are many other possible risks that should be considered in the project planning stage using a comprehensive Risk Assessment, but those listed above are the most relevant for the Microsoft Dynamics NAV projects that Fenwick Software manages.
Capturing all requirements at the beginning of a project is very difficult. One way to check that all requirements have been captured is to start defining test scenarios as soon as possible after the requirements document is completed. Any gaps should quickly come to light. Early pilot runs of parts of the system, presented to user subject matter experts, is an additional way of checking that requirements are being met. Time spent verifying the requirements, and time spent adequately testing that the requirements are being delivered, will result in a smooth go-live and avoid the disruption, high cost and stress that come with a poorly prepared go-live.
It is interesting to note the number of times that clients push for a very short (aggressive) timeframe for delivery. This is rarely a problem for Fenwick Software as we are dedicated to the project but the overworked client team can struggle, tasks are missed or delayed and, as a result, quality is compromised. By quality I mean the required level of testing, training and data preparation. A go-live can be rushed, which leads to high levels of post-implementation support as missed requirements are discovered, data needs to be fixed, and users need time-consuming and expensive hand-holding. Setting a realistic timeframe will deliver a less expensive implementation with less stressed employees.
Another way to minimise risk and lower the time and cost of an implementation project is to accept the software package as is. Look for ways to use the standard software rather than demanding changes to make it look like the system that is being replaced. Once users get over the initial reaction of “but we don’t do it that way” it is surprising how quickly they will adapt to the new way of doing something. We are all resistant to change but the cost and risk of making a new system look like an old one are too high.
There’s a very old quality adage about how additional time invested at the beginning of a project will avoid multiples of that time later in the implementation.
