Avoid Project Assumptions

Assumptions are the root of all evil on a project.

Why wasn’t the branch release made today?
The quality assurance manager assumed someone else was going to do it.

Why is this code so sloppy? It’s barely readable!
The lead developer assumed that wasn’t important.

Why didn’t anyone mention this problem earlier?
The team lead assumed folks would raise concerns before they became problems.

Why are we using this communication mechanism between the client and the server?
The architect assumed the modifiability quality attribute was not important.

Why was I the last to hear about the new quality assurance process?
The process manager assumed someone else would let you know.


The fastest way to project failure is to make the wrong assumptions. At the beginning of any project, especially when there’s a brand new team involved, there are going to be assumptions. People come with biases – judgment is one of the things humans are really good at. The more assumptions you can avoid as a team, the better off you’ll be. Write down your thoughts, talk about your history and experience with everyone on the team, write down the decisions you’ve made throughout the project, and record the justifications you used to make those decisions. But whatever you do, don’t assume.