Organising software demonstrations

Software demonstrations can be very impressive, by focusing on the software's strengths and glossing over weaknesses. Beware losing sight of the basics. Will the software actually handle your type of business and its core needs?

It's therefore important to:

1. Have a clear summary of requirements
2. Organise and control the meeting to see how well the software covers those core needs, and flush out any key weaknesses

Essentials

Whether you are changing systems, or trying to make better use of existing systems, it helps to have:

1. Senior management commitment and support
2. A clear vision of scope, benefits and requirements in a "User Requirements Specification"
3. Suitable software and support
4. Implementation experience

These and other key factors are detailed below.

Testing Testing

Custom-written software obviously needs to be tested. But what's needed for software packages?

It's easy to assume that a package will have been thoroughly tested. Sadly it is rare for packaged software to be bug-free for three main reasons:

1. It will be unlikely that the software will have been tested with your specific set of systems parameters.
2. For new versions of software, authors are dependent on end-user "beta" sites that are prepared to test software before general release. The extent and depth of testing is dependent on the organisations involved, and restricted by the time they have available.
3. Not all identified bugs will have been fixed. Are any significant to your business?

Examples of bugs that I've seen go live include:

• Payment generation routine that didn't work. Cheques had to be raised by hand, and the delay meant some supplies were put on stop.
• System set-up problem that resulted in changes being lost. Training sessions became farcical.

Therefore testing of at least the key functions is worthwhile. This also provides the opportunity to develop and test the associated manual procedures. Are instructions clear, concise and complete? Printing can be a problem - does it work as expected?

By collecting representative transactions during production of the User Requirements Specification, the suitability of the software to cover the range of business can be checked. This should include checking if and how to make changes, for example if a customer order has to be changed or corrected.

A testing plan that includes each process, such as product set-up and credit note production, helps to ensure the system will be fit for purpose once implemented.

Why prepare a URS?

Are you adding to a system, upgrading a system, or completely changing it?

The "User Requirements Specification" (URS) is a powerful document that can be used to:

• Set a vision for the system and the benefits anticipated
• Clarify scope and boundaries, and interactions with other systems
• Agree requirements between departments
• Assess software and suppliers, often as part of a tender document of some kind
• Ensure software demonstrations cover what's important
• Avoid risk of inappropriate purchases (and they do otherwise happen!)
• Steer implementation to achieve the benefits

It's common for key issues to be highlighted by preparing a URS, that would not otherwise have become apparent until too late.

Depending on the scope of the system, the document can be very short, or somewhat longer. It's a matter of being concise, but with sufficient detail to achieve its purpose. Aspects to cover include, inter alia:

• Business background and future
• Objectives and benefits
• Systems context, architecture and interactions
• Management information
• Functional requirements, highlighting core aspects and what may be different
• Transaction examples
• Sizing
• Existing systems, and any specific issues to address
• Technical preferences
• Supplier aspects

If you would like to discuss how to go about preparing a URS, do contact me.
Chris Challis
challisc @ camwells.co.uk
+44(0)1628 632914

Key Factors for Success

Are you adding to a system, upgrading a system or completely changing it? There are some key factors that are crucial for success.

Most factors apply equally to packaged and custom-written systems:

1. SENIOR MANAGEMENT SUPPORT AND COMMITMENT

There will be times in the project when business priorities clash. It's important for senior management to make their commitment to the systems project clear, given the benefits to be gained and any problems the new system will overcome.

2. PROJECT PLANNING

Doing the right things in the right order at the right time is critical to success. Experience counts.

Where can quick wins be made? Should the project be phased? How?

When in the financial year should changes be made? When do staff have time? When would it be impossible?

3. USER REQUIREMENTS SPECIFICATION

The "User Requirements Specification" document acts as the cornerstone for discussions with prospective suppliers and to steer subsequent implementation. It can be incorporated into a "Request for Proposal" or "Invitation to Tender".

Key aspects include:

• Benefits anticipated
• The "big picture" vision and scope
• Management information
• Key processes, including communication with customers, suppliers and between departments
• Other functionality and system management issues
• Transaction examples for software demonstrations and testing
• Detail where important

The selection of a package requires less detail than for custom-written systems. But with packages, it's still important not to take too much for granted.

A formal sign-off procedure by relevant managers helps ensure commitment to the project and its scope.

4. SELECTION OF SOFTWARE AND SUPPLIER

Software requires support, during implementation and on an ongoing basis. The supplier is therefore as important as the software, be this the author and/or reseller. Factors include:

• Is the software used in your type of business?
• Is the software appropriate for current business size, with scope for growth?
• Does the supplier have experience of your size and type of business?
• What range of support services do they provide?
• Financial strength?

Software demonstrations will tend to highlight the software's strengths. It is critical to use the User Requirements Specification to uncover any important weaknesses .

5. USE A "SOFTWARE AS A SERVICE" SYSTEM?

Traditionally packaged software was licensed to be hosted by the end-user. Increasingly there is the option for hosting to be outsourced, with access via a web browser. Some software is only available on a hosted basis.

Hosted software is usually, but not necessarily, sold on a subscription basis - "Software as a Service" (SaaS). Payment is made monthly, quarterly or annually.

Whilst there are some clear attractions of a SaaS approach, it is not always practical. There are also some important drawbacks which have become apparent through experience, which the SaaS providers obviously do not highlight!

As the use of SaaS is a key strategic decision, it's worth making it with your eyes open.

6. IMPLEMENTATION MANAGEMENT

Implementation requires dedicated time and experience. Meeting deadlines is crucial. Missing a deadline can mean missing a window of opportunity in the financial year, and a substantial delay.

There are many aspects to successful implementation. Three to highlight:

(a) Actions need to be allocated to individual people. Over the course of a project there will be leavers and joiners. This all needs to be co-ordinated.

(b) Any external organisations involved in the project need to be actively managed. Availability of their personnel can be critical.

(c) All software needs to be tested. Packaged software may not have been used in your configuration, and is rarely bug free. It's important to run through all key processes.

7. TRAINING

Software is only as good as it is used. In the case of packaged software, it is also only as good as it is configured.

Software is usually sold as "easy to use". So is a car easy to drive once you've got the hang of it - but this takes tuition, time and experience.

Training of end-users and one or more "super users" is therefore vital for success.

8. STANDING DATA MANAGEMENT

Systems all require standing data to function correctly, such as:

• Chart of accounts and analysis codes
• Customers and suppliers
• Product and/or project details
• User roles and access rights

If administration of these aspects is not addressed adequately, the system will fail to perform as expected.

9. BACKUP AND DISASTER RECOVERY

Financial systems tend to be mission critical. It is vital that backup and recovery arrangements, including disasters such as fire and flood, are adequately addressed. This includes periodic testing.

10. POST-IMPLEMENTATION REVIEW

Often overlooked, a post-implementation review is important to establish that anticipated benefits have been achieved, or what is still required to achieve them.

It also allows the experiences to be captured to aid future projects.

IN CONCLUSION

There are some key factors for success when changing financial systems. Overlooking any one of these can result in anticipated benefits not being achieved, or the systems failing completely.

If you would like to discuss any of these aspects with me, do contact me.

Chris Challis

challisc @ camwells.co.uk

+44(0)1628 632914