Accountability Element

Key Documents/Project Elements

Responsibility for element

Performance specification

IT strategic plan.

Individual project business cases.

Relevant milestones in Chief Executive performance agreement.

Department prepares.

Department prepares, central agencies advise, Cabinet approves.

Department prepares, SSC implements and monitors.

Decision authority

Ministerial approval.

Responsible Minister (within legislative and Cabinet authority).

Incentives/sanctions

Annual performance review against performance agreement of Chief Executive.

State Services Commissioner.

Performance information

Project reporting and independent quality assurance (if required under monitoring regime).

Departmental quarterly reporting (unaudited).

Departmental annual reporting (audited).

Department for original preparation.

Central agencies and independent QA for external monitoring.

Business case

The fundamental document underpinning the justification of a specific major IT project. It sets out the costs and benefits expected from the new system and provides information on the deliverables and timeframes for return on investment.

Business process re-engineering

The review and implementation of new ways of "doing business around here" that usually leads to the re-design of business and work processes as a result of the new system.

Change control (project changes)

The process that is used to identify changes outside of the scope of a specific project, tracking the changes and monitoring the impact on the system.

Change management strategy and plan (relates to organisational change)

As part of the internal suite of project specific documents, this document records the principles and approach to change management. It also sets out the processes to be used to identify, mitigate and manage the impacts a major IT initiative and implementation of a new system will have on the organisation and its people.

Communication Plan

This document is part of the suite of internal project specific documents and sets out an overall communication strategy, the audiences and the type and means of information sharing, consultation and communication to be undertaken. The plan also details timeframes and allocates responsibilities, i.e. who is responsible for communicating what and when.

Department

The term department is used generically to refer to any Government entity whose major IT projects are subject to the public sector IT monitoring regime.

Feasibility study

The research and report that determines the basis for developing a specific IT project to the point of preparing a business case.

Information Systems Strategic Plan

A 3-5 year plan that sets out the strategy and objectives to meet the business requirements as set out in the Strategic Business Plan. This plan identifies in order of priority the IT initiatives planned by the department to support its strategic direction.

Issues register

This is a project specific repository for any issues that arise during the project. It provides a means of documenting each issue through to conclusion. Each issue is allocated a unique tracking number.

IT system

Information technology that may include any or all of: hardware, software or telecommunications that is implemented to meet the department's business needs.

Post-implementation review

At the end of a pre-determined time (usually linked to the warranty period) all parties to a specific project meet to review and report on the project processes and outcomes. This is a valuable learning exercise for all parties that can be shared and utilised in future projects.

Project Definition

A document that contains the overall view of a specific project from the purpose and objectives of the system to be developed, through to a scope of the project and a high-level project plan.

Project management life-cycle

A description of the phases required in the management of a project from the initial definition or concept through planning and implementation to completion and post-implementation review.

Project Plan

This is an overall detailed working plan of all phases and modules of a specific project. It sets out the tasks, milestones, timelines, resourcing and shows dependencies. Each subproject should also have a detailed working plan.

Project Report

This document is part of the suite of documents associated with a specific project. It provides a weekly account of progress to date against the project plan milestones, indicates the tasks completed and planned for the next period, records the most significant issues and risks and what is being done to mitigate or address them.

Proof of concept

Development of a prototype of the system to ensure that the design will meet the business benefits sought.

Registration of Interest (ROI)

The first part of a staged selection process for a supplier that gives potential suppliers the opportunity to indicate their interest by sending contact details.

Request for Information (RFI)

The second stage of the selection process that provides a more detailed outline of the project and offers those vendors who responded to the ROI the opportunity to provide further more detailed information.

Request for Proposals (RFP)

The final stage in the selection process in which the department prepares a fully documented set of requirements that is issued to suppliers whose RFI responses were evaluated as being able to meet the requirements for the new system.

Risk management plan

This is an assessment of all the risks and their likely impact. It is part of the internal suite of documents associated with a specific project. The plan assesses each of the risks and includes options for accepting, eliminating or managing them.

Risk register

This is a register of all the risks, probability, impact and actions for a specific project. The register is continuously monitored and updated during the life of the project.

Selection process

ROI - Registration of Interest

RFI - Request for Information

RFP - Request for Proposals

The three staged process that can be used to narrow down the list of suppliers to eliminate unlikely candidates at each stage, while at the same time ensuring transparency and contestability.

The three phases are more likely to be used together when the department expects the requirement will attract a large number of potential suppliers.

The selection process is accompanied by pre-determined criteria set by the department.

Software Development Life-cycle

A component in the project life cycle that describes the steps in the software development process from defining the requirement through design and development to implementation and post-implementation review.

Strategic Business Plan

An overall plan for the department that sets out the strategic goals and objectives for the department - usually over a three to five year period.

User acceptance testing

The system testing phase of a project during which users test and report any faults or problems they experience that need to be fixed (or that trigger the change control process) by the suppliers before the system is accepted (and paid for).

Warranty period

The period immediately following "go live" of a new system during which users report faults or problems they experience that are fixed by the suppliers at (usually) no additional charge or that trigger the change control process for further work.

Principle

Guideline

The guiding principles from the Policy Framework for Government-held Information apply when selecting IT based projects.

The information supporting Government and departmental business processes is a key strategic Crown resource, and must be managed throughout its life cycle.

IT projects must conform to Public Service standards that, subject to statutory and privacy requirements, common core information should be accessible and able to be shared.

Information relating to business requirements should be collected only once, and thereafter be shared by authorised users, but only if this is practical and cost-effective.

Common definitions for shared information must be agreed to and implemented.

In their role of monitoring major IT projects, the monitoring agencies have an overview of all such projects across Government.

The monitoring agencies are in a good position to consider how well the projects are progressing and ensure a 'whole of Government' perspective.

Enable sharing of information among departments, with appropriate security and access and within the limits of existing legislation

Avoid duplication of effort by more than one department.

Principle

Guideline

Best practice

It is best practice world-wide for organisations to align their IT projects with the business objectives by using a common set of criteria that enables the best use of resources.

These criteria must:

• Support and advance the business and strategic directions of both the department and the Government.
• Provide a long-term cost-effective solution to a specific business requirement.
• Provide greater long-term benefit than alternative available options.
• Support improved work processes.

The strategic business plan will show where the project fits into the department's priorities and systems.

The business objectives will be accurately defined and analysed.

(Note: A new infrastructure must meet business requirements, it must not be developed without reference to the strategic business plan).

The criteria are based on the business and operational values and objectives of the department.

The criteria will include:

• Meeting specific strategic objectives.
• Supporting particular policies.
• Reduction of costs.
• Improving service quality.
• Minimising risk exposure.

The process involves comparing:

• New projects against each other.
• All projects against existing systems.
• Infrastructure projects against business-driven systems.

IT delivers systems to support the business processes (IT may often offer the only means of carrying out the process).

Business managers propose projects that:

• Will benefit their area of work.
• Meet the department's and Government's strategic objectives.
• Can be appropriately justified.

The right project supports and advances the business and strategic direction of both the department and the Government including its E-Government Strategy.

In the selection of a potential IT project the defined criteria must:

• Support the business directions and functions of the department and take into account the collective interest of the Government.
• Link with the strategic directions of both Government and the department.
• Be consistent with the Government's E-Government Strategy.
• Provide long-term cost-benefits to the department.
• Support improved work processes.
• Satisfy interdependencies with other systems and departments.
• Integrate with the strategic IT architecture.

The project's suitability is assessed from a general screening process to justify performing a feasibility study.

There may be several ways to provide the IT component to satisfy the business objectives.

Treat each approach as a project and assess it against agreed criteria before doing any further detailed analysis.

The feasibility study determines the business objectives to be achieved from a specific project.

In the feasibility study, highlight the link with the business strategy by:

• Specifying how the project will be integrated with the department's technology strategy.
• Defining the business requirements that must be met by the selected IT project, including the critical success factors for the project.
• Detailing alternative IT approaches which will meet the business requirements and evaluate each approach against agreed criteria.
• Providing an assessment of which option will best meet the business objectives.
• Describing how the project fits into the departmental programme of projects.
• Recommending the best approach for preparing a business case.
• Providing the basis for the business case (See Section 3).

The preferred approach takes into account the impact on other IT systems.

Interactions that may determine the approach adopted for the project include the potential impact of the proposed system on:

• Current and planned IT systems in the department.
• Current and planned systems in other organisations.

Business process redesign (BPR) is an iterative process that occurs alongside the IT design and implementation.

Any BPR begins prior to the acquisition or development of new technology or systems.

Principle

Guideline

The Information Systems Strategic Plan (ISSP) supports the department's strategic direction.

If the department's strategic direction changes, review the ISSP to ensure the two strategies remain aligned.

The ISSP is the guiding document for planning and implementing new IT initiatives.

The ISSP will:

• Specify a strategy that will provide an environment with the maximum level of flexibility.
• Set out a mechanism for introducing new technology to enable diversification.
• Identify the linkages between the proposed information systems (and the programmes/ projects to develop or acquire them) and the strategic objectives.
• Show how the proposed information systems projects contribute and link to the Government's E-Government Strategy.
• Include justification for a large-scale investment based on clearly defined business outcomes.
• Consider a range of options.
• Detail the IT projects that a department intends to undertake in support of its strategic direction.
• Specify how the project will be integrated with the department's technology strategy.
• Provide an assessment of which option will best meet the business objectives.

The impact of changing departmental circumstances or changes to the Strategic Business Plan is identified in an annual review of the ISSP.

An annual review will:

• Highlight opportunities that were not foreseen earlier.
• Enable such opportunities to be evaluated against other projects.
• Enable such opportunities to be approved for addition to the ISSP and built into the programme of projects.

Each of the projects in the ISSP is supported by a business case that sets out the funding required for that project.

(For details on the business case, see Section 3).

The purpose of the business case is to:

• Present the case for IT investment.
• Outline the scope of a particular project.
• Detail the funding required.
• Identify its benefits and costs.
• Explain what risks are associated with the project.

Distinct activities are involved in selecting an IT project.

The stages involved in selecting an IT project include:

• Assessing the project's suitability.
• Conducting the feasibility study.
• Preparing the business case, including estimated costs - essential for financial approval.

Projects qualify and are managed in an integrated Project Programme.

A Project Programme is

• A group of projects established to meet common goals and objectives that are managed in a co-coordinated way.
• It is the means by which the achievement of strategic goals and objectives should be managed.

Principle

Guideline

The risk management strategy sets out a process for identifying, documenting and treating potential risks.

A risk management strategy will be prepared for each project. The strategy will include:

• Identified risks.
• Impact if they occur.
• Likelihood of occurrence.
• A mitigation (or treatment) process.

Risks are associated with:

• The business
• Technology
• The project
• External (e.g. political).

Business risks to consider include:

• The dependency of the department on the proposed system.
• The management and other skills that are available to deliver the benefits from the system.
• The ability to implement any necessary changes in departmental infrastructure.
• Risks associated with links between the department and other businesses or operations.
• Impact on 'business as usual' and people during transition and implementation.

Technology risks to consider include:

• Adopting unknown, complex or changing technologies.
• Inadequate existing skill levels.
• The use of unproven hardware and/or software environments.
• Implementing proven software in un-proven environments.
• Changes required to the existing IT infrastructure and its interface with the department.
• An assessment of the risks associated with potential suppliers and their services.
• Rate of obsolescence.

Project risks to consider include:

• Management commitment.
• Project management expertise.
• Resource capability and availability.
• Cost variations (over/under).
• Supplier relationships.
• Inadequate planning for transition and implementation.
• Inadequate training of staff in the new technology or system.

External political risks to consider include:

• Possible impact of political change.
• The effects of major changes such as restructuring of a department.
• Changes in Government policy.
• Impact on stakeholder groups/external users.

Quantitative risk analysis provides structure for assessing and treating risks.

Quantitative risk analysis involves:

• Assessing the impact and probability of each risk.
• Modelling the project outcomes on simulations of these risks, to produce an estimated probability distribution of total costs.
• A final probability distribution, describing the range of outcomes and their relative likelihood.

Unless relevant Ministers agree that the size and nature of the project do not warrant this approach, quantitative risk analysis should be used as the basis for:

• Appropriations.
• Access to contingency funding.
• Cash draw-downs for major IT projects.

Quantitative risk analysis (QRA) enables more accurate project costing.

QRA or risk modelling is an essential part of the approval process.

How it is operationalised will be determined on a case-by-case basis.

Principle

Guideline

The current departmental structure changes as a result of political decisions on the overall structure of Government, e.g. departments merge

OR

the current functions or operations change.

To confirm the result of the business planning process is still valid, review:

• The business strategic plan.
• The ISSP.
• The programme of projects.
• Continued feasibility of individual projects.

Internal departmental changes cause staffing instability.

Maintain stability of the project by ensuring stability of key positions, especially:

• Project sponsor.
• Project manager.
• Project programme director.
• Key project team members.
• Provide mechanisms for knowledge transfer if the incumbent of one of the key positions is not available.

Other departments undergo structural change or functional/ operational change.

Review the guiding principles from the Policy Framework for Government-held Information to ensure:

• There is no duplication of effort on the part of more than one department.
• Sharing of information among departments as originally planned is not compromised by the external changes.
• Other guiding principles are considered.

The IT investment should reflect not only the good of the individual department, but also the wider, collective good.

Review strategic goals of other departments and consult in areas of commonality.

Consider how to enable information to be combined with information held by other Government agencies to provide for multi-agency transactions and to extend the list of potential uses on a multi-agency or sector-wide basis.

The department is capable and ready to undertake a major project.

Assess the impact on the department as a whole to undertake the project and to manage the changes involved. This issue is far broader than the project team concerned. It includes the impact on the way the department operates, and interacts with external stakeholders (e.g. the Minister, other departments, clients).

Consider what action is needed, what skills are required to make up for lack of previous experience. The transition phase from the old to the new is important and must be addressed.

Consider the skill mix in the department so that:

• Project managers and seconded staff reflect the complexities of the project.
• Senior Management and the Chief Executive have had prior experience of large change projects.
• External senior expertise can be contracted or seconded into the department.
• Include external quality assurance with that role reporting directly to the Chief Executive.

Business process re-engineering enables integration of new work processes following the introduction of a new system or new technology.

Identify processes that will change, then:

• Define changes.
• Identify impact of changes.
• Document new processes.
• Prepare training and communication programmes about the changes.

Project team dynamics.

Initial team building at project set-up is critical. Establish team ground rules at the start of a project. Although some of these will be established through the project structure, they may include delegation levels, budget, reporting, priorities and success criteria.

Hold regular formal progress meetings for the whole team to ensure everyone continues to aim towards the same goal. The outcome of these meetings will feed into the regular progress report to the sponsor.

Throughout the project, team dynamics are an internal matter for the project manager and team to manage, and should only be raised with the sponsor if there is an insurmountable problem.

Appropriate expertise is acquired for the project from internal or external sources.

Use of internal resources does not compromise the ability of the department to carry on with business as usual.

There is a clearly set out definition of tasks in a Project Definition, business definition or project charter to assess the capability of potential project personnel. This document includes:

• Objectives and scope of the project.
• Roles and responsibilities.
• Accountabilities.

Principle

Guideline

New projects are supported by a sound business case, irrespective of how a project is to be financed.

A good business case includes the following features:

• A clear description of the business function(s) that the project will support or improve.
• The anticipated benefits linked to Government strategy and the department's key priorities.
• Demonstrated tangible benefits for the new and current core business.
• A factual description of the expected qualitative benefits.
• Options available to the department.
• A risk assessment of each option.
• An analysis of the strengths and weaknesses of each option.
• Cost-benefit analysis of each option.
• The internal (departmental) and external. (supplier) capabilities to deliver the project
• An analysis of the impact of implementing the recommended solution on the business, customers and other agencies.
• A clear description of the scope of the project and its deliverables.

The business case is tailored to the size and specific features of a project.

A sound business case must:

• Be comprehensive.
• Be specific to the project concerned.
• Be fiscally and/or strategically significant.
• Demonstrate why the Crown as owner should invest in a particular project through the existing vote of additional capital injection.

The business case is comprehensive, and tailored to the size and risks of the project concerned.

The business case:

• Sets out project details, including key features, on how the project will meet business requirements, and how the project fits with business and strategic directions.
• Identifies assumptions, including policy decisions, conditions and risks surrounding the project.
• Provides detailed cost/benefit analysis (as far as possible with known or estimable costs) showing anticipated benefits outweighing expected costs.
• Provides risk analysis assessing risks associated with the project.
• Identifies and assesses financing options.
• Identifies organisational impact and changes and business process changes.

The business case for major IT projects that introduce business change will generally be made having regard to the full programme of supporting business and IT projects.

In general, projects will be established to meet the business needs set out in the Strategic Business Plan (SBP).

Not all projects will have a clear link to the SBP or appear to provide tangible business benefits, for example "Infrastructure projects" which update technology without introducing business changes.

However, such projects may be an essential stepping stone to:

• Establishing an environment in which business projects are able to be introduced.
• Reducing the total cost of ownership of technology.
• Reducing the business risk, or exposure to IT failure, or loss of data or system availability.

Principle

Guideline

The cost of a major IT project in the public sector must be met from within appropriations.

Major IT developments typically comprise a mix of:

• Hardware acquisition.
• Software development or acquisition.
• Data conversion or capture.

There are separate costs for each of these items and each must be considered separately. An important issue is whether specific cost elements can be capitalised as an asset or must be accounted for as an operating cost that is expensed in the period in which the costs are incurred. This is important because the Government often sets separate limits for its expenditure on new capital items and operating costs.

All public sector entities are required to follow generally accepted accounting practice (GAAP). Binding advice is in Financial Reporting Standards such as FRS-3: Accounting for Property, Plant and Equipment. Binding advice on the interpretation of GAAP for the Crown and departments is provided in Treasury Instructions, which are published on Treasury's web site (www.treasury.govt.nz/instructions).

The accounting treatment for each of the three elements of major IT developments, current when these IT guidelines were prepared, is set out below. Departments should seek professional advice on the accounting treatment in this area, especially if intangible assets are involved, because there is no Financial Reporting Standard currently in place in New Zealand on intangible assets.

• Hardware costs - if these meet the definition of, and recognition criteria for, an asset, as identified in the Statement of Concepts for General Purpose Financial Reporting, they are to be accounted for in accordance with FRS-3. This standard requires that the costs associated with the construction or acquisition of the asset be capitalised.

• Software development or acquisition - some software, such as an operating system, is an integral part of a tangible asset and is therefore accounted for in accordance with FRS-3. Other software is not an integral part of a tangible asset and the significant component of the software is intangible in nature. In the absence of more authoritative guidance, apply the principles of FRS-3 when accounting for such software.
• Data conversion or capture - a database is an intangible asset. For the Crown and departments, Treasury Instructions require that internally generated intangible assets not be capitalised, but that purchased intangible assets that meet the definition of, and recognition criteria for, an asset be capitalised. Where the costs associated with the development of a database are unable to be capitalised, these costs must be expensed. If data capture or conversion costs are material for a particular IT project, entities and analysts should check the accounting treatment with Treasury and their auditors to ensure that actual and proposed transactions are recorded in accordance with generally accepted accounting practice.

A person with the delegated authority approves the funds for the project to go ahead.

Current guidelines for financial authorisation are as follows:¹

• Authorisation limits for capital purchases or the total cost of the project must be in line with currently specified delegations.
• Any financial delegations to a Chief Executive from Cabinet can, with the approval of the Minister concerned, be delegated to one or more officers of the department. However, delegation does not diminish the responsibility of the Chief Executive, or warrant departure from existing statutory provisions, regulations, rules, or agreements.

Financial delegations are formally recorded in writing.

For major IT projects, the investment is usually of a magnitude that expenditure must be approved by the Chief Executive.

Any delegated powers issued by a Chief Executive must be made in writing and be specific as to the expenditure limits and the type of expenditure the delegation covers.

The department's baseline includes funding for all the modules, even when they are scheduled to occur several years in the future.

Follow current practice for approval to commence each module and draw down of associated funding.

Clearly identify which modules can or cannot be completed before seeking the release of funds for the next module.

Note that in some circumstances modules may be undertaken concurrently. This should be apparent in the business case and definitely be in the project plan.

Approval is dependent on a two-stage business case presentation.

Follow the two-stage approval process to release initial funding to scope a potential project to the detail required for ministerial assurance:

• Stage 1 - project definition, initial indicative costs and benefits,
• Request to do detailed scoping and finalisation of cost and benefits associated with the project.
• Stage 2 - final consideration of the business case, fully developed costs and benefits.

Principle

Guideline

The business case identifies what alternative solutions have been considered.

Assess the implications of maintaining the status quo as well as:

• Other funding options.
• Other technology solutions.

There should be consideration of a range of options, with a detailed assessment (including risks) of which option will best meet the business objectives.

The business case presented offers assurance that the proposed solution is the most cost-effective to meet the business needs.

Provide comparative costs and benefits of alternative solutions.

Confirm that reasonable effort has been made to identify and manage risks associated with:

• The technology.
• Its implementation.
• The organisational changes resulting from its introduction.

More detail is provided for the recommended option.

For the recommended option include:

• Key milestone dates and descriptions of what will be delivered.
• Key project performance measures.
• Key business performance measures.

Principle

Guideline

The business case identifies and reflects all significant costs and benefits.

Analyse the costs including:

• Direct costs of the project.
• Any indirect costs incurred by the department itself, other departments and agencies of the Crown in adjusting their business operations, or the general public, including social costs.
• The basis for calculation, including any independent assessments of calculations.
• Have all the relevant options been considered.
• Analyse the potential benefits including any direct efficiencies and cost savings for the department itself, for other departments and agencies of the Crown, and for the general public, including social benefits.

Such costs and benefits may be either:

• Quantifiable in monetary terms.
• Qualitative but unquantifiable.

Use Net Present Value (NPV) calculation to identify the net cost or benefit.

The Weighted Average Cost of Capital (WACC) of a typical organisation engaged in such a project offers an appropriate discount rate to calculate the NPV.

Note the implications of maintaining the status quo as well as other funding options and other technology solutions.

The business case contains the costs, benefits, risks, etc of the specific technologies.

Include:

• Internal costs (such as for temporary assistance to provide support for permanent staff assigned to the project).
• Contingency, especially for cost categories which have a tendency to be underestimated such as:
• User acceptance testing.
• Equipment configurations.
• Data migration.
• Changed requirements for software development or package modifications.
• Training, temporary staff to cover for people assigned to the project.
• Documentation.
• Decisions about sizing of the equipment that can only be taken after prototype or proof of concept phases have been completed.
• Budget process for:
• Upgrades to equipment.
• Software licenses.
• On-going maintenance costs for both hardware and software.
• Outline of assumptions underlying all the financial, cost and benefit projections.

The timeframe for the return on investment is determined by the size and the complexity of the project.

Consider the anticipated lifespan of the investment in terms of:

• Future demand for the business product or service to be delivered, which should have been assessed and identified in the strategic business plan.
• An assessment of the maturity, capability and versatility of the technology proposed.
• The financial breakeven point, particularly where the proposed solution is heavily technology-dependent.

Principle

Guideline

Governance is the process and structure to exercise overall control and direction of a project.

It defines the purpose of the project, sets strategies for attaining the purpose and gives authority for the use of resources to implement the defined strategies.

Governance provides the structure that links process, resources and the business strategies and objectives.

Good Governance ensures:

• Accountability for what is planned and implemented.
• That business aims are met.
• Balancing risk against return.

There is a Governance role within management.

Keep the governing body informed on:

• Expenditure against budget.
• Resource management.
• Progress against plan.
• Risks and their management.

Introduction of effective Governance principles provides a clear set of guidelines for the governing body and the management team.

It is vital to introduce effective Governance principles to:

• Provide for a clear allocation of responsibility and accountability.
• Ensure that the decision-making process at the Governance level is understood.
• Ensure that the information provided by the management team is appropriate to the decisions required.

Principle

Guideline

Every IT project has a formal management and reporting structure.

Set up the formal management structure:

• Decide on the most appropriate senior manager to sponsor the project.
• Appoint a project manager.
• Appoint the members of the Steering Committee.
• Define the project team requirements and appoint members of the team.
• Set up templates for consistent monitoring and reporting for the project.
• Document the process (and use it next time!)

Roles and responsibilities are clearly defined.

It is important to distinguish between:

• The Governance role of leadership, strategic direction, control and accountability.
• The Management role of administration and delivery.

Principle

Guideline

The Sponsor needs a strong vision for the project and must be able to influence senior management to commit resources to the project.

The Sponsor or Business Owner champions the project; chairs Steering Committee; facilitates resolution of issues at senior levels; holds or allocates project budget; is responsible for delivery of project within approved scope, timescales and budget.

The sponsor should be a member of the senior management team with responsibility for the system that will be the outcome of the project.

It is important that, if possible, the sponsor should be someone other than the Chief Executive. This helps preserve the objectivity of the Chief Executive to addressing the overall interests of the department and in managing project risk.

The Business Owner will select the Steering Committee, members of which will be key stakeholders for a particular project.

The Steering Committee is responsible for acceptance and sign off of deliverables and business outputs and will recommend continuation to the next phase on successful completion of all deliverables.

Members will have a business interest in ensuring the success of the project and be prepared to take personal responsibility to ensure a successful outcome to the project. They will provide thoughtful, constructive input into the project and commit the time required to attend and actively participate in the Steering Committee meetings throughout the project.

The inclusion of an external person on the Steering Committee, who brings technical or other expertise, can be valuable in providing a neutral view.

The governance role of the Steering Committee is to provide overall direction, guidance and support to the project, and to monitor the project to ensure successful delivery of expected outputs and outcomes within scope and budget.

Specific tasks include:

• Approving and prioritising Project Definition for project elements.
• Monitoring progress by exception.
• Reviewing and approving substantial changes ("Substantial" will be defined in the Project Definition for the project).
• Other tasks include:
• Monitoring the project progress, including sub-projects.
• Ensuring that proper risk assessment is performed and mitigation strategies are developed.
• Appointing the project manager and approving the team members.
• Approving project scope, budget, objective and plan changes within any delegated authority.
• Signing off the project deliverables at the relevant milestones.
• Confirming project cancellation, where necessary, in concert with the Chief Executive.
• Ensuring that the proper financial checks and professional balances are included.
• Ensuring that the project meets the department's statutory obligations and protects the Government's interests.
• Ensuring that the project delivers the required benefits.
• Reviewing and approving the quality assurance reports, including the project manager's recommended actions.

Principle

Guideline

The Project Director oversees the programmes of projects.

The Project Director may use a "Project Office" or another mechanism to co-ordinate and monitor the projects in the overall programme.

Each project in the programme will have its own project manager.

The Project Manager directs day-to-day activities of the project team.

The role and responsibilities of the project manager include:

• Reporting to the Steering Committee (normally monthly and/or at significant milestones for large projects).
• Day-to-day management of the project against the approved project plan, budget and scope to deliver the specified objectives and benefits.
• Ensuring the project is resourced properly and efficiently.
• Providing regular progress reports to the Steering Committee.
• Delivering project plans, budgets, scoping and resourcing requirements and changes to the Steering Committee for approval.
• Ensuring effective delivery of the business process changes, including documentation and training.
• Undertaking full risk assessments, and developing and implementing risk mitigation strategies as agreed by the Steering Committee.
• Providing full and proper quality assurance at regular intervals, and acting on the quality assurance findings, reporting to the Sponsor where appropriate.
• Managing all third parties contracted during the project life cycle.

The project team performs work to deliver outcomes required and report to project manager against plan.

A project team comprises business and technical specialists including where appropriate systems integration and risk management expertise.

A reference/advisory group provides technical and other advice to the project team as required.

Members of the reference/advisory group have specific expertise that is not required on a full-time basis and is called on as needed.

Principle

Guideline

The post-implementation review (PIR) is the responsibility of the project sponsor.

The post implementation review is undertaken after the project has been completed (usually after the warranty period).

The PIR reviews the strategic outcomes to which the project contributed and evaluates the actual benefits against the expectations specified in the business case.

This review will:

• Determine whether the benefits and time-lines, the project objective(s) and its critical success factors have been met.
• Determine how well the project has achieved the goals set out in the business case.
• Compare financial performance against the project budget.
• Highlight what has been learned so it can be incorporated into future projects.
• Identify other opportunities to add additional value to the system/project.
• Identify the strengths and weaknesses of the project for future reference and action.
• Make any other recommendations on the future of the system/project.

The PIR provides the impetus for changing existing standard models within departments for estimating effort and costs for IT projects. The revised model will be used for similar projects in the future.

Appropriate support is deployed to assist with the PIR.

Technical support to assist the review should be provided by the IT branch or IT provider.

The department's internal audit unit should be involved, especially where financial transactions are involved.

Include the supplier in the PIR process.

The deliverable from this stage is the Post Implementation Report.

Principle

Guideline

This phase of project management is when the project is defined, and is accepted to proceed by the department.

Form a Steering Committee comprising the sponsor (Chair) and a small group (see Section 4) to guide the process at a Governance level.

Appoint the sponsor - a senior business manager (preferably not the Chief Executive) who will be most actively involved in the outcome of the project.

The Project Definition is an 'overview' document, retaining this perspective of the whole project.

The Project Definition sets out the agreed vision that is the basis of a common understanding of the overall project goals and objectives, and its scope. It includes:

• Purpose and objectives of the project.
• Scope (including what is out of scope).
• Assumptions and constraints.
• Critical success factors.
• Risk analysis.
• Deliverables and acceptance criteria.
• Expected benefits.
• High Level Plan - including timescales, resourcing, estimated budget.

The Project Definition is the catalyst for Steering Committee approval.

After the Steering Committee accepts the Project Definition, the detailed Project Plan becomes the main management document of the project.

Approval of the Project Definition signifies the beginning of work on the project.

Planning begins!

Principle

Guideline

Thorough planning gets reflected in the smooth running of the project.

In this phase of project management:

• The project is defined in more detail.
• The project team is formed.
• The detailed Project Plan is prepared, including budget and resourcing needs.

The planning phase identifies the size of the project and enables the project to be broken into manageable 'chunks.'

Major IT projects should be broken down into modules or sub-projects, each lasting no more than six to twelve (6-12) months. Each module or sub-project is considered as an independent business case within the department's overall IT strategy.

Smaller stages are managed concurrently where appropriate.

The two part project plan has:

• A high-level overview plan for the entire project.
• Detailed working plans for the current and next phase of the project and sub-projects.

The level of detail required in both the Project Definition and the Project Plan should be scaled to reflect the size and complexity of the project.

If the project is broken into modules or sub-projects, the high level plan shows how each module is integrated into the overall picture.

At the beginning of the planning phase:

• The initial modules or sub-projects are planned in detail.
• Later dependent modules or sub-projects are planned at a high level.

Realistic resourcing helps projects to be successful.

It is important to be realistic about how much time each individual can put into a project. Total work utilisation of 75-80% is the maximum anyone should be allocated to work - on projects. Any more than 80% means there is no room for contingencies like unplanned work and projects inevitably will not be completed on time.

The detailed project plan sets out all tasks with timeframe, allocated resources and milestones.

Phasing projects into distinct and manageable stages with deliverables at the end of each phase enables the project team, and stakeholders, to see and acknowledge the achievements.

The detailed project plan is developed in conjunction with the supplier and includes:

• A description of each task.
• Resources needed to undertake each task.
• Milestones - expected dates of deliverables.

Accompanying the project plan is:

• An approved budget, financial plan and cash flow statement (month by month).
• A project quality plan that:
• Includes the quality control processes to be used on the project, such as peer review, design demonstrations and testing.
• Sets overall quality target for the project deliverables.
• Specifies quality assurance roles for both the team members and an external quality assurance specialist.
• A communications plan that sets out:
• The message.
• Who needs to hear the message and when.
• How the message will be delivered.
• Who prepares and delivers the message.
• Date action was taken.
• A risk management plan that includes a detailed risk assessment that identifies all risks that could jeopardise the project outcomes.
• The risk assessment report should cover budget variances, resource problems, inadequate management support, unrealistic timeframes and "scope creep".
• Use the risk assessment to prepare a risk management plan that recommends treatment for the identified risks. The risk management plan will include options for accepting, eliminating or managing risks and will be signed off by the project sponsor.
• Training plan.
• Installation plan.
• Testing plan.

A plan for the programme of related projects links them together.

The programme plan identifies:

• Scope of the programme.
• Dependencies between projects.
• Estimates for the entire programme.
• Fixed costs for individual projects, rather than the entire programme.
• All contingency costs associated with individual projects rather than the programme as a whole.

• As well as reflecting the expected timing of costs and benefits, the analysis in the business case should estimate and reflect uncertainty and risk.
• Projects, which update technology without introducing business changes, may not appear to offer tangible benefits. These are often referred to as "Infrastructure Projects". However, such a project may be an essential stepping stone to:
• Establishing an environment in which modular projects are able to be introduced.
• Reducing the total cost of ownership of technology.
• Reducing the business risk, or exposure to IT failure, or loss of data or system availability.

Risk management is an important part of the planning phase.

During project planning it is desirable to manage risk by specifying exit points (or "off-ramps") where the project can be terminated early while still obtaining identifiable and worthwhile benefits (if any) or at least minimising further costs that produce little or no benefits.

These off-ramps to terminating the project (and funding) early may be triggered by:

• Significant changes in the environment which affect the project; or
• Specific issues or failures to achieve milestones during the project.

Where possible, criteria for these exit points should be set in advance, included in the business plan, and monitored by the Steering Committee.

Principle

Guideline

Implementation is planned in detail.

This ensures that the agreed deliverables will be produced, while at the same time managing the risk elements.

The methodology selected for implementation fits the purpose of the system to be developed and implemented.

A systems development methodology provides a disciplined approach to the in-house work required to implement the IT project.

The methodology defines the milestones where the project is reviewed and approval given to proceed to the next stage.

Completion of the project is marked by formal closure.

This covers the orderly termination of the project and makes sure that:

• The business unit involved is satisfied with the results of the project.
• Processes are in place for system maintenance.

During this stage the project operation is closed down and responsibility for ongoing tasks is handed over to the appropriate function within the department.

The business unit formally accepts the system and confirms that:

• The project is complete and the systems are available for use.
• The systems are operational and meet requirements and specifications.

Principle

Guideline

Government must be seen to be getting best value for money spent. There is an obligation to ensure contestability in procurement.

The procurement process follows the Guidelines for Contracting for Services (CO (92) 15) or relevant departmental guidelines, and is consistent with the Government Purchasing Policy which took effect from 1 July 2001².

A common approach to procurement that is open to external scrutiny is to request proposals from vendors.

Once a viable approach has been identified, vendors capable of meeting the requirements need to be identified.

It is best to follow a staged approach, eliminating unlikely candidates at each stage, while at the same time ensuring transparency and contestability.

The staged process includes:

• ROI - Registration of Interest.
• RFI - Request for Information.
• RFP - Request for Proposals.

The ROI process:

• Develops a high level outline of the project.
• Offers vendors the opportunity to indicate their interest by sending contact details.

The RFI process:

• Prepares a more detailed outline of the project.
• Offers those vendors who responded to the ROI the opportunity to respond.
• Evaluates responses according to pre-defined criteria.

The RFP process:

• Prepares a fully documented set of requirements.
• Is sent to vendors whose RFI responses were evaluated as being able to meet the requirements for the new system.
• Evaluates responses.

Consider the vendors in the RFP process.

Vendors form a critical part of the RFP process. They need sufficient time to prepare a proposal that will take into account the client's needs.

• Allow sufficient working days for a response to the RFP.
• Consider an appropriate process that enables clarification of the content of the RFP prior to the preparation of the proposal.

The RFP process is transparent and is able to assure Government of open contestability by enabling a fair and thorough comparison of vendors' proposals so the department can choose the best option to meet its needs.

Develop and document the evaluation strategy and identify the evaluation team as part of preparing the RFP.

Evaluate the proposals in a two-stage process.

The first stage evaluates each proposal against key criteria and eliminates those tenders that do not meet requirements.

Successful tenderers are short listed at this point.

The second stage is a detailed evaluation of the qualifying proposals that were short-listed to select the best solution.

This evaluation of the final contenders will include presentations and/or product demonstrations and detailed reference checks with current and previous clients of the preferred vendor(s).

The evaluation report is the deliverable from this process. It contains a recommendation for the preferred supplier.

The evaluation report is approved by the Steering Committee.

Principle

Guideline

Measuring performance is an ongoing project management task.

Regular progress reporting enables quick identification of deviations to the plan.

Use the project implementation plan to track progress on tasks. Update this plan to meet progress reporting requirements.

The project manager prepares a progress report to the sponsor (cc to project team) weekly. The Steering Committee gets a summarised progress report less frequently (monthly or quarterly - depending on the length and complexity of the project).

The project milestones will form the basis for the review dates.

Progress reports will include:

• A management summary on progress against the plan, especially milestones reached and major issues.
• Tasks completed in period under review.
• Tasks for coming period.
• Variances and planned corrective actions for slippage.
• Issues and actions to remedy (for issues register).
• Analysis of risks resulting from slippages.
• Actual costs vs budget.
• Progress against communication plan.

Variances between actual and anticipated progress may require changes to the project plan.

Formal reviews throughout the project ensures common understanding of progress.

Consider a Project Control Review within two months of the project initiation to confirm that:

• All plans are in place.
• Financial policy and details are set up.
• There is adequate resourcing.

A Midpoint Review enables a further overview check on progress. This review should confirm:

• The expected business outcomes will still be met.
• Any changes to the expected business outcomes over the period under review.
• The impact of such changes on the project.

Principle

Guideline

The contractual relationship with the supplier is critical to the success of the project.

Contract negotiation is an early task in the project plan.

The contract(s) is/are finalised or an interim agreement is signed covering contractual arrangements before the work actually commences.

The most successful projects consolidate the supplier and client risk processes, sharing the identification and management of all project risks.

Activities related to managing risk may be made the sole responsibility of either party, but both parties should be aware of all risks and the manner in which they are being managed.

The contractual relationship is a win-win situation for both parties.

Important components of the contract include:

• A clear statement of the responsibilities on each party for roles, deliverables, timeliness, resources and project and risk management. These will cover each phase of the project.
• A payment schedule that links progress payments to completion of specified deliverables and/or major milestones that need Steering Committee sign-off.
• A payment schedule that includes an amount to be retained until the end of the warranty period.

The contract for a large project should be divided into distinct phases. It will provide no commitment to proceed to the next phase without approval from the Steering Committee.

It is essential that the Chief Executive or another senior executive approve all contracts with external organisations or vendors before signing.

The strategy for the relationship with vendors is focused on performance during the implementation, not the business outcomes.

Partnership contracts are developed where risk is jointly managed.

Exceptions gaps are flushed out during contract negotiations.

Partner relationships are clearly defined in the beginning.

Consequences of non-performance by either party are clearly defined in the contract.

A formal arrangement for on-going support minimises risks from poor or non-performance of the system.

After the warranty period, a Service Level Agreement is required to ensure the vendor provides timely, and technically sound support for the system.

Good partnership relationships become very worthwhile following implementation.

Fixed price contracts work best where the requirements are well defined and the time required to implement is relatively short.

Fixed price contracts can minimise time and cost over-runs. Features include:

• A fixed price demands fixed requirements that will not change (strong change control will be needed by both client and vendor).
• Clients have an assured cost of development up-front.
• Expectations are set for both parties.
• A single vendor takes total responsibility for the success of the project.
• Suppliers face penalties if the project is not completed on time.
• Vendors tend to build in a risk premium into their pricing.

Incremental contracts can be provided on a fixed price basis for large projects where the components are broken down into a series of smaller projects, each of which is priced separately.

Features of incremental contracts include:

• Emphasis is on improving business processes through the use of information technology.
• The vendors have accurate information at each phase on which to prepare pricing.
• Need for risk premium eliminated.
• Hardware is not purchased until it is needed, thus taking advantage of the latest technology.
• The project is able to be undertaken in more manageable modules.
• Clients are not tied into one vendor throughout a lengthy project.

However, the client will not know at the beginning of the project what the total cost will be. It may be more difficult to get financial approval.

Principle

Guideline

Effective risk management is concerned with opportunities (positive outcomes) as well as hazard management (negative outcomes).

The Governance in the management of risk lies in assessing and treating risks.

High-level potential risks are identified in the Project Definition. In the Project Plan, they are assessed for potential impact, and effect on other projects.

The Steering Committee will define the areas of risk, eligible risks and the boundaries for elements of risk.

In setting these boundaries, Governance will take into account wider considerations than the specific project.

Political considerations, financial implications on other areas of the business, and various project priorities will affect the definition of risk areas for a project.

An analysis of risks and a risk management plan undertaken at the beginning of the project, highlights areas of concern that will need close attention during the project.

The risk assessment report should cover budget variances, resource problems, inadequate management support, unrealistic timeframes and "scope creep".

The risk management plan:

• Includes a detailed risk assessment that identifies all risks that could jeopardise the project outcomes.
• Recommends treatment for the identified risks.
• Includes options for accepting, eliminating or managing risks.
• Is signed off by the project sponsor before the project commences.

Principle

Guideline

Quality assurance (QA) is an integral part of the project, not an add-on at the end.

• On all major IT projects, departments will be required to provide regular, independent quality assurance reports to the Chief Executive on key issues and risks arising from the project.
• Departments will be required to forward a higher-level version of the independent assurance reports to the SSC and Treasury for monitoring purposes.
• Make provision for external QA of off-track projects, reporting to the monitoring team but charged to the department.
• The Ministers of State Services and IT will receive a regular report on the risks associated with IT projects across the Public Service.

A review programme for monitoring the communication with all stakeholders should be agreed during the formative stage:

• These project statements will summarise the progress of the project to that point.

External QA is included, that role reporting directly to the Chief Executive.

QA recommendations are implemented.

Provisions made in the implementation plan are undertaken.

Departments consult with monitoring agencies on the Independent QA assessor and the Project Definition for the Independent QA.

Principle

Guideline

Good consultation and communication protocols will increase the commitment to, and acceptance of, the recommendations and actions of the project.

Communication is about managing the relationships within and external to a project. These require planned formal and informal communication with all stakeholders - internal (including project team members, other staff in the department) and external.

These protocols are paramount in project management.

Consultation may be part of the activity of the project) or aspects of project management (e.g. information gathering). The effect of some types of consultation on the project timeframe is important.

Be realistic about how long it is likely to take for the consultative process, and build the necessary time into the project plan.

Relevant information is communicated to the appropriate people through an appropriate medium in a timely manner.

Details of the project must be communicated throughout the project.

A communications plan is produced for every stage of the project including the development of the business case.

A communications plan sets out the message, its intended audience and mechanism for timing and delivery.

It is a simple yet effective technique for ensuring openness and for implementing the communication aspects of 'damage control' should your projects require such action.

Changes to the project must be communicated to the different management and Governance levels of the project.

Project communication may be formal (e.g. brief, mandatory regular meetings) or informal (e.g. 'chats in the corridor'), written or oral, paper-based or electronic (e.g. on the Intranet).

Principle

Guideline

Good change management practice ensures that the impacts upon the organisation and its people are identified and managed.

Develop a change management strategy and plan at the initiation phase. This plan should include:

• Identification of the main organisational impacts or potential impacts of the project and how these will be addressed.
• Identify the processes that will be used to assess during the design phase the scale of changes to processes, future skills, structures and ways of working.
• Identify the consultation requirements to satisfy employee contractual arrangements and the department's human resources policies.
• Specify the processes for managing and communicating the impact of changes upon departmental clients or other key stakeholders.
• Link the change strategy to the communication and consultation processes by stating the principles that will guide these activities.
• Set out the approach to training and how this will be developed and delivered.
• Allocate responsibility within the project team for oversight of change management issues.

Obtain Steering Committee and Project Sponsor sign off to the change management strategy.

Communicate change management issues and their resolution to the Steering Committee, to the project sponsor and in normal project reporting.

Principle

Guideline

The system specifications meet the business requirements.

The business unit responsible for the final system prepares a detailed set of business requirements.

These requirements will form the basis for developing the functional and technical specifications.

The technology solution meets the system specifications.

Build in proof-of-concept (or pilot) to the business case, Project Definition, project plan and costing.

The proof-of-concept is a separate phase:

• No further commitment is made to proceed until this phase is tested, evaluated and accepted.
• Evaluation criteria must reflect the specifications.

New, unproven technology is not the first choice for new systems.

Investigate all possible options for the required technology, including systems that have been developed for other organisations in New Zealand (especially other departments) or overseas for similar purposes.

Consider if the business requirements will be best met by:

• A package purchased from a vendor.
• Custom-development either in-house or by an external software development company.
• A combination of package acquisition and custom development.

When solutions involve unproven technology, include:

• External peer review in the selection and evaluation processes.
• Proof-of-concept as a critical phase in the development process.
• Strict change control once core architecture solution is finalised.

Be aware of the risk of:

• Withdrawal of vendor support for a major component (check the contractual arrangement).
• A component (or components) that does not perform as expected.
• Substitution recommendations.
• Scarce resources or expertise for particular technical components.

Management strategies include:

• Selecting proven components.
• Including a technical substitution clause in the contract.
• Allowing specific contingency for technical problems.

IT infrastructure and applications' development platforms are separate.

Look for evidence that:

• Large IT infrastructure is 'unbundled' from applications solutions.
• The applications' solution is divided into modules of discrete business objectives.

Use 'off-the-shelf' software applications (packages) where possible.

To provide the greatest certainty of what is being purchased and the requirements to implement it, a package solution should always be considered.

Assessment of the choice of a package solution should consider:

• Identification of core and non-core requirements.
• Closeness of fit with core requirements.
• Trade-off or risks of custom-built solution against the receipt of a sub-optimal package solution.

Principle

Guideline

A systems development methodology provides a disciplined approach to ensure that the work required to implement a successful technology project is carried out.

There are a number of accepted systems development methodologies available.

The choice will depend on the organisation and its development environment.

All members of the development team must follow the selected methodology.

A traditional methodology will include the following steps:

• Systems definition.
• Financial justification.
• User requirements analysis.
• System specifications.
• System design.
• Software development.
• Testing and implementation.
• Documentation.
• Training.

Modern system development approaches include a proof-of-concept phase.

A more modern, risk-averse approach that is more commonly used includes:

• Proof-of-concept cycle,
• Capture business requirements.
• Define goals for proof-of-concept.
• Produce conceptual system design.
• Design and construct the proof-of-concept.
• Produce acceptance test plans.
• Conduct risk analysis.
• Make recommendations.
• First build cycle,
• Derive system requirements.
• Define goals for first build.
• Produce logical system design.
• Design and construct the first build.
• Produce system test plans.
• Evaluate the first build.
• Make recommendations.

• Second build cycle,
• Derive subsystem requirements.
• Define goals for second build.
• Produce physical design.
• Construct the second build.
• Produce system test plans.
• Evaluate the second build.
• Make recommendations.
• Final cycle,
• Complete unit requirements.
• Final design.
• Construct final build.
• Perform unit, subsystem, system, and acceptance tests.
• Accept system.
• Implementation.
• Documentation.
• Training.

Principle

Guideline

A post-implementation review is conducted after a 'warranty' period.

See Section 4.

New technology testing will not prototype a full system.

Vendors may claim that developing a proof-of-concept equates to developing the full system. The following safeguards against this by:

• Including this scenario in the risk analysis.
• Ensuring that full functionality equivalence is evaluated by the proof-of-concept.
• Preparing a strategy to counter such claims.
• Clarifying the different level of detail required for user requirements and detailed specifications.

Principle

Guideline

A formal change control process ensures that changes to the system that were not included in the agreed scope are justified, planned, coordinated.

Any proposed changes that may affect the delivery of the system as defined in the business case, Project Definition, project plan and other project documents, must go through a change control process before approval.

The assessment for each change request will ensure that the impacts on the whole system are identified, including:

• The original business case.
• Cost/benefit analysis.
• Risk management strategy.
• Implications for job design, skill mix, health and safety, consultation processes.
• Staffing requirements (including accommodation - space, furniture).
• Implementation timing and cost factors.
• Introduced in a way that prevents or minimises disruption to services and the business.

The change control process is outward looking:

• to the rest of the project.
• to the rest of the organisation.
• outside the organisation.

The change control assessment process will consider the impact on:

• Existing business processes.
• Staff in the organisation outside the project.
• Other current or planned projects.
• Communications to target audiences.
• Any other major changes happening in the organisation that may impact on or be impacted on by the changes to the project.
• The general public and any social environment effects.

Principle

Guideline

It is necessary to migrate data from existing systems.

The business (user) requirements will identify the data from existing systems.

Build time and cost factors for data migration into the business case, Project Definition, project plan and budget:

• Consider data conversion needs early.
• Consider impact on other projects and business as usual.
• Acknowledge and identify all migration costs.

Installation of new hardware required careful management.

The transition from existing hardware to new hardware (e.g. servers) must be managed so that there is no or minimal disruption to business-as-usual:

• Specifically plan for the migration or transition.
• Communicate the plan to all stakeholders (build into communications strategy and plan).
• Acknowledge and identify all transition costs.
• Balance the cost of working out of hours (project team and vendors) with disruption to business as usual.

Principle

Guideline

Acceptance testing is the final test action prior to deploying a new software solution.

The goal of acceptance testing is to verify that the solution is ready and can be used by the end-users to perform those functions and tasks the solution was built to do.

Confirm that the acceptance process is comprehensive and that the testing process will meet the business needs.

Once the system is accepted, any further changes are subject to another round of change controls and management (usually including additional costs).

The types of tests vary with the system being developed.

In general, tests will be set in some or all of the following groups:

• Functional (the system does what was expected).
• Volume (number of transactions the system will deal with at any one time).
• Performance (speed of access with defined volumes).
• Usability (ease of use by end-users).

The tests need to:

• Be based on the specific functions sought in the system.
• Be based on expected performance with defined volumes of transactions.
• Show consistent functionality and performance over repeated tests.
• The criteria need to be requirements-based and define the expected performance levels.

The test plan should define sets of completion criteria for each set of tests.

Acceptance testing is a highly managed process.

The tests are planned and designed carefully and in detail:

• The test cases chosen should be representative of all known cases that will use the system.
• It is important not to deviate in any way from the chosen test cases.
• Representatives of the end-user organisation perform the acceptance tests on a test system or using dummy data.
• It is important that the tests are designed around what the new system is designed to do.
• End users doing the testing should not get sidetracked into comparing the new system with the legacy (existing) system.

Disadvantages include:

• Significant resources and planning required.
• The tests may be a re-run of system tests. (Note that the system tests and the acceptance tests are run from a different perspective. The supplier runs the system tests; the client runs the acceptance tests).

Resources for acceptance testing frequently are not under the control of the project and may be constrained.

Principle

Guideline

Full system documentation is an essential component of any new system.

The project plan must include tasks, time and costs of preparing system documentation.

The format of the documentation may vary (e.g. hard copy, electronic, Web-based) and should be agreed at the planning phase.

Lack of documentation, especially for customised developments becomes a major risk when the project is completed and the developer is no longer accessible.

A training programme for system administrators and for users maximises uptake and subsequent use of the new system.

Training is a very common omission from project planning and implementation.

A training programme should be included in the project planning.

Once the development is completed and has been accepted, the client is responsible for maintenance.

Maintenance can be:

Provided in-house.

• Contracted to an external company.
• The maintenance engineers or system administrators must be thoroughly trained in the new system to minimise business disruption when the new system is in use.

User training:

• The value to the department of the new system can plummet if users are not trained to use the new system.
• Training needs to be provided at different levels for different users.