We’ve set our goals for the project and written a specification.
Now, I’m going to quickly discuss setting our own expectations. We’re getting into the nitty gritty and it’s time to talk about or own biasses.
Have you heard of confirmation bias?
…the tendency to search for, interpret, favor, and recall information in a way that confirms one's preexisting beliefs or hypotheses, while giving disproportionately less consideration to alternative possibilities.(fn)
We are all guilty of it. It’s an innate feature of being human. If you are writing a specification, ask yourself where your expertise lies. The classic conflict with suppliers is a designer who over-simplifies a develop to job and a developer who thinks design is just drawing pretty things.
Often the writer of the specification has more experience using websites rather than building them. The complexity behind the scenes is hidden. Something that may seem simple is in fact complex.
That's one of the reasons we've been looking at our intentions before we look at the way we achieve them. That way we can look at things without bias.
In the goal setting section we looked at identifying the core goals before prescribing how we think the goal should be achieved. In our example we had a time-consuming process to manage returns, but we just outlined the problem and the goal. We didn’t set out what we thought was the best way to achieve it.
We removed our bias from the equation. Awareness of our biasses reduces their influence. Our goal-focused approach to the spec should also help us choose the best approach to our project.
Now in the next section we are going to look at the budgets involved. Prior to that I’m going to run through some of common misconceptions and expectations and how that can limit our specification.
It comes down to something simple: Building a good website is hard work.
It’s important to set our expectations correctly about this in particular and what is involved.
The problem is, we’ve been primed.
We’re used to spending a few dollars on a smart phone app. We are users of software and not developers. On top of that our common interaction with software is with scalable products. Products that are downloaded hundreds and thousands of times. Not as a bespoke piece of development.
Marketing emphasises simplicity and value whatever the product. How hard can web development be in 2016?
The cliche goes that we all have a niece of nephew who can build a website. And isn’t a lot of this stuff free?
I work with WordPress and it’s a common trope bandied about. Themes can cost less than $50 and that nifty bit of functionality you require has been build already for not much more.
There are hundreds of self-proclaimed experts out there all telling a hundred different stories. The most successful stories I see are the ones we want to hear. You see, they have tapped into our confirmation bias - we like the stories we want to hear:
That this is all easy, quick and cheap.
These expectations cause countless problems. Half-finished projects often arrive in my inbox. Help! I’ve been let-down. Honest people who bought the snake oil.
Developers and designers who have felt pressurised by clients to lower their rates and don't have the time to do the job well. Clients who haven't outlined the scope of the work and are frustrated there suppliers are not doing more.
Projects that have eaten half their budget already and need to start again. Where the development partner split with the client. Where the finished project is a disappointment.
I think we have a problem and it comes down to risk.
Have you heard the expression - buy cheap, buy twice?
I think it should be buy cheap the first time, buy actual price the second. The problem is many new business are bootstrapping it and don't have the budget second time around.
That's why the single most important thing in any spec is being transparent about your budget.
Enjoying these posts? Subscribe for moreSubscribe now
Already have an account? Sign in