| It depends? For high-caliber projects (ie: some kind of engineering, regulated, or mission-critical software) I'll go with the ISO standard processes for software requirements gathering and estimation. For SME-level businesses it depends on whether it's a new project or changing requirements to an existing one. In the first case I'll do some light-weight analysis using event storming to map out the problem/process the users are facing/using. This will give me an idea of the scope of the problem domain (ie: how big is the problem?). This gives me enough information to make a Scientific Wild Ass Guess. I can only estimate at the granularity of weeks/months at this point. Typically project estimates will be refined as the project moves along in increments. In the latter case I have more information at the start. I can give estimates in three intervals: optimal, realistic, pessimistic. I include a confidence ratio in those interval estimates. The intervals reflect my understanding of the scope of the change and how much work it may end up being. The ratio represents my understanding of what I know to be true: if there are a lot of unknowns then my confidence in my estimate isn't high. This lets my stakeholders estimate what they think the likely outcome will be and determine what they'd be comfortable with. And I always make sure, regardless of which approach is used, that no estimate is a binding promise or commitment. It's a forecast of a possible outcome. My teams and I are still able to take on release deadlines and ship dates but I work those out separately from the estimate: how to ship releases and schedule them is team and industry dependent... but that's how I estimate things in general. |