Manage the project to fit your timescales rather than the re-sellers.
Most re-sellers have multiple projects running at the same time,
consequently their projects are competing with each other for resources.
It is important that a regular dialog is maintained with the re-seller's
project manager to ensure your project is reflecting your time lines.
Do not purchase modules in the software package that
you are not going to use immediately, if they are needed they can
be bought later. You will be too busy familiarising yourself with
the basic package at the start and not have time for learning any
Review the situation again after 6 months after all the systems
have bedded down and everyone is comfortable working with the package,
to see if these specialist modules would be beneficial to the business.
You must make time for your employees to learn how
to use any specialist modules, or you will not be maximising the value
of your investment. All modules will have a support contract attached
and any you don't use or use ineffectively will be a waste of money.
We have seen too many software investments fail by organisations
not allocating enough time for a package to be completely understood,
don't make this mistake.
Try and resist purchasing bespoke changes to the software from
day one. Many organisations once a software solution has been purchased
have a tendency to want it to reflect their working practices, or
alternatively the working practices dictated by the previous software.
We can help you examine your processes to see if they can be easily
changed to reflect the new software, the package will most likely
do what you require, but in a different way. We would recommend
using the system for 3 months and if a particular business process
is still causing a problem then investigate whether a bespoke change
It is worth noting that bespoke changes nearly always impact the
release of a new version of the software. Quite often the changes
will have to be reflected onto the new version. Taken overall, keep
these customisations to an absolute minimum, they can be a version
upgrade headache you can do without.
Involve your employees on the progress of the implementation,
canvass their opinions, identify business process inefficiencies and
see if there are ways the new software can resolve them.
If people are felt to be part of the implementation process, they
will work towards its success, and it will be a success!
Here are two real life examples of software solution implementations,
one good and one bad.
Bad - A solution was purchased and all operators were given training,
there was no consultation with them regarding how their business
processes they were responsible for, would be handled by the new
package or how any processes could be improved. After 'Go Live'
they continuously gave reasons why the software was no good, change
is bad thing when forced on people, in addition everyone likes a
good communal moan and this was it.
Good - Same system, same set of operators. They spent a lot of
time each month producing reports to their line manager, and a new
set of automated reports were being proposed. This time they were
asked opinions when the data could be retrieved, how its accuracy
could be improved. Change is now a good thing because they were
part of the decision process, if the project fails it reflects badly
on them also. As a consequence they were very pro-active in putting
forward solutions and made it a success. This time they had to have
a communal moan about something else !
Training for the new software should start early on and be a continuous
process throughout the implementation, gaining in detail as the
'Go Live' date approaches.
Once the software has been purchased give your employees who will
be using the new system (targeted at each operative work group)
an overview of what it is going to achieve and also what their functions
Give monthly updates on how the implementation is going, both good
A month before the 'Go Live' date, give details on how they will
perform their tasks within the new software. Use data from any
practice data take on's that have been completed, to make your
training as real as possible.
Two weeks and also one week before the 'Go Live' date, detailed
training should take place on how to perform their specific functions
on the new system.
The take on of data for a new software solution
(populating the new database with for example, customer information),
is one of the most underestimated tasks regarding time. Whatever your
re-seller allocates for this task in reality it will probably take
twice as long.
At mooooch we have accumulated a lot of knowledge in this field
and we never underestimate the complexity of a data take on exercise.
We understand what tools will be used and how to use them and would
encourage the re-seller to start the data take on well in advance
of the 'Go Live' date.
Depending on the type and volume of data, it may be quicker in
the long run to key the initial data directly into the new software
package, so take a view on each type of data. Run some time trials
on how long it takes to key in say 10 items. However, beware keying
the data will almost certainly have input errors, so include some
time for validating your data in your time trials.
Whether your data has been transferred manually or electronically,
you will need some quantitive way of measuring and/or reporting
that the data has transferred from your old system to the new correctly.
In the case of financial ledgers this is a relative simple task
(eg for a sales ledger sum the total debt), however for other data
it will most likely be reports.
Ensure you have these reports written and tested at least a month
before your 'Go Live' date