Client Meeting -- Another Risk Mgt Sell

A couple of us went to see a prospective client yesterday. To cut a rather long story short, they need a team of real heavy duty technical talent to build out their application and technical infrastructure since their current consulting firm does not have the wherewithall to get the job done.

We met with the senior manager who asked some obvious but pertinent questions. How do we structure projects in terms of risk and project management ? What controls do we put in place before and during a project ? How do we work with other incumbent groups in an organization, whether they are employees or other consultants ? How do we incentivize and motivate our staff to get the project done ? Many of these are general questions we take care of through engagement and relationship managent, project-specific structures, employee benefits packages, as well as team-based get-togethers, etc.

Ultimately though, once again it comes down to how we mitigate risk (particularly for a new client we have not worked with before): put a plan together for a series of quick hits of delivering functionality, demonstrate our value and potential, gain quick feedback, provide quality rather than quantity (and they will pay for quality), regular communication at the executive and project level, etc. And guess what kind of approach provides that .... ?!

Also, buyers of products and services tend to think of the things in a different way than those doing the selling or execution, so the message and approach of a project needs to bridge that gap. I have mentioned some ideas before on this. Here also. However, one can only address most of buyer's objections and issues so far. There is a philosophical difference in mindset in how different people sometimes think of these projects (ie CFO vs PM vs vendor). Fundamentally, how can you ever 100% guarantee scope, time and budget to any client without something giving and breaking the financial vaiability of the project ? You can't. So therefore don't even bother trying to figure that out.

It is about trust, shared responsbility and risk mgt. (see this on trust as well). If you can't get the first two, forget it. Problems, dependencies and issues happen on every project and sometime unexpectedly -- your solution/ approach needs to expect and embrace this.