テキスト2:WBS、資源見積、スケジュール
Planning a Project
In this lesson, we will plan an e-learning implementation project and then create a document to be used as a management document during implementation, monitoring and control, and closure.
I'm sure many of you are involved in or manage some kind of project on a regular basis, and I'm sure you've taken the e-learning course on project management at the beginning of this Instructional Design II course. In this section, we will skip the explanation of project management.
Here is a brief review and supplementary explanation of the WBS (Work Breakdown Structure), resource estimation, and schedule, which are the basic documents created during planning. For this task, we would like you to submit at least these three documents, but you are welcome to submit other documents as well. You may submit any other documents you wish. You can use any format you use in your daily work.
WBS
The WBS (Work Breakdown Structure) is a hierarchical diagram of all the elements (work items and outputs) that need to be executed in a project. The WBS also serves as the basis for other tasks that occur in the management and operation of the project, such as resource estimation, scheduling, work assignment, project revision, and progress monitoring and management.
Level 1, the top level of the WBS, is always the entire project.
Level 2, which is one level below, can be divided into several types as follows.
- Product decomposition: decomposition based on the physical structure of the deliverable (software, building, manual, etc.)
- Service decomposition: There is no specific structure to the deliverable, but the outcome is something that provides some work for another company (e.g., a conference, an event).
- Service decomposition: There is no specific structured deliverable, but the outcome is the result of the process to obtain the product or conclusion (e.g., cancer research, new drug development, culture change).
- Cross-cutting elements: Elements that include tasks that are commonly required for multiple deliverables. Usually technical or ancillary work (design design, assembly, system testing, etc.)
- Project management elements: Define the tasks and responsibilities of the management aspects of the project. In principle, there is only one level 2 element in any project.
The last one, "Project Management Elements," is often left out, but don't forget to describe it. If you don't, the project manager's time and effort will be lost from the plan.
After that, the project will be subdivided to the lowest level of the WBS, the "work package" (a unit of work that can be clearly defined and easily managed). It is always difficult to decide how far to subdivide, but one guideline is to consider two points: "one person is assigned to the task (can do it by himself)" and "there is a clear output.
When subdividing, it is important to have a "100 percent rule," i.e., if all the lower-level items are met, the higher-level items can be achieved. Be careful not to have any leaks when subdividing.
As mentioned above, the WBS is the basis for other tasks, but at the same time, you may notice gaps in the WBS while doing other tasks. Since each task in project management is systemic, you should have the courage to revise the WBS if you notice any gaps. On the other hand, it is also a good idea to move on from the WBS to other tasks when you are "there".
<Reference material>
Introduction to WBS for Practical Use Gregory T. Haugan (Author), Hira Itoh (Translator), Shoei-sha
(An easy-to-understand explanation of WBS.)
Resource Estimation
Resource estimation is the process of clarifying the management resources (people, goods, and money) needed for the work required to achieve the project goals.
- Personnel planning (clarification of required skills, number of people, man-hours, etc.) and whether the risks involved are understood.
- Equipment plan (necessary specifications, costs, when to prepare, etc.) and whether the risks are understood.
- Is it possible to understand the budget plan (whether the cost is sufficient or insufficient, etc.) and its risks, and what to do if the budget exceeds the initial budget?
When estimating, we consider human resources (man-days), facilities (work space, etc.), equipment (computers, servers, etc.), materials and supplies, etc. for the work package (the lowest level) of the WBS. In other words, we consider and confirm "Can we complete the work package if we have those resources? In other words, we consider and confirm whether the work package can be completed with those resources. As for the personnel plan, it would be easier to think about it if you first draw an "implementation system diagram" for the project based on the WBS.
Although it is not required this time, in an actual project, there is a "work assignment (responsibility assignment) matrix" to clarify who is responsible for which tasks, a "procurement management plan" to procure resources, and a "scope of work description" to define the tasks to be procured when procuring services, etc. It is not uncommon to prepare a "Statement of Work (SoW)" to define the work to be procured when procuring services, etc., and then implement the procurement of the estimated resources.
[Reference Links]
Work Assignment (Responsibility Assignment) Matrix (@IT Information Management Terminology Dictionary)(in Japanese)
http://www.atmarkit.co.jp/aig/04biz/ram.html
Project Management Skills Practice Training Course #9: Throwing everything away is the beginning of failure - Procurement Management (1)(in Japanese)
http://jibun.atmarkit.co.jp/lskill01/rensai/pm09/pm01.html
SOW (statement of work)Scope of Work (@IT Information Management Dictionary)
http://www.atmarkit.co.jp/aig/04biz/sow.html
Schedule
The schedule is also based on the WBS work packages. We estimate the time required to execute each work package, and sort the work packages according to the work order. Then, the start/end dates of each work package are set according to the duration of the project (while ensuring the required duration, of course). Gantt charts are commonly used to create schedules.
You should also set milestones when making the schedule. Milestones ("ichi-ryotsuka" in Japanese) are "milestones" to confirm that the project is progressing as planned and to keep to the schedule. For example, reports, presentations, and review meetings for clients. If you are working with a client or subcontractor, milestones include the delivery of your product.
It is not uncommon for a project to not go as planned, but it is difficult to determine what constitutes "going as planned" or "not going as planned. It is not practical for a project manager to keep monitoring the progress of all work packages and change the plan accordingly. Therefore, milestones are set as triggers to review the project.
Then, while the project is in progress, we should pay attention to whether the milestones can be implemented (completed) on time, and take action when it becomes difficult to do so.
Therefore, it is a good idea to think about what the milestones are and what you have to do when making the schedule. By setting milestones for the schedule you want to adhere to, you can use them as a guide to the progress of the project and as a checklist.
If various tasks are intricately related to each other, it is a good idea to use the critical path method to clarify the relationship between them (which tasks have enough time in the schedule, and which tasks will affect the entire project if they are delayed).
[Reference Links]
Critical Path:http://www.atmarkit.co.jp/aig/04biz/criticalpath.html (@IT Dictionary of Information Management Terms)
Project Management Skills Practice Training Course No.9 Throwing everything away is the beginning of failure - Procurement Management (1)(in Japanese)
http://jibun.atmarkit.co.jp/lskill01/rensai/pm09/pm01.html
About the sample case
An example (sample) of project planning and management documents for a sample case is shown below.
Please use it as a reference.
However, you do not need to follow this sample as the format is free.
In this sample, the WBS, the project implementation structure, the resource estimate, and the schedule plan are each separate documents, but as you can see, the items overlap, so you may integrate some of these documents when you create your own. If you have a form or template that you use in your daily work, you may use it.
Note that this is a "sample" and not a "model," so please be critical of what is written.
Task 12: Project Management(in Japanese)(PDF:99KB)
{mlang}
プロジェクトの計画
今回はeラーニング導入プロジェクトを計画し、その後、実施・監視コントロール・終結時に管理資料として使う書類を作成します。
皆さんの中には日頃から何らかのプロジェクトに関わられたり、マネジメントしたりしている方も多いでしょうし、このインストラクショナル・デザイン II の冒頭でプロジェクトマネジメントに関するeラーニングも受講されているはずですので、プロジェクトマネジメントのそもそもについての説明は省かせていただきます。
ここでは、計画時に作成する基本的な書類であるWBS(Work Breakdown Structure)、資源(リソース)見積、スケジュールの概要について、簡単なおさらいと補足説明をします。なお、今回のタスクとしては、最低限この3種類の書類を提出していただければ結構ですが、これ以外の書類についてご提出いただいても構いません。また、書式は自由です。日頃、皆さんが仕事等で使っている書式で構いません。
WBS
WBS(Work Breakdown Structure:作業分解図)は、プロジェクトにおいて実行しなければならない全ての要素(作業項目やアウトプット)を階層化したものです。そして、プロジェクトの管理・運営で発生する他の業務、たとえば今回作成する資源(リソース)見積、スケジュールや、業務分担、プロジェクトの修正、進捗状況の把握・管理などの基礎になるものです。
WBSの最上位であるレベル1は常にプロジェクト全体となります。
ひとつ下のレベル2の分け方には次のようにいくつかタイプがあります。
- プロダクトの分解:成果物の物理的な構造に基づく分解(ソフトウエア、ビル、マニュアルなど)
- サービスの分解:具体的に構造を持つ成果物は無いが、成果として他社に何らかの作業を提供するもの(会議、イベントなど)
- 結果の分解:具体的に構造を持つ成果物は無いが、プロダクトや結論を得るためのプロセスの結果が成果になるもの(ガン研究、新薬開発、風土改革など)
- 横断的要素:複数の成果物に共通して必要な作業を含む要素。通常、技術的または補助的な作業(設計デザイン、組み立て、システムテストなど)
- プロジェクトマネジメント要素:プロジェクトの管理面での作業や責任を定義する。どのプロジェクトでも原則としてレベル2の要素としてひとつだけ存在する。
最後の「プロジェクトマネジメント要素」は抜けがちですが、忘れずに記述するようにしましょう。そうしないと、プロジェクトマネージャーの手間は計画からモレてしまうことになってしまいます。
そしてその後、WBSの最下位のレベル「ワークパッケージ」(明確に定義でき、管理が容易な作業に分解した単位)まで細分化していくことになります。どこまで細分化していくかは常に悩ましいところですが、一つの目安としては「担当者一人がアサインされている(一人でできる)」「明確なアウトプットがある」という2点と考えておけば良いでしょう。
細分化する際に大事なことは「100パーセントルール」、つまり「下位のものを全て満たせば、その上位レベルを実現できる」ようにすることです。細分化する際にモレが発生しないように注意しましょう。
WBSは前述の通り、他の業務の基礎になりますが、同時に他の業務をする中でWBSのモレに気づくこともあります。プロジェクト管理の各作業はシステム的な(システミックな)ものですので、もし、モレなどに気づいたら、WBSを修正する勇気を持ちましょう。逆に「そこそこ」のところで、まずはWBSから他の作業に移ってみる、というのもひとつの手と言えるでしょう。
<参考資料>
実務で役立つWBS入門 Gregory T. Haugan (著), 伊藤 衡 (翻訳) 翔泳社
(WBSについて、わかりやすく解説されています。)
資源(リソース)見積
資源(リソース)見積もりは、プロジェクトの目標を達成するために必要な作業に必要な経営資源(ヒト・モノ・カネ)を明確にすることです。
- 要員計画(必要スキル、必要人数、工数等の明示)とそのリスクの把握ができているか
- 設備計画(必要スペック、費用、いつまでに用意するか等の明示)とそのリスクが把握できているか
- 予算計画(費用は十分か、不十分か等の明示)とそのリスクが把握できているか、当初予算をオーバーした場合の対処
見積もりに際してはWBSのワークパッケージ(最下位のレベル)について、人的資源(人日)、施設(作業スペース等)、設備(パソコン、サーバ等)、資材備品などを検討していきます。つまり「それらの資源があればワークパッケージが完遂できるか?」を考え、確認していくということになります。また、要員計画に関しては、まずWBSをベースにプロジェクトの「実施体制図」を書いておくと考えやすいでしょう。
今回は作成を課しませんが、実際のプロジェクトでは、誰がどの作業を行うのか、誰がどの作業について責任を持つのかを明らかにするための「業務分担(責任分担)マトリクス」、資源を調達するための「調達マネジメント計画書」、サービスなどの調達をする際に調達対象の作業を定義するための「作業範囲記述書(SoW=Statemaent of Work)」といったものを作成し、見積もった資源の調達を実施していくことが少なくありません。
[参考リンク]
業務分担(責任分担)マトリクス(@IT情報マネジメント用語事典)
http://www.atmarkit.co.jp/aig/04biz/ram.html
プロジェクトマネジメントスキル 実践養成講座第9回 丸投げは失敗の始まり——調達マネジメント(1)
http://jibun.atmarkit.co.jp/lskill01/rensai/pm09/pm01.html
SOW (statement of work)作業範囲記述書(@IT情報マネジメント用語事典)
http://www.atmarkit.co.jp/aig/04biz/sow.html
スケジュール
スケジュールに関しても、WBSのワークパッケージがベースになります。ワークパッケージの遂行に必要な期間を見積もり、作業順序に沿ってワークパッケージを並び替えます。そして、各ワークパッケージの開始日/終了日を、プロジェクトの期間に合わせて定めていきます(もちろん必要な期間を確保しながら)。スケジュール作成にはガントチャートを使うのが一般的でしょう。
また、スケジュールを立てる際にはマイルストーンを設定しましょう。マイルストーン(日本語で言う「一里塚」)は、プロジェクトが計画通り進捗しているかを確認するための、そしてスケジュールを守っていくための「節目」です。たとえばクライアントに対する報告やプレゼン、レビュー会などがそれにあたります。また、顧客や外注先との共同作業がある場合、自分側のプロダクトの引き渡し等がマイルストーンとなります。
プロジェクトでは計画通りに行かないことは珍しくないのですが、何をもって「計画通り行っている・行っていない」を判断するかは案外難しいものですし、プロジェクトマネージャーが始終全てのワークパッケージの進捗を監視し、それに従って細かく計画を変更し続けるのは現実的ではありません。そこで、プロジェクトの見直しのきっかけ(トリガー)としてマイルストーンを設定します。
そして、プロジェクト進行中は「マイルストーンが期日通り実施(完了)できるか」に注目し、それが難しそうになった場合に対処をするようにします。
従って、スケジュールを立てる際にはマイルストーンを何にするか、何にせざるをえないか、から考えると良いでしょう。厳守したいスケジュールをマイルストーンに設定することで、プロジェクトの進捗の目安や、チェックなどの目的に使うことができます。
なお、様々な作業が複雑に関連し合っている場合には、クリティカル・パス法を用いて、それぞれの関係(どの作業には日程に余裕があり、どの作業が遅れると全体に影響してしまうか)を明らかにすると良いでしょう。
[参考リンク]
クリティカルパス:http://www.atmarkit.co.jp/aig/04biz/criticalpath.html(@IT情報マネジメント用語事典)
プロジェクトマネジメントスキル 実践養成講座 第9回 丸投げは失敗の始まり——調達マネジメント(1)
http://jibun.atmarkit.co.jp/lskill01/rensai/pm09/pm01.html
サンプルケースについて
サンプルケースについてのプロジェクト計画・管理書類の例(見本)を以下に示します。
参考にしてください。
ただし、書式などは自由ですので、この見本通りに作成いただく必要はありません。
この見本では、WBS、プロジェクト実施上の体制、リソース見積、スケジュール案をそれぞれ別の書類にしていますが、見てお分かりのように項目は重複しますので、皆さんが作成される際には、これらの書類のいくつかを統合したものを作ってもかまいません。日頃、お仕事で使われている様式やテンプレートがあれば、それを使っていただいてもかまいません。
なお、「見本」であって「手本」ではありませんので、記述されている内容については批判的な視点で見てください
第12回 プロジェクト管理(PDF:99KB)