(2)「運用レベルでの推進」
2番目のポイントは、
大きな方向性とやるべきTODOが認識された後の推進時での貢献についてです。つまり大抵顧客側のメンバーは
リソースが足りていない状況にある、という事実があります。
プロジェクト体制をつくっても、プロジェクトの推進(実行部隊)は顧客側の責任において実行されますが、多くの場合顧客側のリソース不足でプロジェクトが理想的な結果を生み出すことは
少ないのです。
その背景には、
①「顧客側のメンバーのほとんどは当該プロジェクト以外も兼務している」
②「同様の特命プロジェクトは、日々の定型業務と密接につながっている」
③「コンサルティングファーム側のメンバーはたとえ常駐でも特命業務のみの専任」
という3つの状況があるからです。
①によるリソース不足は、本来は「顧客側の怠慢」といえるかもしれません。実際はどの顧客のメンバーも「定型業務でいっぱいいっぱい」になっている場合が多く、すでに業務が
「破たんしている」と感じる場合も少なくありません。
しかし一方では、「本来それは顧客側の責任」と正論を吐いても意味がないため、実際はそれを
どう解決していくかを考えなくてはいけません。 その際、事業会社での経験があると、
事業会社内での定型業務の仕事の振られ方、時間の取られ方、根回しや稟議のポイントなど、メンバーの方の業務分析のイメージが沸くため、当該プロジェクトを円滑に進めるための
ステップとして、「顧客側のプロジェクトメンバーの業務プロセスの変革」を一緒に考えたりすることが可能であることが多いようです。
②、③についても同様です。
コンサルティングのプロジェクトというのは「現状(as is)をあるべき像(to be)に変革(transformation)する」ということなので、どんな小さなものでも
これまでのやり方を変える、または新たに加えるということになります。つまり、その最中にはこれまでのやり方(定型業務)と変えようとしている内容(特命業務)の間で2つの異なる
スタンダードが生まれ、並行稼働をさせていく必要があります。そして、実は、実行段階でのプロジェクトの躓きはここで起こることが多いのです。