"Planning starts usually with something like a general idea. For one reason or another it seems desirable to reach a certain objective, and how to reach it is frequently not too clear. The first step then is to examine the idea carefully in the light of the means available. Frequently more fact-finding about the situation is required. If this first period of planning is successful, two items emerge: namely, an 'over-all plan' of how to reach the objective and secondly, a decision in regard to the first step of action. Usually this planning has also somewhat modified the original idea. The next period is devoted to executing the first step of the original plan." (Kurt Lewin, "Action research and minority problems", 1946)
"Every company has beloved projects on which if prices had held up, if the contractors had finished on time (or finished at all), if the plans hadn't been altered, if the thing had actually worked, the planned return would have been earned. But since some or all of these calamities [things that don't go as expected] usually happen, any manager who neglects to allow for them is not planning - merely thinking wishfully. Desire for the project has, as usual, overtaken desire for profit." (Ernest Dale, "Planning and developing the company organization structure", 1952)
"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. [...] 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 he accurately determined." (Robert D Carlsen & James A Lewis, "The Systems Analysis Workbook: A complete guide to project implementation and control", 1973)
"Since software construction is inherently a systems effort - an exercise in complex interrelationships - communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning [increasing the workers]. Adding more people then lengthens, not shortens, the schedule." (Frederick Brook, "The Mythical Man-Month", 1975)
"Because one has to be an optimist to begin an ambitious project, it is not surprising that underestimation of completion time is the norm." (Fernando J Corbató, "On Building Systems That Will Fail", 1991)
"If we decide to plan not to lose, we take a defensive posture in which we expend huge amounts of effort trying to prevent and track errors. This will lead us to a very heavyweight planning process in which we try to plan everything up front in a much detail as possible. Such a process will have many review steps, sign-offs, authorizations, and phase gates. Such a planning process is highly adept at making sure that blame can be assigned when something fails; but takes no direct steps towards making sure that the right system is delivered at a reasonable cost." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"One of the purposes of planning is we always want to work on the most valuable thing possible at any given time. We can’t pick features at random and expect them to be most valuable. We have to begin development by taking a quick look at everything that might be valuable, putting all our cards on the table. At the beginning of each iteration the business (remember the balance of power) will pick the most valuable features for the next iteration." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time software gets there, the customers don’t want what was planned, they want something different." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"Projects sometimes fail long before they deliver anything. At some point they may be determined to be too expensive to continue. Or perhaps they took too long to develop and the business need evaporated. Or perhaps the requirements change so often that the developers can never finish one thing without having to stop and start all over on something new. Certainly these are planning failures." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"There are two ways to approach prevention of these planning failures. We can plan not to lose, or we can plan to win. The two are not identical. Planning not to lose is defensive; while planning to win is aggressive. [...] the problem that planning is supposed to solve is simply, to build the right system at the right cost. If we take a defensive posture by planning not to lose, we will be able to hold people accountable for any failures; but at an enormous cost. If we take an aggressive posture and plan to win, we will be unafraid to make errors, and will continuously correct them to meet our goals." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"We plan because: We need to ensure that we are always working on the most important thing we need to do. We need to coordinate with other people. When unexpected events occur we need to understand the consequences for the first two." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"When we plan to win we take direct steps to ensure that we are building the right system at the best possible cost. Every action we take goes towards that end. Instead of trying to plan everything up front, we plan just the next few steps; and then allow customer feedback to correct our trajectory. In this way, we get off the mark quickly, and then continuously correct our direction. Errors are unimportant because they will be corrected quickly." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"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)
"No project can succeed when the team members have no commitment to the plan, so the first rule of project planning is that the people who must do the work should help plan that part of the project. You will not only gain their commitment to the plan, but also most likely cover all of the important issues that you may individually have forgotten."(James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"The big fallacy in our assumptions is that the world will stand still while we execute our project plan." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)
"Project planning is the key to effective project management. Detailed and accurate planning of a project produces the managerial information that is the basis of project justification (costs, benefits, strategic impact, etc.) and the defining of the business drivers (scope, objectives) that form the context for the technical solution. In addition, project planning also produces the project schedules and resource allocations that are the framework for the other project management processes: tracking, reporting, and review." (Rob Thomsett, "Radical Project Management", 2002)
"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."
"The pathology of setting a deadline to the earliest
articulable date essentially guarantees that the schedule will be missed." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)
"Ending up somewhere entirely different from where you expected to go is the norm in this world. Software projects are prime illustrations of the law of unintended consequences, and their innovations and breakthroughs are more often side effects than planned outcomes." (Scott Rosenberg, "Dreaming in Code", 2007)
"[…] in software development, as in all things, plans get dodgier the farther into the future one looks. Any developer who has been around the block will admit that the cavalcade of methodologies over three decades of software history has left the field richer and given programmers useful new tools and ways of thinking about their work. But finding a developer or team that actually subscribes to a particular methodology isn’t easy." (Scott Rosenberg, "Dreaming in Code", 2007)
"The picture of digital progress that so many ardent boosters paint ignores the painful record of actual programmers’ epic struggles to bend brittle code into functional shape. That record is of one disaster after another, marking the field’s historical time line like craters. Anyone contemplating the start of a big software development project today has to contend with this unfathomably discouraging burden of experience. It mocks any newcomer with ambitious plans, as if to say, What makes you think you’re any different?" (Scott Rosenberg, "Dreaming in Code", 2007)
"Users may be annoyed by bugs, and software developers may be disappointed by their inability to perfect their work, and managers may be frustrated by the unreliability of their plans. But in the end, none of that matters as much as the simple fact that software does not work the way we think, and until it does, it is not worth trying to perfect." (Scott Rosenberg, "Dreaming in Code", 2007)
"And even if we make good plans based on the best information available at the time and people do exactly what we plan, the effects of our actions may not be the ones we wanted because the environment is nonlinear and hence is fundamentally unpredictable. As time passes the situation will change, chance events will occur, other agents such as customers or competitors will take actions of their own, and we will find that what we do is only one factor among several which create a new situation." (Stephen Bungay, "The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results", 2010)
"A project plan is a prediction. It predicts that a team of N people will complete X amount of work by Y date." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)
"Development is a design process. Design processes are generally evaluated by the value they deliver rather than a conformance to plan. Therefore, it makes sense to move away from plan-driven projects and toward value-driven projects. […] The realization that the source code is part of the design, not the product, fundamentally rewires our understanding of software." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)
"The planning fallacy is the systematic tendency for project plans and budgets to undershoot. […] The reasons for the planning fallacy are partly psychological, partly cultural, and partly to do with our limited ability to think probabilistically." (Paul Gibbons, "The Science of Successful Organizational Change", 2015)
"An effort estimate is not complete without including its assumptions. Estimate assumptions include any and all underlying factors the estimate relies upon. Assumptions are especially important in more rigid estimation environments, but they are a good practice even where expectations are more flexible. Explicitly listing all assumptions helps to remove ambiguity and avoid misunderstandings during project delivery." (Morgan Evans, "Engineering Manager's Handbook", 2023)
"Plans allow us to think through objectives beforehand in the hope of being prepared for delivery. Plans are useful when they preempt conflict, direct efforts in harmony, and align expectations. Plans are not useful when they waste valuable build time or provide a false sense of security, for example, by missing unknown unknowns." (Morgan Evans, "Engineering Manager's Handbook", 2023)
No comments:
Post a Comment