Getting project assumptions right
Anyone, anywhere that’s been involved in project work of any kind will be able to identify with the following situation:
You’re two thirds of the way through the project, tempers are rises, and expectations are unclear. You’re all sitting in a room and the most of the sentences are starting with ‘But I thought that…’ or ‘We said at the start…’
Expectation management is one of the toughest parts of any project. It’s a harsh mistress as even good expectation management can still cause hostility between client and vendor. This blog isn’t gone to attempt to try and solve this problem, that’s a couple books with of discussion. All I’m going to touch on is a quick look at writing assumptions.
As people working in the web, we forget how much we know about the web, about information technology in general. It’s not specific to I.T., every profession forgets the level of subject matter knowledge it has over the ‘common person’.
What this means though, is that we tend to make assumptions. The problem with these assumptions, is we tend to just think them, not write them down.
The problem
When we’re concocting a solution in our head, we assume a lot. We assume our designers are going to design it. We assume our developers are going to build it. We assume that we, as UX designers, can utilise the full potential of these colleges we’ve worked with on many projects before.
The client all makes assumptions. They assume you understand how a catering company works. They assume you know Drupal inside out. They assume you’re writing most of the content.
These assumptions are fine, as long as their written down at the start of project and each side get to review. Assumptions are a great way of ticking off big sections of a project with very little discussion: we’re a .Net business, so we assume the site will run on Microsoft Windows Server 2012. The client knows they’re getting a .Net site so brilliant! No discussion needed!
The solution
Assumptions (and it can be a long list of them) needs to be the first section of any document that attempts to scope a project. Whenever we thinking about anything to do with a project, we’ve made assumptions in our head and those assumptions are influencing our thinking. For someone else trying to understand our thinking, they need to read our list of assumptions to make sure their heads at the same level as ours.
