How Long Will It Take – Part II

This is a follow up post to How Long Will It Take.   I often read that we need to know the “all in cost” before embarking on an initiative.  I’m not sure at what level this rule applies at i.e. the program, product or feature level etc etc. I do however disagree with that position.  I agree that sometimes its needed for decision making re how valuable are your estimates.

Over a decade ago, I was tasked with the programming language/technology platform conversion of a large supply chain system.  It was a change we needed to make in order to remain relevant and stay in business.  Both the platform and language were brand new to all of us and we had very little knowledge as to what the conversion would really entail for this complex system.  Yet this was something we just had to do or we’d be out of business, remember?

I was asked to estimate how long it would take to complete this assignment and I tried my best (with a lot of preliminary research, long discussions with the company that was retiring the language/platform and searches for other companies who were doing the same thing) but at the end of the day the upper bound of my estimate range was still too low.  I will accept that I could have possibly tried harder or used better estimating methods but given how much was not known, I question how valuable the estimates would have been anyway.  Would they have really reduced uncertainty? Would the reasonable uncertainty range have provided much value?  Did we need an estimate to decide to port the solution suite?  I daresay that even if I had come in under, it would have been a result of luck or pushing the team to the brink and not the estimating procedure (but no one makes their teams make sure they come in at the estimate, right?)

In full disclosure, several months into the conversion, we did become good at projecting how long things would take.  But this was a result of a ton of experimentation and learning that we had acquired after a couple of months of working through things.  We now had historical data and experience that we could reference when asked “how long”. Based on my experience, it seems quite obvious that we often need to experiment and learn first and then and only then can we attempt to estimate effectively (if we still need too).  It would seem that there are those are uncomfortable with the notion of getting paid to learn or discover.  I think this gets to the heart of some of the debate surrounding #NoEstimates i.e. a disagreement about the nature of the work we do or how much do we really know at the onset.  I, based on my experience, believe that learning and discovery reside at the core of product development.  It’s knowledge work.  Maybe that will change with time, we’ll see.

Advertisements

About Ebenezer

culture hack. contrarian. change artiste. speaker. writer. silo-connector. entrepreneur. totally human. ff at your own risk. :-)
This entry was posted in Software Development and tagged , , , . Bookmark the permalink.

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