Project Delivery Process D860

D860 - Define Live Support Mechanisms

DEFINITION

Dictate responsibilities for support of the live system and liaison points with the vendor.

SUMMARY

Define how the live system will be managed and supported.  With a medium system, this may not require a specialist department nor, in certain cases, specialist staff; frequently the system will be supported and managed by a line department.

The approach should be defined and agreed.  It will normally be documented in a Brief Implementation Paper (BIP) - System Support and Administration.

This process is intended for Brief Delivery cases where the size and nature of the final solution does not warrant a specialised support department.  Where a Systems Administration function is to be defined, further information is available in Process D850

PATH PLANNING GUIDANCE

Optional - used where post live support will be required.  This process is an alternative to Process D850 which deals with similar arrangements in larger systems where staff will be dedicated to support and management of the system.

DEPENDENCIES

Prerequisites (Finish-Start):

• Delivery Approach Definition (DAD) or equivalent definition of overall business solution.

Prerequisites (Finish-Finish):

• definition of User Procedures

Dependent procedures (Finish-Start):

• live running

RECEIVABLES

• Delivery Approach Definition (DAD)
• various User Procedures and BIPs relating to organisational set up, roles and functions
• various BIPs relating to functional and technical design

DELIVERABLES

• Brief Implementation Paper - System Support and Administration

TOOLS

• Examples: Terms of Reference for Systems Administration

DETAILED DESCRIPTION OF TASKS

The System Support and Administration Brief Implementation Paper

The approach to management and support of the live system is considered in an environmental brief implementation paper - the system support and administration BIP.  In a similar fashion to other brief implementation papers, it will state and detail a recommended approach.

Requirements for support and management

All systems require some continuing support and management.  In some small systems, the arrangements are left undefined and informal.  Although this may be practical in very small organisations, it is usually worthwhile agreeing and publicising the details.

Requirements will vary according to:

• the business needs
• the functional design
• the user procedures required
• the user organisation - its structure, and nature
• the desired form of systems management and support
• the amount of investment in support that would be available in terms of people and funding
• the system’s vendors and their style of support.

Some major types of support or management that might need to be addressed include:

• bug reporting by end users and the resolution procedures
• rules and procedures for reporting bugs to the vendor’s support facility
• liaison with the vendor’s support functions (for both functional and technical problems)
• application of corrections and routine amendments from vendor
• liaison with vendor regarding sales, new products and upgrades
• implementation of upgrades (nb any major upgrade should be handled as a separate project)
• vendor user group membership
• run scheduling and instigation
• run controls and system controls, eg system-wide carried forward / brought forward figures, control totals etc
• management and control of interfaces, eg instigation of runs, verification of control totals
• monitoring reported user or data errors and ensuring they are rectified
• update and control of system parameters, eg calendar, reporting periods
• update and control of shared master files
• management of functional security and access controls
• management of technical security and database security
• “ownership” of data types - eg is the purchasing department or the accounts payable department responsible for vendor data
• report and enquiry writing and support
• users’ Help Desk
• update and control of vendors’ manuals
• update and control of own user documentation
• minor functional enhancements
• provision of continuing training programmes or facilities
• archiving of old data
• monitoring of system performance and capacity
• monitoring of backup, recovery and disaster recovery arrangements
• acquisition of minor enhancements to the computer hardware, communications equipment etc
• acquisition of operating resources, eg disks, paper, tapes, cartridges, special stationery, printer ribbons/toner cartridges

Many of the topics listed above may need to be broken down into individual cases.  For example, separate ownership might be defined for each type of master data, or even for sub-sections within the master data - eg ownership of customer details defined according to sales region.

The detailed arrangements will need to cover all situations so that there is no misunderstanding amongst the staff involved, and, in particular, so that no significant task is overlooked.  Responsibilities should be unambiguous; they should be held by specified staff or units.  In particular, responsibilities for liaison with external bodies such as the vendor should be well defined and limited to ensure that confusion does not arise in these external relationships.

Defining Responsibilities

The various options available should be considered.  These will depend upon the details of the business solution, the structure of the organisation and the technicalities of the system.

The key choices will normally relate to who performs each specific task, and how that task is managed in terms of line responsibility.  There will normally be at least some of the necessary tasks which cross organisational boundaries.  This will probably require the agreement of the line managers involved.

In most cases, there are elements of both functional skills and technical skills required in the management, control and operation of the system.  Where the organisation has a specialist MIS department, it may be possible to involve them in the technical side of support and management.  It is, however, normally recommended that the overall management and control of the system remain in the hands of the user management.

The requirements and options should be considered with the key user management, particularly those who will have line responsibility for the system.  An approach should be agreed and documented in the Brief Implementation Paper.

In some cases where new roles need to be created or where existing roles are changed substantially, the organisational and staffing recommendations will have to be agreed with senior management, the line management directly concerned and with the organisation’s personnel function