It's you, not the client

read —
19 May 2014

Over the last four or so years I've tried to spend time understanding why almost consistently web and digital projects would become completely derailed.

There are a lot of theories as to why projects fail, and it almost always ends up in Clients from Hell^ references, though that's a rather naive approach to the problem. Discussions about clients in a way that disregards or mocks their knowledge and understanding will simply perpetuate the stereotype and decrease your ability to grow the relationship.

It also very clearly demonstrates that the core problem isn't understood by us. The real problem is that we as professionals are allowing the client to make decisions that are not based on educated knowledge or qualified data. The core problem is bad client management—both expectation and responsibility.

Almost always this will result in the client driving the project (not understanding responsibility) with us taking the back seat on a largely unsatisfactory project, while later being held to blame when it all falls apart (not understanding expectation).

Derek from The Tomorrow Lab writes about Modern Web Design, wherein he describes that designing for the web is more akin to designing for product and industry than print or graphics.

It's a pretty sound analogy.

We find ourselves then at the point at which we need to take ownership of the projects that we're running, or forever make submissions to Clients from Hell ignorant to the problem we're not addressing.

We can regain ownership by following a carved process that is used more to hold clients accountable, than to produce a successful outcome. The process will be unique to each agency, though there are a few universal observations:

1. RACI is your friend

I'm a huge fan of the Responsible, Accountable, Consulted and Informed mapping when it comes to outlining who's who within a project. I also like to take it one step further an flesh out what each person will do in the project.

Generally I'd see the Project/Product Manager being responsible along with one client contact. All other clients involved directly would become accountable, and anyone else client side is consulted.

Accountable attend every other WIP, and Consulted never attend WIPs or meetings.

We then set the tone for the Responsible Client contact, which would be to make yes or no decisions, to seek advice from their colleagues if necessary, and to come back with yes or no answers.

2. Speak in outcomes and business goals, never 'requirements'

As with the agile manifesto we should speak about tangible business goals being solved to produce qualified outcomes. We begin to decouple specific requirements as must haves and business goals.

Should we have a business requirement to 'make more converted sales', adding a 'wishlist' or 'save my cart' is arguably not going to increase conversion as the user has comfort in knowing they can save it, and there is no immediacy, versus a countdown timer for cart expiry.

Typically we would hear the argument of 'but it is an ecommerce website, it must have a wishlist, all ecommerce sites have a wishlist'.

3. Remove 'ta-da!' moments

I talk about ta-da! moments with my team a lot, and try to remove as many of them from whatever it is they're working on with a client as possible.

Ta-da! moments are any points within a project that we're not 100% sure what the client is expecting from us, but we're working anyway in the interest of time and gaining project ground.

Taking Derek's example of graphic design being a picture of a website, we could easily find ourselves in the position of 'slicing and dicing' it into a website, and building what we think the implied functionality is, and asking the designer to fill in blanks.

Before too long, we're presenting the client with our first prototype (ta-da!) and asking for their feedback. Only the feedback that returns is plentiful, changes massive amounts of the underlying architecture and is, well, different to what we created.

We try to claw back the ta-da! with phrases like 'scope creep' and 'change request' but the lines are far too blurred.

4. Ok, maybe it is the client

Any client that doesn't want to play ball simply isn't the kind of client you want to to work with; no matter how promising the budget is. We know from brutal experience that we as the service provider bear the full brunt of 'scope creep' which eats into any project profit incredibly fast.

Holding onto these clients as a 'loss lead' or other romantic notion is deeply flawed, and the sooner you're able to work exclusively with clients happy to follow your process the better outcomes will be, and the higher the profit will be.

Ultimately what we're trying to achieve is the clear bridging of what we are trying to do and how we're going to achieve it. We want to clearly communicate what we expect from clients, and they from us.

Failing to do so will result in a project doomed to fail from the beginning.

^Any Clients from Hell references made around me end in a lecture about proper client management. Don't be that person.