Presentation is loading. Please wait.

Presentation is loading. Please wait.

School of Business Administration

Similar presentations

Presentation on theme: "School of Business Administration"— Presentation transcript:

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

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.


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

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.


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.


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


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:Probability
7 6 Threat 2 5 Threat 1 4 Threat 4 3 Threat 3 2 1 Impact Legend: Critical Monitor Ignore

74 Problem 1:Problem 1:Probability
7 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.

Download ppt "School of Business Administration"

Similar presentations

Ads by Google