Warning: Creating default object from empty value in /home4/panthro/public_html/lessonsit.com/wp-content/themes/skeptical/functions/admin-hooks.php on line 160

Get away from assumptions

Communication is a key factor for a successful project or an epic disaster, so make sure you’re not assuming anything. If it’s not possible, focus on having as less assumptions as possible.

Some months ago, I had my first clash with stakeholders, and now looking back I can understand it was caused by the level of assumptions in place. We had agreed to start an UAT cycle in a specific date. From an IT perspective, to start a cycle I meant that we’d start preparing things up, i.e. promoting changes into UAT environment, align data, trigger reports, etc. From a business perspective, however, to ‘start an UAT’ means effectively to start analysing data.

So, my assumption here was that stakeholders would know that data isn’t ready for assessment in a day. Looking the other way round, their assumption was that we’d be preparing things early on to actually deliver something on the agreed date. It could’ve be easily avoided by clearly stating the steps involved on the plan. Now, when plans are being aligned with users, I clear state the preparation time required separated from the dates the reports will be available. Simple things making life easier.

Same applies for requirements. That’s one of the main ideas from Brooks on his The Mythical Man Month:


To avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible — e-mail, phone, meetings, memos etc. Instead of assuming something, the implementer should ask the architects to clarify their intent on a feature he is implementing, before proceeding with an assumption that might very well be completely incorrect. The architects are responsible for formulating a group picture of the project and communicating it to the others.

As more complex the requirements, are more assumptions can be made. After the initial reviews, ask yourself: What have I assumed? Also, ask your team the same. It’s a matter of habit. Down the road, you and your team will naturally spot assumption spots across requirements / documentation.

What can we do about assumptions? Get a formal confirmation on them. When I mean formal, I mean that an instant messenger confirmation doesn’t apply here. Ask for an updated version of the documentation, a formal mail at least (that can be transformed into a PDF for historical reference) or something else that can be shared and transparent to all the people involved.

And you have any tip to avoid assumptions?

Share and Enjoy

No comments yet.

Leave a Reply