Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
I have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public.
I find it difficult to release books in progress. The in-progress part challenges my perfection rules. I also know that some of you who want this book will wait until it’s done, or worse, available in paper.
However, since this is an agile and lean book, it seems nuts to not release it, even though it is not quite done.
If you get the book, please send me comments about what confused you, what you thought was crazy, and anything else.
Thanks so much!
Thanks to all my neighbors, friends, and colleagues for their service.
It's been popular recently in some agile circles to mention¬†we use the 5 whys¬†when asking about dysfunction. This common and misguided approach assumes - wrongly - causal relationship are linear and problems come from a single source. For example
Estimates are the smell of dysfunction. Let's ask the 5 Whys to reveal these dysfunctions
The natural tendency to assume that in asking¬†5 whys there is a connection from beginning to end for the thread connecting cause and effect. This single source of the problem - the symptom - is labeled the Root Cause. The question is¬†is the root cause that actual root cause. The core problem is the¬†5 whys¬†is not really seeking a solution but just eliciting more symptoms masked as causes.
A simple example illustrates the problem from¬†Apollo Root Cause Analysis.
Say we're in the fire prevention business. If preventing fires is our goal, let's look for the causes of the fire and determine the correction actions needed to actual prevent fire from occuring. In this example let's says we've identified 3 potential causes of fire. There is ...
So what is the root cause of the fire? To prevent the fire - and in the follow on example prevent a dysfunction - we must find at least one¬†cause of the fire that can be acted on to meet the goals and objectives of preventing the fire AND are within our control.
If we decide to control of combustable materials then the root cause is the combustibles. Same for the oxygen. This can be done by inerting a confined space, say with nitrogen. Same for the ignition sources. This traditional Root Cause Analysis pursues a preventative solution that is within our control and meets the goals and objectives - prevent fire. But this is not actually the pursuit of the Root Cause. By pursuing this approach, we stop on a single cause that may or may not result in the best solution. We're mislead into a categorical thinking¬†process that looks for solutions. This doesn't means there is no root cause. It means we can't that a root cause cannot be labels until we have decided on which solutions we are able to implement. The root cause is actually secondary to and contingent on the solution, not the inverse. Only after solutions have been established can we identify the actual root cause of the fire not be prevented.
The notion that Estimates are the¬†smell of dysfunction in a software development organization and asking the 5 Whys in search for the Root Cause is equally flawed.¬†
The need to estimate or not estimate has not been established. It is presumed that it is the estimating process that creates the dysfunction, and then the search - through the 5 Whys - is the false attempt to categorize the root causes of this dysfunction. The supposed dysfunction is them reverse engineered to be connected to the estimating process. This is not only a na√Įve approch to solving the dysfunction is inverts the logic by ignoring the need to estimate. Without confirmation that estimates are needed ot not needed, the search for the cause of the dysfunction has no purposeful outcome.¬†
The decision that estimates are needed or not need does not belong to those being asked to produce the estimates. That decision belongs to those consuming the estimate information in the decision making process of the business - those whose money is being spent.
And of course those consuming the estimates need to confirm they are operating their decision making processes in some framework that requires estimates. It could very well be those providing the money to be spent by those providing the value don't actual need an estimate. The value at risk¬†may be low enough - 100 hours of development for a DB upgrade. But when the¬†value at risk is sufficiently large - and that determination of done again by those providing the money, then a legitimate need to know how much, when, and what is made by the business¬†In this case, decisions are based on Microeconomics of opportunity cost for uncertain outcomes in the future.
This is the basis of estimating and the determination of the real root causes of the problems with estimates. Saying¬†we're bad at estimating is NOT the root cause. And it is never the reason not to estimate. If we are bad at estimating, and if we do have confirmation and optimism biases, then fix them. Remove the impediments to produce credible estimates. Because those estimates are needed to make decisions in any non-trivial value at risk work.¬†
¬†Related articles Let's Get The Dirt On Root Cause Analysis Essential Reading List for Managing Other People's Money The Fallacy of the Planning Fallacy Mr. Franklin's Advice
The book¬†Software for Your Head¬†was a seminal work when we were setting up our Program Management Office in 2002 for a mega-project to remove nuclear waste from a very contaminated site in Golden Colorado.
Here's an adaptation of those ideas to the specifics of our domain and problems
Software for your mind from Glen Alleman This approach was a subset of a much larger approach to managing in the presence of uncertainty, very high risk, and even higher rewards, all on a deadline, and fixed budget.¬† As was stated in the Plan of the Week.
Do this every week, guided by the 3 year master plan and make sure no one is injured or killed.
That project is documented in the book¬†Making the Impossible Possible summarized here.
Making the impossible possible from Glen Alleman Related articles The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future There is No Such Thing as Free
We've been doing this for 20 years and therefore you can as well
Is a common phrase used when asked¬†in what domain does you approach work? Of course without a test of that idea outside the domain in which the anecdotal example is used, it's going to be hard to know if that idea is actually credible beyond those examples.
So if we hear¬†we've been successful in our domain doing¬†something¬†or better yet NOT doing something, like say NOT estimating, ask in what domain have you been successful? Then the critical question, is there any evidence that the success in that domain is transferable to another domain? This briefing provides a framework - from my domain of aircraft development - illustrating that domains vary widely in their needs, constraints, governance processes and applicable and effective approaches to delivering value.
Paradigm of agile project management from Glen Alleman Google seems to have forgotten how to advance the slides on the Mac. So click on the presentation title (paradigm of agile PM) ¬†to do that. Safari works. Related articles The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future There is No Such Thing as Free Root Cause Analysis Domain is King, No Domain Defined, No Way To Test Your Idea Mr. Franklin's Advice
I've posted this week's lecture in my Understanding Software Projects series at https://cxlearn.com. Most of the lectures that have been posted are still free. Lectures posted so far include:
0.0 Understanding Sofware Projects - Intro
0.1 Introduction - My Background
0.2 Reading the News
1.0 The Software Lifecycle Model - Intro
1.1 Variations in Iteration (New this week)
1.2 Lifecycle Model - Defect Removal
2.0 Software Size
Check out the lectures at http://cxlearn.com!
Geoff Watts is one of the leading Scrum thinkers in the world, and one of the few to hold both the Certified Scrum Trainer and Certified Scrum Coach designation. In addition to his book, "Scrum Mastery: From, From Good To Great Servant-Leadership" Geoff has written a new book, "The Coach's Casebook". His new book is not specifically about Scrum or agile, but since a great deal of a ScrumMaster's job is indeed coaching a team to better performance, I think you'll find the book applicable to your work. In the following guest post, Geoff shares with a story about a feeling I think we can all relate to. I know I've felt the way he describes many times. --Mike Cohn
"One of these days, I'm going to be found out. They will realise I have no idea what I'm talking about and I'll be fired."
I remember standing in my kitchen 15 years ago saying these words to my wife. We were thinking about buying something for the house and I was worried that my position as a project manager wasn't secure enough for us to make the purchase. I was worried because I was not a technical person, yet I was project managing a technical project full of technical people.
I didn't understand databases or SQL or Java; I didn't even know how a phone worked yet, and I was working for a telecom company! How could I possibly manage a project in this context with so little domain or technical knowledge?!
I was bluffing as best I could, but I thought that one day they would realise I didn't know what I was talking about.
What I didn't realise at the time was that I didn't need to know that stuff because the people that mattered did. In fact, I believe that if I had known that stuff, then I would have been much less successful in my job.
You see, the development team knew about databases and Java and SQL, and the customer knew how phones worked. If I wanted to run the project, I mean really micromanage it, then I would have needed to know all that stuff. But that wasn't my goal.
My goal was to enable the people around me to be able to do what they needed to do, to apply their knowledge, intelligence and experience to making the project and product work. Being an impostor actually helped me avoid being a micromanager.
What I needed to know and learn was how to enable those people. And then I needed to learn to be comfortable with being an impostor.
“Impostor syndrome” is an actual phenomenon – yes, it is widespread enough to have a name – and you may be suffering from Impostor syndrome if you believe:
Ever felt like that? It's completely normal. In fact, it would be abnormal if you haven't felt like that because it is believed that up to 70 percent of people have. This certainly matches my personal empirical evidence.
ScrumMasters are perhaps more prone to feelings of Impostor syndrome than anyone else in an agile team or organisation. This is partly because of the lack of authority inherent in the role. They have no power, and so often find themselves doubting themselves and their position.
Their role is also quite loosely defined in terms of their responsibilities and that increases the lack of clarity and confidence that ScrumMasters can have.
Impostor syndrome, like all of the traits that come up in my coaching practice, is not a bad thing. People with Impostor syndrome are generally quite humble, reflective and diligent.
They are constantly trying hard to prove themselves worthy (to themselves and others) and rarely settle for mediocrity because of their anxiety about being found out. As a result, people with a high degree of Impostor syndrome are often high achievers.
It's not therefore a trait to try and get rid of altogether, but rather, it's important to bring it into balance. Harness the positive aspects while trying to mitigate the anxiety and stress that can come from this trait when overdone.
The first step in bringing Impostor syndrome into balance is normalisation – accepting that this is common. Then, consciously appreciating your strengths and bringing others down from the often-overinflated pedestal that you have put them on, because in all likelihood, they are “faking it” just as much as you are!
Bringing this trait into balance for yourself in your role as ScrumMaster may also help you coach others on their Impostor syndrome as well.
There are some great techniques for dealing with this and other traits that can trap us in my new book, “The Coach's Casebook” available now from Amazon here.
Some people noticed that my avatar pictures on the social networks were deviating from the real-life version at a slow but steady pace.
Yes, I’m getting older!
Thanks for pointing it out.
Education is not the learning of facts, but the training of the mind to think - Albert¬†Einstein¬†
So if we're going to learn how to think¬†about managing the spending of other peoples money in the presence of uncertainty, we need some basis of education.¬†
Uncertainty is a fundamental and unavoidable feature of daily life. Personal life and the life of projects. To deal with this uncertainty intelligently we represent and reason about these uncertainties. There are formal ways of reasoning (logical systems for reasoning found in the Formal Logic and Artificial Intelligence domain) and informal ways of reasons (based on probability and statistics of cost, schedule, and technical performance in the Systems Engineering domain).
If Twitter, LinkedIn, and other forum conversations have taught me anything, it's that many participants base their discussion on personal experience and opinion. Experience informs opinion. That experience may be based on¬†gut feel learned from the ¬†school of hard knocks.¬†But there are other ways to learn as well. Ways to guide your experience and inform your option. Ways based on education and frameworks for thinking about solutions to complex problems.
Samuel Johnson has served me well with his quote...
There are two ways to knowledge,¬†We know a subject ourselves, or we know where we can find information upon it.
Hopefully the knowledge we know ourselves has some basis in fact, theory, and practice, vetted by someone outside ourselves, someone beyond our personal anecdotal experience
Here's my list of essential readings that form the basis of my understanding, opinion, principles, practices, and processes as they are applied in the domains I work - Enterprise IT, defense and space and their software intensive systems.
So In The End
This list is the tip of the iceberg for access to the knowledge needed to manage in the presence of uncertainty while spending other peoples money.Related articles Mr. Franklin's Advice Want To Learn How To Estimate? Two Books in the Spectrum of Software Development
My column is up on projectmanagement.com. It’s called Is Agile Working for Your Project?
I hope you enjoy it.
People from all over the world sign up to join the Happy Melly business network because–apparently–they think we’re doing a good job. That’s so awesome. It also increases the pressure on us to report on what we’re doing. And it makes me think harder: What can I do to help people enjoy their job?
Any process that does not have provisions for its own refinement will eventually fail or be abandoned
- W. R. Corcoran, PhD, P.E.,¬†The Phoenix¬†Handbook: The Ultimate Event¬†Evaluation¬†Manual for Finding Profit¬†Improvement in Adverse Events,¬†Nuclear Safety Review Concepts, 19 October 1997.
In the agile community it is popular to use the terms¬†complex, complexity, complicated¬†many times interchangeably and and many times wrongly. These terms are many times overloaded with an agenda used to push a process or even a method.
First some definitions
One more item we need is the types of Complexity
And Now To The Point
When we hear complex, complexity, complex systems, complex adaptive system, pause to ask what kind of¬†complex are you talking about. What¬†Type of complex system. In what system are you applying the term¬†complex. Have you classified that system in a way that actually matches a real system.
It is common use the terms complex, complicated, and complexity are interchanged. And software development is classified or mis-classified as one or the both or all three. It is also common to toss around these terms with not actual understanding of their meaning or application.
We need to move beyond buzz words. Words like¬†Systems Thinking.¬†Building software is part of a system. There are interacting parts that when assembled, produce an outcome. Hopefully a desired outcome. In the case of software the interacting parts are more than just the parts. Software has emergent properties. A Type 4 system, built from Type 1, 2, and 3 systems. With changes in time and uncertainty, modeling these systems requires stochastic processes. These processes depend on estimating behaviors as a starting point.¬†
The understanding that software development is an uncertain process (stochastic) is well known, starting in the 1980's  with COCOMO. Later models, like¬†Cone of Uncertainty made it clear that these uncertainties, themselves, evolve with time. The current predictive models based on stochastic processes include Monte Carlo Simulation of networks of activities, Real Options, and Bayesian Networks. Each is directly applicable to modeling software development projects.
 Software Engineering Economics, Barry Boehm, Prentice-Hall, 1981.Related articles Decision Analysis and Software Project Management Making Decisions in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Approximating for Improved Understanding The Microeconomics of a Project Driven Organization How to Avoid the "Yesterday's Weather" Estimating Problem Hope is not a Strategy
Project work is random. Most everything in the world ¬†is random. The weather, commuter traffic, productivity of writing and testing code. Few things actually take as long as they are planned. Cost is less random, but there are variances in the cost of labor, the availability of labor. Mechanical devices have variances as well.
The exact fit of a water pump on a Toyota Camry is not the same for each pump. There is a tolerance in the mounting holes, the volume of water pumped. This is a variance in the technical performance.
Managing in the presence of these uncertainties is part of good project management. But there are two distinct paradigms of managing in the presence of these uncertainties.
In the first case we have empirical data. In he second case we don't. There are two approaches to modeling what the system will do in terms of cost and schedule outcomes.
Bootstrapping the Empirical Data
With samples of past performance and the proper statistical assessment of those samples, we can¬†re-sample them to produce a model of future performance. This bootstrap resampling shares the principle of the second method - Monte Carlo Simulation - but with several important differences.
This¬†bootstrapping method is quick, easy, and produces a quick and easy result. But it has issues that must be acknowledged.
Monte Carlo Simulation
This approach is more general and removes many of the restriction to the statistical confidence of¬†bootstrapping.
Just as a reminder, in principle both the parametric and the non-parametric bootstrap are special cases of Monte Carlo simulations used for a very specific purpose: estimate some characteristics of the sampling distribution. But like all principles, in practice there are larger differences when modeling project behaviors.
In the more general approach ¬†of Monte Carlo Simulation the algorithm repeatedly creating random data in some way, performing some modeling with that random data, and collecting some result.
In practice when we hear Monte Carlo simulation we are talking about a theoretical investigation, e.g. creating random data with no empirical content - or from reference classes - ¬†used to investigate whether an estimator can represent known characteristics of this random data, while the (parametric) bootstrap refers to an empirical estimation and is not necessary a model of the underlying processes, just a small sample of observations independent from the actual processes that generated that data.
The key advantage of MCS is we don't necessarily need ¬†past empirical data. MCS can be used to advantage if we do, but we don't need it for the Monte Carlo Simulation algorithm to work.
This approach could be used to estimate some outcome, like in the bootstrap, but also to theoretically investigate some general characteristic of an statistical estimator (cost, schedule, technical performance) which is difficult to derive from empirical data.
MCS removes the road block heard in many critiques of estimating -¬†we don't have any past data on¬†which¬†to¬†estimate. ¬†No problem, build a model of the work, the dependencies between that work, and assign statistical parameters to the individual or collected PDFs and run the MCS to see what comes out.
This approach has several critical advantages:
So Here's the Killer Difference
Bootstrapping models make several key assumptions, which may not be true in general. So they must be tested before accepting any of the outcomes.
Monte Carlo Simulation models provide key value that bootstrapping can't.
The critical difference between Bootstrapping and Monte Carlo Simulation is MCS can show what the future performance has to be to stay on schedule (within variance), on cost, and have the technical performance meet the needs of the stakeholder.
Bootstrapping can only show what the future will be like if it like the past, not what it must be like. In Bootstrapping this future MUST be like the past. In MCS we can tune the PDFs to show what performance has to be to manage to that plan. Bootstrapping is reporting¬†yesterday's weather as tomorrow's weather - just like Steve Martin in LA Story. If tomorrow's weather turns out not to be like yesterday's weather, you gonna get wet.
MCS can forecast tomorrows weather, by assigning PDFs to future activities that are different than past activities, then we can make any needed changes in that future model to¬†alter the weather to meet or needs. This is in fact how weather forecasts are made - with much more sophisticated models of course here at the National Center for Atmospheric Research in Boulder, CO
This forecasting (estimating the future state) of¬†possible outcomes and the alternation of those outcomes through management actions to change dependencies, add or remove resources, provide alternatives to the plan (on ramps and off maps of technology for example), buy down risk, apply management reserve, assess impacts of rescoping the project, etc. etc. etc. ¬†is what project management is all about.
Bootstrapping is necessary but far from sufficient for any non-trivial project to show up on of before the need date (with schedule reserve), at o below the budgeted cost (with cost reserve) and have the produce or service provide the needed capabilities (technical performance reserve).
Here's an example of that probabilistic forecast of project performance from a MCS (Risky Project). This picture shows the probability for cost, finish date, and duration. But it is built on time evolving PDFs assigned to each activity in a network of dependent tasks, which models the work stream needed to complete as planned.
When that future work stream is changed to meet new requirements, unfavorable past performance and the needed corrective actions, or changes in any or all of the underlying random variables, the MCS can show us the expected impact on key parameters of the project so management in intervention can take place - since Project Management is a verb.
The connection between the Bootstrap and Monte Carlo simulation of a statistic is simple.
Both are based on repetitive sampling and then direct examination of the results.
But there are significant differences between the methods (hence the difference in names and algorithms). Bootstrapping uses the original, initial sample as the population from which to resample. Monte Carlo Simulation uses a data generation process, with known values of the parameters of the Probability Distribution Function. The common algorithm for MCS is Lurie-Goldberg.¬†Monte Carlo is used to test that the results of the estimators produce desired outcomes on the project. And if not, allow the modeler and her management to change those estimators and then mange to the changed plan.
Bootstrap can be used to estimate the variability of a statistic and the shape of its sampling distribution from past data. Assuming the future is like the past, make forecasts of throughput, completion and other project variables.¬†
In the end the primary differences (and again the reason for the name differences) is Bootstrapping is based on unknown distributions. Sampling and assessing the shape of the distribution in Bootstrapping adds no value to the outcomes. Monte Carlo is based on known or defined distributions usually from Reference Classes.Related articles Do The Math Complex, Complexity, Complicated The Fallacy of the Planning Fallacy
When we hear words about any topic, my favorite of course is¬†all things project manage, it doesn't make them true.
So when we hear some phrase, idea, or conjecture - ask for evidence. Ask for domain. Ask for examples. If you hear¬†we're just exploring ask who's paying for that? Because it is likely those words are unsubstantiated conjecture from personal experience and not likely very useful outside that personal experienceRelated articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future Want To Learn How To Estimate? There is No Such Thing as Free Estimates
Two new lectures have been posted in my Understanding Software Projects lecture series at http://cxlearn.com. All the lectures that have been posted are still free (though this won't last forever). Lectures posted so far include:
0.0 Understanding Sofware Projects - Intro
0.1 Introduction - My Background (new this week)
0.2 Reading the News
1.0 The Software Lifecycle Model - Intro
1.1 Lifecycle Model - Defect Removal (new this week)
2.0 Software Size
Check out the lectures at http://cxlearn.com!
The Planning Fallacy is well documented in many domains. Bent¬†Flyvbjerg has documented this issue in one of his books, Mega Projects and Risk. But the Planning Fallacy is more complex than just the optimism bias. Many of the root causes for cost overruns are based in the¬†politics of large projects.
The ¬†planning fallacy is ...
...a phenomenon in which predictions about how much time will be needed to complete a future task display an optimistic bias (underestimate the time needed). This phenomenon occurs regardless of the individual's knowledge that past tasks of a similar nature have taken longer to complete than generally planned.¬†The bias only affects predictions about one's own tasks; when outside observers predict task completion times, they show a pessimistic bias, overestimating the time needed.¬†The planning fallacy requires that predictions of current tasks' completion times are more optimistic than the beliefs about past completion times for similar projects and that predictions of the current tasks' completion times are more optimistic than the actual time needed to complete the tasks.
The critical notion here is about¬†ones own estimates. This is the critical reasons for¬†
With all that said, there still is a large body of evidence that estimating is still a major problem.‚Ä†¬†
I have a colleague who is the former Cost Analysis Director of NASA. He has three reasons projects get in cost, schedule, and technical trouble:
The Planning Fallacy
Daniel Kahneman (Princeton) and Amos Tversky¬†(Stanford) describe it as ‚Äúthe tendency to underestimate the time, costs, and risks of future actions and overestimate the benefit of those actions‚ÄĚ.¬† The results are time and cost overruns as well as benefit shortfalls.¬† The concept is not new: they coined the term in the 1970s and much research has taken place since, see the Resources below.
So the challenge is to not fall victim to this optimism bias and become a statistic in the Planning Fallacy.
How do we do that?
Here's our experience:
So With These And Others...We can remove the fallacy of the Planning Fallacy.
This doesn't mean our project will be successful. Nothing can guarantee that. But the Probability of Success will be increased.
In the end we MUST know the Mission we are trying to accomplish, the units of measure of that Mission in terms meaningful to the decision makers. Without that we can't now what DONE looks like. Amnd with that only our optimism will carry us along until it is too late to turn back.
Anyone using Planning Fallacy as the excuse for project failure, not planning, not estimating, not actually doing their job as a project and business manager will likely succeed in the quest for project failure and get ¬†what they deserve. Late, Over Budget, and the gadget they're building doesn't work as needed.
‚Ä† Please note, that just because estimating is a problem in all domains, that's NO reason to not estimate. Like planning is a problem, it's no reason NOT to plan. Any suggestion that estimating or planning is not needed in the presence of uncertain future - as it is on all projects - is willfully ignoring the principles of Microeconomics - making choices in the presence of uncertainty based on opportunity cost . To suggest other wise confirms this ignorance.
These are some background on the Planning Fallacy problem from the anchoring and adjustment point of view that I've used over the years to inform our estimating processes for software intensive systems. After reading through these I hope you come to a better understanding of many of the mis-conceptions about estimate and the fallacies of how that is done in practice.
Interestingly there is a poster on twitter in the #NoEstimates thread that objects when people post links to their own work or work of others. Please do not fall prey to the notion that everyone has an equally informed opinion, unless you yourself have done all the research needed to cover the foundations of the topics. Outside resource are the very life blood of informed experience and the opinions that come from that experience.¬†
Anchoring unbound,¬†Nicholas Epley and Thomas Gilovich¬†
On the Reality of Cognitive Illusions,¬†Daniel Kahneman,¬†Princeton University,¬†Amos Tversky,¬†Stanford University.
The framing effect and risky decisions:¬†Examining cognitive functions with fMRI,¬†Cleotilde Gonzalez, Jason Dana, Hideya Koshino, and ,Marcel Just, The Journal of Economic Psychology, 26 (2005), 1-20.
¬†Discussion Note: Review of Tversky & Kahnemann (1974): Judgment under uncertainty: heuristics and biases,¬†Micheal Axelsen¬†UQ Business School¬†The University of Queensland¬†Brisbane, Australia
The Anchoring-and-Adjustment¬†Heuristic,¬†Why the Adjustments Are Insufficient,¬†Nicholas Epley and Thomas Gilovich.
¬†Judgment under Uncertainty: Heuristics and Biases,¬†Amos Tversky; Daniel Kahneman,¬†Science, New Series, Vol. 185, No. 4157. (Sep. 27, 1974), pp. 1124-1131
This should be enough to get you started and set the stage for rejecting any half baked ideas about anchoring and adjustment, planning fallacies, no need to estimate and the collection of other cocka mammy ideas floating around the web on how to make credible decisions with other peoples money.Related articles The Reason We Plan, Schedule, Measure, and Correct Herding Cats: Five Estimating Pathologies and Their Corrective Actions Tunnel to Nowhere Root Cause Analysis The Flaw of Empirical Data Used to Make Decisions About the Future