プロジェクトを失敗に導く方法は数えきれません。ここでは、よくある 15 の失敗をまとめました。不明確な作業負荷、マネジメントの支援不足、過負荷のメンバー、品質保証の不備まで、さまざまです。それぞれのつまずきの石について、回避のための具体的なヒントをご紹介します。
プロジェクト管理で頭ひとつ抜け出し、プロジェクトを効率的に運営するためにどのような能力が必要かについては、以前ご紹介しました。
その一方で、プロジェクトが失敗に至る原因となる失敗も数えきれないほどあります。最も頻繁に起こる 15 の問題を集めました。あわせて、それらを是正する、あるいは最初から避けるためのヒントもご紹介します。

1. 不明確な作業負荷
多くのプロジェクトは、作業量が明確に定義されていないために失敗します。ここに曖昧さが入り込むと、プロジェクト全体に影響します。最悪の場合、いつ完了するのかすら不明なままになります。最初に、達成すべき明確な プロジェクト目標 を定義してください。

2. 定義されていない期待
すべての関係者は、プロジェクトがどのような要件を求め、どのような期待を満たすべきかを最初から知っている必要があります。さもなければ失敗を招きます。そのため、何が行われ、どうなればプロジェクトが完了したと判断できるのかを、あらかじめすべてのチームメンバーのために文書化してください。

3. マネジメントの支援不足
経営トップからの支援は必ず確保すべきです。さもなければ成功の見込みは大きく下がります。経営層と足並みをそろえるための定期的な相互の情報共有は、成功するプロジェクトに不可欠です。

4. 適合しない手法
プロジェクト管理では、一般に標準化された主要タスクと成果物を用いて作業を進めます。しかし、こうした標準的な手法は多くの場合、特定の規模のプロジェクトに合わせて設計されています。過去より大きなプロジェクトに挑む場合、もはや適合しないことがあります。

5. 過負荷のメンバー
メンバーに過度な作業が積み重なることでも、プロジェクトは失敗しかねません。あらかじめチームメンバーの強みを明確に把握し、タスクを適切に配分するよう心がけることで、これを避けられます。

6. 共有されない専有知識
プロジェクトは、情報が独占されずに互いに共有されることで成り立ちます。これは、成果を長い準備期間の後にしか出せない場合に、しばしば実現しません。プロジェクトを短いフェーズに分け、その終わりごとに成果、いわゆる マイルストーン を設け、チーム全体がそれをもとに作業を進められるようにしてください。

7. 不明確な意思決定
プロジェクトの進行中、当初のロードマップの変更はしばしば避けられません。しかし 変更管理 において、誰がいつ何を変更し、新しい方針がどのようなものかを明確に文書化すべきです。

8. 際限なく広がる危険
変更要求、つまり変更の依頼は、プロジェクトの日常では当たり前のことです。しかし残念ながら、期限や予算を次第に押し広げてしまうという好ましくない副作用をしばしば伴います。これは長期的に、関係者全員のモチベーション低下や不満につながりかねません。この流れに歯止めをかけるには、明確な目標設定に加え、日々のモニタリングと、変更要望に対する明確なプロセスが有効です。

9.「いいえ」と言えない
会社のため、そしてプロジェクトの成功のためには、要望を断ることが必要な場合もあります。そのため、どう「いいえ」と言うかを知っておくとよいでしょう。そうした場合には、建設的な代替案を提示するのが最善です。

10. 結束の不足
プロジェクト作業はチーム作業です。しかし、一部のプロジェクトチームでは、嫉妬心から本来の目標への集中が失われてしまいます。代わりに、小グループ同士が問題や成果の悪さの責任を互いになすりつけ合います。これを防ぐには、プロジェクトマネージャーによるリーダーシップが求められます。そしてマネージャーは、チームを巻き込み、意思決定に関与させる術を心得ているべきです。コミュニケーションがなければ、破綻はあらかじめ約束されたようなものです。

11. 忘れられた日常業務
プロジェクトマネージャーは、日々の業務をこなすことを忘れるべきではありません。責任者として会議の日程を伝えず、ステータス報告を忘れ、メールに返信しないままでいると、不必要な遅延を招くおそれがあります。

12. 頻繁すぎる会議
現状を確認する会議は、特に開催頻度が高すぎたり長すぎたりすると、わずらわしく感じられることがあります。重要な情報は、コラボレーションツールを使うことで、より的確かつ効率的にチームメンバーに届けられる場合が多くあります。会議では意思決定に集中してください。新しいタスクを配分し、優先順位を定めるには、週に一度の集まりで十分なことがよくあります。

13.「十分」が常に「良い」とは限らない
品質保証における手抜きは問題になりかねません。その悪い結果を取り除くために費用と時間をかけるより、初めから失敗を避けるほうが常に得策です。高い品質基準に気を配る人は、後の手戻りや評判を落とす危険を避けられます。

14. 失敗から学ばない
プロジェクトの終了後には、その経過を分析することが非常に重要です。何がうまくいき、何を改善すべきか。こうした 教訓 は、犯した失敗を将来避ける助けになります。

15. ソフトウェアの欠如
Excel の表計算は、プロジェクトマネージャーに手作業での修正を強い、ステータスの更新で問題を引き起こすことがよくあります。その点で、Merlin Project のような、自動更新を行い、わずらわしい手作業の報告から解放してくれるプロジェクト管理ソフトウェアで作業できることは、まさに開放的です。
1 / 15