"Rushing into action, you fail.
Trying to grasp things, you lose them.
Forcing a project to completion,
you ruin what was almost ripe."
(Lao Tzu, "Tao Te Ching", cca. 6th-century BC)
"In many ways, project management is similar to functional or traditional management. The project manager, however, may have to accomplish his ends through the efforts of individuals who are paid and promoted by someone else in the chain of command. The pacing factor in acquiring a new plant, in building a bridge, or in developing a new product is often not technology, but management. The technology to accomplish an ad hoc project may be in hand but cannot be put to proper use because the approach to the management is inadequate and unrealistic. Too often this failure can be attributed to an attempt to fit the project to an existing management organization, rather than molding the management to fit the needs of the project. The project manager, therefore, is somewhat of a maverick in the business world. No set pattern exists by which he can operate. His philosophy of management may depart radically from traditional theory." (David I Cleland & William R King, "Systems Analysis and Project Management", 1968)
"But the greater the primary risk, the safer and more careful
your secondary assumptions must be. A project is only as sound as its weakest assumption, or its largest uncertainty." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)
"Faced with a decision, always ask one implacable question: If this project fails, if the worst comes to the worst, what will be the result? If the answer is total corporate disaster, drop the project. If the worst possible outcome is tolerable, say, break-even, the executive has the foundation of all sound decision making - a fail-safe position." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)
"The Eighth Truth of Management is: if you are doing something wrong, you will do it badly. The reverse of this truth is that, if your decision is blindingly right, you will execute it well - or appear to do so, which is much the same thing. But any executive can massacre his own nonsensical project." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)
"Yet intelligent men plump for one project rather than
another on the strength of a difference of a few decimal points in the rate of
return calculated over the next decade. All such mind-stretching calculation comes
under the lash of the Seventh Truth of Management: if you need sophisticated
calculations to justify an action, it is probably wrong (the sophisticated
calculations, anyway, are all too often based on simple false assumptions)." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)
"Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs." (Barry Boehm, "Software Engineering Economics", 1981)
"[…] the longer one works on […] a project without actually concluding it, the more remote the expected completion date becomes. Is this really such a perplexing paradox? No, on the contrary: human experience, all-too-familiar human experience, suggests that in fact many tasks suffer from similar runaway completion times. In short, such jobs either get done soon or they never get done. It is surprising, though, that this common conundrum can be modeled so simply by a self-similar power law." (Manfred Schroeder, "Fractals, Chaos, Power Laws Minutes from an Infinite Paradise", 1990)
"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)
"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve C McConnell, "Software Project Survival Guide", 1997)
"Today, excellent companies realize that project failures have more to do with behavioral shortcomings - poor employee morale, negative human relations, low productivity, and lack of commitment." (Harold Kerzner, "In search of excellence in project management", 1998)
"Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%." (Barry Boehm, "Software Cost Estimation with Cocomo II", 2000)
"Choosing a proper project strategy can mean the difference between success and failure." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"Note that a project always begins as a concept, and a concept is usually a bit fuzzy. Our job as a team is to clarify the concept, to turn it into a shared understanding that the entire team will accept. It is failure to do this that causes many project failures." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"Project failures are not always the result of poor methodology; the problem may be poor implementation. Unrealistic objectives or poorly defined executive expectations are two common causes of poor implementation. Good methodologies do not guarantee success, but they do imply that the project will be managed correctly." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)
"Projects often fail at the beginning, not the end." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"Success or failure of a project depends upon the ability of key personnel to have sufficient data for decision-making. Project management is often considered to be both an art and a science. It is an art because of the strong need for interpersonal skills, and the project planning and control forms attempt to convert part of the 'art' into a science." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)
"Today, most project management practitioners focus on planning failure. If this aspect of the project can be compressed, or even eliminated, then the magnitude of the actual failure, should it occur, would be diminished. A good project management methodology helps to reduce planning failure. Today, we believe that planning failure, when it occurs, is due in large part to the project manager’s inability to perform effective risk management." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)
"When unmeetable expectations are formed, failure is virtually assured, since we have defined failure as unmet expectations. This is called a planning failure and is the difference between what was planned to be accomplished and what was, in fact, achievable. The second component of failure is poor performance or actual failure. This is the difference between what was achievable and what was actually accomplished. […] Perceived failure is the net sum of actual failure and planning failure. […] Planning failure is again assured even if no actual failure occurs. In both of these situations (overplanning and underplanning), the actual failure is the same, but the perceived failure can vary considerably." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)
"You need to identify and terminate infeasible projects early. Sending a message to project managers that project termination threatens their career will tempt them to continue projects that should die” (Barry Bohem,"Project termination doesn't equal project failure", Computer, 34 (9), 2001)
"Projects fail because of context, not because of content.[...] the traditional emphasis in project management on the technical issues of the project (content) has led to a legacy of an extremely poor set of tools, techniques, and tips for managing the complex of people, political, and other 'softer' issues that make up the context of the project." (Rob Thomsett, "Radical Project Management", 2002)
"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses." (Barry Boehm & Richard Turner, "Observations on balancing discipline and agility", Agile Development Conference, 2003)
"A project is composed of a series of steps where all must be
achieved for success. Each individual step has some probability of failure. We
often underestimate the large number of things that may happen in the future or
all opportunities for failure that may cause a project to go wrong. Humans make
mistakes, equipment fails, technologies don't work as planned, unrealistic
expectations, biases including sunk cost-syndrome, inexperience, wrong
incentives, contractor failure, untested technology, delays, wrong deliveries,
changing requirements, random events, ignoring early warning signals are
reasons for delays, cost overruns and mistakes. Often we focus too much on the
specific project case and ignore what normally happens in similar situations
(base rate frequency of outcomes- personal and others)." (Peter Bevelin,
"Seeking Wisdom: From Darwin to Munger", 2003)
"If you've been in the software business for any time at all, you know that there are certain common problems that plague one project after another. Missed schedules and creeping requirements are not things that just happen to you once and then go away, never to appear again. Rather, they are part of the territory. We all know that. What's odd is that we don't plan our projects as if we knew it. Instead, we plan as if our past problems are locked in the past and will never rear their ugly heads again. Of course, you know that isn't a reasonable expectation." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)
"Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few. But it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. On the other hand, a good design can create opportunities to exploit those complex features." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)
"A fundamental reason for the difficulties with modern engineering projects is their inherent complexity. The systems that these projects are working with or building have many interdependent parts, so that changes in one part often have effects on other parts of the system. These indirect effects are frequently unanticipated, as are collective behaviors that arise from the mutual interactions of multiple components. Both indirect and collective effects readily cause intolerable failures of the system. Moreover, when the task of the system is intrinsically complex, anticipating the many possible demands that can be placed upon the system, and designing a system that can respond in all of the necessary ways, is not feasible. This problem appears in the form of inadequate specifications, but the fundamental issue is whether it is even possible to generate adequate specifications for a complex system." (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)
"The collapse of a particular project may appear to have a specific cause, but an overly high intrinsic complexity of these systems is a problem common to many of them. A chain always breaks first in one particular link, but if the weight it is required to hold is too high, failure of the chain is guaranteed." (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)
"As hard as it is to find good ideas, it's even more difficult to manage them. While the project is humming along, vision document in place and a strong creative momentum moving forward, there is another level of thinking that has to occur: how will the designs and ideas translate into decisions? Even if good designs and ideas are being investigated, and people are excited about what they're working on, the challenge of convergence toward specifications remains. If a shift of momentum toward definitive design decisions doesn't happen at the right time and isn't managed in the right way, disaster waits. For many reasons, project failure begins here." (Scott Berkun, "The Art of Project Management", 2005)
"Failure usually results from a lack of a common approach to accomplish the work as a team. Inadequate leadership fails to create the environment in which teams can flourish. Furthermore, potential team members are seldom trained in how to share their efforts to accomplish team goals. The team may also assume they know more about teamwork than they actually do. So we need to be able to differentiate between superficial teamwork and the real thing." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)
"Project failures can frequently be traced to unrealistic technical, cost, or schedule targets. Such targets may be entirely arbitrary or based on bad assumptions - setting team members up for failure. Furthermore, the goals that motivate one team member may not motivate another member. All tasks don’t have to be inherently motivating - that’s not sensible. But there have to be motivating factors, if by nothing more than participating in goal determination. This also helps ensure adequate opportunity and risk identification, analysis, and management." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)
"Projects are complex non-linear systems and have significant
inertia. If you wait to see acute problems before taking action, you will be
too late and may make things worse." (Scott Berkun, "Making Things Happen:
Mastering Project Management", 2005)
"The appropriate models help avoid costly errors that can lead to failure. One of the major sources of project failure is f lawed requirements and scope management. Models of the project environment, therefore, need to address the development and management of project requirements. Continuing to work on the project solution with an insufficient understanding of stakeholder requirements and a deficient requirements development process often leads to expensive time delays and redesigns. This doesn’t have to be the case. A strong requirements development and management process model can provide that ounce of prevention." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)
"Any effort at large-scale reorganization - that is, any project spanning more than two years and, more generally, anything that has not already been done - is inevitably doomed to failure." (Corinne Maier, "Bonjour Laziness: Why Hard Work Doesn't Pay", 2007)
"In software management, coordination is not an afterthought or an ancillary matter; it is the heart of the work, and deciding what tools and methods to use can make or break a project. But getting sidetracked in managing those tools is a potent temptation." (Scott Rosenberg, "Dreaming in Code", 2007)
"As a general rule, implementations do not just spontaneously combust. Failures tend to stem from the aggregation of many issues. Although some issues may have been known since the early stages of the project (for example, the sales cycle or system design), implementation teams discover the majority of problems during the middle of the implementation, typically during some form of testing." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)
"Implementing new systems is not like baking a cake.
Organizations cannot follow a recipe with the following ingredients: three
consultants, six weeks of testing, two training classes, and a healthy dose of
project management. Nor do projects bake for six months until complete, after
which time everyone enjoys a delicious piece of cake. For all sorts of reasons,
a well-conceived and well-run project may fail, whereas a horribly managed
project may come in under budget, ahead of schedule, and do everything that the
vendor promised at the onset." (Phil Simon, "Why New Systems Fail: An Insider’s
Guide to Successful IT Projects", 2010)
"Pre-implementation, post-implementation, and ongoing data audits are invaluable tools for organizations. Used judiciously by knowledgeable and impartial resources, audits can detect, avoid, and minimize issues that can derail an implementation or cause a live system to fail. Rather than view them as superfluous expenses, organizations would be wise to conduct them at key points throughout the system’s life cycle." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)
"The best managed project may fail, whereas a horribly managed project may come in under budget, ahead of schedule, and do everything that the vendor promised at the onset. In reality, however, organizations are unlikely to find themselves in one of these extreme scenarios. On a fundamental level, successfully activating and utilizing a new system is about minimizing risk from day one until the end of the project and beyond. The organization that can do this stands the best chance of averting failure." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)
"Understanding the causes of system failures may help organizations avoid them, although there are no guarantees." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)"Stakeholder management to me is key, as success or failure is in the eye of the beholder. Time, cost and quality fall prey to the perceptions of the key stakeholders, who may have nothing to do with the running of the project." (Peter Parkes, "NLP for Project Managers", 2011)
"Projects fail from under-communicating, not over-communicating. Even if resource constraints preclude the dependency that you want from being delivered any sooner, clarifying priorities and expectations enables you to plan ahead and work through alternatives." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)
"Reading reviews of failure can be a dispiriting exercise. It can also create a distorted perception of reality. Reform of the implementation of large programs and projects should not just be based on a litany of what has gone wrong. Many things go right and, for that very reason, go unnoticed." (Peter Shergold, "Learning from Failure", 2015)
"Complexity is one of the causes of failing projects; failing to split the project into smaller tasks also causes software quality issues or project failure. Complexity can also be caused by the size of the project; if the project is too big, there is a huge possibility that the project may become complex and complicated." (Abu S Mahfuz,"Software Quality Assurance", 2016)
"A correct and sanity-checked judgment of both the financial and logistic feasibility of a project is absolutely critical to its eventual outcome; get it wrong and a failed project is almost guaranteed. In support of this statement we can refer to the contents of a number of serious academic studies which support the idea that two of the chief causes of the failure, particularly the financial failure, of major infrastructure projects are optimism bias and strategic misrepresentations. […] Optimism bias means that the original project sponsors and planners fooled themselves that the project would be easy and could be completed within a 'back-of-the-envelope' budget, perhaps because they didn’t have the experience to know it would be difficult and expensive, or perhaps they didn’t want to know. Strategic misrepresentations mean that even if they did know it would be more difficult and expensive than their published estimate, they lied about it so that the Public, the Banks, and Politicians, would support the idea." (Tony Martyr, "Why Projects Fail", 2018)
"No project should be allowed to proceed without clear specification and acceptance criteria, that are understood by all participants." (Tony Martyr, "Why Projects Fail", 2018)
"[...] consistently good project results are hard to come by, yet most organisations continue to think they’re doing a great job. It’s got to the stage where project failure has become so commonplace that we’ve started to see it as success, or we just aren’t seeing clearly at all." (Tony Martyr, "Why Projects Fail", 2018)
"Every year more than two-thirds of projects are considered failures, and most organisations would not be surprised by this statistic. In most cases, however, failure was the result of not making a hard decision." (Colin D Ellis, "The Project Book", 2019)
"Organisations whose IT projects failed usually deployed recognisable project management methodologies; the reasons for failure were invariably to do with failures of project governance rather than simply of operational management." (Alan Calder, "ISO/IEC 38500: A pocket guide" 2nd Ed, 2019)
"Part of the problem is that we take project failure personally, seeing it as a stain on our reputation. It’s worth remembering that while a project may fail, this doesn’t make you a failure as a leader. In fact, the research shows that those who embrace failure become much more resilient and make better decisions as a result, so in that sense failure can only be a good thing." (Colin D Ellis, "The Project Book", 2019)
"Remember, though, there are only two reasons for project failure: poor project sponsorship and poor project management. And given that the buck stops with you, you could argue there’s only one reason for project failure." (Colin D Ellis, "The Project Book", 2019)
"A project is usually considered a failure if it is late, is over budget, or does not meet the customer’s expectations. Without the control that project management provides, a project is more likely to have problems with one of these areas. A problem with only one constraint (scope, schedule, cost, resources, quality, and risk) can jeopardize the entire project." (Sandra F Rowe, "Project Management for Small Projects" 3rd Ed., 2020)
No comments:
Post a Comment