Slide 1

Michael Mainelli and Ian Harris

[A version of this article originally appeared as "Software Observed", Charity World, Tolley Publications (Summer 1993) pages 20-21.]

 

Seven Paradoxes of Software Selection for Charities

 

There were seven wonders of the world and you've seen the Magnificent Seven. You may have committed one of the seven deadly sins, now read about the seven paradoxes of software selection for charities.

Paradox 1: Charities are unique, yet charities are not unique

Charities have special requirements of software that make them unique. There are many software houses (e.g. Dolphin. Minerva, Raiser's Edge, Donorbase, etc) that specialise in meeting the unique requirements. These include functions (e.g. covenants and legacies), reporting regulations (e.g. segregated reporting by restrictions in SORP 2) and taxation (e.g. partial exemption in VAT). Often charities have unusual volume requirements, with large volumes of transactions appearing at irregular intervals (e.g. seasonal appeals) sometimes of low value (e.g. thousands of individuals returning £5 cash and stubs for the charity raffle). 

Despite charities special and changing requirements, the market for charity specific software does not seem to be correspondingly dynamic. We took two samples of 15 products from the recently issued 1994 Software Users Year Book (only software users would demand their 1994 book in June 1993). The first sample was software advertised in the charity sector section, the second sample was general financial software from suppliers included in our current research on Mid Range Financial Systems. We took the date of the most recent software release advertised for each product and calculated the age of the current release in months. Table One below shows the statistics this simple test yields.

Table 1: Charity Software is Usually much Older than Financial Software 

STATISTIC

 

SOFTWARE AGE FINANCIAL SYSTEMS (MONTHS)

SOFTWARE AGE CHARITY SPECIFIC (MONTHS)

MINIMUM

1

2

MEAN

9

21

INTERQUARTILE RANGE (half the sample falls in this range)

3 to 15

 

9 to 25

 

MAXIMUM

20

84

Although the sample is small, we believe the results are significant. There may be several reasons for the age difference, but we think the most likely factor is that the market for specialist charity software seems to be decreasing. Often charities manage rather well with standard software products (e.g. accounting packages, databases, spreadsheets).

After all, most businesses need to cope with complex reporting requirements, seasonal fluctuations in the volume of transactions and fiddly but vital marketing databases. Perhaps charities functions are not so unique after all. In fact, specialist software may lock you in to ageing products. Far more important than the simplistic notion "we are a charity therefore we are different" is to understand the essential information needs and flows of your organisation. Strive to know yourself as an organisation and plan around that knowledge accordingly.

Paradox 2: Information technology plans should be visionary while being pragmatic

The initial stage of a systems project is usually given the grandiose title of IT Strategy. It is easy to gather a plethora of exciting IT opportunities. A flick through the computer press or a chat with a friend who works for a better endowed organisation will provide plenty of ideas. More difficult is the process of prioritising the wishes and needs.

Charities often have seemingly infinite calls on precious few resources. Once a sum has been earmarked for the systems project, the calls on that small sum also seem limitless. Consultation with staff responsible for all the main functions in the charity is imperative at this stage. In addition to building consensus and commitment to the computerisation project, this IT strategy process should help the charity to produce a specification of requirements. Information needs and flows form the core of the outline requirements. Further, once priorities amongst the diverse calls for resources are agreed, the process of selecting systems is much easier. The need for a pragmatic approach is especially great in charities. A pragmatic approach requires you to know your direction.

Paradox 3: Charities should utilise voluntary help but remember the commercial importance of the project

Charities often lack some of the skills required to plan, select and implement a systems solution. However, charities are more likely than commercial businesses to be offered voluntary help with the project. The help may be in the form of goods, services or both. This help may be manna from heaven or a poisoned chalice. The table below raises some of the issues charities should question when considering accepting the types of voluntary help that are commonly offered.

Table 2: A sample of issues to consider about voluntary help 

TYPES OF HELP

SOME ISSUES

COMMENT

 

General

 

conflict of interest, market value, restricted choice, maintenance

 

take care if the donor or advisor has a vested interest in the solution (e.g. free consultancy from a software supplier) understand the market value of the gift and its significance to the overall solution beware gifts that restrict your choice of other aspects of the solution (e.g. of hardware and software) only accept gifts of hardware and software that can be properly upgraded, supported and maintained

 

Equipment

 

age and history of equipment

be cautious of equipment that is old (two years can be old) and/or second hand (why does the original owner no longer want it?)

 

Software

match with requirements

consider using free software only if you would have been prepared to pay for it

 

Advice and implementation assistance

 

Value, skills, requirement, commitment

 

will you value advice if it is free? do the skills of the volunteer really match your current requirement for skills? is the volunteer committed to getting things done and seeing their part of the project through?

 

All free help has strings, so make sure you put a proper value on the project and on the help.

Paradox 4: Charities usually require standard packages that are totally bespoke

Charities, like most organisations, usually begin the selection process from the premise that they want their solution to be based on standard packages. Once they have gauged diverse opinions and specified their requirements, it becomes clear that no standard packages come close to meeting all the requirements. Resolving this paradox requires sound judgement in scaling down expectations and specifying requirements again in line with pragmatic IT opportunities.

The following table provides some very general guidelines on the types of expectations we believe different sizes of charity should have. The income ranges are a rough and ready guide to the size and complexity of charities. The terms and income ranges should not be confused with legislative and regulatory definitions of large and small charities.

Table 3: Types of expectation based on size 

LARGE (ANNUAL INCOME £10M PLUS)

MEDIUM (ANNUAL INCOME £1M to £10M)

SMALL (ANNUAL INCOME LESS THAN £1M)

 

IT strategy - High degree of automation

Specialist charity packages plus modified standard packages plus productivity tools (e.g. spreadsheets, word processors, databases)

Possible use of externally managed facilities

Connectivity and integration issues to resolve

Documented procedures "No system fits us"

Complex issues to resolve, as it may be difficult to establish the degree of automation required and the extent to which specialist software should be employed

The ideal solution for most functions may resemble large charities, yet resource constraints impose small charities solutions

Less reliance on specialist charity software and software modification

Greater reliance on standard packages (e.g. accounting software) that matches many but not all requirements

"We have to fit the system"

Practical, simple approach

Some use of packages combined with manual processes (e.g. basic accounts, spreadsheets, word processors and databases)

 

 

We believe that charities should specify their requirements iteratively, and learn from the earlier iterations. Paradox 5: Charities need an easygoing yet formal relationship with software suppliers

When a charity buys core system software it is not merely buying a software package. It is also buying a parcel of services and entering one of its most important business relationships. Very often charities choose to buy turnkey solutions (hardware, software and support services from one source). We question whether the charity has had sufficient contact with the supplier after a couple of meetings with a salesman plus a ten minute chat and handshake with one of the directors of the systems house. It is important to have a good and easygoing relationship with the systems supplier and charities are usually highly skilled at being "warm and cuddly" with their suppliers. The systems supplier relationship is very likely to come back to haunt you, however, if the fundamentals of a commercial relationship are absent (e.g. a proper contract that includes the specification of requirements and agreed service levels).

Paradox 6: Computers get faster smaller and cheaper but the price of solutions doesn't fall

A combination of improved microchip technology and fierce price competition has caused dramatic hardware price and performance improvements. Similarly in the software market, modern software development tools enable authors to produce flexible software systems that they market at increasingly keen prices. Why then does the overall price of solutions remain more or less the same? Some argue that the cost of professional staff (who provide services such as consultancy, training and support) has increased during the same period. This is true, but we do not believe that this can account for all of the difference. We suggest that it is the nature of the solutions that has changed. As prices fall, charities adjust their expectations from their IT spending accordingly. This is fine if the decision makers know what the costs are going to be. The cost of the machines and the basic software are now often less than half of the solution cost, when all the surrounding services are properly costed in. As expectations increase, the complexity of systems and the effort involved in implementing solutions also increases.

Remember, however, that the solution delivered today should have far more power and features than the same spend bought a few years ago. Understand the true cost of systems and understand value for money from systems.

Paradox 7: Charities should hurry their computer projects along while not rushing them

Charities are often in a hurry to change their systems. The system they are replacing may be costing them a small fortune each month or may lack some vital functionality. The project manager rightly wishes to capitalise on the flurry of excitement caused by the IT review process. Prospective suppliers, fearful of the excessively ponderous charity customer threaten to withdraw favourable quotes and nag for decisions. Inability to make a software selection decision promptly is usually a sign that the charity has missed an important stage of the process (e.g. specifying requirements or ranking priorities). In the hurry to get the project moving, the inexperienced project manager can inadvertently slow the process down.

Worse, if an inappropriate selection is made, the cost in money, effort, morale and time can be enormous. Only experience and good judgement can tell you where to let the deadline be the overriding concern and where to let the quality of the process override the deadline. There is always risk in a charities systems project, the skill is in understanding and managing that risk.

Table four below summarises the seven paradoxes and the lessons we believe charities can learn from them. In the next issue we shall describe the ten commandments of quality in charities.

Table 4: The paradoxes and lessons summarised

Number

The Paradox

The Lesson

1

Charities are unique, yet charities are not unique

know yourself

2

Information technology plans should be visionary while being pragmatic

know your direction

3

Charities should utilise voluntary help but remember the commercial importance of the project

understand project value

4

Charities usually require standard packages that are totally bespoke

iterate and learn

5

Charities need an easygoing yet formal relationship with software suppliers

be commercial

6

 

Computers get faster smaller and cheaper but the price of solutions doesn't fall

understand value for money

7

Charities should hurry their computer projects along while not rushing them

understand risks