A Software Engineer and data professional's blog on SQL, data, databases, data architectures, data management, programming, Software Engineering, Project Management, ERP implementation and other IT related topics.
Pages
- 🏠Home
- 🗃️Posts
- 🗃️Definitions
- 🏭Fabric
- ⚡Power BI
- 🔢SQL Server
- 📚Data
- 📚Engineering
- 📚Management
- 📚SQL Server
- 📚Systems Thinking
- ✂...Quotes
- 🧾D365: GL
- 💸D365: AP
- 💰D365: AR
- 👥D365: HR
- ⛓️D365: SCM
- 🔤Acronyms
- 🪢Experts
- 🗃️Quotes
- 🔠Dataviz
- 🔠D365
- 🔠Fabric
- 🔠Engineering
- 🔠Management
- 🔡Glossary
- 🌐Resources
- 🏺Dataviz
- 🗺️Social
- 📅Events
- ℹ️ About
25 December 2012
🚧Project Management: Project Management (Just the Quotes)
🚧Project Management: Project Failure (Just the Quotes)
(Lao Tzu, "Tao Te Ching", cca. 6th-century BC)
"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)
"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."
"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)
"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)
"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."
19 December 2012
🚧Project Management: Quality (Just the Quotes)
"Managers jeopardize product quality by setting unreachable deadlines. They don’t think about their action in such terms; they think rather that what they’re doing is throwing down an interesting challenge to their workers, something to help them strive for excellence."
"People under time pressure don’t work better - they just work faster. In order to work faster, they may have to sacrifice the quality of the product and of their own work experience."
"The [software] builders’ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the quality of the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past. This is invariably a higher standard than what the market requires and is willing to pay for." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)
"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)
"Issues of quality, timeliness and change are the conditions that are forcing us to face up to the issues of enterprise architecture. The precedent of all the older disciplines known today establishes the concept of architecture as central to the ability to produce quality and timely results and to manage change in complex products. Architecture is the cornerstone for containing enterprise frustration and leveraging technology innovations to fulfill the expectations of a viable and dynamic Information Age enterprise." (John Zachman, "Enterprise Architecture: The Issue of The Century", 1997)
"The aim of leadership should be to improve the performance of man and machine, to improve quality, to increase output, and simultaneously to bring pride of workmanship to people. Put in a negative way, the aim of leadership is not merely to find and record failures of men, but to remove the causes of failure: to help people to do a better job with less effort." (W Edwards Deming, "Out of the Crisis", 2000)
18 December 2012
🚧Project Management: Estimation (Just the Quotes)
"Be sure you understand whether you're presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment."
"Don't expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can't accurately estimate an out-of-control process."
"Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates."
"Not all estimation methods are equal. When looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results."
"The primary purpose of software estimation is not to predict
a project's outcome; it is to determine whether a project's targets are
realistic enough to allow the project to be controlled to meet them." (Steve
McConnell, "Software Estimation: Demystifying the Black Art", 2006)
"Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses."
10 December 2012
🚧Project Management: Control (Just the Quotes)
"Project management is needed only for situations which are out of the ordinary; but when the need exists, this may often be the only way by which the task may be handled successfully. These situations require a different attitude on the part of the top management, the undivided attention of a project manager and different methods for control and communications than those used in the normal routine business situation. […] Pure project management assigns complete responsibility for the task and resources needed for its accomplishment to one project manager. The organization of a large project, though it will be dissolved upon completion of the task, operates for its duration much like a regular division and is relatively independent of any other division or staff group." (Executive Sciences Institute, Operations Research/Management Science Vol 6, 1964)
"Probably the most neglected area in systems analysis involves the planning and control of the project, especially those projects requiring automation. More than one disastrous project has been launched by 'computer people' who communicated their aims to the vexed manager using technical data processing jargon in lieu of specific lists of easily understood tasks, schedules, and costs. This problem applies equally to in-house projects or those requiring the services of outside consultants. Each project must first be planned in detail. Control is involved with comparing actual progress with the plan and taking corrective action when the two do not correspond. Without the plan, true control is not possible; the need for corrective action, its nature, extent, and urgency cannot be accurately determined." (Robert D Carlsen & James A Lewis, "The Systems Analysis Workbook: A complete guide to project implementation and control", 1973)
"Project management is the process by which it is assured that the objective is achieved and resources are not wasted. Planning is one of the two parts of project management. Control is the other." (Robert D Carlsen & James A Lewis, "The Systems Analysis Workbook: A complete guide to project implementation and control", 1973)
"Project management is the planning, organizing, directing, and controlling of company resources for a relatively short-term objective that has been established to complete specific goals and objectives. Furthermore, project management utilises the systems approach to management by having functional personnel (the vertical hierarchy) assigned to a specific project (the horizontal hierarchy)." (Harold Kerzner, "Project Management for Executives", 1982)
"Control cannot be achieved through micromanaging." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"Control is exercised by comparing progress against planned performance, and taking steps to correct for any deviations from the proper course." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"If you have no plan, you cannot have control, by definition, because it is your plan that tells where you are supposed to be in the first place. Further, if you don’t know where you are, you can’t have control. This comes from your information system. Most organizations have difficulties with both of these." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"In any system of humans or machines, the element in the system that has the greatest variability in its behavior will control the system." (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)
"Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates."
"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)
"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)
03 December 2012
🚧Project Management: Project Management (Just the Quips)
About Me
- Adrian
- Koeln, NRW, Germany
- IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.