Archive for June 2009

Functionality details

Public sector entities purchasing software often go through a much more rigorous selection process than the private sector.  Much of this revolves around the public tender (RFT) process which is more structured than the way in which private enterprise buys almost anything, software included.  However when it comes to functionality both public and private sector needs reassurance that the money they’ll be spending on software purchase and implementation will give them the outcome they want - hence the need for functionality checklists.  A well-structured checklist however doesn’t look at prescriptive detail as much as basic concepts.  Milestone-based workflows, for example, is a concept that can be used in multiple and quite different functional scenarios.  Knowing that a package has a well-designed workflow engine that can be used in multiple ways can overcome the need for overly-detailed checklists.

Work smarter

Increasing demands on public sector employees mean either worker harder or working smarter - or maybe both.  Well-designed software utilising the Internet for customer interaction can help the working smarter side.  Working harder maybe isn’t a great option - especially as the workforce is greying.  This recession will end, and when it does demographics are going to start working in favor of the labor force, as the number of younger workers starting to climb the ladder dwindles and councils face what could be big gaps in the talent pool. That should spell opportunity for better software, and better use of software.

Common vendor mistakes

According to Ross Storey’s blog, many vendors just try too hard.  “But, all too often, sales people just can’t help themselves. They fall into the temptation of making their presentations blatant sales pitches. They can’t resist the opportunity to do a traditional sales presentation to a captive audience of senior IT executives. But this is a big mistake.”

Software as a Service

One of the options in selecting software is to select software that will be “hosted”.  One public sector provider of tax billing software, Civica, offers a hosted solution for many of its smaller customers, and are looking to increase this business.  On the utilities side, the Australian energy retailer, Origin, is apparently outsourcing its SAP-based solution to Wipro.  Whether outsourcing the platform or the software (or both) a whole new dimension arises - the reliability of the telecoms or Internet infrastructure that supports the hardware and software being located far away from (and by another business altogether) the core retail business, whether it’s electricity, water, your local Council or an airline. Hosting however is only a stepping stone to software-as-a-service (SaaS), where the user doesn’t own the software at all.

The successful RFI

A successful RFI (Request for Information) consists of 5 elements

  1. The breadth and depth of the proposed solution.  What modules?  What functionality?  If the vendor bundles a General Ledger with their Billing product, is that a plus?
  2. The product road map.  The application will be in use for five, ten or fifteen years.  Where has it come from?  Where is it going?  What is the strength of the research and development team?
  3. Our environment.  How does it fit in with our plans and expectations?  If we plan to run everything on Linux two years from now, where does this application fit?
  4. Other users.  Who else uses this software?  What is their experience?  Is there an energetic user group?
  5. How much?  An RFI should only elicit indicative pricing, but at least pricing models (eg. license fees based on revenue or per user or per site) should be provided by the vendor