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.

mm
Written By Peter R Hill

Peter has been in the Information Services industry for more than forty years with broad experience covering a number of industries working in both Australia and New Zealand. He holds an MBA from LaTrobe University. For seventeen years Peter headed and was a director of the International Software Benchmarking Standards Group (ISBSG) a not-for-profit organisation with a mission of improving the performance of IT through the provision of project history data. He has served on a number of Boards of IT companies. In 2010 Peter became an non-executive director of Fenwick Software. Peter has been a speaker at conferences in Australia, Asia, Europe, Brazil and the USA.   He has had a number of articles published, covering key aspects of the Information Services industry.  He is a past Chairman, Secretary and Fellow of the Australian Computer Society. He is a member of the Committee of Management of Writers Victoria. Peter has compiled and edited five books, including: "Practical Software Project Estimation"  published by McGraw-Hill. In his leisure time, Peter enjoys motor sport and writing.

Leave a Reply

Your email address will not be published. Required fields are marked *

Thanks!

We're here to help!

Call us

03 9695 3333

Or, leave us a message