コンサルタントの日々学び

日々のデリバリーで得た体験、ノウハウ、教訓とかを週次ベースで書き留めていきます。

複数プロジェクトを担う難しさ

コンサルタントも役職なりタイトルが上がってくると顧客も内容も異なる複数のプロジェクトを同時に進めることになる。

例えば、将来の構想策定のプロジェクトとシステム構築のPMO。

例えば、働き方改革の推進とIT戦略の立案。

例えば、ビジネススキームの具体化と技術戦略策定。

などなど。

 

こういう異なるプロジェクトを同時並行に進める難しさはいくつもある。

1)頭の切り替え

まずは内容が全く異なることを考えるため、頭の切り替えがしづらい。

1つのお客さん、プロジェクトであれば考えていることは複数でも

基本的に1つの目的やゴールに集約される。

ある顧客の基幹システム刷新において販売と在庫を担当したとしても「顧客」は1つであり、「刷新したいシステム」も1つなのでその顧客のためにどうすべきかをベースに考えればよい。

複数プロジェクトの場合は、当然顧客により優先すべき事項やゴールも異なるし、判断基準、報告・コミュニケーションスタイル、CSF・発生しうるリスク、そして業界情報やプロジェクト内容の情報が倍以上になってくる。

「基幹システム刷新」と同じプロジェクトだとしても

ある顧客では「グループ統合が課題、どうグループ会社に落とし込むか」を考えなくてはならないが

ある顧客では「業務を抜本的に見直し、それに伴うシステムに」が主題かもしれない。

プロジェクトという唯一無二のもので、考えること・考慮すべきことがが倍以上になることは混乱と至らなくても、頭を切り替えるのに時間がかかる。


2)複数のことをやることによる非効率

1にも関連するが複数プロジェクトを行うことによる非効率もある。

筆頭は移動時間。複数を行き来するだけでも時間が余計にかかる。

内部への報告なり、コンプライアンス遵守に向けたタスク、顧客とのやりとりのメール・返信・コミュニケーション量も増える。

マルチタスクゲームに見られるような、複数のことをすることで非効率・非生産性なことも発生する。

特に、メンバークラスだと、資料なり顧客報告資料なりモノをつくる時間が大部分を占めるのだが、いろいろなムダが重なってきてモノをつくる時間が取れなくなり徐々に首がしまってくる。


3)リソースの調整

個人的に一番難しく、経験して辛かったのが、このリソースの調整。

同一顧客内なら、複数タスクがあり、どちらかが難題を抱え時間・リソースを逼迫した場合、どちらを優先すべきか、リソースを注力・追加できないか顧客と調整がしやすい。

内部でも、同じPMなりパートナーであれば、個人のリソース逼迫を訴え、内部でタスクの優先度を決めたり、他のメンバーに協力してもらったりと調整もしやすい。

ただ、これが別の顧客なら、別々のPMなら、他の顧客で問題が増えようが、自社・自PJには関係ないのでやるといったことはやってもらう、リソースの調整は個人に任せられる、となり相談する先がなくなり破綻してしまう。

 

プロジェクトは予測できない波がある。

うまくいっていると思ったら突然の問題が発生した、報告がスムーズにいくと思ったら怒涛のダメ出しをもらった、予想外に検討が進まず進捗が遅れてしまった、参加者が発病により急きょスケジュールを見直すことになった、などなど。

そのときに繁忙の波が調整しきれず、波が重なりリソース逼迫、その調整も調整先が分散されうまくいかない、となるとデスマーチまっしぐら。

 

こんな場合の備えとしては、経験上これくらいしか思いつかない。

a)より上位とのコミュニケーションパスをつくっておく

複数のエスカレーション先だとリソース調整ができない。

なのでそれを統括するようなより上位とコミュニケーションし、タスク・リソースを調整する。

 

b)できるだけ負荷に余裕を見ておく、期待値下げる

はじめての複数プロジェクトだと勝手がわからないかもしれないが

2にあるようなムダは発生しうるので、あまり「120%やればできるはず」なタスクを抱えない。

80%くらいの期待値に抑え、できれば足を踏み込むくらいがちょうどよい。

 

c)そもそもメンバーレベルなら複数プロジェクトを抱えない

個人的にはこれが一番だと思っている。

PMクラスなどだと「考えること」に時間を割け、手を動かすのはメンバーに振ることができる。

だがメンバークラスだとそれができない。

その状況で複数プロジェクトを担うことは荷が重いと考えている。

 

自分がメンバーの際に複数プロジェクトでリソース逼迫経験した際も片方のプロジェクトで問題が発生し、両方担えなくなったことがある。

片方が開発でも問題が発生し火消しをする必要であったが、片方は制度設計で選択肢と判断基準の整理をする必要があり、つい前者に頭がとらわれ、後者の準備に頭が切り替わらなかったのを記憶している。

その時はPMより上位のパートナーと話し、結果的に片方のプロジェクトを離脱させてもらうことで事なきを得た。
複数プロジェクトを担うことはなかなか思ったより簡単ではないと実感した、よい経験だった。