on September 17, 2007, 6:01 PM PDT
Define project scope to include deliverables, boundaries, and requirements
There are two places that scope is defined on your project. High-level scope is defined in your project charter. Low-level scope is defined in your business requirements document. High-level scope consists of two main components. Deliverables. If you can’t remember anything else about scope, list your deliverables. Defining your deliverables goes a long way toward ... There are two places that scope is
defined on your project. High-level scope is defined in your project charter. Low-level scope is defined in your business requirements document. High-level scope consists of two main components. - Deliverables. If you can’t remember anything else about scope, list your deliverables. Defining your deliverables goes a long way toward defining the overall scope of the project.
- Boundaries. You should also try to define the boundaries of your project. Boundary statements help
to separate the things that are applicable to your project from those areas that are out of scope. Examples of boundary statements include:
- This project will affect USA operations only. All other locations are out of scope.
- We will deliver our solution to the Finance and Legal departments. All other departments are out of scope.
Think of project scope as a box. High-level scope defines the sides of the box and separates what is relevant to your project from
that which is irrelevant. Once the project starts, however, you generally do not have a lot of requests to change boundaries and deliverables. Most of the scope change requests you receive are changes to the business requirements. Business requirements help define the detailed scope. The project deliverables are used to define high-level scope. Business requirements describe the details of the deliverables. If scope is a box, then your requirements are what fill in the inside of the
box. There are two types of requirements. They are: - Product requirements (features). Product requirements describe the characteristics of the deliverables. If you were building a bridge, for instance, most of the requirements would be product based. These might include the number of cars the bridge would hold, the strength of the steel, the water level it needs to span, the color of the bridge, etc.
- Process requirements (functions).
Process requirements describe how people interact with a product and how a product interacts with other products. For example, when you discuss how data gets moved and how business transactions flow from one point to another, you are describing process requirements. If you need to describe the requirements for billing transactions, most of the requirements could end up being process oriented. This would include how billing transactions move from orders to invoicing to accounts receivable. They
can describe at what points people look up a status, how people manually update an invoice and what people should do if accounts are out of balance.
If you remember how these pieces fit together, you’ll have an easier time defining scope for your project in the future. High-level scope is defined in your charter and consists of boundary statements and deliverables. Low-level scope is defined by your business requirements. These two components together make up the entire scope
definition for your project. About this lessonLearn how to quickly identify project boundaries using the W questions. Quick referenceProject BoundariesThe Project Boundaries are the list of project goals, assumptions, and constraints that are agreed upon by the project team and stakeholders and form the basis for project planning. When to useThe project boundaries are
clarified by the project team as they transition from initiation to planning. These boundaries act as objectives and constraints in the development of the project plan. InstructionsProject Boundaries are most beneficial early in the project and whenever the project is undergoing change. An agreement between the project team and stakeholders on boundaries will reduce the likelihood of confusion on project goals and missed expectations at the end of the project. Setting
the project boundaries at the time of initiation allows the project team to plan the project with a clear understanding of project goals, assumptions, and constraints. This speeds and simplifies the planning process. In addition, whenever there is a request for a project change, the boundaries help the team evaluate whether that change is within scope or out of scope. Clear boundaries will reduce the likelihood of scope creep. There are a variety of ways to capture and
identify boundaries. Typically, some of them can be found in the Project Charter and, if it exists, a requirements document. A best practice for identifying boundaries to be used in planning is the ask the “W” questions: - What is the project supposed to accomplish?
- Why do we need to do this project?
- Who are the customers, stakeholders, and team members for this project?
- When does the project need to start and end?
- Where is the project activity to
take place?
- How should the project team approach the project? (procedures, examples, constraints)
The answer to some questions may be, “It doesn’t matter” or the answer may be very specific. If it doesn’t matter, that is an area of flexibility the team can use to optimize the project plan. If it is very specific, that becomes a constraint the must be addressed in the plan. Hints & tips- Ask each stakeholder all six questions. Look for
inconsistencies between stakeholders and resolve them.
- Answers of “It doesn’t matter” or, “I don’t care” are great answers. They give the project team flexibility on those boundary conditions.
- Vague answers like, “As soon as possible.” for the “When” question, or “Everybody.” for the “Who” question often lead to missed expectations on the part of the stakeholders. If that type of boundary is important to them, work to get a specific answer.
- I use these
questions whenever I am being asked to start a project – even if it is just a small action item. The questions only take a few seconds to ask, and the answers are very helpful for planning and executing the work.
Login to download - 00:04 Hi, this is Ray Sheen.
- 00:05 I'll talk with you now about setting the boundaries for the project so
- 00:09 that you can ensure the project plan will meet the project goals and objectives.
- 00:14
Setting boundaries is often a negotiation process between the project team and
- 00:18 the stakeholders.
- 00:19 Stakeholders have a vision for the project with goals and objectives.
- 00:23 The project team often is aware of constraints and limitations.
- 00:27 Together they can determine the direction of the project and
- 00:30 the boundaries that the team will stay within.
- 00:33 This will assist the team by allowing them to focus on what is inbounds for
- 00:37 the project and
not be distracted by what is out-of-bounds.
- 00:41 The boundaries normally describe the result of the project so
- 00:45 that the team knows what must be done.
- 00:47 The rationale for the project so that the team knows how to weigh options and
- 00:51 choose the best.
- 00:52 And finally any other boundary parameters that will impact the project planning and
- 00:58 the project execution such as time or money.
- 01:00 Some projects have a detailed requirements document prepared well in
advance of
- 01:05 project planning, but most do not.
- 01:07 When there is no document to refer to, we use the W questions.
- 01:11 The answers to these six questions will set our project boundaries.
- 01:15 The
first one is the what question.
- 01:18 It gives the project description.
- 01:20 From this we can derive the project deliverables.
- 01:23 The second is why.
- 01:25 This provides a context for the project
and
- 01:28 helps the team make trade offs in the project.
- 01:31 This is the key question to help us manage risks.
- 01:34 The next four W questions address assumptions and constraints.
- 01:38 Who will be
involved?
- 01:40 When is the expected start and finish time?
- 01:43 Where will the project activities be conducted?
- 01:45 And finally, how should the project be planned and executed?
- 01:49 Yeah, I know,
the W is at the end of how, but there's still a W so
- 01:53 we're going to count it.
- 01:55 Once we have the answer to the W questions,
- 01:57 we can put a fence around the project.
- 01:59 And then keep all
of our project activities inside the fence,
- 02:03 and keep the distractions and irrelevant items outside the fence.
- 02:07 Let's now consider each of these W's in just a little more detail.
- 02:13 For the what question, it's the result of the project, all of the deliverables
and
- 02:17 any other actions that the project team is supposed to complete.
- 02:21 It also includes the quality characteristics of the deliverables.
- 02:24 This is sometimes called the definition of done.
-
02:28 Let's talk about the why question next.
- 02:30 This answer helps the team to understand, what is the underlying driver for
- 02:35 the project?
- 02:36 Is it linked to strategic plans or other major initiatives?
- 02:39 Is it a compliance project with a rigid finish date?
- 02:43 What are the business benefits, growth or cost savings?
- 02:46 When the team understands the rationale, they're better able to make trade offs
- 02:51 between various options
while planning the project.
- 02:54 The who question is next, sometimes many of the who are obvious.
- 02:59 There may only be one or two customers, users or stakeholders for the project.
- 03:03 But sometimes there are many customers and users.
- 03:07 Or who the project team members are could influence the project plan and tracking.
- 03:12 And finally, approval authorities in a project create the need for
- 03:16 additional documentation or interactions.
- 03:19 The next W is when,
are there constraints on the expected start date and
- 03:23 expected finish date?
- 03:25 Are there any other external milestones that the project team must be aware of
- 03:29 because it will drive the project plans and execution?
- 03:32 For instance, if the project spans two fiscal years, is there a milestone at
- 03:37 year end that is tied to how much money they can spend in one year or the other?
- 03:42 The next W question is where.
- 03:44 This is becoming more
and
- 03:46 more of an issue in many businesses today as many companies are global in nature.
- 03:50 And using suppliers as part of their project team.
- 03:53 Activities on projects are now often spread across multiple locations, often in
- 03:58 multiple countries on multiple continents and speaking multiple languages.
- 04:02 The difference in managing a co-located team or a virtual team is significant.
- 04:07 This will drive the type of communication processes that must be used.
-
04:11 Finally, the use of remote contractors and
- 04:14 vendors will change the nature of some of the project management activities.
- 04:18 Our final W is the how, how is a category to capture any constraints or
- 04:23 assumptions that had been missed in the
other categories.
- 04:27 In addition, there may be constraints concerning methodology or
- 04:30 oversight that will be identified under this W.
- 04:33 Even the budget limitations show up at this time as we ask, how much?
-
04:37 Now what order you do the W's in does not matter.
- 04:40 The point is we need to do them all.
- 04:42 Understanding the project boundaries eases the project team's work during both
- 04:47 planning and execution.
- 04:49 It also points to what must be demonstrated as part of closing.
- 04:54 The W questions are the simplest and
- 04:56 most straightforward method to get a complete view of the project boundaries.
Lesson notes are only available for subscribers.
What is a boundary in a project?
The boundaries are defined as measurable and auditable characteristics and closely linked to project objectives. They create a holistic project perception, determine limits and exclusions of the project, and form the content of project scope in terms of expected results.”
What are the four 4 areas for typical project boundaries?
Project management processes within the project boundaries [25] The four project phases are conception (idea initiation), development (detailed project plan), realization and termination [16].
How are project boundaries identified?
To identify and state the boundaries for a project, it is required to clearly define items that are inside and outside of project work. All this is about defining the limits and exclusions for the project.
What is the difference between scope and boundary?
A project's boundaries define what is included in the scope of work. They set the lines or limits that mark what is included and what is excluded. Planners need to know a project's boundaries in order to produce a project scope statement.
|
