Project management by numbers E-Book

Dietmar Prudix

• Herausgeber: Books on Demand
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 127

Veröffentlichungsjahr: 2016

Beschreibung

Project management by numbers is an experiment to describe different perspectives of project management. With different points of views interested people will get additional access to project management. In short chapter you´ll find short explanations, easy and to the point explained. This enables everybody to get fast insights within a short time period. Enjoy

Leseprobe

Table of Contents

Forward

42 Personal projekt strategies from Napoleon

64 Reasons that is project fail

5 Definitions of Project Failure

22 Types of Project Risk

12 Examples Of The Pareto Principle

130 Project Management Objectives

100 NASA Rules

39 Types of Project Risk

5 Types of Risk Treatment

19 Types of Project Constraint

101 Project Management Basics

16 Types of Project Stakeholder

19 Agile Principles

26 Scrum Basics

15 Immutable Laws of Project Management

10 Project Management Best Practices

63 Experts Share Their #1 Tip

8 Reasons, Benefits and Overviews

9 Lessons Learned from the Apollo 11 Moon Landing

7 Top Challenges by Peter Taylor

5 Lessons to Learn from Superheroes

Forward

Attached you ´ll find different perspectives of project management with different insights: The best way to get an access to projects including success factors.

For example Jerry Madden, retired associate director of the flight projects directorate within the NASA`s Goddard Space Flight Center is known as the first project manager in the NASA organization. Over years he collected these gems of wisdom.

Although it`s not part of Jerry`s written lessons learned, he consistently told his people the following: “Show up early for all meetings; they may be serving doughnuts.” Finally, Les Meredith (former director of Space Sciences and Acting Center Director) had this remark to make about Jerry Madden`s project managers lessons learned: “God only gave us ten commandments. Jerry has listed over a hundred instructions to a project manager. It is evident a lot more is expected from a project manager”

So the idea was born: Project management by numbers.

Project management is people business. A lot of learnings are linked to well-known people, like Napoleon or some super heroes.

Enjoy

Dietmar Prudix

42 Personal projekt strategies from Napoleon

Planning

1. I start out by believing the worst.

2. The reason most people fail instead of succeed is they trade what they want most for what they want at the moment.

3. There is only one step from the sublime to the ridiculous.

Office Politics

4. Never interrupt your enemy when he is making a mistake.

5. In politics, stupidity is not a handicap.

6. The herd seek out the great, not for their sake but for their influence; and the great welcome them out of vanity or need.

7. When you have an enemy in your power, deprive him of the means of ever injuring you.

8. If they want peace, nations should avoid the pinpricks that precede cannon shots.

9. We frustrate many designs against us by pretending not to see them.

Motivating Teams

10. Give me enough medals and I’ll win you any war.

11. A cowardly act! What do I care about that? You may be sure that I should never fear to commit one if it were to my advantage.

12. Courage isn't having the strength to go on - it is going on when you don't have strength.

13. Impossible is a word to be found only in the dictionary of fools.

14. Victory belongs to the most persevering.

Training and Professional Development

15. Show me a family of readers, and I will show you the people who move the world.

Leadership

16. Imagination rules the world.

17. A leader is a dealer in hope.

18. He who fears being conquered is sure of defeat.

19. Ten people who speak make more noise than ten thousand who are silent.

20. Ability is of little account without opportunity.

21. Circumstances-what are circumstances? I make circumstances.

22. Glory is fleeting, but obscurity is forever.

23. In our time no one has the conception of what is great. It is up to me to show them.

24. A true man hates no one.

25. One is more certain to influence men, to produce more effect on them, by absurdities than by sensible ideas.

26. Lead the ideas of your time and they will accompany and support you; fall behind them and they drag you along with them; oppose them and they will overwhelm you.

Work Life Balance

27. Let him sleep ... for when he wakes, he will move mountains.

Product Launch

28. The greatest danger occurs at the moment of victory.

Managing Teams

29. Never ascribe to malice that which can adequately be explained by incompetence.

30. If you want a thing done well, do it yourself.

Managing Stakeholder Expectations

31. The best way to keep one's word is not to give it.

Project Communications

32. Four hostile newspapers are more to be feared than a thousand bayonets.

Managing Issues

33. The battlefield is a scene of constant chaos. The winner will be the one who controls that chaos, both his own and the enemies.

34. I may have lost a battle, but not the war.

35. In politics nothing is immutable. Events carry with in them an invincible power. The unwise destroy themselves in resistance. The skillful accept events, take strong hold of them and direct them.

Decision Making

36. Nothing is more difficult, and therefore more precious, than to be able to decide.

37. Take time to deliberate, but when the time for action comes, stop thinking and go in.

Project Management

38. All great events hang by a hair. The man of ability takes advantage of everything and neglects nothing that can give him a chance of success; whilst the less able man sometimes loses everything by neglecting a single one of those chances.

39. If you wish to be a success in the world, promise everything, deliver nothing.

Risk Management

40. If the art of war were nothing but the art of avoiding risks, glory would become the prey of mediocre minds.... I have made all the calculations; fate will do the rest.

41. Audacity succeeds as often as it fails.

Compliance

42. There are so many laws that no one is safe from hanging.

64 Reasons that is project fail

Testing fails to uncover serious defects that are later detected by users (shaking confidence in the product).

IT projects commonly fail. Studies peg the average project failure rate somewhere between 50%-80%.

In recent years, many organizations have mandated lessons learned sessions for every project. This has led to a better understanding of why projects fail.

Failure often has more than one root cause. In other words, many projects are ripe with problems. The following list (with examples) represents the most common reasons projects fail.

Business Case

1. Failure to evaluate alternatives

The business case fails to consider alternative approaches to the project. This exposes the project to challenges later (i.e. why didn't we consider ____ approach?).

2. Poor financial forecasts

Financial forecasts in the business case are inaccurate.

3. Optimism bias renders business case unrealistic The business case makes rosy assumptions that don't reflect business realities.

4. Cooked numbers in forecast

Lack of objective financial analysis. The developer of the business case makes the numbers "work".

5. Metric based approvals

Reviewers approve a business case based on a handful of forecast metrics without examining constraints and risks.

6. Missed future costs

The business case promises to reduce existing costs but fails to anticipate new costs the project will introduce. For example, a system project may free-up administrative resources but increase the need for system administrators (who are generally more expensive).

7. No business case

The project proceeds without a formal analysis of its merit.

8. Budgeting errors

A low quality project budget that leads to financial chaos.

9. Poor risk analysis

Failure to identify, analyse and communicate risks.

10. Failure to identify all stakeholders

The project manager fails to involve IT operations. When it comes time to launch, the head of operations rejects the project.

11. Optimistic resource assumptions

The project plan assumes key resources are 100% committed to the project when they have other commitments.

12. Optimistic estimates

Estimates that are overly optimistic or fail to consider true project scope.

13. Coerced estimates

The project manager directs the team to provide low estimates.

Can you estimate this? I don`t except it that it will take you any longer than few days.

14. Naive estimates

Those who provide estimates don't have the requisite experience (e. g. the project manager provides estimates for the testing phase).

15. Rough estimates

Ballpark estimates are assumed to be rock solid (no formal estimates are produced).

16. Failure to properly estimate tasks not considered critical

Tasks that aren't on the critical path such as data migration are severely underestimated.

17. Poor task scheduling

The work breakdown structure is missing dependencies.

18. Big bang releases

It's well accepted that releasing a project in incremental phases tends to reduce risk and cost. Nevertheless, projects tend to be planned with major releases.

19. No Methodology

The project is executed according to an ad-hoc process that's likely to fail.

Requirements

20. Inadequate requirements

Unclear requirements that leave too much room for interpretation. In many cases, the project manager or developers end up filling in the blanks.

21. Gap between requirements and expectations

Business users begin to dream that the system will do things that aren't captured by the requirements.

22. Requirements aren't compliant

Requirements are not in compliance with laws, regulations, standards, best practices or requisite audits.

23. Silo requirements

Requirements fail to look at the project at the enterprise level. For example, they fail to consider integration with key business processes.

24. Naive requirements

Lack of due diligence in developing and validating requirements (e. g. subject matter experts aren't consulted).

25. Solution in search of a problem

The requirements don't solve business problems.

26. Requirements don't match the business case

The requirements drift from the original goal of the project.

27. Requirements dictate architecture

Requirements specify the solution. For example, specifying that a particular COTS product must be used without proper due diligence.

28. Inaccurate requirement priorities

Nice-to-have requirements are classified as high priority.

Project Execution

29. Project plan becomes outdated

The project plan isn't kept up to date during the execution phase. It quickly becomes obsolete and the project essentially runs without a plan.

30. Tasks aren't tracked

Schedule slippage isn't addressed until deadlines have passed. The project becomes hopelessly behind schedule and over budget.

31. Issues aren't managed

The project manager fails to aggressively escalate and resolve issues.

32. Scope management failure

Severe scope creep throws the project into disarray.

33. Risk realization

A risk identified in the planning phase is realized. For example, a project plan may identify a heavy dependency on a critical resource. If that resource resigns or becomes ill, the risk is realized and the project may fail.

34. Financial controls failure

The project manager fails to control the project budget.

35. Low performance

The performance of a key team member fails to meet expectations.

36. Communication failure

Project goals, objectives, progress; productivity, quality, risk and constraint information isn't transparent to key stakeholders. Expectations become out of line with project reality.

37. Low customer satisfaction

The customers (e. g. project sponsors or users) aren't happy with the project. For example, executives get the perception that the project is out of control.

Business

38. Business strategy change

New business priorities lead to project cancellation.

39. Business environment

A recession or industry event takes place that triggers project cancellation.

40. Organizational changes

Organizational changes disrupt project execution.

41. Business disruption

Project launch often requires time from key business talent (e. g. learning a new system or launching new business processes). For this reason, there is sometimes resistance to launch.

42. Low user adoption

Users refuse to adopt a new technology or process.

43. Excessive quality sacrifices

Business demands a fast, cheap project. They sign off on risks that the project will have quality issues. The result is a low quality product that's unusable.

44. Negative business results

A project that's delivered to specifications but the business results don't meet expectations. For example, a new product that decreases sales instead of improving sales.

45. Force Majeure

An act of war or nature.

Political

46. Loss of sponsorship

The sponsor changes their mind about the project.

47. Loss of executive support

Powers larger than the sponsor step in to stop the project (sponsor lacks support).

48. Project Infighting

Interpersonal conflict between team members.

49. Passive aggressive tactics

A stakeholder secretly sabotages the project.

50. Vendor management failure

Your relationship with a key vendor turns bad and project issues quickly pile up.

51. Vendor infighting

The relationship between vendors turns bitter and issues mount.

Technical

52. Naive technology selection

Business chooses technologies without understanding the full implications of their decisions.

53. Inadequate technology evaluation

Technologies are chosen without a diligent evaluation.

54. Poor architectural design

The solution architecture is flawed leading to insurmountable project issues.

55. IT governance

IT governance blocks the project. For example, the project duplicates capabilities that already exist.

56. Loss of key technical resources

Losing a key resource who has no backup.

57. Unforeseen technology dependencies

A technology dependency is identified in the execution phase that delays the project.

58. Gold plating

Developers add features to the product that aren't in the requirements. The added complexity escalates project costs or prompts users to reject the product.

59. Security vulnerabilities

Security vulnerabilities in a chosen technology trigger unforeseen risks, costs and delays.

60. Capacity planning failure

The product fails performance testing and requires hardware or software reworks beyond the project's budget.

61. Tool breakdown

Tools (e. g. development tools) are buggy or ineffective leading to delays.

62. Data quality

The data migration team discovers that data quality is low. The solution is unusable without major data quality initiatives.

63. No methodology

Development follows an adhoc process that's prone to failure.

64. Inadequate testing

Testing fails to uncover serious defects that are later detected by users (shaking confidence in the product).

5 Definitions of Project Failure

Most IT professionals will agree that project failure is common. Exactly how common largely depends on the definition of project failure.

Different studies peg the average IT project failure rate between 50%-80%. However, they tend to use differing criteria to define failure.

There are at least 5 common definitions of project failure:

1. Judgment Call

The stakeholders (or some subset of stakeholders) decide if a project is a success or failure. For example, a project board may make this decision as part of project closure activities.

In other words, a project is a failure if its stakeholders consider it a failure. This is the most commonly accepted definition of project failure.

2. Delivery to Plan

Any project that fails to meet time, budget and quality targets is considered a failure.

This is a relatively strict definition that may lead project managers to pad schedules and budgets with excessive contingency.

3. On-time Delivery

Any project that is late is considered a failure.

Organizations in highly competitive, time-to-market driven industries are sometimes tolerant of cost overruns as long as a project meets its target launch date.

4. Financial Results Match Projections

Any project that fails to meet the financial forecasts set out in its business plan is considered a failure.

In many ways, this is the most effective definition. It's hard to mark a successful investment as a failure.

5. Minimum Return

The project fails to meet a minimum return criteria (e.g. a minimum ROI target).