Home > management > OMITTED ACTIVITIES!


The best book I’ve read (so far) on software estimation is Steve McConnell’s “Software Estimation: Demystifying the Black Art“. Steve is one of the most pragmatic technical authors I know. His whole portfolio of books is worth delving into.

Prior to describing many practical and “doable” estimation practices, Steve presents a dauntingly depressive list of estimation error sources:

  • Unstable requirements
  • Unfounded optimism
  • Subjectivity and bias
  • Unfamiliar application domain area
  • Unfamiliar technology area
  • Incorrect conversion from estimated time to project time (for example, assuming the project team will focus on the project eight hours per day, five days per week)
  • Misunderstanding of statistical concepts (especially adding together a set of “best case” estimates or a set of “worst case” estimates)
  • Budgeting processes that undermine effective estimation (especially those that require final budget approval in the wide part of the Cone of Uncertainty)
  • Having an accurate size estimate, but introducing errors when converting the size estimate to an effort estimate
  • Having accurate size and effort estimates, but introducing errors when converting those to a schedule estimate
  • Overstated savings from new development tools or methods
  • Simplification of the estimate as it’s reported up layers of management, fed into the budgeting process, and so on

But wait! We’re not done. That last screaming bullet, OMITTED ACTIVITIES!, needs some elaboration:

  • Glue code needed to use third-party or open-source software
  • Ramp-up time for new team members
  • Mentoring of new team members
  • Management coordination/manager meetings
  • Requirements clarifications
  • Maintaining the scripts required to run the daily build
  • Participation in technical reviews
  • Integration work
  • Processing change requests
  • Attendance at change-control/triage meetings
  • Maintenance work on previous systems during the project
  • Performance tuning
  • Administrative work related to defect tracking
  • Learning new development tools
  • Answering questions from testers
  • Input to user documentation and review of user documentation
  • Review of technical documentation
  • Reviewing plans, estimates, architecture, detailed designs, stage plans, code, test cases
  • Vacations
  • Company meetings
  • Holidays
  • Sick days
  • Weekends
  • Troubleshooting hardware and software problems

It’s no freakin’ wonder that the vast majority of software-intensive projects are underestimated, no? To add insult to injury, the unspoken pressure from the “upper layers” to underestimate the activities that ARE actually included in a project plan seals the deal for “perceived” future failure, no? It’s also no wonder that after a few years, good technical people who feel that hands-on creative work is their true calling start agonizing over whether to get the hell out of such a failure-inducing system and make the move on up into the world of politics, one-upsmanship, feigned collaboration, dubious accomplishment, and strategic self-censorship. Bummer for those people and the orgs they dwell in. Bummer for “the whole“.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: