そう評価されるPMを思い浮かべてみてください。

もしかすると、

「大きなトラブルが起きたプロジェクトを立て直したPM」

ではないでしょうか。

顧客から大きなクレームが入った。

スケジュールが大幅に遅れた。

プロジェクトが赤字になりそうになった。

メンバー間で大きな対立が起きた。

そんなプロジェクトをPMが見事に立て直す。

こうしたPMは、確かに目立ちます。

一方で、

「何の問題も起こさず、予定通りプロジェクトを成功させたPM」

はどうでしょうか。

こちらも、もちろん優秀なPMです。

しかし、なぜか前者ほど目立たない。

私は、ここにPMの評価の難しさがあると思っています。

トラブルが起きると、PMは一気に目立つ

特に経営層から見た場合、この傾向は強くなると思います。

経営層は、会社で動いているすべてのプロジェクトを細かく見ることはできません。

数十、数百のプロジェクトが動いている会社であれば、なおさらです。

では、経営層のところにどんなプロジェクトの情報が上がってくるでしょうか。

当然、

• 大きなトラブルが起きた
• 大幅な遅延が発生した
• 大きな損失が発生しそう
• 顧客から重大なクレームが入った
• プロジェクトの継続が危ぶまれている

といったプロジェクトです。

つまり、

問題が起きたプロジェクトほど、経営層の目に入りやすい。

これは、ある意味当然です。

経営層は、問題のないプロジェクトをすべて確認する必要はありません。

しかし、問題が起きているプロジェクトには対応する必要があります。

その結果、

トラブルを解決したPMは、経営層から見ても非常に目立つ。

という構造が生まれます。

「トラブルを解決したPM」が評価されやすい理由

例えば、こんなプロジェクトがあったとします。

プロジェクトAは順調に進んでいます。

PMが、

• リスクを事前に潰す
• 顧客と認識を合わせる
• メンバーの問題を早期に発見する
• スケジュールの遅延要因を事前に潰す

といった活動をしています。

結果として、大きな問題は起きませんでした。

プロジェクトは予定通り完了しました。

一方、プロジェクトBでは大きなトラブルが発生しました。

経営層にも報告が上がります。

担当PMがプロジェクトを立て直し、最終的には成功させました。

どちらのPMが経営層の記憶に残るでしょうか。

おそらく、プロジェクトBのPMです。

なぜなら、

経営層がPMの仕事を見るきっかけがあったからです。

これが、トラブルを解決したPMが評価されやすい理由の一つだと思います。

トラブルがないと、PMの仕事そのものが見えない

さらに問題なのは、

PMが何をしているのかが見えなくなること。

です。

プロジェクトが順調に進んでいると、

「特に問題ありません」

という報告になりがちです。

しかし、その「特に問題ありません」の裏側では、PMがさまざまな活動をしているかもしれません。

例えば、

• リスクを事前に潰している
• ステークホルダーの認識を合わせている
• メンバーの不満を早期に拾っている
• チーム間のコンフリクトを解消している
• 顧客の期待値を調整している
• 遅延につながる要因を先回りして対応している

などです。

ただし、これらの活動は、

問題が起きなかった瞬間に、存在していなかったかのように見えてしまいます。

「何も起きなかった」と「何もしなかった」は違う

ここは非常に重要です。

プロジェクトでトラブルが起きなかった。

だからといって、

「PMは何もしなかった」

わけではありません。

むしろ、

PMが何かをしたから、トラブルが起きなかった。

可能性があります。

例えば、

「顧客から仕様変更の要求が出てきそうだった」

↓

PMが事前に顧客と認識を合わせた。

↓

仕様変更が発生しなかった。

この場合、結果だけを見ると、

「仕様変更はありませんでした」

となります。

しかし実際には、

PMが事前に動いたことで、仕様変更による混乱を防いだ。

とも考えられます。

この差は非常に大きいと思います。

予防型PMの成果は「起きなかったこと」

トラブルを起こさないPMの特徴は、

成果の中に「起きなかったこと」が多い。

ことです。

• 発生しなかった遅延
• 発生しなかったクレーム
• 発生しなかった品質問題
• 発生しなかったコンフリクト
• 発生しなかったコスト超過
• 発生しなかった重大リスク

こうしたものは、実際にはプロジェクトにとって非常に価値があります。

しかし、

起きなかった問題には、目に見える「事件」がありません。

そのため、評価する側からすると難しいのです。

「トラブルがないPM」と「トラブルを解決したPM」を比較してみる

もちろん、これは「トラブルを解決するPMより、トラブルを起こさないPMのほうが必ず優秀」という意味ではありません。

予想外の問題に対応する能力も、PMにとって重要なスキルです。

ただ、

評価されやすさには違いがある。

ということです。

では、評価されないことを受け入れるしかないのか？

私は、そうは思いません。

ここで重要なのが、

PM自身が自分の仕事と実績をPRする。

という考え方です。

「トラブルが起きなかったから、自分の仕事を説明できない」

ではなく、

「なぜトラブルが起きなかったのか」を説明すればいい。

のです。

例えば、

「問題なくプロジェクトを完了しました」

だけではなく、

「プロジェクト開始時に15件のリスクを特定し、そのうち重要度の高い5件について事前対策を実施しました。その結果、重大な遅延や品質問題を発生させることなく完了しました。」

と説明する。

これなら、PMが何をしたのかが見えてきます。

重要なのは「定量化」

ここで特に重要になるのが、

実績を定量的に示すこと。

です。

「ステークホルダーとの関係を改善しました」

という説明では、人によって評価が変わります。

「かなり改善した」と感じる人もいれば、

「それで何が変わったの？」

と思う人もいるでしょう。

一方、

「ステークホルダーとの定例会を月1回から週1回に変更し、意思決定事項を○件明確化した」

などと具体的に示せば、評価する側も判断しやすくなります。

「リスクを潰した」を数字で示す

例えば、リスクマネジメントなら、

「リスクを適切に管理しました」

ではなく、

「プロジェクト開始時に20件のリスクを特定し、重要度の高い8件について事前対策を実施した」

とします。

さらに、

「そのうち3件は、対策をしなければ納期遅延につながる可能性があった」

まで説明できれば、より価値が伝わります。

もちろん、数字を作るために無理に数値化する必要はありません。

大切なのは、

自分が実際に行った活動と、その結果をできるだけ客観的に示すこと。

です。

プロジェクトによって「重要な活動」は違う

ここで注意したいのは、

「PMはリスクを何件潰せばいい」

という単純な話ではないことです。

プロジェクトによって、重要なポイントは変わります。

あるプロジェクトではリスクマネジメントが重要かもしれません。

別のプロジェクトではステークホルダーとの認識合わせが重要かもしれません。

また別のプロジェクトでは、メンバーの育成やチーム間の調整が重要かもしれません。

だからこそ、

何をしたかではなく、そのプロジェクトにとって何が重要だったのか

を説明する必要があります。

私自身も「トラブルを起こさないためのPM」を経験した

以前紹介した、若手2人と進めた小規模プロジェクトがあります。

メンバーは入社3年以内の若手でした。

前のプロジェクトでは、メンバーがプロジェクトマネジメントについて十分に理解していなかったことで、指示がうまく伝わらず、納期遅延を起こしてしまいました。

そこで次のプロジェクトでは、その経験を教訓にしました。

単に、

「これをやってください」

と指示するのではなく、

なぜ計画段階でリスクを考えるのか。

なぜスケジュールを立てるのか。

なぜコミュニケーションルールを決めるのか。

といったことまで説明しました。

その結果、メンバー自身がプロジェクトマネジメントを理解するようになりました。

そしてプロジェクトの途中では、メンバー自身が新たなリスクに気づき、

「このリスクがあります」

と自発的に伝えてくれるようになりました。

プロジェクトも問題なく進めることができました。

このプロジェクトで、私は大きなトラブルを解決したわけではありません。

しかし、

過去の失敗から教訓を得て、次のプロジェクトでトラブルを防ぎ、さらにメンバーを成長させた。

これも、PMとしての一つの実績だと考えています。

評価されるPMになるために、トラブルを起こしてはいけない

ここで一つ、絶対に間違えてはいけないことがあります。

「トラブルを起こしたほうが評価されるなら、トラブルを起こせばいい」

ということではありません。

当然ですが、これは本末転倒です。

PMの目的は、

自分が評価されることではなく、プロジェクトを成功させること。

だからです。

トラブルを起こして目立つより、

トラブルを起こさずプロジェクトを成功させる。

そのうえで、

「なぜ成功できたのか」を説明する。

これがPMとして正しい方向だと思います。

「評価されるPM」ではなく「評価できるPM実績」を作る

だから私は、

評価されるために仕事をするのではなく、評価できる形で実績を残す。

ことが重要だと考えています。

例えばプロジェクト終了時に、

• プロジェクトの目標
• 目標達成度
• プロジェクトの難易度
• 重要だった課題
• 自分が実施した施策
• 事前に防いだリスク
• 定量的な成果
• メンバーや組織に残したもの

を振り返ってみる。

そうすると、

「このプロジェクトでは何を成し遂げたのか？」

が見えてきます。

「何も起きなかった」を実績に変える

PMの評価を考えるとき、私はこの視点が重要だと思います。

例えば、

「納期遅延が発生しなかった」

だけでは、単なる結果に見えます。

しかし、

「過去のプロジェクトで納期遅延につながった要因を分析し、今回は○○という対策を実施。その結果、納期遅延を発生させずに完了した。」

と説明すればどうでしょうか。

そこには、

経験

↓

教訓

↓

対策

↓

結果

というPMの仕事が見えてきます。

これなら、「何も起きなかった」という結果も、PMの実績として評価できます。

PMの実力と評価のギャップを埋める

私は、PMには、

「プロジェクトを成功させる力」

と、

「自分がプロジェクトを成功させたことを説明する力」

の両方が必要だと思っています。

これは少し厳しい話かもしれません。

しかし、どれだけ優秀なPMでも、自分の実績を説明できなければ、市場では評価されにくいからです。

だから、

「自分はトラブルを起こさないPMだから、評価されなくても仕方がない」

と諦める必要はありません。

むしろ、

「トラブルを起こさないために、自分は何をしたのか？」

を整理する。

そして、

できるだけ定量的に示す。

これが重要です。

まとめ：トラブルを起こさないPMは、自分の仕事を見える化しよう

なぜトラブルを起こさないPMは評価されにくいのでしょうか。

それは、PMとしての実力が低いからではありません。

トラブルが起きないと、PMの仕事が見えにくいからです。

特に経営層は、すべてのプロジェクトを細かく見ることができません。

そのため、トラブルが起きて報告が上がってくるプロジェクトや、そのプロジェクトを立て直したPMのほうが目立ちやすくなります。

一方、トラブルを起こさないPMは、

リスクを潰した。

認識を合わせた。

問題を早期に発見した。

メンバーを支援した。

ステークホルダーを調整した。

といった仕事をしていても、それが見えにくい。

だからこそ、

PM自身が自分の実績をPRすることが重要です。

特に、

「何をしたのか」だけではなく、「どれだけの成果につながったのか」を定量的に示す。

これがポイントです。

トラブルを起こさないことは、決して「何もしなかった」ということではありません。

むしろ、

何も起きなかったという結果の裏側に、PMの高度なマネジメントが隠れていることがあります。

だから、PMとして目指したいのは、

トラブルを起こして目立つPMではなく、トラブルを起こさず、そしてその価値を説明できるPM。

私は、そんなPMこそ「PM戦闘力の高いPM」だと考えています。

あなたは、最近のプロジェクトで「起きなかったトラブル」をいくつ説明できるでしょうか？

そして、その中で自分がどんな行動をしたのか、数字で説明できるでしょうか？

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない

• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断してみる

• PM戦闘力を高めるには？

• PM戦闘力と転職・市場価値の関係