Project Pitfalls

Issues That Derail Many Business Systems Projects

Brand Purchasing

Don’t choose business software by brand-name! Your business is different to every other business; each software package is different to every other one. Take time to select the most valid combination; you’re spending a lot of money and you’re going to live with the result for a long time. If you don’t have relevant experience then buy-in assistance, preferably from a neutral source. Advertisements mean very little in the business software market.

Insufficient Staff Availability

Organisations rarely budget for sufficient internal staff time, and the project time that is budgeted is often diverted for other purposes. Don’t compromise on input. Consider bringing in contract staff for routine work and allowing your permanent team a chance to focus on your new, business-critical system. If you can manage an implementation with your existing level of resourcing then you’re probably over-staffed!

Inappropriate Expertise

Make sure you have the right experts. You want people who have worked on implementations, not just run a software package. Someone classed as an expert user is most unlikely to be able to build a new system; a spreadsheet-whizz will almost certainly struggle with data migration. Be very clear as to the skills needed.

Lack of User Consultation

Consult end-users early and often. They will know for certain what’s wrong with the old system and probably understand a lot of what’s needed to make the new one a success. If they aren’t kept involved from the beginning then the shock of the new system will hit very heavily indeed and, however good your new implementation, it will be months before the benefits are fully recognised.

Lack of Business Process Definition

If you haven’t decided what you want the system to do then how are you going to task anyone to set it up? How can you even choose a software package? Begin with a clear statement of requirements specific to your business, particularly of the processes that are unique to you. Time spent here will be recouped many times over within the project life-cycle.

Undefined Reporting Needs

Management and statutory reports will be key outputs from most systems. If you haven’t defined these ahead of the system design then you risk expensive re-work when demands subsequently arise. It is common for report design to be left to a late even post-go-live phase.

Unplanned Data Cleansing

Over time most systems build up a residue of redundant or incorrect records – both reference data and transaction history. If you are migrating data then plan properly for review and cleansing, or you’ll move all of the problems into the new system.

Weak Integration

Be both dogmatic and pragmatic over integration. Where business benefits are concrete and significant accept no compromises. However, don’t let your database guru talk you into integrating systems for the sake of it. Building integration is always messier than anticipated.

Poor Acceptance Processes

There are many ways of messing up acceptance. Define the process from the start of the project, with a clear statement of acceptance standards and criteria, and then make sure testing is carried out comprehensively. Don’t let the installation team persuade you to base acceptance on their technical design document! Only accept the system when you are confident it provides what you asked for.

Inadequate Testing

Test all system outputs formally, document failures clearly, and then re-work and re-test until the result is acceptable. Easily stated and understood, but surprisingly, rarely done!