Archive for May 2009

Scoring vs. analysis

Scoring’s limits should be recognised when it comes to comparing vendors.  What does it mean that one vendor received an overall score of 90% and another 91%?  Even reviewing  raw percentages at a greater level of detail.  Suppose there are two functional areas (A and B), and two vendors - each is weak where the other is strong.  At the level at which most consultants report (A+B) the vendors appear to score equally.  Even if the software buyer rates both A and B as equally important, a consultant who draws attention to the results rather than letting the purchaser find the results by poring over the details buried in the figures for each vendor is adding the sort of value for which consultants should be responsible - but often are not.

More scoring

A more informative method of scoring is to have a three-dimensional matrix.  Not only “fully complies” etc. but which version - “current”, “will be released within 6 months”, “will be released within 18 months”, “will consider for future release”, “would not consider”.  The latter pieces of additional information should give a better, although only approximate view, of the direction in which software development is headed.  There are arguments for and against this approach, but if more distant horizons are reflected by discounting the scoring, purchasers may get more information than the two-dimensional somehow complies/does not comply traditional responses.  As billing software is evolving to meet new needs (industrial or trade waste, for example), future directions are significant for potential users

Scoring vendor responses

The simplest way of reviewing vendor responses is to apply a scoring mechanism.  This is often a matrix of weighted criteria -  “how essential is this feature to us?” applied to a limited set of vendor responses (”fully complies”/”complies with intent”/”does not comply”).  It’s a rough-and-ready way of determining fitness for use.  But that’s what it is - rough and ready.  Maybe it’s good enough.  Perhaps it isn’t.

How many vendors does it take to …

Towards the end of a software selection process it’s usually obvious that two or three of the vendors can more or less meet your organisation’s needs.  They may not be able to meet them all and each will probably have different functional shortcomings.  Each vendor will also probably have different strengths and weaknesses, on implementation or support, say.  At that point the two non-functional elements come into play - “chemistry” and price.  The successful billing software vendor will have a close relationship with your organisation over a number of years.  Billing is not a “plug it in and walk away” application.  You need to be confident of the general calibre of their staff - not just the ones you met.  Can they attract and retain staff in whom you have confidence?  Unfortunately it’s not always possible for any company to guarantee that.  With vendor consolidation many fine staff have been let go from takeover targets.  So while chemistry is important, “falling in love” with a vendor’s staff may not always be satisfactory in the long term.

Big business for consultants

Software selection and implementation services have become big business for consulting firms as well as the software vendors themselves.  Even with outside assistance, selecting the right software for your operation and having a successful implementation can be an extremely difficult undertaking. Remember however that they are two separate exercises.  An expert project manager may not be the right person to help you select the software as well.  Horror stories of failed ERP system implementations are unfortunately very common.  Anyone that frequently reads business publications has likely read stories where governments, utilities and large corporations cite problems associated with the implementation of a new software system as one of the causes of whatever problems have come to light.  Whether these claims are legitimate or not is up to debate. What is true, is both the public sector and businesses are highly dependent on information systems, and failures in the selection and implementations of systems can result in anything from a minor nuisance to a complete operational shutdown.  However getting the software impemented is something that comes after selecting the appropriate software.

User groups

The health of an application can often be gauged through the health of its User Group.  The main interface between the user group and the vendor should be the product manager, whi should have a close working relationship with those key users.  However, while many RFIs and Tenders ask the vendor whether there is an active user group, they often rely on the vendor’s assurance about the group’s existence and its activities.  Although site visits to users are usually undertaken, most often there is no contact with the user group at this stage.  That is an oversight and we recommend that some interaction with the user group from part of the due diligence of software purchasers.

“Best of breed”

There’s an argument about whether a single vendor can satisfy every need, or whether software buyers should try for “best of breed”.  Sone public sector vendors have decided to focus on one or two areas of differentiation, assuming that they should not compete for, say, payroll or general ledger customers.  Others try to cover every base.  Fortunately the newer standards for integration such as SOAP and Web Services are changing the nature of this argument but it will undoubtedly continue as SAP and Oracle, in particular, try to crowd out other players.

Software development

Sales at software companies, big and small, are falling as a result of the recession.  Such facts raise the question of the business model some of these companies adopt.  Many regard their development activity as a research and development item, and recognise that new development, essential for them remaining credible, must continue in bad times and good.  Others have a business model where the main revenue comes not from sales but from the predictable revenue stream of on-going maintenance.  One of the newer players manages its business entirely by metrics that disregard the R&D element of software development altogether.  Their software development is almost shut down, as they weather the storm in the same way as the bear survives the winter - in hibernation.  Public sector software purchasers rely on that sort of vendor at their peril.  The winter may be longer and harder than imagined - and the bear may never wake up, but die.

The Product Manager

In evaluating software vendors in an area as specialised as public sector billing, the role of the vendor’s product manager is paramount.  He must be a person with extensive industry knowledge.  Why so?  Consider how software is developed.

Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well - only they did a different job from what they were supposed to.

The definition of a successful program is that it is 100% compliant with its initial requirements. But it those requirements contain mistakes, are unclear or poorly defined, then there is very little one can do to correct the problem later in the process. So, a bit of advance planning simply doubles the success changes of any software project.

The person in charge with writing the requirements should be the product manager.  His job is to keep abreast of industry developments, and liaise with the team in charge with software engineering, all the stakeholders, the clients and the end-users. Writing good requirements takes time and practice.  It also needs extensive experience.  The best product manager is someone who is perhaps a former project manager, with a variety of projects under his belt, and knoweldge of how at least two different public sector billing applications tackle the same functional areas.

Industry knowledge

Consultants who support public sector billing choices must keep abreast of all of the latest opportunities and requirements.  One of these are the multiple options surrounding payments, particulalrly by credit card.  Few outside public sector consultants, for example, are aware of the special rates credit card operator Visa for payment of utility bills by credit card.  Specialist consultants should be aware of this and provide an opportunity for value-add.