Software Observed

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

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.

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.

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.