PMstyle 2024年7月~10月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 【PMスタイル考】第117話:価値を中心にプロジェクトを考える | メイン | 【PMスタイル考】第119話:コンセプトを作る »

2016年11月18日 (金)

【PMスタイル考】第118話:責任を設計する

バックナンバー https://mat.lekumo.biz/pmstyle/cat9747239/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Sekinin1

◆プロジェクトの進め方

今のプロジェクトマネジメントで教科書通りにできていないことの一つは、権限と責任の決め方です。プロジェクトマネジメントでは

(1)タスクを決める
(2)タスクを遂行する組織と責任を決める
(3)責任を果たせるように権限を決める

というのが普通の考え方ですし、多くのプロジェクトマネジャーはそのように認識していると思います。

ところが現実にはそうなっていないケースの方が圧倒的に多いように思います。まず決めているのはプロジェクト体制であることが多いようです。つまり、まず、権限を決めているのです。

そのように進めると、小さなタスクを実施するにも、意思決定をするに当たって政治的な要素が入ってきます。それを権限委譲してなんとかスムーズに進めようとしますが、政治の上の話になりますので、なかなかうまく行きません。どうしても、権限を持つ人が介入してきます。

ということで、今回のPMスタイル考は、責任と権限について考えてみたいと思います。


◆組織を設計するというイメージ

プロジェクト組織を設計するというと何をイメージするでしょうか。たいていの場合、「権限」を決めることです。例えば、プロジェクト体制として以下のようなプロジェクト組織を設計したとします。

A(事業部長) ── B(PS) ── C(PM) ── D
                     |
                      ─ E

このときに、AやBとCには上下関係があると考え、AはB、C、Dより権限を持つと考えられます。具体的には、A、BはC以下の行使する予算を承認したり、C以下に指示できるわけです。


◆まず、設計すべきは「責任」

このように「権限」から考えるのは、プロジェクトには事業部長の持つ権限の一部しか、与えないことが前提になっています。例えば、プロジェクトとして外部の企業とのパートナーシップを組むといった事業部長がもっていない権限をプロジェクトに与えることができないわけです。そして、このことがプロジェクトで取り得るアプローチを限定しています。これが例えばイノベーションプロジェクトの成功が生まれにくい一因になっていると考えられます。

すべきことは体制を決めることではありません。まず、すべきことは責任の設計です。つまり、投資の判断、品質の判断、販売の判断など、プロジェクトで想定されるいくつかの代表的な状況における意思決定の責任を明確にする必要があります。

その上で、責任を果たすための権限を決める必要があります。

しかし上に述べたように、多くの場合、プロジェクト体制から決め、権限を先に決めています。そうすると権限がやたらと増え、政治的な活動の必要性が多くなってきます。極論すれば、すべての意思決定をAやBの了解を取らなくてはならなくなります。

プロジェクトの生産性が低い最大の理由はこの点にあるように思えます。


◆プロジェクトの責任はプロジェクトによって異なる

特にプロジェクト組織の場合はこの原則は重要です。一般的な組織であればある程度、業務が決まっており、権限と責任が同期しているので、権限を決めれば責任がついてくるという見方もできます。

ところがプロジェクトの場合、定型業務ではないので責任はさまざまです。プロジェクトごとにしか想定できません。したがって一般的な組織の感覚でプロジェクトをやると先に述べたように、プロジェクトは交渉や根回しなど政治活動の連続になります。

そのため、権限から決めると責任が誰にあるのかわからないケースが出てくることがよくあります。こういう場合、結局、プロジェクトマネジャーが最終責任を取るということで、済ませてしまうわけです。つまり、いわゆる権限のない責任というのが出てくることになります。

最悪なのは、ここで権限委譲をしてしまうことです。つまり、意思決定が出てきた場面に遭遇したときにはじめて権限委譲をするわけです。このように進めると、すべての意思決定が政治的な活動になり、権限を持つ人の顔色を伺わざるを得なくなります。


◆OBSとRAMを使ったプロジェクト組織の設計をしよう!

最近、プロジェクトマネジメントの中でもステークホルダーマネジメントが注目されるようになってきました。その中で、よく聞く問題の一つにいわゆるプロジェクトスポンサーが責任を明確に認識していないという話があります。ところが観察していると、そのような場合でも権限は行使していることが多いようです。

要するに、プロジェクト組織を設計するときに、権限は組織の権限をそのまま持ち込み、責任はプロジェクトマネジャーにあると考えているケースが多いのが現実です。

プロジェクト組織の設計に関しては、OBS(Organization Breakdown Structure )という素晴らしい組織設計のツールがあり、また、責任の設計のツールとしてRAM(Responsibility assignment matrix)というツールがあります。これらを駆使して、まず、責任を設計し、責任を果たすための権限の設計をするようにしたいものです。

コメント

コメントを投稿