Devising a strategy to address supranormal project challenges

Anyone can manage a Gantt chart. In some cases, real challenges can exist outside the defined scope of the project. In this case, we can call these supranormal challenges. Here strategy—real strategy—starts where your conventional project plan ends. It begins with the friction, complexity, and surprises that arise not from task lists, but from people, politics, culture, inter-project issues and power.

The best project managers understand that success isn’t just about solving technical problems. It’s about navigating the system around the project: the stakeholders, the conflicting priorities, and the sudden shifts in direction that would normally never show up on a risk register.

This is where smart PMs distinguish themselves—not by reacting to every problem, but by designing strategies that account for the messiness of real-world environments.

The obstacle course they never told you about

No one tells you this during certification training: some of your biggest project challenges will have nothing to do with the defined project itself.

They include:

• Inter-project clashes over resources or timelines

• Integration of project outputs with parallel projects

• Organizational politics that influence priorities or slow down approvals

• Conflicting stakeholder agendas that surface too late

• Overloaded portfolios that dilute focus and stretch your team thin

• Siloed subcultures that block collaboration

• Shifting market or executive strategy that upends your plans overnight

These are supranormal challenges. They’re not unusual, especially in larger organisations. They’re just not formalized in the plan. And because they’re unofficial, they’re harder to see, harder to solve, and in many ways far more dangerous.

Super PMs don’t wait for these challenges to strike. They anticipate them. They use project diagnosis tools to identify organizational and broader system-level friction, and they build adaptive strategies for navigating complex, political, and volatile environments.

Strategy for supranormal problems starts with people, not plans

When your project challenge isn’t a technical one, you can’t fix it with another spreadsheet or sprint backlog. You fix it with situational awareness, influence, and leadership. Here’s what real strategy looks like for supranormal problems:

• Build your internal network – Relationships open doors that processes can’t.

• Become a detective – Dig beneath surface updates to understand the real story.

• Map stakeholder interests – Know who supports what, who’s blocked, and who’s silent.

• Prioritize the issues – Not every challenge deserves equal energy. Focus on the ones that move the needle.

• Use change management tactics – Influence behavior, not just process.

• Build coalitions and alliances – Projects succeed when they’re co-owned.

• Sell the problem (and the solution) – Influence starts with shared understanding.

• Be smart with workarounds – if organizational issues will evidently persist

• Work out your locus of control and influence – don’t stress over insoluble problems - workaround them

• Know when to escalate, and when to just act – Super PMs balance diplomacy with momentum.

These strategies don’t come from textbooks—they come from the battlefield. They require EQ, judgment, timing, and guts. Analysis and strategy are crucial to setting the foundations to find a way forward. Effective communication is often a vital factor in implementing much-needed solutions. And they’re what separates delivery-focused PMs from true project leaders.

Personal Story:  Dealing with Organizational Weaknesses

A few years ago, I took a contract as an Engineering Program Manager for a large and innovative IP development company. They developed large-scale digital IP for ICs. My program was to develop a massive-scale Ethernet Packet Processing IP block targeted at 6nm silicon technology. I took over the program from another Program Manager who was completely overloaded.

My main development team was based in India, while the system architect was based in California. The development team in India was about 40 strong, with another 20 engineers being UK based. This 3-time zone interaction meant the working day typically spanned 13 hours, so it was quite exhausting over several months.

As is typical when parachuting into a new project, I rapidly assessed the project situation. It was initially evident that:

• The project schedule was extremely tight and the project estimation was inadequate

• Many of the Indian team members were fresh graduates or new for the company

• Since the IP was to be used in automotive applications including powertrain, there was a new and strict ASIL B functional safety standard to be complied to - the development process was unfamiliar to the team

• The company, in the past, had dropped MS-Project as a scheduling tool and replaced it with a tool that could not dynamically schedule, nor analyse critical paths

• The architecture of the design could not be implemented in physical form because the layout runtime would have been 6 months per trial run using CAE tools

• The company had committed to Agile, even though customers had fixed parameters for schedule, scope, quality, and cost

• The team in India were using Agile in principle, but had no trained Scrummasters, or team members familiar with Agile principles

The last factor was particularly difficult. There was an absence of project management capability on the project, besides myself as Engineering Program Manager. Normally, on high-tech developments like this you would need one project manager per 15 development engineers - so typically 3 project managers for the program.

It was quite clear that the project team and the organization as a whole had significant weaknesses and this situation was difficult to overhaul in a few months. I was therefore left with workarounds.

The first thing a project or program manager can do in this situation is identify the positives and look for allies:

• A brilliant systems architect in California who was approachable

• An experienced Engineering Director in India who could nurture, organise and push the Indian team

• An expert Physical Design department to help address the severe layout challenge

• An expert Functional Safety team to catalyse progress

• A cross-section of experience design engineers

One simply has to leverage off the positives as much as possible. This is exactly what I did. I found the expertise and utilized it to a maximal extent. This requires advanced communication skills and the ability to identify root cause problems quickly, then formulate a winning strategy. Using a coalition of expert and motivated helpers we were able to overcome the significant absence of project management capacity, and to devise a winning approach. In this case, rather than transforming the organisation, effective workaround solutions were identified and implemented.

On the issue of no MS-Project, in the short-term, I personally acquired a cheap older version and used that for critical scheduling. Again, it was a workaround solution, but a necessary one. In parallel, I formed and built a coalition of other Program Managers who wanted MS-Project and agitated a kind of revolution. I admit this was a political campaign, but in the end the company relented and changed their policy.

Conclusion

If your project plan feels solid but your project still isn’t moving—look up, not down. The problem may not be in the tasks. It may be in the system they’re sitting in. Devising strategy for project success means recognizing that tools solve normal challenges, but people solve supranormal ones. Super PMs lead at both levels.