Retired course

This course has been retired and is no longer supported.

About this lesson

In-Frame/Out-of-Frame is a technique for clarifying project boundaries by listing the activities and deliverables that are in scope for the project as well as the activities that are not required as part of the project.

Exercise files

Download this lesson’s related exercise files.

In-Frame and Out-of-Frame.docx
60.5 KB In-Frame and Out-of-Frame - Solution.docx
59.8 KB

Quick reference

In-Frame/Out-of-Frame

In-Frame/Out-of-Frame is a technique for clarifying project boundaries by listing both the activities and deliverables that are in scope for the project and listing the activities that are not required as part of the project.

When to use

In-Frame/Out-of-Frame techniques should be used at the time of project initiation.  It is particularly helpful for those cases where the stakeholder’s requirements are unclear or uncertain.  When that is the case, the technique can help the stakeholders to clarify their expectations.   

Instructions

  1. Meet with the stakeholders to determine the project goals and deliverables.  List these “In-Frame.”
  2. Question the stakeholders about other possible activities that are related to the work of the project to determine if they are required.  If so, list them “In-Frame,” otherwise list them as “Out-of-Frame.”
  3. Review the activities that are “In-Frame” and question the stakeholders about the need to extend any of these beyond the normal level for projects of this type.  Clarify with them the boundary for completion and list activities for the item that is in frame.
  4. If agreement cannot be reached with respect to which list an activity should be placed on, place that activity “On-the-Frame” and include that activity in the Risk Register with a clear trigger point for when the decision will be made to move it either “In” or “Out.”
  5. If at some point an “Out-of-Frame” item is requested by a stakeholder, a project change must be processed which normally results in a change in the authorized schedule and budget.

Hints & tips

  • You do not need to use a “picture frame.”  That is just the metaphor that the technique relies upon.  The key is to develop the two lists.
  • The “Out-of-Frame” list is your best defense against scope creep.  A good discussion with this tool will ensure that everything that should be done on this project is included, and everything that is not necessary is identified and the stakeholders concur that it is not necessary.
  • Don’t go crazy on the “Out-of-Frame” list.  You don’t need to list “solve world hunger.”  Just list items that are logically related to the project, but not required this time.
  • Don’t portray the “Out-of-Frame” list as items that the stakeholders cannot have.  If they want them, put them “In-Frame.”  Rather the list represents those items that the stakeholders agree they don’t want to spend time and money on with this project.
Login to download
  • 00:05 Hi, I'm Rey Sheen.
  • 00:06 And I'd like to talk now about one of my favorite tools for
  • 00:10 project initiation, the In-Frame / Out-of-Frame tool.
  • 00:15 This tool helps us to clarify the project boundaries by listing both what is part of
  • 00:19 the project and what is not part of the project.
  • 00:22 This means it describes what is In Scope and what Is Not In Scope for
  • 00:26 the project using simple declarative statements.
  • 00:30 With this, we can meet with stakeholders and
  • 00:32 gain concurrence from them on what is to be done in the project, and
  • 00:35 equally important, what we should not be doing in this project.
  • 00:39 This will help to minimize the amount of time and money needed to do the project.
  • 00:43 This also helps us to eliminate Scope Creep, a list of the out-of-frame
  • 00:48 conditions provides a clear idea of where the project boundary is.
  • 00:52 Anything that is out-of-frame is out-of-scope for the project and
  • 00:56 will not be done.
  • 00:58 This helps the team not to waste time or money on unnecessary activities.
  • 01:03 And it also helps to keep stakeholders accountable for the project boundaries.
  • 01:07 They must provide the team with time and money if they change the requirements and
  • 01:12 move something from the Out-of-Frame list to the In-Frame list.
  • 01:17 When this tool is being used well,
  • 01:19 the nasty problem of Scope Creep is sharply curtailed.
  • 01:23 Another aspect of this technique allows us to identify risk and uncertainty.
  • 01:28 At the beginning of the project, the need for some activities will be uncertain.
  • 01:33 The stakeholders and
  • 01:34 project team cannot decide if they should be in-frame or out-of-frame.
  • 01:38 In fact, that's almost always the case with iterative and adaptive projects.
  • 01:43 In that case, I put the uncertain activity On-the-Frame.
  • 01:47 Those items that are On-the-Frame are uncertain at the time of the start of
  • 01:50 the project.
  • 01:52 We put them in the list for On-the-Frame, then we include them in our risk register.
  • 01:58 For those activities we also identify the phase in the project
  • 02:01 that will allow the project team and
  • 02:03 stakeholders to make a decision on whether these should be In-Frame or Out-of-Frame.
  • 02:09 Let's look at an example.
  • 02:10 Our project is to update the RWR17 product line.
  • 02:16 After meeting with the stakeholders, we have a list of project requirements.
  • 02:19 All we need to do is update the electronics
  • 02:22 in order to address some component obsolescence, and add some features.
  • 02:26 These include adding a Wi-Fi interface, and
  • 02:29 a touch screen to improve our whole user experience.
  • 02:32 Marketing wants the RWR17 to have an App-like feel,
  • 02:36 and we need to do some testing to make sure it's backward compatible.
  • 02:40 Finally, we have to create a marketing campaign for
  • 02:43 this new version of the product.
  • 02:45 At the same time that we determine all the things that we need to do in the project,
  • 02:49 we also clarified with our stakeholders the things that we do not need to do.
  • 02:53 We're not changing the size and
  • 02:55 shape of the RWR17, that means we wont have to do any tooling changes.
  • 03:00 We're not changing the packaging design.
  • 03:02 Again, minimizing the design effort, there's no change in accuracy of the unit,
  • 03:06 so we're not redesigning how the unit will perform.
  • 03:09 There are no new suppliers to qualify,
  • 03:11 so we'll be working with our existing supplier team.
  • 03:14 And finally, there's no facility modifications expected for
  • 03:17 the production line.
  • 03:19 There is one thing that is on the frame.
  • 03:22 We don't know the amount of product certification testing and
  • 03:24 analysis that will be required, and we won't know how much would be needed
  • 03:28 until we understand the magnitude of the changes.
  • 03:31 Once the design changes are finished,
  • 03:33 we'll be able to make a determination of what re-certification tests are required.
  • 03:38 One more time, we're not saying that we're unable to do the out-of-frame activities.
  • 03:44 Rather we're saying that after meeting with the stakeholders,
  • 03:47 they don't want have to do those activities unless needed.
  • 03:50 Therefore, we're not including them as part of the scope of the project yet, but
  • 03:54 they are at our risk register and
  • 03:55 something that we'll have to decide at the design review.
  • 04:01 In-frame, out-of-frame clarifies for both the team and
  • 04:04 the stakeholders the project scope boundaries

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course