2008/09/18 バックナンバー
最近、参画しているプロジェクトが忙しくなってきてます。
今、大変な状況に置かれている金融業界の中の某社のプロジェクトにて、
プロジェクトが開始した後、このままでは頓挫しかねないという状況のなか、
助っ人としてプロマネで入らせてもらいました。
キックオフ後に参画したので、予算や人的リソースも自分で見積もり、
アサインをかけたわけではなく、リソースは既に決まっていて、
動いている中にマネージャーとして入ったわけで、まぁ、
キャッチアップに時間がかかるだろうなぁと覚悟はしていました。
初日からスケジュール・タスク・工数を既にあるものから書き換えて
作りあげ、メンバー一人一人の名前・年齢・特性・バックボーンなどを
さりげなくヒアリングしたりなどして、もうかれこれ１ヶ月以上が経過しました。
顧客のカウンターパートと進捗、メンバーとの調整などをこなしていきながら、
帰属する組織のラインマネジメントとプロジェクトとしてその目的を切り出した形で
運営する組織体のマネジメントにおいて、共通する部分と固有の部分が、
自分のなかで改めて明確化できたのは、大きな収穫になりました。
そして、共通する部分というのが、マネジメントの根本であり、
それらはどの組織に行ってもやはり共通します。
カウンターパートもメンバーも自分より年上で、なお且つプロジェクトについて
一番よく理解していない状況でマネジメントをはじめても、メンバーを馴らし、
顧客のカウンターパートから高い評価をえて、信頼関係を築いていくプロセスは、
シチュエーションによって変化はあるにせよ、おさえるポイントは同じです。
どっかで聞いた言葉だけど、自信が確信に変わりました。
一番大きいポイントは、顧客にしてもメンバーにしても、
細かく言えば交渉力だとか判断力だとか実行力だとか、そういう表現で表せる
能力もかなり必要だけど、それらを持った上でのコミュニケーション力が大事です。
管理能力を持っているが、それらを表に出す表現力も必要で、自分がマネージャーとして
目的を果たすのに、何を管理してどう推進しているのか、今現在どこまで進んでいて、
それは予定通り進んでいるのか、遅れているのか、遅れている場合どれくらい遅れているのか、
それらをリカバリするのにどれくらいの期間とコストを要するものなのか、
わかりやすく表現するのに、数値化は必須ですね。
そして、それらを報告資料としてコミュニケーションをとることも重要で、
報告資料は一つのコミュニケーションツールであるという認識ができていない
マネージャーは、けっこう多いのではないでしょうか。
それらもふまえてコミュニケーションであるという認識があるかないかで、
マネジメント力という総合的なものに大きな差が出てくるものです。
もちろん、報告資料だけではなく、提案資料や計画書・企画書などもそうです。
なので、これら計画書や報告資料などは、一目見れば作成者のマネジメント力がある程度
はかれると言っても過言ではとないと思います。
プロジェクトマネージャー用の参考資料や、色々な概念のもとに作成された手法などは
一長一短であり、必ずどこかに落とし穴があります。
落とし穴があることをわかっていてその手法をとり、補っていくものが明確になっていれば
問題はないけど、手法にこだわりすぎて、策に溺れるパターンが多いようですね。
今のプロジェクトで、私が採用した進捗管理の手法は、スケジュールとコストの予算実績を
マトリックス的にいくつかの指標にて分析する手法をとっています。
よくあるのは、一つのタスクに対して、その進捗率は５０％です。
という報告に対して、その５０％の分母は一体何？？ という議論。
ＩＴに限らず、色々なプロジェクトで物議をかもし出す"進捗率"、
プロジェクトにおいては、たいがいは、プロジェクト計画書にて％の定義をし、
それらで運営しています。
あるドキュメントを作成するというタスクにて、目次作成完了で２０％・本文作成完了で５０％・
内部レビュー完了で７０％・顧客レビュー完了で９０％・清書完了で１００％ というように。
これって、どうも違和感あるんですよね。その定義であれば、％で表現しなくても良くて、
厳密ではないんですよね。 他では、ドキュメントの予定総ページが１００枚で、１００枚を分母として
何枚書いたかで進捗率を出したりっていうのもあるけど、枚数なんかいくらでも水増しできるし、
枚数が完了したからそのタスクが完了するのかというと全然違う。
それらの管理手法で実際に管理をすると、８０％という報告があってから、
１ヶ月過ぎても８０％のまま、でも実際はタスク担当はその作業をしていないわけではなく、
夜遅くまで行っていたりし、実態を管理しているとはとても言えるようなものではないですよね。
システム案件のテストのフェーズにおいて、テスト項目が洗い出され、一つ一つの項目にかかる工数が
わかっているような簡単なものであれば良いけど、ソリューションを模索しながらドキュメントを
したためていくようなタスクには意味がない。 今回はそのようなケースなので、
アンドバリュー分析と改善目標指標というのをスケジュールとコストの観点から使い分けて、
進捗を管理する手法で取り組んでいます。
[ＢＡＣ](Budgeted At Completion：完了時総予算)
< 概要 >計画したプロジェクト完了時の総コストを示す。単位は工数(H)。
[ＣＶ](Cost Variance：コスト差異)
< 概要 >計画したコストと実際に要したコストの差分を示す。単位は工数(H)。
<値の意味>CV = 0：計画通り CV > 0：計画内 CV < 0：計画超過
< 計算式 >CV = EV - AC
[ＣＰＩ](Cost Performance Index：コスト効率指標)
< 概要 >コスト消化の効率性を評価する指標。
<値の意味>CPI = 1：計画通り CPI > 1：計画内 CPI < 1：計画超過
< 計算式 >CPI = EV / AC
[ＳＶ](Schedule Variance：スケジュール差異)
< 概要 >計画したスケジュールと実際にのスケジュールの差分を示す。単位は工数(H)。
<値の意味>SV = 0：計画通り SV > 0：計画内 SV < 0：計画超過
< 計算式 >SV = EV - PV
[ＳＰＩ](Schedule Performance Index：スケジュール効率指標)
< 概要 >スケジュール消化の効率性を評価する指標。
<値の意味>SPI = 1：計画通り SPI > 1：計画内 SPI < 1：計画超過
< 計算式 >SPI = EV / PV
[ＥＴＣ](Estimate To Completion：現時点から完了までのコスト予測)
< 概要 >現時点からプロジェクト完了までに要するコストの予測値。単位は工数(H)。
< 計算式 >ETC = (BAC - EV) / CPI ETC(最大) = (BAC - EV) / (CPI * SPI)
[ＥＡＣ](Estimate At Completion：完了時コスト予測)
< 概要 >プロジェクト完了時点で要するコストの予測値。単位は工数(H)。
< 計算式 >EAC = AC + ETC EAC(最大) = AC + ETC(最大)
[ＶＡＣ](Variance At Completion：完了時コスト差異)
< 概要 >予算とプロジェクト完了時点で要するコストの差分。単位は工数(H)。
<値の意味>VAC = 0：計画通り VAC > 0：計画内 VAC < 0：計画超過
< 計算式 >VAC = BAC - EAC VAC(最大) = BAC - EAC(最大)
[ＥＡＣスケジュール](Estimate At Completion：完了時スケジュール予測(期間表示))
< 概要 >プロジェクト完了時点で要する日数の予測値。単位は日。
< 計算式 >EACスケジュール = タスク予定日数 / SPI
[ＶＡＣスケジュール](Variance At Completion：完了時スケジュール差異(期間表示))
< 概要 >計画期間とプロジェクト完了時点で要する日数の差分。単位は日。
<値の意味>VACスケジュール = 0：計画通り VACスケジュール > 0：計画内 VACスケジュール < 0：計画超過
< 計算式 >VACスケジュール = タスク予定日数 - EACスケジュール
[ＴＣ＿ＣＰＩ](To Complete Cost Performance Index：計画通り完了するために必要なコスト効率指標)
< 概要 >計画したコスト以内に完了するために必要なコスト効率指標。
<値の意味>TC_CPI = 1：現行のままの生産性で計画通りのコストで終了予定
TC_CPI > 1：計画通りのコストで終了させるためには、生産性の向上が必要
TC_CPI < 1：生産性は高くコストに余裕がある
< 計算式 >TC_CPI = (BAC - EV) / (BAC - AC)
[ＴＣ＿ＳＰＩ](To Complete Schedule Performance Index：計画通り完了するために必要なスケジュール効率指標)
< 概要 >計画したスケジュール以内に完了するために必要なスケジュール効率指標。
<値の意味>TC_CPI = 1：現行のままの生産性で計画通りのスケジュールで終了予定
TC_CPI > 1：計画通りのスケジュールで終了させるためには、生産性の向上が必要
TC_CPI < 1：生産性は高くスケジュールに余裕がある
< 計算式 >TC_SPI = (BAC - EV) / (BAC - PV)
[ＣＰＩ要改善倍率]
< 概要 >計画したコスト以内に完了するために必要なコスト効率指標の向上倍率を示す。単位は倍。
<値の意味>CPI要改善倍率 = 1：現行のままの生産性で計画通りのコストで終了予定
CPI要改善倍率 > 1：計画通りのコストで終了させるためには、生産性の向上が必要
CPI要改善倍率 < 1：生産性は高くコストに余裕がある
< 計算式 >CPI要改善倍率 = TC_CPI / CPI
[ＳＰＩ要改善倍率]
< 概要 >計画したスケジュール以内に完了するために必要なスケジュール効率指標の向上倍率を示す。単位は倍。
<値の意味>SPI要改善倍率 = 1：現行のままの生産性で計画通りのスケジュールで終了予定
SPI要改善倍率 > 1：計画通りのスケジュールで終了させるためには、生産性の向上が必要
SPI要改善倍率 < 1：生産性は高くスケジュールに余裕がある
< 計算式 >SPI要改善倍率 = TC_SPI / SPI
元ネタ(進捗のインプット)は、ガントチャートやＷＢＳに用意し、スタッフから密な報告を受け、
上記を計算し、プロジェクトの進捗を分析・管理しています。
顧客もメンバーも、こんな細かい管理手法は今まで見たこともないと口ぐちに言っており、
理解するのに少々時間がかかったけど、逆に顧客からはここまで高度な管理を行ってもらえて
嬉しいと、満足度があがり、自身の管理も楽になったので良かったです。
やはり、こうやって、一般的にどこにでもあるようなサービスを提供するのではなく、
独自性や特異性を持ち、且つ品質の高いサービスを提供することで、
顧客の満足度をえていくものだと、改めて感じます。
そしてその顧客の目が肥えていて、レベルが高くしきいの高い顧客であればあるほど、
自分の市場価値もあがるということで、お互いにWinWinな関係という事が、ビジネスの根本で
あり、これらが小さいところでも行われることで、微力ながら社会に貢献できていると実感します。
今後の個人的な話としては、しゅくしゅくとプロジェクトを進めながら、更新時の単金交渉にのぞもうかと、
そういった流れと、このプロジェクト以外に話がある、某ソフトウェア会社との怪しい動きや、
とある企業の新規事業立ち上げなどで、また違う領域での仕事があり、正式に受託できるよう、
中身のつまった提案資料を作成し、営業活動の時間を作っていくという、
時間的にも中身的にも、比較的ドＭな感じの今日この頃です。
