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: 7 hours 29 min ago

Decision Making in the Presence of Uncertainty

Sat, 06/25/2016 - 23:44

There's another rash of Twitter posters supporting the conjecture that decisions can be made about how to spend other people's money without estimating the impact and outcome of that decision. This is a core premise of #NoEstimates from the Original Poster

No Estimates

Here's a starting point to learn that simply not true 

There are 100's more books, papers, conference proceedings on the topic of decision making in the presence of uncertanty.

It comes down to a simple concept

All project work is uncertain. Reducible uncertainties (epistemic) and irreducible uncertainties (aleatory). When money is being provided to development software, those providing the money a reasonable expectation to know something about when you will be providing the value in exchange for that money, how much money will be required to provide that value, and what capabilities will be provided in exchange for that money. The field of study where these questions and answers live is microeconomics of decision making. Software development decision making is a well studied subset of that field.

When it is conjecture decisions can be made in the presence of uncertanty without estimates - like the Original Poster did, and there is no supporting theory, principle, practices, or evidence of how that can be done - run away - it's a bogus claim. 

Related articles Making Decisions In The Presence of Uncertainty Essential Reading List for Managing Other People's Money Herding Cats: Decision Making in the Presence of Uncertainty Herding Cats: Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics Making Conjectures Without Testable Outcomes
Categories: Project Management

#NoEstimates Book Review - Part 1

Sat, 06/25/2016 - 01:17

I've started reading Vasco's book #NoEstimates and will write a detailed deconstruction. I got the Kindle version, so I have a $10 investment at risk. Let's start with some graphs that have been around and their misinformation that forms the basis of the book.

The Chaos Report graph,is the 1st one. This graph is from old 2004 numbers. That's 12 year old numbers. Many times the books uses 12, 16, even 25 year old reports as the basis of the suggestion that Not Estimating fixes the problems in the reports. The Chaos reports have been thoroughly debunked as self selected samples using uncalibrated surveys for the units of measure for project failure. Here's a few comments on the Standish reporting process. But first remember, Standish does not say what the units of measure are for Success, Challenged, or Failure. Without the units of measure, the actual statistics of the projects and the statistical ranges of those projects for each of the three categories, the units as essentially bogus. Good fodder for selling consulting services or for use by those with an idea to sell, but worthless for decision making about the root cause of Failure, Challenged, or even Success. Any undergraduate design of experiments class would have all that information in the public. 

So the 1st thing to read when you encounter data like this is Project Success: A Multidimensional Strategic Concept, Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz. Only then start to assess the numbers. Most likely, like the numbers in the book, they're not credible to support the hypothesis. Which by the way there is no hypothesis for you can make decisions in the presence of uncertanty without estimating

So let's look further at the difficulties with Standish and why NOT to use it as the basis of a conjecture

A simple google search would have found all this research and many many more. I get the sense V didn't do his homework. The bibliography has very few references to actually estimating, no actual estimating books, papers, or research sites. Just personal anecdotes from a  set of experiences as a developer.

The Standish Report failure mode is described in Darrell Huff's How to Lie With Statistics - self select the samples from the survey. Standish does not provide any population statistics for their survey.

  • How many surveys were set out?
  • How many responded?
  • Of those responding, how many were statistically significant?
  • What does it means in terms of actual measures of performance to the¬†troubled?
  • If the project was over budget, was the needed budget estimate correct?
  • If the project was late, was the original schedule credible?

None of these questions are answered in Standish reports. No Estimate picks these serious statistical sampling error up and uses the, as the basis of the pure-conjecture that Not Estimating is going to fix the problems. This would garner a high school D is the Stats class.

Screen Shot 2016-06-24 at 2.08.13 PM

Next comes a chart that makes a similar error. This reference is from Steve McConnell's book, but is actually from another source. The No Estimates book does a poor job of keeping the references straight. It is common to misattribute a report, a graph, even a phrase. The book needs a professional editor.

The graph below is used to show that estimates are usually wrong. But there is a critical misunderstanding about the data.

  • It starts with a straight line called¬†perfect accuracy/. First there are two attributes of any estimate.¬†Accuracy¬†and¬†precision. There is no such thing as perfect accuracy in the estimating business. An estimate is an approximation of reality.
  • The sample projects show they did not meet the¬†perfect accuracy - whatever that might have been. This knowledge can only be obtained¬†after the work has been done. Either at the end or during the project - cumulative to date.¬†
  • But there are two sources of the variances of¬†estimates and actuals

Screen Shot 2016-06-24 at 2.08.06 PM

I'm in the early parts of the book and already have a half dozen pages of notes for either fallacies, incorrect principles, 30 year old references, and other serious mistakes on understanding on how decisions are made in the presence of uncertainty. My short assessment is 

It's a concept built on sand.

Related articles Myth's Abound All Project Numbers are Random Numbers - Act Accordingly The Failure of Open Loop Thinking How to "Lie" with Statistics Statistical Significance How to Estimate Software Development Capabilities Based Planning IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes
Categories: Project Management

Control, Stability, Short Term, Long Term all needed for Success

Tue, 06/21/2016 - 02:27
Single Track

When riding a single track like this one behind our neighborhood, I came to an understand of the tradeoffs between stability and control. In our conference sessions, we speak about how the Wright Brothers learned this concept as well.

Nationals Here's another trail being ridden by our son at Nationals in 2013. who's massively better than I will ever be. But same tradeoff between stability and control is needed to be ranked 33rd Cross Country and 23rd Short Track at DII in the nation, with team taking 2nd overall.

In both cases, nationally ranked and rank amaetur, control of bike is the key. Stability is a relative term, depending on speed, terrain, skill, risk taking tolerance,  experience, technical equipment, and other intangible factors.

We speak at conference where program planning and controls is the topic. Starting 2 years ago, our foundation for speaking about managing in the presence of  uncertanty is the Wright Brothers.

Most earlier experimenters in powered flight focused only on one or two of the primary problems - (a) A set of lifting surfaces, or wings, (b) A method of balancing and controlling the aircraft, and (c) A means of propulsion -  and did not consider the final design from the outset. The Wrights recognized that each of these areas had to be successfully addressed to build a working airplane. They believed that the aerodynamic and propulsion problems would be comparatively easier to solve, so they first concentrated on how to maintain balance and control.

Many believed that air currents were too swift and unpredictable for human reflexes. Therefore, an aircraft had to be inherently stable for the pilot to be able to maintain control.¬†Because of the Wrights‚Äô extensive experience with the bicycle‚ÄĒa highly unstable but controllable machine (just like the mountain bike)‚ÄĒthey saw no reason why an airplane could not be unstable yet controllable as well.

The notion of Control is missed used in software development projects. Misused and misunderstood. Control inside the upper and lower control bounds is a critical success factor. What are those upper and lower control bounds? Good question. They have to be estimated in the start. They become cleared as the project progresses. They have to be adjusted as new information emerges.

In projects, the question for Stability is a false quest. All project work is uncertain. Stability is short lived. New inputs arrive every day. Just like new inputs arrive while riding down the flat trail for cruising around the open space in the neighborhood or more so on the bumpy high speed trail of collegiate racing.

Even if the trail is defined in from of you, the small disruptions and many times big distributions input your control of the bike. The key is Control over Stability. Staying in control will get you across the finish line, down the trail, and home again to ride another day.

Skills of Maintaining Control on the Mountain Bike and the Project

Starting from our house there is a nice loop Left Hand Trail, that is easy, has a few climbs, and a few descents, uncrowded, and provides a nice view of the small hills before the real mountains start . Combine that with the Eagle Trail, Sage Trail, and North Rim Trail and it's a nice 7 mile loop

  1. Short term feedback - what's happening right in front of me? What do I need to do NOW to maintain stability, to survive for the next 10 feet on the trail 
    • On projects,¬†short term feedback is for the¬†next day or week.
    • What's coming due?
    • A Plan of the Week or even a Plan of the Day is ¬†very useful.
  2. Long term feedback - I see things coming on the trail. A big drop. A huge climb. What am I going to do to prepare for both? Do I have a plan of action to get through these?
    • On projects, I need to see this coming before I am¬†Overcome¬†By¬†Events¬†(OBE). The term OBE is used often in our domain. It says, they didn't see it coming. They didn't have a plan to respond to emerging events.
    • The naive term in agile of¬†respond to emerging requirements means you have to have a plan to meet that emerging requirement. If you don't, just like on¬†the bike, you're going to end ¬†up on the side¬†to the trail, landing on a cactus¬† or worse a snake where we live.
  3. Corrective actions - what corrective actions am I capable of performing? On the bike, I must know my limits. Can I power through the steep climb? Maybe if it's short. No likley if it's 1/2 mile at 18% grade.
    • On projects knowing the limits of the team is a critical success factor.
    • Who can work the problem with the most rapid response? Who's got skills and experience needed to¬†power through till we get back in control
  4. Alternative choices - as the trial unfolds in front of me, choices present themselves. Some are optional, some are mandatory alternatives. Other riders coming up the trail have to be addressed. If their coming up hill and I'm going down hill, they have the right-of-way. I can easily start again going down hill. Stopping and starting again going up hill is a real pain. Obstacles on the trail have to be dealt with. In the spring branches hang in th trail from the trees and bushes. Many have sharp leaves or thorns, riding through them is painful.
    • On project having alternatives is also mandatory.¬†
    • Nothing ever goes right as planned. Having an alternative ready to go, means when trouble arrives, there is no delay in making a choice to take another path.
  5. Estimate what's right in front of you - the trail is rough, bumpy, rutted, off camber, muddy, thorny, and many times some animal runs across my path - rabbitt, prairie dog, a snake. A quick estimate is needed to decide what to do. Keep going, speed up, slow down, stop? All depends on the situation.
    1. Estimating on projects is part of the close loop control system.
    2. Both project controls and business control depend on making estimates in the presence of uncertanty about future outcomes.
    3. These estimates keep the project Green, just like estimates on the bike keep me rubber side down.
  6. Estimates of needed for solutions coming up the trail - with short term estimating there are a limited number of choices, bounded by the physical terrain. For longer term choices, there are more options. Do I turn left at the next opportunity, go over the mesa, then back down to rejoin the trial at the parking lot of the hiking trailhead? 
    • For projects a longer view of what's coming is needed.
    • Points of integration or incorporation need to be in the Plan.
    • Alternative Points of Incorporation (APOI) are needed as well.
    • Many time these APOI are part of the master plan, since external facilities may be booked, resources become scarce, technology changes.¬†
    • A ¬†Plan B is needed as part of the normal process
  7. Estimates of needed resources - food, water, spare equipment are part of the normal riding gear. For really big rides, Bear Spray is common, since we live in Bear Country. Energy resources must be managed. Knowing how fast you can go, when is the next resting spot, next shady spot?
    • The resource plan for the project is needed no matter the method used to develop the project.
    • What skills, how many of those skills, the availability of those skills?¬†
  8. Estimates to complete - rarely do we go out without some plan of when we'll be back. This means some estimate of when we'll be back. Telling wife's we're going up to Hygiene and we'll be back in 2 hours is always good protocol. 
    • On projects knowing something about when you plan to finish is part of managing the project.
    • Anyone working on a project that doesn't have some type of deadline is working on a de minimis project - it's too small for anyone to care about when you'll be down.
    • Same for the budget
    • Same for the needed technical performance.
  9. A Plan B and even a Plan C - planning in depth is a good idea when riding anywhere. The longer the ride, the steeper the terrain, the higher the exposure, means having more plans to deal with the emerging situations
    • Without a plan, you're driving in the dark with the lights off.
    • What ever comes up is likely to be a surprise.
    • While surprises are nice for birthday parties, surprises 25 miles out from home, with a 25 mile return can turn unpleasant real quick.
    • Planning in depth is always a good idea.
    • Knowing the¬†Value at Risk¬†defines the magnitude and detail of the plan. If the impact is minimal and can be handled with a few changes, no problem. If the impact is major, having a detailed plan when it occurs is the basis of success
    • Risk Management is How Adults Manage Projects Tim Lister should never be forgotten
  10. Knowledge of capacity for work - how big is a big ride? Good question. When we have friends ask hey want to go for a ride, I have to make sure I have the capacity for work. Our neighborhood has many cyclist. A Silver Medalist rider. A semi-pro road rider. A former pro road rider. A semi-pro mountain biker all the way down to casual riders like me and our group. Know what the ride will demand and what I'm capable of doing is a starting point. Along the way reassessing both those informs decisions about routes, pace, and overall strategy to get home in one piece
    • On projects, if we don't our capacity for work, we can't make informed estimates if we can get to the end in¬†one piece.
    • If we¬†bite off more than we can chew, then we're going to be late and over budget before we start.
    • Know our capacity for work comes from past performance.
    • But it also means estimating what we can do, knowing that past performance, and he future demands for work.
Related articles Late Start = Late Finish Eyes Wide Shut - A View of No Estimates All The World's A Random Process Project Risk Management, PMBOK, DoD PMBOK and Edmund Conrow's Book Architecture -Center ERP Systems in the Manufacturing Domain Staying on Plan Means Closed Loop Control Strategy is Not the Same as Operational Effectiveness Estimating Processes in Support of Economic Analysis Qualitative Risk Management and Quantitative Risk Management
Categories: Project Management

Quick Summary of Estimating Advice

Mon, 06/20/2016 - 23:23

There's lots of misinformation going around again in the #NoEstimates community

  • We can't estimate things we've never done before - this is simply not true. There is not much that hasn't been done before in some form. If you truly haven't done the work before, you're probably not the right person to be estimating for those wanting to pay you.¬†
  • Estimates are guesses, because we don't know that the future is - this is a fundamental error,¬†either of commision¬†or¬†omission) on how estimates are made.
  • Just deliver often in small chunk and we won't need to estimate - this of course ignores the need to produce an Estimate To Complete and an Estimate At Completion.
  • Estimates are a waste, we should be coding to generate value for the customer -¬†the¬†customer has a fiduciary¬†need to know how much it will cost to get that value and when that value will be delivered. This is core business. If there is no need to know estimated cost and schedule, the project is likely a de minimis effort, or the customer has enough money to burn to not care about how much and when.
  • Deadlines kill innovation and reduce quality - this is only true of your a really bad planner. All project work is probabilistic. This probabilistic (and statistical) behaviour mandates a plan to manage in the presence of uncertainty. Bout reducible and irreducible uncertainties have specific¬†handling plans. Either¬†margins¬†to protect from the naturally occurring ¬†variances or specific¬†buy down¬†activities to protect against probabilistic occurrences of undesirable outcomes.¬†

Here's the starting point to clarify and debunk those concepts

  • How To Estimate Almost Any Software Deliverable in¬†90 Seconds¬†- this the starting point for learning how to estimate for all software projects. Is it a¬†bigger than a breadbox, or¬†Twenty Questions approach. It's actually a Binary Search approach, that will¬†get you an¬†85%¬†confidence number in 90- seconds or¬†less. No more excuses for not estimating anything, including things you know nothing about - assuming you are a developer with any experience in the domain. If you have no experience in the domain, then you shouldn't be estimating to begin with - go find someone who is.

Here's some more details, once it's been confirmed you have domain experience

  • How Do You Estimate Work That's Never Been Done Before?¬†- This is a common lament in the #Noestimates community.¬†We've never done this before, so how can we¬†possibly¬†estimate how long it will take?¬†Lot's of ways - Reference Classes, Parametric models. Monte Carlo models of activity networks.
  • Let's Stop Guessing and Learn How to Estimate¬†- estimates are NOT guesses. Estimate - it is an approximation of some value for some purpose, even if the data is incomplete, uncertain, or even unstable. Typically the estimate is derived from a statistical source of data - either observed or referenced in some way.
  • How ¬†to Estimate if you really want to¬†(Updated)¬†- the key here¬†is if you want to. There is NO reason to not estimate. Estimates are need to make decisions in presence of uncertainty.¬†
  • How to Estimate Almost Anything if You Really Want To¬† - this starts with¬†what's the¬†coastline¬†of England¬†problem and uses a similar red herring about a hike down the coast of California.

In the end it's simple. Anyone speaking about the difficulties or the waste of estimating is likely on the spend side of the software development equation. Those on the pay side know (or should know) they needed estimates. They can get the estimates from those most qualified to provide them - the developes. Or they can just make them up. Probably better to have a bottom up estimate.

Related articles Humpty Dumpty and #NoEstimates Want To Learn How To Estimate? Let's Stop Guessing and Start Estimating
Categories: Project Management

Software Development Process Improvement Opportunities

Wed, 06/15/2016 - 15:56

 When we hear about all the suggested ways to improve the effectiveness of our development effort, if we're to going work on improvements, let's go where the REAL money is. 

Here's the IT budget for the Federal Government. This is larger than all the IT systems found everywhere else in the world, plus all their custom built IT stuff. This is not the embedded systems. These are business systems.

So if we're going to make improvements in the spend of IT for better value, let's start here.

Screen Shot 2016-06-13 at 1.55.39 PM

 

 

Related articles Estimating and Making Decisions in Presence of Uncertainty Intentional Disregard for Good Engineering Practices? What's in a Domain?
Categories: Project Management

Deadlines Require Time and Care For Success

Tue, 06/14/2016 - 16:10

The latest thread in agile is ...

the continued paradigm of deadline-driven development is killing the benefits that Agile Software Development can bring.

It is suggested by Neil Killick that ...

... using genuine time constraints as a factor in the prioritisation of work rather than as a focus for its execution, the odds of meeting those "deadlines" are actually improved.

Not sure what a genuine time constraint is versus any time constraint. But the conjecture that Executives of software product and service companies always want stuff delivered faster, cheaper and better. Agile principles and methods are believed to be a way to achieve this ignores several fundamental principles of all work and especially software development work.

 All project work has uncertanty. Reducible uncertanty and irreducible uncertanty.

Agile does not remove this uncertanty. Agile is NOT a risk management process. Genuine constraints don't remove this uncertanty., I've spoken many times in the past about how to Manage in the Presence of Uncertainty.

These principles are always in place. More so on Agile projects, where emergent requirements are encouraged, which in turn drive uncertanty further to the right in the Probability Distribution Function of the possible range of durations, costs, and technical performance shortfalls.

When those uncertainties are not considered and handled, any project is going to have an increased chance of being late, over budget, and have technical issues. 

Setting genuine constraints may make this issue visible, but does not remove the risk to the project's probability of success. Only active risk management and the necessary margin can increase this probability.

The only protection for irreducible uncertanty is Margin and the only protection for reducible uncertainty is active risk management. Both of these activities require careful planning and execution of the plan, along with the estimate of the probability of occurrence of a reducible event and the statistical distribution of the naturally occurring variances and the probabilistic impact on the success of the project.

This is the Reason for Planning

It's been suggested I work in a unique domain, where deadlines and need dates are themselves unique. This is False.

No credible business, no matter the size, Doesn't have a need date for the Value produced by the software project. If there was no need date, the developers would show up whenever they wanted after spending whatever they wanted, with whatever they thought the customer needed.

Ignoring the simple time cost of money and the time phased Return of Investment of (Value-Cost)/Cost, any business that intends to stay in business is spending money for software - either developed or purchased - to provide some value to the business. Not having a need date for the production of that Value means the business is ignoring the core principle of retained earnings. Even non-profits and not-for-profit business (and I've worked there as well) have a time value of money economic model.

The End

  • No process can remove the irreducible uncertainties that create risk (naturally occurring variances) of project work - only margin can protect the project from these variances. Schedule margin, cost margin, technical margin.¬†If you're building software with Scrum, add more sprints to cover the margin. Or be prepared to deprecate the¬†needed Capabilities and the Features and Stories that implement those Capabilities.¬†You do know what needed business or mission¬†capabilities¬†will be produced for the money you're¬†spending¬†right?¬†NO? You're on a death march project from day one.¬†Genuine¬†constraints¬†aren't going to do anything for you. Nothing's going to help that project.
  • For reducible uncertainties that create risk (probability of occurrence uncertainties), specific actions need to be taken to reduce the risk from these probabilistic event. This can be¬†buying two, running extra tests on test beds, formal verification and validation, external surveillance‚Ć of the product (DB engineering, security, performance assessments).

So if you're going to produce value for your customer, that value is most always time sensitive other wise it's de minimis value. If it's time sensitive, there is a deadline. If there's a deadline, reducible and irreducible uncertanty and the risk it produces must be handled. 

Risk Management is How Adults Manage Projects - Tim Lister

† The naive notion that scrum teams are self contained and need no external support is only the case when there is little at risk for the resulting code. Cyber security, Database integrity, performance validation, operational integrity are external surveillance roles on any Software Intensive System of Systems. This is called Governance and guided by documents like ISO 12207, ITIL V3.1, COBIT, DoDAF, ToGAF.

Related articles Risk Management is How Adults Manage Projects Essential Reading List for Managing Other People's Money Agile Software Development in the DOD The Art of Systems Architecting Seven Principles of Agile Software Development in the US DOD Deadlines Always Matter
Categories: Project Management

Software Economics

Mon, 06/13/2016 - 19:37

Here's some thoughts on the economics of software development using other people's money, after 3 weeks of working a proposal for a major software intensive system of systems using Agile.

  • With the advent of Agile, the linear spend planning and delivery of capabilities was altered to iterative and incremental spend and delivery planning.
  • Time boxed, drip funding, fixed budget are ¬†funding profiles that might be added to the economic model once they've been verified and validated in practice to provide better approaches to managing funding in the presence of uncertainty.
  • Core business processes are still in effect, no matter the funding profiles
    • Money consumed provides capabilities produced.
    • Capabilities enables value from the use of money.
    • Capability defined by the¬†user¬†through some form of¬†value assessment, not by the provider.
    • Emergent needs can be addressed.
  • When we merge business value with development cost without monetizing that business value, we've lost the ability to make economic decisions.
    • Both the business value and the development cost operate in the presence of uncertainty.
    • This uncertainty is always present.
    • To make those economic decisions, we need to estimate both business value and development cost.
    • There is no way out of this in any credible development environment.
  • Monetized value allows the decision process to use ROI, IRR, Analysis of Alternatives.
  • Without monetized value cost and value decisions are simply¬†made up and are arbitrary.

So to come full circle 

Why Do We Need Estimates?

  • It's not the developers that need the estimates - they take the money and turn that money into value.
    • They should estimate if the needed value can be produced by that money.
    • But if the developers decided they don't need to estimate, then they'll be subject to the whims of management, just like Dilbert.
  • The developers are certainly closed to the work and have the information needed to best contribute to the estimate.
  • Estimates are primarily used to support decisions.
    • Product margin.
    • Cost target for business management.
    • ROI, IRR, AOA.
    • Staffing, release date, launch date - literally and figuratively.
  • Knowing the cost of a product or service produced is a fundamental piece of information needed by the business if they intend to stay in business.

It can't be any clearer than this - if you  don't know what something costs or is going to cost in the future, you can't make a business decision about it's value

When you read estimates are a waste, estimates are non-transferable, estimates are wrong, estimates are temporary think again. Go ask those paying if they need estimates to make decisions for the business. If they don't, then continue to spend your customers money. If they do, they may consider looking for someone who knows the difference between willful ignorance of how to estimate software development and someone who can provide that information needed to stay in business. On our proposal team, this would get you a 2nd place prize in the estimating capabilities contest - which is a one way trip home with weekends off.

Related articles Capabilities Based Planning First Then Requirements Incremental Delivery of Features May Not Be Desirable Quantifying the Value of Information Essential Reading List for Managing Other People's Money Decision Making Without Estimates? Economics of Software Development Risk Management is How Adults Manage Projects Process is King Deadlines Always Matter
Categories: Project Management

Misquotes of Deming

Sat, 06/04/2016 - 14:50

It's common to misquote famous quotes. The #NoEstimates advocates love to use a Deming quote

It is wrong to suppose that if you can‚Äôt measure it, you can‚Äôt manage it ‚Äď a costly myth.

This is used in support of the fallacy that estimates aren't needed to make decisions in the presence of uncertanty. They are for, all the reasons listed in the 100's of blog posts here and other places.

But more important is the use and misuse of quotes without checking on the validity of the quote. This too seems common among those quoting without confirmation, attribution, or establishing the proper domain and context of the quote. It's just sloppy thinking at best and willful ignorance at worst.

I spent the week speaking at the College of Performance Management conference where government and industry come together to work on the issues of cost, schedule, and technical performance management process improvement needed to increase the probability of program success.

This community of program controls, cost analyst, earned value managers and program managers is accountable for providing information to decision makers on enterprise and complex projects and programs. It would be unheard of to make statement that aren't based on well researched background and principles. The antithesis of the rogue agilist currently populating the #NoEstimates community, spending other people's money (which I doubt takes place on anything but de minimis projects) with no consideration for the principles of managerial finance. 

To learn more about the Deming quote start here and check for yourself when you hear or read any quote that doesn't make sense in practice. It's likely wrong, misquoted, misattributed, or taken out of context.

Screen Shot 2016-06-04 at 7.40.56 AM

Related articles Technical Performance Measures Assessing Value Produced By Investments Who's Budget is it Anyway? Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter Software Engineering is a Verb
Categories: Project Management

Memorial Day 2016

Mon, 05/30/2016 - 15:49

Memorialday

If we don't remember those who have died, they died for nothing

From 1775 to Present - 2,852,901

Categories: Project Management

The Fallacy of Beneficial Ignorance

Sat, 05/28/2016 - 01:01

The basis of #Noestimates is that decisions can be made in the presence of uncertainty without having to estimate the impact of those decisions

No Estimates

Here's a research paper that hopefully will put an end to the nonsensical idea of #NoEstimates.

All project work is uncertain. And has been stated here endless times, uncertainty comes in two forms - Reducible (Epistemic) and Irreducible (Aleatory).

Add to that the biases found on all projects - confirmation and optimism are two we encounter all the time. The conjecture - and it is pure conjecture- that decisions can be made when spending other people's money in the presence of uncertainty without estimating the consequences of those decisions is not only conjecture, it's factually false - a Fallacy.

Here's the paper at SSRN. You'll need to create a free account. This version is the pre-publication version, but it's the same paper I downloaded from my account. Read the paper, discover how to reject the notion of #NoEstimates, not only by its ignorance of managerial finance, probabilistic decision making, business governance violations, but foundational mathematics.

So time to learn why estimates are needed to make decisions in the presence of uncertanty, how to make those estimates, and start behaving as adults in the presence of the risk created by this uncertainty as Tim Lister tells us Risk Management is how Adults Manage Projects.

Screen Shot 2016-05-27 at 5.50.13 PM

Related articles What's the Smell of Dysfunction? Making Decisions in the Presence of Uncertainty Making Choices in the Absence of Information Making Conjectures Without Testable Outcomes Estimating and Making Decisions in Presence of Uncertainty Making Decisions In The Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Estimating on Agile Projects

Fri, 05/27/2016 - 03:39

Here's a straightforward approach to estimating on agile projects. This is an example of the estimating profession found on many domains. 

Categories: Project Management

How to Make a Decision in the Presence of Uncertainty

Wed, 05/25/2016 - 23:28

Uncertainty is all around us. In the project world, uncertanty comes in two forms:

  1. Aleatory Uncertainty - the naturally occurring variances due to the underlying statistical processes of the project. These can be schedule variances, cost variances, and technical variances - all driven by a stochastic process with a known or unknown statistical distribution. If you don't know what the distribution is, the Triangle Distribution is a good place to start. For example: The statistical processes of testing our code ranges from 2 to 4 days for a full cyber security scan. Planning on a specific duration has to consider this range and provide the needed margin. Aleatory uncertainty is irreducible. Only margin can protect the project from this uncertainty.
  2. Epistemic Uncertainty - the probability that something will happen in the future. The something we're interested in is usually unfavorable. For example: The probability that the server capacity we have selected will not meet the demands of the user when we go live. Epistemic uncertainty, being probabilistic, can be addressed with redundancy, extra capacity, experiments, surge capacity and other direction actions to buy down the risk that results from this uncertanty before the risk turns into an issue.

When we hear you can make decisions without estimates, this is physically not possible if you accept the fundamental principle that uncertanty is present on all projects. If there is no uncertanty - no aleatory or epistemic uncertainties - then there will be no probabilistic or statistical processes driving the project's outcomes. If that is the case, then decision have no probabilistic or statistical impact and whatever decision you make with the information you have is Deterministic.

So if you want to learn how and why estimating is needed to make decisions in the presence of uncertainty start here:

And then when you hear about a conjecture that decisions can be made without estimating you'll know better, and consider anyone making that conjecture as uninformed about how probabilistic and stochastic processes in the project world actually work - especially when spending other people's money.

 

Categories: Project Management

Quote of the Day

Tue, 05/24/2016 - 16:47

Wise men profit more from fools than fools from wise men; for the wise men shun the mistakes of fools, but fool do not imitate the success of the wise - Cato the Elder

Any conjecture not based on testable principles, independent of personal opinion or anecdotes cannot stand up to the questioning of the wise.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

Book of the Month - IT Project Estimation: A Practical Guide to the Costing of Software

Tue, 05/24/2016 - 04:42

IT Project EstimationEstimating is part of all decision making in the presence of uncertainty. Accuracy and precision are two primary attributes of all estimates.

We all know estimates are hard. But there are lots of hard things in the development of enterprise software. We wouldn't be whining about how hard it is to construct a good First Normal Form database schema, or bullet proof our cyber security front end from attack by the Chinese would we.

So why is estimating a topic that seems to be the whipping boy for software developers these days?

My first inclination is that estimating is not taught very well in the software arts. In engineering schools it is. Estimating is part of all engineering disciplines. One undergraduate and one graduate degree is in physics. Estimating is at the very heart of that discipline. A second graduate degree is in Systems Management - which is a combination of Systems Engineering and Managerial Finance - how to manage the technical processes of engineering programs with the principles of managerial finance, contract law, and probabilistic decision making.

This book comes with a spreadsheet for making the needed estimates to increase the probability of project success. It opens with an important quote that should be a poster on the wall of any shop spending other people's money

For which of you, intending to build a tower, sitteth not down first, and counteth the cost, whether he have sufficient to finish it? Lest haply, after he hath laid the foundation, and is not able to finish it, all the behold it begin to mock him, saying, This man began to build, and was not able to finish - Luke 14:28-30

 

Categories: Project Management

Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics

Mon, 05/23/2016 - 21:26

The on-going discussions that Decisions can be made in the absence of estimates reminds me of this concept.

 

The conjecture that we can manage in the presence of uncertanty without estimating the impacts of our decisions, willfully ignores uncertainties in the present and future that will impact our outcomes, the external governance frameworks of managerial finance, probability and statistics of the processes under management, and regular governance processes and the decision rights of those governance frameworks.

Those decision rights by the way belong to those paying, rarely to those spending. So the decision to estimate or not estimate rarely belongs to the developers spending the business's money.

When the claim that #Noestimates critics say we're simply not being Opened Minded those advocates  want us to accept that everything can be challenged, without any basis for that conjecture. If that were the case, those proforring #Noestimates fit right into those believing the pseudoscience of spending other people's money in the presence of uncertanty.

Thanks to Peter Kretzman for the link to the video.

Related articles Intentional Disregard for Good Engineering Practices? Calculating Value from Software Projects - Estimating is a Risk Reduction Process How to Estimate Any Software Problem Quote of the Day - All Things Project Are Probabilistic Probability and Statistics of Project Work How We Make Decisions is as Important as What We Decide. An Example of Complete Misunderstanding of Project Work Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Quote of the Day

Mon, 05/23/2016 - 02:05

"It is the mark of an instructed mind to rest satisfied with the degree of precision that the nature of the subject admits, and not to seek exactness when only an approximation of the truth is possible." Aristotle 

 

Categories: Project Management

Quote of the Day

Thu, 05/19/2016 - 17:32

Do not deny the classical approach, simply as a reaction, or you will have created another pattern and trapped yourself there.
‚ÄĒ Bruce Lee

Any new innovative or revolutionary suggestion in the software development world, needs to be anchored on the established principles of how to manage the spend of other people's money. If it's your own money, spend as you please - no one cares.

But if you're spending other people's money to produce value in exchange for that money, those providing the money likely have a fiduciary obligation to know something to some level of confidence how much it will cost, when it will be done, and what they'll get for that that cost and time.

To suggest otherwise without a foundation of principles by which this new and innovative idea can be tested is selling snake oil to the uninformed. That approach has worked since the dawn of time - I have the solution to your unnamed ailment, just try this magic elixir and all will be better. 

Categories: Project Management

Learning Through Research

Sun, 05/15/2016 - 16:30

A primary learning process is research. This process is part of all science, engineering, management processes. Here's a starting point for learning how to estimate in the presence of uncertainty on agile projects.

This is the start of a literature search. Anyone making suggestions about making decisions in the presence uncertainty on agile project can start here for establishing the basis of any arguments of how and why that suggestion (conjecture possibly) is based on some set of principles. Not just anecdotal opinion.

Evm+agile estimating from Glen Alleman Related articles Debunking Failure is not an Option Project Risk Management, PMBOK, DoD PMBOK and Edmund Conrow's Book
Categories: Project Management

How to Estimate Any Software Problem

Sun, 05/08/2016 - 20:13

The conjecture of #NoEstimates starts with the first Tweet

No Estimates

This conjectures - (there are) ... ways to make decisions with No Estimates ... is not founded on any principle of business management, microeconomics of decision making, or principles of probability and statistics. It's a fallacy.

Let's start with a simple approach to exploring  for anything?

  • What are we looking for?¬†It says we're looking for An Alternate Way to make¬†decisions¬†- in the presence of uncertanty. Uncertainty of course is present in all software development work¬†both¬†reducible and irreducible¬†uncertainty.
  • How will we recognize it when we encounter it?¬†Any expectations for what we'll¬†find? Any expectations of how to measure if what we¬†found is what we're¬†actually looking for?
  • Once we find it, how can we test that what we found is actually of use to anyone other than us?¬†The use of anecdotes is to collect a sample of One from an Unknown population and consider it representative of as evidence of our hypothesis.

The Hypothesis might well be (if there was one) is ... can we make a decision in the presence of Uncertainty without making an estimate of the impact or outcome of that decision?

Let's put aside for the moment the missing principles of managerial finance, probabilistic decision making, microeconomics of decision making, Real Options, Bayesian decision networks, and other decision making processes used in modern business when spending other people's money. And ask a simple question...

What would be the evidence that we could make decisions in the presence of uncertanty without estimating the impacts and outcomes of those decisions? 

The Myths of No Estimates and the busting of them is one purpose of this blog post. Here are some books and papers that can provide you with all the tools needed to learn to estimate in the presence of uncertainty. As well these books and papers can show you the snake oil salesman's fallacy that estimates are hard, are a waste, and aren't needed to make decisions in the presence of uncertainty. 

Reading Materials

Before listening to any conjecture that estimates aren't needed to make decisions in the presence of Uncertainty for software development, please read these books. Ask the person making those conjectures if they have read the books. Ask to see the marked up, sticky noted, tabbed copy of the book and the notes they made from the content. If not, walk away. They are not informed by the principles of spending other people's money.

Guesstimation

Before we start, let's look with the notion of estimation. A Guess is uninformed by experience, skill, or data. An estimate is.

This is a simple book that will show how to estimate most everything. Start here. Read the entire book,. Learn how to think as an estimator.

Take that experience and start making estimates for software projects. Then and only then ask yourself why do people claim estimates are wrong, why is estimating hard. And you'll know the answer - they have no experience, they have no skill, they have no knowledge of how estimates can be made. Then you'll know. It's not that estimates  that are smell of dysfunction, it's the unskilled, inexperienced, untrained, uninformed, unknowledge people making those unsubstantiated claims. 

Hard Fact Dangerous

The next learning opportunity is to realize how much nonsense is floating around about not estimating. Here's the start for that understanding.

Managing a business profitably is always hard work. There are intense pressures,¬†incomplete information about what‚Äôs happening in the marketplace and an army of¬†consultants, advisors and others who come along with new ideas every day. Under¬†these conditions, it isn‚Äôt surprising managers sometimes fall victim to hype about¬†‚Äúmiracle‚ÄĚ cures for management challenges or simply adopt the ‚Äúbest practices‚ÄĚ of other¬†successful companies. The result is sometimes poor-quality decisions are made which¬†end up wasting time and money which are badly needed elsewhere.

This book was handed out by Jeff Sutherland at the State of Agile conference as an indication of how agile has come to represent sloppy thinking on behalf of many of its advocates. 

How Many Licks

Here's a start of actually estimating in a credible manner, using tools available to anyone. 

Start here to learn how simple it is to estimate things. Things you have never seen before. Things you have never done before Using Enrico Fermi’s theory of approximation.

The Fermi estimate, or order estimation is an estimation problem, teaches dimensional analysis, approximation, using a back-of-the-envelope calculation. The estimation technique, named after physicist Enrico Fermi, makes good approximate calculations with little or no actual data. Fermi problems typically involve making justified guesses about quantities and their variance or lower and upper bounds.

There is no excuse for not learning how to apply this approach to software development.

Economics of Itertaive SW Development

With the basic concept that estimates are straightforward, this book shows the economics of managing iterative development. Here estimates are part of planning and measuring progress.

The book speaks to assessing the technical viability of the system and the overall cost to achieve that technical viability.

These are core business processes for the success of any investment. And of course based on making decisions in the presence of uncertainty.

Estimarting SW Intensive Systems

Now that we've established with the above sources there are conjectures without basis, nonsense statements like estimates are the smell of dysfunction without ever stating what the dysfunction is or what could possibly be causing the dysfunction, here's the place to start for serious estimating for software intensive systems.

A de minimis software project rarely benefits from estimates. Willfully bad management rarely benefits from learning how to estimate. If you customer has no real value at risk, of has no real concern about showing up on time to start accruing the business value in exchange for the cost to produce that value, then estimates are unlikely to be needed.

Agile Estimating and Planning

This is a seminal book on estimating. It provides the background and the practices needed to estimate Agile projects.

Mike shows why traditional processes fail and why agile approaches work. It's standard Feature Story breakdown but with the reasoning behind the processes.

SW Estimating

This is the other seminal book on estimating.

Between these two books, you'll find need to know to make credible estimates for the development of software using Agile. The book claiming to show hwo to improve your project performance by 10X is so riddled full of holes, it's worthless. Don't waste your money on it. For the same price as that book, you can own both Mike's and Steve's books with field proven examples rather than fictitious anecdotes of bad management practices.

Probability methods for cost uncertainty analysis

All project work is probabilistic. Some probabilities are event based, some are statistically based. Cost is always a driving consideration for how products are built, delivered, and sustained. A critical success factor for all software project work is cost and the associated schedule. Showing up on or near the needed time at or near the planned cost is simple business. Anyone saying cost is not important is not accountable for the business success of the development. Ignore them, they have no seat at the business management table.

If we come out late with the product we lose revenue needed to meet the business plan. If we spend more than planned, we erode profit and fail to meet the business plan.

Both these variables - cost and schedule - along the the needed technical performance to meet the expected acceptance of the product are probabilistic. Estimates are needed to inform the decision makers of the Probability of Success of the product.

 Estimating SW Costs

Setting the date before the project is planned is the oldest root cause of project failure. Not having some sense of the scope of work, the effort needed to produce that scope, and the capacity for the development to produce the needed features for that scope is in the same class of failure modes. 

Ignoring the need to have estimates of effort, time, and cost is not only bad project development it is bad business management.

Any suggestion that decisions can be made in the presence of project uncertanty without estimates willfully ignores these principles. 

Large Scale Scrum

Large Scale Scrum (Less) is a framework for scaling Scrum to the enterprise. In the Less method, estimates are part of the Product Backlog Refinement. This process:

  • Split big items,
  • Does a light weight analysis for basic understanding,
  • Estimates the items,
  • Identifies strongly related items to reveal shared work, common work, or coordinated work.
Agile IT Org

Agile at Scale is not the same as small agile teams. Governance drives processes in Agile at Scale. Governance can be ignored or even flaunted for small self contained teams. Organizing for responsiveness to external business drivers at scale means additional cost must be absorbed to govern in the presence of these externalities. 

Agile at Scale also means dealing with architecture - technical architecture,process architecture, business architecture. Managing in the presence of all these uncertainties mandates we estimate the impact of these decisions. At scale without estimating the work processes turn into chaos.

Agile Project Management

This is one of the books that started it all. In Highsmith's books he calls out explicitly the need for estimating and some of the steps to do it.  

Any enterprise agile development operating inside a corporate governance process requires knowing something about the outcomes of the work effort. The cost, the expected delivery date, and the expected business value produce for the cost. The time cost of money is a foundation of business decision making.

O those paying you have no need to know the time cost of money, how much it will cost, what the possible business value will be and when you might be done, then estimating is not needed.

How to Measure Anyhting

Anyone suggesting you can't estimate must read this book to learn that conjecture is false - patently false - and learn how to actually make estimates of anything. 

What I've found is when there are statements like all estimates are wrong, we can't estimate, estimates are misused is that those making those conjectures aren't actually informed how good estimates are made. 

So instead of learning about estimates, they fall into the fallacy of #Noestimates.

Forecasting and Simulating

This is another book that if the #Noestimates advocates had read on day one of their exploring they would have found the destination and stopped spouting all the nonsense about the smell of dysfunction.

Troy combines all of my favorite topics - mathematics of project management, monte carlo simulation - the actual monte carlo simulation, not the bogus sampling of past performance advocated by some No estimator's, and a logical, clear, and concise approach to making estimates in the presence of uncertanty to inform the decision makers when spending their money.

Facts and Fallacies of SW

There are many fallacies in the software development world. Many of these fallacies go unchecked, unaddressed, unchallenged. 

Here's where to start learning about the fallacies and their facts. 

This is a similar issue with #Noestimates. This starts with the missing principle by which a decision can be made in the presence of uncertanty without estimating. Attempts to question these missing principles, results in further fallacies being put forward, along with labeling anyone probing further for the missing principle as aggressive, rude.

Software Cost Estimating with COCOMO II

 This is the basis of software estimating. It's been updated for agile.

Read it first, then read the agile updates. Learn how to use numbers, models, evidence, tools to estimate in the presence of uncertanty.

This is how non-trivial projects are managed. Anyone suggesting this is olde school hasn't done their homework to earn the position to be critical of the contents.

Goverance

Spending other people's money involves governance of those decisions.

Governance by its definition is about decision rights

Who gets to the decide what is needed, when it is needed, how much it could cost (affordability). These decision rights are almost alwasy assigned to those paying for the outcomes.

The #NoEstimates advocates would have those decision rights transferred to those who spend, by suggesting estimates are a waste. Without stating who they are waste to. It is very unlikely they are a waste to those provided the funds that enable the #NoEstimates advocates to produce the software needed by those providing the funds.

It's illogical to invert this relationship between those paying and those spending. 

Forecasting Methods

Now we're into the heavy lifting of estimating. Yes estimating is forecasting. Forecasting is an integral part of the decision making activities of management. The organization establishes goals and objectives to produce outcomes from its decisions. The need to forecast (estimate future outcomes) is based on management's need to decrease its dependence on chance and become more predictive  in dealing with the uncertainty it encounters.

We're now down to the core processes of making decisions in the presence of uncertainty. This is how business operates. Anyone conjecturing that decisions can be made in the presence of uncertanty without estimating - forecasting is estimating outcomes in the future - needs to stop and learn more.

Learn how business actually works. Not just assume that some who make an unsubstantiated statement about estimates are the smell of dysfunction has any credibility when spending other people's money. It's time to call BS on the notion of #NoEstmates.

 Along with these books here's a collection of papers and articles showing how to estimate on agile development projects and how to avoid the Snake Oil Sales Pitch of #NoEstimates

Evm+agile estimating from Glen Alleman So stop listening to the fallacy that estimates aren't needed to make decisions. And start learning to estimate and be a proper steward of your customers money. Screen Shot 2016-05-08 at 9.20.50 AM

 Related articles

Risk Management is How Adults Manage Projects Making Choices in the Absence of Information Decision Analysis and Software Project Management Risk Management is Project Management for Adults Economics of Software Development How Not To Make Decisions Using Bad Estimates Complex, Complexity, Complicated Software Engineering is a Verb Making Conjectures Without Testable Outcomes
Categories: Project Management

Quote of the Day

Wed, 05/04/2016 - 14:03

Predictions are always difficult - especially about the future ‚Äē Niels Bohr
‚Äē¬†Neandertal's¬†Guide to Cost Estimating, Naval Aviation Systems

This is a quote often used by those conjecturing that estimating is a waste. The quote is true of course. Making predictions about the future is difficult. But that has nothing to do with the need for predictions and the estimates that support them.  When making decisions in the presence of uncertainty about some outcome in the future - this is the basis of Microeconomics of decision making.

Categories: Project Management