Product and Project Scope
A project’s scope is all the work that needs to be done to produce the project deliverable(s). Deliverables are what remain at project completion – a product, process or service produced for an internal or external client. Some projects have many deliverables; others just have one. Defining project scope is an important first step to preparing a project plan no matter what project management methodology we use – waterfall, agile, scrum, and even PRINCE2 (the UK government’s nightmarish methodology inexplicably adopted by our own government to the delight of exorbitantly-priced PRINCE2 training purveyors).
What determines a project’s scope is the product, process or service that the project intends to produce with its desired features or characteristics, called the product scope. The project scope includes everything we need to do to ensure the product scope is achieved. So project scope and product scope are inextricably linked. Thus, we must have a well-defined product scope in order to develop a well-defined project scope.
We need to be clear about the product scope in order to clearly identify the project work needed (and not needed – “exclusions”). If requirements aren’t completely identified and unambiguously described, and if there is no effective change control, scope creep or requirements creep may ensue. Therefore a detailed and accurate product scope or specification for the final deliverable(s) is an essential prelude to identifying project scope. Incidentally, the project scope is sometimes expressed as a scope statement or a statement of work (SOW).
If we are awarded a project through a contract, we will usually get the product scope or specification with the contract. However, if the project is initiated by our own organisation, we will need to develop the product scope by consulting relevant stakeholders – particularly the users. The product scope includes the required features, functions and characteristics of the product. And should we be responsible for developing the product scope, we should check back periodically to make sure that the product is still a valid solution to the problem or opportunity. Sometimes the business rationale for a project diminishes or even evaporates (although this doesn’t always cause a halt to a project, since sometimes sunk costs make it awkward to admit defeat.)
The purpose of creating a product scope or specification is to clearly define the requirements for the final deliverable. Once we are clear about what the project is to produce with the required functionality, “user requirements” may then be prioritised, which is important if there are tough budgetary constraints that mean the final deliverable may not have all the bells and whistles that the stakeholders desire. Thus, the purpose of the product specification or product requirements document (PRD) is to clearly and unambiguously articulate the product’s features, functionality and behaviour. The project team will use this specification to determine the project scope. Remember a specification that is easy to navigate is more likely to be read, understood and complied with. Should we need to prepare a specification some points to keep in mind in order to minimise misinterpretation and costs are:
- – Use plain English, avoiding legalese and jargon and restricting vocabulary to words in common usage. Avoid acronyms and abbreviations, unless they are very well known. And remember “a picture is worth a 1000 words”, which includes drawings, photos, videos and sketches, whereby a complex idea can often be conveyed with a single image.
- – Consider developing an open or performance specification that describes required performance without mandating how this performance is to be achieved. An open specification leaves freedom for the project team to create a suitable product. Such specifications must state the acceptable conditions under which the product is to perform. Most projects will involve a combination of performance and prescriptive specifications.
- – Use the word “shall” to define a requirement rather than “should” or “could.” Requirements expressed as “shall” must be fully and properly met.
- – Where performance would not be adversely affected, specify off-the-shelf components rather than one-off specially manufactured items to save cost, reduce lead-times and help ensure future availability.
- – Where possible specify with figures in preference to adjectives and adverbs – that is, be precise and measurable. Rather than “light” better to state “not more than 10 grams.” Rather than “quickly” better to state “not less than 10 kilometres per hour.”
- – Where performance would not be adversely affected, to help minimise cost and time, provide a range rather than a single figure – that is, allow some latitude or tolerance. Rather than “100 grams” better to state “95 – 105 grams.” Rather than “50 metres per second” better to state “45 – 55 metres per second.”
Once the product scope is clear, the best way to illustrate the project scope is in the form of a Work Breakdown Structure (WBS), which for a simple project is essentially a task list or “to-do list” as for the following recruiting and selection project:
Notice that the above WBS tasks are described using an active verb and a noun. For example, “Conduct Job Analysis” where the active verb is “Conduct” and the noun or interim deliverable is “Job Analysis”. Using conventional project management language the start and finish of a task is an “event” and some important events may be labelled “milestones” that are important achievements that mark progress along the project timeline (eg, “Job Analysis Complete”). For a bigger and more complex project the WBS usually looks like an organisation chart. Using MS Project terminology, as shown below, “Summary Tasks” break down to “Tasks” that break down to “Subtasks” and so on with default codes assigned. The lowest level of breakdown or terminal element is often referred to as a “Work Package” (WP). Other scheduling software and methodologies may use the terms such as “phases”, “entries” and “activities”.
To ensure the management work associated with project planning, implementation, control and closure is also costed, this work may be included in the WBS, shown below as “Manage Project”, or more commonly some 10 to 15% is added to the budget to cover these overhead expenses incurred over the life of the project. Each work package (WP), which is the lowest level of breakdown, may be included in a WBS dictionary, which is a document that more fully describes each component in the WBS as at http://www.projectmanagementdocs.com/project-planning-templates/work-breakdown-structure-wbs.html#axzz3u4B6fD1r.
Each chunk of work is usually assigned a unique code for easy reference. A useful codification system must be readily expandable to accommodate any extra work that may be identified as a result of variations. The following example shows a codified WBS for a landscaping project. This example includes estimated work package durations where “d” is an abbreviation for day. A costed-WBS (CWBS) would show estimated costs. If we use MS Project it will automatically produce a default number for each task, the first task in our task list would be number 1. If that task has three subtasks, the subtasks would be number 1.1, 1.2, and 1.3 and so on.
A WBS may be developed using sticky notes on a flipchart page, although these stickies are inclined to fall off which is possibly why the Te Rau Matatini planning team photographed in acyion below isn’t using them. Anyway, as we place these sticky notes on the chart and start to create our family tree structure, everyone can clearly see and contribute to what is being accomplished. Also this technique allows for the easy movement of work elements within the WBS. Occasionally, we will run into a project that is a “first of its kind,” but that is not usually the case. Mostly someone has done a similar project in the past and there may be a WBS from a previous project that we can use as a start template. We may need to run the team through a WBS training class prior to the session, to be sure everyone has the same foundational knowledge.
Below is a photo of a erudite project team member with his first draft of a WBS for a Nulook Ltd construction project where task responsibilities are colour coded.
While a WBS is usually prepared in family tree format, it is often published as an indented task list if only to save space as shown below for this landscaping project example taken from the Project Management Institute’s PMBOK (Project Management Body of Knowledge).
Creating the WBS is usually a top-down process whereby we start with our project goal and identify what work needs to be done to achieve that goal. We usually do this by collaborating with the project team and/or experts to decompose the work into logical chucks until we get to an appropriate level of breakdown called a Work Package (WP), which is a chunk of work that in due course we will do ourselves, delegate to a team member or contract out. Thus, the first step to creating our WBS is to get our project planning team, and possibly key stakeholders, together in the same room, preferably one with a large whiteboard.
Once the planners are familiar with the project charter (ie, terms of reference) and product scope, the brainstorming process may start with a blank whiteboard in the centre of which we write the project goal and then in mindmap/brainstorm fashion a scribe writes around this goal all the jobs that the team suggest need to be done to achieve this goal as described in the product scope. To be useful the project goal should comply with SMART criteria, an acronym with various interpretations, which can be used to provide a more comprehensive definition for project goal setting, where: S – specific, significant, stretching, M – measurable, meaningful, motivational, A – agreed upon, attainable, achievable, acceptable, action-oriented, R – realistic, robust, and T – time-bound or timely. For example, a project goal might be “To plan and deliver a three-day annual conference for (organisation’s name) to be held in Invercargill during the period (conference dates).” If for example, we did not know where the conference was to be held, determining the conference location would then be a task in the WBS.
Another goal acronym is CLEAR – Collaborative (goals should encourage team members to work together collaboratively), Limited (goals should be limited in duration), Emotional (goals should make an emotional connection to team members, tapping their energy and passion), Appreciable (large goals should be broken down into smaller goals so they can be accomplished more quickly and easily for long-term gain), Refinable (as new situations or information arise, we give ourselves permission to refine and modify our goal). The right goal is vital, but I think I prefer SMART to which I would indeed add “clear” meaning “readily understandable,” and certainly “written down and displayed” is useful to keep us on track throughout the project planning process.
Phew – that’s a lengthy explanation, but I’m sure we recognise the need to have the right target. Incidentally, my interpretation is that the project purpose concerns the reason or justification for the project or why the project is needed (eg, “to provide shelter”), whereas the project goal is about what needs to be done (eg, “to build a house”). And a project’s objectives are subordinate to this goal and define project boundaries, parameters or constraints are typically scope, time, cost and quality.
Once the brainstorming session is done we need to edit our result by eliminating any duplication of tasks and any tasks that are outside the project scope (“exclusions”) for this particular project. Also, some tasks might be too small and others may need to be broken down further. The finished product can then be published in either hierachial or list form. WBS Schedule Pro is a helpful software package for this process, a demo version of which may be downloaded athttp://www.criticaltools. com/download.html. The WBS Charts in WBS Schedule Pro are customisable. See too the video about this product use at http://www.criticaltools.com/WBS Chart_Video.html. However, a whiteboard or flipchart is usually better than a computer screen if we wish to involve others in the WBS development process.
Producing the WBS may be part of initial project team building at project kick-off. It’s a logical thought process that provides the understanding needed to stem any anxiety should our team members feel overwhelmed and a useful opportunity to obtain their buy-in. Once completed the WBS allows us to undertake subsequent planning activities that include estimating time and cost, scheduling work, risk identification and resource allocation to culminate in the preparation of a project plan. Nevertheless, the baseline project scope may need changes (variations) as the project proceeds, so WBS version control is very important. Another way to show the WBS for a bigger project is using a table such as this:
Thus, the WBS defines and organises the total work scope for the project. It is the basis for detailed project planning. It turns one very large often intimidating piece of work – the project – into several small manageable chunks of work that are in effect smaller projects. If it’s not in the WBS, it’s not in the project. To reiterate, the reasons for breaking the project down or chunking it in this manner are:
- – To further define project scope and codify work elements for their easy reference.
- – To enhance commitment through stakeholder and team participation in building the WBS.
- – To enable us to more clearly identify resources (equipment, materials and skills) needed to complete the project.
- – To enable us to determine what work can be done in-house and what work we will need to outsource. (Many businesses contract out project work that doesn’t pertain to their core business.)
- – To allow for the assignment of clearly defined elements of work to project team members responsible for their delivery, which is often illustrated by a Responsibility Assignment Matrix (RAM).
- – To enable cost, work effort and duration estimates to be undertaken from a “bottom-up” perspective, which is invariably more accurate than the initial “order of magnitude” or “top down” estimate.
- – To allow for the identification of task relationships (dependencies) and thus enable the development of a network diagram and schedule of work often illustrated by Gantt chart.
- – To enable us to identify, analyse and respond to risks associated with the various project tasks.
- – To facilitate measurement of project progress by completed elements of work.
Incidentally, a WBS is not to be confused with a Product Breakdown Structure (PBS) that identifies the things that the project will make or outputs (deliverables) that it will produce. The PBS can be thought of as a project shopping list. It decomposes a project product or deliverable into its constituent parts in the form of a hierarchical structure. From the PBS a Product Flow Diagram can be produced to represent the order in which sub-products build into the main project product. In contrast to the PBS the WBS provides a hierarchical structure of project work items. The WBS focus is on work and things (eg, “create project plan” not simply things (eg, “project plan”). The cumbersome and bureaucratic PRINCE2 project methodology advocates that planning should be focused around products rather than tasks, whereas other methodologies do not require that a PBS or Product Flow Chart be prepared in order to produce a WBS. Below is an example PBS that shows the relationship among components for a mountain bike.
We must decide when to stop dividing work into smaller elements. The extent to which project work is broken down or “chunked” (ie, lowest level of work breakdown) may influenced by considerations such as:
- – Milestones previously determined – that is, a milestone plan of dates by when important elements of work are to start or finish. Milestones often designate the completion of project interim deliverables.
- – The size of the project. A large project is likely to be broken down further than is a small project. Thus, the extent of work breakdown is usually a function of project size. For most projects three or sometimes four levels is sufficient. Remember too that each work package is mutually exclusive – they do not overlap.
- – The “80 hour rule” suggests no work package should be larger than 80 hours work effort. For example, four people working on the same task for 20 hours would total 80 person-hours of work effort. However, this is very much a guideline only. Also, for a cost-driven project, dollars might more appropriately determine work package size.
- – The project work should not be broken down below the level where each element is a clearly definable independent and unique entity of work, its start and finish and resource needs readily apparent, and results in a measurable deliverable.
- – It is sometimes suggested that a work package should be no longer than the time between status meetings. If project status meeting are held fortnightly, then no work package should be longer than a fortnight. Personally, I suggest that meeting dates should not dictate a work package’s duration, rather work package durations (among other factors) are more likely to help us determine meeting dates.
- – When the project completion date is fixed, the work timetable (ie, schedule) will need to be carefully controlled. This may require that no work package exceed a specific duration. Thus, the need to carefully control time may influence the level of breakdown.
- – When the project budget is fixed, expenditure will need to be carefully controlled. This may require that no work package exceed a certain cost to enable more accurate control of expenditure. Thus, rigid funding/expenditure limits may also influence the level of breakdown and the size of work packages.
- – The need to delegate coherent chunks of work may require that work be broken down until different skill needs emerge. There is usually no need to further breakdown work assigned to an individual or organisation. They will break the work down as they need to, otherwise us project managers can appear to be directing people, often more technically skilled than ourselves, how to do the work – micromanagement. However, if a detailed breakdown is required, perhaps for accurate costing purposes, we should develop this in consultation with the appropriate experts.
- – The resultant WBS should be compatible with the performing organisation’s structure. When deciding the composition of work packages the project manager should consider the performing organisation’s breakdown structure (OBS) to allow assignments of suitable work packages to match appropriate functional groups.
- – Containing risk. There is no need to take the WBS down to a common level. The lowest level of WBS may vary according to risk. A risky element of work may be further broken down to help contain or exploit the risk. A non-risky piece of work may not need to be broken down further, at least not for risk management purposes.
- – While the lowest level of breakdown will depend largely on project size, it would often be a waste of time and effort to plan say a five-year project in detail, other than for the first year perhaps. Thus, more immediate work might be further broken down than is subsequent work. This allows for the ‘rolling-wave’ or ‘progressive elaboration’ process whereby we prepare in detail for the next stage only when project continuation is confirmed and sufficient information is available about the ongoing project scope.
- – In deciding whether we need to go to an additional level of detail, we might ask the team, “If you were put in charge of this deliverable, would you need to break it down to more detail to manage the work?”
Thus, the WBS is the tool that allows all projects to be broken down into smaller, more manageable projects (work packages). When developing the WBS, we should involve the people who will do the work. They will know what’s involved with the job and how those jobs can be decomposed into manageable chunks. And do check the WBS by looking at all the “children” chunks to ensure they add up to their “parent” chunk. The sum of the work at the “child” level must equal 100% of the work represented by the “parent.” Each work package should have one person overall responsible for its completion. This “single point responsibility” should permeate the entire WBS. Each WBS element can be assigned an identification code which indicates its level and component group. The WBS code ensures all project participants work to a common baseline. Remember most projects need only three or four levels of breakdown. Too many levels amount to micro-management.
Finally some considerations worth repeating for a useful WBS:
- – The WBS is developed from the top down. Tasks are subsets of summary tasks. No task is mentioned more than once. All tasks produce a deliverable or deliverables. Every project must have one task by default.
- – Tasks must add up to summary tasks. The summary tasks are mainly for communication purposes. They aren’t actually executed; they are simply the summation of related subordinate tasks. Only tasks are assigned resources.
- – Task names should include both a verb and a noun. The noun gives the task a clear output. A verb or noun by itself is an inadequate description for a WBS.
- – Each task must be clearly defined such that its completion is obvious. One individual is unambiguously responsible for the successful completion of the task. And all work within the task should occur within a sequential timeframe.
- – Sometimes to help with clarity we also mention “exclusions” – those items outside the project scope. For example, if we do not require that our house-building project needs painting then this exclusion might be mentioned.
- – If breaking down work further doesn’t make it easier to estimate, assign and track then don’t break it down. A WBS is not a project schedule. The WBS defines the “what” of a project and the project schedule defines the “when” of a project. A WBS is not required to be created in any type of order or sequence. It is simply a visual breakdown of deliverables. It is not a project plan or schedule.
- – It is important that there is no overlap in scope definition between different elements of a work breakdown structure. Such ambiguity could result in duplicated work or miscommunications about responsibility and authority, and confuse project cost accounting.
- – The WBS is a formal project document, and any changes to it require the use of a variation control process. Any changes to the WBS change the deliverables and, therefore, the scope of the project. This is an important point to help control scope creep.
In summary, the WBS provides a global, yet detailed, view of the project scope and becomes the basis for time, resource, cost, risk and quality planning, and for work allocation, control and progress reporting. The scope baseline needs to be controlled. There will most likely be changes to this baseline, but it is important to ensure that these changes do not build upon each other incrementally. This issue is referred to as “scope creep” and usually produces unacceptable risks because the combined effects of these incremental changes are seldom considered in total, hence the expression “death by a thousand cuts.” Having a clear and agreed definition of our project’s scope and managing that scope as the project proceeds is critical for its success. One of the hardest parts of planning any project is also one of the easiest ways to screw it up: clearly defining the scope of a project or, in other words, understanding what’s included in a project and what’s not. Proper scope definition is critical for a project’s success. Wow – did you really read all this?