On the other side there are unconscious assumptions too. Sometimes our clients are so sure something has to work “their way” that they don’t even mension that. And we end up in a similar situation. That is even harder to control than our own project assumptions.

I find a lot of confusion among requirements/business analysts regarding the documentation of assumptions. Many analysts capture assumptions about requirements and use cases, but the assumptions are about things like pre-conditions or system states. What they fail to capture are their own, personal assumptions that went into documenting the requirements (things like “this project is just like Project X, so we can use the same UI” or “additional details about this feature will be captured before implementation begins.”

Thanks for reminding us all to get those assumptions out in the open!

And about importance of the assumption – that’s exactly my point. It didn’t matter since it was done unconsciously. If the team was aware of the assumption everyone would know how the project would go a few of months earlier. Even if the schedule wouldn’t be changed because of sales team or the client still Joan would be able to adjust at least plan of work (if nothing else).

If you know you’re going to fail with some delivery, but you know it a few months ahead, you have enough time to prepare plan B. If you realize that a week before the deadline all you can do is to try to calm the client down a bit. That’s a significant difference, isn’t it?

Furthermore – Joan’s assumption didn’t matter at all, as long as project plan was forced by the sales team on presales stage.

Joan :-)