Raymond CruzSenior Program Manager/Directorhttp://www.linkedin.com/pub/raymond-cruz-pmp/2/645/924

Definition Classic Triple Constraint

Chaos Definition Project Resolution By Type Profiles

Project Management System Articles Summary References

2

Project success is defined as the completion of a project Within the allocated time period Within the budgeted cost At the proper performance or

specification level With acceptance by the customer/user With minimum or mutually agreed upon scope

change Without changing the corporate culture

3

Cost

Budget Limit

Time(“Schedule”)

Due Date

Performance

Required Performance

Target

Meets or Exceeds Customer’s ExpectationMeets or Exceeds Customer’s Expectation

4

"The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task."

Tom Clancy (The Sum of All Fears)

http://www1.standishgroup.com//

5

Success Project is completed on-time, on budget,

and with most of the features & functions

Challenged Project is completed over-budget, over-

time, and/or fewer features & functions

Impaired Canceled & unused

6

16.2%

52.7%

31.1%

Type 1 Type 2 Type 3Type 1: Project Success

• Completed on-time, on budget

• Has specified features/functions

Type 2: Project Challenged

• Completed & functional, over-budget, over time estimate

• Offers fewer features/functions

Type 3: Project Impaired

• Project cancelled in development cycle

7

Item

1

2

3

4

5

6

7

8

9

10

11

Smaller Project Milestones

8.2%

7.7%

Hard-Working, Focused Staff 2.4%

Other 13.9%

Project Sucess Factors % of Responses

Realistic Expectations

User Involvement 15.9%

Executive Support 13.9%

Clear Statement of Requirements 13.0%

Proper Planning 9.6%

Clear Vision & Objective

Competent Staff 7.2%

Ownership 5.3%

2.9%

8

Item

12345678910

Other

Incomplete Requirements & SpecificationChanging Requirements & SpecificationLack of Executive Support

Lack of ResourcesUnrealistic expectation

Unrealistic Time Frames

% of ResponsesProject Challenged Factors

Unclear Objective

7.5%Technology Incompetence

23.0%

4.3%New Technology 3.7%

7.0%6.4%5.9%5.3%

12.3%11.8%

Lack of User Input 12.8%

9

Item

1

2

3

4

5

6

7

8

9

10

Other

9.3%

8.7%

10.6%

9.9%

13.1%

12.4%

8.1%

7.5%

% of ResponsesProject Impaired Factors

Lack of IT Management 6.2%

Technology Illiteracy 4.3%

9.9%

Incomplete Requirements

Lack of User Involvement

Lack of Resources

Unrealistic expectation

Lack of Executive Support

Changing Requirements & Specification

Lack Of Planning

Didn't Need it any Longer

10

11

12

Most projects fail for one or more of the following reasons: Inappropriate use of the project form of

organization Insufficient top management support Naming the wrong project manager Poor planning

13

Success Failure

14

Focus groups to address problems of procedure & communication

Hold regular meetings Program managers

Leadership Sniff out barely visible issues Excellent communicators

Common objective for customer, project office & function

Customer provides proper direction & problem solving

Good project planning & control

15

Management's seven deadly sins:

– Mistaking half-baked ideas for Mistaking half-baked ideas for viable projects viable projects

– Dictating unrealistic project Dictating unrealistic project deadlines deadlines

– Assigning under-skilled project Assigning under-skilled project managers to high-complexity managers to high-complexity projects projects

– Not ensuring solid business Not ensuring solid business sponsorship sponsorship

– Failing to break projects into Failing to break projects into manageable "chunks" manageable "chunks"

– Failing to institute a robust project Failing to institute a robust project process architecture process architecture

– Not establishing a comprehensive Not establishing a comprehensive project portfolio to track progress project portfolio to track progress of ongoing projects of ongoing projects

Ten Signs of IS Project Failure:

– Project managers don't Project managers don't understand user’s needs understand user’s needs

– Scope is ill-defined Scope is ill-defined

– Project changes are managed Project changes are managed poorly poorly

– Chosen technology changes Chosen technology changes

– Business needs change Business needs change

– Deadlines are unrealistic Deadlines are unrealistic

– Users are resistant Users are resistant

– Sponsorship is lost Sponsorship is lost

– Project lacks people with Project lacks people with appropriate skills appropriate skills

– Best practices and lessons Best practices and lessons learned are ignored learned are ignored

16

Loss of key players

No in-house expertise for total project concept

Coordination vacuum

Self-directed project teams

Bad Planning

Weak business case

Loss of executive sponsorship

Selection of a concept that is not applicable

Selection of the wrong person as project manager

Upper management that is not supportive

Inadequately defined task

Misused management techniques

• Team DeclineTeam Decline55

Loss Of key players Imposes norms standard

workload Interface management

disputes Subcontractor

performance Personal Motivation

17

The lessons often contradict what one learns in smaller projects and in everyday life

The lessons derive from over 100 consulting studies of such programs that used an extensively evolved and validated series of dynamic simulation models.

The lessons are demonstrable: The simulation models allow controlled experiments to identify with certainty which management strategies are successful and why.

The lessons are rules of thumb for both planning and starting a program and responding to the unexpected, both in the small and the large.

The lessons fall into three major areas: team architecture, managing re-work and managing the plan.

18

Item

1

2

3

4

5

6

7

Put customers on the team.

Lesson Why

Twenty percent of the Total employees account 50% of the productivity "Augustine's Law"

Data

Hire the right people. Hiring for industry pays off.

Customers discover mismatches at the wrong end of the 1, 10, 100,1000 sequence. (1 hour Specification, 10 Hrs Design, 100 Hrs Implementation, 1000 Hrs Test)

Twenty percent reduction in program cost and schedules.

Like redesigns for cost, such changes add as much or more indirect impact through rework as they do in direct and obvious work.

Components of complex products such as aircraft can seldom be redesigned without affecting other parts, and without a rework cycle.

When evaluating whether or not to redesign for affordability, include the full likely costs of the redesign, which will be a multiple of the "plan for success" direct costs-count on two to eight times if the modeling or analysis capability for more rigoro

Mitigate redesign by focusing on the essentials.

Cross-functional integrated product teams (IPTs) are a proven "best practice" in many industries.

When redesigning for affordability, assume that redesign cost will be several times the direct cost.

There is a temptation to add changes, "as long as the design is being upgraded anyway."

Include all the functions in IPT's

When implementation starts, managers will find themselves in several months of added turbulence. They should stay the course!

Use a dedicated cross-functional team to do major design rework.

Charter a distinct cross-functional team activity to work through all the issues offline, even if it means apparently slowing down the whole program.

Moving to IPTs, prepare for pain before gain.

IPTs are highly beneficial. But companies shifting to this form of organization hesitate to change programs already under way;

Without a major cross-functional rethinking of the system architecture and replanning of the subsequent detailed work, literally more mistakes than finished work can be created.

IPT's instead of traditional functional organizations could save 25% on schedule and 30% on labor cost

19

Item

8

9

10

11

12

13

Lesson Why

Plan for rework. Leave time for rework:

"Planning for success" invites failure.

Understaff the front of phases; overstaff the finish to kill rework.

Starting design work before the requirements are stable is counterproductive in the long run. It is better to do high-quality work up front and use resources at the end of a phase to accomplish known rework quicker.

For large, complex programs, it is nearly a statistical certainty that rework will occur, and there are many opportunities for rework to propagate-to corrupt the design of related subsystems.

Put rework detection and correction first.

Execute development phases serially, not in parallel.

Concurrent development, for example, does not put up the roof concurrent with pouring the foundation!

Finish detailed design before starting to code software or create mechanical drawings. If there is schedule pressure, put resources onto reviewing the present phase's work to scour out any remaining defects.

For every work phase that an error remains undetected, the cost to fix it goes up roughly an order of magnitude.

If quality of execution is even in doubt, slip the close-in milestones. Even in terms of just completing the present phase, emphasizing quality often gets the work done sooner

Programs revealed savings of roughly 20% of overall program cost, simply from this strategy plus prioritizing rework above new work

Always take the time to do process improvements.

Process improvements are more beneficial to programs with deep schedule/resource/quality/rework troubles than to smoothly running programs.

Process improvements accounted for a reduction of roughly 30% off cost and 25% off schedule.

Even with a slow startup, don't slip testing.

Simulation analysis revealed that even with (an appropriately) larger budget, early testing had a clear overall benefit to the program.

Testing, because it is earlier in the development cycle, will reveal more flaws than normal, which is constructive and proper. If expectations are set properly, testing can make even more of a contribution than normal.

Data

20

Item

14

15

16

17

18

19

20

Lesson Why

Use time and program management attention to getting leadership in all the functions on board and up to speed. Firm, realistic specifications add considerable efficiency for later in the program. Allow the vendors to take the same constructive response t

Mitigate slow startup by slipping interim milestones.

A program will be underfunded at the start or otherwise delayed, and yet the client will want the same schedule.

An initial underfunding and slow-start situation that would have added 20% to the total program cost.

Adding people creates confusion on roles, gives tasks to people unfamiliar with them, creates hidden quality and rework problems, often brings in people with less experience and skill than the current staff, and in general throws yet another monkey wrench

Prohibit long-term overtime.

Long-term (three months or longer) overtime isn't worth the productivity and quality problems created by fatigue, morale, and turnover issues.

Study also finds that 12 hours per week overtime per engineer even for as short a period as two months actually results in less finished, ultimately usable work output than a standard 40-hour week.

Best risk management requires, in addition, designing the program ahead of time (and spending extra resources when appropriate) to minimize risk impacts to the overall program.

Don't shrink the schedule without expanding the budget.

Nine women and a man can't create a baby in a month.

Don't wait for problems to grow.Delaying the updating of an official plan for political (or client relations) reasons not only can make relations worse by delaying bad news, but also actually creates more bad news.

20% reduction in total program duration, for a schedule that was already moderately aggressive, added over 50% to the total labor expended.

React to progress problems or understaffing problems sooner rather than later.

Go all the way to mitigation planning.

Because it's so difficult to know with certainty when they're right or wrong, there is considerable value in using a formal process and formal analysis to design an effective management response.

Remember Brooks' law." Adding labor to a late software project makes it later,"

It is often intuitively compelling (and usually untrue) that the alternative to slipping interim milestones is adding more people to allow the program to stay on schedule.

Mitigate slow start by building the leadership team, the core specifications, and vendor knowledge.

Don't spend scarce dollars adding Indians; go for getting each and every Chief early to form a cohesive and experienced leadership group.

Data

21

Staff Project Mission Executive Support Clear Statement of Requirements Proper Planning Realistic Schedules Hire the Right People. Customers Participation. Communication Monitoring and Feedback

22

Incomplete Requirements Unrealistic Project Deadlines Loss of Executive Support Changing Requirements & Specifications Poor Planning Lack of Customer Inputs Inadequate Resources Wrong Project Manager Subcontractor Performance Breakdown in Communication

23

Suggested1CHAOS Report2Unfinished Voyages Report3“Competition Drives Changes in Organizational

Structure”, PM Network, November 19964“When Bad Things Happens to Good Projects”, CIO

Magazine, October 1997, http://www.cio.com.au/article/6262/when_bad_things_happen_good_ideas/

5Moore T., and M. Ahmad, Can Project Success and Failure be Predicted ?, Hydrocarbon Processing, Vol. 79, Issue 2, p55, 2000

24

Researched6Meredith J. R. and S.J. Mantel, Project Management: A

Managerial Approach, John Wiley & Sons, Inc. 2000 Fourth Edition

7Zimmer B.T. ,”Project Management: A Methodology for Success”, Hospital Materiel Management, Vol. 21, Issue 2, p83, 1999

8Martin J. J., “Mixed Emotions at End of Project”, Computer World Canada, Vol.15, Issue 16, p18, 1999

9“Projects Need a Clear Objective”, Insurance System Bulletin Vol. 13, Issue 11, p6, 1998

10Mahaney R. C. and A. L. Lederer, “Another Look at On Time and Within Budget: An Agency Theory Explanation”, Journal of Database Management, Vol.10, Issue 3, p41, 1999

25

Researched11Kerzner H., Project Management: A System Approach to

Planning, Scheduling, and Controlling, John Wiley & Sons, Inc. 1998

12Dorf R. C., The Technology Management Handbook, Richard C. Dorf, Editor-in-Chief, CRC/IEEE Press, 1999

13Graham, Alan K., “Beyond PM 101: Lessons for Managing Large Development Programs”, Project Management Journal, Sylva, Dec. 2000

14Fisher, M., “Cutting the Costs of Turnkey”, Food Manufacture, Feb. 96, Vol 71, Issue 2, p31

15Schulz, Y., Project Teams Need a Qualified, Full Time Leader to Succeed, Computing Canada, 05/26/2000, Vol. 26, Issue 11, p11

16Saunders, J., Bad Project Management Remains a major Problem, Computing Canada, 12/22/1997, Vol. 23, Issue 26, p1

26