Underestimation is Underestimated (a.k.a. Overestimation is Overestimated)

Sometimes it seems like we have an underestimation gene embedded really deep in our cognition but for some “obvious” reason (e.g. underestimation! :) most manager will rather “fight” overestimation and *not* underestimation.

Disclaimer: I have originally estimated this post will take ~33 min but it took me ~240% more time… (this is why I prefer to tweet lately ;)

Six annoying facts about our (/homo sapiens) planning or estimation “skills”:

• We are basically optimistic and have strong desire to please
• We tend to have incomplete recall of previous experience
• We tend to have focus bias when estimating e.g. estimating only the coding phase estimations which is only ~14-37% of the required work
• We tend to postpone what we can a.k.a. “The Student Syndrome”  (Eliyahu M. Goldratt, Critical Chain)
• “It always takes longer than you expect, even when you take into account Hofstadter’s Law” (Douglas Hofstadter, Godel, Escher, Bach: An Eternal Golden Braid)
• We tend to underestimate task completion times – a.k.a. The planning fallacy

Overestimation is Overestimated

“The developers say that this project will take 6 months… I think there’s some padding in their estimates and some fat that can be squeezed out of them…we also need to instill a sense of urgency in the development team… so I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will deliver in the 6 months they originally estimated” (Does this ring *any* bell???)

Four reasons on managers tendency to “fight” overestimations:

• Underestimation (see above :) | “The feature estimation seems bloated” | “Isn’t it 20 min work?” | “Just add another index to the %$^&ing table?” | “It is only one more button…”
• Unreasonable time constraint | “We need this feature yesterday” | “Nothing is impossible for the man who doesn’t have to do it himself” (A. H. Weiler)
• True belief that Parkinson’s “Law” is really a law – “Work expands so as to fill the time available for its completion”
• “The Student Syndrome”  (see above)

So… if feature estimation seems bloated, managers and other project stakeholders fear that Parkinson’s Law and the Student Syndrome would kick in and therefore consciously squeeze the estimates to try to control it (a.k.a. “The Parkinson’s Squeeze”) and when we squeeze where it isn’t needed or was squeezed already, it immediately lead to… UNDERESTIMATION (!!!)

Underestimation is Underestimated

Underestimation creates numerous problems – some obvious, some not so obvious.

• Reduced effectiveness of project plans – Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work. If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems but numerous studies have found that software estimates are often inaccurate by 100% or more (see above). When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.
• Statistically reduced chance of on-time completion – Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.
• Poor technical foundation leads to worse-than-nominal results. A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take much longer than it would have taken with an accurate estimate.
• Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project… below are some examples when the important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals, these extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately
  • More status meetings with upper management to discuss how to get the project back on track
  • Frequent re-estimation, late in the project, to determine just when the project will be completed.
  • Apologizing to key customers for missing delivery dates (including attending meetings with those customers).
  • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready on time, the software itself could be used, and no interim release would be necessary.
  • More discussions about which requirements absolutely must be added because the project has been underway so long.
  • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the schedule pressure.

Tip of the day
Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through control, tracking and *mentoring* but not by bias.

****************************************

More related posts (a.k.a. people who read this post also read these posts)

• Software projects anxiety
• The Stockdale Paradox the Pessimistic Developer paradigm
• In Broken Images
• The Dunning Kruger Effect
• The Cone of Uncertainty in Pastel

“The further a project progressed, the more accurate the estimates for the remaining effort and time became”

Make sense?
 

“The British merchant ship Madagascar set sail from Melbourne in August 1853, headed for London and carrying 60,000 ounces of gold dust. – She was never seen again…” (http://www.futilitycloset.com/2008/01/29/overdue/)

Well… Saying “no more gold dust” is the only way I know to close a software release on-time…

P.S. Did you noticed that the Mona Lisa has no eyebrows. (http://www.futilitycloset.com/2008/02/12/trivium-16/)

• Start with the mother of all lists to store your Product Manager wish list– We use eScrum Product-Backlog to store our work-items
• Prioritized them – We use 0-Yesterday; 1-Must; 2-Important; 3-Nice-to-Have and 4-”Forget-About-It”… ;-)
• Get relative estimations on all items
  • Granularity is the bronze-bullet for time estimations – Strive to the finest grained possible in reasonable time-frame  e.g. We usually aim for 2-5 days granularity in 2-3 days of time-boxed-estimation-period since the finest granularity in planning without reasonable time-box might take twice the time of doing the planned work (a.k.a. The Estimation Paradox)
  • Experience can turn your bronze bullet into silver one (ye ye, a silver one) – Relative estimation is calculated relatively upon a common scale of known work items from the team history e.g. We use Scrum “Story Points” and constantly measure the team velocity for time estimation adjustments
  • Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 etc.) can be used to “embed” the complexity and risk of rough (with insufficient drilldown) estimations e.g. if your estimation granularity for specific task reach ~40 days then your pragmatic estimation should be around 55 days (= the closest Fibonacci sequence) since it is reasonable to believe your (insufficient) granularity conceals risk, complexity and unknowns issues which requires Fibonacci-like-”buffering”
  • Strive to synchronize your time estimation techniques into very simple one – different time estimation conventions in the same development team is the 2nd reason for time delays. (I will give 0.95$ grant if you can guess what the 1st reason)
  • I know I am different but personally, I do prefer to have “pragmatic hours” vs. the normal Agile “ideal hours” and to start the project when 1 “Story Point” =  1 “Pragmatic Day” so long everyone understand this will change as soon as you start the project and then you need to return to velocity tracking to calculate the end
  • Don’t be naïve (a.k.a. “Ideal  Days”) with two known flavors:
    • Optimistic time estimations,  assuming 24*7 of concentrated programming ability with no outside interference (a.k.a. no such thing)
    • “Stupid” hand-waiving time estimations a.k.a. It is only 10 min to code this (but ~5 days to Integrate, Review, Design, Test, Schema and DAL changes, I18N support, Styling etc.)
• Get the rough project estimation = Sum of all product backlog story points / 22 (work days in month) / Number of relevant people
  • Usually this calculation will show you don’t have enough time for the project (even without project dependencies buffer which can be added later)
  • Start the “Tradeoff Game” – Try to cut items (content) based on the relative ROI
  • Revalidate your priorities since they will be the main tool (beside dependencies) for creating the project work plan.

As I see it, estimating software projects in a realistic time-frame is a statistic prediction of chaotic, time-delay-series of events and will never be straightforward nor easy so you can only do your best in the estimation and then track the project as it goes and make the needed adaptation on the way upon crystal clear project priorities.

Good Luck!

2019-1972=47 (!!!)

Someone wise once gave this as a metaphorical example for a common engineers disorder, he called experience-anxiety-disorder, claiming that NASA stopped sending manned missions to the moon since they now know much more about the complexity and risk with doing this.

During the early seventies, it was a nice, naive working implementation but when NASA engineers started thinking about the next release they have built a five-decades-project-plan simply because they considered all the technological experience they have gained into large complexity buffers.

The Moral Lesson
Keep-it-simple can-do-approach and don’t over-complicate things with the long-tail-little-details when not needed or the project will take 5 decades to finish.

How do you know you are have an experience-anxiety-disorder?
If someone ask you to add a button to change the database schema and this make you feel a mixture of fear, apprehension, heart palpitations, nausea, chest pain, shortness of breath and headache.

What to do?
Sit down and relax, drink a cup of water and then add the damn button!

Last Long-Tail-Detail
Well… I don’t want to ruin this lovely moral lesson with the long-tail-little-detail but the real facts behind this 47 years gap were politics and money (as always) and not that NASA engineers got a severe experience-anxiety-disorder.

Google Trends (a.k.a. my experiment – part IV – Almost forgot…)

• Betty Casey
  
• Most Haunted Life
  
• Piercing & Tattoos
  
• Madonna
  
• World War III (…)
  

1. Release scoping start with marketing high-level-copy-paste-from-last-year-marketing-presentations MRD in ~1 month delay
2. 1 month of quick lets-write-all-the-features-we-can PRD – This is also the last time you hear from the product manager until the next milestone-demo-crisis.
3. High level design for a couple of weeks which sum-up to a Very Rough Time Guesstimate a.k.a. VeRTiGo
4. Release time-frame is set ~1 year ahead with the needed VeRTiGo “squeezing” and high level time-frame is determined:
   • 2 months of the waste above and last release leftover
   • 1-2 months of Planning (functional and technical design)
   • 4-5 months of Development – with ~3 Major Milestones
   • 3 months of QA & stabilization
   • 1 month of Project Buffer
5. Very soon the development teams are scattered like lonely wolfs – everyone for himself until the next integration or major milestones months away.
6. First milestone is ending with:
   • 20% of the content is really Done a.k.a. “Even a Blind Chicken Finds a Kernel of Corn Now and Then”
   • 50% is “done” with dirty bugy code, low quality, performance issues with missing or wrong functionality
   • 30% is just not ready
7. Developers and low level management remind themselves yet again to put more buffers…
8. The PMO suggest (in relax and trusting tone) to postpone the milestone or remove content.
9. Management doesn’t get in panic (they have seen it before ;-) and decide not to decide: “Let’s see if we can cut the drawback in the next Milestone” a.k.a. The classic do {} while(timeRemaining > Last Milestone)
10. Next milestone has much more content and the pressure builds up… until the last milestone blaming game which usually ends up with ~2 month delay and half of the planned content.

Checkmate

Almost a month ago, I have moved to my own hosted blog due to google blogger outage.

Last week (September 3rd ~00:00), I was visiting BlogCatalog and I got the Internet Service Outage-Lie-of-the-Day: “Database Error – We’re sorry, but our database servers are currently overloaded. Please enjoy a cup of coffee and then try refreshing this page – Blog Catalog” [BlogCatalog Outage September 3rd - 2007] … so I followed the site recommendation and I have enjoyed a great cup of Italian coffee but I was very sorry to see that it didn’t helped the BlogCatalog database to recover…

These days, we are working intensively on the last sprint goals; One of the goals was to finish the architectural design of our unique internet service.

So… Yesterday we where guesstimating (until the very late hours of the night) on the scale needed for this service and started mapping the IT topology, Database implementation and software back-end options that are viable to support it.

I have a lot to say on the process, technology challenges and options for my future posts and I can sum it up now saying: We all hope that by taking the right decisions when reaching a critical-architectural-junction these days, we will be able to enjoy a good cup of Italian coffee while our databases are down for maintenance… but we also know that simple risk management on our guesstimates is also to be prepared for rainy days with a good enough Internet Service Outage-Lie-of-the-Day ;-)

…Then came Scrum by “Natural Selection”:

“It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change” – Charles Darwin’s Origin of Species (1859)

…So I have evolved by Natural Selection to Agile and I can’t really go back to over-planned fantasy Gantt charts that try to capture every feature in advance and predict we will finish the project exactly in 666 days …

Why “Agile”?
For using all the right buzzwords e.g. Flexibility; Transparency; Short-term predictability; Long term vision ;-)

Why “Scrum“?
Scrum provides the mechanism for making the people and process problems apparent so they can be solved – It encompasses almost any good engineering technique; very simple, not overly prescriptive and relatively small set of interrelated practices and rules which can be learned quickly and is able to produce productivity gains almost immediately.

Why not???
The main reason as I see it now, is that it is extremely simple but very hard to implement successfully* – Mainly because short iteration cycles, rapid changes and transparency brings project management headache and programmer life to extreme optimization while traditional development processes (e.g. waterfall) give you the misleading euphoria** for very long time-frames (e.g. ~666 days in the above example ;-) inside the traditional project lifecycle

e.g. Transparency forces accountability, responsibility, prioritization discussions, trade-offs, and often scope reduction. Scrum requires that managers behave differently than in the past. Instead of reviewing status reports, managers should attend Sprint reviews and retrospectives. Instead of waiting for team members to prepare and present updates, management should go to the project room and see the project’s task board and burn down chart.

Scrum isn’t a silver bullet* but a simple yet powerful encapsulation of Peopleware mindset, project management patterns and development best practices which can put you on a good starting point when you face the software challenge…

—————————-
* Friendly reminder: no silver bullet in successful software management
** Although I did see few cases where a mixture of skilled project management & legendary engineers have managed to bypass that inherent misleading euphoria while allegedly practicing traditional development process but my claim is that if you look very closely they were actually practicing 90% scrum without even knowing it…

A project manager is a professional* in the field of project management.

A project manager’s main duty is to ensure the success of a project by minimizing risk throughout the lifetime of the project.
This is done through a variety of methods, both formal and informal**. A project manager will usually have to ask penetrating** questions, detect unstated** assumptions, and resolve interpersonal conflicts**, as well as use more systematic management skills.

According to Wikipedia statistics: 69% of project failures*** are due to lack and/or improper implementation of project management methodologies.

I didn’t have the pleasure of being a project manager but I did see some good project manager implementations and this is my recommendation:

Risk Management – Identifying, managing and mitigating project risk

Issues Management – Identifying, tracking managing and resolving project issues

Reporting – Proactively disseminating project information to all stakeholder s(a good web based project dashboard will do the trick)

Quality Management

Scope Management – Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management

Forecasting project trends – Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable

Tracking – Managing the overall work-plan to ensure work is assigned and completed on time and within budget

Monitor resources (e.g. allocation, movement, skill matrix, roles and responsibilities)

Define Development Methodology

Managing integrations & dependencies (documentation, shared infrastructure etc.)

Configuration Management

Standardization, rationalization and training of processes & procedures (e.g. customer escalations & patches, customer enhancement request, beta or EA plans etc.)

Manage projects postmortem reviews

There are many things to be said on the project manger role and I know god is in the details Kalish but I was told that my blog posts should be much shorter so I will end it here and I reserve the right to post about it again if needed… (e.g. Scrum-Master vs. PMO post will come real soon)

Good Luck Yonit! ;-)

————————————————————————-
* The term “Professional” should imply that this role isn’t trivial or intuitive as it might sounds or implemented in many organizations

** All the ‘bold**’ words should have “rang the complexity bell” – it will never be easy (or straight forward) and will require a bundle of emotional intelligence

*** When according to the same statistics 90% of projects do not meet time/cost/quality targets.

I will argue that pareto principle conceals one of the most important princples in software (and not only in software) management – Don’t try to do more. Just do more of the right things!

exempli gratia

* Don’t invest too your time in dark software corners since the same principle will catch you with investing 80% of your force with only 20% value (e.g. What will happen if someone disconnect the database network cable 1 minute before DST transition… etc.)

* Don’t over design since you will bump into the 80% investment for only 20% value again – Don’t drill the holes for air-condition system before you have one, since you might find yourself a bunch of holes in the wall…

* While planning, always ask yourself if you can do more for less and try to find that thin-gray-line that cross the 21% effort for the 81% value* - try to identify how to invest minimal effort (~20%) to create enough (~80%) business value.

* In performance tuning you want to find the silver bullet that with minimal effort (let’s say 20%) solve 80% of your issues (a.k.a. low hanging fruits)

* Workforce wise – Jack Welch’s vitality model has been described as a “20-70-10″ system. The “top 20″ percent of the workforce is most productive, and 70% (the “vital 70″) work adequately. The other 10% (“bottom 10″) are non-producers and should be fired. Rank-and-yank ideologues credit Welch’s rank-and-yank system with a 28-fold increase in earnings (and a 5-fold increase in revenue) at GE between 1981 and 2001 – Obviously, this is a tremendously competitive model of organization and all criticisms of both the morality and (in)effectiveness of such a Dog Eat Dog method of social cohesion apply but as a manager you must take this in mind since reality and statistics (law of large numbers) do show that the “top 20″ percent of the workforce is most productive and is doing 80% of the work…

I would even dare claiming that, perfectionism is a strong indication for weak leadership!

——————————————–
* Note: I was told that everyone knows this principle but the question is how to do it… so my tip (and I promise to post more around this dilemma) is to handle this with-in the scoping of the feature or module; efficient scoping should get very fast to ROI (look for the items with low ROI) and risk analysis (look for the items in high risk and try to understand where the risk come from) and soon after the tradeoff discussion which is the perfect time to take the hard “cutting” decisions and for doing this you must have someone in the room with deep customer understanding; e.g. In most systems it is very “easy” to cut enterprise-readiness features to simplify development (I18N, Security, Upgrade, Scalability, High Availability, Distribution, Monitoring etc.) and many of those features can be added later if needed with no real overhead (warning: you must know what you are doing to make it work so don’t try this at home if you don’t have professionals with you);