When Things Go Right

Cornell’s PeopleSoft 8.9 Upgrade

Lisa StenslandManager, CIT Project Management Office

May 15, 2008

Agenda

• Challenge• Change in Methodology and How We

Manage Resources• Results

Challenge

• Two critical projects competing for resources– Upgrade PeopleSoft (HR, Payroll, Contributor

Relations) from 8.0 to 8.9– Implement PeopleSoft Student Administration

modules

• Technical implementations could not overlap• They both must be done ASAP

Analysis

• Conducted forecasting of schedule and budget for multiple options– Upgrade first, then implement Student Admin

…or…– Implement Student Admin, then upgrade the

whole thing

• Decision– Upgrade first, do it as quickly as possible

What We Knew

• The forecasting effort indicated that the PS 8.9 Upgrade project would take approximately 15-18 months to complete– Late Summer 2005 - Spring 2007

• We spent 3 months doing more detailed planning, which resulted– Targeted completion in Winter of 2006– Estimated $5M budget

What We Knew

• The timing of a Fall 2006 upgrade was not ideal– Competing business cycles– A “tax/fix version” of PS comes out at that time,

and how would we address that?

• How do we bring the schedule in further when all our planning indicates that we can’t?

I did some digging….

Critical Chain Project Management

• A way to schedule and track a project that encourages:– Aggressive scheduling– Team Focus– Team ownership of the project commitment

The old way….

Create list of tasks

Project Manager asks,“How long will

each task take?”

Well…about 5 days+ I am working

on another project+ I get interrupted

alot+ Something usually goes wrong

So…10 days!

Safety in estimation

• Time needed to protect the work estimate commitment from: – Murphy’s Law - what can go wrong, will go wrong– Distraction – Multi-tasking

Parkinson’s Law

Work expands to fill the time allotted

“Student Syndrome”

Many people will start to fully apply themselves to a task at

the last possible moment before a deadline.

What do these factors do to a project?

• It is normal to focus on task ‘due dates’• Student Syndrome -> Late starts• Parkinson’s Law

– If nothing goes wrong, the task will finish on time– If something goes wrong, the task will likely finish

late

• Late tasks on the critical path will delay the project

What should be done differently?

Remove the safety from the individual tasks

Safety

Safety

Safety

Safety

Move it to the end…the Project Buffer

Safety

Safety

Safety

Safety EndEnd

Earliest Possible Finish

Committed Finish

Refocus the team on…

• Starting tasks on time• Completing tasks as aggressively as possible • Managing the amount of Project Buffer that is

consumed– Project Buffer is consumed when a task on the

critical path is late– Project Buffer is replenished when a task on the

critical path is early

P S 8 . 9 U p g r a d e F e v e r C h a r t

0 . 0 %

1 0 . 0 %

2 0 . 0 %

3 0 . 0 %

4 0 . 0 %

5 0 . 0 %

6 0 . 0 %

7 0 . 0 %

8 0 . 0 %

9 0 . 0 %

1 0 0 . 0 %

9/27/200510/4/2005

10/11/200510/18/200510/25/2005

11/1/200511/8/2005

11/15/200511/22/200511/29/2005

12/6/2005

12/13/200512/20/200512/27/2005

1/3/2006

1/10/20061/17/20061/24/20061/31/2006

2/7/2006

2/14/20062/21/20062/28/2006

3/7/2006

3/14/20063/21/20063/28/2006

4/4/2006

4/11/20064/18/20064/25/2006

5/2/2006 5/9/2006

5/16/20065/23/20065/30/2006

6/6/2006

6/13/20066/20/20066/27/2006

7/4/2006

7/11/20067/18/20067/25/2006

8/1/20068/8/2006

8/15/20068/22/20068/29/2006

9/5/2006

9/12/20069/19/20069/26/200610/3/2006

10/10/200610/17/200610/24/200610/31/2006

11/7/2006

11/14/200611/21/200611/28/2006

12/5/2006

12/12/200612/19/2006

S t a t u s D a t e

% Buffer Utilization

July

October

December

P S 8 . 9 U p g r a d e F e v e r C h a r t

0

1

2

3

4

5

6

7

8

9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

2/24/2006

3/3/2006

3/10/2006 3/17/2006 3/24/2006 3/31/2006

4/7/2006

4/14/2006 4/21/2006 4/28/2006

5/5/2006

5/12/2006 5/19/2006 5/26/2006

6/2/2006 6/9/2006

6/16/2006 6/23/2006 6/30/2006

7/7/2006

7/14/2006 7/21/2006 7/28/2006

S t a t u s D a t e

Buffer Utilization

7 / 7

7 / 1 4

7 / 2 1

7 / 2 8

F i n a l c u t o v e r d e c i d e d :

J u l y 2 8 - 3 1

What Had to Change?

• Estimate aggressively by removing safety from individual tasks– Trust management to not hold staff accountable to

aggressive estimates without safety

• Put safety where the project can use it• Minimize multi-tasking• Track progress using buffer consumption

– Not individual milestones!

Benefits

• Protection against Murphy’s Law• Took advantage of early finishes• Team protected the project buffer• Opportunity for team to focus• Sponsor visibility to what is possible vs

realistic• Better visibility to when project is in trouble

The Results?

• Team cutover to PeopleSoft 8.9 in July 2006– Our most aggressive possible go-live!

• Project delivered 40% under-budget– $3M spent– $2M saved

• Staff time not needed - $1.3M

• Unused contingency - $500K

Moral of the story…

• Encourage aggressive planning by developing trust between management and the team

• Allow staff to focus on one task at a time rather than multitask across projects

• Implement mechanisms that encourage the team to protect the project commitment, rathern than individual commitments

More information…

• Critical Chain Project Management– http://www.focusedperformance.com/articles/ccpm

.html