Project Turnaround

Willing to harmonize practices, mutualize organizations and adopt standards…
…until faced with local impacts versus overall optimum.

Resistance to change begins well before go-live and increases as go-live approaches. Resistance to change is one of the main factors in budget and schedule overruns. 

The ideal original vision

Indeed, all organizations naturally adhere to transformation general principles validated during project scoping and to their consequences outlined in general design. It is during the detailed phases, and in particular in the implementation phase, that these same organizations question the concrete changes that upset the micro-balances that have crystallized over time.

The slow yet certain deconstruction

The overall vision is lost to the benefit of local optima. Transformation general principles are deconstructed stone by stone to return step by step to the original state. The transformation is gradually distorted to restrict itself to a technological evolution.

Projects are collapsing under the avalanche of inevitable “change requests”. Each of them is ardently defended by middle management, because often the objectives (and the related incentives) of these managers have not been aligned with the challenges of the transformation!

Resistance to change is initiated within the project teams themselves and intensifies as the project progresses. Addressing resistance very early on within project teams is a key success factor of the transformation. This very often translates into the revision of individual objectives, putting theses into perspective of a more general and collective interest.

Sponsorship related to stakes understanding …
…distantly supported by executives committee.

Concerned with good management practices and worried about financial issues, companies assign a sponsor to transformation projects, often from the executives committee. This sponsor is chosen in connection with the organizational scope mostly impacted by the transformation, and also for its “appetite” for technology. The other members of the executives committee put themselves in the position of spectators of the transformation, clients of it, or even challengers.

Spectators

Transformation necessarily impacts the entire company, even if it concerns only a part of it. Indeed, the mobilization of resources and budgets, which is generally very significant, is necessarily to the detriment of other, even smaller, projects. The longer the transformation project lasts, the more other projects that have been deprioritized are postponed. This is why the company’s players who are in a wait-and-see posture cannot remain so for too long. They are indirectly affected by the transformation. It is in their interest to see the transformation completed as quickly as possible and in the best conditions, so as to leave the field open to the projects that come after, or even are facilitated by transformation.

Clients

The members of the executives committee who adopt a client posture vis-à-vis the transformation project infuse mistrust into their teams. The efforts made by these teams are the price to pay for the expected result. In detail and on a daily basis for the project, the teams will measure the perceived benefit of their investment at their level. They will often fall back on local optimization, or even the reconduction of as-is practices, believing that this is the best way to make their involvement profitable.

Challengers

As for the challenger posture, it is necessarily destructive of value for the company. The pursuit of competing objectives by part of the executives committee is detrimental to the effectiveness of the investments in resources and means in the transformation project. The failure of the transformation project involves at best the write-off of investments, at worst has serious operational consequences for the company, which can even lead to its loss.

A complete alignment of all the members of the executives committee on the challenges, the priority and the means of the transformation is key to the success of the project. It is supported by the entire executive committee. Thus, the position that must be adopted by the executives committee with regard to the project is that of partners. 

Poorly defined objectives / ROI…
…while high pressure on costs, timeline and business impacts.

At present, technological constraints (technical obsolescence, cyber risk, etc.) are regularly at the origin of IT transformation projects. These projects involve large-scale financial investments and resource mobilization. Technological constraints alone struggle to justify the sacrifices that the company must make and the risks it incurs

Weak business foundations for transformation

This is why the company seeks to balance its business case by adding business challenges to the IT project. In a way, the business lines are forced to follow the contours of a project, which is originally technical, in a timing and scope that are not always aligned with its shorter-term challenges. Business benefits are artificially identified, roughly sketched, and roughly quantified. This will make it all the more difficult to measure the return on investment. The weakness of the business foundations of the transformation project will put its successful execution at risk.

Tight management of project budget

As for the project costs, they were assessed with the greatest care. An in-depth analysis made it possible to optimize the budget. Its consumption is very regularly monitored. Comply to the budget is an imperative priority, any overrun is subject to validation at the highest level of the company. And above all, boards are concerned about the operational disruption caused by IT transformation projects. Pressure is constantly exerted on the project management. It is all the stronger when the business expectations are weakly established.

The clear and engaging definition of the business challenges of the transformation project is a powerful lever for its governance. It is therefore an important factor to monitor its costs and deadlines.

Empowered project management team…
…lacking shared target understanding.

The project management team relies on the “business” and “technology” challenges of the transformation to deliver the expected value on time and on budget. The stakes are a key to arbitrate for the project management team. They enable the team to proritize allocation of means and resources. The effort must focus exclusively on what will contribute to achieving transformation objectives. This is the mandate that the executives committee gives to the project management. 

A major arbitration tool

Project management team is a restricted group of people built around the project director and made up of experts: business experts, technology experts, change management experts, project management experts. Their common understanding of the transformation challenges allows them to guide the work on a daily basis and to arbitrate: for example, on which processes should the design effort mainly focus, according to which architectural guiding principles should the technical solution be designed, what are the change management approaches best suited to the context of the project?

Diverging interests

The adherence to the challenges of the project among the members of the project management team may vary over time. One of the classic gaps happens in-between business and IT. The relationship between the different businesses involved in the project can also become unbalanced. As a result, operational choices on the project are polluted by divergence of interests. Arbitration processes are too often activated, which slows down decision-making and consequently the pace of the project. Or the decisions are made in the light of a biased interpretation or a one-sided perspective. This means that, on a regular basis, these decisions are called into question even though work has already been undertaken.

The permanent commitment of the project management group to the objectives of the transformation is mandatory in the balance of the Quality, Costs and Deadlines iron triangle. The management team must continuously remain federated around the transformation stakes. The members of this team form the operational arm of the executives committee in the transformation. The consistency of the project management team around the transformation stakes is strongly correlated with the unity of the executives committee.

Ambitious transformation plan…
…missing recognized legitimacy to trigger change.

The project is a temporary organization specifically created for the duration of the project. This organization is dedicated to achieving a clearly defined outcome. It embodies transformation. Its authority in the company is conferred on it by the executives committee. The scope of its authority consists in defining transformation levers and roadmaps. The project is almost never in a hierarchical position in relation to the entities on which it will have to deploy the transformation. The project cannot unilaterally impose transformation on these organizations.

No sustainable transformation under coercion

The entities of the companies on which the transformation is deployed are rarely part of a fully verticalized governance model. Depending on the company and the model, the different entities deployed have varying latitudes with regards to the executives committee, ranging from autonomous business units to purely operational service centers. The transformation embodied by the project cannot be imposed on these organizations. The authority conferred by the executives committee on the project is therefore rarely sufficient. And even if it were, no sustainable transformation is performed efficiently and achieves its objectives under coercion alone.

Establish a win-win relationship between the project and the deployed entities

It is therefore necessary to establish a win-win relationship between the project and the deployed entities. Executive committee triggers the company’s entities convergence on the need to transform themselves and the nature of this evolution. They support the launch of the project and contribute to it by providing company resources allocated to the project. These resources are key players in change management: they become change advocates with the entities from which they come. Organizing in this way facilitates adoption by entities of the transformation shaped by the project.

The sponsorship of the project by the executive committee plays a key role in the success of the transformation. It facilitates anchoring the need for transformation in the organizations that are going to be deployed. On this foundation, the project builds a relationship with the organizations deployed to successfully implement and deploy the transformation. The company’s resources, drawn from these organizations and assigned to the project, are tasked with building a balance between the company’s transformation prescriptions and the necessary adaptations to field constraints.

Initial scope and related governance set…
…with no relation to stakes.

An IT transformation project generally embraces a wide functional, technical and organizational scope. By nature an IT transformation project is exposed to scope extensions. Scope extensions cause costs and budget overruns. When inappropriate, they prevent the project from delivering initial expected benefits. They may even alter the very core objectives of transformation.

A project scope detailed from the very start in all its dimensions

Base layer of scope management consists in a detailed scope statement. Project scope statement is developed with specific features, refining the results expected to be delivered by the project. It pertains tight scope definitions, clearly identifying in and out of scope areas. Project scope statement aims at cancelling ambiguities: vague functional boundaries, slushy organizational perimeter, nebulous technical bill of materials. The high-level scope of the project charter is expanded into project scope statement decomposing functional processes into variants and use cases, organizations into geographies, sites and departments, technical bill of materials into subproducts, modules and add-on packages.

Detailed project statement is broken down into a robust and comprehensive Work Breakdown Structure. The Work Breakdown Structure is organized into work packages. Work packages are structured around consistent chain of sequenced deliverables relating back to project scope and objectives.

Objectivized governance of project scope

The scope management process is attached to the project scope statement. In the day-to-day discovery and detailing of requirements, scope changes arise that need a decision making authority. Scope monitoring leverages requirements traceability: all new functional, technical or organizational requirements are traced back to business and project objectives. Requirements traceability contributes to sorting detrimental scope changes from valuable ones. Scope management process handles scope changes in an effective and unbiased way so as to facilitate a timely and sensible arbitration. Scope change authority is objectively enabled. 

Controlled project delivery schedule

Delivering the project in a timely manner is critical for scope management. The longer the project, the higher chances for scope extensions to occur. A large project scope combined with a long project schedule open the door for more features to be added to the project scope.

One way to secure project delivery consists in scheduling regularly significant milestones and / or decision making events. Theses events mobilize sponsors and stakeholders. They compel project teams to deliver in time intermediate results. They also bring back the project into sponsorship’s focus and ensure sponsorship’s continued ownership.

Distributing the scope across sub-projects allows to break down the project into shorter sub-projects. The organizational scope is a good candidate for splitting: project can be broken down into pilot entities and deployment waves, versus a big bang approach. Functional and technical scope can also be distributed into sub-projects. Sub-projects are closed faster, thus maintaining momentum and demonstrating tangible results.

The wide scope of an IT transformation project implies the mobilization of multiple and diverse sponsors and stakeholders. A scope management process is defined in the initial phases of the project to ensure relevant involvement of sponsors and stakeholders. Such a governance is set to ensure scope evolutions are appropriate and contributive to project stakes. Scope monitoring is based on a detailed scope statement. Contribution of new scope features to benefits pursued by the project is traced for informed decision making. A properly defined scope alongside with a robust scope control process are key to monitor scope extensions.

A complementary way to supervise scope consists in dividing it into smaller sub-projects. Such an approach aims at delivering value in shorter timeframes. Shorter schedules and faster pace help projects escape scope extensions.

Acknowledged transformation impact on culture and skills…
…limited to tech adoption plans.

All enterprises undertaking transformation projects recognize that a change management approach is required to ensure smooth transition to the target state. The change management approach is often focused on Communication and Technology Adoption work streams. 

Efficiency in change management stems from knowing and understanding change stakeholders. Change stakeholders are generally organized into 4 groups: executive leadership, middle management, operational teams and key interacting teams (e.g. Human Resources). Segmenting these groups according to intensity of change impacts with regards to organization, practices, culture and technology dimensions helps with tailoring the change management approach.

Having performed change stakeholders segmentation, projects engage in the Communication workstream and focus on preparing the Technology Adoption workstream.

Engage with transformation projects sponsors 

The first missing work stream is the Sponsor Engagement workstream. Sponsor Engagement goes way beyond Executive Leadership Communication. The greatest success factor for managing the “people side” of change management is active and visible sponsorship throughout the effort. Sponsor Engagement workstream consists in defining and achieving a set of identifiable actions that executives committee takes to sponsor changes. All these actions concur to build a supporting coalition among senior management across the enterprise. Sponsor Engagement workstream mainly delivers individual and collective commitment to transformation at executive level.

Address employee resistance through transformation coaching

The second missing work stream is the Organization Transformation Coaching. The number one obstacle to success for major change projects is employee resistance.

Transformation projects look at standardization, harmonization, mutualization as levers to promote generic and prescriptive guidance for practices across international and multi-activities organization. Striking the balance in-between these global guidelines and local innovations and customizations is key to avoid arising employee resistance. In diverse organizations, achieving this balance is critical given the various specific cultures, practices, requirements and regulatory constraints. Change agents, appointed from each of the work groups impacted by transformation, advocate as peers for changes and on the same time identify areas where global practices yield to local ones. Change agents act as coaches to the transformation effort.

In addition, the Training work stream is not limited to Technology Adoption, which consists specifically into trainings on the new IT tool. Trainings address all aspects of change and are as much as possible crafted to individual needs, especially when considering organization, competencies and behavior / culture changes. Training aims at building the knowledge, skills and abilities required for individuals to endorse their new roles across the enterprise.

Precisely monitor change resistance and transformation adoption

Eventually, the last change management work stream is the Resistance Monitoring one. Resistance Monitoring work stream aims at controlling change management performance. Rate and pace of transformation adoption is supervised, for instance through assessment of training and communication effectiveness.

Deploying a structured approach to change management positively impacts speed of transformation adoption. The structured approach focuses specifically on the “people side” of change. The “people” dimension is addressed within a set of change activities centered on sponsor engagement, organization transformation coaching, communication and training. Results of the change management approach are objectively monitored and actions are adapted to optimize their efficiency.

Project staffed with strong business representatives…
…missing IS counterparts on the level. (and vice versa)

Transformation projects tend to be staffed with specific expert profiles, according to the perception of project challenges. Perceived required skills span across business, technology, project management or change management skills. Often the same team is continued across the whole project duration, regardless of project needs.

However, assigning to the project professionals unfit with project needs increases project people costs with 40% and project failure with 25% according to 2021 Project Management Institute’s Talent Management report. Project leaders continuously adapt staffing plans to assemble a team with the right bandwidth and expertise, filling talent gaps and reducing redundancies.

A staffing plan based on a detailed analysis of needs and the advanced management of the skills available internally as well as externally

Assigning people with proper skills to the right positions starts with needs analysis. The initial staffing plan is based on the top-down analysis of the project time and scope. Project Manager works with Project Owner and company managers to appoint the appropriate team leads, who in turn drill down their respective domains and outline the capacity required to deliver the expected results. This overarching staffing plan becomes the reference plan which is adapted throughout the project life cycle.

Project Managers are often driven to shop for talents across and beyond the enterprise to fill the gaps. Assigning an internal resource to the project means backfilling the vacancy created in the organization, which may cause delay for the resource to be available and / or overload due to dual staffing of the resource. It also triggers the issue of career paths for the assigned resources. Alternatively, skills can be sourced from outside the company. Project Managers must in this case secure knowledge transfer to prevent unexpected departure of the outsider and when required to internalize the missing competence. 

Dynamic and proactive management of the project team

Effective project staffing also means shedding redundant and / or unneeded resources when necessary. Making sure teams are working at their full capacity is based on clearly defining and communicating team members’ roles in the initial staffing plan. Assigned responsibilities are regularly reviewed as project plan is adapted. 

Talent needs evolve during the project requiring shifts in the team size and skills profile. However projects obviously run into unplanned situations missing the right skill set when needed. Understanding and mitigating staffing risks attached to the staffing plan is therefore a good project management practice. 

Organizations often launch parallel transformation initiatives which sometimes require the same skills. One of the main reasons for resource unavailability is concurrent assignment. Taking a holistic view on staffing helps optimizing and consolidating projects resources needs. Proactively analyzing resource needs across project portfolio prior to kicking-off transformation projects helps identifying resource conflicts. Conflicts are anticipated and can be addressed in advance. In a context of limited resources, this means projects have to be re-prioritized.

Competencies needs vary with project phases and project events. Too large teams lack reactivity, too small teams are unable to absorb unplanned workload increase, under-qualified teams are deprived form the in-depth expertise when needed, over-qualified teams inflate project costs. A tailored and proactive approach to project staffing keeps project teams capacity and expertise balance appropriate.

Design efficient end-to-end processes…
…when cross function understanding is partial.

The business part of the project team is a group of functional profiles working together pursuing the same transformation goal. Between them these people have the skills and capabilities needed to deliver the project expected value. Each of team members enjoys a degree of specialization on their own functional field. They may in the course of the project be driven to work in silos separately from each other, while deploying a cross-functional collaborative working approach increases creativity of specialized teams and improves consistency of the solution.

However a single cross-functional team can seldom embrace the full functional scope of a transformation project. Project teams are generally organized into functional domains. These domains face collaboration related impediments to cross-functional work:

• Lack of value stream mapping,
• Lack of appropriate integration approach,
• Lack of timely feedback from other functional domains.

Value stream mapping as an overarching repository

Value stream mapping identifies the steps to bring a product and / or a service from order to delivery to the company’s client. Value stream mapping is used in lean management to eliminate waste. It overarches process mapping as it materializes both material and information flows. Value Stream mapping shows the link in-between the material flow and the information flow. Functional domains work at process / information flow level and below. Understanding this link fosters collaborative works, especially during cross-functional intensive phases such as cutover preparation or post go-live support. 

Value stream mapping sets a common language and a shared business structure to refer to. Relating functional domains’ functional deliverables back to the overarching value stream map helps understand consequences in other domains of their design / build. Leveraging value stream mapping in project events such as stage gates help ensure the consistency of cross-functional design / build. It also secures top management’s proper understanding of transformation consequences along the value chain.

Team structure makes end-to-end functionality difficult to attain. Domains focus on their respective scopes, often regardless of the end-to-end process flow. Understanding off boundaries functional design and / or build is a challenge for domains. The challenge is addressed through the transformation project approach and related governance.

Collaboration across domains infused in the transformation project governance

Project organization features a functional integration unit. The functional integration unit is attached to project management operates across functional domains.

The integration unit can be staffed with a single individual, whose role consists in facilitating inter-domains dialogue, ensuring cross-functional governance is qualitatively deployed. Alternatively the functional integration team can be ran with subject matter experts widely spanning across the functional scope. In this case, there are organization models where functional domains report to the functional integration unit, which reports to the project management. Some cross-functional features of the scope may also be assigned to the subject matter integration unit for design and / or build, such as master data management.

The integration unit chairs the integration committee, where functional integration issues are reported, cross-functional decisions discussed and functional integration action plans are monitored. All functional domains prepare and attend to the integration meeting.

Cross-functional integration at the core of the transformation project approach

The integration committee ensures functional consistency between the functional areas. It clears and monitors functional area action plans on integration points. These action plans make it possible to address the open points raised by the functional domains during their daily work in their respective swim lanes. The integration open points are administered by the functional integration unit and prioritized by the integration committee. The project organizes their management: reserved periods are set aside in the work plan of each phase. During these recurring reserved periods, the relevant domains work together to resolve the integration open points assigned to them.
It is critical to identify and address integration points at a very early stage. Late resolution of an integration point increases the risk of re-designing the target to retrofit the solution to the integration point. It is often because solutions to integration points were neglected in the design phase that the implementation or user acceptance phases seriously drift.
In agile mode, the use case approach reduces the risk of functional inconsistency within the same sprint. In the case of significant transformation programs, this risk of inconsistency persists between sprints. “Integration” sprints are then planned in sprints scheduling. “Integration” sprints allow teams to test and ensure overall functional consistency. It is also while preparing a detailed backlog of user stories upstream of the project that integration points are identified. They are scheduled in a relevant way in order to play them in the sprints to consistently iterate on the solution.

The importance of the functional and organizational scope covered by transformation projects often requires that the scope be modeled and distributed over homogeneous functional areas. As a result, the work of these domains on cross-functional integration points must be organized in such a way to ensure end-to-end consistency of the target processes. Several tools are implemented.
Value Stream mapping establishes a business reference for communication and inter-domain exchanges. This framework is also used in interactions with customers and stakeholders in the transformation project.
The functional integration unit is the linchpin in the organization of the functional integration project. The unit tracks, traces, and supervises the identification and resolution of integration open points. It organizes collaborative work between the domains on the specifically identified integration points.
This cross-domain work is planned and organized in the project plan within each of the phases in a systematic way, regardless of the Agile or Waterfall project method.

Structured Enterprise Architecture guidelines…
…which don’t match with short term business priorities.

Enterprise Architecture guidelines as guard rails for the project

The IT Department and the enterprise architects teams have set an application target and established a roadmap for its deployment. The solution supporting the organizations and processes targeted by the transformation project is part of this target Enterprise Architecture. The latter is based on guiding principles, such as a tree of functional capabilities, a selection of recommended technologies, a policy for adapting and managing solutions as closely as possible to the requirements of each entity, or the definition of integration standards in-between applications. The solution will respect these principles and integrate these fundamentals into its functional and technical design.

Enterprise Architects part of the transformation team

The project organization integrates the Enterprise Architecture dimension into the transformation teams for this purpose. The Enterprise Architect assigned to the transformation project may be attached to the integration unit or directly to the project management team. In this way, the Architect embraces the solution as a whole and in a transversal way. The Architect fully measures the impact of the adoption of Enterprise Architecture principles on the solution, and therefore on the transformation project that designs and implements it.

A solution designed to embrace Enterprise Architecture principles

The deployment plan for the solution supporting the target organizations and processes will be part of a broader plan for the deployment of the target Application Architecture and the evolution of its components: integration tools, technical platforms, security standards, etc. However, the duration and complexity of the solution deployment project mean that not all of these guidelines can be digested by the project. Priority will be given to intangibles as well as principles that will directly serve the achievement of the objectives of the transformation project.
In this context, it is important to clearly identify the Enterprise Architecture principles whose integration has been postponed and to include them in the solution’s evolution backlog. It is also critical to anticipate their future reintegration and to design the solution in such a way that it can absorb these principles in the future without being disrupted.

The solution designed and deployed by the transformation project blends into the functional capability structure established by the Enterprise Architecture and adopts its standards. The transformation project as well as the Enterprise Architecture are by nature in permanent movement. It is difficult to coordinate them completely, the project is inevitably bound to select the principles that it will be able to integrate into the solution it will deliver, and prepare it so that it can reintegrate in its future developments the standards that were deprioritized during transformation project delivery.