Archive for March 2010

Do projects ever end?

In the public sector, the billing system usually represents the biggest single entity within the IT environment.  However even if the billing system  doesn’t account for a lot of the infrastructure per se, it is one of those applications (or suites of applications) a lot of other stuff needs to be plugged into. It’s therefore not something you can easily put to one side and forget about.

The truth is that while everyone focuses on the initial implementation project when considering the cost and resource requirements of the billing system, it doesn’t all come to a nice sweet end after the initial go-live. Whether it’s looking after the beast itself from an operations, maintenance or enhancement perspective, or making sure it remains properly integrated with everything around it, the end result is typically a significant ongoing effort on the part of the IT department.

In terms of routine activity, there’s the usual application of patches and fixes from the vendor, which could be to do with minor functional enhancements, the implementation of regulatory changes, or more systems related things such as supporting the latest upgrade to the database management system upon which the application depends. There’s then the more traditional systems ops side of the equation, ranging from patch management and maintenance of the underlying hardware and platform software, through storage and information management, to performance monitoring and management, including troubleshooting server, storage and network issues as they arise.

In addition to this core activity, an area that has become more of a consideration over the past few years in particular is security and access. As billing systems have been opened up to broader and faster moving audiences, especially customers, more thought and effort has needed to be given to user provisioning and making sure access routes are properly secured. And, of course, the billing system needs to be kept in sync with everything else from a policy perspective.

Some of these developments have come about quite naturally as technology has evolved and opportunities have arisen to take advantage of new ways of doing things within the business. In other areas, technology advancements have also enabled efficiencies to be introduced into the underlying platform. Modern servers, for example, can reduce the cost of ownership considerably when you look at improvements to price performance, energy consumption, space requirements and - not least - manageability. And improvements at this level are not going to let up, so the occasional replatforming project is inevitable in most organisations, with all of the migration work that goes with it.

Beyond the systems side of things we have the day-to-day keeping up with what’s going on in the business. This includes handling change requests for minor modifications and enhancements to the system, and here it is not just the technical work that needs doing, but managing the whole review and approval process, which can understandably be quite strict in some organisations where even a relatively minor mistake could easily have disastrous consequences from a business integrity, continuity and regulatory point of view. All of this adds to the overhead on IT, without even thinking about more substantial projects such as major package upgrades, implementation of new components/modules, extension and customisation work, and integration overhauls as other systems with which billing is inter-dependant are changed or added, etc.

In some organisations, the level of ongoing activity is such that they maintain permanent development and test environments alongside the live system to control and manage the throughput.

Project costs

There are many variables that impact the final project price. The mistake many companies make when initially trying to estimate the cost of a project is paying attention to only the actual software license costs. However, a recent white paper outlines four elements that need to be considered in every software budget.

One of them is “implementation services”. This term can seem vague, especially if it is a company’s first large software project. The white paper includes a definition of the 8 services you are paying for. It also outlines minimum software to services ratios, 8 questions to ask to know when to add more money to the budget and a sample quote. The buyer is also given the pros and cons of the two methods of pricing software implementations: “Time and Materials” versus “Fixed Fee”.

The White Paper is a useful overview that can alert readers to potential costs they may have overlooked

Implementing the software wisely

In the second part of a recent Computerworld series on ensuring software implementation project success, Ian Anderson, director at SAP services company DNAstream sets out four elements that he regards as critical:

The first one is a telling reflection on SAP in particular:

“The chosen software must be able to meet the required business processes, not absolutely, but at least to a level that is agreed in advance as acceptable, perhaps a 70% to 80% fit. This is often achieved through a level of compromise, such as adapting the business processes to fit the software where possible.

It is essential to have these business processes identified, documented, understood, mapped to the software and signed off by the business before you start implementation.”

A lot of billing folks would regard a 70 to 80% fit for billing to be a failure.  To be fair to Anderson, he was talking about ERP.

The second is “choose the vanilla flavor”.  In billing that’s not always possible, as billing rules are often mandated by external agencies and regulators.  Here’s what Anderson says:

“The overwhelming advice is to keep the software as standard as possible to avoid potentially costly effort on support and future developments, including upgrades. This is often referred to as vanilla ERP.”

His third point is always a timely one, especially where utilities rush out to get advice from a big-name consulting firm, as if that minimises their risk – use a consultant who understands your business and will know the best approach for you, rather than simply repeating the method he used at his previous client.

Lastly, “Constantly check and review during the project.”  A well-managed project is a prerequisite for a successful implementation.

|