1. School of Business Administration
Chapter 6: Project Activity and Risk Planning (Chapter 5 in Chinese Edition)
Jason C. H. Chen, Ph.D.
Professor of MIS
School of Business Administration
Gonzaga University
Spokane, WA 99258

2. Part II
Project Planning

3. Project Management

4. Why do Projects Fail?
Studies have shown that the following factors contribute significantly to project failure:
• Improper focus of the project management system
• Wrong level of detail
• Lack of understanding about project management tools; too much reliance on project management software
• Too many people
• Poor communication
• Rewarding the wrong actions

5. Project Triangle (Project Management Trade-offs)
Time
Cost
The center of project triangle is
QUALITY
Figure 11.2 Project Triangle (Project Management Trade-offs) – mbus626
Scope
The objective of the PM is to define project’s scope realistically and ultimately deliver quality of product/service on time, on budget and within scope.

6. Why Planning? Reasons for Planning
To eliminate or reduce uncertainty
To improve efficiency of the operation
To obtain a better understanding of the objectives
To provide a basis for monitoring and controlling work

7. MOST MANAGERS DO NOT LIKE PLANNING DUE TO THE FOLLOWING:
It takes time.
You have to think.
It involves paper work.
You are bound to systematic procedures.
You are committed to achieve a specific result within a specified time period.

8. Effective Planning An effective plan will be: Explicit
stated in detail, leaving nothing merely implied.
Intelligible -
it must be understood and be comprehensible.
Flexible -
capable of accepting change.
Controllable -
capable of being monitored for control purposes.

9. DEFINITION OF A PROJECT LIFE CYCLE
CONCEPTUAL
PHASE
FEASIBILITY AND
PRELIMINARY PLANNING PHASE
DETAILED PLANNING PHASE
IMPLEMENTATION
PHASE
CONVERSION
OR TERMINATION PHASE
Resources
Utilized
RESOURCES
TIME
PMO
PMO
PMO: Project Management Office

10. PLANNING QUESTIONS OFTEN ASKED
Who plans the project?
Who executes the project?
Who is responsible for monitoring work and controlling work?
Who is responsible for providing feedback regarding the planning and execution phases of a project?
The Line Manager(s) ?
The Project Manager ?
Both Parties ?

11. Project Manager vs. Line Manager
A Project Manager manages the work taken up by a single project whereas the Line Manager will be managing the work taken up by a line of projects.
The Line manager will interact/liase with the Project Managers who manage the projects that fall in his line.
Usually projects in organizations are aligned based on the line of business, catered to, by the project. Hence, they will have a Line Manager who manages all those projects.
Cater: provide, serve
Line management is a business term to describe the administration of activities that contribute directly to the output of products or services. In a corporate hierarchy, a "line manager" holds authority in a vertical 'line' (chain of command), and/or over a particular product line. He or she is charged with meeting corporate objectives in a specific functional area or line of business.

12. Project Manager’s Responsibility
Project Manager will define:
Goals and objectives
Major milestones
Requirements
Ground rules and assumptions
Time, cost, and performance constraints
Operating procedures
Administrative policy
Reporting requirements

13. Line Manager’s Responsibility
Line manager will define:
Detailed task descriptions to implement objectives, requirements, and milestones
Detailed schedules and manpower allocations to support budget and schedule
Identification of areas of risk, uncertainty, and conflict

14. 6.1 Initial Project Coordination and the Project Charter
Early meetings are used to decide on participating in the project
Used to “flesh out” the nature of the project
Outcomes include:
Technical scope
Areas of responsibility
Delivery dates or budgets
Risk management group
Flesh out: expand, elaborate, amplify

15. Outside Clients
When it is for outside clients, specifications cannot be changed without the client’s permission
Client may place budget constraints on the project
May be competing against other firms

16. Project Charter Elements
Purpose
Objectives
Overview
Schedules
Resources
Personnel
Risk management plans
Evaluation methods

17. Systems Integration
Performance
Effectiveness
Cost

18. 6.2 Starting the Project Plan: The Work Breakdown Structure (WBS)
A hierarchical planning process
Breaks tasks down into successively finer levels of detail
Continues until all meaningful tasks or work packages have been identified
These make tracking the work easier
Need separate budget/schedule for each task or work package

19. Hierarchical Planning
Major tasks are listed
Each major task is broken down into detail
This continues until all the activities to be completed are listed
Need to know which activities “depend on” other activities

20. A Form to Assist Hierarchical Planning
Figure 6-2

21. Work Breakdown Structure (WBS)

22. A Visual WBS
Figure 6-3 WBS with account numbers shown

23. Career Day
Figure 6-4 Partial WBS for college “Career Day”

24. The WBS What is to be done When it is to be started and finished
Who is going to do it
Some activities must be done sequentially
Some activities may be done simultaneously
Many things must happen when and how they are supposed to happen
Each detail is uncertain and subjected to risk

25. PURPOSE OF WBS
It is to STRUCTURE an ASSIGNED PROJECT into VARIOUS ACTIVITIES in ORDER that:
Detailed planning can be performed
Costs and budgets can be established
Objectives can be linked to available resources in a logical manner
Specific authority and responsibility can be assigned

26. Most common type: Six-Level Indentured Structure
WORK BREAKDOWN STRUCTURE (WBS)
LEVEL
DESCRIPTION 1
Total Program 2
Project(s) 3
Task(s) 4
Subtask(s) 5
Work Package(s) 6
Level of Effort
Most common type: Six-Level Indentured Structure

27. WBS: SIX-LEVEL STRUCTURE
THE WBS BREAKS WORK DOWN INTO SMALLER ACTIVITIES THUS REDUCING THE RISK THAT ANY MAJOR OR MINOR ITEM WILL BE OMITTED
WBS: SIX-LEVEL STRUCTURE
LEVELS
RESPONSIBILITY 1 2 3 4 5 6
Usually specified by the client and managed the project manager.
Generated by contractor for in-house control and managed by the functional manager(s).
Planning accuracy is dependent on the WBS level selected. The lower the level the greater is the planning accuracy but the higher the management cost.

28. WBS Controls SCHEDULES DECISION TREES MGT. COORDIN. ORGANIZ. CHARTS
WORK
BREAKDOWN
STRUCTURE
ORGANIZ.
CHARTS
ACCOUNT-
ABILITY
COSTS

29. 6.3 Human Resources: The RACI Matrix and Agile Projects
Useful to create a table that shows staff needed to execute WBS tasks
One approach is a organizational breakdown structure (OBS)
Organizational units responsible for each WBS element
Who must approve changes of scope
Who must be notified of progress
WBS and OBS may not be identical

30. The Responsibility (RACI) Matrix
Another approach is the Responsible, Accountable, Consult, Inform (RACI) matrix
Also known as a responsibility matrix, a linear responsibility chart, an assignment matrix, a responsibility assignment matrix
Shows critical interfaces
Keeps track of who must approve what and who must be notified
When it comes to leadership, responsibility is the before-the-fact mindset of taking ownership for the results of a project or job. To be responsible, you must first acknowledge that action must be taken on a particular issue.
Accountability is the after-the-fact ownership of the results of your project. It is the commitment to honestly explain why things were done a particular way.
Example: If you ever find yourself in court answering questions about why an employee was injured under your leadership, you are being held accountable.

31. Sample RACI Matrix Figure 6-7
When it comes to leadership, responsibility is the before-the-fact mindset of taking ownership for the results of a project or job. To be responsible, you must first acknowledge that action must be taken on a particular issue.
Accountability is the after-the-fact ownership of the results of your project. It is the commitment to honestly explain why things were done a particular way.
Example: If you ever find yourself in court answering questions about why an employee was injured under your leadership, you are being held accountable.
Figure 6-7

32. COBIT® Answers Key Business Questions – A Model for Information Ethics
Is my information technology organization doing the right things?
Are we doing them the right way?
Are we getting them done well?
Are we getting the benefits? *
When we think about COBIT and IT governance at the most fundamental level, there are four questions that every leader asks him or herself when it comes to IT initiatives:
Is my IT organization doing the right things?
Are we doing them the right way?
Are we getting them done well?
Are we getting the benefits?
Using the maturity models developed for each of COBIT’s 34 IT processes, management can identify:
• The actual performance of the enterprise—Where the enterprise is
today
• The current status of the industry—The comparison
• The enterprise’s target for improvement—Where the enterprise wants
to be
• The required growth path between ‘as-is’ and ‘to-be’
* Based on the “Four Ares” as described by John Thorp in his book The Information Paradox, written jointly with Fujitsu, first published in 1998 and revised in 2003

33. COBIT® Defined Responsibilities for Each Process – A Model for Information Ethics
RACI Chart
A RACI chart identifies who is Responsible, Accountable, Consulted and/or Informed.
Functions
Activities
Link business goals to IT goals. C I
A/R
Identify critical dependencies and current performance. R
Build an IT strategic plan. A
Build IT tactical plans.
Analyse programme portfolios and manage project and service portfolios.
COBIT also provides information on what processes should be delegated and to whom they should be delegated. This helps to ensure that IT processes are being managed at the appropriate level within an enterprise. The ‘RACI’ Chart is defined for each process and indicates who is responsible, accountable, consulted or should be informed about specific tasks within a given process.
The roles in the RACI chart are categorized for all processes as:
• Chief executive officer (CEO); • Chief financial officer (CFO)
• Business executives; • Chief information officer (CIO)
• Business process owner; • Head operations
• Chief architect; • Head development
• Head IT administration (for large enterprises, the head of functions such
as human resources, budgeting and internal control)
• The project management officer (PMO) or function
• Compliance, audit, risk and security (groups with control responsibilities
but not operational IT responsibilities)
When it comes to leadership, responsibility is the before-the-fact mindset of taking ownership for the results of a project or job. To be responsible, you must first acknowledge that action must be taken on a particular issue.
Accountability is the after-the-fact ownership of the results of your project. It is the commitment to honestly explain why things were done a particular way.
Example: If you ever find yourself in court answering questions about why an employee was injured under your leadership, you are being held accountable.

34. Project Development Methodologies
The choice of development methodologies and managerial influences distinguish IT projects from other projects.
There are four main methodologies IT professionals use to manage the technology projects:
Systems Development Life Cycle (SDLC)
Prototyping
Rapid applications development (RAD)
Joint applications development (JAD) 34

35. Agile Project Planning and Management
When scope cannot be determined in advance, traditional planning does not work
Agile project management was developed to deal with this problem in IT
Small teams are located at a single site
Entire team collaborates
Team deals with one requirement at-a-time with the scope frozen

36. Project Planning: Basic Four-Stage Model
Strategic
Project
Planning
Project
Requirements
analysis
Resource
allocation
Project
Planning
Generic
Activity

37. Phases in the SDLC (Waterfall Approach) SDLC Revisited
Project Identification
and Selection
Project Initiation
and Planning
Analysis
Analysis
Logical Design
Physical Design
Implementation
Major features will be summarized in the next slides.
Maintenance

38. Systems Definition/Investigation (Feasibility Study)
What are new from the last slide?
Economic
Feasibility
Operational
Feasibility
Can we afford it?
Will it be accepted?
Schedule
Feasibility
Technical
Feasibility
iTeaching Tip: Consider redisplaying slide 5 “Traditional Systems Development Life Cycle”, before beginning discussion of this lecture slide.
As pointed out earlier, all application development methodologies share certain common activities. During the remainder of this lecture we will discuss these activities. We will begin by discussing systems investigation.
The Investigation Phase begins the preliminary study of the proposed information system solution to meet the E-Business needs. Its focus is to seek to answer the questions: What are our opportunities, what are our priorities, and can IS be used to address these needs?
Because the process of application development can be costly both in time and resources, the system investigation phase begins with a Feasibility Study. The goal of feasibility studies is to evaluate alternative systems and to propose the most feasible and desirable systems. Feasibility is assessed across four major categories:
Organizational Feasibility. This focuses on how well a proposed information system supports the objectives of the organization.
Technical Feasibility. This ascertains whether reliable hardware and software capable of meeting the needs of the proposed system can be acquired or developed.
Operational Feasibility. This refers to the willingness and ability of the management, employees, customers, suppliers, and others to operate, use, and support a proposed system.
Economic Feasibility. This is concerned with whether the proposed IS benefits are greater than its costs. This area is particularly concerned with financial affordability -- whether the firm can pay to develop the system. A cost/benefit analysis is used to weigh the total costs a new system is likely to incur against the total anticipated benefits to be gained. This includes determining tangible costs (such as hardware and software purchases and employee salaries) and intangible costs such as effects on employee morale and disruptions in productivity during the installation of the new system. Benefits too can be either tangible (such as reduced inventory and carrying costs) or intangible (higher customer satisfaction).
Economic feasibility study – (cost-benefit analysis) – identifies the financial benefits and costs associated with the systems development project
Operational feasibility study – examines the likelihood that the project will attain its desired objectives
Technical feasibility study – determines the organization’s ability to build and integrate the proposed system
Schedule feasibility study – assesses the likelihood that all potential time frames and completion dates will be met
Legal and contractual feasibility study – examines all potential legal and contractual ramifications of the proposed system
Which type of feasibility study would be appropriate for each of the following:
Implementation of a new payroll system
Implementation of a new CRM system
Implementation of a new module to an existing CRM system
Implementation of a new ERP system
Implementation of a additional functionality to an existing KM system
Will it be completed by
the deadline?
Does the IT
capability exist?
Organizational
Feasibility
Legal and
Contractual Feasibility
(Is it a good fit –
objective of the organization
Is the proposed
system legally?

39. Systems Development Life Cycle
SDLC typically consists of seven phases
Initiation of the project
The requirements definition phase
The functional design phase
The system is actually built
Verification phase
The “cut over” where the new system is put in operation and all links are established. Possible conversion methods
Parallel
Direct
Phased in/out
pilot
The maintenance and review phase
Which one is the best approach?
Sabre mini case 39

40. System Conversion Approaches (4Ps)
Pilot
Implement entire system in limited portion of business
MRV uses system for selected customers.
Advantage: limits exposure to business if system fails
Phased
System is installed in phases or modules.
Each piece is installed and tested.
Parallel
Complete new and old systems run simultaneously
Very safe, but expensive
Plunge (or direct)
High risk if new system fails, no old system to fall back on
Only used if new system is not vital to company operation

41. Installation Conversion Methods: 4 Ps
Cut-over time
Old System
New System
Parallel
Old System
New System
Pilot
When the development of a system will replace or improve a current system, a conversion process will be needed. Conversion methods are used for managing system change and managing both the cost and risk associated with a failure of the new system..
Four major forms of system conversion are common:
Parallel. This involves operating both the old and the new system at the same time for some period until the project development team and end user management agree to switch over completely to the new system. This is the least risky approach but the most costly, since resources must be used to keep both the new and old system operational.
Pilot. Here one department or often an off-site office gives the new system a trial run to see how it works and to catch any problems before the system is implemented company-wide. This is a less costly approach. Risk of failure is isolated to the department or office which receives the new system.
Phased. Here the new system is implemented gradually throughout the organization according to some diffusion plan, such as department by department, section by section, or even floor by floor. This approach exposes the organization to more risk, but is less costly.
Plunge. This "cold turkey" approach ends use of the old system and begins use of the new system all at once. This approach has the highest risk, but is the least costly to implement. Can be considered for non-critical applications, or application improvements that are marginal.
Old System
New System
Phased
Old System
New System
Plunge/
Direct
Name a major advantage and disadvantage of “Parallel” and Plunge”?

42. Skip the following ppts

43. 6.4 Interface Coordination Through Integration Management
Managing a project requires a great deal of coordination
Projects typically draw from many parts of the organization as well as outsiders
All of these must be coordinated
The RACI matrix helps the project manager accomplish this

44. Integration Management
Coordinating the work and timing of different groups
Interface coordination is the process of managing this work across multiple groups
Using multidisciplinary teams to plan the project
Requires structure
I.D.E.A project
Q: What do you have at Ming-Chi regarding “Integration”?

45. Managing Projects by Phases and Phase-Gates
Break objectives into shorter term sub-objectives
Project life cycle is used for breaking a project up into component phases
Focus on specific, short-term output
Lots of feedback between disciplines

46. Homework: Incidents for Discussion WBS (p. 265)
Ringold’s Pool and Patio Supply
Tasks to do:
1. Create a WBS like Figure 6-3 or Figure 6-4
2. Then, answer the following two questions
a) Is John Jr.’s WBS projection reasonable?
b) What aspects of the decision will John Sr. consider?

47. Incidents for Discussion (p. 265) WBS (continued)
Ringold’s Pool and Patio Supply
Question:
1. Is John Jr.’s WBS projection reasonable?
2. What aspects of the decision will John Sr. consider?

48. Answer for Ringold’s Pool and Patio Supply
This is a good opportunity to engage the class in a discussion of the importance of involving the team in developing plans and schedules.
One way to do this is to engage the class in collectively creating the upper level or two of a WBS for the project. Chances are they will come up with several items that Junior missed in his, demonstrating the danger of working alone.

49. Answer for Ringold’s Pool and Patio Supply
John Sr. is asking a reasonable question, but his son is giving him a defective answer. Even though Junior’s WBS looks very precise, it would be dangerous to base any decision on it. Since, it has not been validated by anyone who has actual experience in installing pools, there is no way of knowing if the estimates are reasonable, or even if it has accounted for all the work.
Junior has made no effort to evaluate the requirements of the job. For example, he doesn’t list in his WBS anything related to permitting, electrical or plumbing. In addition to these concerns, John Sr. must consider several business issues including whether his company has the staff, skills, and equipment to take on this new area. He needs to consider whether this expansion matches his long-term goals for the business.

50. 6.5 PROJECT RISK MANAGEMENT

51. Risk Management: Basic Concepts
Risk management focuses on:
Known unknowns
Proactive management
The alternative to proactive management is reactive management, also called crisis management.
This requires significantly more resources and takes longer for problems to surface

52. RISK MANAGEMENT Risk Management focuses on the Future.
Risk and Information are inversely related.
Historically, we focused our attentions on schedule and cost risk management.
Today, our primary emphasis on technological risk management:
CAN WE DESIGN IT AND BUILD IT?
WHAT IS THE RISK OF OBSOLESCENCE?

53. Risk Management Projects are risky, uncertainty is high
Project manager must manage this risk
This is called “risk management”
Risk varies widely between projects
Risk also varies widely between organizations
Risk management should be built on the results of prior projects

54. Sub-processes to Risk Management
Risk management planning
Risk identification
Qualitative risk analysis
Quantitative risk analysis
Risk response planning
Risk monitoring and control
The risk management register
Creating a permanent register of identified risks, methods used to mitigate or resolve them, and the results of all risk management activities.

55. Risk Management Planning
Need to know the risk involved before selecting a project
Risk management plan must be carried out before the project can be formally selected
At first, focus is on externalities
Track and estimate project survival
Project risks take shape during planning
Often handled by project office

56. Risk Identification
Risk is dependent on technology and environmental factors
Delphi method is useful for identifying project risks
Other methods include brainstorming, nominal group techniques, checklists, and attribute listing
May also use cause-effect diagrams, flow charts, influence charts, SWOT analysis

57. Qualitative Risk Analysis
Purpose is to prioritize risks
A sense of the impact is also needed
Each objective should be scaled and weighted
Construct a risk matrix
Same approach can be used for opportunities

58. Risk Matrix
There are “five” threats with “three” categories (critical, monitor, ignore) in this example.
Figure 6-12

59. Quantitative Risk Analysis: Failure Mode and Effect Analysis (FMEA)
List ways a project can fail
Evaluate severity (S)
with “1” “no effect”, “10” is “very severe”
Estimate likelihood of cause of failure (L)
“1” is absolutely “uncertain”, “10” almost certain
Estimate the inability to detect (D)
“1” detectability is almost certain and “10” failure is not be detected in time to avoid
Find the risk priority number (RPN) (RPN = S  L  D)
Consider ways to reduce the S, L, and D for each cause of failure
since the lower numbers of S,L,D the BETTER for reducing the cause of failure (i.e., the LESS risk)

60. A FMEA Example Q: Which one is with the “biggest” threat? Why?
Answer: #2 (Can’t acquire tech knowledge)
Table 6-1

61. Decision Tree Analysis
Q: 1. Why EMV is 8.0 for Stocks (a2)?
2. Why EMV is 8.4 for this scenario?
Figure 6-13 Decision Tree based on expected monetary value (EMV)

62. Risk Response Planning
Threats
Avoid
Transfer
Mitigate
Accept
Opportunities
Exploit
Share
Enhance
Accept

63. Risk Monitoring and Control
Monitoring covered in detail in Chapter 10
Control covered in Chapter 11

64. The Risk Management Register
Purpose: The risk management system should maintain an up-to-date data register to ensure against particular risk(s).
Environments that may impact projects
Assumptions made
Risks identified
List of categories and key words
Estimates on risk, states of project’s environment, or on project assumptions
Minutes
Actual outcomes

65. Managing Scope Changes

66. Change Management
YOU CANNOT MANAGE YOUR CUSTOMER WITHOUT MANAGEMENT OF YOUR PROJECT MANAGEMENT PROCESS.
WHEN YOUR CUSTOMER INITIATES A CHANGE REQUEST, YOU MUST BE ABLE TO PREDICT IMMEDIATELY THE IMPACT ON SCHEDULE , COST AND TECHNICAL PERFORMANCE. (why not “SCOPE”)

67. Unmanaged vs. Managed Changes
Where TIME is invested
How ENERGY is invested
Which RESOURCES are used
Back-end
Rework
Enforcement
Compliance
Supervision
Senior Management and key players only
Unmanaged Change
Front-end
Education
Communication
Planning
Improvements
Value-Added
Stakeholders
Suppliers
Customers
Managed Change

68. Implementation /Conversion
Cost of Corrections
Definition
Preliminary Planning
Detailed Planning
Execution
Implementation /Conversion $1 $5
$25
$100
$1000

69. Integrated Processes for The 21st Century
Project Management
Concurrent
Engineering
Total Quality
Management
Change
Management
Risk
Management

70. Video VIDEO. Understanding_Project_Mgt_Benefits (11m)
FMEA (FMEA Services from Concept to Completion-Dynamic Positioning (6m)

71. In class Exercise and HW
Problem #1 (p.263)
Construct a risk matrix (see Figure 6-12)
Problem #2 (p.264)
FMEA analysis
Problem #5 (p.264)
Decision Tree (which one is the best option)
Start to read and prepare case study 1: Southwest Airlines

72. Problem #1 (p.263) Construct a risk matrix (see Figure 6-12)

73. Problem 1:Problem 1:Probability7 6
Threat 2 5
Threat 1 4
Threat 4 3
Threat 3 2 1
Impact
Legend:
Critical
Monitor
Ignore

74. Problem 1:Problem 1:Probability7 6
Threat 2 5
Threat 1 4
Threat 4 3
Threat 3 2 1
Impact
Legend:
Critical
Monitor
Ignore
Threat 1: The threat of costs being excessive could occur. Actually, the probability is somewhat high. This can be transferred to an outsourcing provider to help reduce this threat.
Threat 2: The likelihood of the users resisting changes could cause major problems. This is somewhat likely to happen, but can be avoided if they are given an alternative and consulted in advance.
Threat 3: The project may run longer than expected. This isn’t highly likely, but this can be transferred by outsourcing the project.
Threat 4: The changes may reduce the quality of care in the hospital. The probability is satisfactory because the improvements brought about by the new system may not be significant. If the quality decreases, the impact could be fairly significant, thus the hospital may need to mitigate this threat by including more users in the planning.

75. Problem #2 (p.264) FMEA analysis (RPN)

76. Threat
Severity (S)
(Impact)
Likelihood (L)
(Probability)
Inability to detect (D)
RPN #1 3 5 4 60 #2 6 1 30 #3 36 #4 7
168
Problem 2:
The main thing that changes when using this approach is that threat #2 drops significantly from “critical” to possibly “ignore.” This is mostly due to the lack of inability to detect.
Threat #2 is somewhat severe and the likelihood is great, but since the threat is relatively easy to detect, it can be mitigated early and possibly even removed.
Thus, this is a much more realistic evaluation of the threats than just creating a risk matrix.

77. Problem #5 (p.264) Decision Tree (which one is the best option)
Revenue
Expense
Profit
Problem 5:
a1, a3 decision = (0.7  $3,000) + (0.3  $2,000) – $500 = $2,200
YOUR TURN to compute a1,a4; a2,a5 and a2,a6 decisions
a1, a4 decision = (0.7  $1,000) + (0.3  $2,000) – $500 =
a2, a5 decision = (0.4  $2,150) + (0.6  $3,000) – $1,000=
a2, a6 decision = (0.4  $2,150)+ (0.6  $4,000) – $1,000=
$800
$1,660
$2,260
Which one is the best option?
Based on this analysis, the best option is
a2, a6.