PMBOKのステークホルダーマネジメントは組織のハックかもしれない

諸事情があって、差し戻しになった案件をリスタートさせるエンジニアがいて、主体的に進めようと活動を再開し始めた。

差し戻しになったときには基本的にwillを持っているエンジニアが自主的な判断で進めれば良いと思っていたので、口は一切挟まず任せていた。結果的には、チェックポイントで差し戻しになり、リスタートをすることになった。

介入しようと思えばいくらでもできて、進め方の段取りを聞いたり、アウトプットの作り方、ステークホルダへの具体的な依頼内容を聞けばいい。

それに対して自分ならこうする的なことをいい、スケジュールにマイルストーンを設定させ、それに対して予実をトレースすればいい。

でもそれは人は育たないし、自分の仕事ではなくなってしまう。

その観点で言えば、全部自分でやりきったという事実において差し戻しになったとはいえ、途中までやりきろうとしているし、諦めていないので失敗ではない。

コンピテンシ的には、

などを発揮している。ただ、ステークホルダーをマネジメントすることにおいては意識が回っていなかった、というところだろうか。

なるほど、こういうときにPMBOKのステークホルダーマネジメントを活用できるのか、などと気づかされる。

ステークホルダーマネジメントでは、

などあるが、それは、

に左右されるからである。

それでステークホルダは何に関心を持つかと言えば、

などが関心事になるようであるが、既得権なり裁量に対してどのような影響があるかで判断すれば良いのだろう。

つまり、先様の損得を考えずにいきなり持っていくと地雷を踏み抜くことがあるから、何に関心を持っているかを踏まえて、物の言い方を考えなさい、ということだろう。

例えば本社部門が施策をする際に、事業部門にコスト配賦をするとき、伝える内容は同じでも、物言いを上手くした方が受けれられやすいということだ。

PMBOKにこうしたことがプラクティスとして章を割いて載せているということは世界どこでもどの業種でも同じ構造だと知ることができる。

まあ、エンジニア的には組織のコミュニケーションをハックするような物で、物言いはコードの書き方のような話なのかもしれない。