Setting Expectations

The stage between initial consultation about user requirements and finally defining and communicating project scope is one where many organisations come unstuck. It is unlikely you will find a system that can meet all of your needs; requirements will have to be prioritised and compromises made. How you manage the expectations of your stakeholders at this time is critical to your success.

Many suppliers work closely with institutions to produce high-quality, innovative products specifically for their purposes. Nevertheless, some problems will undoubtedly occur when implementing any of their software applications and it is wrong to assume that the problems can be avoided by simply choosing a different system to those receiving bad press. In fact, the notion that there is a product from any supplier that will work correctly immediately upon installation with few dangers of over spending or dissatisfaction with the results is simply mistaken. Many of these dangers are inherent in the nature of this type and generation of software.

Whilst it would be nice if institutions could depend on suppliers to educate them about the pre-requisites and ramifications of implementing, maintaining and using their products, they cannot. The product 'bundle' of interconnecting systems and different ways of using them via alternative configurations are rarely identical between organisations. Nor can institutions depend on consulting firms that make their living out of implementing systems, to give them the complete story about deploying those systems. After all, by far the biggest cost in any such implementation is likely to be the huge fees paid to consulting firms to assist with the configuration and customisation of the software. Although consulting firms can be valuable partners, their interests do not always coincide with the organisations they serve.

Open source software is proving a viable alternative to commercial products for some institutions but many of the implementation issues remain the same. The JISC provides an open source advisory service known as OSS Watch.

The true costs of implementation will not emerge until detailed analysis is performed on how well the basic 'out of the box' system fits the stated needs. This is usually a part of the implementation process that can take weeks or even months. Suppliers' or even third party estimates of costs made without this information are seriously misguided. Institutions must commit to finding out about the strengths and weaknesses of the software being considered and the inevitable risks and high costs of the processes to implement and maintain the systems at the earliest opportunity.

Avoiding or at least mitigating these problems when implementing a complex management and administrative system demands extra detailed information, more sophisticated knowledge and greater tactical decisions than have been required of administrators in the past.

Unfortunately, projects often suffer from a phenomenon whereby people who are selling the project play up the benefits while the budget request is successively trimmed by repeated layers of review. The obvious result is a project that is over-sold and under-funded. The Risk Management infoKit has some useful advice on setting project budgets.

At the end of the implementation planning stage, the project should have a firm foundation with a plan and resources secured to make the implementation a success.

It is vital that the user community, principal officers and project staff, indeed all stakeholders, should have a clear understanding of the amount of work, costs and risk involved along with realistic and unambiguous expectations of the system's appearance and capabilities and the benefits that will be achieved.

As has already been stated it is easier for an institution to select a suitable system and understand the issues affecting implementation if the system requirements have been specified and signed-off as early as possible, setting realistic expectations of the new system at this much earlier point is an added advantage.

Scope Creep

An all too common phenomenon during system developments or implementations is that of 'scope creep'. Scope creep is the expression used by project managers and/or suppliers who are constantly under pressure to deliver in excess of the requirements originally agreed. This normally results from a failure to establish the clear requirements of the users. Having taken the trouble to specify and approve requirements and timescales, allowing these to change significantly will run the risk of scope creep with continual review and revision of plans, timescales, costs, direction and deliverables. Even if this can be achieved successfully, you shouldn't underestimate the damaging effect that an ever-shifting sea of scope and timescales can have on the perceptions of staff 'outside' the project, as they grow wary of the lack of focus and more concerned for their future roles.