Annotated Bibliography & Problem Statement

gnsv.srinivas

Agile_Governance_and_Audit_An_Overview_for_Auditor..._----_Chapter_4_Project_Initiation_and_Risk_Assessment.pdf

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

CHAPTER 4: PROJECT INITIATION AND

RISK ASSESSMENT

Overview

The initial phases of any project, waterfall or Agile, are

important to set the scope of the project and ensure

commitment from all concerned to achieve the desired

outcomes. For Agile projects these project initiation and

risk assessment phases are likely to be less formal than for

waterfall, with the aim of achieving quick decisions and

getting started on product development rather than

documentation delivery. However, it is still necessary to

ensure the project is desirable and will meet specific

business needs. Given the use of Agile for cost reduction it

is more important than ever to ensure the project is feasible

and cost effective. In this chapter we will consider:

 project initiation.

 risk assessment.

 how to audit initiation and risk assessment.

 conclusion.

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:33:26.

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 .

4: Project Initiation and Risk Assessment

Project initiation

All projects have a starting point. Someone has an idea,

which might be driven by innovation or the need to update

software. At any one time there will be many of these

within an organisation. There can often be more ideas than

resources to complete them.

Given the flexibility of Agile it would be possible for large

numbers of projects to start in different parts of the business

with little or no overall business benefit. Businesses need to

control where they use their limited resources, by

considering whether these projects:

 have potential conflicts with other projects. For example, sales may want to launch a new range of products at the

same time as compliance is under pressure to reduce the

range of products marketed and their complexity.

 are trying to achieve the same or similar objectives or outcomes.

 could impede the business as a going concern.

 could conflict with regulatory or compliance requirements. For example, in Sarbanes-Oxley registered

companies there is usually a ‘no fly’ zone around the

financial year end, to prevent projects impacting

financial reporting, going live and impacting audit

compliance.

Senior management therefore need a mechanism to review

and approve projects before they commence and then

monitor them as they progress. This is the basis of

project/programme governance.

The project team needs a clear understanding of what it is

intending to achieve, and the business stakeholders need to

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 .

4: Project Initiation and Risk Assessment

agree that there is a business case to proceed. I was once

asked to review a major digitisation project for a large

travel operator. There were six major stakeholders for the

project and I asked them all the same questions regarding

the project objective and the channels to be used (mobile

phone, internet, TV, etc.). All gave completely different

responses. How can a project be successful if it is not clear

what it is for? This needs to be agreed by the key

stakeholders and communicated to all involved in the

project.

A traditional approach is likely to involve a process of

consultation, development of documentation and then a

cycle of issuing drafts and convening meetings. The output

may or may not be widely communicated to the project

team and other interested parties. This approach can be time

consuming and may take the project in a completely

different direction.

The agreement of a vision for a project can be missing from

an Agile project. Some project teams put the argument that

Agile is about full delegation to project teams. In my

experience this is incorrect. The Agile project team should

have delegated responsibility for agreeing how it will

deliver the product; however, the business and key

stakeholders MUST agree the objectives of the project and

its business case. To summarise:

Stakeholders decide ‘WHAT’

Agile project teams decide ‘HOW’

The best approaches for agreeing the vision for Agile

projects involve short stand-up meetings of the people who

have the idea and the stakeholders impacted. Using brown

paper or one of the modern automated presentation tools,

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 .

4: Project Initiation and Risk Assessment

they create a business case, with specific, measurable,

achievable, relevant and timely (SMART) objectives. Once

agreed, this is then presented in the form of a wall chart on

either a noticeboard or the intranet sites so it can be widely

shared. Publishing in this way also fixes and agrees the

project’s objective.

Risk assessment

From a risk and controls perspective the project team needs

to identify the risks associated with the Agile project and

also make a case for including risk and controls

considerations during the project lifecycle.

All organisations should have their own arrangements for

risk assessment. In the UK and US these are likely to be

based on the COSO 2 framework. At a strategic level the

stakeholders will consider the risks likely to impact the

organisation. This assessment may include political,

economic, social and technological (PEST) considerations.

Under the technological heading it is highly probable that

the organisation’s executive board will be interested in new

projects that will change the business.

For any project, the auditor will be interested in how the

financial, operational and regulatory risks are addressed.

The same principles apply for Agile, although as we have

seen the extent and documentation for an Agile project are

likely to be lighter.

2 COSO – Committee of Sponsoring Organizations of the Treadway Commission

provides frameworks and guidance on enterprise risk management, internal control and

fraud deterrence.

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 .

4: Project Initiation and Risk Assessment

There are also specific Agile risks. The auditors George

Westerman and Richard Hunter refer to the 4 As (see ‘IT

Risk’):

 Availability.

 Access

 Accuracy

 Agility

The first three are generic risks found in a number of controls

frameworks. Availability is about ensuring the system and data

can be used by the business and includes disaster recovery and

capacity management. Access, sometimes referred to as

confidentiality, is about ensuring only authorised users can

access the data and system. This will include user access,

passwords, firewalls and segregation of duties. Accuracy in

this context includes completeness of data and verification of

data entry and processing, including key interfaces.

The fourth, Agility, is not usually included in traditional

controls frameworks. Agility relates to the organisation’s

capability to respond promptly and effectively to change.

Organisations cannot stop the flood of technological,

political or competitor change – but they can, however,

decide how they will respond. Organisations with low Agile

risk are more able to respond quickly and positively to

changes, enabling them to:

1. develop and sell new products.

2. scale systems and incorporate changes.

3. adapt their organisational structure.

The auditor needs to be aware of Agile risk to ensure their

reviews and recommendations do not impede the

organisation’s capability to respond to change.

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 .

4: Project Initiation and Risk Assessment

In a fast-changing world the risk of a project not being

Agile can be as great as being too Agile (e.g., bookshops

versus online as described in Chapter 1).

The characteristics of organisations with low IT Agility risk

are that they are better able to:

 acquire and integrate new applications, products and processes.

 scale solutions as the organisation grows or shrinks.

 outsource or transfer services.

 adapt to changing customer market demands or technological changes.

An Agile risk audit can also help to identify improvements

in the current controls framework and compliance

monitoring process. I was involved with one project

(C$8m) where the entire cost of the project was covered by

cost benefits from reducing the cost of control and

compliance. Monthly detective controls in more than 100

different locations were replaced by single centralised

preventative processes and controls. Instead of teams of

people producing and reviewing reconciliations before the

submission of monthly reporting we introduced automated

validation checking of data obtained from other computer

systems.

By reviewing the existing (‘As Is’) control issues as part of

the Agile project risk assessment opportunities can be

identified to:

1. automate controls.

2. overcome any existing controls gaps, poor control or

audit weaknesses previously identified.

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 .

4: Project Initiation and Risk Assessment

3. ensure adequate controls are built into the product as it is

developed rather than have the disruption and additional

costs of building them later.

Improved controls mean reduced costs of controls

maintenance and compliance. The best way to achieve this is

for the upfront involvement of risk and controls/compliance/

audit representatives. Input from controls specialists is most

effective where there is provision for their involvement

throughout the project. This could be via high impact, fun

lunch and learn sessions. Yes, controls really can be fun.

We ran one such session for project teams where we used

prizes, games and music to engage the audience while

educating them on why controls are important and the risks

faced by other projects elsewhere and at the organisation.

The sessions were well received and we were asked for an

encore!

How to audit project initiation

Audit objective

To ensure management has adequate procedural controls

and evidence for decisions regarding:

 project inception and choice of approach.

 the business benefits required and how these can be achieved.

 the risk/compliance implications of the project.

 phasing of work and benefits including impact on other planned changes.

 level of governance required.

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 .

4: Project Initiation and Risk Assessment

Audit risks

The main risks for auditors to consider during a review of

project initiation and risk assessment are that the project

will not:

1. have adequate management of Agile risks.

2. produce a product that is feasible, governable or desirable.

3. complete on time, budget or to the quality required.

4. meet business requirements or strategic expectations.

5. facilitate ongoing compliance or overall risk management.

6. fit in with the current or future overall systems

application and business architecture.

Audit approach/questions

Through observation and enquiry, identify:

1. How has this Agile project been assessed to ensure

specific Agile risks are adequately managed?

 Review the formal risk assessment (e.g., guidance can

be obtained from ‘Risk Analysis for Agile’ by Gary

Mohan).

 Interview senior project management.

 Assess specific risk mitigations for adequacy and

monitoring mechanisms.

2. How has this Agile project been assessed to ensure it is

feasible, governable and desirable?

 Review the feasibility study (does it adequately cover

technical, budget, time, management and other

change constraints?).

 Review the governance plan for delegation to Agile

teams, reporting and checkpoint reviews.

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 .

4: Project Initiation and Risk Assessment

 Is there evidence of approval for objectives, timelines

and realistic expectations/benefits?

3. How has this Agile project been assessed and approved

to ensure it is likely to complete on time, budget and to

the quality required?

 Review the project plans and estimations if available

(these will be at a high level for Agile as they will be

finessed as the project proceeds).

 Review team communications and interview key

project team members.

 Review project communications.

4. How has this Agile project been assessed to ensure it will

meet business requirements and strategic expectations?

 Sign-off by senior management, including key users

and IS.

 Experience of similar projects, including lessons

learned.

 Clear demonstration of understanding of an Agile

approach and its implications.

5. How has this Agile project been assessed to ensure it

will not negatively impact compliance or overall risk

management?

 Formal compliance review documented.

 Training and awareness of compliance for all project

staff (including SOX, etc. if relevant).

 Authorisation to proceed, including identification of

touchpoints, for risk and compliance teams.

6. How does this Agile project fit into the overall systems

and IT architecture?

 Does the requirement fit within the overall

information strategy, IS service provision, and

current and planned future systems architecture?

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 .

4: Project Initiation and Risk Assessment

 Will the project create any technical or process debt

that will need to be mitigated by additional projects

and investment?

 Are there any restrictions or other general

requirements that the project needs to include (e.g.,

standard non-functional requirements such as data

structures, compliance with design standards or

access policies)?

Conclusion

In this chapter I have provided an approach for reviewing

the impact of an Agile project on business as usual

compliance, and considered how we can improve the

operation of controls in a product deliverable (e.g.,

automated versus manual, detective versus preventative

controls). The use of Agile does not remove the need to

ensure there are real business benefits to be derived from

the final product. The extent of the review is likely to be

shorter and less formal than the auditor may be used to for

other types of project, but the basic principles remain. The

organisation also needs to understand the risks associated

with the project, including any additional Agile risks, and

ensure frameworks are in place for their mitigation. The

intervention of the auditor, or other risk professionals, at

this stage should reduce the governance risks and ensure

proposed controls are adequate.

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 .