Don't give estimates without doing a full analysis of the effort involved in a project.  Ideally get others with similar experience to do estimates in parallel to yourself and average them.  Many times in your career your boss or a customer will ask you to give a ballpark estimate.  A simple answer is this:

Sorry, I need to see the detail of what's required before I can estimate how long it will take.

Invariably the reply will be:

“Look we won't hold you to it. We just want a rough idea of how long it will take..”

If you tell the customer that it might take about six months but you need to do further analysis, they will jot down a delivery date in six months time in their calendar and send an invitation for a demonstration to their CEO.  And when you do your analysis that shows the project will take ten months, the customer will hire another company to do the work.

Likewise, don't ever put examples of what could be on the screen in wireframes or prototypes even if it is clearly marked “indicative only”.  The customer will expect to see that exact functionality on the screen.  Best to make sure the wireframe reflects exactly what what's going to be developed.  

All documents which refer to features that are not going to be delivered should be considered unfinished and can be rejected by the development team.  The risk of leaving them in place is that the customer will raise many bugs against functionality that isn't in scope.

blog comments powered by Disqus