なぜプロジェクトマネジメントが機能しないのか 22 タスクの全量性④

日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はＰМ、ある時はＰМОとして、お客様と問題解決に取り組んでいます。本記事では、まだＰМＢОＫには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います。
マガジン：https://note.com/think_think_ab/m/m0e070db46016

成果物と成果物の間

本記事の第２１回 タスクの全量性③（https://note.com/think_think_ab/n/n3ce2219683c2）では、
タスクの全量性を確保するため、
まずは最も大きな粒度で成果物の全量性を確保し、

そのうえで
各成果物を分割して、タスクブレークダウンすることを説明しました。

この際、実は
必ずといっていいほど、抜け落ちてしまうタスクがあります。

それは、
成果物と成果物の間のタスク、すなわち、
成果物を分割した際に必要となる、分割した成果物の結合試験タスクです。

結合試験タスクは、
別々のチームや担当者が作ってきたものを、それぞれ出来上がったところで
あわせて全体として正しく機能するかどうかを確認するタスクです。

このタスク（結合試験）が定義されている場合もありますが、
結合試験の準備タスク（試験項目や日程計画の準備やすり合わせ）が
定義されている場合はほとんどありません。

特に、部門や委託先が分かれている場合は、その傾向があります。

試験準備もなく、
ある日突然、結合試験の初日を迎えるＷＢＳになっているのです。

さらに、
そんな肝心のタスクが抜けた状態のＷＢＳであっても、
プロジェクト半ばまで、場合によっては本当に試験前日まで、
誰もそのことを指摘しない場合もあります。

本当にそんなことがあろうか、と思われるかも知れませんが
そんなことがあるのです。

なぜこんなことが起こるのでしょうか。

組織の脆弱性

原因は組織の脆弱性にあります。
＊組織の脆弱性については、本記事の第４回でも少し触れました。

組織のメンバーは、リーダーも含め、
自分の所属する部門の中のことはとても上手にこなしますが、
タスクや課題が部門をまたがったとたんに機能しなくなります。

タスクや課題が、自分の所属する部門も関係はあるものの、
球が部門間に落ちているに気づきつつ、それをひろうべきか迷ってしまう。あるいは、あるときはあえて気づいていないふりをします。

いわゆる「ポテンヒット」です。

組織人としては、通常のふるまいで、
そもそも組織が持つ特徴のため、精神論だけでは解決されません。

ちなみに、
リーダークラスよりも上の部長や本部長クラスは、
暗に優秀なリーダー間の調整能力に期待しますが、それは幻想で、

組織の特徴に原因のある問題は、
個人的な能力や、精神論や、コミュニケーションでは解決できません。

では、どうすれば解決できるのでしょうか。

それは、
ポテンヒット性の玉を拾う機能を組織的に持つことで解決できます。

具体的には、
部門間のボールを落とさないよう、遊撃手としてＰＭＯを設置します。

ＰＭＯが正しく機能することで、
部門が横串しで統合され、縦割り組織のもつ脆弱性を補うことができます。

ＰＭＯが定着してきた昨今であっても、
具体的なやり方が形式知化していないためか、
本機能がＰＭＯの役割として説明されているのはあまり見かけません。

本来は、
ＰＭが上述のＰＭＯの機能を果たせることが望ましいですが、

昨今のように
複数部門や複数の会社をまたがったプロジェクトが多くなってくると、
ＰＭは自分の所属部門以外の部門への権限の行使は控えるようになります。

これも、
そもそもＰМが原因ではなく、組織の持つ特徴が原因のため、
ＰＭの能力や精神論に期待するだけでは解決できません。

そこで、
既存の組織とは直接の関係がない（しがらみのない）
外部リソースによるＰＭＯを配置させ、機能させることで、解決できます。

現代では、
ＰＭＯは単なるＰＭの事務手続や定常業務の負担軽減だけの立場ではなく、

ＰＭ同様、
プロジェクトの統合に暗に責任を追う、
ＰＭの代理としての機能が求められるようになってきています。

ただし、
ＰМと違って、権限がありません（ＰМОには責任もありませんが…）
権限がない中で、ひろったポテンヒット性の球を

しかるべき人やチームに球を持っていただき、
推進して頂く必要があります。

どうすれば、それができるのでしょうか。
それは、また機会を見て説明していきます。

次の記事（２３回）
↓