How to TRANSITION your Project for Success After the Project

The purpose of this blog post is to cover TRANSITION, the fifth and final part of the Project Management MPM Model.  TRANSITION is the part in the model that covers how to set up your project deliverables for operational success after your project is complete.

TRANSITION sets up your project deliverables for operational success 

The Project Manager Sets up Their Creation for Long Term Success

Imagine you had to buy a vehicle and it was like a small project. And you followed the steps to INITIATE your project, to set it up for the greatest probability of success.

Then weekly and daily you followed the steps to LEAD your Project’s Purpose and People for the Best Outcomes, and you followed the steps to CONTROL your Project’s Outcomes and Money to Deliver the Best Results, and the steps to PLAN the Project’s Best Execution and Schedule.

You have completed your vehicle purchase.  It was a success, and it was enjoyable and rewarding.  You’re having a drink with some delicious appies and thinking, “this was one of the best things I have ever done, thanks to my great project management.”

Celebrate your project success

In fact, it was one of the best experiences for your stakeholders too.  

Your automotive expert advisor, for example, said they had helped others with their car purchases and the experience with your project to purchase your vehicle was the best they had ever had:  

• Communications were excellent and they always felt informed  
• The deliverables were well understood, the methodology made sense and the approach and schedule were reasonable
• The project was actually enjoyable, something they looked forward to being a part of during their day 

To review once again, this was all because you followed the steps to INITIATE your project, so you set it up for the greatest probability of success.

Then, weekly and daily you followed the small simple habits of success in the other blog posts to LEAD the Motive and People, CONTROL the Things and Money, and PLAN the Map and Timing.

INITIATE, then weekly LEAD, CONTROL, and PLAN

This was all done while investing the minimum amount of time per week in each of the areas of LEAD, CONTROL, and PLAN, because you followed the suggestions for the small habits in each of those blog posts.

Now the final step is to transition from a project state to an operational state, so your success continues for what you have created after your project is complete.

The next section is a quick one-page review of the MPM model to refresh the context of where we have been and then we’ll dive into the details of TRANSITION.

MPM Model Quick Review

In our project management MPM model, there are 5 parts: 

1. INITIATE, which involves creating an overview of your project before you get started,
2. LEAD, which looks at why you are doing the project and the people that are going to help and be affected by it,
3. CONTROL, which is where you shape and manage the outcomes of the project,
4. PLAN, which looks at how everything fits together and timing, and
5. TRANSITION, which covers how your project outcomes continue to work after the project is done.

The project management MPM model has 5 main parts

Each part of the model always involves all of the other parts as well, but each one of the five labels for that part tells us our intent at that point, indicates what aspect we are emphasizing, and the lens through which we are looking at our project.

This article then is about the TRANSITION part, which is moving any project activities that need to continue after the project is done to someone’s daily or weekly routine, so the project outcomes continue successfully in an operational state.  

TRANSITION is also about leaving behind, but in an organized way, the project activities and information which are no longer active after the project is done but may be needed for reference at some point in the future. 

Project Management TRANSITION is about Operations Readiness

What is in TRANSITION?

TRANSITION sets your on-going creation up for success, Dr. Frankenstein.  It moves each of the project outcomes and any of the activities to support them, out of the responsibilities of the project manager and project team and into the daily and weekly routines of someone else in the operational environment.  

It may be the same people supporting it operationally as who were supporting it in the project, but the situation has changed, because the allocation of their time, and the priority for use of their time, is now under an operational budget, not the project budget. 

TRANSITION moves the parts of your project which need to continue after the project is complete into an operational state and leaves behind the inactive project-specific activities which no longer need to be performed.   

There are activities on the project which are not finished when the project completes but are required to continue after the project is officially done, such as making sure software is kept current, that new changes by the software provider work in your environment, that on-going training and education is present and updated, and that processes integrated with other aspects of the organization are managed and kept current.

The danger in skipping the TRANSITION part of your project, is that the outcomes that the project team worked so hard to create and make work may not survive in the operational environment.  

There is tremendous inertia to existing work habits and routines even if they are manual and clumsy; because it is what the operational world knows and is comfortable with.  New ways of doing things and new tools, even though they are more effective and efficient, are hard to adopt because habits are hard to change, and they are personal.

Therefore, it is key that your project go through TRANSITION, no matter how trivial outcomes or activities may seem, so that the operational change introduced by the project is supported and continues long term, and change becomes lasting.

Transition items are covered in five sections: 1. Stakeholder and Objectives Review, 2. Lessons Learned, 3. Financial Review, 4. Resource Allocation, 5. Project vs Operational Information. 

Each section first explains the project item, then brings in the example of the personal vehicle purchase project to help illustrate the concept of the project

A vehicle purchase is a personal example of a project.

1. Stakeholder and Objectives Review

This is where you host a review meeting, with your stakeholders, regarding how the project went and how the objectives were met.

The meeting can be held in any number of formats: an informal conversation, an email, in person meeting, or conference call.

Remember we said in the INITIATE and CONTROL sections, to make sure your objectives are objectively measurable?  Well, this is where that is tested.

Design for success with measurable objectives

If you know that you are accountable, set yourself up for success earlier on in the project in the INITIATE part when creating your charter and set up your Objectives so they can be independently verified by anyone.

If the project met its objectives

If the project objectives were met the stakeholder meeting provides an opportunity to celebrate the project team’s achievements.  

It provides closure to the stakeholders, including the sponsor, project manager, and project team to acknowledge the project’s success and the extra efforts of the team to overcome particular project challenges and the value the project outcome brings to the organization.

If the project didn’t meet its objectives

If the objectives were not met, the project may be closed with items left uncomplete, or it may get more funding to continue to completion of outstanding objectives.

Maybe the stakeholders accept the challenges your project faced and accept that what your project created as “good enough” and consider the project complete.  It doesn’t have to be a win-lose situation.

The acknowledgement of what was accomplished, can be a formal document or just the minutes from a stakeholder meeting.  

The stakeholder review also provides an opportunity for the stakeholders to allocate additional funding if they feel value would be gained by finishing any uncompleted objectives.

The Stakeholder review is the first step in TRANSITION as the stakeholders may increase funding if there are some items remaining that they feel are of value to complete.  If that happens then the project is back into the weekly cycle, as before, with LEAD, PLAN, and CONTROL again.  It may also require an update to the charter from INITIATE. 

The outcome of the stakeholder meetings feed into the Lessons Learned.

Operational State for Stakeholder Review for Your Vehicle Purchase Project

In your vehicle purchase project example, here are some examples of outcomes from a stakeholder review:

• The vehicle expert, as a stakeholder, identifies that all of the objectives were met; the vehicle was purchased within the time required, the financing met the financial targets, and the vehicle met all of the mandatory requirements for the purchaser.
• The vehicle expert, as a stakeholder, identifies that most of the objectives were met; the vehicle was purchased within the time required, and it satisfied the mandatory requirements, however the monthly financial payments were $50 higher than set out in the objectives. In this case since you were the customer as well, your approval was coincidental, but in a business project, that approval may not be so simple.

Operational State for Stakeholder and Objectives Review

If the project objectives were not completed but the stakeholder review provided increased funding to complete any remaining unfinished deliverables, then the project enters back into an active state.  The appropriate project items are updated and the project once again enters the weekly LEAD, CONTROL, PLAN cycle and it is not in an operational state.

The stakeholder review can also be advice on how to continue in an operational state with what the project has accomplished and the operational dollars available and then the project continues through the TRANSITION project items.

2. Lessons Learned

The lessons learned usually starts with a meeting with the project team where lessons learned items are explored in detail.

The lessons learned exercise then expands to your sponsor, with a summary list that contains less detail and descriptions of recommendations written at a higher level.

Lastly it can be a presentation to executive or stakeholders.

The project manager confers with the sponsor to determine when to hold the meetings and who to include.

Lessons learned can be shared over several meetings with the project team, sponsor, and stakeholders.

Details about how to conduct lessons learned is covered in this blog post, along with a template and example, and in the workshops.

Lessons learned can be very political, so executive, as in sponsor support, is necessary for some of the wording and distribution.

Lessons learned are an opportunity to create valuable input to adjust and update the methodology for future reference.

Operational State for Lessons Learned for Your Vehicle Purchase Project

In your vehicle purchase project example, here are some examples of lessons learned:

• Lessons learned 1:
  • Project Deliverable or Activity: Test Drives  
  • Project Experience: More than three test drives in one evening were rushed and stressful
  • Assessment: Room to Improve
  • Lessons Learned Recommendation: Limit to two test drives, and reduce the number of overall test drives to meet the project schedule
• Lessons learned 2:
  • Project Deliverable or Activity: Monthly financial payment
  • Project Experience: Valuable to do the analysis upfront in terms of what is affordable to set realistic expectations for vehicle options 
  • Assessment: Keep doing  
  • Lessons Learned Recommendation:  Always critical to examine financial targets as constraints for options early on to save time doing test drives for vehicles that are outside the financing range.  

Operational State for Lessons Learned

Lessons learned helps the organization by providing input to improvement in general business processes, in the methodology used, and in how projects are conducted.

Remember I said earlier in the PLAN part that the methodology was fluid and a point in time.  Now is when the methodology can be updated with input from the lessons learned.

Lessons learned provides feedback to the manager to improve their skills in managing projects on the side, as projects are an on-going reality in any organization.

Lessons learned provides value to future managers managing projects in the organization by giving them knowledge about how to improve how things are conducted to increase their likelihood of success. 

3. Financial Review

A financial review examines how capital (CAPEX) and operational expenses (OPEX) were allocated during the project, and it ensures the correct depreciation procedures were followed for CAPEX. 

Also reviewed at this time are financial measures such as projections versus actuals and monthly spend versus deliverable progress.

The financial review is conducted with someone from the financial team and if required summarized results can be provided to the project sponsor.

As an engineer who was not a financial person and did not take an MBA, but depended on accounting courses for entrepreneurs, I found the financial review, in terms of how I reported or tracked numbers and presented them to the finance team, was very valuable input to continual learning about how best to track and report financials.  

The financial team review should provide any improvements or recommendations in regards to your financial methods or processes for the future. 

Conduct a financial review of your budget

Operational State for Financials for Your Vehicle Purchase Project

In your vehicle purchase project, the following financial details may be a part of your review:

• If you have a monthly payment with a lease or loan, are they scheduled to come out of the correct account or does that need to be changed from how it started with the down payment during the project?
• Is there an auto withdrawal set up?  If so, do you need to set up a monthly reminder to move the necessary amount from a main account into that bucket at a particular date during the month?  
• Maybe you need a reminder to ensure a certain threshold amount in a particular account on a particular day each month?
• Set aside financial amounts in the future in your budget for seasonal tire changes, if applicable.
• Set aside weekly, monthly or semi-annual amounts for items not covered in the warrantee, such as car washes, detailing, or oil changes (if not covered under maintenance).  

The above examples may be trivial personal considerations, but they illustrated the need to examine all project outcomes and activities in the operational state and ensure the appropriate funding is available.

Operational State for Financial Review 

The sponsor role may need to be involved in the financial review that deals with moving funds to the appropriate operational budget to manage project outcomes and support activities that exist in an operational state.

This also includes moving staff allocations or skill sets that are needed to support the project especially if that operational budget is owned by another manager in the organization.

There may be annual maintenance amounts due in subsequent fiscal periods which also need to be added to some manager’s operational budget.  For example, software often has an annual recurring maintenance payment, and one of the management teams needs to own that.

Other financial review considerations for the operational state are any related processes the project depends on that have costs associated with them for an interface created by the project.     

4. Resource Allocation

Resource allocation was identified in the Financial Review section, but here allocation refers not to additional expense for staff in the organization, but re-allocating staff whose majority of time was working on the project.

If their time was minor and via a cross-matrix relationship from another business are, as they were on “loan” from that area, then the re-allocation is simpler.

Resource allocation may be necessary after the success of the project

Project resource re-allocation after project completion often requires a conversation with that team member or their manager as they transition back to their functional area.

Non-people resources the project was using need to be allocated to someone else’s area to manage, once the project is complete.  For example, machines or equipment that were borrowed or on loan from another business area; or if new equipment or software was purchased, someone needs to own or maintain the operations of that.

As a manager in the project management role, you may have been wearing other hats such as a business analyst or vendor interface, or on-going user training for existing or new staff, and now all of those responsibilities need to be handed off to someone else. 

If you were wearing multiple hats, this is now where you face some challenges, handing off those jobs to someone to integrate into their daily and weekly habits.  

Oh yes, been there, done that, got the t-shirt.  As a manager doing project management on the side, I have worn too many hats and then it takes a lot of work to hand that off to others post-project to make sure someone takes that on, so the ball doesn’t get dropped for each responsibility.

Resource allocation can be very political – usually people have more to do than the time available, so they may resent having to take on yet more responsibilities, so this may be something that needs some discussion ahead of time, long before it is needed at the end of the project.

Resource allocation also includes understanding the difference between the four levels of support: incident management, problem management, change management, and asset management, but that is covered in a future blog post.

Operational State for Resource Allocation for Your Vehicle Purchase Project

In your vehicle purchase project example, here are some examples of allocation of resources:

• Road-side assistance agreements need to be updated with the vehicle make, model and year
• Assigned parking services, including parking tag listings need to be updated with the new vehicle information

Since the project was small re-allocation of resources who were committed on the project is not really an issue.  The resource allocation becomes a matter of aligning the new asset, or vehicle, with the various vehicle service arrangements.

Operational state for Resource Allocation

Operational support roles for the project are those that currently exist and need to continue after the project is complete, as well as new roles that may need to be added for the start of operational support.

Operational Support roles have tasks that need to be detailed and an expected average effort per week or year or whatever period is applicable has to be identified.  Some of that planning is covered in this blog post.

Operational support roles include all those required to support the solution for incident management (including Tier 1, 2, and 3), change management, problem management and asset management.  They need to be listed with the tasks required, time periods and hours required.  Those four are covered in this blog post.

Tiered support (1, 2, 3, 4) is explained in this blog post.

As a TRANSITIONAL responsibility the manager of the project works with management teams and support teams to ensure all identified operational support roles and resources are appropriately assigned to ensure successful support of the project solution in an operational state.

TRANSITION ensures all required operational support roles are assigned

5. Project vs Operational Information

This is where the manager sorts out the information that was only relevant to the project execution, from the information needed to support the solution operationally.

Leave behind information that was only relevant when the project was active, such as status reports, project communications, requirements review, project budget, etc.  

Create a repository to handle information that sustains the on-going support of what the project has created, such as vendor information, financial information, user or process guides, tip-sheets or documents (the uniqueness of the solution implementation for your organization), training, detailed background about the various pieces of the solutions, to name some of the areas of information.

Where does the information exist so people can find it when they need it such as in a shared space or learning site.  Is mobile access needed?

Operational State for Project vs Operational Information for Your Vehicle Purchase Project

In your vehicle purchase project, you might have the following project specific information that really isn’t relevant when you transition to an operational state:

• List of dealerships visited
• Schedule for test drives
• Funding options  

In your vehicle purchase project, you might have the following project specific information, that is needed in an operational state:

• Financial payment schedule
• Asset information for your accountant
• Warrantee information  
• Registration – and renewal periods or reminders
• Insurance – and renewal periods or reminders
• Vehicle user guide or tip-sheets for use

Operational State for Project vs Operational Information

Information necessary to support the solution long term needs to be moved into a location where anyone who needs it or has responsibility for something operational with the project can easily locate it.

Have ONLY ONE LOCATION for the master information for the support of your solution, not several as this causes confusion and can hamper effective support.  

Create a optimum folder structure that works best in operations by getting input on the structure from some of the team members who are in the support role.  Your perspective as a project manager may be a little too familiar to create an objective view for someone not as familiar with the solution as yourself.

Summary

When the project is done, usually that is just the beginning for the life of what you have created.  

TRANSITION involves ensuring that what the project creates continues in a way that ensures its long-term success, and that it becomes integrated successfully into the existing habits and routines within the organization and within the personal daily and weekly steps of people who have to ensure the vision of what it achieves continues.

TRANSITION activities ensure the on-going success of what you and the project team have worked so hard to create.

Action Steps / Apply This Knowledge

1. Go through each of the sections above for a project you completed recently and put one or two sentences regarding the status of each section.

2. If there are any sections that you feel need additional work to ensure the health of what you have created, document that and set up whatever communications or meetings you need to make sure the transition happens as it needs to.
3. Look at a current project you have and start a new document, title it with the name of the project and add “Transition” to the title.  Add each of the five transition areas as its own heading and then add one or more sentences under each about what you would like to have as your ideal transition state.  This is kind of like beginning with the end in mind and it can alert you to things you should be doing now so that the transition is smoother when your project is complete.

Learn More

In an upcoming workshop, for which you can subscribe to be notified when it’s available, we cover project management examples in detail.  

Also, in the workshop, we go into greater depth on many of the project management items in the Project Management MPM model.  As well you can ask questions about any of your current projects during the Q&A. 

TRANSITION – Main  

© Simple PM Strategies 2021