インフィニティソリューションズ株式会社ブログ

WBS作成で陥りがちな問題点

何かを作らねばならないとなると、本来何のために作るのかということを忘れ、とにかく作れば良いのだというようになってしまうことは、あってはならないことではあるが、実際にはよく見かける。プロジェクトの基本の1つともいうべきWBS(Work Breakdown Structure)作成にはどのような問題が発生しがちなのか。

brighthubpmより。「Work Breakdown Structure Pitfalls to Avoid(避けるべきWBSの問題点)

1. Neglecting to create a WBS Dictionary(WBSディクショナリを作成しない)

‘Creating a WBS dictionary is not always necessary, especially if the acronyms and category content in the WBS are obvious. This ia a common misconception. A WBS dictionary helps keep track of all of the summary and detailed activities, including a short description of what is – and what is not – included in a WBS element.’

「WBS名とカテゴリの内容が明らかであれば、WBSディクショナリは必ずしも必要ではない。これはよくある間違いだ。WBSディクショナリは、WBSの要素として何が含まれていて、何が含まれていないかについての記述が含まれており、アクティビティのサマリと詳細の全てをトラッキングできるようにするものだ。」

— 従って、これがないと、漏れや重複が発生しがち。

Work Breakdown by Jolene Curran2009, on Flickr

2. Expecting More than 100% from your WBS(WBSから100%以上のものを期待する)

‘An important WBS design principle is the 100% rule, which states that the WBS includes 100% (or everything) of what is in the project scope. However, we often hear people say that they have given a project or a task 110%. That’s fine for an individual, but a project is doomed to failure if the WBS includes more than 100% of what is in the project scope.’

「WBSを設計する上で重要な考え方は、100%ルールである。すなわち、WBSはプロジェクト・スコープに含まれるものを100%(あるいは全て)をカバーするkとおを意味する。しかしながら、プロジェクトやタスクに110%のものをセットしたというのをよく耳にする。個人ならそれでいいかもしれないが、プロジェクト・スコープにあるもの以上をWBSに含めてしまうと、プロジェクトは失敗する運命だ。」

— 決めたプロジェクト・スコープがいつのまにか拡大してしまっているかもしれない。

3. Why bother with Formal Change Control?(正式な変更管理は不要だ)

‘Companies use change management to control both internally generated and customer-driven changes in the scope of projects. Any update to a WBS, other than an elaboration of details that already exist, should require formal change control. To ignore this step invites changes in scope that can spell doom for the project.’

「企業は、社内で発生したものであれ、顧客が要因のものであれ、プロジェクト・スコープの変更を全てコントロールするために、変更管理を行う。既存のものの詳細化以外に、WBSに対するあらゆる更新は、正式な変更管理が必要だ。」

— 2と同様、いつのまにかスコープが拡大する。その観点でいくと、詳細化の際に、(意図せずとも誤って)既存にないものを付け加えてしまう恐れがあるため、詳細化を例外にするのはいかがなものか。

4. Method Orientation(手法重視)

‘The WBS should be outcome oriented and not prescriptive of methods. Methodology can change without any change to the planned outcomes. Planned outcomes or deliverables (which should be fairly rigid) should not be closely blended with actions and methods (which can be flexible).’

「WBSは成果物重視で、手法の記述であってはならない。手法は、予定している成果になんら変更を加えることなく、変更可能なのだ。予定している成果物(ほぼ固定されている)は、アクションや手法(柔軟でよい)と密接に組み合わせてはならない。」

5. To Do List Mentality(To DOリスト的考え方)

‘The To Do list approach to WBS construction stems from a manager’s belief that the WBS is actually a step-by-step procedure for doing everything. This approach can lead to the concept that managers walk around with a detailed checklist they use to check off each item as it is completed. Ultimately this leads to micro-management, which is not generally attractive to team members.’

「WBS構築をTo Doリスト的に行うのは、WBSは実際には、全てのことを行うためのステップバイステップの手順であると思っていることに起因する。この手法では、マネージャが詳細なチェックリストを持って、項目ごとに完了チェックをして回るということになりかねない。究極的にこのような手法は、マイクロ・マネージメントになり、通常、チームにとってうれしくないことだ。」

— マネージャがマイクロ・マネージメントにつながるTo DOリスト的な考えがダメな理由は、チームメンバーがどう思うかよりも、マネージャ本来の役割は、マクロ的にプロジェクトを見ることだからではなかろうか。

6. Adding Requirements in Lieu of Tasks(タスクの代わりに要件を追加する)

‘When you place a deliverable on your WBS, you can break down the deliverable into the activities required to create it. What doesn’t work is breaking down the deliverable into the requirements that describe it. Deliverables and tasks do belong in the WBS, but requirements do not.’

「WBSに成果物を設定すると、その成果物を実現するために必要なアクティビティに分解できる。成果物を、要件に分解することではない。成果物とやるべきタスクは、WBSに属するが、要件は属しないのだ。」

— WBSは要件を満たすためのタスクに分解したものであるから、WBSに要件を記述しても何も分解したことにならないことになる。

7. Skipping the Buy-In Process(巻き込むプロセスをスキップする

‘Your project team possesses all the expertise, experience, and creative thinking that will be needed to get down to the specifics of each deliverable, so naturally the WBS should be drafted with input from all team members. If the project manager creates the WBS with limited input from other project team members, they people may in turn offer little to no support for the WBS. It may be time-consuming, but in the long run it pays to engage all of the core project leaders in WBS development.’

「プロジェクトチームは、各成果物の細部に至る知見、経験、創造的な考え方を所持しているはずであるから、当然、WBS案は全てのチームメンバーからのインプットに基づき作成されるべきである。プロジェクトマネージャが他のチームメンバーからのインプットをあまりいれずにWBSを作成してしまうと、メンバーはWBSをサポートしなくなる。時間がかかるかもしれないが、長期的に見れば、WBS構築において、コアとなるプロジェクトリーダ全員を巻き込む価値がある。」

8. Too Many Tasks(タスクが多すぎる)

‘Team members are generally more productive if they are held accountable for reaching measurable achievements rather than completing a laundry list of tasks. When the WBS is broken down to tasks that take just a couple of hours to complete, workers spend so much time reporting on these small tasks, and managers spend so much time keeping track of them, everyone may lose sight of the desired end result. As a general rule, WBS tasks should have durations between 1 week and 8 weeks long.’

「一般的にチームメンバーは、タスクの長ったらしいリストを完了していくより、はっきりとわかる達成度をクリアしていく方がより生産的になる。WBSを数時間で完了するタスクに分解すると、メンバーは小規模なタスクの報告に多大な時間を費やし、マネージャもそれをトレースするのに時間を費やし、誰も達成すべき最終結果に目を向けなくなる。一般的にWBSのタスクは1週間から8週間の期間に収まるようにする。」

— むろん、WBSのタスクの期間は、プロジェクト全体の期間との相対関係を考慮する必要があるが。