Specifying, choosing and implementing computer systems

Stage 1 - Establish the foundations

What is your aim?

The overall aims of the project should be specified by the project sponsor. In a small company this will probably be the owner or Managing Director. In a larger company the sponsor will probably be a director supported by senior management. The project sponsor (aided by other staff as necessary) should ask the following questions:

 When the system is in operation what do you want it to have achieved? What will have improved (WP 1-1)?

 What is the rough budget going to be?

 How long do you want it to take?

 Which systems will interface (that is pass output and/or receive input) with the proposed system. This should arise from the determination of input and output requirements but it’s always good to have another view.

 What are the features of the current system? Document the current and proposed features (1-2). When the activities and tasks are documented, align the two (SS 2-1 Tasks) to ensure consistency and completeness. The ‘Proposed new system’ column is useful as it sets the general direction of the project and may highlight inconsistencies at an early stage.

Get the project sponsor to formally approve the aims, budget and timing when appropriate.

The Project Manager

A person to manage the delivery of the project is essential to ensure it is delivered on time and within budget. The Project Manager will not normally be the project sponsor.  Qualities of the Project Manager are:

 Ideally full-time.

 Knows the organization, its procedures and people.

 Confident to work with computer systems and users.

 Diplomatic, assertive, friendly, open to learning and new ideas, able to motivate, calm, honest, realistic.

 Supported by the users (WP 1-3).

 Targeted with delivering the output required, within the time and budget specified in the documents approving the expenditure.

 Maintains a daily diary to record what worked and what didn't (WP 1-4)

 Maintains an index of meetings and their purpose (WP 1-5)

 Oversees the ‘Problems, Issues and Requirements’ (PIR) database (SS1-7).

 Maintains the risk registers (SS1-8, 1-9)

 Structures the project and sets up a project plan (SS 1-8). Monitors this to ensure timely delivery (Not covered in this document).

 Regularly reports progress to the project sponsor and users.

The success of the project will depend on the abilities of the project manager - so choose carefully.

Establish a ‘Problems, Issues and Requirements (PIR) database

On the project involving me, we established a ‘Problems, issues and requirements’ database which was maintained by the Systems Analyst. The intention was to capture any questions as soon as they occurred and make sure they were answered. Each PIR was uniquely numbered and contained the following data fields:

 The date raised

 Person raising the PIR or reference to the schedule it came from

 The problem, issue or requirement

 The relevant activity and task

 The person responsible for dealing with the PIR

 The answer to the question

 The date resolved

 Reference to the document which shows resolution of the PIR

If no database is considered necessary, a spreadsheet should be used. The problems, issues and requirements relate to actual circumstances which require action. The lists of risks (below) relate to circumstances which may occur and may need action to reduce their threat.

The users (stakeholders)

Having decided on what the project is to deliver, you should be in a position to decide which jobs are affected by the system. The people doing these jobs are the users. Users will be job holders who:

 Require information from the system to make decisions to assist them to achieve their objectives. (Don’t forget users who may get data electronically from any system being replaced). (More information at www.managing-information.org.uk).

 Input data, either manually or electronically.

 Process information, prior to input.

 Implement the system (not strictly ‘users’ but we will consider them as such).

 Operate the system (may be an external company engaged to support the computer systems).

List the users’ job titles together with their responsibilities and the tasks to which they relate (WP 1-3). At this point the related activity will be a ‘best guess’. The actual activities will be identified in stage 2. The job titles are given a number which is later used to reference their objectives.

Hold an introductory meeting

A meeting (or meetings) of people who might be remotely affected by the new system should be held. Remember to include senior managers whose staff might be involved. Topics at the meeting should include:

 Why the new system is needed.

 What are its aims?

 What are its benefits?

 How it will be implemented.

 Timescale.

 The support required from them.

 What are the activities and tasks involved? The detail will be determined in stage 2 but it’s useful getting a high level view at this stage (SS 2-1 Tasks).

 What problems, issues and requirements do they foresee?

 Use this meeting to complete the current and proposed features (WP 1-2) document.

This meeting is an opportunity to get those people affected by the new system ‘onside’.

Risk workshops

Risks may threaten the achievement of objectives in two ways:

 During implementation, cause the budget to be exceeded, implementation to be delayed and/or the requirements not to be delivered (SS 1-8).

 After implementation (‘go live’) result in a failure to deliver objectives, such as satisfying customers (SS 1-9).

The implementation risks are best determined by a risk workshop held at the start of the project, with the list being regularly updated in meetings of relevant users. This gives the opportunity to spot risks which may bring the project to a halt if not addressed.

The risks arising in the implemented systems should be determined when the objectives are clearly understood.

There may be some crossover between entries in the PIR and in the risk documents, since ‘risks’ could be defined as ‘issues’. A means of differentiation is to consider risks as being circumstances in which a loss will occur, and which may require controls to be implemented, whereas an item on the PIR may just be a question answered when choosing the system. The distinction is not vital, since both types of ‘issue’ should be resolved.

Advice on holding a risk workshop can be found in book 1 at www.internalaudit.biz.