Managing complex programs – standardize and decentralize for efficiency and agility

Program management Turnaround and transformation

28 March 2016 — In complex projects and programs, the choice of operating model (structure, processes and tools) is a key driver of success and execution efficiency. This article presents the evolution of a particularly complex technology program from a top-heavy organization to an agile “divisional” (self-contained) structure.

Managing complex programs – standardize and decentralize for efficiency and agility
Authors
Per Stenius
Per SteniusClient Director
Venla Pouru
Venla Pouru(Alumnus) Manager
Hyojeong Lim
Hyojeong LimAlumnus (Business Developer)

Download this post (PDF)

In complex projects and programs, the choice of operating model (structure, processes and tools) is a key driver of success and execution efficiency. In this article we discuss the evolution of a particularly complex technology program from a top-heavy organization to an agile “divisional” (self-contained) structure. For this program, standardizing key processes opened the window for decentralization resulting in improved efficiency and better decision making. This initially counter-intuitive combination of actions considerably improved the organization’s ability to handle the massive complexity.

The case program here is a (still ongoing) multi-year program, consisting of tens of complex installation projects applying a significantly novel technology. The installations are conducted across a company’s transportation asset portfolio to more than 20 units that are continuously in operation and traversing across the globe. Each project involves various stakeholders such as external designers, contractors, auditors and internal customers.

Old models failed due to unprecedented complexity – a radical organizational change was required

The initial program organization was built based on earlier and simpler installation project models applied within the company, with the assumption that this program, despite being much larger and more complex, would not differ significantly. The original structure was top-heavy and hierarchical, with a large number of people reporting to a single decision-maker. On an individual level, the program lead tried to stay in control of all details but simply lacked the bandwidth to address all projects’ issues. This resulted in a situation where at one point the lead had over 5 000 unread emails. No surprise then that decision-making was significantly delayed and wrong decisions with insufficient analysis were made. This slowed down frontline work, causing both anger and frustration across the many on-going projects that were part of the program.

Further, due to lack of standard processes and follow-up mechanisms, the visibility and comparability of projects was insufficient. It became difficult to see when a project was heading towards a crisis, and mitigating actions were initiated too late. Top management felt increasingly nervous, as key information did not reach them in time and surprising bad news were common. The central team’s workload continuously grew as additional reporting requests piled up from the increasingly frustrated top management. Changes of key personnel and the program team’s geographically dispersed setup further complicated communication and knowledge transfer. There was a clear need for standardized processes, but the strength to implement these was missing.

After about 12 months it was clear that this program was considerably more complex than what the corporation had ever experienced, and that the program is going towards failure rapidly. Without a decisive shift into a new model, the program would have continued to suffer from heavy delays across the individual projects with increasing costs and potential market effects (the program was large and public enough to have a substantial effect on the company's share price). The delays also created financial distress for key suppliers, creating a clear and present danger of some smaller supplier companies going into insolvency.

The big change - switching into a standardized processes and a decentralized model

As the senior program leadership realized the potentially devastating risks of continued delayed decision-making and lack of visibility, the need for a new model became pressing. To mitigate complexity, the program management supported by the program management office (PMO) standardized and automated central program management functions. This helped to free up resources from many routine tasks, and also provided some resource flexibility. Key persons were able to address fires, rather than being tied down by ineffective routine work. At the same time, the management of individual projects was decentralized for faster and more flexible frontline decision-making.

The need for scalability, comparability (benchmarking between projects in the program), organizational robustness and decision-making agility drove the need to establish a new program management model. In the following, we describe the elements of the new model in more detail, applying the traditional operating model framework presented in figure 1. The definition of the project management model applied in the case example is extended from the traditional operating model scope by incorporating two key elements; tools and data, which are increasingly critical elements of today’s organizations.

Figure 1. Extended framework of operating model elements

Figure 1. Extended framework of operating model elements [1]

Structure. The original program governance model (see figure 2) was highly centralized. The resource pool from each central line organization department, such as logistics, finance and PMO, was spread thin across the different projects. This fragmentation and lack of critical mass caused slow execution, inefficiency and process quality issues.

The new organization structure (see figure 3) addressed this issue through grouping two to four projects into a “division” (self-contained unit), capable of and resourced for independent operation and decision-making. A senior project manager role was created to lead each “division” to provide focused support, coaching to project managers and senior troubleshooting capacity across projects. Project managers appointed to this new position were those who had been most successful so far or had a relevant central insight of the program. They were given clear authority to make project-level decisions combined with increased level of responsibility and budget control. Further, support resources for planning, logistics and coordination were assigned into the “divisions” to increase local on-the-spot execution capability. The central organization became lighter, as support resources were assigned under senior project managers. The central PMO was also reorganized to include people with strong analytical ability and solid experience in process and software development (the latter being critical in automation and standardization of tools and processes).

The new model allowed more focus and bandwidth in each management layer for its direct subordinate layer. The program head was now able to spend more dedicated time with the senior project managers for coaching and problem solving. In turn, the senior project managers could now focus more on coaching and proactive fire-fighting with project managers and project teams. Project managers were pleased, as agility and speed of decision-making increased on the project level. The impact of senior project managers was soon visible in frontline development. They started to support and drive initiatives for better site management and more efficient way of working. The role of central PMO became sustaining continuous process and tool development. Top management felt more confident, as there was enough resources to ensure project management process and tool development, knowledge transfer and documentation, which would provide value to future large programs in the company.

Figure 2. Original organization model of the program​Figure 2. Original organization model of the program​

Figure 3. Decentralized organization modelFigure 3. Decentralized organization model

People. In contrast to the initial organization depending solely on the program head, the new structure leveraged leadership capabilities of most experienced project managers more broadly. This improved management in general, and also increased buy-in. Project track record as well as decision-making and coaching capabilities were considered crucial in “division” management. The senior project managers were carefully selected based on these criteria. Two most experienced project managers with extensive frontline exposure and an experienced program manager with solid communication and coaching skills were assigned. Each senior project manager also had a long history in the company and a broad network across corporate stakeholders, helping to resolve the project issues pertaining to different departments.

The role shift yielded tangible improvements from early on, yet some transition challenges emerged as well. The senior project managers quickly took on their new role and started demonstrating leadership with the projects in their “division”. On the other hand, the ones assigned to significantly challenged projects struggled with implementing the corrective actions and coaching project managers, since some of the challenges were beyond what they have addressed in the past. For the former program manager, gaining solid followership from project managers was challenging due to insufficient technical expertise. Further, he maintained the dual roles of former position and the new position for a while, which posed challenges in moving on and immersing into the new senior project manager role. The challenges were addressed through the program head’s targeted coaching and communication of the scope of the new roles across the stakeholders. This emphasized the importance of seeing a role change like this as a process, requiring continued support and guidance, rather than as a appointment.

Processes and tools. While keeping the frontline organization agile was the main target of the change, process standardization was driven to provide holistic oversight and comparability and to mitigate complexity. This also helped to transfer best practices across the program. As a first step, the central program management processes and tools were standardized. Weekly team meetings were implemented across all projects with clear objectives and a standard agenda to achieve alignment among global teams, escalate issues and agree on corrective actions. The monthly "all-hands" workshops underwent a major change, resulting in a more compact and focused 3-day program (previously a full week). The purpose of workshop sessions also shifted from lengthy presentations to collaborative problem-solving sessions. Progress follow-up was standardized and automated with software by applying standard report templates. This also reduced the margin for interpretation and deviations in reporting. By standardizing certain elements across the program real time transparency of progress was considerably improved, while simultaneously reduced reporting and administrative overhead. It also became easier to ensure quality of decision making.

The complex resource management process, which early on hampered execution due to competing needs from various departments, was significantly simplified. An overall resource status report was implemented across all projects initially, followed by step-wise development of a more detailed view. As the basic reporting process stabilized, forward-looking planning tools and scenario analysis were implemented to enhance proactive resource management. This was a considerable effort, since the entire reporting system setup required extensive coordination with other departments as well as an integration to the existing system. However, addressing the complexity was critical to improve efficiency, improve decision making, and reduce overhead.

For severely challenged projects, “war rooms” with standard setup were established to co-locate project team members and contractors, and to enable daily co-working. The war room concept built momentum when the program lead started spending time daily in one of the war rooms, giving practical guidance in planning and project management in general. This front-line leadership also increased morale. Though it took time and conscious efforts to make the war room work, the setup eventually helped to focus execution and problem-solving, as well as team spirit. It also increased the transparency towards top management, who started visiting the room, and improved confidence across the organization.

Metrics, rewards and data. The program decision-making originally suffered from lack of visibility. There was a clear need to increase transparency and comparability of projects while avoiding qualitative metrics such as traffic light indicators. To achieve this, the data collection process was redesigned and project metrics were redefined using concrete milestones and quality gates. A standardized report template was built to achieve data integrity and enable efficient processing of the immense number of line items. Fixed templates with standard line items and input fields were developed for each project phase. To define meaningful metrics for each project phase, considerable work was needed. For each project phase ‒ from design to installation and commissioning ‒ specific quality gates and required system readiness levels were defined for entering the next phase. As a practical example, a standard checklist tool with several hundred line items for commissioning readiness of each installation was developed and implemented across all projects in the program. Further, it was realized that the original man-hour based progress tracking tool was insufficient. A physical line-item level installation tracking tool was developed, and now provides much more accurate assessment on progress.

Leveraging software for improved transparency and speed

The initial central program organization was large, but ineffective. A lot of the resources were wasted on administrative tasks and mundane report preparation. There was clearly a potential to achieve “more for less”. As an example, it took 1.5 days to simply generate PowerPoint material for a program team meeting. This time was spent only on consolidating and reproducing existing information into a presentation, without adding new insight. To address this a macro tool was developed to automatically create PowerPoint slides from underlying data, which reduced the time required by 50%. However, this approach still did not provide adequate transparency, and lacked in ability to look at past data. The process was further developed by including data collection into a well-designed database, from which reports could be generated with a further enhanced software tool. This approach allowed implementing standardized metrics across projects, as the standard database required all projects to report on defined data points. This had a dual benefit, it facilitated best practice sharing, and increased efficiency (and scalability, which was important as new projects were added to the program).

The central PMO now processes 100 000 line items per week and runs a weekly reporting cycle. The time to prepare program meeting materials have reduced close to zero making the process in practice real-time, and users can obtain both top-level and in-depth reports at will through the same user interface. Senior executives now receive a compact and synthesized summary on a few slides and the software tool allows drilling into key areas of interest in greater detail. Compared to a cumbersome consolidation of an over 50-page slide report on a bi-weekly basis, the new approach increases accuracy, transparency, and gives more confidence to management. At the same time, it frees up PMO resources for more value-adding process development.

Using pilots to validiate potential development efforts

While there were several suggestions on how to develop project execution, the management was hesitant to overwhelm the projects with development efforts. In many cases the projects were already late, and development efforts would cause further delay. To validate development ideas, a pilot approach was applied.

As an example, a quality audit for installation plans was developed in one project to reduce the number in-project changes and related cost. Once proven effective, the practice was documented and rolled out across the project portfolio as a standardized initiative. A related development area had to do with progress follow-up. Initially each design contractor was providing progress follow-up in their own format, making it hard to compare progress between projects. A standard format was developed together with contractors, reviewed by the central program management and rolled out in two waves. Wave one to stable projects and wave two to the ones in a challenging situation. Clear instructions were provided both face to face and in writing, after which PMO supported in solving potential issues.

The pilot approach also leveraged the new structure. Initiatives were designed based on observations made in the “divisions” or by central management. They were reviewed and iterated with the relevant stakeholders and implemented in selected projects and – if successful – rolled out as success cases to all projects in a consistent top-down approach. The pilot projects were typically projects with strong performance or ones not in a critical phase, allowing room for experimentation and trial-and-error. This approach was complemented by explicit instructions, implementation support in form of the PMO as well as control over adherence to the established procedures. A "productivity manual" was developed, establishing a best-practice standard across the entire program. The project managers could understand this approach, since they regularly dealt with similar standards in other areas, for example safety. The productivity manual is also expected to provide value in future large scale programs within the company.

Achieving a truly scalable and agile model in a complex program is a continuous journey

Despite considerable improvements achieved so far, the push towards an improved program approach continues. Gaps and process flaws are continuously identified, and steps to address these are taking. The path ahead remains challenging due to the intrinsic complexity of the installations and work volume within a tight timeline, with projects in many cases running in parallel.

Continuous development is the rule. Existing processes and tools go through iterations of development as insights accumulated. The evolution of planning practice is a good example. When existing planning practices were shown to be flawed, a revised planning approach was introduced and tested in a project that was just about to start. As the approach received positive feedback, it was defined as a standard requirement for all future projects. This approach is establishing a continuous learning culture in the multi-year program.

As the first phase of the program is coming to an end and the second phase starting, the focus is on stabilizing existing processes and eliminating "bugs" to improve execution performance. The scale of the program is growing, which raises the stakes. Automated reporting tool development continues to support the need for scalability. The ambition is to have a web-based application for data collection and real-time reporting. In the projects, considerable practical improvement opportunities still exist in workplanning, material flow and pre-assembly. Nevertheless, the lessons so far show that process standardization combined with an agile "divisional" organization structure can increase program performance significantly. This is critical in order to free up resources needed in the more operative process development. The experience from this complex program is also contributing to the development of how to run future complex programs with reduced overhead and higher efficiency. This is of considerable value, since the company expects to see the number of large complex programs increase substantially in the future. Tackling these issues decisively now is thus a critical investment into continued future growth of the company.

References:
[1] Applied from: Amy Kates, Jay R. Galbraith, Designing your Organization: Using the STAR Model to Solve 5 Critical Design Challenges, 2007

For further reading:
Aaron Shenhar and Dov Dvir, Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, 2007 Harvard Business Review
Capturing the Value of Project Management Through Decision-Making