プロジェクトのスケジュールの 7 つの大罪The Seven Deadly Sins of Project Schedules

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection.

この記事では、プロジェクトのスケジュールにおけるよくある間違いについて説明し、実践的なアドバイスを提供します。This article discusses common mistakes that are made in project schedules and offers practical advice. Microsoft Project のすべてのバージョンに関連する実践的なアドバイスと推奨事項が提供されます。It provides practical advice and recommendations that are relevant to any version of Microsoft Project.

その他の記事については、 ホワイトペーパー「Trenches」を参照してください。To see more articles, see "From the Trenches" white papers.

プロジェクトのスケジュールの 7 つの大罪The Seven Deadly Sins of Project Schedules

スケジュールは、プロジェクトの単純なコンポーネントではありません。過去20年間に、自分たちのスケジュールに関して行ったすべての組織で同じ基本的な問題を繰り返し実行しています。Scheduling is never a simple component of a project; yet in the last 20 years, I've repeatedly run into the same basic problems in every organization I have worked for or consulted with regarding their schedules. ここでは、プロジェクトスケジュールの7つの危険な ins をレイアウトし、いくつかのアンチな機能を提供します。Here I lay out the seven deadly sins of project schedules and provide you with some antidotes. このアドバイスを使用して、スケジュールを使用して適切なプロジェクト管理を行うための優れた基盤を配置することをお勧めします。My hope is that you'll use this advice to lay the right foundation for successful project management when using schedules.

Sin #1: スケジュールが複雑すぎます。Sin #1: The schedule is too complex!

右から右に北から南までの行数が多いスケジュールがある場合は、問題があります。When you have schedule that has more lines running north to south than left to right, you have a problem. 関係者がスケジュールを理解するのに数週間または数日かかる場合は、モデルが非常に複雑になります。If it takes weeks or days for stakeholders to understand your schedule, then the model is too complex. 経営幹部に説明するのが困難な場合、またはチームであっても、他のユーザーにとってメリットがあるかどうかを判断する方法はありますか。If it's too difficult to explain to executives or even to your team, then how can you expect anyone to benefit from it?

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

プロジェクトが複雑すぎるかどうかを確認するにはどうすればよいですか。How do you know if your project is too complex? 自分のスケジュールでクリティカルパスを簡単に見つけられるかどうかを確認します。Ask yourself how easy it is to find the critical path in your schedule.

Sin #2: スケジュールに含まれるタスクが多すぎますSin #2: Your schedule has too many tasks

このようにすると、スケジュールが理由によって、その理由によってスケジュールが影響を受けます。This, more than anything, will contribute to why schedules fall by the wayside. プロジェクトマネージャーは、スケジュールが実行する必要があるすべてのチェックリストにする必要があるという印象を取得します。Project managers somehow get the impression that a schedule needs to be a checklist of everything that needs to get done. To do アイテムと事前通知は、作業分解構造に属していません。To-do items and reminders-to-self don't belong in a work breakdown structure. この方法では、プロジェクトのモデルを表すスケジュールの目的全体が完全に損なわれます。This approach completely defeats the whole purpose of a schedule representing a model of your project.

この点を説明するために、例を共有してみましょう。To illustrate the point, let me share an example. Erecting となる伐採用品または framer を作成しているとします。Suppose that you're the lumber supply person or the framer who will be erecting a house being built. 伐採パッケージをいつ提供するか、またはクルーに表示して作業を開始する時期を知る必要があります。You need to know when to deliver your lumber package, or when to show up with your crew to start work. これは通常、基礎が完成したときに発生します。This typically occurs when the foundation is complete.

スケジュールは次のように作成できます。You can build a schedule like this:

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

または、次のようなものです。Or one like this:

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

ビルダーとスケジューラを使用している場合は、どのアプローチを使用して実績を更新し、維持する必要がありますか。If you were the builder and scheduler, which approach would you prefer to have to update and maintain your actuals?

ここで、1つの工事の下に同時に30の住宅があるとします。Now imagine that you have 30 houses under construction at the same time. これをお勧めします。Which would you prefer?

これは、表示されている他のすべてのタスクが重要ではないことや、他のタスクを実行する必要がないということではありません。That is not to say that all the other tasks listed aren't important, or that other tasks don't need to be done. ここでの実際の質問は、追跡して管理する方法です。The real question here is how to track and maintain it. 上記の1行のタスクに関するメモとして詳細タスクを一覧表示することもできます。You could also just list the detail tasks as a note to the one line task shown above.

次に示すのは、Eric Uyttewaal の書籍から、Microsoft Project 2010 を使用してスケジュールを予測するという経験則です。最小期間はプロジェクト期間の1パーセントです。最大値は、期間の10% です。Here's my rule of thumb, which I take from Eric Uyttewaal's book, Forecast Scheduling with Microsoft Project 2010: The minimum duration is one percent of the project duration; the maximum is 10 percent of the duration.

Sin #3: ネットワークロジックが不完全であるか動的ではありませんSin #3: Your network logic is incomplete or isn't dynamic

不完全なネットワークロジックは、スケジュールが適切に予測されなかったり、動的に変化したりする1つの理由です。Incomplete network logic is the number one reason why schedules fail to forecast properly or evolve dynamically. このの依存関係のアカウントが少なすぎます。Too few dependencies account for this. 使用する制約の数が多すぎると、適切に配置されたネットワークの動的な性質が大きく損なわれることになります。Use of too many constraints will also greatly impair the dynamic nature of a properly laid out network. [状況説明マーク] 列にほとんどの制約が表示されている場合は、実際に作業していることがわからないことを示します。If you see mostly constraints in the indicator column, this indicates you may not really know what you're doing. プロジェクト管理者は、多くの場合、この列を非表示にして、スケジュールに多くの制約があることを非表示にすることができます。Project managers often make it a point to hide this column in order to hide that they have many constraints in their schedule.

簡単なテストがあります。Here's an easy test for you. スケジュール内の重要なパスを見つけます (必要でない場合は、既に重大な問題がある場合)、次に、スケジュールで最も長い未完了のタスクの1つを実行し、期間を2倍にします。Find the critical path in your schedule (if you can't, you already have a major problem), then take one of the longest incomplete tasks early in your schedule and double the duration. プロジェクトの終了日が変更されるかどうか。Does your project finish date change? それ以外の場合は、作業スケジュールがありません。If not, then you don't have a working schedule. タスクと時間枠を予測するための動的なスケジュールを使用して、結果をより適切に制御するために使用できる動的なスケジュールを作成することはできません。You won't be able to benefit from the basic tenants of having a dynamic schedule that you can use to forecast tasks and timeframes and for you as project manager to control the results better.

Sin #4: スケジュールが baselined になっていないSin #4: Your schedule isn't baselined

スケジュール設定されていない場合は、差異を測定することが困難になります。Not baselining a schedule will make it difficult, if not impossible, to measure variance. 作業を開始する前に、スケジュールをキャプチャできます。また、現実がで設定されている場合に、差異から学習することができます。Baselining helps to capture your schedule before you begin work and allows you to learn from the variances when reality sets in. 測定できない場合、それを制御することはできません。If you can't measure it, then you can't control it.

Sin #5: スケジュールが更新されないSin #5: Your schedule doesn't get updated

表示されたスケジュールの大部分が古くなっています。The vast majority of the schedules I have seen are out of date. プロジェクトマネージャーは、プロジェクトの進行中にスケジュールを破棄して、実行中の戦闘開始を検出することがよくあります。Project managers will often abandon the schedule once the project is underway and find themselves fighting fires while in execution. スケジュールの詳細が多すぎて最新の状態に維持するには、過剰な事態が発生する可能性が高くなります。The likelihood of this happening increases significantly if the schedule is too detailed and requires too much work to keep it up to date. 下線: スケジュールを更新しない場合、将来の日付を予測する機能が失われました。The bottom line: If you don't update your schedule, then you have lost your ability to forecast future dates.

Sin #6: スケジュールにリソースが割り当てられていないか、割り当て超過になっていますSin #6: Your schedule has no resource assignments, or they're over allocated

多くの場合、リソース割り当てなしでスケジュールが作成されます。Often schedules are created without any resource assignments at all. これはすばらしい画像になるかもしれませんが、タイムラインが達成可能であるという誤った印象を与える可能性があります。This might make for a nice picture, but it also might give the false impression that the timeline is attainable. リソースが追加され、その後、平準化されると、まったく異なるタイムラインが出現することがあります。If resources are added and then leveled, an entirely different timeline may emerge.

リソースが割り当てられると、[内部] ([リソース配分状況] ビューを使用して) を検索しているときよりも多くの場合、リソースは割り当てられた grossly になります。When resources are assigned, more often than not when looking "under the hood" (using resource usage view), they're grossly over allocated. すぐに使用できる固定単位で開始すると、間違ったフットで開始されます。If you start with out-of-the-box fixed units, you'll be starting off on the wrong foot. 時間をかけて、ユーザーの容量内で割り当てられた時間と作業時間に現実的な割り当てを行ったかどうかを評価します。Take the time to evaluate whether you've made realistic assignments in terms of time and work allocated within a person's capacity.

また、自動リソース平準化機能を使用する場合は、細心の注意を払ってください。Also, show extreme caution when using the auto resource leveling feature. これは手動モードで最適に使用されます。It's best used in manual mode. また、他のプロジェクトのワークロードを参照できるエンタープライズソリューションを使用することで、タスクが完了するという信頼を得ることができます。And using an enterprise solution that gives you visibility into other project workloads should increase your confidence that tasks can get done.

Sin #7: タスクの種類がわからないSin #7: You don't know what task types are

プロジェクトのスケジュールエンジンのしくみと、数式でのタスクの種類の動作を理解していない場合If you don't understand how the project scheduling engine works and how task types work in the equation

期間 * 単位 = 作業時間Duration * Units = Work

このツールを使用すると、髪の手が不要になります。you will be forever pulling out your hair and getting frustrated with the tool.

メッセージを取得していない場合は、適切なリソースを入手して調査することをお勧めします。If you find yourself not getting the message, then I recommend you get yourself a good resource and study it. Microsoft Project 2010 を使用した予測のスケジュールを開始することをお勧めします。Forecast Scheduling with Microsoft Project 2010 is a good place to start.

著者についてAbout the Author

25年以上のプロジェクト管理の実績がある場合、加山博士、PMP、MCT、MCTS は、Microsoft Project と Microsoft Project Server のブラックベルトです。With over 25 years of project management experience, Kevin Watson, PMP, MCT, MCTS, is a black belt in Microsoft Project and Microsoft Project Server. 佐藤さんは、Microsoft のシニアコンサルタントであるように、project management と project server の独自の組み合わせをフィールドに統合します。Kevin brings a unique combination of project management and project server to the field, where he is a Senior Consultant with Microsoft. Kevinw@microsoft.com で彼に連絡してください。Contact him at kevinw@microsoft.com.