CompTIA Project+ PK0-003

Prepare Scope Statement

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

Prepare Scope Statement

00:00:01 - Back to our Project Plus road map,
00:00:04 - pre-project setup and initiating is complete, now we are moving
00:00:08 - into the most critical phase, critical phase because the highest
00:00:13 - percentage of your questions are going to come from project planning
00:00:16 - and I've already discussed project planning is also critical
00:00:20 - as an active project manager to project success because this
00:00:25 - sets the definition of the scope, of the time, of the cost, of
00:00:29 - the quality and so on; each one of our core know areas of Project
00:00:34 - Management are going to be defined in project planning. Let's
00:00:40 - see how project planning breaks down according to the Project
00:00:43 - Plus. Consistent with the fact that we just said project planning
00:00:47 - has the most questions from the exam project planning has the
00:00:51 - most break down of elements that we're going to discuss as part
00:00:55 - of project planning. In fact we're going to have 11 nuggets
00:01:01 - focused on
00:01:05 - project planning.
00:01:10 - Project planning has 13 discreet areas. I'm going to combine
00:01:14 - a couple of them together where they're relevant but literally
00:01:17 - we're going to spend an entire nugget on each one of with a couple
00:01:21 - of notable exceptions the key elements of project planning as
00:01:25 - defined by the Project Plus. In this nugget we're going to focus
00:01:29 - on 2.1 prepare project scope and as a matter of fact I have abbreviated
00:01:34 - the definition a little bit to take it directly from Project
00:01:37 - Plus. 2.1 is prepare a project scope document based on an approved
00:01:43 - project charter.
00:01:46 - Let's see what preparing the project scope statement is all about. Continuing
00:01:51 - on with the road map straight from Project Plus exam objectives,
00:01:56 - 2.1 prepare project scope or more appropriately 2.1 prepare a
00:02:00 - project scope statement based on the approved project charter
00:02:04 - consists of these core elements. We need to understand what the
00:02:09 - key performance indicators are, what are the measures
00:02:15 - for the business. In
00:02:20 - this nugget I'm going to address the key performance indicators
00:02:23 - at the same time I talk about this element of preparing the project
00:02:27 - scope which is the final project acceptance criteria because
00:02:31 - our project acceptance criteria is going to use those measures
00:02:36 - for business success, the key performance indicators, as part
00:02:39 - of our final acceptance criteria.
00:02:43 - The core focus of preparing the project scope is defining the
00:02:48 - scope boundaries what's in scope, what's not in scope, what do
00:02:53 - I do, what are the project requirements, and what are not the
00:02:57 - project requirements.
00:02:59 - Once we have the scope boundaries well defined we need to define
00:03:03 - the constraints and the assumptions around which the project
00:03:07 - is based. So these are conditions
00:03:12 - necessary for success.
00:03:22 - Part of defining what's in scope and not in scope is detailing
00:03:27 - the objectives of the business. The key method I have found for
00:03:32 - detailing the objectives is to define the deliverables.
00:03:38 - We already touched on the deliverables in the project charter
00:03:42 - and we defined the deliverables at the name only.
00:03:47 - In project scope definition we're going to define the deliverables
00:03:51 - a name and table of contents material that's going to be included
00:03:56 - in the deliverables.
00:04:00 - We're going to determine what the final project acceptance criteria
00:04:03 - is and finally we're going to validate the scope statement with
00:04:07 - our stakeholders and we're going to do that thing that Steve
00:04:10 - likes to harp on we're going to have formal
00:04:14 - acceptance. So now let's roll up our sleeves and see what this
00:04:22 - prepare project scope is all about.
00:04:26 - So our first step of preparing the project scope statement is
00:04:28 - really to get an understanding of what scope definition is all
00:04:31 - about or what scope is.
00:04:34 - We've already alluded to this already. It's the foundation for
00:04:37 - the project. Now I put the word detailed foundation for the project
00:04:41 - already because we already said the project charter
00:04:47 - was the foundation for the project so having said that now I'm
00:04:51 - going to have to say that my scope definition is the detailed
00:04:54 - foundation for the project. It's all a level of detail. I would
00:04:58 - suggest the project charter is defining our foundation for our
00:05:02 - project at the 30,000 foot level.
00:05:07 - So at a very high level the project charter defines all of the
00:05:13 - foundational requirements for our project.
00:05:16 - At the scope definition we're providing a detailed foundation
00:05:20 - for the project and I would suggest that's bringing us down to
00:05:23 - the 10,000 foot level.
00:05:26 - Why is it not down to ground level? Why is it not down to absolute
00:05:31 - details? Because that's what the work of the project is going
00:05:34 - to do. We're going to have an analysis phase,
00:05:38 - we're going to have a design phase,
00:05:42 - and in analysis we're going to probably take the foundation for
00:05:45 - our project down to the 3,000 foot level and by the time we're
00:05:49 - done design we're certainly down to the ground level. So it's
00:05:53 - definitely a series of layering or a series of successful successive
00:05:58 - refinement, well hopefully successful too, but of successive
00:06:01 - refinements. Project charters are a foundation at 30,000 feet,
00:06:05 - our scope definition as part of planning is going to take it
00:06:08 - down quite a bit farther to the detailed level but not as detailed
00:06:14 - as the actual project delivery activity itself. And what is our
00:06:17 - project scope definition going to define? It's going to define
00:06:21 - the boundaries
00:06:23 - what do we need to do
00:06:27 - and what don't we need to do.
00:06:35 - now we've talked already about how requirements definition is
00:06:39 - very hard for IT projects because we're dealing with intangibles.
00:06:44 - So often it's very hard to define what we need to do because
00:06:47 - this is IT, because it's intangible.
00:06:53 - So a big tool in our tool kit for defining a good effective project
00:07:00 - scope statement is we're also going to define what we don't need
00:07:03 - to do. We're not going to do training, we're not going to do
00:07:06 - data conversion, we're not going to do, we're not going to do
00:07:10 - so that again we're clearly defining the boundaries of our project. The
00:07:15 - what we need to do is considered in this next element the requirements
00:07:19 - to be included. What are the business
00:07:24 - requirements to be included? What needs
00:07:29 - to be fixed? Continuing on the metaphor that our business sponsor
00:07:34 - has a problem, a pain point, the business requirements are going
00:07:37 - to define what needs to be fixed,
00:07:40 - what are the business objectives
00:07:45 - for the project.
00:07:47 - And then finally
00:07:50 - the definition of success.
00:07:54 - Often new project managers will spend a fair bit of time doing
00:07:59 - the boundaries, doing the requirements, doing the objectives
00:08:03 - but they miss this key component of scope definition. What's
00:08:06 - the definition of success? How do we know
00:08:11 - when we're done
00:08:14 - and how do we know
00:08:17 - it will be accepted? I
00:08:26 - already talked about the scope boundary a little bit. I'm not
00:08:30 - sure this particular diagram helps a lot. But people often refer
00:08:35 - to the scope boundaries as the scope box and
00:08:40 - I actually find the definition of a scope box to be very apt
00:08:44 - metaphor for scope boundaries for scope definition. Everything
00:08:49 - inside this box
00:08:53 - is the project,
00:08:57 - is something I must deliver
00:09:02 - to the business.
00:09:06 - Everything outside this box is not in scope, is not in scope
00:09:11 - it doesn't matter how I write it it's still not in scope.
00:09:16 - Now how is that helping me? Well often it's hard to say what
00:09:22 - is the requirement for an IT project because of the intangibility
00:09:27 - so we do our very best and we'll explore several techniques in
00:09:31 - this nugget about how we're going to define good solid scope
00:09:35 - statement but if we say things like not in scope training,
00:09:41 - if we say things not in scope such as data conversion,
00:09:49 - if we say things not in scope such as solving
00:09:54 - world peace
00:09:58 - no, that's silly. When we're saying the things that are in the
00:10:02 - scope we're talking about things that could be considered by
00:10:08 - the average business person as being part of the project scope
00:10:12 - unless explicitly told not so if we're developing a new IT project
00:10:18 - we're going to do our very best to define everything that's in
00:10:20 - the scope and we're going to clearly state the items that are
00:10:23 - not in the scope. It's clearly not part of Steve's project to
00:10:28 - be responsible for training. It's clearly not part of Steve's
00:10:32 - project to be part of data conversion. It's clearly not part
00:10:35 - of Steve's project to be responsible for etc. etc. I deliberately
00:10:40 - put this one in here, solving world peace. Now unless this is
00:10:44 - a very special project it's not even feasible that solving world
00:10:49 - peace is going to be part of my project scope so we don't even
00:10:52 - talk about the stuff that isn't even remotely that the wildest
00:10:56 - dream of the most extreme business person would never consider
00:11:02 - that item to be in the scope. We don't want to get carried away
00:11:06 - with saying what's not in scope but anything that could be considered,
00:11:11 - that's on the fringe, that is not sitting at this point just
00:11:16 - outside the scope box and that could be implementing
00:11:23 - new hardware
00:11:27 - that's required for the project
00:11:30 - but it's not part of the scope for my project, somebody else
00:11:32 - is responsible for it, and we'll discuss items like that a little
00:11:36 - later in this nugget when we're talking about the constraints
00:11:39 - and assumptions. But again clearly not in scope is the implementation
00:11:44 - of new hardware because someone else is looking after that. Maybe
00:11:48 - a pre-condition for my project but it's not in my scope.
00:11:52 - We need to clearly
00:11:56 - unambiguously define what is in the scope box as clearly as possible
00:12:08 - using clear language, pictures,
00:12:13 - diagrams, data flow diagrams, entity models
00:12:21 - that's what I mean by pictures, not necessarily your home vacation
00:12:26 - pictures diagrams,
00:12:29 - brief narratives to clearly describe what's in the project unambiguously
00:12:33 - and I'm going to throw a little twist into
00:12:41 - a good scope definition is flexible as well. You don't want to
00:12:46 - constrain the scope to the point where you are going to be processing
00:12:50 - change management which is another element that we're going to
00:12:53 - discuss as part of this overall series on project planning. We
00:12:59 - don't want to constrain the project to the point that it becomes
00:13:02 - unmanageable. So we're going to clearly and unambiguously but
00:13:08 - yet be flexible. Now how can I put all of that together? I'm
00:13:12 - going to stray from an IT metaphor for just a couple of moments
00:13:16 - and talk about house building scope box. We're going to build
00:13:20 - a house and this house is going to be 2500 square feet, it's
00:13:24 - going to have three bedrooms, it's going to have two bathrooms
00:13:27 - etc. etc. and that is clearly defining
00:13:32 - the scope for the project. We're going to use pictures in terms
00:13:35 - of a blueprint,
00:13:39 - we're going to use diagrams to show where the electrical outlets
00:13:42 - and where the plumbing is to be installed in the house, we're
00:13:46 - going to make it unambiguous as possible but we're also going
00:13:49 - to make it flexible and by that we're going to say the bedrooms
00:13:56 - to be painted
00:13:59 - with primer
00:14:02 - and two coats
00:14:06 - of finished paint.
00:14:10 - That's pretty clear, that's pretty unambiguous, the bedroom is
00:14:13 - sure to be painted with a coat of primer and two coats of finished
00:14:17 - paint. Where I'm making it flexible I'm going to say color
00:14:24 - TBD. If in this part of project planning we have defined without
00:14:33 - flexibility in mind and we've said bedroom 1 is to be painted
00:14:38 - with primer, two coats of finished paint, color code 1369
00:14:45 - and bedroom number 2 is to be painted with one coat
00:14:49 - of primer, two coats of finished paint, color code 1412.
00:14:55 - To me that's not flexible you may absolutely know exactly what
00:15:01 - colors you want in those bedrooms before you've even walked into
00:15:05 - the room to get a sense or the feel of the ambience of the room
00:15:09 - but I would suggest that's often not the case. You may not want
00:15:13 - 1369 at the time that they're going to start painting, you want
00:15:17 - to make it 3113
00:15:19 - or whatever.
00:15:22 - By making it clear and unambiguous exactly what the criteria
00:15:26 - for measurement is going to be
00:15:29 - primer, two coats of finish, color to be determined
00:15:34 - I believe that is a good clear unambiguous scope statement while
00:15:39 - it still supports flexibility. Does it matter to the scope of
00:15:43 - the project? Does it matter to the cost of the project? Does
00:15:46 - it matter to the schedule of the project? Does it matter to the
00:15:49 - resourcing of the project what color paint they're going to use?
00:15:53 - And I'm going to suggest no. Now you may be getting into nuances
00:15:56 - that if you're going with a special gold flake paint that's going
00:16:00 - to require specialized skills, etc. etc. then yes, that could
00:16:04 - have an impact on the cost and on the resources but maybe again
00:16:08 - we're going to take it a little bit further primer, two coats
00:16:11 - of finish paint of standard household grade
00:16:15 - then that's clear and unambiguous.
00:16:18 - Work hard,
00:16:20 - work very hard to define a clear unambiguous but yet flexible
00:16:27 - scope statement. This is probably going to be the single hardest
00:16:31 - thing we need to do as project managers but it's also the single
00:16:37 - most important thing we're going to do as project managers because
00:16:40 - you'll see as we move through the nuggets in this project planning
00:16:44 - series that everything else is going to be driven off of the
00:16:49 - scope statement. We're going to develop the work breakdown structure,
00:16:53 - we're going to develop the schedule, we're going to develop the
00:16:55 - cost, we're going to develop the resourcing requirements based
00:16:58 - on the work
00:17:01 - required to satisfy that scope statement.
00:17:08 - Creating a good scope definition is the single most important
00:17:13 - and hardest thing that we need to do as project managers in project
00:17:18 - planning. So let's see what a good scope statement should look
00:17:22 - like. So a clean unambiguous and flexible scope statement should
00:17:28 - contain these following components. It's going to identify the
00:17:31 - business objectives.
00:17:34 - And I keep stressing business because it needs to be written
00:17:37 - in business terms. At
00:17:43 - this point the scope statement oops, terms does not have an H
00:17:48 - in it, T-E-R-M-S
00:17:51 - at this point the scope statement is being created for the business
00:17:54 - to review and validate that if I deliver a project that satisfies
00:18:00 - these objectives, these requirements I'm going to satisfy their
00:18:04 - pain. So make sure that you're not creating a technical document
00:18:08 - when you're writing the scope statement. We need to focus on
00:18:11 - business terminology.
00:18:15 - I believe a key component to the scope statement is the deliverables.
00:18:19 - As I mentioned already in the project charter we identified the
00:18:22 - deliverables, we have an analysis document
00:18:26 - and we have a design document,
00:18:29 - and we have other documents produced by the project. In a scope
00:18:33 - definition we're going to take that analysis document
00:18:38 - and we're going to identify the table of contents, 1.0 executive
00:18:43 - summary, 2.0
00:18:47 - current situation,
00:18:54 - 3.0 evaluation
00:18:59 - of alternatives,
00:19:02 - etc. etc. etc. When
00:19:05 - we start to lay out the deliverables and we're now telling the
00:19:09 - business that in our analysis document we're going to deliver
00:19:12 - an executive summary well that's pretty standard all documents
00:19:15 - should have an executive summary. But we're telling the business
00:19:18 - we're going to evaluate the current situation.
00:19:22 - So this is going to give them the confidence that the IT team
00:19:26 - is going to go into and talk to the existing users, they're going
00:19:31 - to review the existing documentation, they're going to understand
00:19:34 - what works and what doesn't work in the current situation. We're
00:19:38 - going to tell them that we're going to evaluate alternatives.
00:19:41 - So again this should give the business the confidence of knowing
00:19:45 - what works and doesn't work in the current situation
00:19:48 - is going to allow us to evaluate alternatives. Do we simply add
00:19:53 - more patches and fixes to the current system? Do we look at doing
00:19:57 - a new custom solution? Do we look at doing a package implementation?
00:20:02 - What are the various alternatives that we're going to explore?
00:20:05 - And so on and so on. By defining the deliverables at the TOC
00:20:09 - level, table of contents level, we're beginning to again further
00:20:14 - manage the expectations of the business and by reviewing our
00:20:18 - table of contents it's going to allow them to confirm that this
00:20:22 - deliverable should be addressing their expectations.
00:20:27 - Now I would suggest that simply laying out the table of contents
00:20:33 - isn't necessarily truly going to help alleviate their fears of
00:20:38 - help validate that we're delivering exactly what we want. I would
00:20:42 - suggest we should produce an annotated
00:20:47 - table of contents. What does an annotated table of contents provide?
00:20:51 - It's going to give us a paragraph
00:20:56 - of text describing what's in the executive summary, another paragraph
00:21:00 - of text describing what's in the current situation. In the current
00:21:04 - situation review the project team will review and document
00:21:10 - interviews from the manager's
00:21:13 - assessment of the current documentation and a review of the existing
00:21:19 - IT problem backlog for the system. So now the business is really
00:21:25 - getting understanding of exactly what's going on in this particular
00:21:29 - chapter. It's eliminating the assumptions of what Steve thinks
00:21:34 - he's going to do as part of the current situation assessment
00:21:37 - and what the business is assuming Steve is going to do and so
00:21:41 - on, another paragraph of text along the way. In the evaluation
00:21:45 - of alternatives we will evaluate three alternatives period, or
00:21:50 - we will evaluate upgrade, etc. etc. but again we're managing
00:21:54 - the expectations.
00:21:56 - An annotated table of contents is going to go a long way to better
00:22:01 - defining the deliverables that the project is going to be produced.
00:22:06 - If you have the time and the knowledge I would suggest listed
00:22:11 - deliverables need to be taken one step further and we need to
00:22:14 - say an estimated number of pages.
00:22:20 - Executive summary is going to have 1, 2, 3 pages, current situation
00:22:26 - is going to have 5 to 10 pages, evaluation of alternatives is
00:22:30 - going to have 15 to 20 pages. Again
00:22:35 - this is going to allow the business to read the annotated table
00:22:39 - of contents, I think they should be doing, but he's only going
00:22:44 - to produce 5 pages of results.
00:22:47 - I really think there's a lot of value in reviewing my current
00:22:51 - situation, there's a lot more detail in there that Steve's team
00:22:55 - should be learning, there's no way he's going to put that in
00:22:58 - 5 or worst case 10 pages. I think I need to talk to Steve and
00:23:02 - say there's more value in the current situation assessment than
00:23:05 - you're potentially understanding, let's up the expectations,
00:23:11 - let's make that 20 to 30
00:23:15 - and therefore you will address all of my requirements with that
00:23:18 - current situation review. As soon as we get the confirmation
00:23:22 - that the business thinks there's a lot of work to be done in
00:23:26 - there then that is our clue as we move into the next nuggets
00:23:31 - in the series that there is a lot of work to be done and we probably
00:23:36 - need pick a number 20 days of work to do the current situation
00:23:42 - assessment where originally I thought I was going to get that
00:23:44 - done in 5. So this is allowing us to get the definition that
00:23:49 - we need to be more successful with completing a realistic project
00:23:54 - planning identifying all of the work that's required, confirming
00:23:58 - all of the work that's required, and developing a realistic schedule. We've
00:24:04 - already talked about the boundaries. What is the scope box?
00:24:10 - What's in scope, what's not in scope?
00:24:14 - We're probably going to start to create some text.
00:24:19 - This system
00:24:23 - will address
00:24:25 - the following business requirements
00:24:32 - and list them off in bullets. And then maybe you need to have
00:24:36 - a paragraph on each one of the bullets but we're going to define
00:24:40 - exactly what it is that the project is going to undertake. And
00:24:44 - this is where we start to use our pictures
00:24:49 - a DFD, a data flow diagram, a context diagram,
00:24:55 - a high level entity model.
00:25:01 - Dig into our project tool kit, our IT took kit, and find effective
00:25:08 - ways to define the boundaries, to define that scope box. When
00:25:13 - I say you're going to use text, I think it's unavoidable that
00:25:15 - we're going to have to put some text into our scope statement
00:25:19 - but I believe text is often very clear if we do it in bulleted
00:25:24 - lists as opposed to the larger flowing paragraphs of beautifully
00:25:29 - composed prose that have several and's and an or and a not in
00:25:34 - the same sentence because that's not clear. Start to use pictures,
00:25:38 - start to use diagrams but develop that clear unambiguous definition
00:25:43 - of what it is that we're going to do to satisfy the business
00:25:48 - objectives. Keep it in business terms as much as possible,
00:25:53 - recognize and I just said we're going to use some IT speak over
00:25:55 - here we're going to use data flow diagrams, we're going to do
00:25:58 - context diagrams, we may throw an entity model in there but these
00:26:02 - are going to be at a high level,
00:26:06 - they're certainly not going to be at a point that we're going
00:26:07 - to do data normalization and database creation. We still have
00:26:10 - to do the analysis and design but a level 1 or level 2 DFD and
00:26:16 - a level 1 or a level 2 entity model with very careful attention
00:26:20 - paid to the text, to the words that you're going to use in these
00:26:24 - models can still be, I believe, easily understood by the business. We're
00:26:32 - going to define the acceptance criteria in advance and we're
00:26:36 - going to talk a little bit more about acceptance criteria just
00:26:39 - a little later in this nugget so I'm not going to spend a lot
00:26:41 - of time on that beyond stressing that we need to define the acceptance
00:26:47 - criteria in advance.
00:26:49 - How are you going to measure that I've been successful? What
00:26:53 - is the yardstick, what is the measuring tool that you're going
00:26:56 - to use by knowing the acceptance criteria in advance? Again,
00:27:01 - we can define the work packages required to make sure that we
00:27:05 - satisfy the acceptance criteria. We're
00:27:08 - going to identify the priorities. What mandatory?
00:27:14 - What's desired?
00:27:18 - What's optional?
00:27:22 - When we get into project delivery there may be times when we're
00:27:27 - running out of time, we're running out of money, we need to find
00:27:30 - some way to keep the project on track
00:27:34 - and as much as we hate to say it sometimes some of those optional
00:27:38 - requirements may have to be dropped of to allow us to continue
00:27:42 - to deliver the project on time, on budget. And again knowing
00:27:45 - those priorities in advance is going to give us the ammunition
00:27:49 - we need later on to make the hard decisions to keep our project
00:27:55 - on track to be a success. We're
00:27:58 - going to talk about the assumptions and constraints. These are
00:28:01 - the pre-conditions required and I've got a specific discussion
00:28:04 - on assumptions and constraints again a little later in the nugget
00:28:07 - series; I'm not going to spend a lot of time on that and we're
00:28:10 - going to talk about the ownership. Ownership
00:28:12 - to me is significantly related to acceptance criteria, who is
00:28:17 - going to accept that we satisfied the requirements, but ownership
00:28:21 - is also going to tell us who knows
00:28:26 - what's needed.
00:28:31 - We made sure that we have an appropriately identified acceptor
00:28:34 - who has the authority and the knowledge to accept the project
00:28:41 - on our behalf but chances are our acceptor doesn't know 100%
00:28:45 - of everything that's going to be delivered in the project so
00:28:47 - we need to know what's needed in the various sub-requirements
00:28:55 - so we can absolutely accurately understand and document the requirements. We've
00:29:03 - already talked about the importance of documenting the assumptions
00:29:06 - and constraints as part of our scope definition. I just want
00:29:09 - to share with you my definition of what an assumption is and
00:29:12 - what a constraint is. An assumption is a statement that we believe
00:29:17 - to be true. And the key with creating assumptions for project
00:29:21 - planning, as part of the project scope, is we honestly have to
00:29:25 - believe that it is a high probability of being true but it's
00:29:30 - something that we need to validate with the business,
00:29:34 - it's something we need to validate with management, but it's
00:29:37 - something that we believe can be validated,
00:29:41 - we believe it is true, and again I want to stress we have to
00:29:44 - believe it's true. We don't want to create assumptions on knowingly
00:29:49 - false statements,
00:29:51 - creating an unrealistic situation that will lead to project delivery
00:29:55 - challenges, we just know this ain't going to happen,
00:29:58 - we don't put that in assumptions, we only put in assumptions
00:30:02 - that we believe to be true, it needs to be validated, but even
00:30:06 - with validation there is a possibility during project delivery
00:30:09 - that it could be false which is going to cause
00:30:14 - issues and documenting the assumptions really is a bit of cover
00:30:19 - your own back side. I created this project plan, this project
00:30:23 - scope statement based on these assumptions boss, management you
00:30:28 - validated that these are realistic assumptions but guess what?
00:30:32 - Three months into the project it proved to be false, it's causing
00:30:36 - issues, but you can't blame me. This is the cover of the back
00:30:39 - side part we all agreed this were the conditions we were going
00:30:43 - to go in on so let's just roll up our sleeves
00:30:49 - and fix it, do whatever is going to be required, but no one's
00:30:53 - going to point the finger at Steve saying "Why did this happen?"
00:30:57 - That's what an assumption is. A constraint is a pre-condition.
00:31:03 - It's parallel work. Remember the hardware install?
00:31:10 - Some other projects somewhere is working on installing the hardware
00:31:14 - necessary for my project. It's a pre-condition, it's parallel
00:31:18 - work, it's something else that's happening somewhere outside
00:31:21 - in the organization or in the world environment that I need to
00:31:25 - have finished, it's a condition for my success but it's outside
00:31:30 - of my dome of responsibility.
00:31:34 - They're mandatory conditions that again if they prove to be false
00:31:38 - or probably more appropriately put don't happen
00:31:46 - or late
00:31:48 - they are going to again cause issues and this is a bit of cover
00:31:52 - your own back side if the constraints don't happen, come in late,
00:31:57 - causing project issues again you're going to roll up your sleeves
00:32:01 - and you're going to fix the problems but literally no one's going
00:32:04 - to be pointing their fingers at Steve and saying "Why didn't
00:32:07 - you think about this?" The fact is I did think about it, these
00:32:10 - are my assumptions, believe it to be true; these are the constraints,
00:32:14 - other work that was necessary but outside of my responsibilities
00:32:18 - to be a success. And
00:32:21 - the last element I want to spend just a moment or two with you
00:32:24 - in this nugget is defining the acceptance criteria in planning,
00:32:31 - in scope definition.
00:32:38 - A few criteria for acceptance criteria is it needs to be clear,
00:32:42 - it needs to be absolutely yes or no that's not a very good tick
00:32:47 - box there should be no ambiguity. Did we satisfy the acceptance
00:32:53 - criteria? Is there a measurement,
00:32:56 - is it pre-defined,
00:32:58 - and is it obtainable?
00:33:00 - Now in planning
00:33:06 - and I want to stress that defining the acceptance criteria now
00:33:09 - in planning
00:33:11 - part of the Project Plus exam itself, something you need to be
00:33:14 - aware of to pass the questions correctly or to answer the questions
00:33:18 - correctly, but it is absolutely a mandatory part of being successful
00:33:22 - with delivery. Plan
00:33:26 - for closure
00:33:30 - if you know what the acceptance criteria in advance is every
00:33:34 - activity in your project is working towards the minimum work
00:33:38 - required to achieve that clear, pre-defined, obtainable acceptance.
00:33:47 - You know in advance what rule or what measurement, what meter
00:33:53 - the customer is going to use to assess acceptability, you build
00:33:57 - towards that. This
00:34:00 - concludes our nugget on 2.1 Prepare Project Scope Definition.
00:34:04 - In this nugget we spent a lot of time talking about scope definition,
00:34:09 - defining the scope boundaries the clear,
00:34:13 - unambiguous but flexible definition
00:34:22 - of what's in scope
00:34:26 - and what's not in scope.
00:34:29 - We talked about how deliverables
00:34:34 - with the table of contents and even an annotated table of contents
00:34:38 - and estimated number of pages is going to help clearly define
00:34:43 - our scope boundaries. We talked about using text
00:34:46 - and we talked about using diagrams
00:34:50 - data flow diagrams, entity models. Find the right tool that's
00:34:55 - going to allow you to clearly define the scope boundaries. And
00:35:00 - to repeat what I said in the nugget this is a lot of work but
00:35:04 - this is critical to successful project delivery.
00:35:07 - Around those scope boundaries we've identified the constraints
00:35:10 - and the assumptions, the pre-conditions that are required to
00:35:14 - satisfy delivery to those scope boundaries. The scope boundaries
00:35:20 - are based on the objectives and I'll put the word business objectives
00:35:24 - in there
00:35:26 - that the business is going to use. Using those business objectives
00:35:30 - we're going to identify the key performance indicators and the
00:35:33 - key performance indicators are going to feed into the final acceptance
00:35:37 - criteria that we're going to define in planning that's going
00:35:43 - to be our measure
00:35:46 - for closure.
00:35:51 - And finally although not specifically discussed in the nugget
00:35:55 - our last step of 2.1 preparing the project scope is take everything
00:36:00 - that we've done
00:36:03 - back to the business and validate the scope statement with the
00:36:06 - stakeholders. Now in planning before we move into the next
00:36:12 - parts of planning which is developing the work breakdown structure,
00:36:16 - developing the schedule if we don't get the scope statement validated
00:36:20 - we're going to build invalid work breakdown structures and so
00:36:23 - on for the rest of project planning, get that scope statement
00:36:27 - validated as the first part of project planning, and then use
00:36:30 - that as the detailed foundation for the rest of project planning.. This
00:36:36 - concludes our nugget on preparing the scope definition. I hope
00:36:40 - this module has been informative for you and thank you very much
00:36:43 - for viewing.

Create WBS and WBS Dictionary

Define Change Management Process

Develop Project Schedule and Resources and Roles

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.


Pick up where you left off watching a video.


Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development

Stay Connected

Get the latest updates on the subjects you choose.

  © 2015 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS