Locked lesson.

Upgrade

About this lesson

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.

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:04 Hi, I'm Ray Sheen and I'd like to talk now about one of my favorite tools for
  • 00:09 project initiation, the in-frame/out-of-frame tool.
  • 00:12 >> This tool helps us to clarify the project boundaries by listing both what
  • 00:17 is part of the project and what is not part of the project.
  • 00:20 This means it describes what is in scope and what is not in scope for
  • 00:24 the project using simple declarative statements.
  • 00:27 With this we can meet with stakeholders and
  • 00:29 gain concurrence from them on what is to be done in the project and,
  • 00:33 equally important, what we should not be doing in the project.
  • 00:37 This will help to minimize the amount of time and money needed to do the project.
  • 00:42 This also helps to eliminate scope creep.
  • 00:46 A list of the out-of-frame conditions provides a very clear idea of the project
  • 00:51 boundary.
  • 00:51 Anything that is out-of-frame is out of scope for the project and
  • 00:56 will not be done.
  • 00:57 This helps the team not to waste time or money on unnecessary activities.
  • 01:02 And it also helps to keep the stakeholders accountable for the project boundaries.
  • 01:07 They must provide the team time and money if they change the requirements and move
  • 01:13 something from the previously agreed to out-of-frame list onto the in-frame list.
  • 01:19 When this tool is being used well the nasty problem of scope creep is
  • 01:23 usually curtailed.
  • 01:25 Another aspect of this technique allows us to identify risk and uncertainty.
  • 01:30 At the beginning of the project the need for some activities may be uncertain.
  • 01:35 The stakeholders and project team cannot decide if it should be in-frame or
  • 01:39 out-of-frame.
  • 01:40 In fact, that is almost always the case with iterative and adaptive projects.
  • 01:45 In that case, I put the uncertain activity on-the-frame.
  • 01:48 These items that are on-the-frame are uncertain at the time of the start of
  • 01:53 the project.
  • 01:54 We list them on-the-frame and we include them in our risk register.
  • 01:58 For those activities we also identify the phase or
  • 02:01 milestone in the project that will allow the project team and stakeholders to make
  • 02:06 an informed decision whether they should be in-frame or out-of-frame.
  • 02:10 Let's look at an example.
  • 02:13 Our project is to update the RWR17 product line.
  • 02:17 After meeting with the stakeholders we have a list of project requirements.
  • 02:21 All we need to do is to update the electronics in order to address some
  • 02:24 component obsolescence and add some features.
  • 02:27 These include adding a WiFi interface and
  • 02:30 a touch screen to improve our user experience.
  • 02:33 Marketing wants the RWR17 to have an app-like feel and
  • 02:37 we need to do something to make sure it's backwards compatible.
  • 02:41 Finally, we have to create a marketing campaign for this new version.
  • 02:45 At the same time that we determined all these things we need to do on the project
  • 02:50 we also clarify with our stakeholders the things that we don't need to do on this
  • 02:55 project.
  • 02:56 We're not changing the size and shape of the RWR17.
  • 02:58 Of course, that means that we don't need to do any tooling changes.
  • 03:02 We're not changing the packaging design.
  • 03:05 So, again, that minimizes the design effort.
  • 03:08 There is no change in the accuracy of the unit, so
  • 03:11 we're not redesigning how the unit will be performing.
  • 03:14 There are also are no new suppliers to qualify, so
  • 03:17 we'll work with our existing supplier base.
  • 03:20 Finally, there's no facility modifications expected for this product line.
  • 03:24 There is one item that is on-the-frame.
  • 03:27 We don't know the amount of product certification that will be required and
  • 03:31 we won't know how much is needed until we understand the magnitude of
  • 03:36 the design changes.
  • 03:37 Once the design changes are finished,
  • 03:39 we'll be able to make a determination of what recertification tests are required.
  • 03:44 One more time,
  • 03:45 we're not saying that we are unable to do the out-of-frame activities.
  • 03:50 Rather we're saying that after meeting with the stakeholders they
  • 03:55 don't want us to do those activities on this project.
  • 03:59 Therefore, we're not going to include them as part of the scope.
  • 04:03 >> In-frame/out-of frame clarifies for both the team and
  • 04:07 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