Three Common Pitfalls of Reorganizing Project Systems
For those of us in or supporting capital project organizations, rumors and announcements regarding organizational reshuffling are commonplace. As the leader of IPA’s Organizations and Teams Group, I’ve had the pleasure of helping dozens of companies, including multi-national companies, with complex project systems in the chemicals, energy, refining, pharmaceutical, and mining sectors, create strong capital project organizations and teams. A good few of the reorganizations I have observed over the years are rather well rationalized. But I’ve noticed several pitfalls that frequently undermine reorganization efforts.
Before exploring the pitfalls of reorganizing project systems, it has to be mentioned that reorganization can mean different things in different contexts. Reorganizations can start in different places within the corporate structure. Sometimes, efforts are isolated to the project system, but often they are part of a larger, company-wide reorganization effort that necessitates project system change. The depth of the effort can also vary from relatively minor to a wholescale transformation. These considerations certainly influence the approach and scale of a change effort, but the fundamentals of this kind of change, and the things that often get in the way, are consistent.
Too often I have observed project system reorganizations encounter three common pitfalls.
- The blind leading the blind: reorganizing without a clear vision
- Pushing a rope: trying to make a change from the bottom up
- Reorganizing is a hammer, everything else is a nail: jumping to reorganization to solve a perceived problem
The Blind Leading the Blind
My team of analysts at IPA recently worked with a client group that had decided they needed to reorganize. The group had some pretty clear ideas about how things should change. But when my team asked some basic questions about the motivation behind reorganizing and what they were trying to accomplish, things started to unravel. In this case, the group’s gut feeling was right; things did, in fact, need to change. Yet, they had difficulty articulating how change would help. The underlying problem was the group was fooled into thinking that any change alone would solve their problem.
IPA has found that clear vision is fundamental to effective project system change. When we work with systems on reorganization efforts, we work early on to establish organizational design principles. These are statements about what the organization exists to do and serve as a North Star through the rest of the change effort. Every decision and design element is filtered through these principles to ensure we are designing around or towards the desired objective, not simply designing something that makes sense theoretically.
Pushing a Rope
Sometimes those on the ground can more clearly see issues than organizational leadership. In fact, IPA’s Team Functionality, Site Health, and Organizational Dynamics services are predicated on this idea. These insights are important, must be sought, and should be heeded. However, fundamental organizational change simply does not occur at this level. It must come from the top down.
This is not a new idea and many change management frameworks highlight the need for leaders to drive change for it to be effective. However, my observation is that well-meaning, smart people waste a lot of time and energy trying to fix problems they will never be able to fix. These are your best people; those that see a problem and are not content to work around it but instead take it upon themselves to enact change. Not only do these people end up wasting time and effort on a problem they cannot fix, but there is opportunity cost associated with occupying your best people with dead-end projects, and going through this cycle is often demoralizing.
When my team gets involved in a potential organizational change effort, one of the first things we ask is, “Who is involved, and who is driving the change?” If the answer does not include senior, usually C-Suite, company leadership, we either strategize an approach to get senior leadership buy-in or attempt to redirect the team to actions and changes within their control and that may provide incremental benefit. If leadership does not fully own organizational change efforts, the efforts will fail, at best, and create ambiguity and chaos, at worst.
Hammers and Nails
Leaders may rely on organizational change as a cure-all to any problem where the solution is not apparent. An example of this is a company that I worked with not too long ago that experienced real challenges with project controls. After some study and thought, they determined it was an organizational issue because the right information was not getting to the right people at the right time. As IPA worked with this company, it became clear, however, that it was not so much a problem of information flow, but rather some fundamental things simply were not being done. Rather than change the organization, we worked on building competency in the controls function, and this eventually addressed the issue.
From time to time, a leader may also initiate a reorganization to draw attention away from operations problems, perhaps problems they are responsible for creating. It is well understood that reorganization takes a significant amount of time and tangible results should not be expected immediately. The reorganization, in such instances, may last long enough for a leader to move on to another position.
However, I believe most of the time leaders are genuinely searching for a toe-hold for progress and thus seek to empower project organizations to drive project system improvement. Organizational change is complex and opaque though and can therefore be used as a solution to almost any problem.
Effective organizational design is foundational to success, and reorganization is sometimes necessary to adapt to the changing environment. Companies must carefully consider whether the pursuit of change is fully understood from the top down to prevent a time-consuming and costly endeavor from worsening project performance in the long run.