Good scope definition is such a critical step for project planning whether it be Plan-Driven or Delivery Driven approaches. So as we start into the year, what are some of your suggestions / hint on good project scope? A challenge we encounter quite often when first working with new clients is defining, at a fairly granular level, a project’s scope. Often organisations and clients know what they want in terms of high-level project deliverables, but have not gotten down to the nitty gritty stuff. That is the essence of good scope definition, to be able to understand the nitty gritty stuff!
Firstly, the use and alignment of a good work breakdown structure is critical to good scope definition. This is the method that work breakdown structures can be defined with a template and various levels of the project can be associated with the template:
- Level 1: – The total Program which is composed of a set of projects and this is laid out as such.
- Level 2: The project or project itself which should be deliverable orientated to get a sense of what is involved
- Level 3: The major deliverables of the project. As such this is the requirements and shows what is in and what is not in
- Level 4: Sub-tasks associated with the major deliverable. How are the requirements going to be executed on. Or the sub-requirements
- Level 5: Work Packages are identified that are elements of the sub-tasks. This is the ‘How’ question. How is this going to be done.
- Level 6: Effort or activity that is required in order to deliver the work package. This is the next level of the h
- ow and this is how the work package is going to be managed
A work breakdown structure is a logical structure of the projects activities and the template should present this. Essentially, the levels are open to interpretation and can vary depending on the application / project. What is important is the decomposition of the project into manageable work packages.
This decomposition to work packages, is achieved through the use of some standard guideline when attempting to break the project into manageable pieces of work:
- Are all major elements identified at top level? Does the WBS include the entire scope of work for the project?
- Is the scope decomposed into measurable components? In other words, can each of the work packages be measured using time (i.e. the work can be defined in term of start times and end times) and cost (i.e. can resources be applied to the work package)
- Are all lower level items necessary and is the WBS all inclusive? In this case, the work breakdown structure may have too much or too little detail.
- Would the stakeholders agree that the WBS is satisfactory? Essentially, it is the team / experts who decompose the scope of any project. However, the WBS is a tool that allow stakeholders to visual the content of a project and in turn stakeholder buy-in is required
- Can elements be scheduled, budgeted, and assigned to a unit that will accept responsibility? Each work package should be measured with time and money and should be assigned to a specific area.
- Is there too much or too little visibility and control? This is a subjective question and based on experience. The level to which the project scope is decomposed is indicative of the level of control over project work.
- Can status reports be generated at all levels? Information needs to flow from / to a project. The level of detail associated with a WBS impact on the type and quality of information available.
A Work Breakdown Structure defines the activities, work packages and task associated with the project. One of the things to note is that each of the activities can be referenced. This identifier with the activities is collectively known as the code of accounts.