なぜプロジェクトはトラブってしまうのか? ~永遠の課題?
私は2002年からシステム開発の世界で仕事をしてきましたが、その当時からいままでずっとどこかしらでトラブルプロジェクトが起きていました。 それは別に自分の身の回りだけで起きていたわけでなく、業界を見回してもずっとどこかしらでトラブルプロジェクトは起きていました。
また、この業界には「デスマーチ」という名著があるくらいですので、やはりトラブルプロジェクトはいつの時代もある、ということなのでしょう。
トラブルプロジェクトは、なくならないものなのでしょうか?
おそらく、これから未来もトラブルプロジェクトはなくならないでしょう。
トラブルが大きくなり炎上してしまうと、いわゆる火消しPMがやってきます。 その火消しPMはだいたいの炎上は鎮火させてしまいます。いわゆる、スゴ腕PMです。
そのようなPM達を見ていると、このような人が最初からプロジェクトをやっていれば炎上しないんだろうなぁ、と思ってしまいます。
「じゃあ、その人達が重要プロジェクトをやればいいのでは?」と思うでしょうけど、だいたいどこの会社・組織もそのような人たちはどこかの炎上プロジェクトに入っていて、トラブってもないプロジェクトにアサインされることはほとんどありません。
一方で、炎上させてしまったPM達は、その後もどこかのプロジェクトのPMをやっていたりしますが、そのPMの実力値を超えたプロジェクトを任された途端にまた火がくすぶってしまいます。
『つまり、トラブルかどうかはPM次第だ!』と結論づけてしまうのも何とも雑ですので、なぜプロジェクトはトラブるのか、トラブらせないためにはどうすればいいのか、ということを今回は書いてみようと思います。
今回は、大きく2つの視点で考えます。大小問わず、トラブらないためのテクニックを上げると100個以上はすぐに出てきますが、文字数があっという間に溢れてしまうので、2つの大きなポイントに集約して書いていきます。
見積り通りに計画を立てるからトラブル
見積もったコストとスケジュールを下回って終わるプロジェクトはほとんどありません。成功したプロジェクトでせいぜい見積り通りで完了します。ちょっと規模が大きくなったり、難易度が上がったプロジェクトでは、9割以上のプロジェクトはコストやスケジュールが超過してしまいます。
なぜでしょう。
答えは簡単です。見積り通りに計画を立てるからなのです。
「ん?何を言っていのだろう?」と思ったかもしれません。「そりゃ、見積どおりに計画立てるだろう」と。
実は、見積りからプロジェクト計画を立てるとところに最初の大きな落とし穴が潜んでいるのです。
例えば、システム開発の見積りして、20人で2年かかる見積りとなったとします。工数としては240人月で、期間は2年という見積りです。そして、その見積りに沿って計画を立てます。
ここで、ほとんどのプロジェクトは20人で2年かかる計画を立ててしまうのです。
そして、見積りモレや見積りミス、想定作業のモレなどが大体あるので、それが発覚した瞬間にコストとスケジュールのどちらも計画内に収まらなくなってしまうのです。
そうならないために、コストバッファーとスケジュールバッファーを最初に確保しておかなければいけません。
当たり前に聞こえる話ですが、実際のプロジェクトの計画立案のときには、この当たり前ができていないのがたくさんあるのです。
その当たり前ができていない理由もあります。
ほとんどのプロジェクトの場合、開発チームや開発会社ごとに見積りを行い、それらを集約してプロジェクト全体の見積りになります。とすると、見積りをしたチームや会社に対して、見積りよりも少ない工数とスケジュールで計画を立てさせなければいけない、ということになり、当然、反発を食らってしまうのです。その反発に負けてしまい、見積り通りの計画を立ててしまうことになるのです。
じゃあ、プロジェクト全体でバッファーも含めて見積りをしておけばいい、と思いますが、プロジェクトの見積りは提示してから契約に至るまでの間にコストダウンという名のもとに見積りが削られていくのが常です。ですので、なかなかバッファーを持たせた見積りをできることはありません。できたらラッキーくらいに思っておくといいでしょう。
つまり、最初のプロジェクト計画の段階で、いかにコストとスケジュールにバッファーを持たせた計画が立てられるか、がポイントです。
想定外を想定内にしていなからトラブル
トラブったときもそうだし、コストやスケジュールが超過したときもそうであるが、プロジェクトがコケたときによく聞く言葉があります。
「 想定外のことがおきました」
いや、そんなの当たり前でしょ、と思います。 すべてのことが想定できて、想定通りに進むプロジェクトなんていうものは存在しません。
では、どうするのか、というと、禅問答のようになってしまいますが、
「 想定外のことが起きるということを想定しておく」
ことです。
そして、想定外が起きたときには「ほら、きた!」と言わんばかりに、即座に手を打ちましょう。
次の図を使って少し説明しましょう。
PMBOKの知識エリアごとに、状況をシグナルで示したものです。左から右に時間軸が進んでいく、というイメージでご覧ください。
プロジェクトの状況は刻々と変動するものです。
プロジェクトの立ち上げ当初はオールグリーンの健全は状況で進んでいますが、プロジェクト進むにつれて、品質やコスト、スケジュールなどで少し状況が芳しくなくなってきます。このときに、これらをグリーン戻せばまた健全な状態に戻ります。
このイエローシグナルになったときに放置していたり、きちんと対処しきっていなかったりすると、次第にイエローが増えてきて、レッドも増えてきて、最終的には真っ赤な炎上プロジェクトとなってしまいます。
そして、その理由が「想定外のことが起きました」となることが多いのです。
想定外のことは起きます。間違いなく起きます。まず、そう思っておくことで想定外のことが起きたときに焦らなくなります。まあ、ちょっとびっくりすることはありますけど。
実は、この心持ちが重要なのです。このように構えておけば、打ち手のための初動が速くなります。火がつく前の煙のときに消しておけば火はつきません。
『困難は背中を見せると大きくなる 向かっていくと小さくなる』
この繰り返しができるかどうかが、プロジェクトがトラブるかどうかの分かれ道です。
プロジェクト管理ツールを監修しました
私は、長年、数多くのトラブルプロジェクトを経験してきました。どのプロジェクトのときもそうでしたが、WBSや課題管理などにどのツールを使おうか、といつも悩んでました。
重厚長大すぎるツールや、帯に短し襷に長しといったツールもありました。
ちょうどいいプロジェクト管理ツール、というものがなかったので、今回プロジェクト管理ツールを作りました。作りました、といっても私がプログラミングしたわけではありませんが、PMコンサルとして活動している中でツール要件や仕様を決めてきました。
今後、機能拡張はしていきますが、プロジェクトで最重要のWBSや課題管理といったコアな機能からリリースしています。
まずはお試しで使えますので、よろしければちょっといじってみてもらえればと思います。
以前の記事に、プロジェクト管理で絶対におさえるべき3つの管理ということを書いていますので、こちらも読んでみていただければと思います。
参考書籍
トラブらないようにするためにはどうすればいいか、トラブってしまったらどうすればいいか、など、自分で経験する前に、まずは歴史上の経験から擬似的に学んでおいた方がいいです。
本を読めばトラブらないわけではないですが、とても多くのヒントを得ることができますので、ぜひ読んでおいた方がいいと思います。
私が読んできた本を以下に紹介します。
外資系コンサルが教えるプロジェクトマネジメント [ 山口周 ]
- 価格: 1540 円
- 楽天で詳細を見る