欲しいのは解決策They say they want a resolution

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. プロジェクトをスケジュールするときに直面する可能性がある一般的な課題について説明します。It describes some common challenges you may face when scheduling projects. ここでは、タスクの期間と、プロジェクトスケジュールを最適化するために必要なタスクの数を判断する際の最適な方法について説明しています。It describes coming up with the best approach when you try to determine how long tasks should be and how many tasks there should be to optimize a project schedule. さまざまな業界では、通常、さまざまな種類のスケジュール (たとえば、ソフトウェア開発、EPM (エンジニアリング、調達、建設、建設)、プラントのシャットダウン) を必要とする方法について説明します。It discusses how different industries typically require different types of schedules (for example, software development, EPM (engineering, procurement, and construction), and plant shutdown). プロジェクトの解決策 (たとえば、プロジェクトの期間、リソースに関連するリソース、管理またはリソースの部署、データ収集に必要な速度と労力、データ更新スケジュール) を選択する際のいくつかの要因についても説明します。It also discusses several factors in choosing project resolution (for example, length of project, resources involved, management or division of resources, speed and effort required in collecting data, and data update schedule).

この記事の Word バージョンをダウンロードするには、 次のように解決策を希望していることを示します。ホワイトペーパー (Project Server 2010)To download the Word version of this article, see They say they want a resolution: white paper (Project Server 2010).

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

欲しいのは解決策They say they want a resolution

タイトルの apologies を使用して、今日のトピックはプロジェクトの解決策です。With apologies to the Beatles for the title, today's topic is the resolution of your project.

スケジュールを立てる方法についてはたくさんの資料がありますが、最も重要な教訓の1つは、プロジェクトスケジュールに必要なタスクの数と、各タスクが実行される時間を awfully にすることが難しいということです。There are lots of materials available on how to make a schedule, but one of the most critical lessons is awfully hard to come by—how many tasks you should have in your project schedule and how long each task should be?

定期的に、プロジェクトのスケジュールが複雑になっているように思えるかもしれません。また、プロジェクトマネージャーは、スケジュールの問題を特定できるように helpless になっています。On a regular basis I'm confronted with project schedules that seem impossibly complex or with project managers who seem helpless to pinpoint trouble in their schedule because the schedule is at such a summary level. 期間が100年を超えているプロジェクトがあります (実際には、長期間にわたって非常に適切で、数十年にわたるタスクがある)。I've seen a project that was over a hundred years long (yes, really) that was perfectly appropriate in length and in which there were some tasks that were decades long. また、プロジェクトのスケジュールも、必要な場合にのみ持続し、一部のタスクは1分間しか持続していませんでした。I've also seen project schedules that lasted only an hour or less that were perfectly appropriate and in which some tasks lasted only a single minute. 少数のタスクと、10万以上のタスクを持つプロジェクトが表示されています。I've seen projects with only a handful of tasks and others with over 100,000 tasks.

現在使用しているソフトウェアは、数千のタスクと幅広い期間を処理できます。The software we use today can handle thousands of tasks and a wide range of durations.

適切な方法は何でしょうか。So, what's the right approach?

タスクの所要時間、およびプロジェクトスケジュールを最適化するために必要なタスクの数How long should tasks be, and how many should we have to optimize our project schedule? これをプロジェクトの解決策と呼びます。I will call this the resolution of the project.

さまざまな人を対象としたさまざまなストロークDifferent strokes for different folks

要件はさまざまな業界、さまざまな種類のプロジェクト、さまざまな状況によって異なる可能性があるため、スケジュールに含めるタスクの数と、タスクの期間を決定する方法について説明します。Because the requirement might be different for different industries, different kinds of projects, and different situations, let's look at how to decide how many tasks to put in your schedule and how long tasks should be.

さまざまな種類のプロジェクトは、さまざまな種類のスケジュールを自然に呼び出します。Different kinds of projects naturally call for different kinds of schedules. 3つの異なる例について考えてみましょう。Let's think about three different examples:

  1. ソフトウェア開発Software development. 多くのソフトウェアプロジェクトには共通の特徴があります。Many software projects have common characteristics. 各ソフトウェアプロジェクトは固有のものですが、通常は、設計フェーズ、プログラミングフェーズ、品質保証フェーズ、ドキュメントフェーズ、および展開フェーズがあります。While every software project is unique, there is typically a design phase, a programming phase, a quality assurance phase, a document phase, and a deployment phase. ソフトウェアプロジェクトは、通常、週または月単位で測定されます。これは、1日のタスクに長期間にわたって適しています。Software projects are typically measured in weeks or months, and that lends itself to tasks that are a day to a couple of weeks long. リソースの割り当ては、多くの場合、個々のレベルに割り当てられます。Resource allocation here is often assigned to the individual level.

    ソフトウェアを開発するためのアジャイルプロセスを採用しているユーザーは、1週間または2週間の短い "スプリント" を使用していますが、プロジェクト全体の期間は週単位で測定されます。Those who have embraced the Agile process for developing software look to short "sprints" of one or two weeks and within that sprint put tasks that are of brief duration, but the overall project duration is still measured in weeks. アジャイル開発の詳細については、後で説明します。We'll talk more about Agile development a bit later.

    アジャイルスプリントのガントチャートビュー

  2. EPC エンジニアリング、調達、および建設EPC - Engineering, Procurement, and Construction. EPC プロジェクトは、重要なパスのスケジュール方法を開始する場所です。EPC projects are where the Critical Path Scheduling methodology got its start. この種のプロジェクトでは、非常に大きな問題が開発されています。In this kind of project, something very big is being developed. これは、PERT 図を開始した Polaris ミサイルプロジェクトのような大規模な防衛プロジェクトになる場合もあります。また、海外の石油掘削、新しい船、または発電施設の場合もあります。It could be a large defense project like the Polaris Missile project that gave PERT diagrams their start, or it could be an offshore oil rig, a new ship, or a power plant. これらの種類のプロジェクトには、完成したプロジェクトが考案されるエンジニアリングフェーズがあります。In these kinds of projects there is an engineering phase where the finished project is conceived. 通常、エンジニアリングフェーズには、以前に設計されたことがないアスペクトがあります。The Engineering phase typically has some aspect that has never been designed before. 調達フェーズでは、プロジェクトの要素に対する備品の提供またはサブ契約の配信を検索し、管理します。The Procurement phase looks at locating, contracting for and managing the delivery of supplies or sub-contracts for elements of the project. 構築フェーズでは、最終的な製品が構築され、使用するために再構成されます。In the Construction phase, the final product is constructed and then commissioned for use. 通常、EPC プロジェクトのスケジュールは、数か月または数年から数か月にわたって継続していることが予想されます。We typically think of EPC project schedules in many months or several years with activity durations lasting anywhere from a couple of weeks to a couple of months. このようなプロジェクトに 5000 ~ 2万タスクを割り当てることはほとんどありません。It's not at all unusual to have 5,000 to 20,000 tasks on such a project. ここでのリソースのスケジュール設定は、ほとんどが個人ではなくスキルレベルに割り当てられています。 (趣味に追加するため)、プログラムまたはマスタープロジェクトに多数のサブプロジェクトが作成され、管理が容易になります。Resource scheduling here is almost always assigned to the skill level rather than the individual, and (just to add to the fun) there may be many sub-projects made into a program or master project for ease of management.

    複数のプロジェクトとサブプロジェクトのガントチャートビュー

  3. プラントのシャットダウンPlant shutdown. プラントのシャットダウンや、保守のためのターンアラウンドに対してプロジェクトスケジュールを設定する場合は、可能な限り最も厳しいスケジュール環境のいずれかで作業しています。When you do a project schedule for a plant shutdown and turnaround for maintenance you are working in one of the most challenging scheduling environments possible. 工場のシャットダウンによるメンテナンスには、2つのフレーバーが用意されています。計画と緊急。A plant shutdown to do maintenance comes in two flavors: planned and emergency. 緊急の種類は少しだけ残しておきましょう。これは自分だけの世界です。Let's leave the emergency type aside for a moment; it's a world unto itself. 計画中の工場のシャットダウンの期間は、プラントの種類に大きく依存します。The duration of a planned plant shutdown is heavily dependent on the type of plant. たとえば、核電力工場のユニットでは、"高速" プラントのシャットダウンとターンアラウンドを12か月間実行できます。A nuclear power plant unit, for example, might do a "fast" plant shutdown and turnaround in 12 months. オイル refinery は4-6 週間になることがあります。An oil refinery might last 4-6 weeks. しかし、最も注目すべきプラントプロジェクトスケジュールの種類は、スチールミル、ペーパーミル、または同様のような製造ミルです。But the type of plant project schedule that I find most interesting is a manufacturing mill like a steel mill, a paper mill, or something similar. このような植物には、世界中に数千人または数万の植物があり、毎年、定期的にメンテナンスを行う必要があります。There are thousands or tens of thousands of such plants around the world, and they must undergo regular maintenance every year or so.

    このような状況でのシャットダウンのコストは、通常、機会コストで測定されます。プラントがアイドル状態になっていて、メンテナンス中の場合に、生産されない製品のコスト。The cost of the shutdown for these situations is usually measured in opportunity cost; the cost of the product that will not be produced while the plant is idle and undergoing maintenance. このコストは時間単位で計測され、1時間あたりに $15万を $25万することができます。This cost is measured in hours, and the cost can be upwards of $150,000 to $250,000 per hour! そのため、ジョブが完了するまでには、1分間かかる負荷が発生します。So the pressure is on minute-by-minute to get the job done. このような状況では、通常、シャットダウンには5-8 日が続き、1日の遅延は百万単位で計算されます。In this kind of situation, the shutdown typically lasts 5-8 days and the delay of a single day is calculated in the millions. 従来よりも長い頻度でスケジュールを使用している場合は、短時間で、「多くのタスクが必要になるかもしれません」と考えることができます。If you are only used to longer, more traditional schedules, you might think that in a few short days, "how many tasks could there typically be?" しかし、このようなシャットダウンでは、2000 ~ 4000 のタスクを、それぞれ15分から数時間に保持するので、通常はそうではありません。but it's not at all unusual for such a shutdown to have 2,000 to 4,000 tasks, each lasting from 15 minutes to a couple of hours. ここでは、リソースの割り当てはスキルによって実行されますが、リソースの平準化はめったに行われません。Resource assignments here are done by skill but resource leveling is rarely done on personnel. 時間あたりのコストが高いほど、プロジェクトにより多くの人を追加した場合でも、急いで作業するだけで済むとは言えません。With the cost per hour being so intense, it does not matter if you put more people on the project, just get it done in a hurry. このような状況でのリソースの平準化は、多くの場合、制限の厳しいボトルネックに対して行われます。Resource leveling in this situation is often done for highly constrained bottlenecks. たとえば、「私たちは、discretely を管理することができるように、電気の部屋に2人のユーザーを収めることができます。For example, "we can only fit two people in the electrical room, so that's got to be managed discretely".

    シーケンシャルタスクのガントチャートビュー

これで3種類の例が用意されていますが、他にも多数ありますが、これらの3つの方法は、すぐに説明するために役立ちます。Ok, we now have three kinds of examples, and there are many more, but these three will serve the purposes of the discussion just fine. Type one (ソフトウェア開発) では、通常、2日から2週間の期間のタスクを取得します。In type one (Software development), we get tasks that are typically a day or two days to two weeks long. タイプ 2 (EPC) では、週または月の長さのタスクを取得します。In type two (EPC), we get tasks that are weeks or months long. Type 3 (工場でのシャットダウン) では、6分 (1 時間のうち1時間)、10分、15分 (1/4) の単位で測定されたタスクを、最大で2時間で取得します。In type three (Plant shutdown), we get tasks that are measured in units of 6 minutes (1/10th of an hour), 10 minutes, 15 minutes (1/4 of an hour), up to a couple of hours long. 場合によっては、短いタスクに意味があり、長いタスクの方が適していることがよくあります。It's obvious that in some cases, short tasks make sense and in others long tasks are more appropriate. 同じロジックを使用している場合、多くの場合、多くのタスクが必要になることもありますが、そうでない場合もあります。Following the same logic, sometimes it makes sense to have a huge number of tasks and sometimes it just doesn't.

プロジェクトの解決策を選択する際の考慮事項Factors in choosing your project resolution

これらの3つの違いにより、2か月間の EPC プロジェクトタスクが6日間のシャットダウンスケジュールで ridiculous ようになり、EPC またはソフトウェアプロジェクトで15分のタスクが停止することが簡単にわかります。With these three distinctions, it's easy to see that the two-month EPC project task would look ridiculous in a six-day shutdown schedule and that a 15-minute task would be out of place in the EPC or Software project. しかし、この記事に戻って、「Vandersluis 氏はソフトウェアプロジェクトを使用して、タスクの長さを1-10 日間にする必要がある」と言うだけでなく、どのようなレベルの解決策を選択すべきか、どのようなプロジェクトのどのような特性があるかを判断します。But aside from referring back to this article and saying, "Vandersluis says it's a software project so tasks can only be 1-10 days long," (and please, don't do that) what characteristics of the project tell us what level of resolution to choose? いくつかの点を見てみましょう。Let's take a look at a few obvious ones:

プロジェクトの期間How long is the project?

最もわかりやすいものから始めましょう。Let's start with the most obvious. シャットダウンの例に示すように、プロジェクトの長さが数日になることが予想される場合は、数日かかるタスクがあると意味がありません。If your project is expected to be a few days long, such as in our Shutdown example, then having tasks that are several days long makes no sense at all. トップダウンアプローチ以降では、多くの場合、範囲のサブ分割について考えています。Starting with a top-down approach is often productive when we think about sub-dividing the scope. 作業分解構造の考え方を使用します。Use work-breakdown structure thinking. 主要なコンポーネントから始めます。Start with the major components. 4未満で、アイテム数が20未満であることを考慮してください。Think about having no less than 4 and no more than 20 items.

ルールですか?Is it a rule? いいえもちろんそうじゃないです。No, of course not.

一般的な意味があります。It's common sense. 4未満の場合は、作業を分割して、20を超えると、一度に1つの注意を置くのが困難になります。Less than 4 makes you wonder why you divided the work up at all and more than 20 is too hard to hold in one's mind at one time. 個人的には、1つの WBS 要素に8個を超えるアイテムが含まれていますが、八角形が最も複雑な単純な図形であると考えられるようになりました。Personally I go with no more than 8 items per WBS element and that's because of some article I read years ago that suggested that an octagon was the most complex simple shape the mind could immediately recognize.

このことについては、しばらくお待ちください。Think about that for a moment. 円、三角形、四角形、五角形、6辺を持つ六角形、heptagon が7つの辺 (ok、視覚的には難しい)、および八角形を識別できます。You can identify a circle, a triangle, a square, a pentagon, a hexagon which has 6 sides, a heptagon which has 7 sides (ok, that one is hard to visualize) and an octagon.

9番目の図形をカウントせずに識別できますか。Can you identify a 9-sided shape without counting? できません。I can't. これは、trivia buffs の場合は "nonagon" と呼ばれます。It's called a "nonagon" for you trivia buffs.

そのため、個人的には8つのアイテムの制限を追求していますが、経験則は4-20 です。So, personally, I strive for the 8-item limit but my rule of thumb is 4-20.

検索した要素ごとに、作業を分割する方法について考えます。For each element that you looked at, think about how you should divide up the work. ここでも、4-20 ルールを考えてみます。Again, think of the 4-20 rule. しかし、いつ停止するかを知ることは、シークレットです。But knowing when to stop is the secret. 新しいプロジェクト管理者は、corridor のすべてのステップが管理されるタスクであるまで、サブ分割とサブ分割とサブ分割を行います。Newer project managers will sub-divide and sub-divide and sub-divide until every step down the corridor is a managed task. タスクの長さについては、次のような適切な watershed 質問をお寄せください。Some good watershed questions you can ask yourself about the length of a task could be:

  • このタスクが遅れた場合、どのような操作が必要ですか。What action would I take if this task was late? 回答が ' nothing ' の場合は、考えているタスクが小さすぎて管理できないことを示しています。If the answer is 'nothing' then it's a good indication that the task you're thinking of is too small to be worth managing. そのような場合は、あまり詳しい情報を参照してください。If that's the case you are looking in too much detail. レベルをバックアップし、ステップバックして、完了したかどうかを確認します。Back up a level, take a step back, and see if you are done.

  • このタスクの更新時に、タスク自体よりも長くかかるデータを収集しますか?Will collecting the data on the update of this task take longer than the task itself? スケジュールされたタスクを管理するためにどのような工数が行われるかは常に考えられるわけではありませんが、少しの時間があったとしても考える価値があります。We do not always think of what kind of effort it will take to manage a scheduled task, but it's worthwhile to think about even if for a moment. 完了するよりもタスクを管理するために、より多くの作業が必要になる場合は、そのタスクが詳細レベルで定義されている可能性が高いことを示しています。If it's going to take more effort to manage the task than it will take to complete, then that is a good indication that the task is being defined at too fine a level of detail.

  • タスクの期間How long is this task? 作業の分割が行われると、minuscule がどのようになるかがわからなくなることがあります。When we are sub-dividing work, sometimes we lose sight of how minuscule a task becomes. 最上位レベルの大きなフェーズはおそらく数週間にわたっていますが、粒度のレベルがいくつかあるので、管理するタスクを定義するためのトラップを簡単に行うことができます。The big phases at the top level were perhaps weeks long, but as we get down a couple of levels of granularity, we can easily fall into the trap of defining a task to be managed that is only a few minutes long. 小さなタスクに到達した場合は、それらを管理するメリットについてたずねる必要があります。When we get to tiny tasks, we have to ask what the benefit would be of managing them.

実際に説明してきたことについて、現実のチェックを適用しましょう。Let's apply a reality check to what I've just talked about. 2年間の EPC プロジェクトでは、1週間のタスクが遅れている場合は、ほとんどの場合、対策を講じる価値はありません。In a two-year EPC project, if a one-week task is a day late, it's almost certainly not worth taking action over. 6か月のソフトウェアプロジェクトでは、1週間遅れた1週間のタスクは、アクションを実行する価値がありません。In a six-month Software project, a one-week task that is a day late is probably not worth taking action over. 6日間のシャットダウンプロジェクトでは、前日の1週間のタスクは大規模な緊急事態です。In a six-day Shutdown project, a one-week task that is a day late is a massive emergency. つまり、EPC プロジェクトの1週間のタスクは、詳細レベルが低すぎることがあります。ソフトウェアプロジェクトでは、おそらく正しいことがすぐに考えられます。そして、シャットダウンプロジェクトでは、ほぼ間違いなく詳細に細分化する必要があります。In other words, a one-week task in the EPC project may be too fine a level of detail; in the software project, it's probably just about right; and in the Shutdown project, it almost certainly needs to be broken down into more detail.

関係するリソースの数How many resources are involved?

私たちはスコープに対して作業しているだけですが、どのような解決策を必要としているのかを考えてみましょう。I know we are just working on the scope, but when we look at what kind of resolution we require, it's worthwhile to think about how many people will be working on a task. たとえば、大規模な EPC プロジェクトでは、作業フェーズに関わる1つのスキルの労働者数が数十になることがあります。In a large EPC project, for example, we may have dozens of workers from one skill involved in a phase of work. しかし、同じタスクで多くの異なるスキルを使用した場合、そのタスクを管理することは不可能であれば、非常に困難になります。But when we end up with many different skills in the same task, managing that task becomes very challenging, if not impossible. そのような状況では、多くの異なるスキルを必要とするタスクを分割する必要がある場合があります。So, in that situation, tasks that require many different skills probably have to be divided up.

ソフトウェアプロジェクトでは、ほとんどすべての個人が、独自の機能を備えた非常に技術的なリソースとして考えられる傾向があります。In a software project, we tend to think of almost every individual as a highly technical resource with unique capabilities. さらに、ソフトウェアプロジェクトでは、1人のユーザーに割り当てられたタスクが1つだけで、部署内で再割り当てされるタスクが多いことがよくあります。Plus, in software projects it is common to have many tasks that are re-assignable within a department but only one task assigned to one person. そのため、特定のリソースグループまたは部署の1人の人物レベル (インターフェイスプログラミングなど) に割り当てられたタスクがある場合は、さらに詳しい情報が必要ないということを伝えるために十分に近づいています。So when we have tasks that are allocated to a one-person level of a particular resource group or department (for example interface programming) we are close enough to say that we do not need more detail.

リソースをどのように管理するか、または細分化するかHow are resources managed or sub-divided?

リソースがどのように管理されるかは、タスクをサブ分割する方法の大きな要因です。How resources are managed is a big determinant in how to sub-divide your tasks. たとえば、大規模な EPC プロジェクトでは、プロジェクトが大量のサブ請負業者に parceled されるサブプロジェクトになることがよくあります。In large EPC projects, for example, projects are often cut up into sub-projects that are parceled out to huge sub-contractors. このような状況では、いくつかの作業を行う必要があります。In this situation we need to do a couple of things:

  • 作業を定義して、プロジェクトマネージャーが、進行していることに自信を持ってサブ請負業者を監督できるようにすることが大きな要因になります。Define the work in a way that lets a project manager oversee the sub-contractor with confidence that progress being made is a big factor.

  • サブ請負業者のプロジェクト管理スタッフおよびエンジニアリングスタッフがあいまいさを持たないことを意味するように、タスクを定義します。Define the tasks in a way that the sub-contractor's project management and engineering staff will understand what they mean with no ambiguity.

  • 標準として採用した解決レベルが、サブ請負業者によって認識され、合意されていることを確認してください。Ensure that the level of resolution that you have adopted as your standard is understood and agreed to by the sub-contractor.

ソフトウェア、生物学的調査、エンジニアリングなどの白色のプロジェクトを見ると、多くの場合、プロジェクトマネージャーがリソースを一切所有しておられません。また、さまざまなプロジェクト間でリソースを割り当てる部署のマネージャー間で作業する必要があります。When we look at white-collar projects such as software, biological research, or engineering, we are most likely to encounter a Matrix Management structure where project managers own none of the resources and we must work across department managers who allocate those resources across many different projects. この場合、主な質問は次のようになります。In this case, the key questions would be:

  • 1日に複数のリソースが作業する可能性があるプロジェクトの数How many projects is a resource likely to work on across a single day?

  • あるプロジェクトから別のプロジェクトに切り替えられる従業員には、どのくらいの時間がかかりますか?How long does it take an employee to switch from one project to another?

  • 従業員とリソース部門のマネージャーの両方が、適切なスキルを割り当てられる方法を理解していることを、作業が定義されているかどうか。Is the work defined such that both the employees and the resource department managers understand how to allocate the right skill to it?

シャットダウンまたは建設プロジェクトを考えると、crews では、目的に特化したものが使用される傾向があります。When we look at a Shutdown or Construction project, we tend to work across crews that are purpose-built. このような状況では、リソースチームリーダーが電気チームを管理していることがあります (チームが職人およびパイプを使用している場合でも、配管チーム、または Boiler Unit Refurbishing Team)。In these situations, a Resource Team Leader might be managing the Electrical Team (even if that team includes carpenters and pipe-fitters), a Plumbing Team, or a Boiler Unit Refurbishing Team. このような作業を開催する必要があります。このような方法では、交代して、その地域で作業中の他のクルーの上に到着しないようにすることができます。The work has to be organized in such a way that the crew can be kept busy throughout the shift and that they won't arrive on top of another crew already working in something in that area. シャットダウンプロジェクトを完了することが非常に厳しいということは、多くの場合、作業を最初に作業を行い、スケジュールを設定し、次にリソースチームリーダーによって再グループ化とサブグループ化を行い、チームリーダーがそれぞれの作業を1つのドキュメントにまとめ、プロジェクト全体を別のドキュメントに配置できるようにします。Given the intense pressure of getting a Shutdown project complete, the work is often organized by work first, scheduled, and then regrouped and sub-divided by a Resource Team Leader so each team leader can walk around with only their tasks in one document and with the entire project in context in another. そのため、従業員やリソースチームリーダーが理解できるような方法でタスクを定義する必要があります。So tasks have to be defined in a way that is understandable by the employee and by the Resource Team Leader. ここでのタスクは、1時間以内に定義されている可能性があります。Tasks here are probably defined down to the hour or with even more granularity to the tenth or quarter of an hour.

データを収集するのにどれくらいの時間がかかりますか? どのくらいの時間がかかりますか?How quickly can you gather data and how much effort does that take?

プロジェクトのデータを1週間のうちに適切に表示されるようにするために使用していて、プロジェクトのデータをレビュー対象にしているときには、ばかげた質問のように思われますが、プロジェクトの解決レベルを決定しようとすると、これは重要な質問になることがあります。It sounds like a silly question when you're used to seeing your project data all nicely lined up at the end of the week to be reviewed, but when you are trying to determine the level of resolution of your project, this can be a key question. たとえば、多数のサブ請負業者を使用して作業している場合は、ある程度の週または月単位の更新プログラムが表示されることがあります。For example, when you are working through numerous sub-contractors, it is likely that you will get some kind of weekly or monthly update. 実際には、project management update 句を契約に組み込むことが重要です。In fact, building the project management update clause into your contract is essential. このような状況では、これらの異なる企業のデータを独自のものに統合する必要があります。進捗状況のデータが適切であることを確認し、独自の分析とレポートを実行します。In this situation you have to integrate the data from these different companies into your own, validate that the progress data makes sense, and then do your own analysis and reporting. EPC モードでは、おそらく月ごとに発生します。In an EPC mode, this is probably a monthly occurrence.

シャットダウンプロジェクトでは、shift キーを押しながらプロジェクトを更新し、すぐに更新して、次のシフトの途中でリソースチームリーダーの更新プログラムを取得する必要があります。In a shutdown project, you will need to be updating your project every shift, update it quickly, and get the updates to the Resource Team Leaders in the middle of the next shift. このような状況では、プロジェクトの担当者は、移行中のすべてのプラントで、データをリアルタイムに近い状態で収集し、リソースチームリーダーと Foremen が、割り当ての進行状況を「引き継ぐ」シートに使用します。In this situation, project personnel swarm all over the plant all during the shift, gathering data in as close to real time as they can and having Resource Team Leaders and Foremen use 'take-down' sheets to 'take-down' the progress of their assignments. ソフトウェアまたは研究プロジェクトでは、週単位のスケジュールで作業しているかもしれません。または、個人が自分の進捗状況を報告し、毎日または2つ以上の承認を経ている場合などが考えられます。In a software or research project, you are probably working on a weekly schedule or something like it with individuals reporting their own progress and going through approvals over a day or two.

これは、データの収集にコストがかかるため、プロジェクトで必要なタスクの数を確認するときに考慮する重要な点です。This is an important point to consider when you are looking at how many tasks to have in your project, because there is a cost to gathering the data.

データを収集するコストや、収集されるデータの投資収益率を考慮することが重要なのは、データの収集、承認、統合、分析、および定期的なデータの報告がどれだけ短時間で済むかを考えることです。So thinking about how quickly you can collect, approve, integrate, analyze, and report the data on a regular cyclical basis is key, as is the consideration of the cost of collecting the data and the return on investment of that data being collected.

更新される頻度How often will we update?

収集できるデータの量を決定するには、次の2つのキーを使用します。Here are two keys to determine how much data you can collect and include:

  • データを収集する方法について考えてみましょう。Think about how you will collect your data.

  • プロジェクトを十分に更新し、プロジェクトとリソースを正しい方向にガイドするために必要な意思決定ツールを使用して管理を提供する頻度について考えてみてください。Think about how often you can reasonably update your project and provide management with the decision-making tools required to guide the project and the resources in the right direction.

プロジェクトマネージャーによっては、' リアルタイム ' プロジェクト管理およびプロジェクトコレクションに移行する必要があると判断していますが、理論上は実際にはそれを実現することが非常に困難です。I've seen some project managers insist that they want to move to 'real-time' project management and project collection and while this may be possible in theory, it is terribly difficult to realize in practice.

プロジェクト管理データを確認するときは、いくつかの仮定を行います。When we look at project management data we make some assumptions. 次のことを前提としています。We assume that:

  • データはすべて含まれています。The data is all there. 更新されたタスクとそうでないタスクを調べることは期待されていません。We do not expect to be looking at some tasks that are updated and other that are not.

  • データはすべて同じ時点で更新されましたThe data was all updated at a similar time. タスクの半分が数分前に更新されたが、残りの半分が2週間にわたって更新されていないとは想定していません。We do not expect that half the tasks were updated a few minutes ago but the other half have not been updated for two weeks.

  • データには、ある程度の承認がありました。The data has all had some level of approval. プロジェクトマネージャーは、表示されているデータを分離し、「これはプロジェクトを忠実かつ正確に表現する」と言うことができると考えています。We expect the project manager to stand behind the data being presented and that he or she is able to say "This is a fair and accurate representation of the project."

  • データは一緒に属します。The data belongs together. 特にレポートと分析を設計していない限り、コストとリソースを使用してリスクを軽減することは期待されていません。We do not expect risk to be blurred with costs and with resources unless we have specifically designed our reports and analysis that way.

前述のポイントを解決できた場合に、リアルタイムプロジェクト管理の概念について興奮している経営幹部には、多くの人がいるでしょう。I often ask executives who are excited about the concept of real-time project management what they will do if we could overcome the points I just raised above. 「1週間全体で管理上の意思決定を行う準備ができていますか?」"Are you prepared to take management decisions all throughout the week?" 質問します。I'll ask. 応答は、解決のレベルによって異なります。The response should depend on the level of resolution. シャットダウンプロジェクトでは、答えは ' Yes ' にします。In a shutdown project the answer had better be 'Yes'. ソフトウェアプロジェクトでは、「いいえ」という答えがおそらく毎週行われます。In a software project, the answer is probably 'No, we'll do that weekly'. また、EPC プロジェクトでは、' 毎月 ' という答えがあります。And in an EPC project the answer would be, 'Monthly'.

ある時点では、「プロジェクトレポートを迅速に提供すれば、効率が向上することはない」ということがあります。At some point the law of diminishing returns kick in to say, "Delivering project reports any quicker will not give us any increase in efficiency."

作業のレビューReviewing your work

考えられる食品がありましたが、データをサブ分割するために Work 降伏方法を使用しており、データの詳細が定義されていないことを確認しています。You have now had some food for thought, you have used the Work Breakdown Method to sub-divide your data, and you have watched for some of the warning signs that the data is too finely defined. ここで、壁に対してスケジュールを設定し、戻って、プロジェクトをいくつかの視点で確認します。Now it is time to lean the schedule up against the wall, step back, and look at the project with some perspective. 驚くほど、多くのプロジェクトマネージャーはこれを行いません。Amazingly, many project managers never do this. これらのユーザーは、最後に定義された詳細情報を取得することになり、タスクを再度開始することができ、自分たちが自分たちが行ったことが管理する悪夢であるかどうかを確認することがなくなります。They get so caught up in getting the last details defined and are so busy sub-dividing tasks again and again that they push themselves right up to the go-live deadline and never look up to see whether what they have made will be a nightmare to manage.

場合によっては、経営幹部が、"詳細がより良い" というすべての MBA トレーニングから、6か月間のプロジェクトに5分または15分のタスクをプッシュしていることが確認されます。In some cases, executives are sure from all that MBA training that "more detail is better" and they are pushing for those 5-minute or 15-minute tasks on six-month-long projects.

プロジェクトを開始する前に、いつでも簡単に変更することができます。そのため、必要に応じてスケジュールを作成するためのスケジュールを作成するための作業を行います。Changing the project before it starts is always easier than at any time later, so build time into your schedule-building activity to rework the schedule if required.

それほど多くのことはありませんか。Is it too much?

プロジェクト管理者が作成した対象の範囲を調べて、詳細レベルが十分でないことを認識している場合があります。Sometimes project managers look at the scope of what they have created and realize that they are at too fine a level of detail. その場合は、修正がわかります。If that is the case, the fix is obvious. 多くの作業が必要な場合がありますが、後でレベルを移動してスケジュールをより簡単にすることができます。It may be a lot of work, but you will thank yourself later to make the schedule simpler by moving up a level.

場合によっては、図が非常に簡単になることがあります。Sometimes the picture is not so easy. 場合によっては、スケジュール全体が構成されているだけで、プロジェクトマネージャーが複雑な動作を確認できます。In some cases, it is only once the entire schedule is assembled that the project manager can see how complex it is. 複雑なプロジェクトは、その性質、riskier、および今日の経済のリスクによって、プロジェクトの主要な選択要因となります。Complex projects are, by their very nature, riskier, and risk in today's economy is a key selection factor for projects. このような複雑なプロジェクトを開始する前に検討する価値がある質問には、次のようなものがあります。Some questions that are worth considering before such a complex project gets underway might be:

  • このようにすることはできますか?Can we do it in pieces? リスクのあるプロジェクトの中には、大幅に小さなサイズの部分に分割し、小さなプロジェクトに分割することができます。Some risky projects can be broken up into smaller bite-sized portions and as smaller projects, their risk goes down. ただし、この方法を使用している場合は、各プロジェクトの完了時にそれぞれ固有の値を設定する必要があります。However, if you are using this strategy, each discrete project should have its own value when it is complete.

  • 範囲を見直す必要がありますか?Should we rethink the scope? 最も簡単な操作としては、最初に作業の設計者に戻って、スケジュールに表示される複雑さについて説明し、作業を restated できるかどうかを確認することがあります。Sometimes the simplest actions are to go back to the designers of the work in the first place, explain the complexity that seems apparent in the schedule, and see whether the work can be restated. これは、多くの場合、発生する可能性のない画期的な思考につながることがあります。This often leads to innovative thinking that would have never had a chance to occur.

この操作を実行する必要がありますか?Should we do it at all?

一部のプロジェクトは想定されていないため、取り消すのに最も安価な時間が始まります。Some projects were never meant to be, and the cheapest time to cancel them is the day before they start. プロジェクトのリスクが明らかになっただけである場合は、後で理解することをお勧めします。If the risk of the project is only now apparent, better to realize it now than later. スケジュールをプロジェクトポートフォリオ管理 (PPM) プロセスに戻すことによって得られた結果をまとめると、より複雑なプロジェクトのリスクによって、投資収益率が向上します。When you weave the findings of doing your schedule back into the Project Portfolio Management (PPM) process, you might find that the risk of the more complex project has the work score much worse in a return-on-investment scale.

機敏なA nimble… [いいえ] (アジャイルプロジェクト)no, an Agile project

アジャイルプロジェクトの管理について、いくつかのことを言うことがありますが、アジャイルファンで、この点を読んでいる場合は、自分の忍耐を歓迎します。I promised to say a few things about Agile project management and if you are an Agile fan and you have read this far, I appreciate your patience. アジャイル方式を使用してソフトウェアプロジェクトを管理することは、理念の1つですが、大規模なソフトウェア開発プロジェクトに焼き付けられていて、失敗した大きな理念になります。Managing software projects through the Agile method is something of a philosophy, but it is a more and more popular philosophy with those who have been burned on massive software development projects that failed.

アジャイルソフトウェア開発環境では、プロジェクトを非常にサイズの 1 ~ 3 週間の "スプリント" に分割し、各ミニプロジェクトの目標を有効なコードにすることにします。In an Agile software development world, we try to break our project into bite-sized, one-to-three week "sprints" and the goal for each mini-project is to end up with useable code. この例では、非常によく知られている制約の中で作業しているので、レベルの解決策がよく選択されています。In this case we are working within some fairly well-known constraints so that our level of resolution is pretty much picked for us.

1 ~ 3 週間の期間、リソースを利用できるようになり、各リソースに作業を割り当てています。We have a one- to three-week window, the resources are available to us, and we are going to assign work to each resource. この構造で定義できるタスクの数は限られており、これによって適切なレベルの解決を維持できます。The number of possible tasks that we can define in that structure is finite and this lends itself to keeping an appropriate level of resolution. はい、短すぎるタスクを定義することによって、アジャイルで問題が発生する可能性があります。Yes, you can get into trouble in Agile by defining tasks that are much too short. 「Define Field1:10 分、フィールドの定義:10 分、Field3 の定義:10 分」などの一般的な設定。"Define Field1: 10 minutes, Define Field2: 10 minutes, Define Field3: 10 minutes" etc. but it's much less common.

アジャイルは社内で使用するソフトウェアを作成している企業の開発環境向けに設計されており、多くの場合、市販ソフトウェア開発にまで拡張されています。Agile was designed for a corporate development environment where we are creating software for in-house use, and its use is often extended to commercial software development. (TimeControl の開発には、HMS のこちらのメソッドを使用します)。アジャイル方式では、maneuverable と機敏な開発部門がさらに強化されていますが、すべての業界やすべてのソフトウェア会社に対して適用されることはありません。(We use the method here at HMS for our own development of TimeControl.) The Agile method results in a more maneuverable and nimble development department but it is not going to be applicable to every industry or even every software company. ソフトウェア環境でプロジェクト管理を実行している場合は、アジャイルを使用して、そのことを理解し、最も効果的な要素 (すべて、一部、またはなし) を採用することをお勧めします。If you are doing project management in a software environment then my recommendation is to read up on Agile, learn from it, and then adopt those elements (all, some, or none) that will make you most effective.

ラッピングWrapping up

プロジェクト管理のほとんどの側面と同様に、最初は明白だと思われる質問への回答はありません。As with most aspects of project management, there's no set answer to questions that at first seem to be so obvious. プロジェクトに割り当てられているタスクの数と、それらのタスクがどれだけの期間、自分で決定する必要があるか。How many tasks you have in your project and how long each of those tasks should be is something that you need to look for yourself to decide … 必要なことを決定してください。but decide you must.

プロジェクトの解決レベルを選択することは、プロジェクトスケジュールの管理における主要な成功要因となるプロジェクト管理責任です。Choosing your project level of resolution is a project management responsibility that can be a key success factor in the management of the project schedule.

著者についてAbout the Author

Chris Vandersluis 氏は、Microsoft 認定パートナーである、カナダベースの HMS ソフトウェアである Montreal、創設者の社長およびです。Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. McGill 大学と30年以上のプロジェクト管理システムの自動化において、経済の学位が得られています。He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. プロジェクト管理協会 (PMI) の長期のメンバーであり、Microsoft Project ユーザーグループ (MPUG) の Montreal、トロント、およびケベックの章を見つけました。He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Chris が執筆した刊行物には、フォーチュン、ヘビー建設ニュース、コンピューティングカナダ雑誌、PMI の PMNetwork などが含まれており、彼はプロジェクトの時間の正規の columnist です。Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. McGill 大学の高度なプロジェクト管理を指導しており、北アメリカと世界各地のプロジェクト管理関連機能で講演していることがよくあります。He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software は、TimeControl のプロジェクト指向の timekeeping システムの発行者であり、1995以降の Microsoft Project Solution Partner になっています。HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis 氏は、次の場所に電子メールで連絡することができます。 chris.vandersluis@hms.caChris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

Chris Vandersluis 氏がより多くの EPM 関連記事を読む場合は、「HMS の EPM ガイダンスサイト (」を参照してください https://www.epmguidance.com/?page_id=39) 。If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (https://www.epmguidance.com/?page_id=39).