仕事を行う上で、大小様々な『プロジェクト』を経験されたかと思いますが、100%完璧なプロジェクトなど存在しなかったのではないでしょうか？
『プロジェクト』は奥が深く、特にプロジェクトリーダーはあらゆる観点で意識を張り巡らせなければなりません。
本記事では「プロジェクトリーダーの心得」として、プロジェクトの立ち上がりである『定義フェーズ』の心得を紹介します。
プロジェクトにおける『定義フェーズ』の位置づけ
プロジェクトは、『独自の製品、サービス、所産を創造するために実施される有期性の業務』と定義されています。
達成すべき目標、およびそれを実現するためのスケジュールが存在しますが、目標やスケジュールによってそのためのアプローチや投資すべきスキル・リソースは全く異なってきます。
そのため、プロジェクトの最初のフェーズで、プロジェクトを『定義』する（ゴール・スコープは何か？ステークホルダーは誰か？内在するリスクは何か？を定める）ことが必須です。
これがプロジェクトにおける『定義フェーズ』の位置づけです。
ゴール設定
ビジョン・ゴール・目的を明確化する
プロジェクトにおいては、目指すべきビジョン・ゴール・目的などの定義、およびメンバー間での共有がとても重要です。
- ビジョン … ゴールの達成により実現する理想像
- ゴール … 最終的に達成したいこと
- 目的 … ゴールを達成したい理由
「プロジェクトリーダーが自分の言葉でこれらを伝え、メンバー間で認識が一致するまで話し合う」、一見遠回りのようですが、このアクションの有無ではプロジェクトとしてのパワーが全く異なるものとなります。
SMARTなゴールを設定する
プロジェクトの目標設定の際には、『SMART』なゴールが正しい目標設定と言われています。
『SMART』とは、以下の5つのキーワードの頭文字を繋げたものです。
- Specific … 具体的である
- Measurable … 測定可能である
- Achievable … 達成可能である
- Relevant … 適切である
- Timed … 期限がある
一見当たり前のことを言っているように感じますが、これらが一つでも欠けているプロジェクトは必ずと言ってよいほど失敗すると言えます。
・具体的でない
・測定可能でない
・達成可能でない
・適切でない
・期限がない
ため、永遠に目標を達成することはできない失敗プロジェクトの代表例となります。
スコープ設定
スコープアウトを明確にする
スコープ設定でなぜ「スコープアウトの明確化」が必要？と感じられる方もいるかもしれません。
理由は、プロジェクトステークホルダーが「様々なバックグラウンドから構成される人の集まり」である以上、一つの事象に対して完全に同じ認識を持つことは不可能、むしろ自分のバックグラウンドからなる経験や期待から自身にとって都合の良い解釈をすることは責められません。
顧客にとっては、スコープに定義されていないこと＝やらないことではありません。
上記のような誤解を防止するために、明確にスコープアウト（やらないこと）を明確化しましょう。
成果物を定義する
「成果物を定義」するというのは当たり前に感じられるでしょうが、どれだけ上手くいった（とプロジェクトメンバーが主観で感じた）プロジェクトであっても、最終段階でプロジェクトオーナー（顧客）から主観で「想像していたものと違うな」評価を受けたらそのプロジェクトは大失敗です。
そのため、プロジェクトオーナーの「想像していたもの（成果物）」を客観的に定義することは絶対に欠かせないアクションです。
成果物に対し定義すべき事項は以下です。
- 成果物の形状 … 物理なのか、サービスなのかなど
- 受け入れ基準 … 機能、品質など
- 受け入れプロセス … 誰が受け入れ判断するかなど
ステークホルダー管理
推進派・反対派をコントロールする
プロジェクトの難易度は、通常QCD（品質・コスト・スケジュール）で語られることが多いですが、実は最もプロジェクトの成否に関わるのはステークホルダーの関係性です。
ステークホルダー全員がプロジェクトに賛成していることなどほぼ無いといっていいでしょう。
「反対派」の存在は、プロジェクトの予期せぬフェーズでリスクや問題となりえます。
「推進派」をも上手くコントロールしながら「反対派」を、「推進派」少なくとも「中立派」にしていく必要があります。
期待値をコントロールする
「ステークホルダーの期待値コントロール」は、特にコンサルティング業界で行われる手法です。
プロジェクトオーナー（顧客）の期待値は得てして「高く」見積もられます。
そのようなことが無いよう、『SMART』なゴールや『成果物』の設定により期待値を適正にする必要があります。
一方、期待値が「低い」場合も正常な状況ではありません。
特に現場の意識・行動変革を要するプロジェクトにおいては、「何も変わらない」、「オペレーションが複雑になる」といったようなネガティブな意識がある状態では、プロジェクト後の姿は変わりません。
そのようなことが無いよう、ステークホルダーへの『ビジョン』共有などをすることで期待値を上げる必要があります。
リスク管理
リスクを洗い出す
プロジェクトには数多くの想定外の事象が待ち受けています。
成功するプロジェクトは、プロジェクト開始前に十分に『リスク』を洗い出し、顕在化する前に芽をつぶすことが出来ています。
- リスク … 潜在的な阻害要因
- 問題 … 顕在的な阻害要因
- 課題 … 取り組むべき問題
『リスク』は、「顧客要望によるスケジュール変更」、「ステークホルダー（反対派）の抵抗」だけでなく、「プロジェクトメンバーの離脱」、「天災の発生」など多岐にわたります。
もちろん全てのリスクを洗い出すことは不可能ですが、これまでの経験も活かし起こりうるリスクを洗い出し、対策をとることが重要です。
リスクに対応する
前項で洗い出した『リスク』の全てに対策を打つことは不可能です。
そこで、各リスクの『発生可能性』×『影響度』の大きさを評価し、大きいものから可能な範囲で対応するのがよいでしょう。
- 発生可能性 … リスクが顕在化する可能性
- 影響度 … リスクが顕在化した場合のインパクト
例えば、「顧客環境の変化」や「競合企業の参入」などはリスクとして見積ることはできてもコントロール不可能なため、対応することはできません。
まとめ
「プロジェクトリーダーの心得」として、プロジェクトの立ち上がりである『定義フェーズ』の心得を紹介しました。
また他フェーズの心得についても下記にまとめていますので合わせてお読み下さい。
本記事は、プロジェクトリーダーの心得が良くまとまっている『プロジェクトリーダーの教科書』を参考にまとめさせていただきました。
ご興味を持たれた方は、ぜひ本書にてより深い心得を学ばれることをオススメします。
コメント