Annotated Bibliography & Problem Statement

gnsv.srinivas

Agile_Governance_and_Audit_An_Overview_for_Auditor..._----_Chapter_9_Handover_to_the_Business.pdf

Home >Business & Finance homework help >Operations Management homework help >Annotated Bibliography & Problem Statement

CHAPTER 9: HANDOVER TO THE BUSINESS

Overview

In this chapter we will consider the process for finalising

deliverables and handing them over to the business. When

an Agile product is delivered it needs to be implemented

and used. One project I looked at, a hospital catering

system, had been completed for two years and was not

being used. The software had been purchased and installed

using capital budget remaining at the year end. To be used,

it needed further revenue expenditure to enable the catering

department to input recipes and menus. They did not have

the resources to be able to do this and so the system was not

used and the benefits could not be achieved!

We will consider:

 how and why individual project deliverables may be grouped into releases.

 what the business needs to do to ensure it can accept and use the product to achieve the business benefits.

 what IT needs to run the product.

Needs & Risks

Build & Test

Give to Users

GOVERNANCE AND CONTROL

Useable Product

Idea Define Reqs

Wright, Christopher. Agile Governance and Audit : An Overview for Auditors and Agile Teams, IT Governance Ltd, 2014. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=1778767. Created from harrisburg-ebooks on 2020-11-16 07:34:05.

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

 what the controls and audit community need from the implementation.

 how to audit the handover of the product to the business.

 conclusion.

Release management

Agile produces incremental deliverables that can be used by

the business. For small self-contained projects the product

may be implemented and used immediately. However, there

may be good business and Information Systems (IS)

department reasons for delaying the implementation and

grouping the release of software products together. These

reasons can include:

1. The cost, overhead and disruption of implementing

software in production (for example, it may be necessary

to withdraw a frontline customer helpdesk to install a

relatively minor management reporting change).

2. Business or process changes may be required before the

product can be used (for example, a website may be

ready to be used but the customer product or service to

which it relates has not yet been launched).

3. Interdependencies on other deliverables/projects/business

changes.

4. Avoidance of ‘no fly zone’ around the year end or other

high risk event when implementations or major changes

are blocked. For some implementations it may also be

necessary to avoid month end or other periods of high

activity (try implementing a new stock and delivery

system into a toy manufacturer during the run-up to

Christmas!). The use of Agile enables the project to be

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

broken down so that small parts of the software can be

developed and deployed for lower risk areas during these

times. This will reduce the time length for the project as

a whole.

A release may consist of a technical IS code drop and a

business ‘Go Live’ simultaneously, or the two may be kept

separate. For example, any data migration or other business

readiness activity may occur sometime after the programme

code has been installed in the live production system. A

formal Go/No Go decision is likely if the drop/Go Live are

seen as high risk. For the full Go Live decision,

confirmation may be required on the following readiness

factors:

1. Code readiness and test results

2. User documentation and training

3. User role mapping (including assurances regarding

segregation of duties)

4. Risk, compliance and control readiness

5. Data conversion/migration (if required)

6. Any dual or interim processing requirements

Business readiness

The business will need to make preparations to be ready for

the Go Live decision. If Agile has been properly applied,

the business should be aware of the impending change. The

business representative on a project should be a strong

champion to ensure the product will be implemented and

used effectively. Other key stakeholders will have been

included in user acceptance testing and reviews at the end

of development (e.g., ‘Show and Tell’ sessions).

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

The areas to be covered will depend on the project, but

typically will include:

1. awareness and training for both front and back-office

impacted teams, including dealing with any objections or

resistance.

2. identifying any software or processes currently used that

can now be abandoned.

3. agreeing KPIs and other management indicators to provide

assurance during the early stages of implementation, to

confirm the embedding of arrangements and ensure

previously identified benefits are being achieved.

IT readiness

The IS/IT function will also need to accept the new

software so that it is included in frameworks for change

control, IS security and incident management. This will

include ensuring the new software is included in all backup,

incident logging and change logs and complies with any IS

requirements prior to code drops and data migrations.

Early involvement of the IT department enables it to:

 ensure there will not be an adverse impact on its own control framework.

 plan release and data migration activity alongside other projects and developments.

 plan the impact on the overall systems architecture and identify its own non-functional requirements for testing.

 prove that the new software integrates with the existing architecture and that it can operate effectively.

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

 prepare for Go Live, making sure any resources and service contracts are in place with appropriate service

levels.

 ensure all systems operating procedures are updated, that IT staff are given the necessary training, and backup and

disaster recovery plans are updated for the new software.

If the department has been given sufficient warning about

the change, it should be able to participate properly in the

Agile process. If not, it will be falling back on waterfall and

possibly undermining the Agile Principles.

Controls readiness

During an Agile project, if the project team has been made

aware of control requirements, it should have built into the

system either embedded controls (e.g., to check data as it is

entered into a screen for accuracy and completeness) or the

reporting/workflow required to enable manual controls to

operate. The aim is for the project not to adversely impact

the control compliance of the organisation. These impacts

could be due to:

1. inappropriately designed controls.

2. inability to operate controls after Go Live.

3. failure in the general IT controls environment that

supports the system.

There may be benefits available from the software product

that was not originally envisaged. For example, you may

install Microsoft ®

Excel ®

to analyse data. The software

contains additional features that can also be used to present

the data in charts and so on.

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

Controls should be included as part of the general handover

of the product to the business. If controls are not revised,

the next time the controls framework is tested or audited it

will fail. Worse still, failing controls could lead to financial

loss, fraud or regulatory fines.

Whose responsibility is it to ensure controls are delivered and

implemented?

A. The project team

B. The business representative on the team

C. The business/operational IT

D. Internal audit

Like most controls questions the correct answer is ‘It depends.’

The project team is responsible for translating requirements

and design into workable product, including testing to

prove the design. Business is responsible for accepting the

product, which may include additional testing to ensure

requirements have been properly translated.

If there was effective business membership of the team (as

there should be), controls should be seen as an integral part

of the deliverable and hence included in any general plans

for integration. This includes ensuring:

 control owners are trained to operate any manual or IT dependent controls.

 controls are documented in the normal monitoring tools and reviewed as a part of the control framework.

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

Auditing business handover

Audit objective

To ensure management has adequate controls and evidence

so that functionality, processes and controls can be operated

effectively and maintained by the business post Go Live.

Audit risks

The main risk is that the delivered product is not fit for

purpose as:

1. The functionality does not operate in the live environment

as intended.

2. The associated processes are not operated, leading to

controls failures.

3. Controls are not operated, maintained or tested effectively.

Audit approach

While the audit objectives and risks for business readiness

are broadly similar for waterfall and Agile, as we have seen

the documentation and evidence under Agile may be

different.

The auditor should ascertain the following by enquiry and

observation:

1. Does the product operate in the live environment as

designed?

2. Is there adequate evidence to support good control of the

following?

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

 Migration – that is, all sources of data have been

identified and mapped with plans in place for

controlled conversion and verification.

 Go/No Go – this will partly be based on test evidence,

clearance of issues and bugs, and other proof that the

product meets user requirements and stakeholder

expectations.

 Role mapping

3. Do the controls operate effectively? Are the following

aware of their responsibilities for the new software

product?

 control operators

 control owners

 governance risk and controls function

Conclusion

By ensuring the delivered product is implemented and used

effectively there is greater assurance that the desired

business benefits will be achieved. Products not used are

worthless to the business.

As Agile releases are incremental, it is necessary to ensure

releases are managed effectively. Ideally software will be

released as soon as it is completed; however, in my

experience on large projects or programmes this can be

some time after the software has been completed and so the

project team may no longer be available to answer any

queries.

The business needs to be trained and briefed on how to use

the software and understand and implement any changes

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .

9: Handover to the Business

required to processes. The same applies to IS/IT as they

will need to operate and maintain the new system. Controls

and compliance will also need to take account of the

change. By ensuring all of these arrangements are in place

the auditor will be helping the organisation to obtain full

benefit from the investment in the development.

C o p yr

ig h t ©

2 0 1 4 . IT

G o ve

rn a n ce

L td

. A

ll ri g h ts

r e se

rv e d .