Facilitator into project team member

03-Jul-2012 - Clients will often hire someone with expertise to help put a project design together but what if there is an opportunity for the facilitator to take part in the project? Malcolm Sleath of 12boxes suggests how this transition might be made.

Question: I’m helping a client design a project through a series of workshops which I am facilitating. In addition to this design work, I’m pretty sure they will require my assistance in execution as I have experience and knowledge that they don’t yet have. At what point should I broach this to them?

Answer: My first point is that you should not work out in advance too much detail as to where you might fit in to the project. This is because your preconceived idea will colour the nature of your facilitation and, however objective you think you are being, the client will pick up that you are pursuing your own interest. You have to have faith in the process, and ‘discover’ your role later.

This does not mean that you should be completely unprepared. For example, you could make a list in advance of the relevant competencies and experience you would bring to the project and identify areas where these would overlap with the client, and areas where they don’t. This clarity will come in useful later.

It’s not clear where you are in the process, so I am going to outline the process from a 12boxes point of view and hope that these coincide with the structures that project managers will recognise.

There needs to be a definition for the project requirement. Sometimes requirements are over-defined at the beginning in an attempt to inject precision and clarity. Unfortunately, the effect is often to inhibit creativity and limit the discovery of potential project payoffs. This is why I prefer to start with a requirement which is expressed simply: a ‘way of doing something, so that something happens’.

For example, a marketing oriented project might be to find ‘a way of improving the customer experience so that we achieve more repeat business’. Note that I have not put any metrics in here. They come later.

In establishing the requirement, there are two other elements that we need to take into consideration. The first is, “what will happen if we don’t fulfil the requirement?” In other words: “What is the potential opportunity cost of doing nothing?”, and/or “Is the problem serious enough to devote resources to it?” Answering these questions implies that we should consider the worst case scenario and the risk of it happening.

Exposing the worst case scenario gets people’s attention. Projects often start off with the vague intention of achieving a positive payoff. I’ve heard clients say, “I don’t want to talk about problems; I’m only interested in opportunities”. That’s fine for some, but if you want to grab people’s attention, it’s probably better to discuss the prospect of loss first.

The second element that accompanies the requirement is about the things that are going to stop the project from working, or even getting off the ground. In 12boxes we refer to these as ‘restraining forces’.

Some of these restraining forces will be apparent to you from your expert point of view, others will be apparent to the client and not you, and some will be apparent to both. Sometimes people try to skip past the restraining forces, or treat them as objections to be addressed in the here and now. Generally, I don’t recommend either of these approaches.

However, I do recommend that you actively encourage their expression because they can be incorporated into the draft resolution, making it richer, more relevant and credible.If we take the marketing example I gave earlier, we can look at how the ‘worst case scenario’ and the ‘restraining forces’ might make it richer.

It might now become: ‘a way of improving the customer experience, which takes account of the current capabilities of the help-desk team so that we achieve more repeat business and avoid losing market share through preventable churn and loss of profit through needing higher investment to recruit new customers’.

The next stage is to develop a ‘vision of success’ which sets out ‘what good looks like’ and the potential pay-offs from achieving it.

To take simple instances, ‘what good looks like’ would include what help-desk staff will be doing, and how customers will be feeling. The richer and more detailed this vision, the clearer the objectives for the project will become.

In particular, instead of the potential payoffs being described as ‘the board is expecting a x% improvement in retention and y% reduction in the cost per customer’, which is an externally imposed and, dare I say it, arbitrary benchmark, we might go for something more ambitious based on the chain of events arising from our ‘what good looks like’ scenario and its consequences.

A successful high-jumper imagines a vision of the perfect jump. How high the jump is going to be is a function of the coordination and self-belief that informs the execution.If we adopt the high-jumper’s approach and develop the vision first, the board’s requirement may then become the ‘at least’ position, instead of a grudgingly acknowledged target which only carries the ‘we’ll be lucky’ level of conviction because there has been no vision of how it might be achieved.

If your facilitation follows this pattern, my hunch is that the project will become more interesting for all concerned, and you will achieve a much higher level of engagement. Many projects are driven by the need to get away from the worst case scenario. More should focus on the attainment of a positive vision of the future.

But we need to turn to practicalities, and how your future contribution to the project might emerge. For this, we need to turn to developing some rigorously defined criteria. Criteria can be thought of as arising from the tension between the glowing vision of success and the tangible benefits we hope will flow from its attainment, and the restraining forces: the concerns and beliefs about people, processes and resources we referred to earlier, and which have to be convincingly addressed if our project plan is to be believed.

This is not the place to explore criteria for execution and success, and there are others who would be much better than I at offering guidance. But, to answer your original question, it is in the development of criteria that the opportunities for your involvement and the contribution it would make should become apparent.

In working up the criteria with your client, you will be identifying the experience and capabilities required for successful execution. The deficiencies in their in-house resources should emerge.

By now you should have established that, not only do you fully understand the project requirements and the implications of the vision of success, you have also been a positive influence on it and shown that you are a good person to have around.

The client might not be able to justify you being on board for that reason alone, but once the gap in resourcing becomes clear through the rigorous definition of criteria, they will have a ‘good reason’ to hire you, and the initial invitation is more likely to come from them.I hope it does. Good luck!

____________________
Malcolm is the Founding Director of 12boxes Limited. 12boxes is a conversational approach to getting clients to recognise the real value of consulting and other high-value complex services. More information at www.12boxes.com/tc.

Contact Malcolm with your views, questions or suggestions at malcolm@12boxes.com or follow his on Twitter - twitter.com/malcolm12boxes.

© Malcolm Sleath 2012. All rights reserved.