When projects attack!

For all the glossy success stories when it comes to UX and tech projects, there are a nightmare of others that didn’t go quite so well. Victor Lombardi has talked about this at an organisational level in the book Why We Fail (including issues of ethics) and Steve Portigal has been writing and presenting a series UX war stories based on his own experience. Still, I’d yet to hear of one in the mobile sector, let alone one involving health, so was keen to hear this month’s UX Auckland talk by Ian Power of Healthy Digital on his experiences.  It was also the first chance for me to attend the event since moving to the UK!

As the first UX Auckland event to be held in the swanky Digital Arts Network (DAN) basement bar, there was a record turnout with a waiting list, which also meant active discussions taking part before, during and after the talk.

Power talked through a mobile project that started with a tightly constrained budget but global aspirations that over the course of two years spiraled into different scenarios, clinical trials, data protection issues and even having to bring in the lawyers in relation to potential liability! Certainly a trial of fire. Still, as he admitted at the end, while he’d have done some things differently, he still believed in the product, and is optimistic that it will get released to the market soon.

He highlighted a few key pointers:

Be careful what you wish for

Just as Hemingway’s Man and the Sea highlights the perils of ambition overreaching ability, so does getting that big sexy job that may have global reach. Every vendor wants a sexy, far-reaching project that could be great for them as well as enact change. Power’s team were so excited about the potential of the project that they weren’t aware of the potential issues that could happen later on.

Don’t think big, think small

Like the classic VW Beetle ad, it pays to think small as this allows for a bit of scope creep, whereas a big project can quickly spiral out of control if elements change. It’s also possible to carefully add in extra components as new features this way.

Talk like a surgeon

Powers suggested that vendors can promise things that are difficult to deliver, whereas they should instead say the bad things first, like a surgeon does. While some people in the audience expressed concern at this (including someone pointing out that the business researcher Bent Flyvbjerg showed that megaprojects are won through creating a fantasy world and lying!) some practical notes that came out of this both from Powers and the audience were:

• take your developers into meeting. My work do this: and our lead developer was even given a t-shirt for his birthday saying “NO” since that’s what he’s always saying for new features
• for UXers, don’t get caught up in the detail. It’s easy for UXers to start figuring things out in meetings, but for clients this isn’t helpful, they want the what and the why, not the how.

The client is a child(?)

While I agreed with Power’s comments that clients need everything explained to them, I disagreed with the analogy of a client being a child. In my eyes, this demeans the intelligence of the client. I prefer the analogy that a client is a knowledge expert or even a Mastermind champion – they’re brilliant as some things such as their business but have brought you in as the expert on digital, so it is therefore your job to educate them appropriately.

Nothing is free

Scope creep can start with a few innocuous change requests, but they quickly add up. It pays to be open and clear about what’s starting to be creep. (My work also avoid clients directly contacting the developers or designers instead of going through an account manager, as that’s often a sign of “one little thing” leading to another).

Some of the audience also pointed out that big companies can also have particular issues when it comes to financing and leadership – a big company may have vendor list that takes months to get on to let alone be paid from, which means you need to get on it from the day you get the gig if you’re to get paid a part even somewhere near the beginning of a project.

The square cube law and defacto standard requirements

In what turned out of be a very loosely defined project, the goal posts can very quickly shift, leading to a lot of financial and resourcing tensions. In retrospect he would have specified the stages better (and is now also using a staged 30/30/30/10 model for payment which encourages go-live). This led to a lot of discussion about structuring workflow in a way that is practical for the vendor but also feasible for the client in terms of getting sign off and meeting budget windows.

There were a few tomato-tomahto moments in the evening relating to jargon: when Powers noted that agencies work predictively whereas developers work in an agile way, I had to later google to realise predictive refers to things such as waterfall. And there was a heated debate relating to fixed pricing vs just saying billable hours … the latter of which roughly translates to a retainer model provided that you provide a set amount of resources each month.

Next month’s UX Auckland will be a catchup in a pub with talks invited for February on. To find out more about the group and keep up to date with new events, sign up to the Meetup group