Some national and international projects projects in Slovak archives
Why some projects fail why some projects succeed
-
Upload
raymond-cruz -
Category
Business
-
view
5.724 -
download
1
description
Transcript of Why some projects fail why some projects succeed
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