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.