Is your project a failure? Part II 4


It's not war. Photo by: Jayel Aheram

So you’ve got project lead on this. What’s your goal? Finishing X, Y and Z within stipulated budgets and time frames? Please say no. What are you, a robot?

In my mind your goal is to deliver the best product or service possible, your goal is to advice your client on how he or she could achieve his or hers goals in ways they never thought of. In pompous terms borrowed from Seth Godin, your job is to be remarkable.

When you enter a project together with a customer you enter into a collaboration – a relationship even. Just as in any relationship, we need involvement and passion. Much “us-and-them” thinking is floating about creating a lot of tension. There’s a clash between Customer and Client – which of course boils down to “payer of invoice” vs. “sender of invoice”. That’s a business transaction – and that’s probably where all tension originates. Nothing adds pressure as short-sighted financial goals. But this is not war, people. It’s collaboration.

I believe it was in a tweet from Jeff Patton where I caught this spot-on statement:

“We should be more like doctors – helping, and less like waiters – taking orders”.

Well put! How many times have you heard, or maybe even uttered, sentences like: “It’s crap, a road to ruin, but that’s what the customer wants so hey, by any means – let’s go build it, see if I care!”

Now for some prejudice based on experience: If you’re a consultant you’ve probably said the above one too many times yourself. Consultants are the hired guns of our world, and how to work with them intelligently is a whole different chapter for another day.

But back to essentials: All in all, it’s actually really, really easy: The customer has goals, you should go above and beyond in order to help the customer achieve these goals. Here’s where my much repeated mantra returns to haunt you: keep an eye on the end game. What is it really that the customer wants to achieve? This is a question of communication as well as commitment. Communicating what’s possible, what’s realistic and what is not. And committing to the work at hand, – whatever could anyone gain from NOT stepping it up and with solid and well researched arguments direct the customer in the proper direction?

You need to go above and beyond. Should your customer have a lousy process at their end, a process that you KNOW will cause an awful mess, then for the love of Taiichi Ohno, tell them so, and help them improve. If you don’t – go find yourself a line of work where such indifferent behavior is accepted. On the top of my head I can’t really think of one. But as you know, Absence of evidence is not evidence of absence.

It might be that this calls for a different breed of project managers, or maybe a different team setup – a configuration of people for whom system thinking and understanding of business goals is well rooted. A team where everyone involved truly understands the big picture and not only the role they themselves play. In my world, this means making designers and hackers take at least a minor interest in economics, law, marketing and other areas not directly associated with what they are hired to do. Difficult, but not impossible.

And again: a goal is an end game. I will repeat this until my nose bleeds. Helping your customer reach his or hers end game, even if this means not taking the job because what your customer really need is something you can’t offer.

Helping your customer excel. That’s the only success factor you should be interested in.


Leave a comment

Your email address will not be published. Required fields are marked *

4 thoughts on “Is your project a failure? Part II

  • forsandree

    I agree, succeeding requires a setup where everyone has at least a basic understanding of the business objectives. This also requires having everyone understand more about what the others do. You cant solve the business needs by just hacking code, creating the coolest design or the best text – you need to balance all three.

    I'm very interested in how to bridge this gap. It's hard (and probably not a good idea in the first place) to try to change peoples' interests. Yet, somehow you have to force people to work together.

    I think one part of this is to reward solutions where all perspectives have worked together. Stop saying to the programmer that they've done a great job in the coding – always talk about a great job in the overall context. Some thoughts on this here http://definitionofdone.blogspot.com/2009/10/be

  • Thomas Lindqvist

    I couldn't agree more with your post. Often, designers and coders are very much savvy to the possibilities and problems of web based projects. Sometimes even more so than the suit and tie running the business side of things. What the designer and coders lack is the opportunity and the language to express their opinions. We can give them that opportunity. And the language, well, that's just corporate / business / marketing mumbo-jumbo anyways. I think a good start could be to aim for a better definition of delivered value – usable software is a good start. Moneymaking – or customer problem solving software is even better. End game goals. We surely need our experts in each domain, but allowing for everyone's input in the project with egards to the end game, and avoiding the “creative genius” or “back end genius nerd” mentality, could help create a collective ownership of the whole project delivery. I'd like to instill systems thinking across the line. Everyone should realize that even a optimized sub-process is crippled if not placed in the context of the whole system. Holistic thinking and all that. Huge subject – lot's to say. So little time.

    And thank you for your kind comments with regards to my blog.