New announcement. Learn more

TAGS

Why software projects fail...

5 things to keep in mind before delving into a new software project and reasons a software project may fail…

1.      Groundwork

2.      Beware the salesperson

3.      Onboarding vs implementation

4.      Data

5.      Dedicated person or team – test test test

Before you embark on a new software project, do the groundwork, don’t rush the planning, information gathering, and research phase, this is critical.

I see a lot of disappointment and even projects failing when this phase is rushed, this can happen when an organisation is in a panic state because they have left it too late to put a new system in place and they just want it installed now, to magically solve all their problems.
Or it can be caused by lack of people resources to do this groundwork.

It is super important to map your processes, my recommendation would be, do this even before you write the Request for Quote (RFQ), it will give you a really good understanding of your requirements and then your requirements will be in black and white for potential software companies and developers.

Skipping process mapping can cause future issues. This is what I often see, there is a high level understanding of your processes relayed  to the software provider’s sales team, however, when delivery of the system is underway, you may strike variations to your standard processes and suddenly the system you have chosen will not do what you need it to do or you end up paying for extra customisations that you hadn’t budgeted for.

If you don’t have your processes mapped and don’t have the capacity in house to carry this out, there are various consultants out there who can do this for you.

Process mapping can also be a great opportunity to look at your processes and challenge the status quo, is that still the best way to carry out a particular process? Could it be done better, faster or different? Is it some crazy process you have developed because of your substandard existing systems? Can it be changed to align with best practise?

Once the RFQ is released, spend a good amount of time with each of the respondents to ensure they are offering what will actually work for you, not just trying to make a sale.

Salespeople in the software space work on heavy commissions and the industry is highly competitive, I have spoken to many companies who have been disappointed because salespeople have made promises that the delivery team can’t keep.

Often people will ask for referees to check that a software provider can deliver what they say they can, but like a job referee, beware, because no one will offer up a bad reference. 

An alternate or additional approach is to engage a functional consultant to participate in the sales process, a functional consultant is responsible for delivering the solution that the sales team sell. A functional consultant will have a better understanding about what is possible with a systems standard functionality, what might be custom and an additional cost.

Demo, demo, demo, look at as many systems as you can, and throw all your scenarios at the software companies, you should have all your scenarios to hand because of the process mapping that you will have already completed, the software company should have already seen these prior to demo as well, which will make the demo's more tailored and relevant.

Read the proposals carefully, make sure you understand what you are getting, is everything you need in the proposal, understand the gaps. Gaps are features that are custom to you and that are not covered under standard functionality, gaps are an additional cost and are generally scoped separately, but if you have process mapped, this scoping is already completed for the developers to provide estimates for the work to be carried out. So, bonus, you should get these cost estimates up front.

Another thing to keep in mind, understand the difference between onboarding and implementation in a proposal and when comparing software systems.

Onboarding is a guided install, a software provider will walk you through installing and setting up your own software, because of this, onboarding is a cheaper approach. If there is any complexity to your install, I wouldn’t recommend this approach.

Implementation is a project managed approach, led by the software provider, they will manage provisioning your new software, setting up the modules, doing the data migration, doing the initial testing of standard workflows, training and wrap support around you for the implementation period.

Before embarking on a software project, ensure you have the resource in house to make the project a success. This is SUPER important!

This team or person will be responsible for driving the project, they will be the key contact for the software company, and they will be responsible for things like extracting the data from your old systems and ensuring it is clean, tidy and makes sense before importing it into your shiny new system. 

The golden rule is garbage in = garbage out! Don’t clutter your beautiful new system with rubbish.

Don’t drag anything into your new system that is old, obsolete or doesn’t make sense anymore. Take the opportunity to assess your data and revise it. Is it an opportunity to create a new coding methodology or perhaps to standardise your item codes or chart of accounts...?

A software provider will not clean your data for you, well they shouldn’t, it's your data, no one else should mess with it except you, because you understand it, you don’t want someone making assumptions on your behalf. You need to do this work.

The last thing and one of the most critical – test, test, test, and test again. I cannot stress this enough, lots of software projects fall over because organisations skip over the User Acceptance Testing (UAT) and they send their new system live only to discover, the system actually doesn’t do what they want it to do, they then blame the software provider, but this is not the software provider’s fault.  

The software provider will test standard processes, it is your responsibility to test your specific processes and scenarios to ensure the system will work for you the way you expect.

During UAT, this is your opportunity to ask questions and have the software company make some tweaks if needed.

If you have any questions about this article, feel free to get in touch!