PMstyle 2024年11月~2025年3月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 【PMstyle Kit No.11(2/2)】メンバーからリーダーに「変化」する(後)《PMstyle》 | メイン | 【PMスタイル考】第16話:マネジメント過剰・リーダーシップ不足 »

2011年8月17日 (水)

【一期一会】プロジェクトリカバリーマネジメント~システム思考でデス・マーチを撲滅する

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

【狙い】システム思考を応用したリカバリーマネジメントができるようになる

【対象者】プロジェクトリーダー、PMO

【効果】リカバリーの実施に関する意思決定の基準を知ることができ、さらに、「まず、安定化」を基本方針としたリカバリーの方法を習得できる

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

__《 このセミナーの効用は 》___________

知識を得る   ★★★★
実行力を高める ★★★★
思考力を高める ★★★★


__《 このセミナーへのイントロ 》___________

プロジェクトマネジメントへの熱心な取り組みにより、納期に遅れたり、予算をオーバーするプロジェクトは減ってきました。一方で、IT業界で「デス・マーチ」と呼ばれるプロジェクトの割合はそんなに減っていません。

デスマーチという言葉は、ソフトウエアエンジニアリングの大家の一人であるエドワード・ヨードンが軍隊の「デス・マーチ」という訓練に見立てて命名したと言われています。具体的には、

人員不足、短すぎる開発期間、予算不足、ユーザからの過剰な要求などの悪条件が重なり、開発チームが過度のオーバーワークや疲弊状態に陥った状態

を指します。

デス・マーチはスタティックな(静的な)問題として取られられる傾向があります。つまり、受注条件、あるいは、要求です。このため、組織として、受注条件や要求の評価(見積もり)に力を入れ、初期のリスク対応をすることによって対応しようとします。

しかし、現場のプロジェクトマネジャーは肌で感じているように、デス・マーチはダイナミックな問題です。しかも、悪循環という典型的な「システム」問題です。したがって、デス・マーチを回避したければ、システム思考的アプローチをする必要があります。

つまり、悪循環を断ち切り、プロジェクトを落ち着かせた上で、好循環を生み出すような手を打っていきます。

たとえば、上のデス・マーチの記述を見てください。開発期間が短く、要員も足らないので、無理な作業(突貫工事)をします。すると、メンバーはだんだん疲れてきて、成果物の品質が下がってきて、リワークが発生します。それによって、スケジュールがますます、苦しくなります。

そこで、新規の要員を追加投入します。すると、コミュニケーションの負担が増え、既存メンバーの生産性はますます下がり、スケジュールに悪影響を与えます。

実際に、以前にメンバー10名ほどのトラブルプロジェクトで生産性の分析をしたことがあります。このプロジェクトでは顧客との要件合意に齟齬があり、徐々にスケジュールが遅れ、組織として介入するレベルに悪化したので、要員投入を行いました。しかし、その2か月後には生産性が当初計画の30%強まで落ちていきます。初期計画が妥当だったとしても、10人が3人分しか働いていないわけですので、初期要員を倍にしても間に合わないことになります。

作業効率もそれなりに落ちましたが、ここまで落ちたのは作業従事時間の問題で、人が増え、打ち合わせがやたらと増え、当初計画の80%がなんと40%まで落ちたのです。

 

Death

図:デスマーチのダイナミックス

ここで、重要なポイントは、要員投入をするタイミングで、生産性の低下が続いていたことです。さらにスケジュールを遅らせてもよいので、まずは生産性の低下を防ぐべきだったのです。これがデス・マーチを起こさないリカバリー・マネジメントの方法です。

この講座は、デス・マーチを起こさないリカバリーマネジメントの方法を体系的に解説します。


__《 このセミナーの超エッセンス 》___________


リカバリーの難しいのは、リカバリーを行うかどうかの判断と、どのようなリカバリーの方法を取るかのアイデアです。

リカバリーは多くの場合、上位組織が危機感を持って始まります。そこで、まず大切なことは、先入観を持たず、情報を集めることです。情報には

・どういう問題が起こっているのか
・プロジェクトの状況はどうなのか

の2つがあります。前者は単純なようで結構複雑です。たとえば、スケジュールが遅れていることが常に問題になるのは、QCDの中でもスケジュールがもっとも関心の高い事項です。しかし、スケジュールが遅れているのは結果であって、問題は品質にあるといったことがよくあります。注意してほしいのは、品質が原因で、スケジュールが問題ではないということです。

何が問題化を見極めることが重要です。スケジュールを問題だと考えると要員追加をすれば問題は解決するという話になりますが、品質を問題としてみると、要員追加は問題解決にはなりません。これがレバレッジなのです。

つまり、問題を特定するというのは、何を問題としてみればよいかを特定するということであって、上位組織が問題だと思っていることを問題だと考えるということではありません。

もう一つはプロジェクトの状況ですが、これは、

・プロジェクトマネジメント手法の適用
・プロジェクトマネジメント支援状況
・母体組織のプロジェクトへの関心
・プロジェクト作業計画
・チームと主要ステークホルダ

などを見る必要があります。講座では、具体的な方法を解説します。これらの結果を踏まえて、リカバリー・デシジョン・パッケージを作り、上位組織の最終判断を仰ぎます。

二番目のポイントはどのようなリカバリーの方法を取るかです。リカバリーは具体的にはベースライン変更です。状況を踏まえ、問題を解決するようなベースライン設定をする必要があります。この際に大切なことが2つあります。

一つが、まずはプロジェクトを安定化させるということです。これは、ディシジョンと深い関係があります。たとえば、現時点で12日の遅れがあったとします。4週間前は遅れが9日だった場合と、4週間前は遅れておらず、直近の2週間で12日分遅れた場合、どちらが深刻でしょうか?

デス・マーチが起こるのは前者です。しかし、(特に上位組織が)慌ててしまうのは後者です。後者は原因にもよりますが、プロジェクト自体は安定しており、ほとんどリカバリーの必要はありません。遅れの原因を除去したところで、挽回(是正)すればよいだけです。

後者の場合には、まず、遅れの拡大を何とかしないと、手を打っても裏目に出ることが多くなります。遅れの拡大を取り除くことが安定化です。これを基本方針にして、どのような手を打つかを決めれば、よいアイデアが出てきます。

講座では、典型的なパターンに対するアイデアを紹介します。

__《 このセミナーのURLは 》___________

http://www.pmstyle.biz/smn/recovery20.htm

コメント

コメントを投稿