IT Strategic Plan Part 2

chapter_16_project_risk_management.pdf

Home >Information Systems homework help >IT Strategic Plan Part 2

The Chief Information Officer's Body of Knowledge: People, Process,... http://library.books24x7.com.ezproxy.umuc.edu/assetviewer.aspx?boo...

Chapter Sixteen -Project Risk Management

", The Chief Information Officer's Body of Knowledge: People, Process, and Technology

by Dean Lane

John Wiley &Sons 02011 Citation

Recommend? }~e~~. no

~~ Pr~trious #~ hle~ct

Chapter Sixteen: Project Risk Management

Sam Chughtai

A NEW AGE OF RISK MANAGEMENT IN A GLOBAL, INTERCONNECTED WORLD

Today, business and projects are different. Today's projects are agile, complex, and characterized by a vast, complicated network of business relationships teeming with technology, process, regulatory compliance, and sensitive information. A single high-risk unmanaged relationship or variable can be a ticking bomb. Today your business or amission-critical project may be at risk whether you realize it or not, especially if you do not have an independent risk assessment and reporting function in place during the project life cycle.

Today, risk management must be strategically insightful and tactically consistent, and cross-functional across the enterprise—and as fast and reliable as the underlying technology that drives it. Costly solutions for governance, risk assessment, and subjective compliance reporting that offer only compliance comfort are no longer enough. In this new age, you need the independence, transparency, and standardization of an on-demand risk management intelligence as an in-flight check (IFC) to sustain a high degree of confidence in successful project delivery.

Use of content on this site is subject to the restrictions set forth in the Terms of Use. Page Layout and Design 02015 Skillsoft Ireland Limited -Ali rights reserved, individual content is owned by respective copyright holder. Feedback ~ Privacy and Cookie Policy (Updated 12!2014) ~ v.4.0.78.153

TRUJ~T@ ► r

~ ~ , Certified Rtiva~cy ~

r~~~r I

1 of 1 7/7/2015 7:50 AM

The Chief Information Officer's Body of Knowledge: People, Process,... http://library.books24x7.com.ezproxy.umuc.edu/assetviewer.aspx?boo...

Chapter Sixteen -Project Risk Management _, The Chief Information Officer's Body of Knowledge: People, Process, and Technology

by Dean Lane

John Wiley & Sons o 2011 Citation

Recommend? }~e~~• nv

'~ Previoa~s + ~ Next

WHY PROJECT RISK MANAGEMENT?

Big projects fail at an astonishing rate, causing a multitude of impacts ranging from brand value, market share compromise, reputational impact, and regulatory compliance risk. A lack of transparency and independent project oversight causes a loss of objectivity in project progress reporting. Missed project deadlines and deliverables often are not reported or are misrepresented in reporting until it is too late.

When a promising project does not deliver, chances are that the problem was not the idea but how it was carried out. Managers expect they can plan for all the variables in a complex project in advance, but this simply is not possible. The number and frequency of variables in complex projects create a virtually infinite range of possible outcomes.

Large projects still fail at an astonishing rate despite a strong project management office, all the Ivy League MBAs, and Big Four audits on board.[~~

~~~Nadim F. Matta and Ronald N. Ashkenas, "Why Good Projects Fail Anyway", HBRARTICLES, September 1, 2003, http://hbr.org/2003/09/why-good-projects-fail-anyway/ar/1.

Pretriovs ♦ N~xE

Use of content on this site is subject to the restrictions set forth in the Terms of Use. Page Layout and Design 02015 Skillsoft Ireland Limited -Ail rights reserved, individual content is owned by respective copyright holder. Feedback ~ Privacy and Cookie Policy (Updated 12/2014) ~ v.4.0.78.153

TRUSTe ► `~► Certllied Privacy

Sk 1~~#t

1 of 1 717/2015 7:50 AM

The Chief Information Off'icer's Body of Knowledge: People, Process,... http://library.books24x7.com.ezproxy.umuc.edu/assetviewer.aspx?boo...

Chapter Sixteen -Project Risk Management

-- The Chief Information Officer's Body of Knowledge: People, Process, and Technology

by Dean Lane

,~. John Wiley &Sons 02011 Citation

Recommend? ~~e ~ no

~~ Previous ♦ Nexf

KEY EXECUTIVE CHALLENGES

In global enterprise complex projects, what keeps executives up at night?

■ "Can I deliver what I committed to my business?"

■ "Can I trust the executive reporting provided by my team?"

■ "What is my project team not telling me?"

Most executives find out the hard way when it is too late to fix a major failure.

How Big is the Problem?

It is estimated that of the $255 billion spent per year on information technology projects in the United States, more than a quarter is lost to failures and cost overruns. The Chaos Report by the Standish Group, considered a

landmark study, looked at the causes of software development failure.~2~ the sample included large, medium, and small companies across major industry segments: banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 365 respondents representing 8,380 applications.

The report shows that:

■ 31.1 percent of IT projects will be canceled before completion.

■ 52.7 percent of projects will overrun their original cost estimate by 189 percent.

■ U.S. companies will spend $81 billion for canceled IT projects.

■ They will pay an additional $59 billion for ongoing IT projects that exceed time limits.

■ Only 16.2 percent of IT projects are completed on time and on budget. (In larger companies, this rate drops to 9 percent, and only 42 percent of these retain the original features.)

In a recent study by the Gartner Group, many CIOs reveal that identifying and mitigating project risks are critical

steps, especially when cost overruns are no longer tolerated.~3~ Cost overruns and outright project failures represent millions of lost investment dollars and opportunity costs that are incurred far too often. Businesses can no longer afford failed projects.

C-level management and the board receive a range of staff responses when they ask, "Why is the project failing?" Responses may include:

■ The selected technology did not work as expected and is complicated.

■ User requirements and expectations were not managed well or clearly defined.

■ Resources were not managed to achieve the desired business value.

■ Too many project changes resulted in an overly complex system that was hard to test.

■ We have vendor delivery problems or internal management challenges.

1 of 4 7/7/2015 7:50 AM

The Chief Information Officer's Body of Knowledge: People, Process,... http://library.books24x7.coin.ezproxy.umuc.edu/assetviewer.aspx?boo...

Most failed project analysis reveals that even direct staff members fail to admit and were unable to explain why the last project health reports before project failure admission were "all OK" or "all on track." Lack of independent project status reporting has been identified as a fundamental problem in a majority of the failed projects.

Independent third-party objective project data verification and validation is critical to the entire life cycle of a project, and it is essential to minimizing an IT project's exposure to failure. Early project delta identification and course correction results in a high degree of project success.

IFC is athird-party, independent risk management solution for large projects. Research indicates that many complex, high-cost private- and public-sector projects develop significant cost overruns, exceed time estimates, or fail. Failed projects incur tremendous economic and political costs. IFC, which provides objective project tracking and reporting services to senior executives, significantly reduces failure.

IFC is a trust, validate, and delta course correction reporting of project progress. An external project audit framework, IFC ensures that key deliverables meet predefined expectations. IFC incorporates technology, media, and subject matter expert resources to direct course correction during the project life cycle to ensure successful delivery or timely cessation. The small budget overhead for IFC is more than offset by mitigation of risk that can easily double estimated project cost or result in project failure.

The cost of a failed project is only the tip of the iceberg. Every project failure incurs both direct costs of the IT investment itself and indirect costs of the lost opportunity.

Project failure impacts include:

■ Loss of brand value and market share

■ Opportunity costs

■ Product release delay resulting in lost revenue

■ Regulatory compliance violation

■ High cost of supplemental solution

■ Loss of internal and external customers

■ Loss of competitive edge

■ Impact on shareholders' value

In recent interviews, CIOs stated that during cost cutting, they eliminated several high-risk projects and implemented an IFC process to ensure that the remaining projects were managed better and would deliver high-impact value.

A common theme of identifying problems earlier and using an IFC process helped several organizations modify project plans or stop projects due to technical or managerial issues. According to one Fortune 100 CIO, "We previously viewed in-flight check as a luxury, but the cost is such a small percentage of the project budget and it helps ensure the delivery of projected business value with a high degree of trust in all reporting parties. The result is that we're now mandating it on many of our large and high-risk projects."

Multiple CIOs of Fortune 100 companies stated that the enterprise is much better off using an IFC contractor and process because often they identify major technical problems that prime contractors did not recognize. Again, it is the third-party independence and objectivity that is the fundamental building block of IFC reporting.

C-Level Executives' and Boards of Directors' Call to Action

The following best practices will help ensure that both business leaders and the IT organization reap strategic value from IFC engagement:

■ Engage a reputable, independent, and experienced third party; internal resources are not independent.

2 of 4 7/7/2015 7:50 AM

The Chief Information Officer's Body of Knowledge: People, Process,... http://library.books24x7.com.ezproxy.umuc.edu/assetviewer.aspx?boo...

■ Determine the scope of responsibilities for the IFC team.

■ Ensure that the IFC addresses both managerial and technical approaches, requirements, and the ability to deliver the business value as stated in the project charter.

■ Do not treat the IFC as an overhead expense; it is a critical risk management component of the project cost. If the business does not want to pay for an IFC, it must accept the additional risk and conduct more periodic technical and management reviews.

■ Ensure that the IFC team reports to the board to maintain its data reporting objectivity and transparency without any inside influence peddling.

Bottom Line: By implementing up-front planning and ongoing due diligence, IFC is an excellent process to ensure third-party objective project oversight and reporting to reduce project risk/cost and schedule overruns. A secondary and often overlooked benefit is reduced postimplementation support, which can save considerable longer-term costs.

Businesses increasingly will have little tolerance for IT project failures and projects that produce suboptimal results. Organizations can no longer afford the additional costs or the potential loss of promised agility or growth when projects do not achieve the business case for which funding was approved.

Project Risk Management Plan

There are four stages to risk management planning:

1. Risk identification

2. Risk quantification

3. Risk response

4. Independent third-party risk monitoring and control

Risk Identification In this stage, we identify risks. The best approach is a workshop with business and IT people to carry out the identification. Use a combination of brainstorming and reviewing of standard risk lists in addition to IFC.

Business risks are ongoing risks that are best handled by the business. An example is that if the project cannot meet the end-of-financial-year deadline, the business area may need to retain its existing accounting system for another year. The response is likely to be a contingency plan developed by the business to use the existing system for another year.

Generic risks are risks to all projects. Examples include the risk that business users might not be available or that requirements may be incomplete. Each organization will develop standard responses to generic risks.

Risks should be defined in two parts. The first part is the cause of the situation (e.g., vendor not meeting deadline, business users not available). The second part is the impact (e.g., budget will be exceeded, milestones will not be achieved). A risk can be defined as "The vendor not meeting its deadline will cause the budget to be exceeded."

Risk Quantification Risk quantification has two dimensions: impact and frequency. Both require an independent assessment.

For simplicity, rate each value on a 1 to 4 scale. The larger the number, the larger the impact or probability. By using a matrix, a priority can be established (see Figure 16.1).

3 of 4 7/7/2015 7:50 AM

The Chief Information Officer's Body of Knowledge: People, Process,... http://library.books24x7.com.ezproxy.umuc.edu/assetviewer.aspx?boo...

Frt~ls~t~ili~y b

~ ~ ~ ~

JlUJ~i~C~l

~t4't~ite~tt 't`rlll~.il

~.tN1' ~'~1~'b

Figure 16.1: Risk Quantification

Note that if probability is high and impact is low, it is a medium risk. If impact is high and probability is low, it is high priority.

Risk Response There are four possible risk mitigation options and strategies:

1. Avoid the risk. Use another supplier or vendor, for example.

2. Transfer the risk. Make someone else responsible. Perhaps a vendor can be made responsible for a particularly risky part of the project.

3. Mitigate the risk. Take actions to lessen the impact or chance of the risk occurring. If the risk relates to availability of resources, draw up an agreement and get sign-off for the resource to be available.

4. Accept the risk. The risk might be small and acceptable to the business

A risk response plan should include the strategy and action items to address the strategy. The actions should include what needs to be done, who is doing it, and when it should be completed.

Risk Control The final step is to monitor risks continually to ensure that they remain at acceptable levels. It is best to hold regular risk reviews to ascertain status and keep them within an acceptable appetite for risk.

~Z~The Standish Group, "Chaos Report", Standish Group Report, 1995, www.projectsmart.co.uk/docs/chaos- report.pdf.

~3~Gartner Research, "Verifying and Validating to Reduce Project Failures", Gartner Executive Programs EXP Road Notes, September 9, 2009, http://blogs.gartner.com/road-notes/category/uncategorized/page/5.

Previ~s #► ~ Next

Use of content on this site is subject to the restrictions set forth in the Terms of Use. ~~~(~§~~ Page Layout and Design 02015 Skillsoft Ireland Limited -All rights reserved, individual content is owned by ~~ respective copyright holder. Feedback ~ Privacy and Cookie Policy (Updated 12/2014) ~ v.4.0.78.153 ~.

TRUST@ ► ~■~ Csrkifiad Ptiva~y

4 of 4 7/7/2015 7:50 AM

The Chief Information Officer's Body of Knowledge: People, Process,... http://libraly.books24x7.corn.ezproxy.umuc.edu/assetviewer.aspx?boo...

Chapter Sixteen -Project Risk Management

The Chief Information Officer's Body of Knowledge: People, Process, and Technology

by Dean Lane

John Wiley & Sons o 2011 Citation

Recommend? }yes no

'~ PreV1~1s # Ns~C1

CONCLUSION

We all know that risk represents something that we would like to minimize. Risk represents the possibility of an outcome that we do not desire. These two statements are related because in order to achieve a desired outcome, we must manage project risks so that they are minimized. Managing risk is always a balancing act. Doing so requires leadership, participation of other team members, the identification and definition of risk, a plan, and steps for implementation of the risk management framework. The alternative is to do nothing, but should you choose that path, you must ask yourself: How risky is that?

+i~, ~revlous

Use of content on this site is subject to the restrictions set forth in the Terms of Use. Page Layout and Design 02015 Skillsoft Ireland Limited -All rights reserved, individual content is owned by respective copyright holder. Feedback ~ Privacy and Cookie Policy (Updated 12/2014) ~ v.4.0.78.153

~ n TRUST@ ► '; e~~t~ri~d ~~ivA~y:~~

~M~

.S'~C11~S~~~

1 of 1 7/7/2015 7:50 AM

The Chief Information Officer's Body of Knowledge: People, Process,... http://library.books24x7.com.ezproxy.umuc.edu/assetviewer.aspx?boo...

Prsvio~s

NOTES

1~ Previous

Chapter Sixteen -Project Risk Management

The Chief Information Officer's Body of Knowledge: People, Process, and Technology

by Dean Lane

John Wiley & Sons 02011 Citation

Recommend? peg, nr

1. Nadim F. Matta and Ronald N. Ashkenas, "Why Good Projects Fail Anyway", HBR ARTICLES, September 1, 2003, http://hbr.org/2003/09/why-good-projects-fail-anyway/ar/1.

2. The Standish Group, "Chaos Report", Standish Group Report, 1995, www.projectsmart.co.uWdocs /chaos-report.pdf.

3. Gartner Research, "Verifying and Validating to Reduce Project Failures", Gartner Executive Programs EXP Road Notes, September 9, 2009, http://blogs.gartner.com/road-notes/category

/u ncategorized/page/5.

j ~ ~ TRU51'8 ► Certkfiecl p~IVa~Y~

Sk~lsf

1 of 1 7/7J2015 7:50 AM