Home > management > OMITTED ACTIVITIES!

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
  • OMITTED ACTIVITIES!

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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 438 other followers

%d bloggers like this: