Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/sources/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

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!

Herding Cats - Glen Alleman
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.
Syndicate content
Performance-Based Project Management® Principles, Practices, and Processes to Increase Probability of Success
Updated: 2 hours 35 min ago

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Wed, 04/27/2016 - 04:55

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (not de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considered those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz word without knowing what they actually mean.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made with estimates,” and continue on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money
2. Unrealistic cost and schedule estimates – the source of poor estimating
3. Inadequate assessment of unmitigated risk exposure
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Tue, 04/26/2016 - 21:50

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considered those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz word without knowing what they actually mean.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made with estimates,” and continue on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money
2. Unrealistic cost and schedule estimates – the source of poor estimating
3. Inadequate assessment of unmitigated risk exposure
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

Quote of the Day

Tue, 04/26/2016 - 05:33

For the great enemy of truth is very often not the lie ― deliberate, contrived, and dishonest ― but the myth ― persistent, persuasive, and unrealistic. Too often we hold fast to the clichés of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought. ― John F. Kennedy

Take care when you hear any opinion not based on principles, for you are succumbing to those opinions produced by personal anecdotes - untested outside that personal experience - are the basis of myth. When those making those untested personal anecdotal conjectures vigorously criticize those asking for evidence, be more careful. For the smell comes from the propagation of the myth not the facts. 

Related articles Good Project and Bad Project How We Make Decisions is as Important as What We Decide. The Cognitive Illusion of Bad Software Project Outcomes Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Governance and Estimating

Mon, 04/25/2016 - 14:18

If your business is not subject to any external governance process, you’re free to spend your money as you please. But you’re not free to suggest your approach is applicable to those who are governed by external frameworks of spending and accountability for that spend, without a testable confirmation this idea doesn’t violate those governance principles.

Governance includes: Responsibility for a specific duty, task, or decision. Authority to influence behaviours. Communication of decisions. Empowerment to give individual's authority to act.

The governing of IT systems has two distinct components.

  1. A structural component that pertains to the organisation’s information technology activities, the way those activities support the goals of the business, and the people who help manage those activities.
  2. A process component that defines the decision-making rights associated with IT as well as the mechanisms and policies used to measure and control the way IT decisions are made and carried out within the organisation.

All businesses that operate inside governance frameworks, which address:

  • Risk, Conformance and Compliance - COSO, CoBit, ISO 27001, ISO 38500
  • Development Change control - ISO 12207, CMMI, CoBit, OPM3, Prince2
  • Information & Technology Balance Sheet - Balanced Scorecard, Zachman 
  • Operations - ITIL, ITPO, PCI DSS, BCM/BS25000, ISO 20000, TCO/ROI, ISO 27001, CoBit
  • Business Strategy - Balanced Scorecard

make use of estimates in their decision support processes. To suggest Not Estimating can be the basis of those decision making process is to willfully ignore these principles.

If it’s not your money, you don’t get to do as you please. If it’s your money, do as you please no one really cares. If it’s your customer’s money, confirm with them how they expect you to behave when spending that money.

Categories: Project Management

30 Problems That Affect Software Projects

Mon, 04/18/2016 - 15:10

From Estimating Software Costs: Bringing Realism To Estimating, 2nd Edition.

  1. Initial requirements are seldom more than 50 percent complete
  2. Requirements grow at about 2 percent per calendar month during development
  3. About 20 percent of initial requirements are delayed until a second release
  4. Finding and fixing bugs is the most expensive software activity
  5. Creating paper documents is the second most expensive software activity
  6. Coding is the third most expensive software activity
  7. Meetings and discussion are the fourth most expensive activity
  8. Most forms of testing are less that 30 percent efficient in finding bugs
  9. Most forms of testing touch less than 50 percent of the code being tested
  10. There are more defects in requirements and design than in source code
  11. There are more defects in test cases than in the software itself
  12. Defects in requirements, design and code average 5.0 per function point
  13. Total defect-removal efficiency before release averages only about 80 percent
  14. About 15 percent of software defects are delivered to customers
  15. Delivered defects are expensive and cause customer dissatisfaction
  16. About 5 percent of modules in applications will contain 50 percent of all defects
  17. About 7 percent of all defect repairs will accidentally inject new defects
  18. Software reuse is the only effective for materials that approach zero defects
  19. About 5 percent of software outsource contracts end up in litigation
  20. About 35 percent of projects greater that 10,000 function points will be canceled
  21. About 50 percent of project greater than 110,000 function points will be one year late
  22. The failure mode for most cost estimates is to be excessively optimistic.
  23. Productivity rates in the U.S. are about 10 function points per staff month
  24. Assignment scopes for development are about 150 function points
  25. Assignment scopes for maintenance are about 750 function points
  26. Development costs about $1,200 per function point in the U.S.
  27. Maintenance costs about $150 per function point per calendar year
  28. After delivery applications grow at about 7 percent per calendar year during use
  29. Average defect repair rates are about ten bugs or defect per month
  30. Programmers need about ten days of annual training to stay current

Agile addresses 1, 2, 3, 4, 5, and 6 well. 

So if these are the causes of project difficulties - and there may be others since this publication, what are the fixes?

 

Categories: Project Management

What Is Management in the Context of Agile

Sun, 04/17/2016 - 23:07

There's a meme going around in some parts of agile that management is inhumane. This is an extreme view of course, likely informed by anecdotal experience with Bad Management, or worse lack of actual management experience.

Managing in the presence of Agile is not the same as managing in traditional domains. The platitude is Stewardship, but that has little actionable outcomes needed to move the work efforts along toward getting value delivered to customers in exchange for money and time.

One view of management in Agile can be informed by Governance of the work efforts. Here's a version of Governance, from "Agile Governance Theory: conceptual development,” Alexandre J. H. de O. Luna, Philippe Kruchten , and Hermano Moura.

Screen Shot 2016-04-17 at 4.03.36 PM

 

Related articles Agile Software Development in the DOD Deadlines Always Matter Risk Management is How Adults Manage Projects Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Before looking to any solution to a problem, determine the Root Cause

Thu, 04/14/2016 - 00:30

It is common to use the phrase 

If we feel pain X. Let's explore solutions? & possibly "Solutions A & B might be a starting point?"

This approach seeks a solution to the symptom not a solution to the problem

This is the false notion used by #NoEstimates advocates, with the conjecture that estimates are the smell of dysfunction. Without stating what the dysfunction is, then makes the statement that Not Estimating will fix it. So in the end nothing is fixed, the dysfunction is not identified, the Root Cause is not identified, and therefore is it not possible to claim Not Estimating will fix anything, for the simple fact that the problem has not been defined. It's a solution - at doubtful solution - looking for an undefined problem to solve. A lose-lose situation. 

So don't fall for the fallacy of the smell and most of all don't fall for the fallacy, we're just exploring and I have no recommended solutions.

The only way to provide an effective solution to any problem, is to determine the Root Cause to that problem and confirm that the proposed solution will in fact prevent the problem from recurring. If you want to learn how to do this - and not follow the naive 5 Whys - read this. Then if you're working in a domain that does Root Cause analysis buy the Reality Charting tool. It's saved us from catastrophe several times. 

Apollo

 

Related articles The Dysfunctional Approach to Using "5 Whys" Are Estimates Really The Smell of Dysfunction? Root Cause of Project Failure Turning Editorials into Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty The False Notion of "we haven't seen this before" When the Solution to Bad Management is a Bad Solution
Categories: Project Management

Project Breathalyzer

Wed, 04/13/2016 - 00:25

Screen Shot 2016-04-12 at 5.11.38 PM

The Project Breathalyzer provides question for the Program Manager to assess of the project is fit to be on the road. If the Program Manager cannot answer these questions about the current status, or answers in the negative , then the project is subject to a critical review.

This concept comes from the Software Program Managers Network, and the work of Norm Brown in 1997. The SPMN was a non profit organization, with funding canceled in 1002. but is now for Profit. The questions can from the Airlie Software Council of experts after the failure of the Airane 5 launch vehicle failure attributed to a Software Design Flaw.

 

 

Related articles Failure is not an Option Fit for Purpose, Fit for Use Assessing Value Produced By Investments
Categories: Project Management

Find the Root Cause Before Assuming Your Fix Can Actually Fix Anything

Sat, 04/09/2016 - 23:38

A burst of Tweets of No Estimates fixes these problems came across Twitter this morning. I won't repeat who they are attributed to, to protect the guilty. But here's a core concept that is totally missing from not only the No Estimates conjecture, but from most every discussion, where a solution is proposed before the problem has been defined. Let's start with Dean Gano's introduction to Apollo Root Cause Analysis, which is a George Bernard Shaw quote so fitting to the discussion of ignoring the root cause and going straight for a solution to the symptom - in many cases an Unnamed symptom.

Ignorance is a most wonderful thing.
It facilitates magic.
It allows the masses to be led.
It provides answers when there are none.
It allows happiness in the presence of danger.
All this while, the pursuit of knowledge can only destroy the illusion.
Is it any wonder mankind chooses ignorance?
~ George Bernard Shaw

So until the symptom is named - and the smell of dysfunction is not a symptom. Until the search for the root cause of the symptom, and applying the 5 whys to an unnamed symptom is applied properly, the root cause will be undetermined. Without discovering the root cause, there will be no chance that any suggested processes, method, or change in behaviors will have any impact on the symptom - named or unnamed.

To see how the statement Estimating is the smell of Dysfunction is seriously flawed and the approach of asking 5 Whys equally flawed, please read RealityCharting® Seven Steps to Effective Problem-Solving and Strategies for Personal Success, Dean L. Gano

The Seven Steps are:

  1. Define the problem.
  2. Determine the known causal relationships to include the actions and condition of each effect.
  3. Provide a graphical representation of the causal relationships to include specific actions and conditional causes.
  4. Provide EVIDENCE to support the existence of each cause.
  5. Determine if each set of causes is sufficient and necessary to cause the effect.
  6. Provide effective solutions that remove, change, or control one of more causes of the event. Solutions must have been shown to prevent recurrence, meet our goals and objectives, be within our control and not cause other problems.
  7. Implement and track the effectiveness of each solution.

When one or all of these steps are missing, anyone conjecturing their solution - or worse conjecturing we're just exploring for the solution - that conjectured solution is NOT a solution, it's just unsubstantiated conjecture. 

One of my favorite quotes when hearing unsubstantiated claims is this:

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg - Abraham Lincoln

Calling estimating the smell of Dysfunction doesn't make estimating the smell of dysfunction. You've only identified an unsubstantiated symptom. Until you have found the cause and certainly can't suggest Not estimating is the corrective action.

When we have willful ignorance of the Microeconomics of decision making, managerial finance as a governance process for managing other people's money, denial that the uncertainties of projects - aleatory and epistemic uncertainty - can be addressed without estimates of the impact of those uncertainties. Then we are no better than the people mentioned in George Bernard Shaw's quote above. And we are doomed to repeating the symptoms that result from ignoring these principles of managing in the presence of uncertainty. 

 

Related articles The Dysfunctional Approach to Using "5 Whys" Carl Sagan's BS Detector Myth's Abound Making Conjectures Without Testable Outcomes Are Estimates Really The Smell of Dysfunction? Architecture -Center ERP Systems in the Manufacturing Domain The Fallacy of the Planning Fallacy IT Risk Management
Categories: Project Management

Process Improvement In the Second Grade

Fri, 04/08/2016 - 02:53

Our daughter is an elementary school teacher in Austin - and a Graduate student at UT Austin in the Board Certified Behavioral Analyst program. When I hear about some corrective action to an unnamed cause - not the symptom but the cause -  like estimates are the smell of dysfunction, I think of a chart she has hanging in her room for her students, where they are learning critical thinking skills they will need in life. 

Screen Shot 2016-04-02 at 5.45.46 PM

  • Focus Question - what is the question we're trying to explore? Is that question clearly formed?
  • Prediction - is there a prediction of what the possible outcomes might be when we discover the answer to the question? This is important, because we need to separate the answers into plausible answers and implausible answers. That way we can sort out the Wheat from the Chaff. Which is a nice way of saying sorting out the BS from the plausible.
  • Plan - OK, now what's our plan to start exploring. This is exploring is a directed exploring. Not a wandering around looking for Unicorns in the forest. That is called a Snip Hunt. There is no Snip to hunt, but it's a fun thing to do for novice and naive tenderfoots in the scout pack or the business of spending other people's money. 
  • Data - what data will we need to develop to support our search for the answer to the Focus Question? Where would we  find this data? How will we be able to validate this data. Is this data personal anecdotes or is it from a principled framework that can be tested in the absence of the person providing  the data.
  • Claims & Evidence - when claims are made, is there any testable evidence of that data? And most importantly is there any testability that supports the Focus Question?
  • Reflection - with this process, what do we learn? Was there a prediction that could be tested - estimates are the smell of dysfunction? How would you test that conjecture? What would the predicted outcome of that Focus Question and Prediction in terms of measurable evidence? Do we have a Plan to explore that question - or are we  just going to wander around looking for that mythical Unicorn that will bring Rainbows and Sunshine to our project? Where is this data? How did we find it? Journal papers, books, actual data collected ourselves using good data analysis techniques - not the pesky Flaw of Averages approach, but an actual data collection process? For claim to be credible there needs to be evidence to support the claim.

So in the end if 2nd graders in Austin Texas can figure this out, why can't adults tasked with spending other people's money do this as well?

Related articles Everything I Learned About PM Came From a Elementary School Teacher Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Is Macroeconomics and Social Science the Same as Software Development?

Tue, 04/05/2016 - 15:48

There a popular notions in the agile development world that authors like Hayek and Taleb speak to how software development works. Let's look at one example. You Can’t Understand Agile Without Understanding Hayek. Let's look at Hayek's paper. "The Use of Knowledge in Society," F. A. Hayek, The American Economic Review, Vol. 35, No. 4, September 1945, pp. 519-530.

Let's look at the thesis of Hayek in light of software development and the decisions that must be made when spending other people's money in the presence of uncertainty. Below is from the paper, but download the paper and read the whole thesis. Hayek was a social scientist. He was not a program manager of engineered to order software intensive system of systems. His ideas have not held up well. Hayek and Modern Macroeconomics. So I'd suggest not spending your customers money before doing some more research.

What is the problem we wish to solve when we try to construct a rational economic order? 

On certain familiar assumptions the answer is simple enough. If we possess all the relevant information, if we can start out from a given system of preferences and if we command complete knowledge of available means, the problem which remains is purely one of logic. That is, the answer to the question of what is the best use of the available means is implicit in our assumptions. The conditions which the solution of this optimum problem must satisfy have been fully worked out and can be stated best in mathematical form: put at their briefest, they are that the marginal rates of substitution between any two commodities or factors must be the same in all their different uses.

This, however, is emphatically not the economic problem which society faces. And the economic calculus which we have developed to solve this logical problem, though an important step toward the solution of the economic problem of society, does not yet provide an answer to it. The reason for this is that the "data" from which the economic calculus starts are never for the whole society "given" to a single mind which could work out the implications, and can never be so given.

The peculiar character of the problem of a rational economic order is determined precisely by the fact that the knowledge of the circumstances of which we must make use never exists in concentrated or integrated form, but solely as the dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess. The economic problem of society is thus not merely a problem of how to allocate "given" resources-if "given" is taken to mean given to a single mind which deliberately solves the problem set by these "data." It is rather a problem of how to secure the best use of resources known to any of the members of society, for ends whose relative importance only these individuals know. Or, to put it briefly, it is a problem of the utilization of knowledge not given to anyone in its totality.

First some questions:

  • Is the economic data for the project available in a single mind? - probably not. But that data is likely available in a collection of artifacts. In our domain this is the Performance Measurement Baseline, which is a time-phased budget plan for accomplishing work against which contract performance is measured. It includes the budgets assigned to scheduled control accounts and the applicable indirect budgets. The PMB is developed and evolves as the project develops and evolves. This is the basis of the Agile Product Roadmap and Product Release Plan (either cadence or capability based).
  • Is the character of the problem determined precisely? - Of course not. But margin, management reserve, analysis of alternative is standard project management process of dealing with the indeterminate elements of projects. This is also the core principle of Agile - evolutionary emergence of the needed requirements to fulfill the needed Capabilities. 
  • Is there knowledge of what resources can be applied to solving the problem? - On projects yes. The Organizational Breakdown Structure (OBS) is usually on baseline. People don't come a go at will. People have defined skills and capabilities. People - hopefully - don't have conflicting politics about what the project should be doing.

Is there vague and unfolding knowledge, driven by externalities, of what the project should be accomplishing, with uncertain and variable funding? With members of the project team having differing views of the outcomes from those paying for the project?

If so, the project has already failed, the members of the project team are on a death march (Yourdan) and should start looking for work elsewhere, before it gets canceled.

So like the other misrepresentations of seminal works, the agile community adopts this attractive ideas with little or no consideration or understanding of their principles. And most of all it those principles are applicable to software development or if those principles are even applicable in today's understanding of who the world works. Macroeconomics is the dismal science - treat it as such when developing software.

  • Software development is not Macroeconomics, it's Microeconomics.
  • Black Swans only exist on projects when there are unknowables. If there are unknowables, the project is doomed from the start. If it's knowable, doesn't means it's known, but standard Risk Management has the means to deal with knowns and know unknowns - both reducible and irreducible.
  • If you're project doesn't have a plan - having Balls isn't going to help. You'll go into the ditch just has fast. Product Roadmaps, Release Plans are core principles of Agile. When you hear this You don't always need a plan Bro... it's from someone who is NOT accountable for spending other people's money in the presence of uncertainty.

So whenever there is some conjecture that someone outside the software development domain has a principle that can be applied to Agile, test that idea first before spending any time and money acting on it. Especially if that time and money is not yours.

Related articles IT Risk Management Risk Management is How Adults Manage Projects Risk Management is How Adults Manage Projects Qualitative Risk Management and Quantitative Risk Management Domain and Context Are King, Then Comes Process and Experience Two Books in the Spectrum of Software Development What is a Team? Five Estimating Pathologies and Their Corrective Actions How Think Like a Rocket Scientist - Irreducible Complexity Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Systems Engineering and Software Intensive System of Systems

Mon, 04/04/2016 - 23:29

There was a Twitter post mentioning Russell Ackoff YouTube about systems.

A system is never the sum of its parts, it's the product of their interactions.

This is a good start, but it needs to produce actionable outcomes, not just principles, but practices and processes. How do you define, design, represent, assess, analyze, and manage these interactions. The notion that systems are somehow unmanageable is fine in some domains. Finance, social, political. But in technical systems - engineered technical systems - the system has to work when commanded to do so. Much of Ackoff's principles are the basis of practices and processes that assure this happens. 

I come to this systems domain from the Software Intensive System of Systems paradigm. This is where systems are designed, tested, verified, operated, maintained, enhanced, repaired, and replaced with other system. The touchy feely view of systems does not belong here. This is the domain of Systems Engineering, that many times is based on the principles of Ackoff and others like him.

When I hear about complex software systems and how difficult they are, and how undesirable they are, and all the other urban legends about complexity, complex, complicated and chaos, I get a smile. This is the world we work in. And the world where most people are users of those systems. Here's a start in learning how to manage in the presence of these systems.

Ask anyone mentioning complex, complexity, complicated, and chaos if they have a background in Systems Engineering? No, walk away, they don't know what they're talking about.

Related articles The Use, Misuse, and Abuse of Complexity and Complex Technical Performance Measures Agile as a Systems Engineering Paradigm Systems Thinking, System Engineering, and Systems Management Can Enterprise Agile Be Bottom Up? Estimating Guidance Systems Thinking and Capabilities Based Planning What Can Lean Learn From Systems Engineering? Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

A Wrap Up of the #NoEstimating Conjecture Analysis to Date

Mon, 04/04/2016 - 05:26

Quote-everyone-is-in-favor-of-free-speech-hardly-a-day-passes-without-its-being-extolled-but-winston-churchill-34-86-86

The conjecture that we can make decisions in the presence of uncertainty without estimating the impacts of those decisions is without any principles that can be tested beyond personal anecdotes of I know people who spend other peoples money without providing estimates

Here's some reading to help understand why its bunk and how to learn to estimate in the presence of uncertainty in order to make better decisions.

This list starts with the earliest posts, beginning in 2009. 

So when you hear about all the posts about #NoEstimates, take a look here to see if those posts provide any actionable outcomes that can be put to the test on actual projects - other than Slicing. 

  1. A Decoder Ring for #NoEstimates - the post that started it all. Answers to questions that really have no basis, other then personal anecdotes
  2. The #NoEstimates Finale - Pat Richard wrote the blog I wanted to. I've had a conversation of sorts with one of the "leaders" of the #NoEstimates movement who talked in circles when asked where is this method applicable outside your examples of a 5 week project and a cleanup of bugs on another project? 
  3. Can We Make a Decision Without Knowing the Cost? - There is an immutable set of questions that need answers before we can determine the probability of success for our project. The NE advocates don't ask or answer these questions.
  4. How to Forecast the Future - In the YouTube presentation from the previous post, titled Predicting the Future, there was a statement made about minute 9:08 where it is stated the only way that you can estimate is if you can look into the future and that requires precognition, which we don't have. For those of us earning our living by looking into the future, this brings a smile.
  5. Predicting the Future - With the #NoEstimates topic still ringing in my ears, here's an interesting presentation from one of the supporters of this concept. It has many good concepts, one serious math error, and connects well with how we manage and work billion dollar programs.
  6. This Does Not Scale - If there are software development projects that can be executed without knowing how much it will cost in the end (an open ended spend plan), or projects where the budget is capped (a Not To Exceed Number) and we don't really need to know the upper bound of the features to be delivered, how large can this notion scale?
  7. How NOT to Estimate Anything - The #NoEstimates discussion now has something to talk about. There is a presentation titled Re-Estimating the Value of Estimating. While there little here that is applicable in our software intensive world, I had a smile when I came to this slide.
  8. What's Gonna Cost and When Will We Be Done? - What's it gonna cost and when will you be done? And oh yea, ...it will work enough to meet my mission success criteria right?
  9. Reference Design Concept - reference class forecast is the key to estimates if you've never done the work before
  10. No More #NoEstimates Discussion - I've made the mistake of engaging the #NoEstimates crowd in questions about the usefulness of their idea. Not a group that likes to get questions, by the way. They use the old Ron Jeffries approach (which has since passed for him) of well just try it to see if it works for you. 
  11. Why Estimating Is Mandatory - The #NoEstimates notion has merit in the right domain. If you're looking for motivation for estimates outside of the domain where the customer doesn't really care about the final cost, just the final product developed inside a "level of effort" budget, look here and remember.
  12. No Estimates Mean Better Estimates? - Value at Risk means how much money and time are you willing to risk without understanding how much time and money is at risk.
  13. Credible Estimating Processes - prediction is difficult, but prediction is the basis of all decision making. We need to learn how to predict with credible methods. And stop accepting the notion that prediction is simply not possible.
  14. Standing on the side of the road and pointing out problems -There a number of people in the Project Management world that seem to take delight in standing on the side of the road pointing out all the failures of projects, processes, and the people managing them.
  15. Planning, Plans, and Execution of the Plan - An interview with Jeff Sutherland and Hank de Velde brings up some important notions in program and project management.
  16. Hume's Advice for Theoretical Business Process Advice - Hume has some advice for the proffers of business or process improvement that fail to provide tangible evidence from the field that suchadvice actually works in a domain interesting to the reader
  17. Estimates and all that... - Esther Derby has a post on estimating. The thread seems to go that estimating is helpful but estimates are not. Let's start with estimating in a domain where we are spending other people's money. Better yet an environment where we are spending the money of a sovereign - the United States of America.
  18. How Many SW Projects Have No Concern About Budget or Schedule? - Rob Schneider posted a comment suggesting the PM 2.0 proponents "are people (that) tend to have experience/careers in industries and on projects where scope is fungible."
  19. Software Estimating - Pawel commented on the previous post about the difficulties in making estimates of duration and cost of software. From an introduction to a seminar conducted by the 309th SMXG in Ogden Utah.
  20. Using Estimates as a Management Tool - For some reason I've been hooked by David Anderson's conjectures about estimating. This has developed over time, mainly because my role on the current project is to aide in the production of a "credible" Integrated Master Schedule (IMS), where estimates of schedule and cost over the life of the program must be made during the proposal. This includes software, hardware, integration and test.
  21. Management is a Control System - With all the discussion about estimating, controlling, and sometimes even managing project it may be useful to have a paradigm of managing anything.
  22. A Fundamental Principle of Writing Software for Money - When there is a sunk cost of any development, be it software, hardware, concrete, a gene-editing anti-virus drug - the value of the resulting product or service is directly related to that sunk cost. 
  23. Reference Class Forecasting for Software Estimating - When it is conjectured You can't do estimates on software projects stop for a second and think about that concept? Really, "you have no idea what so ever about how long this will take and how much it will cost?" I don't want to estimate because I think it is a waste of time is a bit different. That says you're either too lazy to do the estimating, I don't you know how to do the estimating, or you really just want to get going and write software, because that's what you do for a living.
  24. Don't Do Stupid Things On Purpose
  25. Software Estimating Taxonomy
  26. The Problem Using Platitudes For Management Guidance
  27. Alternatives to Agile Estimation
  28. How to get a "D" in the Freshman Finance Class
  29. Why Hasn't #NoEstimates Produced Actionable Outcomes Yet?
  30. Forecasting The Future is Sporty Business, So Knowledge, Skill and Experience is Needed
  31. Want to Forecast the Future? Here's How - Part 2
  32. Critical Thinking Insight
  33. #NoEstimates Makes Contact With Reality
  34. Facts and Fallacies of Estimating Software Cost and Schedule
  35. Can We Make Decisions Without Feedback?
  36. Fooled By Randomness
  37. Coming to the Table with Facts Improves the Conversation
  38. Estimating Accuracy
  39. Nice Estimating Example
  40. Quote of the Day - More Statistics for Decision Making 
  41. How To and How Not To Make Credible Estimates of Cost and Schedule
  42. Books for Cost and Schedule Forecasting
  43. Indicators of project performance provide us with "Steering Inputs"
  44. How To Estimate Almost Any Software Deliverable in 90 Seconds - here's an example to debunk all those posts that say e can't possibly estimate things we don't knwo the details of. This is a Wide Band Delphi process that has been around for 
  45. Estimating Cost, Schedule, and Technical Peformance
  46. What Software Domain Do You Work In?
  47. How To Estimate, If You Really Want To (Updated)
  48. Five Ways To Rethink Software Projects
  49. Quote of the Day
  50. Statistical Process Control The Basis of All Modern Control Systems
  51. Quote of the Day
  52. Black Swans and "They Never Saw It Coming"
  53. Statistics, Bad Statistics, and Damn Lies
  54. Straight Forward, Logical Approaches to Spending Other Peoples Money
  55. Can There Be Successful Projects With Fixed Dates, Fixed Budgets, and Promised Minimal Features?
  56. All Value Production Is Time Phased
  57. All Value Assessments Must Know the Cost
  58. Alert - Was Poor PM the Root Cause of ACA Difficulties?
  59. The Value of Making An Estimate
  60. Processes for Increasing the Probability of Project Success
  61. How To Estimate Almost Anything If You Really Want To
  62. Is fine grained decomposition of work the same as "Not Estimating?"
  63. Managing In The Presence Uncertainty - Redux
  64. Quote of the Day
  65. How Not To Develop What "Done" Looks Like
  66. Elements of Project Success
  67. Resources for Moving Beyond the "Estimating Fallacy"
  68. How to Fib With Statistics
  69. 3 Impediments To Actual Improvement in the Presence of Dysfunction
  70. Three Kinds of Uncertainty About the Estimated Cost and Schedule
  71. It's an Estimating Problem not A Problem with Estimating
  72. Let's Stop Guessing and Learn How to Estimate
  73. Slicing Work Into Small Pieces
  74. Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices
  75. Quote of the Day - Capabilities state the intent of the commander
  76. Quote of the Day - Nice hypothesis you have there, be a shame if some were to test it
  77. Why Software is Like Construction and Why it is Not
  78. If This is How You See Management ...
  79. Some more answers to the estimating questions
  80. Back To The Future
  81. Danger Will Robinson - it's not your money
  82. Answers to Shim's Questions - answer's the Shim's questions about Estimates are Not Estimates
  83. Flaws and Fallacies in Statistical Thinking - all project work is probabilistic based underlying statistical uncertainty
  84. Cost is KING, No Way Out Of It
  85. Quote of the Day - Software intensive project work is indeterminate.
  86. 8 Reasons Why Estimates Are Too Low
  87. To Stay In Business You Need to Know Both Value and Cost
  88. Four Critical Elements of Project Success - each element has statistical behaviors that requires estimates to provide information for decisions
  89. DDSTOP Part Deux - Don't Do Stupid Things on Purpose - Part 2
  90. Project Finance - all project is guided by managerial finance and microeconomics of decision making, whether you know it or not
  91. How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps
  92. Elements of Project Success - project efficiency, impact on customer, business success, preparing for the future
  93. New Books for Work - making multiple decisions, forecasting and simulating software development projects, forecasting methods and applications
  94. Concept of Operations First, then Capabilities, then Requirements
  95. Connecting the Dots Between Principles and Practices of Project Success
  96. We Can Know the Business Value of What We Build?
  97. We're Asking the Wrong Question - does this suggestion (#NoEstimates) increase the probability of project success?
  98. IT Governance and Decision Rights - those spending the money rarely of ever have the right to decide how, unless explicitly given that right by those providing the money
  99. Is There Such a Thing As Making Decisions Without Knowing the Cost? - We can't make a decision without knowing the cost and benefits of the resulting decision
  100. The Calculus of Writing Software for Money, Part II - the microeconomics of decision making in the presence of uncertainty
  101. Why is Statistical Thinking Hard? - in the presence of uncertainty, probability and statistical is needed to make decisions
  102. Operationalism - When we hear about a process, a technique, or a tool, ask in what unit of measure are you assessing the beneficial outcome of applying those?
  103. Quote of the Day - Writing SW For Money Is Micro-Economics
  104. All Project Numbers are Random Numbers — Act Accordingly - The numbers that appear in projects — cost, schedule, performance — are all random variables drawn from an underlying statistical process.
  105. How to "Lie" with Statistics - much of the #NoEstimates argument is built on Bad Management and Bad Mathematics
  106. Why We Must Learn to Estimate
  107. How To Measure Anything - the notion that we can't estimate the future is nonsense, of course we can. To what precision and accuracy that's the question.
  108. Quote of the Day - Probability theory is nothing but common sense reduced to calculation — Pierre-Simon Laplace1749-1827)
  109. Making Estimates For Your Project Requires Discipline, Skill, and Experience
  110. An Agile Estimating Story
  111. Response to Consolidating #NoEstimates
  112. Staying on Plan Means Closed Loop Control
  113. More Than Target Needed To Steer Toward Project Success - successful projects need closed loop control, and that means Estimate to Complete and Estimate At Completion 
  114. The Use and Misuse of Little's Law and Central Limit Theorem in Agile - misuse of Little's Law is common in Kanban and Agile
  115. Can Enterprise Agile Be Bottom Up? - YES
  116. How To Make Decisions
  117. Why Project Management is a Control System
  118. How Not To Make Decisions Using Bad Estimates
  119. The Myth of Incremental Development
  120. The Power of Misattributed and Misquoted Quotes
  121. The Failure of Open Loop Thinking
  122. Control Systems - Their Misuse and Abuse
  123. Quote of the Day - Gentlemen, we have run out of money; now we have to think - Winston Churchill
  124. Critical Thinking Skills Needed for Any Change To Be Effective
  125. The Value of Information - Since all variables on all projects are random - cost, schedule, and delivered capabilities, in the economics of projects, the chance of being wrong and the Cost of being wrong is the expected opportunity cost.
  126. How to Estimate Software Development - Update
  127. Estimating Software-Intensive Systems
  128. No Estimates Needs to Come In Contact With Those Providing the Money
  129. Making Choices in the Absence of Information
  130. An Example of Complete Misunderstanding of Project Work
  131. The Cost of Value in the Future
  132. Statistical Significance
  133. Quote of the Day - All Things Project Are Probabilistic
  134. Management is Prediction - W. Edwards Deming
  135. What I Don't Know Can Actually Hurt Me - The notion of not knowing the impact of decisions, choices, approaches is like putting your head in the sand because you don't like the answer or don't what to know the answer.
  136. Complex Project Management - only de minimis project are interesting for #Noestimates approach
  137. Estimating on Agile Projects
  138. Constructing a Credible Estimate
  139. Software Estimating for Non Trivial Projects
  140. Show Me Your Math
  141. When the Solution to Bad Management is a Bad Solution - the core notion of #Noestimates is it is the smell of dysfunction. This is a symptom not a cause. Removing estimates does not fix the cause of Bad Management.
  142. Estimating Guidance - With the plethora of opinions on estimating - some informed, many uninformed - here's my list of books and papers that inform our software estimating activities for Software Intensive Systems.
  143. Quote of the Day - The most unsuccessful three years in the education of cost estimators appears to be fifth-grade artihmetic - Norman R. Augustine
  144. Should I Be Estimating My Work?
  145. Basis of #NoEstimates are 27 Year Old Reports - one of the original advocates of #NoEstimates is basing his argument on a 27 year old report.
  146. Baloney Claims: Pseudo–science and the Art of Software Methods 
  147. Decision Making Without Estimates?
  148. Intentional Disregard for Good Engineering Practices? - It seems lately there is an intentional disregard of the core principles of business development of software intensive systems.
  149. All The World's A Random Process 
  150. The Actual Science in Management Science - Planning for an uncertain future calls for a shift in information management — from single numbers to probability distributions — in order to correct the "flaw of averages."
  151. Planning is the Basis of Decision Making in the Presence of Uncertainty
  152. Decision Making in the Presence of Uncertainty
  153. The False Notion of "we haven't seen this before"
  154. Your Project Needs a Budget and Other Things 
  155. Closed Loop Control - Writing software for money is a Closed Loop Control System.
  156. The Myth and Half-Truths of "Myths and Half-Truths" - I love it when there is a post about Myths and Half-Truths, that is itself full of Myths and Half Truths.
  157. Conveniently Unburdened by Evidence
  158. Risk Management is Project Management for Adults - this is a core concept for all project success. Risk management requires estimating probabilities of occurrence, ranges of variance, and probabilities of impact. Take Lister's advice to heart. Not doing Risk Management is managing other people money like a Child would.
  159. Three Increasingly Mature Views of Estimate Making in IT Projects - Update
  160. Estimating Guidance - Updated - some more updates to how to estimate. No reason not to learn how.
  161. Real Life Sources of Empirical Data for Project Estimates - want empirical data, here's where to find it. No eason to claim we've never done this before. Go find the data or  someone who knows the data.
  162. Intellectual Honesty of Managing in the Presence of Uncertainty
  163. Software Engineering is a Verb - I advise my students to listen carefully the moment they decide to take no more mathematics courses. They might be able to hear the sound of closing doors - James Caballero. "Everyone is a Mathematician," CAIP Quarterly 1989. All projects are probabilistic, estimated are needed to manage them. Learn to estimate.
  164. A Theory of Speculation
  165. Here, There Be Dragons - value at risk is a core concept when deciding how much effort is to be applied to estimating outcomes for the future.
  166. Quote of the Day - Ensure good data get to the Bad Decision Makers
  167. What does it mean when we say 80% confidence in a number?
  168. Sources for Reference Class Forecasting - Reference Class Forecasting is a core process by which estimates can be made for work you personally have not dome before. There is NO excuse for not seeking out reference classes other than laziness.
  169. We Suck At Estimating - this is the lamest excuse I've every heard. Here's how to fix that.
  170. Estimating is Risk Management - if Risk Management is how Adults manage projects, then Adult manage projects with estimates.
  171. Planning And Estimating Is Required for Project Success - can't be any clearer.
  172. Bayesian Statistics and Project Work - one of the original NE'ers claimed to be using Bayesian Statistics, Doubt that. Here's how.
  173. Critical Success Factors of IT Forecasting  - quantifying IT forecasting is straight forward, here's how.
  174. Flaw of Averages - there's a misplace notion that averages the number of stories completed in the past will provide a forecast of the future. Start with The Flaw of Averages. Next, the future is rarely like the past. So on both accounts this is a bad idea in the absence of actual statistical analysis of the numbers.
  175. Risk Management is How Adults Manage Projects - another post on behaving like an adult when spending other peoples money.
  176. The Microeconomics of Decision Making in the Presence of Uncertainty - Re-Deux - microecon is the basis of making decisions in the presence of uncertainty. #Noestimates willfully ignores these principles. 
  177. Five Estimating Pathologies and Their Corrective Actions
  178. Managing in Presence of Uncertainty - more managing guidance when spending other peoples money
  179. When Is Delivering Early Not That Much Value? - one of the myths of agile is deliver early deliver often. Without a domain and context, doing this may have no value and may in fact create more trouble for the project.
  180. Quote of the Day - t's not so much about the creativity of the work, it's about emoting on an economically based schedule- Sean Penn talking with John Krakauer. The whole notion of Value is misguided in many agile conversations. Value ot who? What are the units of measure for Value?
  181. Estimating Probabilistic Outcomes? Of Course We Can! - anyone conjecturing you can't estimate a future outcome needs to learn 
  182. Empirical Data Used to Estimate Future Performance Re-Deux - Came across this puzzling tweet today ... real empirical data & using probability to forecast are worlds apart. I don't buy "estimation uses data" argument. If more reason to learn how to do this and learn to call BS on those that don't.
  183. Open Loop Thinking v. Close Loop Thinking
  184. Managing by (mis)quoting Deming
  185. Criteria for a "Good" Estimate
  186. Fibonacci Numbers, Agile, and the Actual Mathematics
  187. Managing in the Presence of Uncertainty - All project work is driven by underlying uncertainty from people, processes, technology, and tools. Let me restate for clarity Certainty is an Illusion, if you're looking for certainty, you're not going to find it in the project domain. You're not going to find it anywhere in the real world.
  188. The Cost Estimating Problem - In probability theory, de Finetti's theorem† explains why exchangeable observations are conditionally independent given some latent variable to which an epistemic probability distribution would then be assigned. It is named in honor of Bruno de Finetti.
  189. Quote of the Day - those suggesting we abandon the principles of Microeconomics of Software Development, it just ain't so
  190. Risk Management is How Adults Manage Projects - again just for reminder
  191. I Think You'll Find It's a Bit More Complicated Than That - When we encounter simple answers to complex problems, we need to not only be skeptical, we need to think twice about the credibility of the person posing the solution.
  192. How We Make Decisions is as Important as What We Decide
  193. Forecasting the Future is Critical to All Success
  194. The Flaw of Empirical Data Used to Make Decisions About the Future - a popular meme Probabilistic forecasting will outperform estimation every time "It is not only not right, it is not even wrong."
  195. Build a Risk Adjusted Project Plan in 6 Steps - if you're going to be an adult about spending other peoples money, time to act like.
  196. Want To Learn How To Estimate? Part Troisième
  197. Doing the Math - In the business of building software intensive systems; estimating, performance forecasting and  management, closed loop control in the presence of uncertainty for all variables is the foundation needed for  increasing the probability of success.
  198. Estimates - Estimation and measurement of project attributes are critical success factors for designing, building, modifying, and operating products and services.
  199. Economics of Software Development
  200. Approximating for Improved Understanding
  201. Debunking - “There’s nothing more dangerous than an idea – or a person – that’s almost right.” – Bono
  202. Qui Bono - Estimates for example are for the business, why would the business no longer what an estimate of cost, schedule, or technical performance of the provided capabilities?
  203. Who Builds a House without Drawings?
  204. The Flaw of Averages and Not Estimating - another Flaw of Averages post. A must read for any hearing #NoEstimates using average past performance.
  205. The Microeconomics of a Project Driven Organization
  206. Capability Maturity Levels and Implications on Software Estimating
  207. Making Decisions in the Presence of Uncertainty - If you're on a project that has certainty, then you're wasting your time estimating. If you are certain things are going to turn out the way you think they are when you have choices to make about the future, then estimating the impact of that choice is a waste of time.
  208. Decision Analysis and Software Project Management
  209. How to Avoid the "Yesterday's Weather" Estimating Problem
  210. Some More Background on Probability, Needed for Estimating
  211. What Happened to our Basic Math Skills? - If the future is not identical to the past, how can we make a decision in the presence of this future uncertainty?
  212. Making Decisions In The Presence of Uncertainty - Decision making is hard. Decision making is easy when we know what to do. When we don't know what to do there are conflicting choices that must be balanced in the presence of uncertainty for each of those choices.
  213. Information Technology Estimating Quality
  214. Climbing Mountains Requires Good Estimates - The quote was Getting better at estimates is like using time to plan the Everest climb instead of climbing smaller mountains for practice. Is another example of clueless NE advocates misusing a paradigm.
  215. Carl Sagan's BS Detector - along with the Debunking posts, BS Detectors are very useful for sorting out all the noise around NE
  216. Myth's Abound - Myths, misinformation, and magic bullets abound in the software development business. No more so than in the management and estimating of complex development projects.
  217. Eyes Wide Shut - A View of No Estimates - When we hear all the difficulties, misuse, abuse, and inabilities for making software development estimates, the real question is what does the business think of this?
  218. Humpty Dumpty and #NoEstimates - is the classic example of how #NoEstimates redefined the term Estimate to fit their needs.
  219. Who's Budget is it Anyway?
  220. The Dysfunctional Approach to Using "5 Whys" - Redux - the original poster of NE seriously misuses the notion of 5 Whys
  221. Essential Reading List for Managing Other People's Money
  222. Monte Carlo Simulation of Project Performance
  223. Just Because You Say Words, It Doesn't Make Then True - some moe debunking of #NoEstimates claims
  224. The Fallacy of the Planning Fallacy - another common misuse of ideas
  225. Let's Stop Guessing and Start Estimating
  226. A Framework for Managing Other Peoples Money
  227. Anecdotes versus Numbers (Statistics) - #NoEstimates is nothing but anecdotes. Show me the numbers
  228.  Why Bother with Probability and Statistics?
  229. One More #NoEstimates Post
  230. Observation Issues and Root Cause Analysis - if you don't have the Root Cause, suggesting #NoEstimates isn';t going to fix anything
  231. Is #NoEstimates a House Built on Sand? - Estimates have little value to those spending the money.
    Estimates are of critical value to those providing the money.
  232. How To Make Decisions - Decisions are about making Trade Offs for the project
  233. Earned Value + Agile a Match Made in Heaven? - Yes
  234. How To Lie With Statistics - is a critically important book to have on your desk if you're involved any decision making
  235. The Flaw of Averages - more cautions from original #NE'ers about using past performance and just averaging the numbers to forecast future performance.
  236. No Signal Means, No Steering Target, Means No Corrective Actions
  237. Flaws and Fallacies of #NoEstimates - The decision maker is asked to express her beliefs by assigning probabilities to certain possible states of the system in the future and the resulting outcomes of those states. This is how it works in the real world of business.
  238. Why Guessing is not Estimating and Estimating is not Guessing
  239. Making Conjectures Without Testable Outcomes
  240. Estimating and Making Decisions in Presence of Uncertainty
  241. Estimating Processes in Support of Economic Analysis
  242. Are Estimates Really The Smell of Dysfunction? - answer NO They're Not. That was a BS conjecture. Go find the Root Cause and fix that. Estimates are just a tool of all business decision making.
  243. What's the Smell of Dysfunction? - a follow up from the nonsense that estimates are the smell of dysfunction
  244. Risk Management is How Adults Manage Projects - another view of Tim Lister's quote
  245. Software Engineering Economics - all decisions are economic decisions. Learn to use economics when spending other peoples money
  246. Deterministic, Probabilistic, and Empiricism - empirical data is the favorite term for #NoEstimates. Doubt they actually know what that means.
  247. The Economics Of Software Development
  248. Slicing Work Into Small Chunks Is Not Without Hazard
  249. The Myth of INVEST and Actual Systems
  250. The Hard Headed Realism of Business Decision Making - it's not your money, act accordingly
  251. The Water Fall Myth - yet another #Noestimates myth busted
  252. Why We Need To Estimate Software Cost and Schedule
  253. SLOC (Source Lines of Code) - this post created a !@#$ storm from those unfamiliar with embedded controls systems and the near 1:1 relationship between SLOC and cost. Threatening to never use a product built with SLOCV estimates. You know airplanes, cars, train controls and the like. It's gonna be a long walk to work.
  254. Bayesian Decision Making - again Bayesian statistics is very useful for estimating.
  255. Decision Support is a Core Business Process
  256. Estimates and Commitment 
  257. Decision Making Means Making Inferences
  258. All The World's a Random Variable
  259. A Core Business Concept - The Investors concern about returns over a limited horizon is a pervasive feature of all business management decision making.
  260. Estimating Software Intensive Systems - Estimation and the measurements that result are critical success factors for Sofware Intensive Systems.
  261. Debunking: The Five Laws of Software Estimating - The Five Laws of Software Estimating contains several Bunk ideas. let's look at each of the Five
  262. Decision Making in the Presence of Uncertainty
  263. Immutable Principles of Managerial Finance When Spending Other Peoples Money - One of the primary responsibilities of  management is to make decisions during the execution of projects so that gains are maximized and losses are minimized. Decision analysis is critical for projects with built-in flexibility, or options. when these choices operate in the presence of uncertainty.
  264. The Twilight Zone Approach to Business Decision Making - When we hear about focusing on value first, delivery early and often, there is rarely any mention of the cost of that delivery.
  265. Risk Management Is How Adults Manage Projects: Agile is Not Risk Management (Alone)
  266. The Unmyths of Estimating
  267. Another Myth Busted - There is a common misinformed conjecture that large programs are managed just like a military operation. Both these concepts are wrong - dead wrong.
  268. Empirical and it's Use in Agile
  269. Produce Shippable Software Every Sprint? Really - There is a popular notion is some circles of Scrum, that Sprints need to produce shippable software at the end of every Sprint. This of course depends as always on the domain.
  270. Drip Funding, Slicing, Decomposing Large Projects Into Small Projects? - A domain is always needed before any suggestion for anything can be assessed to be applicable and useful beyond personal anecdotes.
  271. The Economics of Sofware Quality - To predict the future of a software project with acceptable accuracy and precision, it is necessary to measure past project and keep track of current and ongoing projects. Estimation and  measurement are closely aligned, and good historical data is of great value in estimating future outcomes of future software projects. 
  272. Agile at Scale - A Reading List (Update 9) of the Day - Planning is Everything, Plans are Nothing - a reminder that the misuse of quotes is rampant in #Noestimates, from Deming to Eisenhower.
Related articles Four Critical Elements of Project Success Sources for Reference Class Forecasting Software Requirements Are Vague What Informs My Project Management View #NoEstimates episode 2 - THE ANSWERS Let's Stop Guessing and Start Estimating Managing Your Project With Dilbert Advice - Not!
Categories: Project Management

Another Myth Busted

Wed, 03/30/2016 - 14:53

There is a common misinformed conjecture that large programs are managed just like a military operation. Both these concepts are wrong - dead wrong.

Here's a great briefing on this topic. You'll find there are topics about managing in the presence of uncertainty and the need to make estimates to assess the outcomes of your decisions.

Commando code from go_oh   After this, read this, ask anyone suggesting you can make decisions in presence of uncertainty without estimates and have them show you how that conjecture does not violate managerial finance and Microeconomics principles? To date there is ZERO example of how this can happen beyond personal anecdotes that are untested outside of those personal anecdotes Screen Shot 2016-02-22 at 9.51.56 AM Related articles Making Conjectures Without Testable Outcomes The Microeconomics of a Project Driven Organization The Microeconomics of Decision Making in the Presence of Uncertainty Estimating and Making Decisions in Presence of Uncertainty The Actual Science in Management Science Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Forecasting Program Performance

Tue, 03/29/2016 - 19:27

Program Performance Management is a core process for any successful business venture that develops products

Forecasting cost and schedule performance from Glen Alleman
Categories: Project Management

The Pseudo Science of No Estimates

Mon, 03/28/2016 - 15:28

I listened to the final rant of Jon Stewart (BIG CAUTION this show is from Cable and for Adults Only, just like Risk Management) and came away with inspiration for a post, which I've edited a bit to remove the phrases not applicable here. 

Pseudoscience and science – the former is an belief based on logical fallacies that is supported by some people who may seem rational; the latter is an actual rational methodology to discover facts about the natural universe. The former is utter bullshit. And the latter is fact. Deal with it. And an almost literal translation of Jon Stewart's last broadcast.

Bullshit Is everywhere. There is very little that you will encounter in life that has not been, in some ways, infused with bullshit.

Not all of it bad. Your general, day-to-day, organic free-range bullshit is often necessary. That kind of bullshit in many ways provides important social-contract fertilizer. It keeps people from making each other cry all day.

But then there’s the more pernicious bullshit–your premeditated, institutional bullshit, designed to obscure and distract. Designed by whom? The bashitocracy.

It comes in three basic flavors. One, making bad things sound like good things. “estimates are the smell of dysfunction, so let's not estimate and the dysfunction will disappear." Because "we're just developers who can't even make high level estimates how much it will cost and we work for bonehead managers who can't tell the difference between a good estimate and a bad estimate," doesn't have the same ring.

"Estimates inhibit creativity, restrict our ability to be flexible, and the other restrictions to our creativity"  sounds better than "we have no clue what we're doing, how much it will cost, or when we'll be done, so juts give us the money so we can start spending," So whenever something’s been titled Pure Agile, or 10X improvement in productivity, searching for the Magic take a good long sniff. Chances are it’s been manufactured in a facility that may contain traces of bullshit

Number two. Hiding the bad things under mountains of bullshit Complexity. You know, I would love to download Drizzy’s latest Meek Mill diss. But I’m not really interested right now in reading Tolstoy’s iTunes agreement. So I’ll just click agree, even if it grants Apple prima note with my spouse. This comes to the discussion of Value at Risk and what are estimates for other than to protect Value at Risk. And the willful ignorance of how every business works projects with probabilistic events and statistical variance and how those uncertainties must be dealt with for the business to have any hope of surviving .

And finally, finally, it’s the bullshit of infinite possibility. The Unicorn approach to solving hard problems, by claiming all big problems can be broken down into little problems, These bullshitters cover their unwillingness to act under the guise of unending inquiry. We can’t do anything because we can't possibly know anything in the presence of uncertainty. We cannot take action to improve that knowledge  until everyone in the world agrees we're not headed down the slippery slope of governance of how we spend other people's money. Until then, I say it leads to controversy.

Now, the good news is this. Bullshitters have gotten pretty lazy. And their work is easily detected. And looking for it is kind of a pleasant way to pass the time.

So when you encounter some claim - estimates are the smell of dysfunction. Or the latest There are countless good ways to make decisions: Estimates is one. Then ask for evidence. Ask for working examples that can be tested against some set of principles. Not just personal anecdotes.  If there are no principles, no testable evidence, then ...

The best defense against bullshit is vigilance. So if you smell something, say something.

Related articles Taxonomy of Logical Fallacies Here, There Be Dragons Late Start = Late Finish Information Technology Estimating Quality
Categories: Project Management

Deliver Fast or Deliver as Planned (Update)

Thu, 03/24/2016 - 16:47

A popular mantra in Agile is deliver fast, deliver often. In some domains this may be applicable. Where we work and where agile is becoming the norm, we have another view.

Deliver as planned

The Plan for the delivery of value is shown in the Product Roadmap and implemented in the Cadence Release Plan, or sometimes in the Capabilities Release plan. Fast is a term replaced by Planned. The Plan is based on a Capabilities Based Plan. This Plan shows the increasing maturity of the Capabilities produced by the project. These Capabilities are needed by the business to accomplish the business case or fulfill a Mission. 

Capabilities Flow

Showing up fast is defined by showing up when needed. The need is defined in the Capabilities Based Planning process. 

Capabilities Based Planning

A Capability is  the ability to accomplish something of Value. Here's a sample of what a Capability sounds like.

Screen Shot 2016-03-22 at 9.14.59 AM

These are mission and business case terms, defined by the owners of the mission or Business Case. If y9ou show up Fast, that also means you can't show up early. For a simple reason - early means you may not be able to put that Value to work. It may mean that Value is not needed yet, and that Value may have to change when we get ready to use that Value. This is the role of the Plan.

In what order do we need what Capabilities - and all their associated technical and operational requirements having been fulfilled - for the needed cost, effectiveness, and performance requirements as well.

A final example - one of my favorites is the notion of the intent of the commander as the basis of defining capabilities. I have a colleague, who was General Schwarzkopf's logistic person in the first Gulf war. She was an Army Colonel and one of a small number of women combatants at the time. There are many more now, but she was a pioneer. One of reasons the US Army was able to move up the coast prior to crossing into Iraq in rapid time was because of her and her staffs planning skills. The notion of agile is the basis of all military process, not just 5 coders in the room with their customer.

So this statement says it all in terms of needed Capabilities

Capabilities Patton

So when you hear deliver early and deliver often. Ask a simple question - what are we delivering? Is that deliverable arriving in the right order for the end user - the customer, the warfighter? Are there any predecessors to that deliverable that have to be in place for the FAST deliverable to be of any use? 

This is the role of a Capabilities Based Plan. If your project has no interdependencies, if everything that is produced can be used as a standalone deliverable - arriving in any order - than Capabilities Based Planning is not likely to be of much value. And that's fine. But when we enter the Agile At Scale domain - ERP, Enterprise IT, Software Intensive System of Systems - we've got a separate issue. Order does matter. Fast is no longer of much value. As planned and as needed  are the Critical Success Factors.

And a final thought

If you're going to Deliver Fast, do you have a Plan for how to do that? No, then how in the world are you going to deliver fast of you don't know what you are going to deliver, when that delivery will be done, and how you are going to deliver that value? Without a plan of some sort,  how can you assert the naive notion of deliver fast and deliver often can ever be executed? It's just a platitude, without any actionable outcomes without a Plan on how to do that.

Related articles The Customer Bought a Capability Integrated Master Plan and Department of Energy Program Management Start with Problem, Than Suggest The Solution The Reason We Plan, Schedule, Measure, and Correct Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Decisions In The Presence of Uncertainty
Categories: Project Management

Forecasting versus Estimating - are they Different or are they the Same

Thu, 03/24/2016 - 16:33

One of the escape clauses of #Noestimates is to re-label Forecasting as NOT Estimating,  It is forecasting, based on empirical data. Ignoring for the moment the empirical data discussion since ALL data is empirical, otherwise you wouldn't have the data. 

Empirical is defined as based on, concerned with, or verifiable by observation or experience rather than theory or pure logic.

And just to beat this horse some more

The origin of the term Empirical starts in the 1560s, from L. empiricus, from Gk. empeirikos "experienced," from empeiria "experience," from empeiros "skilled," from en- "in" + peira "trial,experiment." Originally a school of ancient physicians who based their practice on experience rather than theory.

Empirical also means observed, factual, experimental experiential, pragmatic, speculative, provisional. This is in comparison for estimating purpose for a theoretical model that produces data, parametric from empirical or theoretical models that produce data. In all cases the data is used to estimate some outcome in the past, present, or future. When that estimate is about the future, it can also be referred to as a Forecast. Weather forecasts, sales forecasts, market forecasts, earnings forecasts. All are estimates about some outcome. The antonym of empirical is theoretical, un-observed (as would be the case for a model), hypothetical, conjectural.

So just the repeat - empirical data is observed and empirical data can be one of the sources of making estimates about the past, present, or future.

Since Scrum is an empirical process, it is also shares its attributes with empirical process control systems. Project management and the management of work is a process control systems. This work - writing software for money - is a process. And as a process it needs to be controlled. The control makes use of empirical data. Empirical Process control systems have three major attributes. [1]

  1. Visibility - the attributes of the process that affect the outcomes are visible and known to the processes or people involved in the control of the process. You can't have a process control system, if you can't see what is being controlled, what the result of the control inputs and outputs are.
  2. Inspection - the various aspects of the process are inspected - sampled - frequently enough so that the variances can be measured frequently enough to keep the desired process  under control. Yes, Scrum is a control system for producing the desired software at the desired time.
  3. Adaption - makes use of the data received from the Inspection to adjust the process under control within the desired range of outcomes.

This type of control is found from your home thermostat to the dynamic flight controller used to autonomously rendezvous dock the a vehicle with the International Space Station, to provide corrective actions to keep a project on track toward a planned finish date. It's all the same principle. 

So Back To Estimating and Forecasting

No matter how many times the #Noestimates advocates make unsubstantiated claims that Forecasting is not estimating, it's not true.  

Estimating can be based on empirical data or theoretical models, or better yet from my accelerator days, theoretical models informed by empirical data - Forecasting are estimates of outcomes in the future. 

But forecasts are estimates,period. Anyone claiming otherwise needs to come up with reference materials from control systems books, financial modeling books, statistics books, and something to shows Forecasts are not Estimates about future outcomes. Even one of the founders of eXtreme Programming makes that cocla mammy claim that Forecasts are not estimates. Time to send them back to the High School math class.

 

[1] Modern Control Systems, Richard Dorf. This is the 5th edition. Mine is the 1st Edition, 1970 from the control systems course needed to write FORTRAN 77 code to control the sampling processes on the particle accelerator for our experiment. Google will find this book and Modern Control Systems, Dorf, in PDF form if you actually want to explore further. In the latter book here's the architecture of a general control system, which can be used to manage software development while spending other people's money, fly a spacecraft to Mars or you Boeing 737 you're riding on to home. Jeff Sutherland knows this from his days of driving around in an Air Force F-4 about the same time I was driving around in an Army CH-47 and his further development of Scrum from John Boyd's Air Force work of the OODA Loop. All project work, is all process control all the time. No way out of it, unless your conjectured method is open loop - then you're not controlling anything, you're just watching it fly into the ditch or crash into the ground. Not usually what your customer or commanding officer woould find desirable behaviour.

Screen Shot 2016-03-22 at 3.06.17 PM

So time again to call bunk on this notion

Related articles Management is Prediction - W. Edwards Deming Your Project Needs a Budget and Other Things The Flaw of Empirical Data Used to Make Decisions About the Future Business Rhythm Drives Process The Power of Misattributed and Misquoted Quotes
Categories: Project Management

The Naive Notion that Agile Mitigates Risk

Mon, 03/21/2016 - 21:05

The post Top 5 Ways Agile Mitigates Risk is one of those posts that's not wrong in what it says at the detail level - more or less, but is not right in principle.

Agile Mitigates Risk - is not correct. Agile provides rapid identification of risk. That's all.

First let's start with risk, risk management, and risk management frameworks.

First all risk comes from uncertainty,

Uncertainties are thing we cannot be certain about. Uncertainty is created by our incomplete knowledge - not by our ignorance

What is risk management?

Risk management is an endeavor that begins with requirements formulation and assessment, includes the planning and conducting of a technical risk reduction phase if needed, and strongly influences the structure of the development and test activities.

There are two types of uncertainty that create risks to an Agile Project. Aleatory (irreducible) uncertainty creates risk from the naturally occurring random behaviours of the projects. Things like defects, productivity of the development staff, estimates of effort, random performance issues. Epistemic (reducible) uncertainties from event based occurrences. These are probability based. The probability that we didn't order enough SAN for our first 3 months of operations and we'll run out of fast access storage. The probability that there will be 5 times the number is users logging and and this will crater our current server configuration. Remember the Affordable Care Act site's first months of operation. Or the probability that our test coverage is not sufficient for the needed reliability of our offering. Remember the Affordable Care Act sit's first months of operation? These risks are risks to the success of the project. The blog's risks are mostly process failure risks.

Picture1When we speak of uncertainty is means

  • When we say uncertainty, we speak about a future state of an external system that is not fixed or determined
  • Uncertainty is related to three aspects of our program management domain:
    • The external world – the activities of the program
    • Our knowledge of this world – the planned and actual behaviors of the program
    • Our perception of this world – the data and information we receive about these behaviors

There are several sources of risk from both Aleatory and Epistemic uncertainties.

  • Lack of precision about the underlying uncertainty.
  • Lack of accuracy about the possible values in the uncertainty probability distributions.
  • Undiscovered Biases used in defining the range of possible outcomes of project processes.
  • Natural variability from uncontrolled processes.
  • Undefined probability distributions for project processes and technology.
  • Unknowability of the range of the probability distributions.
  • Absence of information about the probability distributions.

The relationship between Uncertainty and Risk is:

  • Uncertainty is present when probabilities cannot be quantified in a rigorous or valid manner, but can described as intervals within a probability distribution function (PDF). 
  • Risk is present when the uncertainty of the outcome can be quantified in terms of probabilities or a range of possible values. 

This distinction is important for modeling the future performance of cost, schedule, and technical outcomes of a program. Both Aleatory and Epistemic uncertainty create risks.

Screen Shot 2016-03-21 at 1.17.11 PM

And these unavoidable uncertainties create risks for software projects

Screen Shot 2016-03-21 at 1.18.46 PMThe processes needed to Manage the risks created by these uncertainties include

Picture2

So Let's at the suggestion from the Blog that Agile Mitigates risk

  1. Sprint Durations - short cycles of produced outcomes provide faster samples to confirm those outcomes meet the needs of the customer. This is a requirements validation risk reduction. But the risk that the produced code doesn't meet the needs of the customer is still there. You just find out about it faster. While it is true shorter sprints reduce the overall variances of the productivity of value, it does not remove this variability.
  2. Retrospectives - the blog mentions ineffective processes but that's not a risk in the Risk Management sense. The reducible (probabilistic) and irreducible (statistical varaince) risk are still there. They are not reduced or eliminated without specific actions.
    •  The natural variations can be addressed with margin. This concept is not in standard Agile. 
    • The event based probabilistic risk can be reduced with explicit activities 
  3. Backlog Grooming - revising and reviewing the backlog does not remove the naturally occurring variances and probabilistic events that someone will go wrong. Those are still there. Grooming the backlog faster doesn't change the probability distribution for the event based risks or the statistical behaviours of the naturally occurring variances that creater risk.
  4. Promoting Transparency - this is an actual risk reduction process. No a mitigation, but a process to IDENTIFY  risk.
  5. Frequent Deliveries and Sprint Reviews - again these are process that IDENTIFY risks, but do not mitigate those risks.

The notion that most risk can be avoided is naive at best. Along with Agile preventing risks from occuring. Both are not true.

Agile provides a good means of identifying risk. Agile is NOT a risk management process. Agile does not prevent risk, only margin or explicitly risk reduction activities can mitigate risks. Risk can not be prevented, they can only be mitigated, avoided, transferred, or ignored.

Posts like this are common. I'd suggest it's because the actual source of information needed to identify, management, and reduce risk on software projects is not being read by developers who are applying agile. It's one of those repeated occurrences of using a word that the meaning is not known

Screen Shot 2016-03-21 at 1.49.09 PM

And of course one final thought

In order to handle risks - reducible and irreducible - through mitigation, transferring, ignoring, or accepting the risk - we MUST be able to estimate several things about the risk:

  • The probability of occurrence of the reducible risk
  • The range of naturally occurring variancs for the irreducible risks
  • The probability that he mitigation will be effective
  • The probability of any residual risk post-mitigation

This is Risk Management, Agile is NOT risk management. Agile is one part of risk management - Identification, potentially tracking, a contributor to control, and a contributor to communicating the risks. 

Related articles Probability and Statistics of Project Work Risk Management is How Adults Manage Projects Qualitative Risk Management and Quantitative Risk Management
Categories: Project Management

Find the Root Cause Before Assuming Your Fix Can Actually Fix Anything

Mon, 03/21/2016 - 17:47

A burst of Tweets of No Estimates fixes these problems came across Twitter this morning. I won't repeat who they are attributed to, to protect the guilty. But here's a core concept that is totally missing from not only the No Estimates conjecture, but from most every discussion, where a solution is proposed before the problem has been actually defined. Let's start with Dean Gano's introduction to Apollo Root Cause Analysis, which is a George Bernard Shaw quote so fitting to the discussion of ignoring the root cause and going straight for a solution to the symptom - in many cases an Unnamed symptom.

Ignorance is a most wonderful thing.
It facilitates magic.
It allows the masses to be led.
It provides answers when there are none.
It allows happiness in the presence of danger.
All this while, the pursuit of knowledge can only destroy the illusion.
Is it any wonder mankind chooses ignorance?
~ George Bernard Shaw

So until the symptom is named - and the smell of dysfunction is not a symptom. Until the search for the root cause of the symptom, and applying the 5 whys to an unnamed symptom is not a root cause analysis process. And the root cause is discovered, there will be no chance that any suggested processes, method, or change in behaviors will have any impact on the symptom - named or unnamed.

To see how the statement Estimating is the smell of Dysfunction is seriously flawed and the approach of asking 5 Whys equally flawed, please read RealityCharting® Seven Steps to Effective Problem-Solving and Strategies for Personal Success, Dean L. Gano

The Seven Steps are:

  1. Define the problem.
  2. Determine the known causal relationships to include the actions and condition of each effect.
  3. Provide a graphical representation of the causal relationships to include specific actions and conditional causes.
  4. Provide EVIDENCE to support the existence of each cause.
  5. Determine if each set of causes is sufficient and necessary to cause the effect.
  6. Provide effective solutions that remove, change, or control one of more causes of the event. Solutions must have been shown to prevent recurrence, meet our goals and objectives, be within our control and not cause other problems.
  7. Implement and track the effectiveness of each solution.

When one or all of these steps are missing, anyone conjecturing their solution - or worse conjecturing we're just exploring for the solution - that conjectured solution is NOT a solution, it's just unsubstantiated conjecture. 

One of my favorite quotes when hearing unsubstantiated claims is this

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg - Abraham Lincoln

Calling estimating the smell of Dysfunction doesn't make estimating the smell of dysfunction. You've only identified an unsubstantiated symptom. You have found the cause and certainly can't suggest Not estimating is the corrective action.

When we have willful ignorance of the Microeconomics of decision making, managerial finance as a governance process for managing other people's money, denial that the uncertainties of projects - aleatory and epistemic uncertainty - can be addressed without estimates the impact of those uncertainties. Then we are no better than the people mentioned in George Bernard Shaw's quote above. And we are doomed to repeating the symptoms that result from ignoring these principles of managing in the presence of uncertainty. 

 

Related articles The Dysfunctional Approach to Using "5 Whys" Carl Sagan's BS Detector Myth's Abound Making Conjectures Without Testable Outcomes Are Estimates Really The Smell of Dysfunction? Architecture -Center ERP Systems in the Manufacturing Domain The Fallacy of the Planning Fallacy IT Risk Management
Categories: Project Management