Deconstructing the fuzzy zone
When I started thinking about this blog I was torn between calling it ‘creative tension’ and ‘the fuzzy zone’, but a quick check of the urban dictionary tells me that fuzzy zone describes the phase in a relationship when you’re more than friends but not quite lovers; that’s way off the mark for this item. What I’m actually interested in is the stages in a development project when you’re somewhere between colleague and enemy. In particular I’m exploring the tension between different roles in a development team: sales, design, development and project management.
Most projects will start with a sales phase, and the natural tendency of the sales role is to over-promise what's possible. You’re trying to connect with a potential client and convert their fears into hopes, and doubts into certainties. This over-promising is integral to the sales process from initial advertising onwards. Buying a car will turn you back into a young, fun-loving sex magnet as opposed to the boring family guy you really are. Skin care products eliminate wrinkles. We actually know this stuff isn't true but apparently quite like these minor deceptions.
Now if you have any ethics as a salesperson, you won’t out and out lie, and if you’re smart you won’t make wildly exaggerated claims. But, (and finally we get to the fuzzy zone), there will be project features where it gets a bit fuzzy about how much is possible on the client’s budget and timescale. In your head the social media integration will be a twitter feed whilst in the customer’s head he’s buying the next Facebook for virtually nothing. You will try and set expectations so that you don’t get bitten further down the line, but maybe you’ll be saying “let’s check out what’s possible on that” rather than “on this budget? Are you totally insane?” In other words, when you hit the fuzzy zone you have every reason to keep it fuzzy; leave the customer with his fantasy intact until the contract’s signed.
Moving on through the roles, there’s a chance the designers and developers will actually play along with your over-ambitious commitments. They want to do cool new stuff, and after all, they are web developers; if they’d wanted to stop people doing things they’d have become system administrators. The designer has a commitment to the value of good design; she doesn’t want to compromise all over the place in order to hit a budget. On the other hand, an experienced developer will have a nose for the illusions a client might have. The chances are she's been bitten in the past by the sales team promising the moon on a stick.
If the sceptical developer doesn’t pick up on the dangerous illusions left in place by sales, the project manager should surely get onto this. Her job is to get the project delivered on time and on budget so she has every reason to reduce each feature to the point where the developers can guarantee to get it done in the estimated time. In fact, a good project manager will go even further and factor in time for unforeseen problems. So she'll put pressure on the development team to reduce the scope even further. Our project manager wants to take that fuzzy zone on the horizon where anything is possible, and eliminate it.
So, given that we have this fuzzy zone that the various roles within a project will perceive quite differently, there’s potential for tension and conflict. What to do about it? Left alone, this tension can become destructive and even lead to a failed project. The first thing to do is recognise that this tension will exist in virtually every project. The chances are that the sales team know exactly where the fuzzy areas are so they need to identify those early and explicitly to the rest of the team. For example, we write a project implementation plan and spell out the assumptions so they’re in the open. You can also do an internal briefing document where the sales team describe any areas where there’s an awareness that the client might have assumptions that differ from the development agency.
Another obvious place to draw out the assumptions is a risk register, at which point you are faced with the awkward reality that the client will presumably also be using the register. While this may be awkward, the truth is your client is probably not stupid; everyone knows there’s a gap between the promise of a thing and its reality. Provided you acknowledge and explain the gap between your client’s assumptions and the technical and financial realities, the sensible client will get the point. Of course, some education may be needed about the technical implications of development tasks; things that look like a five minute job will turn out to take much, much longer.
A useful approach here can be to make the internal conflict quite obvious to the client. The conventional approach may be to present a unified corporate front, but it’s more honest to bring the divisions out into the open. If sales has oversold and opened the risk of under-delivering, and production wants to flip that around, argue about it in front of your client. Provided the basis of the argument is working out how to maximise what’s possible for you client within the constraints of time, money and technology, you need to help your client to understand there is always scope for debate.
If acknowledging areas of tension and getting the assumptions out in the open seem obvious, why is it this doesn’t always happen? One reason could be that there’s a power imbalance in that the people who set the assumptions are in a position of authority over the people who have to deliver. In this scenario, the developers know that something is impossible but keep working on it anyway. Even if the power relationship is not backed by formal authority, it might be a personality clash where two people are convinced they are right. The best way of addressing these fairly normal human behaviours is for everyone in a development project to recognise what role they are playing within the context of this project. In other words, you might be the boss but if you are working in a project, your authority should only relate to the role you are playing in the rpoject. If your team don’t have the confidence to say “you might be the boss, but you’re wrong”, you have a problem. So there it is; tension and conflict between roles is inevitable. The question is really whether you ignore it or make use of it.