ベンチャー2年目　やってはいけないプロジェクトマネージメント①WBS編

プロジェクトマネージメントとは

プロジェクトマネージメントとは、多数の書籍、講習もあり、いろんなところで勉強ができます。
わたしが体系的に学ぶことができたのが以下の本になります。
こちらは、初心者にもおすすめです。
できるPMになるには、勉強と経験を繰り返すことで身に付くと思います。
PMは、負担も大きく、ストレスも溜まります、孤独になります、逃げだしたくなる時もあります。ダメなときは、開き直りも大事です。

プロジェクトマネジメント標準 PMBOK入門: PMBOK 第6版対応版

やってはいけないプロジェクトマネージメント

20代、30代では、いろんなプロジェクトを経験しました。
プロジェクトマネージメントが理解できるようになったは、40代になってからだと思います。今では、リスクが高いプロジェクトは、顧客との関係性や、プロジェクトのスコープ、メンバーのアサインなどである程度リスク軽減できるようになりました。
それまでは、失敗も多く、あまり思い出したくないプロジェクトもあります。
ここでは、やってはいけないプロジェクトマネージメントを紹介したいと思います。
初回は、やってはいけない、自己流プロジェクトマネージメント　WBS編です。

自己流のプロジェクトマネージメント

わたしは、SE、プロジェクトリーダーを経験し、プロジェクトマネージャーになりました。
今考えれば、なぜそんなことを、と思い恐ろしくなりますが、当時はそんなことを考えることもなく、やっていました。
それが、自己流のプロジェクトマネージメントです。
それまで、プロジェクトは複数経験があり、WBSや課題管理など、何となくどう進めるかはイメージができていたため、当時のわたしは、プロジェクトマネージャの依頼があった時に、違和感なく承諾しました。

WBS作成

プロジェクト準備で最初に始めることが多いのがWBS（Work Breakdown Structure）です。
良いプロジェクトでは、プロジェクト計画書があり、マスタースケジュールが設定されていて、そこからブレイクダウンしてWBSを作成します。
当時は、プロジェクト計画書も書けず、プロジェクトの最後から逆引きしたWBSを作成していました。
もちろん、逆引きしているので、期限がタイトなタスクも多く、担当者の割り振りも、アサインされたメンバーをスキルセットで割り当てます。
そうなんです、、、
WBSを作成するのがゴールになっていて、出来上がったWBSは、実現性が低いWBSになっていました。
そして、そのままプロジェクトを開始していました。

期限に追われるプロジェクトマネージャー

プロジェクト開始後、直ぐに遅延が発生します。
担当に割り当てたタスクに無理があるので、当然の結果です。
リカバリーは、気合と根性で乗り切る(笑)
はい、残業してリカバリーします。
週次の報告では、遅延の対策を報告する必要があり、内部の打ち合わせ、リカバリーの対応策の資料作成など、本来のタスク以外に時間が奪われます。
プロジェクトのフェーズが進むごとに遅延がリカバリーできなくなります。

プロジェクトの遅延

プロジェクトが全体的に遅延しました。
顧客、内部の報告も辛くなります。
報告の日は、胃が痛くなります。
そんな遅延を魔法のように乗り切る手段があります。
それは、”終わったことにする”です。
この魔法は、一時的な効力しかありません。
効力というか、時間稼ぎ的なやつです。。。
本来、予定していた作業をやり方を変えて、終わらせます。
端的に言うと、作業を端折る、です。
もちろん、品質が低下するリスクがありますが、全体の遅延をリカバリーするためには、言ってられません。

追いつめられるプロジェクトマネージャー

プロジェクト状況は、更に悪化します。
進捗を出すために、タスクを終わらせることを優先し、テスト工程で品質が割ることが発覚します。
発生している不具合に対して、原因分析を行います。
もちろん、設計での検討や調査、検証が足りていないので、品質が低下します。
不具合報告の重たいタスクが増えることで、更に状況は悪化し、プロジェクト全体の士気が下がってきます。
わたしのメンタルもえぐられてきます。。。
毎日、出社するのが嫌になってきます。

他責にする

心の中では、他責にしています。

プロジェクト受注時のスケジュールに無理があった。
プロジェクトの難易度が高かった。
アサインされたメンバー足りなかった。
顧客が悪かった。
運が悪かった。

などなど。
今考えるとお恥ずかしい限りです。。。

学んだこと

このプロジェクトがどうなったかと言うと、
リリース日は、変わらず、品質が低い状況の中、リリースされました。
リリース後、不具合は見つかり、対応に追われましたが、プロジェクトメンバーがひとつひとつ対応してくれて、何とかプロジェクトを完了することができました。
メンバーに恵まれました。

正直このプロジェクトが終わった後、直ぐには振り返りができませんでした。
この後のプロジェクトで徐々にできなかった点が理解できるようになり、何を準備できるようにならなければいけないかを学びました。

WBS作成では、以下の点に注意して作成しています。

１．プロジェクトのマイルストーンを意識する
２．各工程のタスクを洗い出す
３．タスクの前後関係を確認する
４．スケジュール全体を確認し、無理なポイントがないか確認する
５．メンバー含めて、WBSをレビューする

これがすべてではありますが、この時点でスケジュールに無理があったり、メンバーが足りなかったりした場合は、スケジュールや、メンバーアサインを調整します。
WBSを作るのがゴールではなく、実現可能なWBSを作ることが目的です。
そして、WBSのタスクは、プロジェクトの進捗によって、増減します。
昨今のプロジェクトでは、経験のない技術や、実績のないソリューションなどを扱うことも増え、プロジェクトマネージメントの難易度があがってきています。
あまり最初にきっちりとした、計画を立てようとせず、メンバーと意識を合わせて、柔軟にプロジェクトを推進するマネージメントが求めらているように感じます。
自己流では乗り切ることが難しいので、自己学習が大事ですね。