#001 - Turning Conflict Into Momentum: Lessons from Project Orion
How did a promising high‑tech project crash and burn, and what can we learn from its recovery?
Project Orion—a fictional but realistic effort to build a predictive maintenance platform for a renewable‑energy firm—was awash in cash, technology and talent. Yet the initiative nearly imploded because of human dynamics: hidden dependencies, uncontrolled scope creep, and a breakdown of psychological safety within the delivery team. In this case study, we revisit the root causes of failure in detail and walk through how a new project manager turned the tide by addressing conflict head‑on.
Background: What Project Orion Was Trying to Achieve
ZenithTech, a mid‑sized software company, won a €35 million contract from SolaraEnergy to build a real‑time asset‑management system for wind‑farm operations. Code‑named Project Orion, the platform would collect SCADA data from turbines, apply predictive‑analytics algorithms, and help maintenance crews schedule repairs before failures occurred. SolaraEnergy wanted a live system within 14 months to support its next wind‑farm expansion.
Technical and contractual dependencies
The plan hinged on several external components:
• NebulaPredict API: a third‑party AI service promised accurate predictions but provided limited API documentation. The contract held uptime penalties but said nothing about model explainability or extensibility.
• Legacy SCADA integration: data had to be extracted from SolaraEnergy’s legacy SCADA systems, which used proprietary protocols and inconsistent timestamps.
• Regulatory compliance: EU cybersecurity rules mandated encryption and audit trails for operational technology data streams, with an external audit scheduled mid‑project.
• Cloud migration: ZenithTech was concurrently migrating workloads to a hybrid cloud, pulling infrastructure specialists into two high‑stakes initiatives.
Team structure and pressures
The cross‑functional team comprised a product owner (PO), technical lead, data‑science lead, UX lead, and QA lead. SolaraEnergy supplied subject‑matter experts (SMEs) for wind‑farm operations, but their involvement was limited. The initial project manager mapped out an aggressive schedule with little buffer and no formal risk register—optimism bias and the planning fallacy at work. Dependencies were glossed over, even though unmanaged dependencies can silently derail projects .
The Dominoes Begin to Fall
Early friction: incomplete APIs and delayed security design
During the second sprint, developers discovered that NebulaPredict lacked endpoints for bulk data ingestion. The data‑science lead raised this risk, but the technical lead pressed onward, instructing the team to develop peripheral features while awaiting vendor clarification. This buried the problem, creating an integration time bomb.
Simultaneously, the QA lead warned that the legacy SCADA systems could not support the encryption protocols required by EU regulations. The PM assumed a security waiver could be obtained later and deferred the issue. By ignoring these warning signs, the team built on shaky ground.
Eroding psychological safety and misaligned priorities
Amy Edmondson describes psychological safety as the belief that one will not be punished or humiliated for speaking up with ideas, questions or mistakes . In Orion’s early sprints, this was lacking. Meetings were dominated by the PM and technical lead; junior developers and QA analysts feared raising concerns. The product owner, keen to satisfy SolaraEnergy, often accepted new features without analysing the impact. When people do not feel safe to speak up, projects suffer from more errors and less innovation .
Scope creep disguised as innovation
At the fourth sprint, SolaraEnergy asked to include a green‑hydrogen module to predict hydrogen production during surplus energy periods. The PO, fearing to disappoint the client, added it to the backlog without a change request. The technical and data‑science leads objected: this fundamentally altered the scope and required new datasets. Conflict flared. This scenario illustrates how small “just one more thing” requests can mushroom when there is no change‑control process .
Resource fragmentation and silos
Hiring additional developers proved difficult; two candidates declined due to salary limitations. Core team members were simultaneously allocated to ZenithTech’s cloud‑migration initiative. Research shows that splitting people across multiple projects reduces focus and increases burnout. As workloads mounted, developers retreated into silos to meet their own deadlines and collaboration disappeared. Integration points were missed, and technical debt accumulated.
Open conflict and toxic behaviors
Over the next several sprints, tensions escalated:
• Public criticism in code reviews: the technical lead chastised junior engineers for missing acceptance criteria, eroding confidence.
• Unresolved UX/data‑science disagreement: the UX team wanted simple dashboards; the data‑science team insisted on exposing complex variables. Without mediation, this stalemate delayed design decisions.
• Perceived blame: after a failed demo triggered false alarms, the PO publicly blamed the data‑science lead. The data‑science lead countered that the PO’s unauthorized scope changes were responsible. This confrontation eroded morale even further.
At this point, psychological safety collapsed. In such environments, employees become more likely to take offense, blame others and distrust the team . Two junior developers resigned, citing the toxic atmosphere. Surveys show that employees often cite personality clashes, stress and poor leadership as causes of conflict.
Critical incidents: The audit and the CRASH
1. Security audit failure: the external auditor found unencrypted data transmissions from SCADA systems. The team had not implemented encryption because they were still awaiting a waiver that never came. The audit halted progress until security was remediated.
2. False‑positive crisis: in an attempt to impress the client, the team demoed a version that bypassed data cleansing. NebulaPredict flagged normal turbine operations as faults, setting off false alarms. SolaraEnergy’s operations team lost trust in the system.
3. Team attrition: the combination of unrealistic deadlines, constant scope changes and public blame led to two resignations and several disengaged employees.
The Turnaround: New Leadership Steps In
The Steering Committee (SteerCo) concluded that the project manager in charge lacked the experience and authority to steer the project and mitigate conflict. An experienced PM took over. His approach combined empathy and firmness, acknowledging the human issues while instituting process discipline.
Listening first
Before making changes, the new PM conducted confidential, one-on-one interviews with team members and stakeholders. He discovered misaligned incentives, fear of speaking up, and a lack of structure around change requests and risk management. Only then did he convene a joint meeting with the PO, leads and a client representative.
Setting new ground rules
He opened the meeting with an honest summary: “I’ve heard from many of you that misaligned priorities and poor communication have eroded trust. We need to reset before moving forward.” Then he proposed five ground rules:
1. Respectful communication: all feedback is welcomed; personal attacks are off limits. When teams feel psychologically safe, mistakes decrease and innovation rises .
2. Formal change control: no new features without a documented impact assessment in the Project Change Requested (PCR). This prevents “one more thing” from derailing schedules.
3. Transparent risk management: maintain a risk register and review it regularly at predefined points. Hidden dependencies, risks and assumptions are the root of many delays.
4. Focus and prioritization: limit work in progress; avoid splitting key people across projects. Cross‑training can provide backup when people are unavailable.
5. Constructive conflict: conflict is inevitable; engage with it rather than avoid it. Conflict competence—the ability to use cognitive, emotional and behavioral skills to produce productive outcomes—can be learned.
A real conversation: resetting expectations
To drive these points home, the new PM didn’t just announce rules; he engaged the leadership team in a candid discussion that modelled the kind of respectful, transparent communication he expected. Below is a reconstructed dialogue illustrating how he introduced the rules, responded to objections and fostered alignment:
PM: “I’ve heard from many of you that our project is off course. Misaligned priorities and poor communication have eroded trust and stalled progress. We need a reset.”
PM: “Our shared goal is to deliver a reliable, secure asset‑management system on a realistic schedule. To get there, we need to agree on how we work together. Here are the ground rules: respectful communication, formal change control, transparent risk management, focused resourcing and constructive conflict.”
PO: “I’m worried that strict change control will slow us down. SolaraEnergy’s environment is dynamic—if we don’t react quickly, we’ll miss opportunities.”
PM: “Change control doesn’t mean ‘No.’ It means we assess impact before we commit. If a new request is essential, we’ll adjust scope, schedule or resources together. Otherwise, we risk delivering nothing well.”
Technical lead: “We’ve raised risks before, but nothing happened. Why should we believe it will be different?”
PM: “Going forward, each risk will have an owner and a mitigation plan. We’ll review the risk register at every steering meeting. If a risk needs escalation—to the vendor or the client—we’ll do it immediately. Hidden issues are what got us here.”
UX lead: “Open conflict is uncomfortable. Won’t encouraging disagreement make meetings tense?”
PM: “Conflict is natural and can be healthy when managed well. We’ll focus on problems, not people, and use neutral facilitation when needed. I’m investing in communication‑skills workshops because training improves quality and productivity .”
SolaraEnergy representative: “Our board expects the system in six months. We can’t delay.”
PM: “We want the system online too, but we’ve underestimated complexity—the planning fallacy in action. The current timeline is unrealistic given the integration and security hurdles. I’ll provide a revised schedule next week with contingencies. Meeting a believable date beats missing an impossible one.”
PM (closing the conversation): “These ground rules aren’t optional. I’m accountable for enforcing them, but they require everyone’s commitment. If we work transparently, control scope and engage constructively, we can rebuild trust and deliver a successful project.”
Navigating objections with empathy
When the PO worried that formal change control would stifle innovation, the PM clarified that it simply required understanding the impact of new requests; if the benefits outweighed the costs, the team would adjust the backlog together. To the technical lead, who doubted that risks would be addressed, he promised that risk owners would be assigned and escalation paths made clear. When the UX lead feared that open conflict would be uncomfortable, he offered to bring in a neutral facilitator and invest in communication skills training. Studies show that such training improves quality, productivity and cost outcomes .
Resetting expectations
Confronted by the client’s insistence on the original 14‑month deadline, the PM explained the planning fallacy—our tendency to underestimate complexity and ignore risks. He committed to a realistic schedule with contingencies for integration hurdles and security remediation.
Reinforcing with training and monitoring
To sustain the cultural shift, the PM instituted conflict‑resolution and psychological safety workshops. Training in these areas improves teamwork, productivity and satisfaction. He also introduced anonymous pulse surveys to gauge morale and flag issues early.
Holding everyone accountable
He closed by emphasising that he was accountable for enforcing the new rules but that each member needed to commit to them as well. Accountability would be shared; successes and failures would be discussed openly. By modeling humility and a growth mindset, he signaled that learning from mistakes was encouraged.
Lessons for Project and Program Managers
What can we learn from Orion’s collapse and recovery? Here are practical takeaways:
1. Psychological safety isn’t optional. Teams deliver better outcomes when people can speak up without fear. Leaders must model vulnerability and curiosity; harsh criticism destroys trust.
2. Map dependencies and maintain a risk register. Document vendor constraints, regulatory requirements, integration points and resource dependencies. Review them regularly and build buffers.
3. Control scope through formal processes. Scope creep thrives when stakeholders can bypass change control. Tie every new request to resource, cost and schedule impacts and obtain explicit approvals.
4. Protect resources and limit multitasking. Splitting key people across projects reduces productivity and increases burnout. Align staffing with priorities and cross‑train to avoid single points of failure. Prioritize and Execute.
5. Engage in conflict; don’t avoid it. Conflict can lead to improved understanding and decisions when managed constructively. Provide training in conflict competence and use facilitators when needed.
6. Be realistic about timelines. Address optimism bias by using historical data and including contingencies. Re‑baseline when assumptions change.
7. Communicate transparently. Document decisions, share status updates and use pulse surveys to gauge morale. Hidden issues breed mistrust and errors.
8. Lead by example. Demonstrate respect, accountability and continuous learning. Team culture mirrors leadership behaviours.
9. Consider a red team. Introducing an independent group to challenge assumptions can surface hidden risks and biases. A red team asks tough questions and helps you make better, evidence‑based decisions.
Final Thoughts
Project Orion’s failure wasn’t due to technology alone—it was the result of neglected human factors. By rebuilding psychological safety, instituting disciplined processes, and engaging with conflict constructively, the new project manager transformed a failing project into one with a fighting chance. The lessons from Orion apply to any team facing complex dependencies and high pressure: respect the human element, address conflict head‑on, and lead with humility and transparency.