Tuesday, July 17, 2007

Managing user expectations

Managing user expectations is really important skill at every level of your career.

At the beginning of a career, you will most likely to answer the ultimate question of
"How long will it take this to finish ?" type of questions. Your manager will ask this to you.

Later as a consultant you will need to answer same question to clients, or as a manager you will need to come up with an answer for your senior manager.

As an entrepreneur you will need to answer this crucial question for cost estimation and bidding.


How long will it take? and by what percent will it be finished?
Should i put an beta version out and improve it as customers use it?
or wait for an stable 1.0 release?

At the root of all these questions lies the expectation management.

Here are some tips i have been employing when i need to answer how long it will take?

  • Try to judge from previous similar experience, if you wrote down your previous work allocation via time sheets on the average you know how long it will take
  • Do a quick POC type development which will not take more than a few days if possible
  • Do prototyping of important use cases and features, (important being defined by the customer) and try to estimate from that knowledge
  • If there are external stakeholders you can't control, estimate with relativity of their work. i.e It should take no more than a week, after we receive design templates from XYZ.
  • If possible, Slice the project to little periods, try to keep quality, time constant and vary the features. i.e We will work on these features for a month. We may not finish all features but we will keep our quality metrics to this level. If you are not satisfied with our work, you can always cancel the contract.
Note that the last strategy is not for fixed price projects. But it works because contractor will work honest to get the remaining big portion of the project. It shields the bidder from excessive unpaid change requests. And you can morph to fixed price later, after unknowns are eliminated.

Also last one has the nice feature of "fail fast". If a project is doomed to fail, it will fail in the first one little slice..

And during project implementation:
  • Don't present the work you are doing as too easy or too hard. In other words, communicate clearly.
  • Don't ever demo a feature complete UI early, because users will expect much more complex screens at the end. This is physiological. Instead show some cool features and build some excitement.
  • Always safe estimate a little more than it will take, this way you will always finish before time and earn some credits.
  • Never overestimate with a huge margin, next time they will not believe and your estimations will be halved by customer or manager. You will lose credibility once and for all.

What are your suggestions for estimating how long it will take?

No comments: