is 556 enterprise project management

28
IS 556 Enterprise Project Management 1 IS 556 -Spring 2008 Lecture 2 Apr 7, 2008 //48

Upload: zulema

Post on 23-Jan-2016

34 views

Category:

Documents


0 download

DESCRIPTION

IS 556 Enterprise Project Management. Topic. Critical Chain Project Management Other Frameworks Leach - Chapter 2. Multiple Perspectives on Project System. & TQM. Execute projects effectively. Continually improve every PROCESS. Theory of Constraints. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: IS 556 Enterprise Project Management

IS 556 Enterprise Project Management

1IS 556 -Spring 2008 Lecture 2 Apr 7, 2008 //48

Page 2: IS 556 Enterprise Project Management

Topic

Critical Chain Project Management Other FrameworksLeach - Chapter 2

2IS 556 -Spring 2008 Lecture 2 Apr 7, 2008 //48

Page 3: IS 556 Enterprise Project Management

IS 556 -Spring 2008 3

Multiple Perspectives on Project System

Executeprojectseffectively

& TQM

Continually improve every PROCESSTheory of Constraints

Identifies system constraintsWorks to improve throughput

Lecture 2 Apr 7, 2008 //48

Page 4: IS 556 Enterprise Project Management

IS 556 -Spring 2008 4

PMBOK Project Management Book of Knowledge Framework that defines the areas that

require management attention.1. 9 knowledge areas2. 5 types of processes

It does not tell what areas need more attention than others under what circumstances – so there’s a tremendous amount of managerial attention spent on items that may not need it

Lecture 2 Apr 7, 2008 //48

Page 5: IS 556 Enterprise Project Management

IS 556 -Spring 2008 5

PMBOK and Critical Chain Of the 9 knowledge areas, CCPM impacts the

following ones in bold.1. Integration2. Scope3. Time4. Cost5. Quality6. Human Resources7. Communications8. Risk

(no common-cause special-cause differentiation)9. Procurement

Lecture 2 Apr 7, 2008 //48

Page 6: IS 556 Enterprise Project Management

IS 556 -Spring 2008 6

TOC – Theory of Constraints Looks at individual project tasks logically as the

operation of a system for producing the result or output of the tasks.

Determines 1. What to change2. What to change to3. How to cause the change

5 focusing steps provide the steps to implement the improvement process

1. Identify the constraint2. Exploit the constraint3. Subordinate everything else to the constraint4. Elevate the constraint5. Do NOT let inertia prevent further improvement

Lecture 2 Apr 7, 2008 //48

Page 7: IS 556 Enterprise Project Management

IS 556 -Spring 2008 7

TOC – system o/p limited by constraint

Lecture 2 Apr 7, 2008 //48

Page 8: IS 556 Enterprise Project Management

IS 556 -Spring 2008 8

TOC – Theory of Constraints Must first identify the system constraint

(core conflict) leading to the undesired effects of present project system (or current theory). Core conflict identifies what to change.

TOC leads to a new system design or “what to change-to

Lecture 2 Apr 7, 2008 //48

Page 9: IS 556 Enterprise Project Management

IS 556 -Spring 2008 9

Change Management Necessary to implement the degree of

behavior change necessary to achieve the results promised by CCPM.

Lecture 2 Apr 7, 2008 //48

Page 10: IS 556 Enterprise Project Management

Topic

Critical Chain Project Management Direction the Solution Should Take

Leach - Chapter 3

IS 556 -Spring 2008 10

Page 11: IS 556 Enterprise Project Management

IS 556 -Spring 2008 11

Defining the PM System

The black-box view of the PM System which processes Inputs to produce Outputs that satisfy the system goal

When you look at the PM System this way it becomes obvious that the undesired effects area direct result of what weare doing. Thus, we need to look to see if there’s a underlying conflict or dilemma common to projects. So, we must find the dilemma.

Lecture 2 Apr 7, 2008 //48

Page 12: IS 556 Enterprise Project Management

IS 556 -Spring 2008 12

Identifying the Dilemma (PM Constraint) Goal of projects is to get done fast. Why?

1. Pouring money into project from inception

2. Getting benefits out of project only on completion

Most projects plan their schedules using the critical path method which has been around for over 40 years.

Lecture 2 Apr 7, 2008 //48

Page 13: IS 556 Enterprise Project Management

IS 556 -Spring 2008 13

Critical Path Method (CPM) Schedule

Note: we have 2 people (resources) working on project -- #1 startsworking on tasks 1,3, 5 at same time. Because resources are splittingactivities and the dependencies make completion almost impossible.

Lecture 2 Apr 7, 2008 //48

Page 14: IS 556 Enterprise Project Management

IS 556 -Spring 2008 14

CPM Actual Task Performance

Note that date is now Sept 13th – over a month later. Because all3 beginning tasks of #1 are done simultaneously, each takes 3 timeslonger because each duration on original assumed 100% commitment

Lecture 2 Apr 7, 2008 //48

Page 15: IS 556 Enterprise Project Management

IS 556 -Spring 2008 15

CPM- Resource Leveled Schedule

The software had only tasks 5 and 6 in the critical path – becausethe Critical Path is NOT determined after resource leveling. The CP isdefined as having no slack because it is the longest path to completion.

Resource leveling –rescheduling activities so resource limits not exceeded

Lecture 2 Apr 7, 2008 //48

Page 16: IS 556 Enterprise Project Management

IS 556 -Spring 2008 16

Critical Chain longest path after resource leveling

The critical chain consists of both the time and the person (resource)constraint.

Lecture 2 Apr 7, 2008 //48

Page 17: IS 556 Enterprise Project Management

IS 556 -Spring 2008 17

Exploit the Constraint To have a successful project, every task on the critical

path completes on schedule.

To do that, we must plan every task to include a contingency (difference between a 50% probable estimate and a 90% probable estimate) because of the uncertainty present.

Therefore, every task estimate will include this contingency but it is buried in the task estimate.

But, that leads to reallllllly long estimates so the PM cuts out what is assumed to be contingencywhich leads to the EVAPORATING CLOUD for this dilemma.

Lecture 2 Apr 7, 2008 //48

Page 18: IS 556 Enterprise Project Management

IS 556 -Spring 2008 18

1st Conflict Task Time Conflict

3 typical reasons given for projects overruns-1- group responsible for the late part of the project was sloppy-2- people always underestimate how long it will take-3- management set arbitrary dates

Lecture 2 Apr 7, 2008 //48

Page 19: IS 556 Enterprise Project Management

IS 556 -Spring 2008 19

Several Syndromes in Action Murphy’s Law

1. What can go wrong, will go wrong, does go wrong

Parkinson’s Law1. Work expands to fill the time scheduled.

Student’s Syndrome1. No matter how much time committed to project,

effort expands as urgency increases.

This leads to the 2nd conflict

Lecture 2 Apr 7, 2008 //48

Page 20: IS 556 Enterprise Project Management

IS 556 -Spring 2008 20

2nd Conflict “Successful Completion Rewards”

The answer is to do extra checks and “improve the quality” of the task I am doing.

Lecture 2 Apr 7, 2008 //48

Page 21: IS 556 Enterprise Project Management

IS 556 -Spring 2008 21

Typical Work Pattern

Yet, if this is true then why do most PM literature recommend the useof the early-start schedule. The team knows that there’s slack. HMMMMCan you guess what really happens?

Lecture 2 Apr 7, 2008 //48

Page 22: IS 556 Enterprise Project Management

IS 556 -Spring 2008 22

Multitasking So, everyone starts projects as the earliest possible date leading to

working on several tasks simultaneously So if you start 3 tasks at the same time and each task takes 1 week then,

at best the three tasks will all take 3 weeks to complete. This assumes that there is no time lost for task switching.

This leads to the 3rd conflict.

Lecture 2 Apr 7, 2008 //48

Page 23: IS 556 Enterprise Project Management

IS 556 -Spring 2008 23

3rd Conflict – The Multitasking Conflict

Multitasking delays all projects. Also justifies using longer task times in future plans

Lecture 2 Apr 7, 2008 //48

Page 24: IS 556 Enterprise Project Management

IS 556 -Spring 2008 24

Resolving Core Conflict Because you cannot make predictions about a single

instance of a statistical events, concentrate the uncertainty for many tasks of a project at end of the project.

Concentrate contingency in the buffer leads to 2 bonuses• 1st – SHORTER PLAN

because when we take out the task buffers and put at the end of the path, they add up to the square root of the sum of the squares of the amount removed --- some tasks overrun, some tasks underrun, the distribution of the sum is not as large as the sum of the individual variations because some cancel out!!

• 2ND – REDUCED LIKELIHOOD OF A LARGE OVERRUN

Lecture 2 Apr 7, 2008 //48

Page 25: IS 556 Enterprise Project Management

IS 556 -Spring 2008 25

Contingency (Buffers) at end of Project

The key part of the solution is to use “average” task completiontimes in the plan and to add an aggregated buffer at the end of the plan for overall project contingency.

Lecture 2 Apr 7, 2008 //48

Page 26: IS 556 Enterprise Project Management

Homework

Hmwk wk 2 on COL

26IS 556 -Spring 2008 Lecture 2 Apr 7, 2008 //48

Page 27: IS 556 Enterprise Project Management

IS 556 -Spring 2008 27

Hmwk wk2 – Due Session 3 In Leach text section 2.5.3 Rewards are discussed. Based

on what Leach says and any other sources you have, answer the following questions with its label.

1. Name and describe one common reward/punishment used by project managers on individuals.

2. What project member behavior rewards from having that reward/punishment.

3. In your opinion, how successful is the reward/punishment at keeping the entire project on schedule. In other words, is the project schedule really affected by the use of that reward/punishment? Why?

Ideal length – 1.0 page for all 3 answers

Lecture 2 Apr 7, 2008 //48

Page 28: IS 556 Enterprise Project Management

IS 556 -Spring 2008 28

Next Session

Chapters 4-6 of Leach

Lecture 2 Apr 7, 2008 //48