リソースカレンダー - チーム全体を1つのツールで管理
リソースカレンダー(またはプロジェクトマネジメントカレンダー、またはプロジェクトプランニングカレンダー、リソースプランニングソフトウェア)は、より効果的かつ効率的にリソースを計画・管理・配分することができます。
プロジェクトを担当しているとき、あなたは通常、プロジェクトの要件を満たすためにチームが何をすべきかをよく知っている。しかし、クライアントがどんなに小さなものであっても、既存のプロジェクト・スコープに追加して作業を開始すべき新機能を思いついたとしたらどうでしょう?
この記事のおかげで、あなたは何を学ぶだろう:
プロジェクト・マネージャーであれば、このようなシナリオはよくご存知だろう。ユーザーのフィードバックや市場のダイナミックな状況により、プロジェクトが変更されることはよくあることだ。それは自然なことであり、非常に良い結果(例えば、より質の高い最終製品)につながる可能性もある。しかし、このような予期せぬ編集の結果、スコープクリープが発生し、プロジェクトの進行をほとんどコントロールできなくなる可能性があるということです。
ここでは、プロジェクトのスコープクリープについて詳しく見ていき、プロジェクトマネジメントのキャリアにおいてスコープクリープにどのように対処していけばよいかを議論していこう。
まず、プロジェクトのスコープとは何か?プロジェクトマネジメントにおけるスコープとは、プロジェクトのすべてのタスク、プロセス、アクティビティ、要件、成果物と理解されている。簡単に言えば、プロジェクトを完了させるために要求されるすべての作業である。
プロジェクトスコープは、プロジェクト計画の一部である。プロジェクトマネジメントライフサイクルのこのフェーズの結果が、プロジェクトスコープステートメントである。これは、プロジェクトのスコープ(「スコープ・ステートメント」や「ターム・オブ・リファレンス」とも呼ばれる)を文書化したもので、正確なチェックリストが含まれています。
プロジェクト・スコープ・ステートメントができたら、プロジェクト・スコープ・マネジメント計画と呼ばれる段階に入る。これは、プロジェクトの実施に関わる全プロセスの概要を示すもので、プロジェクトを定義された期待値と制限の範囲内に収めるためのガイドラインとなる。
スコープクリープを説明する最も簡単な方法は、次のように言うことである。 合意されたプロジェクト範囲を超える機能や要件を追加する。 プロジェクトスコープの変更や拡大は、必ずしもスコープクリープと同じではないため、この定義の両方の部分が重要である。
逆に、プロジェクトマネジメントでは、変更はまったく普通のことである。変更が合意されないとスコープは忍び寄り、プロジェクト要件の増加は制御不能になる。
PMBOK®ガイド(第5版)が提供する定義では、スコープクリープとは次のように述べられている。 時間、コスト、リソースを調整することなく、製品やプロジェクトの範囲を無制限に拡大すること。 この説明は、スコープクリープの潜在的な結果を想像するのに役立つはずの重要な要素を強調している。私が言っているのは、これらの プロジェクトスコープにある新機能が、スケジュール、リソース、予算に合っていない。.本質的には、これらの変数のいずれか(あるいはすべて)が非常にうまくいかず、プロジェクトを沈没させる可能性があるということだ。
スコープクリープを定義したところで、その主な原因について説明しよう。
スコープクリープは、以下のような要因の組み合わせによって引き起こされる可能性が高い:
プロジェクトのスコープが悪い。これは通常、スコープクリープを引き起こす主な要因である。プロジェクトのスコープが曖昧だったり、存在しなかったりする場合、どうやってそれをコントロールできるでしょうか?しかし、明確なスコープ・ステートメントを持つことが、この課題に対する究極の解決策ではありません。スコープを検証し、プロジェクトの利害関係者全員で署名する必要がある。
さらにもう1つの問題は、チーム内の適切な人材と要件を協議しなかった場合に発生する可能性がある。例えば、スコープが明確で、クライアントがそれを許可していたとしても、要件によっては技術的に実行不可能であることが判明する場合があります。そのため、次のことが不可欠です:
このプロセスについてもっと知りたいですか?私たちの プロジェクト・スコープ・マネジメントの手引き.スコープをうまく管理するのに役立つだろう。
スコープクリープは、変更要求に対処する手順が確立されていない場合にも起こりやすい。あるいは、いくつかの変更管理ルールを設定していても、ステークホルダーがそれを認識していないのかもしれない。このブログ記事の次のセクションでは、プロジェクトが脱線しないように変更を管理することについてもう少し詳しくお話します。
スコープクリープの原因としてあまり期待されていないのが、チームメンバーがクライアントから直接影響を受け、新しい機能を追加したり、既存の機能を拡張したりすることです。このような外部からのプレッシャーは、特にチームメンバーがそれを透明性を持って伝えなければ、プロジェクトマネージャーにとって気づきにくいものです。
さらにもう一つ考えられる危険は、ステークホルダーがプロジェクトに様々な関わりを示す場合である。要件収集の段階で、クライアントがプロジェクトスコープにそれほど注意を払っていない状況を想像してみてほしい。おそらく他のことで忙しかったり、単にプロジェクトにあまり関与していなかったりするのだろう。しかし、あなたの仕事の最初の成果を見たとたん、彼らは急にプロジェクトに参加するようになり、新しい機能を考え出したり、プロジェクトの目標を再定義し始めたりする。これがスコープクリープにつながりやすいことは想像に難くない。
最後に、外部からの影響について触れなければならない。予期せぬシナリオに備えるのは難しいが、プロジェクトマネージャーとして、いくつかのコンティンジェンシープランを用意しておくべきだ。それがあれば、たとえ不意打ちを食らったとしても、変化に対処することができる。
お分かりのように、スコープクリープの原因にはさまざまなものが考えられます。心に留めておく必要があるのは、スコープクリープはさまざまな要因の組み合わせによっても起こるということです。だからこそ、どうすればスコープクリープを回避できる可能性があるのかを知っておくことは有益なのです。
手始めに言っておくが、スコープの変更は絶対に避けるべきものではない。もしあなたがアジャイル環境で働いているのなら、おそらく変更が起こることを期待しているはずだ。あなたが軽減したいのは、スコープが無秩序に拡大した結果です。スコープクリープを防ぐための戦略をいくつか見ていこう:
プロジェクトマネージャーの中には、「プロジェクトの明確なスコープを作る」ことは、「言うは易く行うは難し」であると感じている人もいるかもしれない。多くのプロジェクト、特に革新的な試みでは、完成品がどのようなものになるか100%確信が持てないかもしれません。多くのソフトウェア開発プロジェクトがそうで、ユーザーからのフィードバックやテストに基づいて変更が加えられることが多い。プロジェクトチームは、最先端の技術や実験的なソリューションの使用を決定すると、さらに別の課題に直面する。
しかし、このようなシナリオでスコープクリープが必ず起こるというわけではない。いわゆるプロジェクトのディスカバリー・フェーズから始めることで、妥当なスコープを構築する可能性を高めることができる。これは、仮説を検証したり、仮定に異議を唱えたり、プロトタイプを作ったりする期間である。すべては、あなたのアイデアを検証し、提案されたソリューションが実行可能かどうかをチェックするためである。
スコープクリープを回避するためのベストプラクティスをいくつか説明しましたが、もしすでに経験していたらどうでしょうか?一見些細な変更要求から始まったのかもしれませんし、プロジェクトのキックオフ時からステークホルダーが追加機能を期待していたのかもしれません。スコープクリープの管理は可能であり、ここにいくつかの選択肢があります。
まず第一に、スコープクリープに落胆するかもしれないが、受け身になって負けている場合ではない。スコープクリープを経験したプロジェクトは、それでもうまくいくかもしれない。
すべての変更依頼をよく見て、その結果を注意深く分析するようにしてください。変更がプロジェクトの予算とタイムラインにどのような影響を与えるかを評価する。たとえチームがすでにある変更を実施していたとしても、その変更がプロジェクトの残りの部分に与える潜在的な影響を調査することは価値がある。
また、次のことに注意を払う絶好の機会でもある。 資源予測.変更要求がプロジェクトのこの側面にも影響を及ぼしているかもしれない。このプロジェクトを遂行するのに十分なチームメンバーがいますか?何人かを雇用/外注する必要がありますか?従業員の稼働率と チーム作業量 を考慮に入れる。 ワークロード管理).チームメンバーを酷使し、スコープクリープのせいで燃え尽きてしまうようなことは避けたい。
スコープクリープに対処するもう1つの戦略は、最初の要件の一部をスコープから外すことである。プロジェクトバックログに優先順位がつけられていれば、新しく追加される要素と交換できる要素を特定できるはずです。その結果、プロジェクトを遂行するための時間やコストを多少余分に稼ぐことができるかもしれない。
変更要求が殺到するにつれ、チームはプロジェクトの期待について少し混乱するかもしれない。その結果、金メッキを施したり、特定のタスクにさらに時間をかけたりすることになりかねない。各チームメイトが新しいプロジェクトの要件を理解しているか、再確認する必要がある。
プロジェクトの全体像を見ることを忘れてはならない。スコープクリープはそれにも影響します。もしかしたら、あなたとプロジェクトの利害関係者が、サブプロジェクトを作ったり、MVPを立ち上げたりすることを話し合う意味があるかもしれません。スコープクリープの弊害の1つは、チームが勢いを失い、プロジェクトが予想以上に長引くことです。プロジェクトのスコープの一部を別のリリースとして提供することで、勢いを取り戻し、チームの達成感を高めることができるかもしれません。このアプローチにはビジネス上のメリットもあります。MVP(最小実行可能製品)を早い段階でリリースすることで、クライアントが製品をテストし、顧客の間で早期に成功を収めることができるかもしれません。
最後に、スコープクリープが発生している場合でも、プロジェクトの健全性を定期的に監視する必要がある。 プロジェクト報告 に役立つだろう。 チームのパフォーマンスを評価する そして、拡大するスコープの効果を計算する。
スコープクリープは珍しい現象ではない。プロジェクトマネジャーであれば、キャリアのどこかで必ずと言っていいほど直面する。Project Management Instituteが2018年に実施した調査では、回答者の半数がスコープクリープに直面している。 プロフェッショナルの意識調査 過去12ヶ月の間にスコープクリープを経験。2020年に このレポートの新しい版 は、能力の成熟度が高い企業は、成熟度が低い組織(30%~47%)よりもスコープクリープの影響を受けにくいことを示した。
というのも、スコープクリープは潜在的に不利なものではあるが、管理可能なものだからである。 このブログ記事が、あなたのチームのためにスコープクリープを管理する方法を発見する一助となれば幸いです。
プロジェクトマネジメントについてもっと知りたいですか?私たちが公開しているプロジェクトマネジャー向けの他のリソースもご覧ください:
[vc_column_text][/vc_column][/vc_row]。