こんにちは、NAEです。
プロジェクトの計画は前提に基づいて立てられるもの。そのため前提が崩れれば計画は見直されてしかるべき。
にも関わらず、前提がもはや成り立たないことが判明してなお計画が見直されない場合があります。
するとどうなるか？答えは簡単。現場は死ぬ。
今回はそんなお話。
プロジェクトの前提事項は計画の土台
コンサルが提案書を書く時に必ず最後につけるページがあります。
「前提事項」です。
そこにはプロジェクトが計画通り実行されるための条件を書いていきます。
たとえば、
- プロジェクト開始時点で依頼事項一覧に提示しているインプットが提供されること
- 意思決定機関である会議体に十分な権限を持った人間が必ず参加すること
- クライアント社内のコミュニケーションはクライアント側の担当者にて実施すること
- クライアントのオフィスにわれわれ（コンサル）の作業スペースを提供いただくこと
といった感じ。
インプット資料が来なければクライアントの魂がこもった成果物は作れませんし、そもそも作業に着手できません。
意思決定が適時適切になされないと、決めたいことが決まらずにスケジュールが遅延します。
クライアントの社内コミュニケーションまでコンサルがやると、それだけコストにはね返ってきます。（やらない前提で見積もりを出している）
クライアントのオフィススペースを使わないと移動その他オーバーヘッドにより効率が落ち、仕事の進みが遅くなります。（そういう前提で見積もりを出している）
すべての計画は前提に基づいているのです。
プロジェクトの前提事項が崩れるとあらゆる計画が崩れる
そのため、前提が満たされなくなったらプロジェクトの計画は崩れます。
計画が崩れる、と言ってもプロジェクトには様々な側面の計画があります。
作業スケジュールが崩れる
わかりやすいものは作業スケジュールでしょうか。どのような作業をどのタイミングで行うのが記載されたスケジュールです。
例として、前提「インプットが適時提供されること」を挙げてみます。
たとえば、IT資産の現状分析の一環としてサーバ一覧がほしいと依頼したとします。
すると、そもそもそんな情報ないし管理もしていないよ、集めるには2週間はかかるよ、と言われてしまったら？
分析もなにもあったもんじゃないですよね。作業の着手が遅れ、スケジュールも後ろ倒しになります。
インプットは仕事の着手に必須です。仕事の構成要素であるSIPOCのI（Input）にあたるものだからです。
- S：Supplier・・・Inputの提供元
- I：Input・・・仕事に必要な情報など
- P：Process・・・仕事の手順
- O：Output・・・仕事の成果物
- C：Consumer・・・成果物の提供先
さて、インプットがもらえたとしても、含まれる情報が
- 記載範囲が狭い
- 粒度が粗い
- 歯抜けである
- どう読み取ればよいか不明
- 必要な人に承認されていない
など、情報の質や量が不十分な場合は役に立ちません。
こうなると、すぐさま着手できるはずの作業の前に余計な分析作業が発生することになり、スケジュールが遅延していきます。
成果物の品質が崩れる
もちろん、インプットの遅れや質や量の悪さをカバーする方法もないわけではありません。
たとえばコンサルの場合、業界に関する知見や過去プロジェクトの成果物などを社内に蓄積しています。
そこから足りないインプットを補完しうる情報を持ってくることができます。
しかし、社内に蓄積できるのは自分たちの書いた成果物、つまり報告書や分析結果サマリのみです。
それらは集計・サマリ・クレンジングされていますので、細かな生データは取ってこられません。
（そもそもクライアントの生データを取っておくなんてできません）
また、それらの情報には目の前のクライアントの実情、意思、魂が全く反映されていません。
そのため、成果物の品質（しみじみ感）レベルは何段階も落ちてしまいます。
それでも構わない、とクライアントと合意ができれば御の字ではあるんですけども・・・
人員計画が崩れる
自社の知見ではインプット補完ができず、そしてプロジェクトの期間延長も認められない場合。
つまり、より短い期間で同じ品質の成果物を出さなければならない場合。
崩れるのは、人員計画です。
たとえば、3人チームで4ヶ月かかる（＝工数12人月の）プロジェクトにおいて、インプット遅れが原因で、最初の1ヶ月間で全く作業が進まなかったとします。
成果物の質と量は変わらないため、プロジェクト完了にかかる工数は12人月です。
しかし期間は1ヶ月縮んで3ヶ月。つまり、1ヶ月あたり4人分の仕事をしなければなりません。
しかし、使える頭数は3人。4人分の仕事を3人でこなすので、1人あたり1.3人分の仕事をしなければなりません。
もともとは3人が定時帰りでこなせたはずの仕事。
それが1.3人分、つまり1日2〜3時間の残業をしないと、もしくは1.5倍のスピートで仕事をしないと終わらなくなってしまいました。
場合によってはメンバー追加で対応もできるかもしれません。
が、人というものはそんなに簡単に調達できるものではないというのが実情です。
また新メンバーのキャッチアップのための教育コストを考えると、手持ちの人員で最後まで走り抜けるという判断が適切である場合もあります。
そして、炎上（デスマーチ）へ・・・
プロジェクトの前提事項が崩れた時の正しい動き方
では、前提が崩れてしまった場合、どうすればいいのか？
プロジェクトの責任者が、コスト・品質・納期についてすぐさまクライアントとの交渉を開始することです。
そのために、まず以下を明らかにします。
- どの前提が崩れたのか（できればエビデンスとともに）
- 作業スケジュール上、どの部分に当たりがあるか
- その結果として、プロジェクト全体へどのような影響があるか
- 取りうる対応の選択肢
- 品質を妥協する
- コストを積み増す
- 納期を伸ばす
- 自分たちとしておすすめする対応
そのうえで、クライアント側のプロジェクトオーナーと対応方針について合意を取りつけます。
必要であれば追加契約や変更契約なども忘れずに。
なお、交渉にあたっては、
- コンテンツの納得感
- クライアントの立場の理解
- 守るべき範囲の見定め
などのポイントをいかに押さえられるかが重要です。
これらがプロジェクトメンバーの生き死にを決めます。
プロジェクトオーナーのみなさま、ぜひ自分のかわいいメンバーたちを守ってあげてください。
まとめ：プロジェクトの前提事項は開始前に合意しておこう
というわけで、プロジェクトの前提事項は計画の肝であるというお話でした。
紹介したような交渉ができるためには、プロジェクト提案の時点で前提事項をできるだけ細かに書いてき、内容をクライアントと合意しておくことが必須です。
そのため、もし「前提事項」ページがない提案書を見たら、すぐに前提事項ページを作れとフィードバックしてください。
そのプロジェクト、前提事項が崩れても交渉ができず、炎上する可能性がありますので・・・
もちろん、プロジェクトが炎上する原因は前提が崩れることだけではありません。
計画時点で炎上確定なプロジェクトも存在します。そんな案件からはいち早く逃げることをおすすめします。見分け方は下記記事をどうぞ。
https://work.naenote.net/entry/planning-basics
コメント