Kai Vaughn

Before the exhibition

1. Draw up a list of objectives for visiting the exhibition. Define what you wish to achieve eg to get an overview of certain types of software, see the latest software functionality, or to meet certain vendors.

2. Plan your visit. Make a shortlist of exhibitors, vendor demonstrations, educational or other sessions you wish to see. Don’t consider spending all day in vendor software demonstrations - they may end up sounding and looking alike and you may end up being totally confused. Plan a balance of visiting stands, meeting vendors, discussing your requirements, as well as attending demonstrations.

3. Mark the locations of the stands / demonstrations you wish to see on an exhibition layout planner so you know your way around the exhibition floor and can save time / avoid getting lost when you are there.

4. Attending with colleagues can help to determine which software to investigate further. However, plan in advance who is attending, who shall see what and when. Aim to cover all items, with colleagues splitting up to cover different parts of the exhibition.

5. Determine how you will get to the exhibition - so that you arrive on time and are able to complete everything. If you are attending for more than one day and need overnight accommodation, book well in advance of the date(s) required.

At the exhibition

6. Follow your visit plan. Ensure you cover the areas you wish to see. Don’t get side-tracked once at the exhibition - you can use any time left over at the end to visit other stands which look interesting.

7. If attending with colleagues - use the opportunity to quickly obtain a large amount of information and to network / create new contacts for later use. Work the exhibition - don’t just stay together or treat as a day out of the office!

8. Take a copy of your outline system requirements* with you - to refer to and / or raise key points with vendors / exhibitors.

9. Take plenty of business cards - to hand out to exhibitors and to save filling in their forms with your details.

10. Take a pen and small note pad for jotting down key items, demonstration notes, points of interest, contacts etc.

11. Attending exhibitions can be tiring. They can be hot (particularly in poorly ventilated demonstration rooms) and you may do a lot of walking. Be prepared - wear comfortable clothing and take regular refreshments throughout the day.


After the exhibition

12. Review the information you have obtained and write up notes / ideas as applicable. Discuss with colleagues. Then determine which software vendors you wish to follow up on and investigate ...

Read the whole post...

There are many benefits of attending an accounting technology event - especially if you’re considering replacing your accounting software. These include:

• improving your knowledge of the accounting software market, the latest trends and what’s available
• checking out a software vendor’s latest offerings- in a low-key, informal way
• comparing multiple vendors quickly and efficiently, in just one day

And it would be even more beneficial if you had details of what you need from your new accounting system. Gathering requirements and preparing a spec doesn’t have to be hard - the Accounting Software RFI/RFP Template can help you quickly and easily gather your requirements and prepare a requirements specification (and also a RFI and RFP).

Clicking a link below, will take you to the event website, where you can obtain more details such as the expo or conference contents, who’s exhibiting, locations and whether it’s chargeable or free to attend.

Although every attempt has been made to make the above calendar as accurate as possible, this cannot be guaranteed. For more details, contact the promoters directly.

You’ve finally got board approval to select a new software system - then what? You’ve actually got to do it! So, here is a quick ‘project initiation checklist’ of 30 things to consider at this stage. If you can tick everything ‘yes’ - you’re ready to start!

Project Initiation Checklist

What is the software / system selection project?

1. Has the project proposal been approved by the board without any changes to the proposal? Or if the board has made changes, can you manage these?
2. Has sufficient funding been approved for the software selection phase?
3. Are the project objectives still the same as within the proposal?
4. Is the project scope (inclusions and exclusions), still the same as within the proposal?
5. Are the project deliverables still the same as within the proposal?
6. Have deliverables been defined for each stage within the software selection?
7. Have acceptance criteria been defined for each deliverable?
When will the project be undertaken?
8. Have the start and completion dates been defined and agreed?
9. Have dates for the key deliverables within the project been defined and agreed?

Who is involved with the project?

10. Provide names for:
- project sponsor:
- project manager:
- project team:
- key users:
- user management (who are responsible for signing off the requirements and accepting the system selection deliverables):
11. Have all the roles and responsibilities been defined?
12. Have all the roles and responsibilities been communicated?
13. Do all resources (involved) have sufficient time available for the project?
14. Is project resourcing sufficient?
15. Do all resources have sufficient knowledge / skills to undertake their part in the project?
16. Have you prepared and issued a project organisational chart?
17. Does everyone understand their role within the project?

How will the project be carried out?

18. Have you determined your project management / system selection methodology?
19. Have you prepared a revised (or final) project plan / gantt chart?
20. Are the responsibilities, milestones and deliverables clear?
21. Has this been issued and discussed with all involved?
22. Does everyone understand it?
23. Have you purchased tools to help you document your business requirements / select your new system? eg Axia’s System Requirements & RFI/RFP Templates
24. Have you set up project communications? eg planned regular (weekly) project meetings, defined an email list of other people to be kept informed?
25. Have you set up an issues escalation process?
26. Have you set up project monitoring? eg using a project management tool
27. Have you defined quality standards and specified ...

Read the whole post...

One solution is to identify the total cost of ownership, not just the software, as clearly as you can prior to acquisition. If you establish and compare the total costs associated with each software package for 1 year and 5 years from the date of acquisition, you will have a much better idea of what to expect. Fairly obviously, a low cost for software does not necessarily mean that it is the best overall value.

Another solution is to look out for potential hidden costs and either include them or a contingency, and then manage them as best as possible at the time they occur. To help, here is a (not exhaustive) list of such potential hidden costs:

The software application licence - the modules you really need, rather than what you would like to have (or be talked into), what the prices are based on - number of concurrent system users, number of employees or records (eg for Human Resources Software), number of transactions or a mix of these? What are the different price bands? How it will work out for your organisation?

Training costs – number of days and day rate. What is the typical amount of training required for the average customer and specifically, what would be required for your organisation? What is the cost of setting up a training facility on your site? Or to use the vendor’s facilities?

Vendor support services fees eg for interface development, report writing, implementation consultancy assistance. Other support services eg contractors, temporary staff (plus their agency fees) to assist with the implementation. Annual licence fees – are these charged? And if so are they on top of, or instead of annual maintenance charges?

It starts with the software vendor’s additional costs (after all they are in business to make money) and carries on throughout the implementation.

One solution is to identify the total cost of ownership, not just the software, as clearly as you can prior to acquisition. If you establish and compare the total costs associated with each software package for 1 year and 5 years from the date of acquisition, you will have a much better idea of what to expect. Fairly obviously, a low cost for software does not necessarily mean that it is the best overall value.

Another solution is to look out for potential hidden costs and either include them or a contingency, and then manage them as best as possible at the time they occur. To help, here is a (not exhaustive) list of such potential hidden costs:

The software application licence - the modules you really need, rather than what you would like to have (or be talked into), what the prices are based on - number of concurrent system users, number of employees or records (eg for Human Resources Software), number of transactions or a mix of these? What are the different price bands? How it will work out for your organisation?

Training costs – number of days and day rate. What is the typical amount of training required for the average customer and specifically, what would be required for your organisation? What is the cost of setting up a training facility on your site? Or to use the vendor’s facilities?