When the Big New Idea starts a mid-project dilemma

When my client mid-project suddenly suggested some nice-to-have extra, I ended up reviewing how I might best handle the situation and avoid incurring their displeasure.

I recently found myself, not for the first time, trying to find a non-confrontational response to explain why I was resistant to the Big New Idea my client had just come up with half way through delivering a tricky web application project. It felt uncompromising to immediately hide behind the obvious fact that the deliverables had been agreed and a plan was now fully under way.

The conversation did not start something like 'I have an idea I'd like to discuss. Here's a flow chart I have run up to help explain how it might integrate with our current plans'. That would have been easy. No. It was one of those ideas that are dropped into the discussion casually, as though it had always been part of the plan, so much so that I found myself wondering if I had missed something in the earlier discussions.

Detecting resistance from me, he asked 'Well, what is the problem exactly?'. He took the attitude that 'it's just a couple of extra pages' on a website. Suddenly I was the bogeyman, the keeper at the gate refusing to let him pass.

Experience tells you that a can of worms has just been opened, but you are struggling to explain your instinctive lack of pliancy. An innate sense grows in you that your professional judgement is being questioned - because it is - and it is easy to take it personally and become defensive. In their turn, your client may well feel that you are questioning their business acumen. If you've been wrong footed you only have yourself to blame. What you should have done is responded by inviting your client to explore the business implications - including, incidentally but not specifically, the knock on effect to your existing terms of agreement.

You need to watch out for this trap because, if you cannot answer their what-is-the-problem question then you actually stand a good chance of losing some of their confidence and diverting your relationship down a rocky road.

Let's take a step back and review the story so far. When you first discussed your client's web application requirement, they had either an existing business or a clear model of how the proposed business would work; including their key aims and message, how they would access their customers, why their customers would come to them and do business, how they would provide the service and how payment would be transacted. They had probably spent a good deal of time working out the original business model, evolving ideas and throwing away the non-starters, and then (hopefully) documenting the whole thing, burning a good bit of midnight oil in the process.

Having discussed their website budget with them you went off and did the preliminary analysis, braking the project down into its discrete parts, mapping their business model, point-for-point, to the proposed web application design. Hopefully you worked out the maximum bang-for-their-buck that you could give this client without going over budget. Then, if you are anything like me, you put a bit of icing on the cake that you knew would go beyond what they were paying for. Then you sent over a carefully formatted proposal which led to a signed contract.

That was all a couple of months or more ago and they have since grown comfortable with you. Suddenly the Big New Idea is casually tossed on the table and you are doing a double take. By the way, a key feature of this idea is that they are convinced it will be very easy for you to do.

The problem is that in their enthusiasm they have not mapped the idea into the overall business model. What monies will pay for the development? What priority should it get and what other deliverables must you therefore delay? How will this integrate into the application you have carefully constructed that virtually mirrors their business? And have they thought through the workflow and resource issues created by this departure from the original concept? Most importantly, even if you deliver it, will it actually justify the effort by enhancing the overall viability of the business?

Actually they will probably think the answer is yes and give you a few off-the-cuff answers to these issues, giving the impression that it is all well considered. This is the point where, instead of digging your heels in, you should gently insist that they produce a business impact assessment and some documentation that describes how the new idea will be incorporated into the business model and advise them that you, in turn, will revise your project documents to meet the new requirement so that you can agree any changes to the delivery schedule and the budget. In all probability, by the time they sit down with you to revise the project deliverables, they will have discovered for themselves any hidden pitfalls.

My current client tends to leave me to define the finer granularity of how the business will work. This is because I am a partner in this particular venture myself. Even so, I plan to present him with exactly the documentation I have described above, then sit down to pore over it together and decide if it's such a great idea.

It's all too easy for the customer to imagine that building web functionality is just a couple of buttons to press and, hey-presto, the internet does it all for you. In truth, you may have encouraged this perception because you want them to have faith that delivering on what you promise is comfortably within your capability.

Your task is to get them to break down the idea and understand its implications. That way you don't have to be the villain, they will work out for themselves which of the Go, No-Go buttons they should press.

If you have managed to guide your client with a little sensitivity, they may eventually realise that the success of the project has been down to your clear minded leadership. You can take that personally if you like.