プロジェクトのスケジュールの 7 つの大罪

この記事は、"From the Trenches" コレクションの一部です。

この記事では、プロジェクト スケジュールで行われた一般的な間違いについて説明し、実用的なアドバイスを提供します。 これは、Microsoft Project の任意のバージョンに関連する実用的なアドバイスと推奨事項を提供します。

その他の記事については、「 溝から」ホワイト ペーパーを参照してください。

プロジェクトのスケジュールの 7 つの大罪

スケジュール設定は、プロジェクトの単純なコンポーネントではありません。しかし、過去20年間、私は仕事をしたり、スケジュールについて相談したりしたすべての組織で同じ基本的な問題に繰り返し出てきました。 ここでは、プロジェクトスケジュールの7つの致命的な罪をレイアウトし、いくつかの解毒剤を提供します。 私の希望は、このアドバイスを使用して、スケジュールを使用する際にプロジェクト管理を成功させるために適切な基盤を築くことを願っています。

Sin #1: スケジュールが複雑すぎます。

左右より北から南に行が多いスケジュールがある場合は、問題が発生します。 関係者がスケジュールを理解するのに数週間または数日かかる場合、モデルは複雑すぎます。 エグゼクティブやチームに説明するのが難しすぎる場合、誰もが恩恵を受けるのをどのように期待できますか?

複雑すぎるプロジェクト スケジュールの例。

プロジェクトが複雑すぎるかどうかを知る方法 スケジュールの重要なパスを見つけるのがいかに簡単か自問してください。

Sin #2: スケジュールにタスクが多すぎます

これは何よりも、スケジュールが途中で落ちる理由に貢献します。 プロジェクト マネージャーは、スケジュールが完了する必要があるすべてのチェックリストである必要があるという印象を受けます。 To Do 項目とリマインダーから自己への通知は、作業明細構造に属していません。 このアプローチは、プロジェクトのモデルを表すスケジュールの目的全体を完全に打ち破ります。

その点を説明するために、例を共有しましょう。 あなたが木材供給者か、家を建てるフレーマーだとします。 木材パッケージを配送するタイミング、または作業を開始するためにスタッフと一緒に表示するタイミングを知る必要があります。 これは通常、基盤が完了したときに発生します。

次のようなスケジュールを作成できます。

サブタスクを示すプロジェクト スケジュール。

または、次のようなものがあります。

高レベルのタスクを示すプロジェクト スケジュール。

ビルダーとスケジューラの場合、実績を更新して維持する必要があるアプローチはどれですか?

今、あなたは同時に建設中の30の家を持っていると想像してください。 どちらが好きですか?

つまり、一覧表示されている他のすべてのタスクが重要ではない、または他のタスクを実行する必要がないというわけではありません。 ここでの本当の質問は、それを追跡して維持する方法です。 また、上記の 1 行のタスクへのメモとして詳細タスクを一覧表示することもできます。

私の経験則は、Eric Uyttewaalの本、Microsoft Project 2010での予測スケジュールから取ります:最小期間はプロジェクト期間の1%です。最大値は期間の 10% です。

Sin #3: ネットワーク ロジックが不完全であるか、動的ではない

不完全なネットワーク ロジックは、スケジュールが適切に予測できない、または動的に進化しない理由の 1 つです。 これに対応する依存関係が少なすぎます。 制約が多すぎると、適切にレイアウトされたネットワークの動的な性質も大きく損なわれます。 インジケーター列に主に制約が表示される場合は、実際に何をしているかがわからない可能性があることを示します。 プロジェクト マネージャーは、多くの場合、スケジュールに多くの制約があることを非表示にするために、この列を非表示にすることをポイントにします。

簡単なテストを次に示します。 スケジュール内のクリティカル パスを見つけます (できない場合は、既に大きな問題が発生している場合)、スケジュールの早い段階で最も長い不完全なタスクのいずれかを実行し、期間を 2 倍にします。 プロジェクトの終了日は変更されますか? そうでない場合は、作業スケジュールがありません。 タスクと時間枠を予測し、プロジェクト マネージャーとして結果をより適切に制御するために使用できる動的スケジュールを持つという基本的なテナントの恩恵を受けることはできません。

Sin #4: スケジュールのベースラインが設定されていません

スケジュールをベースにしないと、分散を測定するのが不可能ではないにしても、困難になります。 ベースライニングは、作業を開始する前にスケジュールをキャプチャするのに役立ち、現実が設定されたときに差異から学習できます。 測定できない場合は、制御できません。

Sin #5: スケジュールが更新されない

私が見たスケジュールの大部分は古いものです。 プロジェクトマネージャーは、プロジェクトが進行中にスケジュールを破棄し、実行中に火災と戦うことがよくあります。 スケジュールが詳細すぎて、それを最新の状態に保つために多くの作業が必要な場合、この問題が発生する可能性が大幅に高くなります。 要するに、スケジュールを更新しないと、将来の日付を予測する能力が失われます。

Sin #6: スケジュールにリソースの割り当てがない、または割り当て過ぎている

多くの場合、スケジュールはリソースの割り当てなしで作成されます。 これは素敵な絵になるかもしれませんが、タイムラインが達成可能であるという誤った印象を与えるかもしれません。 リソースが追加されて平準化されると、まったく異なるタイムラインが出現する可能性があります。

リソースが割り当てられると、(リソース使用状況ビューを使用して) "内部" を見ない場合よりも多くの場合、リソースが割り当て過ぎています。 すぐに使える固定ユニットから始めると、間違った足で起動します。 時間の観点から現実的な割り当てを行い、人の能力内で割り当てられた作業を行ったかどうかを時間をかけて評価します。

また、自動リソース 平準化機能を使用する場合は、細心の注意を払ってください。 手動モードで使用するのが最適です。 また、他のプロジェクト ワークロードを可視化できるエンタープライズ ソリューションを使用すると、タスクを実行できる自信が高まります。

Sin #7: タスクの種類がわからない

プロジェクト スケジューリング エンジンのしくみと、数式でのタスクの種類のしくみがわからない場合

期間 * 単位 = 作業時間

あなたは永遠にあなたの髪を引き出し、ツールに不満を感じるでしょう。

メッセージが届かない場合は、良いリソースを入手して研究することをお勧めします。 Microsoft Project 2010 での予測スケジュールは、開始するのに適した場所です。

著者について

25 年以上のプロジェクト管理経験を持つ Kevin Watson、PMP、MCT、MCTS は、Microsoft Project と Microsoft Project Server のブラック ベルトです。 Kevin は、プロジェクト管理とプロジェクト サーバーの独自の組み合わせをフィールドに持ち込み、そこで Microsoft のシニア コンサルタントを務めます。 で彼に kevinw@microsoft.com連絡してください。