© 2004, David Gadish, Ph.D. 1 Project Management Project Management CIS 486 CIS 486 Fall 2005 Fall 2005 Week 3 Lecture Week 3 Lecture Dr. David Gadish Dr. David Gadish
Dec 21, 2015
© 2004, David Gadish, Ph.D. 1
Project ManagementProject ManagementCIS 486CIS 486
Fall 2005Fall 2005
Week 3 LectureWeek 3 Lecture
Dr. David GadishDr. 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)
4
Project Integration Management
Chapter 4
© 2004, David Gadish, Ph.D. 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.1)
Project Management Plan SectionsIntroduction Project
OrganizationManagerialProcess
TechnicalProcess
WorkPackages,Schedule, andBudget
SectionTopics
Projectoverview;projectdeliverables;evolution ofthe SPMP;referencematerials;definitions andacronyms
Process model;organizationalstructure;organizationalboundaries andinterfaces;projectresponsibilities
Managementobjectives andpriorities;assumptions,dependencies,andconstraints;riskmanagement;monitoringandcontrollingmechanisms;and staffingplan
Methods, tools,andtechniques;softwaredocumentation;and projectsupportfunctions
Workpackages;Dependencies;resourcerequirements;budget andresourceallocation;and schedule
IEEE Std 10581-1987
© 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)Key Stakeholders
Ahmed Susan Erik Mark DavidOrganization Internal
seniormanagement
Project team Project team Hardwarevendor
Projectmanager forotherinternalproject
Role onproject
Sponsor ofproject andone of thecompany'sfounders
DNAsequencingexpert
Leadprogrammer
Suppliessomeinstrumenthardware
Competingfor companyresources
Unique facts Demanding,likes details,businessfocus,StanfordMBA
Very smart,Ph.D. inbiology,easy to workwith, has atoddler
BestprogrammerI know,weird senseof humor
Start-upcompany, heknows wecan makehim rich ifthis works
Nice guy,one of oldestpeople atcompany,has 3 kids incollege
Level ofinterest
Very high Very high High Very high Low tomedium
Level ofinfluence
Very high;can call theshots
Subjectmatterexpert;critical tosuccess
High; hardto replace
Low; othervendorsavailable
Low tomedium
Suggestionson managingrelationship
Keepinformed, lethim leadconversations ,do as hesays andquickly
Make sureshe reviewsspecifications and leadstesting; cando somework fromhome
Keep himhappy so hestays;emphasizestockoptions;likesMexicanfood
Give himenough leadtime todeliverhardware
He knowshis projecttakes a backseat to thisone, but Ican learnfrom him
© 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 e-mail 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
31
Project Scope Management
Chapter 5
© 2004, David Gadish, Ph.D. 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 BroadOrganizational 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
UsesExcel’snpvfunction
Notethat totalsare equal,butNPVsare not.
© 2004, David Gadish, Ph.D. 47
JWD Consulting NPV Example
Multiplyby thediscountrate eachyear, thentake cum.benefits –costs toget 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 www.balancedscorecard.org 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 theScope 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 Form1.0 Concept
1.1 Evaluate current systems1.2 Define Requirements
1.2.1 Define user requirements1.2.2 Define content requirements1.2.3 Define system requirements1.2.4 Define server owner requirements
1.3 Define specific functionality1.4 Define risks and risk management approach1.5 Develop project plan1.6 Brief Web development team
2.0 Web Site Design3.0 Web Site Development4.0 Roll Out5.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 WBSs1. 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 WBSs5. 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 e-mail 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)