Eddielogic

– Thoughts on Strategy and Management

Risks of external consultants and interim managers…

…and how to manage them. When company managers discuss their personal experiences in terms of external consultants you can find a broad range of opinions and beliefs. Point of views may vary between very positive experiences when hiring external knowledge and very bad experiences; the later ones are sometimes expressed in jokes about “flippy” PowerPoint presentations or even statements that those experts only summarize knowledge that was available in the organization all the time.

The truth is that most of those experiences can be proofed; furthermore there is a very high probability that you going to meet both types of consultants (the good ones and the bad ones) after several years in business. One typical kind of problem: Presented results look good on PowerPoint, but not in corporate practice. Process time is assumed to short; certain – in most cases hidden processes – have not been considered and hence do not appear in new flow charts. Essential details and former best practice will not be transferred to new solutions. (From my personal point of view in most cases those “details” and hidden processes make or break large projects, e.g. success of acquisitions, outsourcing). Another frequent problem can be observed in terms of knowledge that leaves the organization. Hiring external expertise for a certain period of time may solve your problems today (e.g. to implement a new IT system), but in some cases the organization will end up with a very expensive black box.

Similar problems can be observed when hiring interim managers for small period of time. The reason: Both groups (consultant, interim manager) are paid to deliver certain project results, but not to live the conditions and organizational surroundings they create. Hence the question is whether there is any chance that you can protect your organization and your team from those consulting dilemma (you need the external experience or the external capacities to fix your problems).

There is no general solution at all…however: The general recommendation is to organize at least an “internal resource” that reviews consulting results in terms of their feasibility and that manages the knowledge transfer from the consultants to you organization. (Of course you can expect that not all consulting firms will like this idea). The size of this resource depends on the size of your organization and the scope of the consulting project. A business model reengineering project of a medium size organization should be reviewed at least by 2 persons (no full time jobs, but 2 people with around 50 % capacity for this job would be great). In the matter of organizational hierarchy those people should not belong to the top management team; a middle manager and a colleague can be a good solution. Why 2 people? There are 2 different types of jobs to do! The most critical task of them is to see and to understand the entire picture of all consulting results as well as the secondary effects within the organization. Most project management structures are good at reviewing single projects (at least) or to get a clear picture whether the single project is able to deliver the expected results, but fail to describe secondary effects. It can also observed in practice that a good solution for project A does not cause a good condition for project B automatically.

But in some cases it can be essential to discuss small details in projects – but not all project review meetings are prepared to do so, in particular when the cycle of project reviews in one moth or even longer. In this case (this is the second type of job) you need a “process and data cruncher” (I derived this expression from number cruncher) who is able to test PowerPoint-good-looking workflows. Finding this person can be a hard job, but it is worth the effort. People with several years of experience in different roles and jobs in your organization can be a good point to start.

One Comment

  1. My friend suggested me to visit your blog. Very well explained. I would like to say that it is very interesting to read your blog.
    regards