Presentation is loading. Please wait.

Presentation is loading. Please wait.

Project Management CIS 486 Fall 2005 Week 3 Lecture Dr. David Gadish

Similar presentations

Presentation on theme: "Project Management CIS 486 Fall 2005 Week 3 Lecture Dr. David Gadish"— Presentation transcript:

1 Project Management CIS 486 Fall 2005 Week 3 Lecture Dr. David Gadish
© 2004, David Gadish, Ph.D.

2 Week 2 Review The Project Management and Information Technology Context (Ch-2) The Project Management Process Groups (Ch-3) © 2004, David Gadish, Ph.D.

3 Week 3 Overview Project Integration Management (Ch 4)
Project Scope Management (Ch 5) © 2004, David Gadish, Ph.D.

4 Project Integration Management
Chapter 4

5 Learning Objectives Describe an overall framework for project integration management as it relates to the other project management knowledge areas and the project life cycle Describe project plan development, including project plan content, using guidelines and templates for developing plans, and performing a stakeholder analysis to help manage relationships © 2004, David Gadish, Ph.D.

6 Learning Objectives Explain project plan execution, its relationship to project planning, the factors related to successful results, and tools and techniques to assist in project plan execution Understand the integrated change control process, planning for and managing changes on information technology projects, and developing and using a change control system Describe how software can assist in project integration management © 2004, David Gadish, Ph.D.

7 The Key to Overall Project Success: Good Project Integration Management
Project managers must coordinate all of the other knowledge areas throughout a project’s life cycle Many new project managers have trouble looking at the “big picture” and want to focus on too many details Project integration management is not the same thing as software integration © 2004, David Gadish, Ph.D.

8 Project Integration Management Processes
Project Plan Development: taking the results of other planning processes and putting them into a consistent, coherent document—the project plan Project Plan Execution: carrying out the project plan Integrated Change Control: coordinating changes across the entire project © 2004, David Gadish, Ph.D.

9 Project Integration Management Overview
© 2004, David Gadish, Ph.D.

10 Framework for Project Integration Management
© 2004, David Gadish, Ph.D.

11 Project Plan Development
Document used to coordinate all project planning documents Main purpose is to guide project execution Assist the project manager in leading the project team and assessing project status Project performance should be measured against a baseline plan © 2004, David Gadish, Ph.D.

12 Attributes of Project Plans
Just as projects are unique, so are project plans Plans should be dynamic Plans should be flexible Plans should be updated as changes occur Plans should first and foremost guide project execution © 2004, David Gadish, Ph.D.

13 Common Elements of a Project Plan
Introduction or overview of the project Description of how the project is organized Management and technical processes used on the project Work to be done, schedule, and budget information © 2004, David Gadish, Ph.D.

14 Sample Outline for a Software Project Management Plan (SPMP) (Table 4
© 2004, David Gadish, Ph.D.

15 Stakeholder Analysis A stakeholder analysis documents important (often sensitive) information about stakeholders such as stakeholders’ names and organizations roles on the project unique facts about stakeholders level of influence and interest in the project suggestions for managing relationships © 2004, David Gadish, Ph.D.

16 Sample Stakeholder Analysis (Table 4.2)
© 2004, David Gadish, Ph.D.

17 Project Plan Execution
Project plan execution involves managing and performing the work described in the project plan The majority of time and money is usually spent on execution The application area of the project directly affects project execution because the products of the project are produced during execution © 2004, David Gadish, Ph.D.

18 What Went Wrong? Many people have a poor view of plans based on past experiences. Senior managers often require a plan, but then no one follows up on whether the plan was followed. For example, one project manager said he would meet with each project team leader within two months to review their plans. The project manager created a detailed schedule for these reviews. He cancelled the first meeting due to another business commitment. He rescheduled the next meeting for unexplained personal reasons. Two months later, the project manager had still not met with over half of the project team leaders. Why should project members feel obligated to follow their own plans when the project manager obviously did not follow his? © 2004, David Gadish, Ph.D.

19 Important Skills for Project Execution
General management skills like leadership, communication, and political skills Product skills and knowledge Use of specialized tools and techniques © 2004, David Gadish, Ph.D.

20 Tools and Techniques for Project Execution
Work Authorization System: a method for ensuring that qualified people do work at the right time and in the proper sequence Status Review Meetings: regularly scheduled meetings used to exchange project information Project Management Software: special software to assist in managing projects © 2004, David Gadish, Ph.D.

21 Integrated Change Control
Integrated change control involves identifying, evaluating, and managing changes throughout the project life cycle Three main objectives of change control: Influence the factors that create changes to ensure they are beneficial Determine that a change has occurred Manage actual changes when and as they occur © 2004, David Gadish, Ph.D.

22 Integrated Change Control Process
© 2004, David Gadish, Ph.D.

23 Change Control on IT Projects
Former view: The project team should strive to do exactly what was planned on time and within budget Problem: Stakeholders rarely agreed up-front on the project scope, and time and cost estimates were inaccurate Modern view: Project management is a process of constant communication and negotiation Solution: Changes are often beneficial, and the project team should plan for them © 2004, David Gadish, Ph.D.

24 Change Control System A formal, documented process that describes when and how official project documents and work may be changed Describes who is authorized to make changes and how to make them Often includes a change control board (CCB), configuration management, and a process for communicating changes © 2004, David Gadish, Ph.D.

25 Change Control Boards (CCBs)
A formal group of people responsible for approving or rejecting changes on a project CCBs provide guidelines for preparing change requests, evaluate change requests, and manage the implementation of approved changes Includes stakeholders from the entire organization © 2004, David Gadish, Ph.D.

26 Making Timely Changes Some CCBs only meet occasionally, so it may take too long for changes to occur Some organizations have policies in place for time-sensitive changes “48-hour policy” allows project team members to make decisions, then they have 48 hours to reverse the decision pending senior management approval Delegate changes to the lowest level possible, but keep everyone informed of changes © 2004, David Gadish, Ph.D.

27 Configuration Management
Ensures that the products and their descriptions are correct and complete Concentrates on the management of technology by identifying and controlling the functional and physical design characteristics of products Configuration management specialists identify and document configuration requirements, control changes, record and report changes, and audit the products to verify conformance to requirements © 2004, David Gadish, Ph.D.

28 Suggestions for Managing Integrated Change Control
View project management as a process of constant communications and negotiations Plan for change Establish a formal change control system, including a Change Control Board (CCB) Use good configuration management Define procedures for making timely decisions on smaller changes Use written and oral performance reports to help identify and manage change Use project management and other software to help manage and communicate changes © 2004, David Gadish, Ph.D.

29 Using Software to Assist in Project Integration Management
Several types of software can be used to assist in project integration management Documents can be created with word processing software Presentations are created with presentation software Tracking can be done with spreadsheets or databases Communication software like and Web authoring tools facilitate communications Project management software can pull everything together and show detailed and summarized information (see Appendix A for details) © 2004, David Gadish, Ph.D.

30 ResNet Summary Gantt Chart
© 2004, David Gadish, Ph.D.

31 Project Scope Management
Chapter 5

32 Learning Objectives Understand the elements that make good project scope management important Describe the strategic planning process, apply different project selection methods, such as a net present value analysis, a weighted scoring model, and a balanced scorecard, and understand the importance of creating a project charter Explain the scope planning process and contents of a scope statement © 2004, David Gadish, Ph.D.

33 Learning Objectives Discuss the scope definition process and construct a work breakdown structure using the analogy, top-down, bottom-up, and mind mapping approaches Understand the importance of scope verification and scope change control to avoid scope creep on IT projects Describe how software can assist in project scope management © 2004, David Gadish, Ph.D.

34 What is Project Scope Management?
Scope refers to all the work involved in creating the products of the project and the processes used to create them. It defines what is or is not to be done Deliverables are products produced as part of a project, such as hardware or software, planning documents, or meeting minutes The project team and stakeholders must have the same understanding of what products will be produced as a result of a project and how they’ll be produced © 2004, David Gadish, Ph.D.

35 Project Scope Management Processes
Initiation: beginning a project or continuing to the next phase Scope planning: developing documents to provide the basis for future project decisions © 2004, David Gadish, Ph.D.

36 Project Scope Management Processes
Scope definition: subdividing the major project deliverables into smaller, more manageable components Scope verification: formalizing acceptance of the project scope Scope change control: controlling changes to project scope © 2004, David Gadish, Ph.D.

37 Project Initiation: Strategic Planning and Project Selection
The first step in initiating projects is to look at the big picture or strategic plan of an organization Strategic planning involves determining long-term business objectives IT projects should support strategic and financial business objectives © 2004, David Gadish, Ph.D.

38 Why Firms Invest in Information Technology
© 2004, David Gadish, Ph.D.

39 Identifying Potential Projects
Many organizations follow a planning process for selecting IT projects First develop an IT strategic plan based on the organization’s overall strategic plan Then perform a business area analysis Then define potential projects Then select IT projects and assign resources © 2004, David Gadish, Ph.D.

40 Information Technology Planning Process
© 2004, David Gadish, Ph.D.

41 Methods for Selecting Projects
There are usually more projects than available time and resources to implement them It is important to follow a logical process for selecting IT projects to work on Methods include: focusing on broad needs categorizing projects performing financial analyses using a weighted scoring model implementing a balanced scorecard © 2004, David Gadish, Ph.D.

42 Focusing on Broad Organizational Needs
It is often difficult to provide strong justification for many IT projects, but everyone agrees they have a high value “It is better to measure gold roughly than to count pennies precisely” Three important criteria for projects: There is a need for the project There are funds available There’s a strong will to make the project succeed © 2004, David Gadish, Ph.D.

43 Categorizing IT Projects
One categorization is whether the project addresses a problem an opportunity a directive Another categorization is how long it will take to do and when it is needed Another is the overall priority of the project © 2004, David Gadish, Ph.D.

44 Financial Analysis of Projects
Financial considerations are often an important consideration in selecting projects Three primary methods for determining the projected financial value of projects: Net present value (NPV) analysis Return on investment (ROI) Payback analysis © 2004, David Gadish, Ph.D.

45 Net Present Value Analysis
Net present value (NPV) analysis is a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time Projects with a positive NPV should be considered if financial value is a key criterion The higher the NPV, the better © 2004, David Gadish, Ph.D.

46 Net Present Value Example
Note that totals are equal, but NPVs not. Uses Excel’s npv function © 2004, David Gadish, Ph.D.

47 JWD Consulting NPV Example
Multiply by the discount rate each year, then take cum. benefits – costs to get NPV © 2004, David Gadish, Ph.D.

48 NPV Calculations Determine estimated costs and benefits for the life of the project and the products it produces Determine the discount rate (check with your organization on what to use) Calculate the NPV (see text for details) Notes: Some organizations consider the investment year as year 0, while others start in year 1. Some people enter costs as negative numbers, while others do not. Check with your organization for their preferences. © 2004, David Gadish, Ph.D.

49 Return on Investment Return on investment (ROI) is calculated by subtracting the project costs from the benefits and then dividing by the costs ROI = (total discounted benefits - total discounted costs) / discounted costs The higher the ROI, the better Many organizations have a required rate of return or minimum acceptable rate of return on an investment Internal rate of return (IRR) can by calculated by setting the NPV to zero © 2004, David Gadish, Ph.D.

50 Payback Analysis Another important financial consideration is payback analysis The payback period is the amount of time it will take to recoup, in the form of net cash inflows, the net dollars invested in a project Payback occurs when the cumulative discounted benefits and costs are greater than zero Many organizations want IT projects to have a fairly short payback period © 2004, David Gadish, Ph.D.

51 Charting the Payback Period
© 2004, David Gadish, Ph.D.

52 Weighted Scoring Model
A weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria First identify criteria important to the project selection process Then assign weights (percentages) to each criterion so they add up to 100% Then assign scores to each criterion for each project Multiply the scores by the weights and get the total weighted scores The higher the weighted score, the better © 2004, David Gadish, Ph.D.

53 Sample Weighted Scoring Model for Project Selection
© 2004, David Gadish, Ph.D.

54 Implementing a Balanced Scorecard
Drs. Robert Kaplan and David Norton developed this approach to help select and manage projects that align with business strategy A balanced scorecard converts an organization’s value drivers, such as customer service, innovation, operational efficiency, and financial performance to a series of defined metrics See for more information © 2004, David Gadish, Ph.D.

55 Project Charters After deciding what project to work on, it is important to formalize projects A project charter is a document that formally recognizes the existence of a project and provides direction on the project’s objectives and management Key project stakeholders should sign a project charter to acknowledge agreement on the need and intent of the project © 2004, David Gadish, Ph.D.

56 Sample Project Charter
© 2004, David Gadish, Ph.D.

57 Sample Project Charter
© 2004, David Gadish, Ph.D.

58 Scope Planning and the Scope Statement
A scope statement is a document used to develop and confirm a common understanding of the project scope. It should include: a project justification a brief description of the project’s products a summary of all project deliverables a statement of what determines project success See the example scope statement in Chapter 3, pages 83-85 © 2004, David Gadish, Ph.D.

59 Scope Planning and the Work Breakdown Structure
After completing scope planning, the next step is to further define the work by breaking it into manageable pieces Good scope definition helps improve the accuracy of time, cost, and resource estimates defines a baseline for performance measurement and project control aids in communicating clear work responsibilities © 2004, David Gadish, Ph.D.

60 The Work Breakdown Structure
A work breakdown structure (WBS) is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project It is a foundation document in project management because it provides the basis for planning and managing project schedules, costs, and changes © 2004, David Gadish, Ph.D.

61 Sample Intranet WBS Organized by Product
© 2004, David Gadish, Ph.D.

62 Sample Intranet WBS Organized by Phase
© 2004, David Gadish, Ph.D.

63 Intranet WBS in Tabular Form
1.0 Concept 1.1 Evaluate current systems 1.2 Define Requirements 1.2.1 Define user requirements 1.2.2 Define content requirements 1.2.3 Define system requirements 1.2.4 Define server owner requirements 1.3 Define specific functionality 1.4 Define risks and risk management approach 1.5 Develop project plan 1.6 Brief Web development team 2.0 Web Site Design 3.0 Web Site Development 4.0 Roll Out 5.0 Support © 2004, David Gadish, Ph.D.

64 Intranet WBS and Gantt Chart in Project 2000
© 2004, David Gadish, Ph.D.

65 Intranet WBS and Gantt Chart Organized by Project Management Process Groups
© 2004, David Gadish, Ph.D.

66 Executing Tasks for JWD Consulting’s WBS
© 2004, David Gadish, Ph.D.

67 Approaches to Developing WBSs
Using guidelines: Some organizations, like the DoD, provide guidelines for preparing WBSs The analogy approach: Review WBSs of similar projects and tailor to your project The top-down approach: Start with the largest items of the project and break them down © 2004, David Gadish, Ph.D.

68 Approaches to Developing WBSs
The bottom-up approach: Start with the detailed tasks and roll them up Mind-mapping approach: Write down tasks in a non-linear format and then create the WBS structure © 2004, David Gadish, Ph.D.

69 Sample Mind-Mapping Approach
© 2004, David Gadish, Ph.D.

70 Basic Principles for Creating WBSs
1. A unit of work should appear at only one place in the WBS. 2. The work content of a WBS item is the sum of the WBS items below it. 3. A WBS item is the responsibility of only one individual, even though many people may be working on it. 4. The WBS must be consistent with the way in which work is actually going to be performed; it should serve the project team first and other purposes only if practical. © 2004, David Gadish, Ph.D.

71 Basic Principles for Creating WBSs
5. Project team members should be involved in developing the WBS to ensure consistency and buy-in. 6. Each WBS item must be documented to ensure accurate understanding of the scope of work included and not included in that item. 7. The WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement. © 2004, David Gadish, Ph.D.

72 Scope Verification and Scope Change Control
It is very difficult to create a good scope statement and WBS for a project It is even more difficult to verify project scope and minimize scope changes Many IT projects suffer from scope creep and poor scope verification © 2004, David Gadish, Ph.D.

73 Factors Causing IT Project Problems
© 2004, David Gadish, Ph.D.

74 Suggestions for Improving User Input
Develop a good project selection process and insist that sponsors are from the user organization Have users on the project team in important roles Have regular meetings Deliver something to users and sponsors on a regular basis Co-locate users with developers © 2004, David Gadish, Ph.D.

75 Suggestions for Reducing Incomplete and Changing Requirements
Develop and follow a requirements management process Use techniques like prototyping, use case modeling, and JAD to get more user involvement Put requirements in writing and keep them current Provide adequate testing and conduct testing throughout the project life cycle © 2004, David Gadish, Ph.D.

76 Suggestions for Reducing Incomplete and Changing Requirements
Review changes from a systems perspective Emphasize completion dates to help focus on what’s most important Allocate resources specifically for handling change requests/enhancements © 2004, David Gadish, Ph.D.

77 Using Software to Assist in Project Scope Management
Word-processing software helps create several scope-related documents Spreadsheets help to perform financial calculations, create weighted scoring models, and develop charts and graphs © 2004, David Gadish, Ph.D.

78 Using Software to Assist in Project Scope Management
Communication software like and the Web help clarify and communicate scope information Project management software helps in creating a WBS, the basis for tasks on a Gantt chart Specialized software is available for applying the balanced scorecard, creating mind maps, managing requirements, and so on © 2004, David Gadish, Ph.D.

79 Questions? © 2004, David Gadish, Ph.D.

80 Next Week’s Agenda Project Time Management (Ch 6)
Project Cost Management (Ch 7) © 2004, David Gadish, Ph.D.

Download ppt "Project Management CIS 486 Fall 2005 Week 3 Lecture Dr. David Gadish"

Similar presentations

Ads by Google