Locked lesson.

Upgrade

About this lesson

To fully realize the benefit of a project, often business systems need to change to implement the project results. This transition can be a challenging aspect of the project.

Exercise files

Download this lesson’s related exercise files.

Transition to Business.docx
65.5 KB Transition to Business - Solution.docx
63.8 KB

Quick reference

Transition to Business

To fully realize the benefit of a project, often business systems and processes need to change to implement the project results.  This transition can be a challenging aspect of the project.

When to use

Whenever the project result will disrupt or change established patterns of behavior – even if no one likes the established patterns – expect resistance to the change.  A transition process is needed to remove the old way of doing business and incorporate the project results.

Instructions

There are several approaches that can be used to transition the result of the project into the normal operations of the organization.

Transition the project team

This approach is often used for a totally new capability or business process.  The transition process is to transfer the project team (or at least a portion of it) to the operational component of the organization.  The project team member transition out of a project mode and into an operational mode.  They are essentially handing off the project results to themselves.  The biggest challenge in this type of transition is to establish the new operation with operation controls.  The danger is that the team will continue to innovate and a stable process is never established.

Transition the project results

This approach is commonly used for product development, process improvement, and facilities projects.  The results of the project are incorporated into the normal business operations and managed by the current business operations management team.  This approach often requires an entire phase of a project to train the users in the operational management of the project results, fully test/demonstrate the results of the project in the operational environment, and overcome any resistance to change.  In many cases, the emotional aspect of change is more difficult to overcome than the technical aspect of the change.

Change can either be implemented all at once – known as the “big bang” approach; or in small increments - known as the phase-in approach.  A big bang requires careful coordination to ensure all aspects of the change go live simultaneously.  This approach can lead to rejection of the entire project result if any aspect does not work well.  The other approach is to “phase it in.”  This will incrementally introduce aspects of the project result.  It takes much longer but usually gets better buy-in because you are able to build momentum and confine issue resolution to only a few minor points.  However, this can be a very difficult transition since it is likely you will be operating with part of the old process and part of the new process simultaneously.  With either approach, it is wise to conduct a pilot run or beta test of the project results before committing the business to the new approach.

Login to download
  • 00:04 Hi, I'm Ray Sheen.
  • 00:05 I'd like to talk with you now about an important aspect of project closeout,
  • 00:09 the transition to business operations.
  • 00:12 A project often creates a new product, process, or facility.
  • 00:15 But for the goals and objectives of the project to be realized, that new product,
  • 00:20 process, or facility must be put into operation.
  • 00:23 This project will end.
  • 00:24 Now, you may be surprised, you may not be used to that idea, but
  • 00:28 projects really do end.
  • 00:29 The business must now manage the day-to-day operations of the project
  • 00:33 result.
  • 00:34 The project team has been disbanded, and it's not there for them to rely upon.
  • 00:38 There are two ways to conduct this handoff of the project results to
  • 00:42 the business management team.
  • 00:44 The easiest one is to transition the project team into the operational
  • 00:48 organization.
  • 00:49 In this case, all or
  • 00:50 at least some of the project team transfer to the operational department.
  • 00:54 They're essentially, transferring the project result to themselves.
  • 00:58 The hardest part of this approach is for the project team,
  • 01:01 now the operating managers, to not continue playing and
  • 01:04 actually use the results that they've developed.
  • 01:08 The second approach is to turn the entire handoff process into another phase of
  • 01:11 the project.
  • 01:13 Many project management methodologies are structured in this way,
  • 01:16 and that is their normal approach.
  • 01:19 The transition phase then, is just like any other project phase.
  • 01:23 It must be project-managed.
  • 01:24 In fact, this may be the longest and highest risk phase in the project.
  • 01:30 Let's talk about this second approach, that of a transition phase to the project.
  • 01:35 We treat each phase of a project as a mini-project with its own project
  • 01:38 management triangle of scope, schedule, and resources.
  • 01:42 So in this case, the scope is the activities needed to handoff
  • 01:45 the responsibility for managing the new product, process, or facility.
  • 01:49 The schedules, the timing of those activities, and the resources or
  • 01:53 the project team and any costs needed to conduct things like training or
  • 01:56 pilot runs and beta tests.
  • 01:59 There are two different approaches that you can take when planning this phase.
  • 02:03 One approach is called the big bang approach.
  • 02:06 In this approach, everything created in the project is introduced simultaneously.
  • 02:10 Everything from the old way is out and everything from the new way is in,
  • 02:14 all at once.
  • 02:16 The advantage of this approach is that it is very fast.
  • 02:19 Also, there's less confusion for users in terms of the transition process.
  • 02:24 And the training is easy since everyone can be trained at once, and
  • 02:27 then immediately begin to use the new product, process, or facility.
  • 02:32 The difficulty with this approach is that it's much more susceptible to a disaster.
  • 02:36 One little thing can cause the entire introduction to fail,
  • 02:39 leading to confusion, frustration, anger, and
  • 02:42 possibly even a rejection of all the project results.
  • 02:46 The other approach is to phase in the transition.
  • 02:49 In this case, we introduce elements of the new product,
  • 02:52 process, or facility one piece at a time.
  • 02:56 Growing the capability in this way allows us to find and fix problems along the way.
  • 03:01 As users become comfortable with the person they have,
  • 03:04 the organization builds momentum and hunger for the complete implementation.
  • 03:08 The difficulty with this approach is that it can take a long time before
  • 03:12 the transition is complete.
  • 03:13 Another very significant management challenge is that during a portion of this
  • 03:17 transition time, we have a hybrid state of affairs.
  • 03:21 We're operating a portion of the old process or system and
  • 03:24 a portion of the new process or system.
  • 03:27 And this can lead to a tremendous amount of confusion and
  • 03:30 high costs to maintain both systems.
  • 03:33 There are pros and cons for each approach.
  • 03:36 I've used them both.
  • 03:37 Coordinate with your stakeholders to chose which one is best for your project.
  • 03:42 Regardless of the approach you use, you'll need to conduct a pilot run or beta test.
  • 03:47 When the new product, process, or facility is first created, it may be fragile and
  • 03:51 susceptible to failure.
  • 03:53 Through the pilot run or beta test process, you can demonstrate that
  • 03:56 the project results are ready for operational deployment.
  • 04:00 A pilot run, which is a preliminary operation of a new process, or beta test,
  • 04:05 which is a preliminary operation of a new system, are used to demonstrate that
  • 04:10 everything will work as expected in lifelike everyday conditions.
  • 04:14 Pilot runs and beta tests use operational resources, not the project team.
  • 04:20 They use the actual procedures, equipment, and
  • 04:23 systems that the operational managers will be using.
  • 04:26 This is meant to be as close to real operations as possible.
  • 04:29 In fact,
  • 04:30 pilot run products are often sold as prime units on new product development projects.
  • 04:35 However, a pilot run or beta test does not need to be perfect.
  • 04:39 But whatever problems they encounter, they should have the procedures and
  • 04:43 tools to manage through them just like they would in day-to-day operations.
  • 04:47 If you have to use the words, now let's pretend at any point in a pilot run,
  • 04:52 you're not really doing a pilot run.
  • 04:55 >> Projects can never realize their promised benefits unless
  • 04:58 the project results are incorporated into the business operations.
  • 05:02 Just because you created it, doesn't mean you're done.
  • 05:05 You have to get it transitioned into the fabric of the business.

Lesson notes are only available for subscribers.

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

Gift this course