Change is omnipresent. With the accelerating pace and complexity of change in the business world, there is an increasing need to manage business transformations in a structured manner to ensure the objectives are met, and desired value is realized. However, while projects do provide the required structure, they may still fall short of delivering the expected value due to one or more of the following reasons:

  • The focus of projects tends to be on completing their deliverables with acceptable quality, on time, within budget. Not necessarily on how the project’s customer will realize the value (e.g., business line) through those deliverables post project closure, e.g., a project to develop a new business application may fail to help establish appropriate Business as Usual (BAU) support structure and processes which are critical for the application to work seamlessly in BAU and generate business benefits.
  • The definition of value/business benefits itself may be ambiguous and not easily understood consistently by various project stakeholders, thereby leading to focus on value realization getting either diluted or lost.

The Project Management Institute (PMI)’s PMBOK® Guide defines a project as a ‘temporary endeavor undertaken to create a unique product, service or result’. In the context of this definition, a successful project, even though it has a defined end date, will be the one that generates significant value for its customer or client organization by delivering sustainable outcomes.

A Sustainable Outcome:

  • Addresses the core issue/problem faced by the customer or client organization,
  • Incorporates specific new methods, approaches, or ways of working that will ensure the solution delivered by the project continues to deliver the envisaged benefits in Business as Usual (BAU) well beyond the project end date.

While a whole host of factors can determine the success of a project, the project’s transition into BAU, if not managed with adequate care and attention to detail, can become the ultimate ‘deal breaker’ and the extensive effort that goes into the project’s core delivery can suddenly come undone with the potential to generate significant client noise.

 Project transition is also a key determinant of sustainable outcomes

Is project transition a point-in-time activity that happens at the time of project handover to BAU?
Project handover is just a key milestone in project transition. While seamless project transition is critical for all projects, mainly medium to large scale projects, the transition needs to begin well in advance of the project handover/closure date (which in most cases will coincide with the project ‘go-live’ date); however, depending upon the agreed scope and objectives of the project, the transition may well extend into BAU post the ‘go-live’ date, e.g., if there is a warranty period post ‘go-live’. For clarity, this concept is visually represented below:

Should project transition be planned only for projects using a specific delivery model/methodology, e.g., waterfall, and not for others, e.g., agile?

Project transition should not be based on a delivery model/methodology. Choice of the delivery methodology is based on each project’s context, customer expectations, and suitability of each method for project delivery. The methodology is just the ‘How’ of the project, while objectives/target outcomes are the ‘What’ of the project. Project’s ‘What’ will remain the same irrespective of its ‘How’. Project transition is about ensuring the sustainability of its ‘What’; hence, it should be planned regardless of methodology.

What then ensures a successful project transition?
Based on our experience of delivering projects of varying size and complexity across different clients, a successful project transition has the following critical success factors:

  • Transition as a Separate Project Workstream
    • Project transition should be considered and managed as an independent workstream of the project and has its own set of deliverables, milestones & detailed activity schedule, rather than as an afterthought as part of the project closure phase, and must be fully integrated into the overall project delivery planning by ensuring touchpoints/interfaces with other project workstreams are outlined clearly.
    • While a high-level schedule for project transition needs to be baked into the overall project schedule at the outset, the planning for project transition need not be initiated at the time of the project initiation – rather, its timing will critically depend on the client context as well as the project scope and objectives, e.g., large and complex projects operating in a client context of multiple levels of review and approval should warrant an early initiation of project transition planning activity within the project lifecycle.
    • Besides, active involvement of the right set of BAU representatives in project transition planning (and execution) is highly crucial for its success since their involvement will ensure:
      1. The right degree of BAU ownership of the transition process, and
      2. BAU expectations from the transition process and any potential BAU ‘blockers and derailers’ are surfaced early on.

If you fail to plan, you plan to fail – Benjamin Franklin

  • Transition Framework – A transition framework provides the guard rails within which project transition needs to happen. It sets out the various aspects that need to be considered while planning for project transition. There could be either an all-encompassing generic framework that can be adapted for each project in the organization or bespoke frameworks for different categories of projects, e.g., Business, Technology, Operations, Finance, etc. The number of frameworks will depend on the client’s appetite for structured project governance and the degree of specificity desired in managing project transitions across different organizational domains. For example, an organization in the early stages of incorporating structured project transition in its project delivery may not have any transition framework available to start with. In that case, specialist advisors can be engaged to help build the required framework library.
    • BAU Operating Model – A well-defined and implemented BAU operating model will ensure the sustainability of the project outcome(s). Consequently, adequate time and resources must be provisioned as part of a detailed project transition schedule to define, refine, and implement this operating model prior to project ‘go-live’. What are some of the key components of the operating model that may need consideration? Based on client context, these could be processes & enabling technology, governance, organization design/roles & responsibilities, and reporting, among other things.

  • Change Management – Each project is, in effect, a change project since it introduces a new or modified product, service, process, or other results into the organization. Especially in the context of multiple projects running across the organization that has an impact in parallel on the same set of BAU teams, it becomes imperative that adequate thought and planning goes into managing the change being introduced by the project to ensure there is minimal / no change fatigue, that the change is readily accepted, and it sticks. This is easier said than done, especially in scenarios where change management is considered an afterthought. Change management tends to be more effective when its importance is fully understood, accepted, and championed by the client’s senior stakeholders. Besides, a good change management plan, like a project transition plan, should be co-created with BAU representatives for it to be successful.

The afore-mentioned critical success factors should be complemented by good project management practices for the project transition to deliver the outcome(s) that will outlast the project for a long time.

Satish Dhingra

Satish Dhingra

Principal Consultant

Satish has over two decades of C-Suite advisory and execution experience in delivering sustainable outcomes for Financial Services clients globally through Strategic Transformation Design and Management across Business, Technology, Finance and Operations domains.

Shan Yong

Shan Yong

VP & Partner Head – CIO Advisory APAC & Financial Services ANZ

Shan is a C-Suite Advisory, Financial Services & Insurance Leader in the APAC region. He has over 20 years of consulting experience in IT transformations and financial services strategy. 

Pin It on Pinterest

Share This