Henrico Dolfing - Independent Board Advisor

IT Outsourcing: A Strategic Decision, Not a Default Choice

2025-02-03T11:00:00.000+01:00

Outsourcing, nearshoring, offshoring—these buzzwords get thrown around as if they are the silver bullet to IT cost reduction and efficiency.

But here’s the harsh truth: If your IT is a key asset or a differentiator, sending it far away from your headquarters is a strategic disaster.

Would you offshore your product strategy? No? Then why would you offshore the very technology that runs your core business? Banking, insurance, or any industry where technology is an essential competitive advantage needs IT close to home, embedded within the business, and deeply aligned with strategic objectives. If it’s far away—whether by geography or corporate structure—it will never be more than a cost center, and that’s a race to the bottom.

If, however, you’re talking about non-differentiating IT—commodity services, back-office systems, or standard support—then, by all means, find the most cost-effective way to get it done. But let’s be clear: outsourcing should be a conscious, strategic choice, not an automatic reflex to cut costs.

And yet, outsourcing is only one piece of the puzzle. The other is how you manage your workforce.

If you keep IT in-house, filling critical roles with external consultants instead of internal employees creates the same risks.

Too many companies play the headcount game, setting KPIs to limit full-time employees while hiring an army of external consultants at a premium. The irony? This ‘savings’ approach ends up costing more while ensuring that the company never retains critical knowledge in-house.

If a capability is strategic, it needs to be built and maintained internally. Otherwise, your company becomes dependent on an endless rotation of consultants who, conveniently, never transfer their expertise before moving on to their next contract. It’s a cash burn wrapped in a short-term illusion of flexibility.

Yes, external expertise has its place—think temporary spikes in workload, specialized knowledge, or transformation initiatives. But outsourcing your core competencies to third parties is like renting your brain: eventually, you’ll forget how to think.

In a nutshell:

> If IT is your competitive advantage, keep it close. Offshoring core technology is a strategic failure.

> Only outsource what is non-differentiating. Everything else belongs in-house.

> Managing by headcount KPIs while overspending on externals is financial nonsense.

> Build internal knowledge for long-term success, don’t rent it short-term at a premium.

The Five Elements of a Strong Governance Structure for Critical Projects

2025-01-16T10:00:00.003+01:00

Every executive has nightmares about that project—the one that spirals into an unmitigated disaster.

In general there are four ways a project can end up in a boardroom-shaking failure that can destroy value, reputations, and trust in one fell swoop.

1. The Titanic Failure: The project chugs along, oblivious to the iceberg ahead, burning millions of dollars only to crash when it’s too late to salvage anything. You’re left with empty pockets and a bitter sense of “we should have seen it coming.”

2. The Frankenstein Success: It’s alive! The project technically succeeds—maybe even on time and on budget—but delivers something the business doesn’t need. It’s a shiny solution to a problem no one has, and your ROI? A big fat zero.

3. The Quality Nightmare: The project ships, but it’s riddled with defects. Faulty execution leads to recalls, refunds, or worse—customer outrage. The financial losses are staggering, reputational damage is irreversible, and legal teams scramble to limit the fallout. Suddenly, "done" doesn't feel done at all.

4. The Regulatory Bomb: The project gets delivered, but it drags your company into the murky waters of regulatory, legal, or compliance hell. Suddenly, that “innovative” initiative has the lawyers working overtime, leaving you questioning every decision made along the way.

These aren’t just hypotheticals—they’re common ways critical projects unravel, taking reputations and shareholder value down with them. Just have a look at my 20+ project failure case studies and you will find plenty of examples for each scenario.

Every single one of these scenarios can be prevented with a good governance structure.

A clear structure ensures accountability, strategic alignment, and problem-solving at every level.

Based on my two decades of experience with large and critical projects I strongly believe that the best governance framework comprises five key elements, each with distinct roles and responsibilities.

I have visualized these elements and their relationships in the diagram below. The remainder of the text will explain the elements and structure in more detail. For each element I have written an additional article explaining why this element is necessary for your critical project that is linked in the text.

1. Executive Sponsor

The Executive Sponsor is the project's ultimate champion. As the highest-ranking stakeholder, this individual:

> Sets the strategic direction by ensuring the project aligns with the organization’s goals.

> Secures funding and resources, breaking through political and budgetary barriers.

> Makes key decisions when roadblocks arise.

> Acts as the face of the project to senior executives and external stakeholders.

Without a strong and engaged sponsor, projects can flounder in bureaucracy or lack the clout to resolve disputes.

Read "Why Every Critical Project Needs an Executive Sponsor" for more details.

2. Steering Committee

Think of the Steering Committee as the project’s advisory board. Composed of key stakeholders and subject matter experts, their primary responsibilities include:

> Ensuring alignment with organizational priorities.

> Approving major milestones and deliverables.

> Providing strategic input and resolving cross-functional conflicts.

> Monitoring risk and performance metrics.

The Steering Committee operates as the decision-making body, ensuring the project remains on course without micromanaging.

Read "Why Every Critical Project Needs a Steering Committee" for more details.

3. Project Manager

The Project Manager is the glue holding the day-to-day operations together. This individual:

> Plans and executes the project within scope, budget, and timeline.

> Manages the project team and ensures clear communication among stakeholders.

> Tracks progress against milestones and mitigates risks.

> Reports to both the Executive Sponsor and the Steering Committee.

A skilled Project Manager is the difference between a plan on paper and a tangible, successful outcome.

Read "Why Every Critical Project Needs a Dedicated Project Manager" for more details.

4. Board Supervision

The Board (or an equivalent supervisory body) provides the top-down oversight needed for critical projects. Their responsibilities include:

> Ensuring governance structures are functioning effectively.

> Monitoring compliance with organizational policies and regulations.

> Providing escalation paths for major risks or crises.

> Reviewing project performance and financials.

Their involvement ensures that even the highest levels of the organization remain informed and engaged.

Read "Why Every Critical Project Needs Board Supervision" for more details.

5. Independent Reviews

Unbiased assessments are crucial for complex projects. Independent reviewers are typically external experts or auditors tasked with:

> Assessing the project at key milestones for risks and alignment.

> Identifying issues that internal teams may overlook.

> Providing recommendations to strengthen delivery.

These reviews act as a reality check, ensuring the project remains viable and aligned with objectives.

Read "Why Every Critical Project Needs Independent Reviews" for more details.

In a Nutshell

A critical project’s success hinges on robust governance. By leveraging the complementary strengths of an Executive Sponsor, Steering Committee, Project Manager, Board Supervision, and Independent Reviews, organizations can drive projects with confidence. Remember, governance isn’t about bureaucracy—it’s about empowering the project to succeed while ensuring accountability at every level.

Next Steps

> If you need help with your critical project just schedule a 30 minute discovery call to explore how I can assist you by clicking here.

> My services include Technology Due Diligence, Business Case Reviews, Project Reviews, and Board Advisory.

Why Every Critical Project Needs Board Supervision

2025-01-15T10:00:00.000+01:00

Projects are like icebergs—what you see above the surface is just the tip. Below lies the complexity, risk, and opportunity that can sink your ship if ignored.

Too often, boards treat projects like black boxes, leaving management to deliver results without sufficient oversight. This hands-off approach might work for routine initiatives, but when it comes to critical projects—those with significant financial, strategic, or reputational implications—board supervision is not optional; it’s essential.

Here’s why your board must lean in and stay engaged with your most important projects.

1. The Stakes Are Sky-High

Critical projects often involve transformative change, whether it’s a large-scale technology overhaul, an M&A integration, or entering a new market. These aren’t just operational gambles—they are strategic bets that can define the company’s future.

Boards are responsible for the organization’s long-term success, which means they cannot afford to stay on the sidelines when big decisions are being made. Their oversight ensures that projects align with the company’s strategy, risk appetite, and ethical standards.

2. Risk: The Silent Killer

Every project comes with risks—delays, budget overruns, scope creep, or even outright failure. The larger and more critical the project, the more significant the fallout.

A board’s role is to ask tough questions:

> Are the risks properly identified and mitigated?

> What’s the worst-case scenario, and how prepared are we?

> Is there transparency in how risks are reported?

Without board-level scrutiny, blind spots can fester, turning manageable risks into full-blown crises.

3. Governance: A Core Responsibility

Good governance doesn’t stop at approving budgets or signing off on proposals. It extends to ensuring that the right structures, processes, and people are in place for successful project delivery.

Board members bring a wealth of experience from diverse industries. Their oversight helps to avoid groupthink and keeps management honest, especially when projects hit roadblocks. By stepping in as needed—without micromanaging—the board strengthens accountability across the organization.

4. Avoiding the “Sunk Cost Fallacy”

How often do companies double down on failing projects simply because they’ve invested too much to quit? It’s a psychological trap that even the most experienced executives can fall into.

Boards provide an external perspective that’s less emotionally tied to the project. They can objectively assess whether to pivot, persevere, or pull the plug. This prevents wasteful spending and reputational damage from dragging out doomed efforts.

5. Spotlight on Performance Metrics

What gets measured gets managed. Boards can ensure that meaningful KPIs are in place, not just for financial performance but also for project health. Are milestones being met? Is value being delivered as promised?

Regular updates to the board—ideally, as part of a structured governance framework—create a culture of accountability and help spot issues before they spiral out of control.

6. Culture and Change: The Human Factor

Critical projects often require significant shifts in company culture or operations. These transformations are not purely technical—they involve people.

Boards must ensure that change management strategies are robust and adequately resourced. Are employees engaged? Are communication efforts effective? Is leadership aligned?

Neglecting the human element is a surefire way to derail even the best-laid plans.

In a Nutshell

Critical projects are too important to leave solely in the hands of management. Board supervision ensures that strategic alignment, risk mitigation, governance, and accountability are upheld throughout the project lifecycle.

The board’s role is not to meddle but to elevate. By providing oversight, asking tough questions, and demanding transparency, boards help turn ambitious initiatives into sustainable successes.

Next Steps

> For a guide on what questions a board should ask read "10 Essential Questions Every Board Should Ask About Technology".

> If you need help with your critical project just schedule a 30 minute discovery call to explore how I can assist you by clicking here.

> My services include Technology Due Diligence, Business Case Reviews, Project Reviews, and Board Advisory.

Why Every Critical Project Needs Independent Reviews

2025-01-14T07:00:00.001+01:00

"Trust, but verify." That timeless adage applies as much to critical projects as it does to diplomacy. Without an independent review, even the best-run projects can veer off course, leaving organizations blindsided by delays, cost overruns, or outright failures.

Here’s the uncomfortable truth: internal stakeholders are often too close to the project to see the cracks—or too invested to admit they exist. An independent review provides the unbiased perspective every critical project needs to succeed.

But timing matters. Independent reviews are most effective when conducted at key stages throughout the project lifecycle. Here’s when they should happen—and why.

1. At the Start: Feasibility and Planning

The foundation of every successful project is built during the planning phase. An independent review at this stage ensures that the project is set up for success before resources are committed.

> Is the business case sound?

> Are objectives clear, realistic, and measurable?

> Are risks properly identified, and is mitigation built into the plan?

Catching flaws at this early stage saves time, money, and headaches down the line.

2. Before Major Milestones: Progress and Risk Checkpoints

As the project moves forward, independent reviews should be conducted before major milestones or decision points. These reviews evaluate whether the project is on track and whether adjustments are needed.

> Are timelines and budgets being met?

> Are deliverables aligning with stakeholder expectations?

> Are emerging risks being addressed effectively?

For example, in a large technology project, a review might occur before moving from design to development or from testing to deployment. These checkpoints provide an opportunity to pause, reflect, and course-correct.

3. During Critical Phases: High-Risk Periods

Certain phases of a project—such as implementation or change management—are inherently more complex and risk-prone. Conducting independent reviews during these high-stakes periods provides an extra layer of oversight.

> Are resources sufficient to meet demands?

> Are teams prepared to handle unexpected issues?

> Is communication effective across all stakeholders?

These reviews help ensure that pressure-filled moments don’t lead to costly mistakes.

4. At the End: Closure and Benefits Realization

When the project wraps up, an independent review assesses whether it achieved its intended goals and delivered the expected value.

> Did the project meet its objectives?

> Were benefits realized, and how are they being measured?

> What lessons can be applied to future initiatives?

This final review not only validates the project’s success but also captures insights to improve future efforts.

5. For Troubled Projects: Midstream Interventions

Not all projects go smoothly. If a project starts showing signs of distress—missed deadlines, escalating costs, or stakeholder dissatisfaction—an independent review can provide a much-needed reset.

> What’s causing the issues, and can they be resolved?

> Should the project pivot, or is it time to pull the plug?

> How can the remaining phases be salvaged or restructured?

These midstream interventions often save projects from complete failure, turning setbacks into opportunities for recovery.

In a Nutshell

Critical projects don’t just need managers, teams, and sponsors—they need a truth-teller at critical junctures. An independent review provides the objectivity, accountability, and expertise that internal reviews often lack, ensuring the project stays on track and delivers real value.

It’s not about distrust—it’s about diligence. Conduct reviews at the start, at major milestones, during critical phases, at closure, and whenever red flags appear. Without an independent review, projects risk becoming echo chambers, where minor issues snowball into catastrophic failures.

“An independent review isn’t about questioning your competence—it’s about safeguarding your success.”

Don’t gamble with your most important initiatives. Plan independent reviews at the right times, and turn risks into opportunities for excellence.

Next Steps

> For a detailed guide on independent project reviews read "The Project Review Model ™".

> If you need help with your critical project just schedule a 30 minute discovery call to explore how I can assist you by clicking here.

> My services include Technology Due Diligence, Business Case Reviews, Project Reviews, and Board Advisory.

Why Every Critical Project Needs an Executive Sponsor

2025-01-13T07:00:00.001+01:00

Launching a critical project without an executive sponsor is like sending a ship to sea without a captain—good luck steering through the storm.

Projects don’t fail because of bad intentions. They fail because of a lack of alignment, authority, and support.

That’s where the executive sponsor steps in—not just as a figurehead but as the driving force that ensures the project delivers value.

According to the Project Management Institute (PMI)'s 2018 Pulse of the Profession In-Depth Report, "1 in 4 organisations (26%) report that the primary cause of failed projects is inadequate sponsor support".

By contrast, "organisations with a higher percentage of projects that include actively engaged executive sponsors, report 40% more successful projects than those with a lower percentage of projects with actively engaged sponsors".

And according to the 2015 Annual Review of Projects of the UKs National Audit Office “the effectiveness of the project sponsor is the best single predictor of project success or failure”.

If your organization treats executive sponsorship as optional, it’s time to rethink that approach.

Here’s why every critical project needs one.

1. Setting the Tone from the Top

Projects live and die on the strength of organizational commitment. An executive sponsor ensures the project gets the visibility and priority it needs across all levels.

> They communicate the strategic importance of the project to stakeholders.

> They create a sense of urgency and purpose.

> They set the cultural tone, emphasizing accountability and excellence.

Without this top-down push, projects often languish as “just another initiative.”

2. Clearing the Path

Projects hit roadblocks—it’s inevitable. Executive sponsors have the clout to remove them.

> Is another department dragging its feet? The sponsor can escalate and resolve conflicts.

> Are resources tight? They can unlock funding or allocate top talent.

> Are priorities misaligned? The sponsor aligns leadership to keep everyone rowing in the same direction.

When bureaucracy threatens progress, the executive sponsor cuts through the noise.

3. The Shield Against Scope Creep

Scope creep is the silent killer of critical projects. It turns well-defined goals into moving targets, leading to missed deadlines and bloated budgets.

An effective executive sponsor protects the project from:

> Endless “nice-to-haves” that dilute focus.

> Stakeholders with competing agendas.

> Management pressure to overcommit.

They ensure the project stays laser-focused on its objectives and delivers maximum value.

4. Connecting Strategy to Execution

A critical project isn’t just about hitting milestones; it’s about achieving strategic goals. Executive sponsors bridge the gap between the boardroom and the project team.

> They articulate how the project aligns with organizational objectives.

> They ensure KPIs reflect not just operational success but strategic impact.

> They maintain a long-term view, balancing short-term wins with sustained value creation.

Without this alignment, projects risk delivering outputs that don’t translate into outcomes.

5. Championing Change

Every critical project involves change—new systems, processes, or ways of working. Executive sponsors are the face of that change.

> They build trust and credibility among stakeholders.

> They manage resistance by engaging key influencers early.

> They ensure that the change is communicated effectively and consistently.

In short, they turn skeptics into supporters and ensure the organization is ready to embrace the project’s outcomes.

6. Accountability: The Buck Stops Here

A project without an executive sponsor often lacks a true sense of ownership. The sponsor serves as the ultimate accountability figure—answering to the board, the C-suite, and stakeholders.

Their presence signals that the project matters and that someone with authority is watching closely. This drives focus, discipline, and urgency across the team.

In a Nutshell

A critical project without an executive sponsor is a ship without a captain, rudderless and vulnerable to the waves of organizational politics, resource constraints, and shifting priorities.

An executive sponsor doesn’t just oversee a project—they champion it, protect it, and ensure it delivers value.

If your project truly matters, don’t let it drift. Secure an executive sponsor who will navigate it to success.

Next Steps

> For a detailed guide on how to play the role of an executive sponsor effectively read "The Vital Role of an Executive Project Sponsor and How to Play It".

> If you need help with your critical project just schedule a 30 minute discovery call to explore how I can assist you by clicking here.

> My services include Technology Due Diligence, Business Case Reviews, Project Reviews, and Board Advisory.

Why Every Critical Project Needs a Dedicated Project Manager

2025-01-12T08:00:00.001+01:00

Far too often, organizations assign critical projects to people who already have full-time roles or, worse, delegate management to a loosely organized team with no single point of accountability. The results? Missed deadlines, blown budgets, and a whole lot of finger-pointing.

Here’s the hard truth: if the project is important, it deserves a dedicated project manager. Period.

1. One Throat to Choke

In any critical initiative, clear accountability is non-negotiable. A dedicated project manager becomes the single point of responsibility.

> Who ensures deadlines are met?

> Who monitors budget burn and course-corrects as needed?

> Who communicates risks and progress to stakeholders?

Without someone owning the project, these tasks fall through the cracks, leaving chaos in their wake. A dedicated PM ensures that doesn’t happen—they are the glue holding everything together.

2. Master of Orchestration

Critical projects are complex beasts involving multiple teams, technologies, and timelines. Expecting subject matter experts or executives to handle this is a recipe for disaster.

A project manager is the conductor of this orchestra, ensuring that every player is in sync and hitting the right notes. They:

> Coordinate cross-functional teams.

> Identify dependencies and resolve bottlenecks.

> Keep everyone aligned on goals, deliverables, and deadlines.

Without a conductor, the music stops.

3. Risk Radar

Every project has risks, but critical projects often face landmines—unforeseen delays, resource shortages, or stakeholder disagreements. A skilled project manager is like a radar operator, constantly scanning for risks and taking preemptive action.

They:

> Create and maintain a risk register.

> Implement mitigation strategies.

> Keep leadership informed so there are no surprises.

Ignoring risks doesn’t make them go away. A dedicated PM ensures risks are managed, not swept under the rug.

4. Keeping the Big Picture in Focus

It’s easy for teams to get lost in the weeds—focusing on minor details while losing sight of strategic goals. A project manager ensures that doesn’t happen.

They keep the project aligned with its intended purpose by:

> Regularly reviewing objectives and deliverables.

> Communicating progress to stakeholders.

> Pushing back on scope creep that threatens to derail timelines and budgets.

Without this guiding hand, projects can meander off course and fail to deliver value.

5. The Art of Stakeholder Management

Critical projects come with high stakes and even higher expectations. A project manager is the diplomat who manages stakeholders—balancing priorities, resolving conflicts, and ensuring that everyone stays informed.

Their ability to manage up (executives) and down (project teams) keeps the project running smoothly. Without this role, miscommunications multiply, frustrations grow, and confidence erodes.

6. Driving Results, Not Excuses

When someone’s primary responsibility is project delivery, there’s no room for excuses. A dedicated project manager has skin in the game—they live and breathe the project.

They:

> Track progress relentlessly.

> Celebrate wins and address failures constructively.

> Push teams to deliver on time and within scope.

This relentless focus on results sets a dedicated PM apart from someone juggling project management alongside other responsibilities.

In a Nutshell

Critical projects are too important to leave to chance. A dedicated project manager provides the focus, accountability, and expertise needed to turn ambitious goals into tangible outcomes.

They’re not just a “nice-to-have” but a strategic imperative. Without one, your project risks becoming another statistic in the annals of failure.

Or as the saying goes: “If everyone is responsible, no one is accountable.”

Don’t gamble with your most important projects. Put a professional at the helm—a dedicated project manager will ensure you cross the finish line with confidence.

Next Steps

> For a detailed guide on how to select the right project manager for your critical project read "How To Select a Good Project Manager for Your Large and Complex Transformation Project".

> If you need help with your critical project just schedule a 30 minute discovery call to explore how I can assist you by clicking here.

> My services include Technology Due Diligence, Business Case Reviews, Project Reviews, and Board Advisory.

Case Study 21: The Australian Securities Exchange (ASX) $250 Million CHESS Blunder

2025-01-06T15:06:00.005+01:00

The Australian Securities Exchange (ASX) embarked on an ambitious journey to replace its 25-year-old Clearing House Electronic Subregister System (CHESS) with a state-of-the-art, blockchain-based platform.

Initially envisioned as a groundbreaking project to enhance efficiency, security, and scalability, the CHESS replacement project quickly turned into a cautionary tale.

The initiative faced repeated delays and escalating costs before its ultimate suspension in November 2022. Stakeholders, including market participants and regulators, expressed frustration with the project's mismanagement, questioning the feasibility of such ambitious undertakings.

Despite being heralded as a world-first use of distributed ledger technology (DLT) in a financial market, the ASX's CHESS replacement project encountered numerous challenges. The ripple effects of the failure impacted Australia's financial ecosystem, as trust in ASX's ability to manage critical infrastructure took a significant hit. This case study examines the series of missteps, governance issues, and technological challenges that led to the demise of one of the most ambitious financial infrastructure projects of its time.

In total, the project's failure has been projected to cost the ASX and its stakeholders upwards of AUD 250 million in direct expenses, with additional indirect costs stemming from lost time, diminished trust, and delayed market enhancements. ASIC Chair Joe Longo described the situation as "a watershed moment for governance in financial infrastructure." The failure also dealt a blow to the broader narrative around blockchain's transformative potential in finance. This detailed case study highlights the lessons other organizations can learn from the ASX’s missteps.

Background

The Clearing House Electronic Subregister System (CHESS) has served as the backbone of Australia's financial market infrastructure since 1994. Operating as the primary platform for clearing, settlement, and record-keeping of share transactions, CHESS has been critical to ensuring the efficiency and integrity of the market. However, as financial markets grew more complex, the aging CHESS system began to show limitations, including scalability issues and difficulty integrating with modern technologies.

In 2015, ASX initiated a strategic review of its market infrastructure. The review highlighted the need for a modern system that could support increased trading volumes, enhanced data capabilities, and real-time reporting. Blockchain technology emerged as an appealing solution, promising transparency, immutability, and efficiency. ASX partnered with Digital Asset, a New York-based fintech firm specializing in distributed ledger technology, to design and implement the new system. ASX CEO Dominic Stevens stated at the time: "Blockchain technology offers unprecedented opportunities to transform the way markets operate."

Stakeholders initially greeted the project with optimism. ASX promised significant benefits, including reduced reconciliation processes, enhanced market efficiency, and lower operational costs. The project was envisioned to be completed by 2020, with a transparent and collaborative approach involving market participants and regulators. However, these early promises soon gave way to skepticism as challenges mounted.

The scope of the project extended far beyond simply replicating the functionalities of CHESS. It sought to reimagine the entire post-trade process, embedding blockchain technology into critical financial infrastructure. This level of ambition introduced complexity, requiring extensive customizations, thorough testing, and close coordination among stakeholders. The ambitious scope, combined with technological and governance challenges, sowed the seeds of its eventual failure.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

2015: Strategic Review and Vision

ASX began a review of its aging CHESS infrastructure to identify a replacement. Blockchain technology was identified as a promising solution, leading to the selection of Digital Asset as the primary technology partner.

2017: Project Announcement

ASX formally announced the CHESS replacement project, promising implementation by 2020 and widespread benefits for market participants. Initial enthusiasm was tempered by questions about blockchain's suitability for such a critical system. Market analyst Sarah Klein noted, "The industry was excited but cautious about the risks of untested technology."

2018: Early Development and Testing

Development efforts commenced, with ASX emphasizing collaboration with industry participants. Early testing revealed scalability issues, prompting adjustments to project timelines.

2020: First Delays Announced

The COVID-19 pandemic disrupted timelines, with ASX announcing a revised implementation date of 2022. Stakeholders raised concerns about insufficient transparency in the project's progress.

2021: Mounting Challenges

Reports surfaced that Digital Asset’s blockchain platform struggled to meet performance benchmarks. Additional delays were announced, pushing the go-live date to 2023. ASX cited the complexity of integrating blockchain technology into existing workflows. "The timelines were ambitious from the outset," said finance professor Alan Morrison.

2022: Project Suspension

An independent review commissioned by ASX highlighted significant gaps in project management and governance. ASX officially suspended the project after further testing revealed that the platform was not fit for purpose. The total sunk cost reached AUD 250 million. Former ASX Chair Helen Lofthouse acknowledged, "This outcome is deeply disappointing and a stark reminder of the need for governance at every level."

What Went Wrong?

Underestimation of Complexity

ASX underestimated the technical and operational complexities of integrating blockchain technology into critical market infrastructure. Blockchain, while promising, required significant adaptations to meet the high-performance standards of financial markets.

Early limited feasibility studies failed to fully capture these challenges, leading to overconfidence in project timelines and deliverables. As technology consultant Mark Connors noted, "Blockchain was treated as a silver bullet without fully understanding the nuances of its integration."

This lack of understanding was evident in scalability tests that revealed major bottlenecks. Developers struggled to balance the decentralized nature of blockchain with the speed and efficiency demands of financial transactions. These challenges were compounded by the need to integrate the new system with legacy infrastructure.

Stakeholder Misalignment

The project suffered from inadequate communication and alignment with key stakeholders. Market participants expressed frustration over a lack of transparency and insufficient opportunities to provide input. "The ASX’s approach alienated many of us," said James Porter, a broker with over 20 years of experience. "We felt sidelined during critical phases of the project."

As a result, critical operational needs were overlooked, further complicating the implementation process. This misalignment created friction between ASX and its stakeholders, eroding trust and delaying progress.

Over-Reliance on Emerging Technology

Blockchain technology, though innovative, was still in its infancy when ASX committed to the project. Relying on an unproven technology for such a critical system introduced significant risks, including performance bottlenecks and integration challenges. "The decision to go all-in on blockchain was premature," said independent analyst Fiona Wong. "The technology wasn’t ready for the scale required."

Insufficient Risk Management

ASX failed to implement robust risk management practices, particularly in identifying and mitigating risks associated with scalability and performance. Testing protocols revealed issues late in the development cycle, compounding delays and costs. "By the time problems were identified, it was often too late to course-correct," observed consultant Ethan Harris.

Governance and Oversight Failures

Weak governance structures allowed issues to persist unaddressed. The independent review commissioned in 2022 highlighted a lack of clear accountability and ineffective oversight mechanisms. Decision-making processes were often slow and reactive, exacerbating project delays. ASIC Chair Joe Longo remarked, "Governance failures were at the heart of this project’s downfall."

Limited Independent Assurance

EY, contracted to provide assurance over the CHESS replacement project, failed to identify and escalate critical risks early in the development cycle. Their reviews often focused on procedural compliance rather than probing the feasibility and scalability of the proposed solution.

"Assurance without substantive scrutiny is a missed safeguard," said corporate governance expert Dr. Olivia Marks. The absence of deeper interrogation into the project's technical risks meant that systemic issues, such as blockchain's scalability challenges, were not flagged until significant resources had already been spent.

Reliance on a Single Supplier

ASX’s decision to rely exclusively on Digital Asset as the sole technology provider created significant dependencies and risks. With no alternative suppliers in place, ASX was unable to pivot when Digital Asset’s blockchain solution encountered performance and scalability issues.

"Diversity in supplier relationships is critical for mitigating risks," said IT procurement specialist Andrew Carter. The lack of competitive bidding also limited opportunities for ASX to benchmark costs or explore other technical solutions that might have been more suited to the scale and complexity of the CHESS replacement.

How ASX Could Have Done Things Differently

Conducting Comprehensive Feasibility Studies with Pilot Testing

ASX could have invested more time in understanding the practical implications of implementing blockchain technology at scale. Comprehensive feasibility studies combined with phased pilot testing would have provided crucial insights into technical and operational hurdles.

Diversifying Supplier Relationships

Relying on a single supplier limited ASX’s ability to pivot when issues with Digital Asset arose. Engaging multiple suppliers would have introduced healthy competition, fostered innovation, and mitigated the risks of over-dependence.

IT procurement specialist Andrew Carter noted, "Supplier diversity is key to building resilient systems. It ensures flexibility and access to alternative solutions when challenges emerge." A multi-vendor approach could have provided ASX with backup options during critical phases.

Enhancing Stakeholder Engagement

Throughout the CHESS replacement project, communication gaps between ASX and its stakeholders contributed to misaligned expectations and operational oversights. Greater stakeholder involvement, particularly from brokers and institutional investors, would have ensured that the system's design aligned with real-world needs. Regular workshops, feedback loops, and transparency around project milestones would have also helped build trust and resolve conflicts early.

James Porter, a veteran broker, emphasized, "Early and consistent engagement would have made a world of difference. We felt sidelined, which only added to frustrations as issues emerged." Greater collaboration would have ensured that critical user requirements were accounted for, reducing resistance and easing eventual adoption.

Establishing Independent Project Assessments

ASX could have benefited from appointing an independent body with the expertise and authority to oversee the project. This body should have had the remit to assess technical decisions, validate risk mitigation strategies, and ensure accountability across all project phases. Independent oversight helps flag early warning signs, provide actionable recommendations, and maintain transparency with regulators and stakeholders.

Dr. Olivia Marks, a corporate governance expert, noted, "Independent assessments bring objectivity and rigor to complex projects. They can challenge assumptions and prevent tunnel vision among project leaders." A well-structured independent review process would have provided additional scrutiny, particularly during critical milestones like vendor selection and scalability testing.

Strengthening Governance and Oversight

Effective governance structures are critical for large-scale projects like the CHESS replacement. ASX's governance approach, described as reactive and fragmented, left key risks unaddressed for too long. Strengthening governance frameworks with clear accountability, decision-making protocols, and escalation mechanisms could have prevented many of the delays and inefficiencies observed.

ASIC Chair Joe Longo remarked, "Proactive oversight and clear accountability are essential in projects of this magnitude. Weak governance structures create an environment where small issues can snowball into systemic failures." Implementing a robust governance framework would have fostered better coordination among teams, enabling timely responses to challenges.

Closing Thoughts

The failure of ASX’s CHESS replacement project serves as a sobering reminder of the complexities and risks involved in large-scale technological transformations. While blockchain technology holds significant potential, its integration into critical infrastructure demands rigorous planning, stakeholder alignment, and adaptive management.

This case illustrates the importance of balancing ambition with practical execution. Organizations must ensure that emerging technologies are validated through thorough testing and phased implementation before full-scale deployment. Equally crucial is the need for robust governance structures, transparent communication, and independent oversight to mitigate risks and ensure accountability.

The lessons from ASX’s experience resonate across industries undergoing digital transformation. By embracing a disciplined and collaborative approach, organizations can unlock the transformative potential of technology while safeguarding against avoidable failures.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> "ASX Abandons CHESS Replacement Project," Financial Times, 2022.

> "Independent Review of the ASX CHESS Replacement Project," Accenture, 2022.

> "EY CHESS Assurance Program Review," 2022-2024.

> "Special Report on CHESS Replacement," 2023.

> "Statutory Inquiry into ASIC and CHESS," 2024.

> "Challenges in Blockchain Adoption for Financial Systems," CIO Magazine, 2022. [https://www.cio.com]

> "Lessons from ERP and Blockchain Failures," TechRepublic, 2023.

When $100 Million Technology Projects Fail, It’s the Board’s Fault—Every Single Time

2025-01-02T11:22:00.000+01:00

In Switzerland, rumors suggest that both Bank Julius Bär and Raiffeisen Schweiz are grappling with failed technology projects, each costing over $100 million so far. Bank Julius Bär is reportedly trying to replace its existing core banking system for the Swiss booking center with Temenos, while Raiffeisen Schweiz is attempting to build a modern e-banking app.

Both organizations have allegedly hired third parties to review what went wrong and determine who’s to blame. While learning from failure and engaging external reviewers is sensible, the question of blame should already be crystal clear.

When a multi-million-dollar technology project collapses under its own weight—costing shareholders, employees, and stakeholders dearly—there’s no escaping the brutal truth: the fault lies squarely with the board.

You can explore my 20+ technology project failure case studies. Without exception, the boards involved failed to fulfill their responsibilities.

The Board’s Job Is Oversight, Not Rubber-Stamping

Boards exist to govern. They approve strategy, allocate resources, and oversee risks. They are not passive observers—they are active stewards of an organization’s success. Yet in failed projects, it’s evident that many boards sleepwalk through their responsibilities. They fail to ask tough questions early, challenge overly optimistic assumptions, or ensure mechanisms are in place to detect and address problems before it’s too late.

A board’s oversight role is not ceremonial. If a project spirals into disaster, the board either ignored the warning signs, delegated oversight to those ill-equipped for the job, or worse, never bothered to establish adequate checks in the first place.

If a board lacks the expertise to fulfill its duties, it must seek external help. This could mean forming an advisory board with independent specialists or adding a temporary board member with the requisite expertise and experience.

Failing Is Acceptable; Failing Late Is Not

Failure is a natural part of innovation and growth. No board can eliminate risk entirely—nor should they try. But there’s a monumental difference between failing fast and failing late.

Early failure allows a company to pivot, salvage resources, and preserve credibility. Late failure, on the other hand, is catastrophic. It burns cash, destroys morale, and erodes stakeholder trust.

Boards must demand stage-gated project governance that clearly delineates when to proceed, pivot, or pull the plug. If a multi-million-dollar project reaches the point of no return before its inevitable demise, the board has failed in its primary responsibility—to safeguard the organization from reckless escalation.

Why Boards Get It Wrong

So why do boards allow projects to go off the rails? Common reasons include:

> Blind Faith in Leadership: Boards often rely too heavily on the CEO or project sponsor’s assurances. Trust is important, but blind faith is a recipe for disaster. A board’s role is to verify, not just trust.

> Lack of Expertise: Some boards lack the technical or industry-specific knowledge to challenge assumptions. Instead of addressing this gap, they defer to management, undermining their oversight role.

> Cognitive Biases: Boards are just as susceptible to biases as anyone else. The sunk cost fallacy, groupthink, and overconfidence often lead boards to double down on failing projects instead of cutting losses.

> Weak Governance Processes: Many boards fail to establish robust governance frameworks for major projects. Without clear accountability, transparency, and regular checkpoints, projects are allowed to drift toward failure.

The Path to Accountability

To prevent future multi-million-dollar disasters, boards must:

> Ask Hard Questions Early: Why are we doing this? What are the critical assumptions? What would make us stop? These questions must be asked before a single dollar is spent.

> Insist on Independent Assurance: Boards should mandate independent audits and reviews for major projects. An objective view can often identify risks that insiders miss.

> Monitor Progress Ruthlessly: Quarterly updates are not enough. Boards must demand real-time reporting on key metrics and intervene when milestones are missed.

> Be Willing to Pull the Plug: The hardest decision for any board is to stop a failing project. But it’s also the most responsible one. Better to write off millions now than to lose billions later.

In a Nutshell

When a multi-million-dollar project fails, the board cannot claim ignorance or absolve itself of responsibility. Failure at this scale is a governance failure, plain and simple. Boards that tolerate late-stage disasters are not just failing the organization—they’re failing every stakeholder who placed their trust in them.

The lesson is simple: you can fail, but not that late. Boards must act as the last line of defense, ensuring that failure—when it happens—is swift, contained, and instructive. Anything less is negligence.

If you or your company needs help with Board Advisory around technology and project governance or an Independent Project Review, just contact me.

10 Essential Questions Every Board Should Ask About Technology

2024-12-16T12:04:00.009+01:00

Board members play an important role in steering organizations through the complexities of technology initiatives.

To fulfil this role effectively, it's essential to ask the right questions that probe the strategic, operational, and risk aspects of technology projects.

Here are ten critical questions every board should consider:

1) How does this technology initiative align with our strategic goals?

Understanding the connection between technology projects and the organization's mission ensures that investments support long-term objectives.

See "Do Your Projects and Initiatives Support Your Strategy?" for a detailed explanation on how to do this.

2) What are the expected benefits and how will we measure success?

Clarify the anticipated outcomes and establish metrics to assess the project's impact on the organization.

See the "Project Success Model" for a detailed explanation on how to do this.

3) What are the major risks and how are we mitigating them?

Identify potential challenges, including cybersecurity threats and compliance issues, and evaluate the strategies in place to address them.

See "Proactively Manage Your Project With RAID Lists (Risks, Assumptions, Issues and Decisions)" for a detailed explanation on how to do this.

4) How are we ensuring data security and privacy?

Assess the measures implemented to protect sensitive information and comply with relevant regulations.

5) What is the Total Cost of Ownership?

Consider not only initial expenses but also ongoing costs related to maintenance, training, and upgrades.

See "What Are the Real Costs of Your Technology Project?" for a detailed explanation on how to do this.

6) How will this impact our organizational culture and workforce?

Evaluate how the initiative will affect employees and what change management strategies are in place to support them.

See "User Enablement is Critical for Project Success" and "If You Want to Bring Change in Your Organization …" for further reading on these topics.

7) Are we leveraging the right expertise?

Determine whether internal capabilities are sufficient or if external consultants are necessary to achieve project success.

8) What is the implementation timeline and are we on track?

Review the project's timeline, milestones, and any deviations to ensure timely delivery.

See "A Great Leading Indicator for Future Trouble - Missing Milestones" for further reading on these topics.

9) How does this position us against competitors?

Analyze how the technology will enhance the organization's competitive edge in the market.

10) What is our plan for post-implementation evaluation?

Establish a process for assessing the project's success and lessons learned after completion.

See the "Project Success Model" for a detailed explanation on how to do this.

In a nutshell: By consistently addressing these questions, board members can provide informed oversight, ensuring that technology initiatives are strategically sound and effectively managed.

If you or your company needs help with Technology Due Diligence, Business Case Review or Board Advisory just contact me.

Case Study 20: The $4 Billion AI Failure of IBM Watson for Oncology

2024-12-07T11:43:00.006+01:00

In 2011, IBM’s Watson took the world by storm when it won the television game show Jeopardy!, showcasing the power of artificial intelligence (AI). Emboldened by this success, IBM sought to extend Watson’s capabilities beyond trivia to address real-world challenges.

Healthcare, with its complex data and critical decision-making needs, became a primary focus. Among its flagship initiatives was Watson for Oncology, a system designed to assist doctors in diagnosing and treating cancer through AI-driven insights.

Cancer treatment represents one of the most intricate and rapidly evolving domains in medicine. With over 18 million new cases diagnosed globally each year, oncologists face an overwhelming amount of medical literature, treatment protocols, and emerging research. Watson for Oncology aimed to address this challenge by analyzing vast amounts of data to recommend evidence-based treatment plans, all in a matter of seconds.

IBM marketed Watson for Oncology as a revolutionary tool that could bridge the gap between cutting-edge research and clinical practice. Its promise was to assist oncologists in identifying personalized treatment options for patients, thereby improving outcomes and reducing variability in care.

However, this ambitious vision quickly collided with the complex realities of cancer care, resulting in widespread criticism and eventual failure.

Background

At the start of the project it had five lofty objectives;

1) Streamlining Clinical Decision-Making: Watson for Oncology aimed to provide oncologists with AI-generated insights, synthesizing vast amounts of data into actionable treatment recommendations.

2) Bridging Knowledge Gaps: With the rapid pace of medical advancements, Watson sought to keep clinicians updated on the latest evidence, clinical trials, and treatment protocols.

3) Improving Patient Outcomes: The system was designed to support personalized care by tailoring treatment recommendations to each patient’s unique genetic and clinical profile.

4) Expanding Access to Expertise: IBM envisioned Watson as a tool to democratize high-quality oncology care, particularly in resource-limited settings where access to specialists is constrained.

5) Establishing Market Leadership: Beyond healthcare, IBM sought to position Watson as a leader in AI applications, demonstrating the transformative potential of cognitive computing.

The project was supported by partnerships with leading institutions like Memorial Sloan Kettering Cancer Center (MSKCC) to train Watson for Oncology.

The partnership aimed to imbue Watson with the expertise of MSKCC’s oncologists by feeding it clinical guidelines, peer-reviewed literature, and patient case histories. The AI would then analyze patient records and suggest ranked treatment options based on the latest evidence. It was envisioned as a tool that could augment oncologists' expertise, particularly in under-resourced settings.

IBM invested heavily in the project, pouring billions into Watson Health, which encompassed Watson for Oncology. The company acquired several firms specializing in healthcare data and analytics, including Truven Health Analytics and Merge Healthcare. These acquisitions were meant to enhance Watson’s capabilities by providing access to large datasets and advanced imaging tools.

Initial trials and pilots were conducted in countries like India and China, where disparities in healthcare resources presented an opportunity for Watson to make a meaningful impact. However, reports soon emerged that the AI’s recommendations were often inconsistent with local clinical practices. For example, Watson’s reliance on U.S.-centric guidelines made it difficult to implement in regions with differing treatment standards or drug availability.

By 2018, skepticism was growing. High-profile reports detailed instances where Watson provided inappropriate or even unsafe recommendations. These challenges, coupled with declining revenues for IBM Watson Health, culminated in the program’s discontinuation in 2023.

This case study examines how a project with such potential faltered, offering lessons for future ventures at the intersection of AI and healthcare.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

2011–2012: Watson's Post-Jeopardy! Evolution

Following its Jeopardy! success, IBM began exploring commercial applications for Watson, identifying healthcare as a priority. In 2012, IBM partnered with Memorial Sloan Kettering to develop Watson for Oncology, marking the start of an ambitious initiative.

2013: Initial Development and Training

Watson’s training began with curated data from MSKCC, including clinical guidelines and research publications. Early feedback highlighted challenges in teaching the system to interpret ambiguous or contradictory medical information.

2014: Pilot Testing at Memorial Sloan Kettering

MSKCC oncologists started testing Watson on hypothetical patient cases. Early results revealed gaps in the system’s knowledge and its tendency to offer impractical or unsafe recommendations, raising concerns about its readiness.

2015: Launch and Early Adoption

IBM officially launched Watson for Oncology with aggressive marketing campaigns. Hospitals in countries like Thailand, India, and South Korea signed adoption agreements, drawn by the promise of bringing world-class cancer care to underserved regions.

2016: Growing Skepticism Among Oncologists

Reports emerged of dissatisfaction among oncologists using Watson. Many found the system’s recommendations simplistic, biased toward MSKCC practices, and poorly adapted to local guidelines.

2017: Critical Media Coverage

Investigative reports revealed that some of Watson’s recommendations were based on hypothetical scenarios rather than real-world data. These revelations damaged IBM’s credibility and raised ethical questions about its marketing claims.

2018: Customer Contracts Cancelled

Major clients, including MD Anderson Cancer Center, ended their contracts with IBM, citing high costs and underwhelming results. IBM began scaling back its marketing efforts for Watson for Oncology.

2019: Internal Restructuring at IBM Watson Health

Facing declining revenues, IBM restructured its Watson Health division. Resources were redirected to other AI projects, and development on Watson for Oncology slowed significantly.

2021: Watson Health Division Sold

IBM announced the sale of its Watson Health assets to a private equity firm, effectively marking the end of its ambitions in AI-driven cancer care.

2023: Retrospective Studies Highlighting System Flaws

Postmortem analyses identified systemic issues, including poor data quality, inadequate clinical validation, and unrealistic timelines, as key factors in the project’s failure.

What Went Wrong?

Overreliance on Limited Training Data

Watson’s knowledge base was heavily influenced by MSKCC’s practices, leading to recommendations that often failed to align with local guidelines or real-world cases. This lack of diversity in training data undermined the system’s global applicability.

Unrealistic Marketing Claims

IBM’s aggressive marketing exaggerated Watson’s capabilities, creating unrealistic expectations among customers. When the system failed to deliver, trust eroded quickly.

Inadequate Physician Involvement

Oncologists reported that Watson’s interface was not user-friendly and often disrupted their workflow. Limited engagement with end-users during development contributed to these usability issues.

Lack of Adaptability to Local Contexts

Watson struggled to accommodate variations in healthcare systems, resource availability, and cultural practices. This rigidity limited its usefulness in diverse settings.

Ethical and Transparency Concerns

IBM’s use of hypothetical cases and selective data to demonstrate Watson’s capabilities raised ethical red flags. Customers felt misled by the lack of transparency.

How IBM Could Have Done Things Differently?

Broader and More Diverse Training Data

IBM could have partnered with multiple institutions worldwide to train Watson on a broader dataset, ensuring recommendations were evidence-based and applicable in varied contexts.

Iterative Development with Physician Feedback

By involving more oncologists in the design and testing process, IBM could have identified and resolved usability issues early on, ensuring the system met clinical needs.

Transparent Communication of Capabilities

IBM should have been more transparent about Watson’s limitations, focusing on incremental benefits rather than overhyping its transformative potential.

Emphasis on Local Adaptability

Developing a system that could integrate local guidelines and resource constraints would have made Watson more practical for global deployment.

Strengthened Ethical Oversight

IBM could have established an independent advisory board to review marketing claims, data usage, and clinical validation processes, building trust with stakeholders.

Closing Thoughts

The failure of IBM Watson for Oncology offers valuable lessons for AI projects in healthcare and beyond. It highlights the importance of realistic expectations, rigorous validation, and end-user involvement in developing and deploying AI solutions.

While IBM’s vision was ambitious, its execution fell short, underscoring the challenges of applying AI in complex, high-stakes domains. Moving forward, the healthcare industry must balance optimism about AI’s potential with a commitment to patient safety and ethical responsibility.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> IBM official press releases (2011–2021).

> Investigative reports from Stat News and The Wall Street Journal on Watson for Oncology’s challenges.

> Interviews with Memorial Sloan Kettering oncologists published in medical journals.

> Retrospective analyses in The Lancet Digital Health and JAMA Oncology.

> Public statements by IBM executives, including John Kelly III (SVP, IBM Research).

My Talk "Technology Due Diligence" @ Business Angels Switzerland

2024-12-05T13:11:00.006+01:00

Last week I was invited by Business Angels Switzerland to give a talk at their Academy about Technology Due Diligence.

The goal of the talk was to enable investors to determine the value and risks of technology in a startup or scaleup.

Many corporate executives share this challenge with startup investors.

Technology Due Diligence (TDD) is an essential part of any merger, acquisition, or IPO. And while the scope of a TDD in such an event is of course different than the scope of a TDD in context of a Series A Investment Round there are also many similarities.

That is why I wanted to share the recording of this talk with you.

You will find the video below or here.

A copy of the slides you can download here.

If you or your company needs help with a Technology Due Diligence just contact me.

And if you think I would be a good fit for speaking at your organisation have a look at my speaking page.

What others are saying ...

Henrico can simplify any AI/blockchain/IT topic, summarize it and extract the essence for investors to make proper technical due diligence. Well done! - Managing Director @ Reinhart Capital

Henrico Dolfing is a powerhouse in the startup world and a cornerstone of the Business Angels Switzerland community. As the mastermind behind multiple fascinating BAS Academies, he’s shaping how we think about investing. Add to that his sharp due diligence skills and engaging personality, and you’ve got someone who truly stands out. Grateful to have Henrico driving investments and being a great Business Angel. To top it all off, Henrico is a great speaker who brings clarity, insight, and a spark of wit to every presentation. - General Manager @ Business Angels Switzerland

Case Study 19: The $20 Billion Boeing 737 Max Disaster That Shook Aviation

2024-08-20T18:04:00.008+02:00

The Boeing 737 Max, once heralded as a triumph in aviation technology and efficiency, has since become synonymous with one of the most catastrophic failures in modern corporate history.

This case study delves deep into the intricacies of the Boeing 737 Max program—a project that was initially designed to sustain Boeing's dominance in the narrow-body aircraft market but instead resulted in two fatal crashes, the loss of 346 lives, and an unprecedented global grounding of an entire fleet.

Boeing's 737 series has long been a cornerstone of the company's commercial aircraft offerings. Since its inception in the late 1960s, the 737 has undergone numerous iterations, each improving upon its predecessor while maintaining the model's reputation for reliability and efficiency.

By the 2000s, the 737 had become the best-selling commercial aircraft in history, with airlines around the world relying on its performance for short and medium-haul flights.

However, by the early 2010s, Boeing faced significant competition from Airbus, particularly with the introduction of the Airbus A320neo. The A320neo offered superior fuel efficiency and lower operating costs, thanks to its state-of-the-art engines and aerodynamic enhancements.

In response, Boeing made the strategic decision to develop the 737 Max, an upgrade of the existing 737 platform that would incorporate similar fuel-efficient engines and other improvements to match the A320neo without necessitating extensive retraining of pilots.

Boeing's leadership was acutely aware that any requirement for significant additional training would increase costs for airlines and potentially drive them to choose Airbus instead.

The company selected the CFM International LEAP-1B engines for the 737 Max, which were larger and more fuel-efficient than those on previous 737 models.

However, this choice introduced significant engineering challenges, particularly related to the aircraft's aerodynamics and balance.

The Maneuvering Characteristics Augmentation System (MCAS) was developed as a solution to these challenges.

The system was designed to automatically adjust the aircraft's angle of attack in certain conditions to prevent stalling, thereby making the 737 Max handle similarly to older 737 models. This was intended to reassure airlines that their pilots could transition to the new model with minimal additional training.

As Dennis Muilenburg, Boeing’s CEO at the time, stated, "Our goal with the 737 Max was to offer a seamless transition for our customers, ensuring they could benefit from improved efficiency without significant operational disruptions".

The MCAS would later become central to the 737 Max's tragic failures.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

2011-2013: Project Inception and Initial Development

The 737 Max project was officially launched in 2011, with Boeing announcing that the aircraft would feature new engines, improved aerodynamics, and advanced avionics. The design and development process was marked by intense pressure to meet tight deadlines and to deliver a product that could quickly enter the market. By 2013, Boeing had completed the design phase, and the first test flights were scheduled for early 2016.

2016-2017: Certification and Commercial Launch

The first test flight of the 737 Max took place in January 2016, and the aircraft performed as expected under controlled conditions. The Federal Aviation Administration (FAA) granted the 737 Max its certification in March 2017, allowing it to enter commercial service. The aircraft was initially well-received by airlines, with thousands of orders placed within the first year of its launch.

October 29, 2018: Lion Air Flight JT610 Crash

Lion Air Flight JT610, a Boeing 737 Max traveling in Indonesia from Jakarta to Pangkal Pinang, crashes, killing all 189 passengers and crew on board. Questions quickly emerge over previous control problems related to the aircraft’s MCAS. This marks the first major incident involving the 737 Max, and it raises significant concerns about the safety of the aircraft.

March 1, 2019: Boeing’s Share Price Peaks

Boeing’s share price reaches $446, an all-time record, after the company reports $100 billion in annual revenues for the first time. This reflects investor confidence in Boeing’s financial performance, despite the recent Lion Air crash.

March 10, 2019: Ethiopian Airlines Flight ET302 Crash

Ethiopian Airlines Flight ET302, another Boeing 737 Max, crashes shortly after takeoff from Addis Ababa, Ethiopia, killing all 157 people on board. The circumstances of this crash are eerily similar to the Lion Air disaster, with the MCAS system again suspected to be a contributing factor. The crash leads to global scrutiny of the 737 Max’s safety.

March 14, 2019: Global Grounding of the 737 Max

U.S. President Donald Trump grounds the entire 737 Max fleet, following the lead of regulators in several other countries. This grounding is unprecedented in its scope, affecting airlines worldwide and marking a significant turning point in the crisis surrounding the 737 Max.

October 29, 2019: Muilenburg Testifies Before Congress

Boeing CEO Dennis Muilenburg is accused of supplying “flying coffins” to airlines during angry questioning by U.S. senators. His testimony is widely criticized, and his handling of the crisis further erodes confidence in Boeing’s leadership.

December 23, 2019: Muilenburg Fired

Boeing fires Dennis Muilenburg, appointing Chairman Dave Calhoun as the new Chief Executive Officer. This leadership change is seen as an attempt to restore confidence in Boeing and address the mounting crisis.

March 6, 2020: U.S. Congressional Report

A U.S. congressional report blames Boeing and regulators for the “tragic and avoidable” 737 Max crashes. The report highlights numerous failures in the design, certification, and regulatory oversight processes, and it calls for significant reforms in the aviation industry.

March 11, 2020: Boeing Borrows $14 Billion

Boeing borrows $14 billion from U.S. banks to navigate the financial strain caused by the grounding of the 737 Max and the emerging COVID-19 pandemic. This loan is later supplemented by another $25 billion in debt, underscoring the financial challenges Boeing faces.

March 18, 2020: Boeing Shares Plummet

Boeing shares hit $89, the lowest since early 2013, reflecting investor concerns about the company’s future amid the 737 Max crisis and the impact of the COVID-19 pandemic on global air travel.

April 29, 2020: Job Cuts Announced

Boeing announces the first wave of job cuts, planning to reduce its workforce by 10% in response to the pandemic-induced drop in air travel. This move is part of broader efforts to cut costs and stabilize the company’s finances.

September 2020: Manufacturing Flaws in the 787 Dreamliner

Manufacturing flaws are discovered in Boeing’s 787 Dreamliner, leading to the grounding of some jets. This adds to Boeing’s mounting challenges and further complicates its efforts to recover from the 737 Max crisis.

November 18, 2020: U.S. Regulator Approves 737 Max for Flight

The U.S. Federal Aviation Administration approves some 737 Max planes to fly again after Boeing implements necessary design and software changes. This marks a significant step in Boeing’s efforts to return the 737 Max to service.

January 8, 2021: Boeing Pays $2.5 Billion Settlement

Boeing agrees to pay $2.5 billion to resolve a criminal charge of misleading federal aviation regulators over the 737 Max. This settlement includes compensation for victims’ families, penalties, and payments to airlines affected by the grounding.

November 11, 2021: Boeing Admits Responsibility

Boeing admits full responsibility for the second Max crash in a legal agreement with victims’ families. This admission marks a significant acknowledgment of the company’s failures in the development and certification of the 737 Max.

What Went Wrong?

Flawed Engineering and Design Decisions

One of the most significant factors contributing to the failure of the 737 Max was the flawed design of the MCAS system. Boeing engineers decided to rely on a single AOA sensor to provide input to the MCAS, despite the known risks of sensor failure.

Traditionally, critical systems in aircraft design incorporate redundancy to ensure that a single point of failure does not lead to catastrophic consequences.

Boeing's decision to omit this redundancy was driven by the desire to avoid triggering additional pilot training requirements, which would have undermined the 737 Max's cost advantage.

The placement of the new, larger engines also altered the aircraft's aerodynamic profile, making it more prone to nose-up tendencies during certain flight conditions.

Instead of addressing this issue through structural changes to the aircraft, Boeing chose to implement the MCAS as a software solution. This decision, while expedient, introduced new risks that were not fully appreciated at the time.

"We were under immense pressure to deliver the Max on time and under budget, and this led to some compromises that, in hindsight, were catastrophic," admitted a senior Boeing engineer involved in the project

Inadequate Regulatory Oversight

The FAA's role in the 737 Max disaster has been widely criticized. The agency allowed Boeing to conduct much of the certification process itself, including the evaluation of the MCAS system. This arrangement, known as Organization Designation Authorization (ODA), was intended to streamline the certification process, but it also created a conflict of interest.

Boeing's engineers were under pressure to downplay the significance of the MCAS in order to avoid additional scrutiny from regulators.

"The relationship between the FAA and Boeing became too cozy, and this eroded the regulatory oversight that is supposed to keep the public safe," said Peter DeFazio, Chairman of the House Transportation and Infrastructure Committee

Corporate Culture and Leadership Failures

At the heart of the 737 Max crisis was a corporate culture that prioritized profitability and market share over safety and transparency.

Under the leadership of Dennis Muilenburg, Boeing was focused on delivering shareholder value, often at the expense of other considerations. This led to a culture where concerns about safety were dismissed or ignored, and where employees felt pressured to meet unrealistic deadlines.

Muilenburg's public statements after the crashes, where he repeatedly defended the safety of the 737 Max despite mounting evidence to the contrary, only further eroded trust in Boeing.

"There was a disconnect between the engineers on the ground and the executives in the boardroom, and this disconnect had tragic consequences," said John Hamilton, Boeing's former chief engineer for commercial airplanes

Communication Failures

Boeing's failure to adequately communicate the existence and functionality of the MCAS system to airlines and pilots was a critical factor in the two crashes. Pilots were not informed about the system or its potential impact on flight dynamics, which left them unprepared to handle a malfunction.

After the Lion Air crash, Boeing issued a bulletin to airlines outlining procedures for dealing with erroneous MCAS activation, but this was seen as too little, too late.

"It’s pretty asinine for them to put a system on an airplane and not tell the pilots who are operating it," said Captain Dennis Tajer of the Allied Pilots Association

Supply Chain and Production Pressures

The aggressive production schedule for the 737 Max also contributed to the project's failure. Boeing's management was determined to deliver the aircraft to customers as quickly as possible to fend off competition from Airbus.

This led to a "go, go, go" mentality, where deadlines were prioritized over safety considerations. Engineers were pushed to their limits, with some reporting that they were working at double the normal pace to meet production targets. This rush to market meant that there was less time for thorough testing and validation of the MCAS system and other critical components

Moreover, Boeing's decision to keep the 737 Max's design as similar as possible to previous 737 models was driven by the desire to reduce production costs and speed up certification. This decision, however, meant that the aircraft's design was pushed to its limits, resulting in an aircraft that was more prone to instability than previous models.

"We were trying to do too much with too little, and in the end, it cost lives," said an unnamed Boeing engineer involved in the project

Cost-Cutting Measures

Boeing's relentless focus on cost-cutting also played a significant role in the 737 Max's failure. The company made several decisions that compromised safety in order to keep costs down, such as relying on a single AOA sensor and not including an MCAS indicator light in the cockpit.

These decisions were made in the name of reducing the cost of the aircraft and avoiding additional pilot training, which would have increased costs for airlines. However, these cost-cutting measures ultimately made the aircraft less safe and contributed to the crashes of Lion Air Flight 610 and Ethiopian Airlines Flight 302

Organizational Failures

Boeing's organizational structure also contributed to the 737 Max's failure. The company's decision to move its headquarters from Seattle to Chicago in 2001 created a physical and cultural distance between the company's leadership and its engineers.

This move, coupled with the increasing focus on financial performance over engineering excellence, led to a breakdown in communication and decision-making within the company. Engineers felt that their concerns were not being heard by management, and decisions were made without a full understanding of the technical challenges involved.

"There was a sense that the leadership was more focused on the stock price than on building safe airplanes," said a former Boeing engineer

How Boeing Could Have Done Things Differently?

Prioritizing Safety Over Speed

One of the most significant ways Boeing could have avoided the 737 Max disaster was by prioritizing safety over speed. The company was under intense pressure to deliver the aircraft quickly to compete with Airbus, but this focus on speed led to critical safety oversights.

By taking more time to thoroughly test and validate the MCAS system and other components, Boeing could have identified and addressed the issues that ultimately led to the crashes.

"In hindsight, we should have taken more time to get it right, rather than rushing to meet deadlines," said Greg Smith, Boeing's Chief Financial Officer at the time

Incorporating Redundancy in Critical Systems

Another key change Boeing could have made was to incorporate redundancy in critical systems like the MCAS. Aviation safety protocols typically require multiple layers of redundancy to ensure that a single point of failure does not lead to catastrophe.

By relying on a single AOA sensor, Boeing violated this principle and left the aircraft vulnerable to sensor malfunctions. Including a second AOA sensor and ensuring that both sensors had to agree before the MCAS system activated could have prevented the erroneous activation of the system that caused the crashes.

"Redundancy is a fundamental principle of aviation safety, and it's one that we should have adhered to in the design of the 737 Max," said John Hamilton, Boeing's former chief engineer for commercial airplanes

Improving Communication and Transparency

Boeing could have also improved its communication and transparency with both regulators and airlines. The company's decision to downplay the significance of the MCAS system and not include it in the aircraft's flight manuals left pilots unprepared to deal with its activation.

By fully disclosing the system's capabilities and risks to the FAA and airlines, Boeing could have ensured that pilots were adequately trained to handle the system in the event of a malfunction.

"Transparency is key to building trust, and we failed in that regard with the 737 Max," said Dennis Muilenburg, Boeing's CEO at the time

Strengthening Regulatory Oversight

The FAA's delegation of much of the certification process to Boeing created a conflict of interest that contributed to the 737 Max's failure. By strengthening regulatory oversight and ensuring that the FAA maintained its independence in the certification process, the agency could have identified the risks associated with the MCAS system and required Boeing to address them before the aircraft entered service.

This would have provided an additional layer of scrutiny and ensured that safety was prioritized over speed and cost.

"The FAA's role is to be the independent watchdog of aviation safety, and we need to ensure that it has the resources and authority to fulfill that role effectively," said Peter DeFazio, Chairman of the House Transportation and Infrastructure Committee

Fostering a Safety-First Corporate Culture

Finally, Boeing could have fostered a corporate culture that prioritized safety over profitability. The company's increasing focus on financial performance and shareholder value led to a culture where safety concerns were often dismissed or ignored.

By emphasizing the importance of safety in its corporate values and decision-making processes, Boeing could have created an environment where engineers felt empowered to raise concerns and where those concerns were taken seriously by management.

"Safety needs to be the top priority in everything we do, and we lost sight of that with the 737 Max," said David Calhoun, who succeeded Dennis Muilenburg as Boeing's CEO in 2020

Closing Thoughts

The Boeing 737 Max disaster is a stark reminder of the consequences of prioritizing speed and cost over safety in the aviation industry. The two crashes that claimed the lives of 346 people were not the result of a single failure but rather a series of systemic issues, including flawed engineering decisions, inadequate regulatory oversight, and a corporate culture that valued profitability over safety.

These failures have had far-reaching consequences for Boeing, resulting in billions of dollars in losses, a damaged reputation, and a loss of trust among airlines, regulators, and the flying public.

Moving forward, it is crucial that both Boeing and the wider aviation industry learn from these mistakes.

This means prioritizing safety above all else, ensuring that critical systems are designed with redundancy, and maintaining transparency and communication with regulators and customers.

It also means fostering a corporate culture that values safety and empowers employees to speak up when they see potential risks.

If I look at the "accidents" that happened to Boeing employees that have spoken up it seems to be the opposite...

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> Cannon-Patron, S., Gourdet, S., Haneen, F., Medina, C., & Thompson, S. (2021). A Case Study of Management Shortcomings: Lessons from the B737-Max Aviation Accidents.

> Larcker, D. F., & Tayan, B. (2024). Boeing 737 MAX: Organizational Failures and Competitive Pressures. Stanford Graduate School of Business.

> Boeing Co. (2019). Investigation Report: The Design and Certification of the Boeing 737 Max.

> FAA. (2023). Examining Risk Management Failures: The Case of the Boeing 737 MAX Program.

> Enders, T. (2024). Airbus Approach to Safety and Innovation: A Response to the Boeing 737 MAX.

> Muilenburg, D. (2019). Boeing’s Commitment to Safety: A Public Statement.

> Gates, D., & Baker, M. (2019). The Inside Story of MCAS: How Boeing’s 737 MAX System Gained Power and Lost Safeguards. The Seattle Times.

> Tajer, D. (2019). Statement on MCAS and Pilot Awareness. Allied Pilots Association.

Lies, Damned Lies, and Statistics

2024-08-15T10:21:00.001+02:00

"Lies, damned lies, and statistics" is a phrase describing the persuasive power of statistics to bolster weak arguments.

It is also sometimes used to doubt the statistics used to prove an opponent's point.

Last night I watched a startup pitching and they presented a slide with some statistics showing the effectiveness of their solution to a particular problem, and the first thing that came to my mind was exactly this phrase.

In statistics, there are several techniques (sometimes referred to as "tricks") that can be used to manipulate data or present results in a way that supports a particular point of view.

While these methods can be used for legitimate analysis, they can also be misused to mislead or deceive.

When you validate a business case or investment opportunity you should be aware of these tricks, and that is why I collected the most common ones for you.

1. Cherry-Picking Data

Selecting only the data that supports a particular conclusion while ignoring data that contradicts it.

Example: A study might report only the time periods where a particular stock performed well, ignoring periods of poor performance.

2. P-Hacking

Manipulating data or testing multiple hypotheses until a statistically significant result is found, often by increasing the number of tests without proper correction.

Example: Running many different statistical tests on a dataset and only reporting the ones that give a p-value below 0.05.

3. Misleading Graphs

Presenting data in a graph with a misleading scale, axis manipulation, or selective data points to exaggerate or downplay trends.

Example: Using a y-axis that starts at a non-zero value to exaggerate differences between groups.

4. Overgeneralization

Drawing broad conclusions from a small or unrepresentative sample.

Example: Conducting a survey in one city and generalizing the results to the entire country.

5. Omitting the Baseline

Failing to provide a baseline or control group for comparison, making the results seem more significant than they are.

Example: Reporting that a treatment led to a 50% improvement without mentioning that a placebo led to a 45% improvement.

6. Selective Reporting of Outcomes

Reporting only positive outcomes while ignoring negative or neutral results.

Example: A drug trial that only reports the successful outcomes while ignoring cases where the drug had no effect or caused harm.

7. Data Dredging

Analyzing large volumes of data in search of any statistically significant relationship, often without a prior hypothesis.

Example: Examining multiple variables in a dataset until any two variables show a correlation, then presenting this as meaningful without further validation.

8. Ignoring Confounding Variables

Failing to account for variables that could influence the results, leading to spurious conclusions.

Example: Claiming that ice cream sales cause drowning deaths without accounting for the confounding variable of temperature (both increase during summer).

9. Manipulating the Sample Size

Choosing a sample size that is too small to detect an effect or too large, which may exaggerate the significance of minor effects.

Example: Conducting a survey with only a few participants and claiming the results are representative of the entire population.

10. Misinterpreting Statistical Significance

Confusing statistical significance with practical significance or misrepresenting what a p-value actually indicates.

Example: Claiming that a treatment is effective based on a p-value below 0.05 without discussing the actual effect size or its practical implications.

11. Simpson's Paradox

Aggregating data without considering subgroups, which can lead to contradictory conclusions when the data is disaggregated.

Example: A treatment might seem effective in the overall population but ineffective or even harmful when broken down by specific demographic groups.

12. Non-Comparative Metrics

Presenting data without proper context, such as not comparing it to a relevant benchmark.

Example: Reporting that a company’s profits increased by 20% without mentioning that its competitors increased by 50%.

13. Double Dipping

Using the same data twice in a way that inflates the significance of the findings.

Example: Reporting an outcome as both a primary and secondary result, thus artificially increasing the perceived importance of the data.

14. Using Relative vs. Absolute Risk

Emphasizing relative risk instead of absolute risk to make a finding seem more significant.

Example: Saying a drug reduces the risk of disease by 50% (relative risk) when the absolute risk reduction is from 2% to 1%.

These techniques can be powerful when used correctly, but they can also be deceptive if not used with care and transparency.

Ethical statistical practice involves full disclosure of methods, careful interpretation of results, and avoiding the intentional misuse of these tricks.

A Step-by-Step Guide to Business Case Validation

2024-08-13T15:05:00.006+02:00

Creating a business case is a systematic process designed to justify a proposed project, investment, or decision within a business context.

A strong business case typically includes an introduction with background information, a clear problem or opportunity statement, a detailed analysis of options, a risk assessment, a financial analysis, a proposed solution, and a high-level implementation plan.

But validating your business case is just as important as creating it.

The validation process is essential for confirming that the proposed initiative is likely to achieve its intended outcomes and align with organizational goals.

I have validated many business cases, both for my clients and as an active angel investor, and if there is one thing I have learned, it is the critical importance of ensuring that a business case is both robust and realistic before committing significant resources.

Over the years I have developed a structured approach that I want to share with you.

1) Review the Problem Statement or Opportunity

Clarity and Accuracy: Ensure the problem or opportunity is clearly articulated and well understood. Question whether the impact of not addressing the problem or missing the opportunity is accurately presented.

See my article "Understanding Your Problem Is Half the Solution (Actually the Most Important Half)" for some further reading on this topic.

2) Scrutinize Assumptions

Identify and Test Assumptions: List and validate assumptions related to market conditions, customer behavior, cost estimates, and revenue projections. Compare them with historical data and industry benchmarks to ensure they are realistic.

Scenario Analysis: Conduct best-case, worst-case, and most likely scenarios to test the sensitivity of the business case to changes in key assumptions.

3) Evaluate the Analysis of Options

Comprehensive Consideration: Ensure all reasonable options, including doing nothing, have been considered.

Verify Estimates and Projections: Ensure cost estimates are accurate and comprehensive, and validate revenue projections against market data and trends. Recalculate ROI and perform sensitivity analyses to assess the impact of changes in key variables.

Focus on Economic Benefits: In my opinion ALL benefits of a technology project should be expressed in dollars (or any other currency). To make estimating the benefits of a project easier and more realistic, I use a simple model to assess the economic benefits of a project. It consists of five benefit types (or buckets); Increased Revenue, Protected Revenue, Reduced Costs, Avoided Costs, and Positive Impacts.

Total Cost of Ownership (TCO): TCO is an analysis meant to uncover all the lifetime costs that follow from owning a solution. As a result, TCO is sometimes called 'life cycle cost analysis.' Never just look at the implementation or acquisition costs. Always consider TCO when looking at the costs of a solution.

Time Value of Money: The time to value (TTV) measures the length of time necessary to finish a project and start the realization of the benefits of the project. One project valuation method incorporating this concept is the payback period (PB). There is one problem with the payback period: It ignores the time value of money (TVM). That is why some project valuation methods include the TVM aspect. For example, internal rate of return (IRR) and net present value (NPV).

Unbiased Evaluation: Check if the criteria for evaluating options are relevant and unbiased, and consider whether alternative criteria might lead to different recommendations.

For more details on the financial valuations of your options have a look at my eBook The Project Valuation Model ™. You can download it for free here.

4) Examine the Proposed Solution

Feasibility: Assess whether the proposed solution is technically, financially, and operationally feasible, with realistic timelines.

Strategic Alignment: Verify that the solution aligns with the organization's broader strategic goals and represents the best value.

See my article "Do Your Projects and Initiatives Support Your Strategy?" for some further reading on the topic.

5) Engage Stakeholders

Involvement and Feedback: Engage key stakeholders, including executives and subject matter experts, to gather feedback and address concerns. Their support is critical to the project's success.

See my article "10 Principles of Stakeholder Engagement" for some further reading on the topic.

6) Perform a Risk Assessment

Comprehensive Risk Analysis: Review the risk assessment to ensure all significant risks are identified and properly analyzed. Evaluate the feasibility of risk mitigation strategies and ensure contingency plans are in place.

See my article "Risk Management Is Project Management for Adults" for some further reading on the topic.

7) Review Legal, Regulatory, and Ethical Considerations

Compliance and Ethics: Ensure the project complies with all relevant laws, regulations, and industry standards. Consider any environmental, social, and ethical implications.

8) Assess Market and Competitive Analysis

Market and Competitive Validation: Reassess market conditions and competitive responses to ensure the business case remains relevant and viable in the current environment.

9) Evaluate Implementation Feasibility

Resource and Timeline Viability: Confirm that the necessary resources are available and that the proposed timeline is realistic. Consider conducting a pilot to validate key aspects of the business case.

Opportunity Cost: If you implement the proposed solution, what other initiatives can't you do? Is it still worth it?

Cost of Delay: What does it cost me if I do the project slower or later? Is there urgency?

For more details on the opportunity costs, and cost of delay of your initiative have a look at my eBook The Project Valuation Model ™. You can download it for free here.

10) Seek Third-Party Review

External Validation: Consider an independent review by a third-party expert to provide objective insights and increase the credibility of the business case.

See for example my Independent Business Case Review service.

11) Final Review

Final Review: Ensure all sections of the business case are complete, coherent, and consistent. Revise as necessary based on the validation process.

Best Practices

Documentation: Keep a detailed record of validation steps, findings, and any revisions made to create a clear audit trail.

Stakeholder Engagement: Maintain clarity and avoid jargon to ensure understanding and buy-in from all stakeholders.

Data-Driven Analysis: Base your analysis and recommendations on solid data and evidence.

Constructive Approach: Focus on strengthening the business case rather than undermining it, using challenges to ensure the best possible outcome.

In a nutshell: Effective validation ensures that any weaknesses in the business case are addressed before committing significant resources, thereby reducing the risk of failure and increasing the likelihood of success.

If you are an executive sponsor, steering committee member, or a non-executive board member and want an unbiased expert view on your business case? Then my Independent Business Case Review is what you are looking for.

Top Ten Leading Indicators of Troubled Projects for Executives

2024-08-05T21:04:00.005+02:00

If you are a senior executive or a board member in the role of executive sponsor, project sponsor, or steering committee member it is key to recognize potential issues before they become critical.

Recognizing early warning signs can make the difference between a project’s success and failure.

Whilst lagging indicators are metrics that reflect past performance, leading indicators are metrics that predict future performance.

They provide early signs of what is likely to happen, helping you and your organization to make proactive decisions.

Here are the top ten leading indicators of project trouble that every executive should be aware of:

#1 Definition of Done

Project failure starts when you can’t tell what “done” looks like in any meaningful way. Without some agreement on your vision of “done,” you’ll never recognize it when it arrives, except when you’ve run out of time or money or both.

Constant changes in project requirements are a red flag and a leading indicator for trouble.

While some changes are inevitable, frequent and significant alterations indicate poor initial planning or external pressures.

Both will disrupt your timelines and budgets.

And if your scope gets reduced to meet budgets and timelines you can be sure your business case will be impacted as there will be less benefits.

#2 Definition of Success

A project can only be successful if its success criteria are defined and agreed upon. Therefore the lack of clear objectives is one of the earliest signs of trouble.

Every project has multiple success criteria related to business results, product/service results, and project delivery results (cost, schedule, scope, and quality).

Some criteria are absolute, meaning they must be completed on or before the original planned date, and some are relative, meaning they must be completed by a date acceptable to the client.

Project success is determined by how many of your success criteria are satisfied, and how well.

Whether or not a project is successful also depends on who you ask;

> The very happy project manager that implemented the SAP project as scoped on time and below budget (I know, this will NEVER happen).

> The end users who absolutely hate the complexity and slowness of the new system.

> The COO that has seen IT costs double whilst none of the expected savings materialized.

They may all have very different opinions on the success of the project.

Project success also depends on when you ask.

Twelve months after the go-live, the users will have a better grasp of the system and initial performance problems will have been solved. And slowly but steadily, the expected savings will often start to materialize as well.

So in order to define success of your project you should;

1) Define all the criteria relevant to your project.

2) Define how you will measure them.

3) Define when you will measure them.

The lack of these definitions is a great leading indicator for trouble.

#3 Financial Runway

The burn rate of a project is a lagging indicator as it describes how much money is spent (or lost) for any period of time.

The financial runway of a project refers to the length of time a project can continue to operate before it runs out of funding, based on its current expenditure rate.

It is a crucial leading indicator for executives, as it helps ensure that the project remains financially viable.

An example:

If a project has a total budget of $10 million and has already spent $4 million, the remaining Current Funding is $6 million.

If this project spends $500,000 per month, the monthly Burn Rate is $500,000.

The Financial Runway (in months) = Current Funding / Burn Rate = $6 million / $0.5 million = 12 months.

This means the project can continue to operate for 12 months before it runs out of funds, assuming the burn rate remains constant and no additional funding is received.

If the runway is shorter than your planned duration you know you are in for some trouble.

#4 Missing Milestones

Missing or achieving the deadline on a milestone is a lagging indicator. But it is also a leading indicator for future trouble.

Missing initial milestones or deadlines signal deeper issues. It might indicate that the project plan was unrealistic, there are problems with team productivity, or unforeseen obstacles are impacting progress.

And if missing milestones is combined with keeping the go-live date the same it rarely ends well for your project.

Unfortunately, I see it again and again. Multiple important milestones are missed. Sometimes by months. And the ones that are marked as completed have their original scope reduced.

For example system integration tests (SIT) without all interfaces being completed and no production like data.

Or user acceptance testing (UAT) with systems that are not ready or contain so many bugs that end-to-end testing is not possible.

Astonishing is that in most cases both the project sponsor and project manager seem to be convinced all is “green” and it will work out until the project folds like a house of cards.

When you look at a typical large system implementation project it is still largely implemented like a waterfall. This includes ERP systems, CRM systems, Core Banking, etc.

And this has not changed with the rise of software as a service (SaaS) offerings like Salesforce, SAP S/4HANA, Workday, etc.

Yes, the design and build phases are now iterative, but at a certain point your full solution needs to be tested end-to-end. This means one or more SIT phases and an UAT phase that includes all upstream and downstream systems and processes.

You also need time to fix all the findings of your testing, and to do re-testing. If you are lucky one cycle is enough. Usually it is not.

You also need to train all your users and your support teams on the new solution and processes. Ideally on a solution that actually works.

And when you are ready to go, you have a cutover phase from your old solution to your new solution.

So yes, you design and build iteratively, but the rest is still shaped like a waterfall.

And this means that if you miss important milestones and you don’t change the go-live date you will steal time from the very important phases that come at the end of such a project.

Starting these late phases without having completed the previous phase just does not make sense and will drive your test team and end users crazy.

Missing milestones does not mean your project team is doing a bad job, but they obviously underestimated the time it takes to do certain things.

Chances are this is a pattern that is repeated for the later phases of the project.

So you will probably need more time for these phases as planned. Not less.

In my experience there are only two probable outcomes of such projects:

1) They never go live

2) They go live too early

The latter can be even worse than the first.

#5 Issue Resolution Time

A very simple metric for determining the health of your project is the age of issues.

Issues are like fish; when they get old, they stink.

A sure sign of a lack of leadership and upcoming trouble is old issues or issues that take longer than necessary to resolve.

Issues are obstacles that get in the way of execution. It is the project manager’s role to resolve and eliminate these issues as quickly as possible regardless of the owner or the cause.

If the project owner cannot solve it (or doesn’t try) it is up to the executive sponsor and the steering committee.

If an issue stands in the way of executing project objectives or makes it difficult for project managers to perform, it’s your responsibility as an executive to resolve it.

If the project manager is the problem, it is also your responsibility to solve this.

Fix the root causes of problems and fix them early.

What you want to avoid is a form of collective project amnesia where issues come up and never get resolved.

Issues have a funny way of resurfacing when they don’t get resolved.

Old issues and/or issues that take too long to resolve are an indicator of poor leadership and a great leading indicator for trouble in the future.

#6 Risk Management

The presence or lack of risk management is a great leading indicator for the impact of negative surprises. Or as Tim Lister states it “Risk management is project management for adults”.

Effective risk management involves identifying, assessing, and mitigating risks.

Signs of trouble include a lack of a risk management plan, unidentified risks emerging frequently, or failure to address known risks adequately.

Poor risk management can, and usually will, lead to significant setbacks.

#7 Team Situation

Stability, quality, availability, and collaboration of your project team is a good leading indicator for trouble.

Stability: a high turnover rate among project team members will disrupt continuity and momentum. It often reflects broader issues such as poor project management, low morale, or inadequate support, which will compromise project success.

Availability: are all approved team positions staffed? If not, for how long have unstaffed positions been empty? Is the project manager constantly looking for new people to fill empty positions? Are the right people in the right roles? Are positions part-time staffed that should be full time staffed?

Quality: look at the skill set necessary to deliver the project: Does the team have these skills? Does the team have the necessary experience or are they learning on the job? Of course you should use your project to let juniors grow and learn, but you will need experience as well.

Collaboration: look at the project team’s relationships with other external groups and teams. How well do they work with the other teams and stakeholders? Are there any internal or external team conflicts or tensions that could disrupt the project? How long have they existed? How severe are they? Have there been attempts to resolve them? How did this go? Are there issues/opportunities the team isn't discussing because they're too uncomfortable?

#8 Stakeholder and Leadership Engagement

Successful projects depend on the active involvement of stakeholders and leadership.

Signs of trouble include stakeholders and leaders who are disengaged, unavailable for key meetings, or not providing necessary feedback.

Poor engagement, whether it’s informal or formal, is a red flag.

When your stakeholders and leaders do not care about your project, then why would anybody else?

#9 Progress Reports

Or better said, non-progress reports are a leading indicator for trouble.

Watermelon projects which come across as green on our project dashboards but are deep red on the inside seem to have a thing in common.

There’s minimal activity associated with it.

You don’t see tangible results, you don’t hear the organization talking about the project, the reports state the same activities over and over, the only meetings you are invited to are the monthly SteerCo meeting, and your project manager is avoiding you.

Without hard work a large project will not come to fruition. And hard work leaves trails.

The absence of these predict trouble.

#10 Gut Feeling

Trust your gut.

If your intuition is telling you that something is wrong, ask questions. Don’t stop until you get an answer that makes sense to you.

Ask the same question to multiple people close to the project. If you get conflicting answers you know something is not right.

If your project team, project manager, and your stakeholders all have a different opinion on the status and chances of success of your project, order an independent project review.

They are your best insurance against a multi million dollar failure.

Why Every Critical Project Needs a Steering Committee

2024-07-28T18:49:00.009+02:00

Critical projects are like Formula 1 races—you don’t just need a driver; you need a pit crew, strategists, and decision-makers ready to adapt in real time.

That’s your steering committee.

Big projects come with big risks, competing priorities, and high expectations. Without a steering committee, those challenges turn into roadblocks. Decisions get delayed, alignment falters, and the project risks becoming a directionless endeavor.

Here’s why every critical project needs a dedicated steering committee to guide it to the finish line.

1. Strategic Alignment on Steroids

A steering committee ensures that the project stays tied to the company’s strategic goals, even as circumstances evolve.

> Are business priorities shifting? The committee adapts the project to maintain relevance.

> Are there trade-offs to make? They ensure decisions align with the bigger picture.

Without this strategic oversight, projects risk becoming siloed efforts, delivering outputs that don’t move the organizational needle.

2. Fast, High-Impact Decision-Making

Critical projects face countless forks in the road—resource allocation, scope changes, and risk mitigations, to name a few. Waiting for executives to weigh in or leaving these decisions to overburdened project teams can grind progress to a halt.

The steering committee acts as the project’s decision engine.

> They approve key changes swiftly.

> They resolve conflicts between departments.

> They keep the project agile, not bogged down in red tape.

When every hour counts, having the right people in the room makes all the difference.

3. Accountability at All Levels

Let’s be honest: people are more likely to follow through when they know they’ll be held accountable. The steering committee creates a structured environment for:

> Project leaders to report progress transparently.

> Stakeholders to address risks and challenges proactively.

> Everyone involved to stay focused on outcomes, not just activities.

It’s not about micromanagement—it’s about creating a culture of accountability.

4. The Ultimate Risk Radar

Risk is a given in any critical project. The steering committee’s diverse expertise helps uncover and address risks that a single project team might miss.

> Financial risks? The CFO on the committee has it covered.

> Operational risks? The COO flags potential bottlenecks.

> Reputational risks? The marketing head ensures nothing falls through the cracks.

This collective vigilance creates a safety net, preventing small issues from snowballing into major crises.

5. A Shield for the Project Team

Project teams often get bogged down by competing demands and organizational politics. The steering committee acts as a buffer, shielding the team from distractions and interference.

> They settle disputes that could derail progress.

> They prioritize resources, so the project isn’t starved of what it needs.

> They back the project manager when tough calls need to be made.

With this support, the team can focus on execution, not firefighting.

6. Driving Stakeholder Engagement

Critical projects often impact multiple departments, each with its own interests and agendas. The steering committee brings these stakeholders together in one room, creating a forum for collaboration and alignment.

> They ensure everyone’s voice is heard.

> They prevent siloed thinking from derailing the project.

> They champion the project within their own spheres of influence.

This engagement isn’t just nice to have—it’s essential for driving buy-in and minimizing resistance.

In a Nutshell

A steering committee is the backbone of any critical project. It ensures strategic alignment, accelerates decision-making, manages risks, and provides the accountability and support needed for success.

It’s not about bureaucracy—it’s about leadership. Without a steering committee, your project is flying blind, at the mercy of organizational chaos and shifting priorities.

Or as one project veteran put it: “A great project team can execute, but a great steering committee ensures they’re executing the right things.”

If your project matters, give it the oversight it deserves. A strong steering committee isn’t just helpful—it’s indispensable.

Next Steps

> For a detailed guide on how to setup an effective steering committee read "How to Establish an Effective Steering Committee (And Not a Project Governance Board)".

> If you need help with your critical project just schedule a 30 minute discovery call to explore how I can assist you by clicking here.

> My services include Technology Due Diligence, Business Case Reviews, Project Reviews, and Board Advisory.

The Most Important Role on Any Large Transformation Project

2024-07-22T21:17:00.008+02:00

The most important role on a large transformation project is the project sponsor.

Not the project manager.

And according to the 2015 Annual Review of Projects of the UKs National Audit Office “the effectiveness of the project sponsor is the best single predictor of project success or failure”.

Project sponsors on large and complex multi million dollar transformation projects are often senior executives and most are not trained in any way to be successful in their executive sponsor role.

Nor do they take the time that is needed to execute this role.

Often the same is the case for the project steering committee members.

Guess what happens with these projects?

Case Study 18: How Excel Errors and Risk Oversights Cost JP Morgan $6 Billion

2024-07-02T17:31:00.016+02:00

In the spring of 2012, JP Morgan Chase & Co. faced one of the most significant financial debacles in recent history, known as the "London Whale" incident. The debacle resulted in losses amounting to approximately $6 billion, fundamentally shaking the confidence in the bank's risk management practices.

At the core of this catastrophe was the failure of the Synthetic Credit Portfolio Value at Risk (VaR) Model, a sophisticated financial tool intended to manage the risk associated with the bank's trading strategies.

The failure of the VaR model not only had severe financial repercussions but also led to intense scrutiny from regulators and the public. It highlighted the vulnerabilities within JP Morgan's risk management framework and underscored the potential dangers of relying heavily on quantitative models without adequate oversight.

This case study explores the intricacies of what went wrong and how such failures can be prevented in the future. By analyzing this incident, I seek to understand the systemic issues that contributed to the failure and to identify strategies that can mitigate similar risks in other financial institutions. The insights gleaned from this case are not just relevant to JP Morgan but to the broader financial industry, which increasingly depends on complex models to manage risk.

Background

The Synthetic Credit Portfolio (SCP) at JP Morgan was a part of the bank's Chief Investment Office (CIO), which managed the company's excess deposits through various investments, including credit derivatives. The SCP was specifically designed to hedge against credit risk by trading credit default swaps and other credit derivatives. The portfolio aimed to offset potential losses from the bank's other exposures, thereby stabilizing overall performance.

In 2011, JP Morgan developed the Synthetic Credit VaR Model to quantify and manage the risk associated with the SCP. The model was intended to provide a comprehensive measure of the potential losses the bank could face under various market conditions. This would enable the bank to make informed decisions about its trading strategies and risk exposures. The VaR model was implemented using a series of Excel spreadsheets, which were manually updated and managed.

Despite the sophistication of the model, its development was plagued by several critical issues. The model's architect lacked prior experience in developing VaR models, and the resources allocated to the project were inadequate. This led to a reliance on manual processes, increasing the risk of errors and inaccuracies. Furthermore, the model's implementation and monitoring were insufficiently rigorous, contributing to the eventual failure that led to massive financial losses.

The primary objective of JP Morgan's Synthetic Credit VaR Model was to provide an accurate and reliable measure of the risk associated with the bank's credit derivatives portfolio. This would enable the bank to manage its risk exposures effectively, ensuring that its trading strategies remained within acceptable limits. The model aimed to capture the potential losses under various market conditions, allowing the bank to make informed decisions about its investments.

In addition to the primary objective, the Synthetic Credit VaR Model was expected to provide a foundation for further advancements in the bank's risk management practices. By leveraging the insights gained from the model, JP Morgan hoped to develop more sophisticated tools and techniques for managing risk. This would enable the bank to stay ahead of emerging threats and maintain a competitive edge in the financial industry.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

Early 2011: Development of the Synthetic Credit VaR Model begins. The project is led by an individual with limited experience in developing VaR models. The model is built using Excel spreadsheets, which are manually updated and managed.

September 2011: The Synthetic Credit VaR Model is completed and implemented within the CIO. The model is intended to provide a comprehensive measure of the potential losses the bank could face under various market conditions.

January 2012: Increased trading activity in the SCP causes the CIO to exceed its stress loss risk limits. This breach continues for seven weeks. The bank informs the OCC of the ongoing breach, but no additional details are provided, and the matter is dropped.

March 23, 2012: Ina Drew, head of the CIO, orders a halt to SCP trading due to mounting concerns about the portfolio's risk exposure.

April 6, 2012: Bloomberg and the Wall Street Journal publish reports on the London Whale, revealing massive positions in credit derivatives held by Bruno Iksil and his team.

April 9, 2012: Thomas Curry becomes the 30th Comptroller of the Currency. Instead of planning for the upcoming 150th anniversary of the Office of the Comptroller of the Currency (OCC), Mr. Curry is confronted with the outbreak of news reports about the London Whale incident.

April 16, 2012: JP Morgan provides regulators with a presentation on SCP. The presentation states that the objective of the "Core Credit Book" since its inception in 2007 was to protect against a significant downturn in credit. However, internal reports indicate growing losses in the SCP.

May 4, 2012: JP Morgan reports SCP losses of $1.6 billion for the second quarter. The losses continue to grow rapidly even though active trading has stopped.

December 31, 2012: Total SCP losses reach $6.2 billion, marking one of the most significant financial debacles in the bank's history.

January 2013: The OCC issues a Cease and Desist Order against JP Morgan, directing the bank to correct deficiencies in its derivatives trading activity. The Federal Reserve issues a related Cease and Desist Order against JP Morgan's holding company.

September - October 2013: JP Morgan settles with regulators, paying $1.020 billion in penalties. The OCC levies a $300 million fine for inadequate oversight and governance, insufficient risk management processes, and other deficiencies.

What Went Wrong?

Model Development and Implementation Failures

The development of JP Morgan's Synthetic Credit VaR Model was marred by several critical issues. The model was built using Excel spreadsheets, which involved manual data entry and copying and pasting of data. This approach introduced significant potential for errors and inaccuracies. As noted in JP Morgan's internal report, "the spreadsheets ‘had to be completed manually, by a process of copying and pasting data from one spreadsheet to another’". This manual process was inherently risky, as even a minor error in data entry or formula could lead to significant discrepancies in the model's output.

Furthermore, the individual responsible for developing the model lacked prior experience in creating VaR models. This lack of expertise, combined with inadequate resources, resulted in a model that was not robust enough to handle the complexities of the bank's trading strategies. The internal report highlighted this issue: "The individual who was responsible for the model’s development had not previously developed or implemented a VaR model, and was also not provided sufficient support". This lack of support and expertise significantly compromised the quality and reliability of the model.

Insufficient Testing and Monitoring

The Model Review Group (MRG) did not conduct thorough testing of the new model. They relied on limited back-testing and did not compare results with the existing model. This lack of rigorous testing meant that potential issues and discrepancies were not identified and addressed before the model was implemented. The internal report criticized this approach: "The Model Review Group’s review of the new model was not as rigorous as it should have been". Without comprehensive testing, the model was not validated adequately, leading to unreliable risk assessments.

Moreover, the monitoring and oversight of the model's implementation were insufficient. The CIO risk management team played a passive role in the model's development, approval, implementation, and monitoring. They viewed themselves more as consumers of the model rather than as responsible for its development and operation. This passive approach resulted in inadequate quality control and frequent formula and code changes in the spreadsheets. The internal report noted, "Data were uploaded manually without sufficient quality control. Spreadsheet-based calculations were conducted with insufficient controls and frequent formula and code changes were made". This lack of oversight and quality control further compromised the reliability of the model.

Regulatory Oversight Failures

Regulatory oversight was inadequate throughout the development and implementation of the Synthetic Credit VaR Model. The OCC, JP Morgan's primary regulator, did not request critical performance data and failed to act on risk limit breaches. As highlighted in the Journal of Financial Crises, "JPM did not provide the OCC with required monthly reports... yet the OCC did not request the missing data". This lack of proactive oversight allowed significant issues to go unnoticed and unaddressed.

Additionally, the OCC was informed of risk limit breaches but did not investigate the causes or implications of these breaches. For instance, the OCC was contemporaneously notified in January 2012 that the CIO exceeded its Value at Risk (VaR) limit and the higher bank-wide VaR limit for four consecutive days. However, the OCC did not investigate why the breach happened or inquire why a new model would cause such a large reduction in VaR. This failure to follow up on critical risk indicators exemplified the shortcomings in regulatory oversight.

How JP Morgan Could Have Done Things Differently?

Improved Model Development Processes

One of the primary ways JP Morgan could have avoided the failure of the Synthetic Credit VaR Model was by improving the model development processes. Implementing automated systems for data management could have significantly reduced the risk of human error and improved accuracy. Manual data entry and copying and pasting of data in Excel spreadsheets were inherently risky practices. By automating these processes, the bank could have ensured more reliable and consistent data management.

Moreover, allocating experienced personnel and adequate resources for model development and testing would have ensured more robust results. The individual responsible for developing the model lacked prior experience in VaR models, and the resources allocated to the project were inadequate. By involving experts in the field and providing sufficient support, the bank could have developed a more sophisticated and reliable model. As highlighted in the internal report, "Inadequate resources were dedicated to the development of the model".

Conducting extensive back-testing and validation against existing models could have identified potential discrepancies and flaws. The Model Review Group did not conduct thorough testing of the new model, relying on limited back-testing. By implementing a more rigorous testing process, the bank could have validated the model's accuracy and reliability before its implementation.

Enhanced Oversight and Governance

Enhanced oversight and governance could have prevented the failure of the Synthetic Credit VaR Model. Ensuring regular, detailed reporting to regulators and internal oversight bodies would have maintained transparency and accountability. JP Morgan failed to provide the OCC with required monthly reports, and the OCC did not request the missing data. By establishing regular reporting protocols and ensuring compliance, the bank could have maintained better oversight of the model's performance.

Addressing risk limit breaches promptly and thoroughly would have mitigated escalating risks. The OCC was informed of risk limit breaches but did not investigate the causes or implications of these breaches. By taking immediate action to address and rectify risk limit breaches, the bank could have prevented further escalation of risks. Proactive risk management is crucial in identifying and mitigating potential issues before they lead to significant losses.

Implementing continuous monitoring and review processes for all models and strategies could have identified issues before they led to significant losses. The CIO risk management team played a passive role in the model's development, approval, implementation, and monitoring. By adopting a more proactive approach to monitoring and reviewing the model, the bank could have ensured that potential issues were identified and addressed promptly. Continuous monitoring and review processes are essential in maintaining the accuracy and reliability of risk management models.

Comprehensive Risk Management Framework

Developing a comprehensive risk management framework could have further strengthened JP Morgan's ability to manage risks effectively. This framework should have included clear policies and procedures for model development, implementation, and monitoring. By establishing a robust risk management framework, the bank could have ensured that all aspects of the model's lifecycle were adequately managed.

Additionally, enhancing collaboration and communication between different teams involved in risk management could have improved the model's reliability. The CIO risk management team viewed themselves more as consumers of the model rather than as responsible for its development and operation. By fostering collaboration and communication between different teams, the bank could have ensured that all stakeholders were actively involved in the model's development and monitoring.

Closing Thoughts

The failure of JP Morgan's Synthetic Credit VaR Model underscores the critical importance of rigorous development, testing, and oversight in financial risk management. This incident serves as a cautionary tale for financial institutions relying on complex models and emphasizes the need for robust governance and proactive risk management strategies. By learning from this failure, financial institutions can develop more reliable and effective risk management frameworks.

The insights gleaned from this case study are not just relevant to JP Morgan but to the broader financial industry, which increasingly depends on complex models to manage risk. By addressing the systemic issues that contributed to the failure and implementing the strategies outlined in this case study, financial institutions can mitigate similar risks in the future.

In conclusion, the London Whale incident highlights the vulnerabilities within JP Morgan's risk management framework and underscores the potential dangers of relying heavily on quantitative models without adequate oversight. By enhancing model development processes, improving oversight and governance, and developing a comprehensive risk management framework, financial institutions can ensure more reliable and effective risk management practices.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

1) Internal Report of JPMorgan Chase & Co. Management Task Force Regarding 2012 CIO Losses, January 16, 2013

2) A whale in shallow waters: JPMorgan Chase, the “London Whale” and the organisational catastrophe of 2012, François Valérian, November 2017

3) JPMorgan Chase London Whale E: Supervisory Oversight, Arwin G. Zeissler and Andrew Metrick, Journal of Financial Crises, 2019

4) JPMorgan Chase London Whale C: Risk Limits, Metrics, and Models, Arwin G. Zeissler and Andrew Metrick, Journal of Financial Crises, 2019

5) JPMorgan Chase Whale Trades: A Case History of Derivatives Risks and Abuses, Permanent Subcommittee on Investigations United States Senate, 2013

Boards Must Understand Technology. Period.

2024-07-01T09:17:00.011+02:00

Reflecting on the 2024 Swiss Board Day in Bern it has become even more clear to me that understanding the current technological landscape and its associated opportunities, challenges, and risks is now essential for both executive and non-executive board members.

Equally important is staying informed about governance issues related to these technologies, including regulatory challenges and potential pitfalls.

There is now way around it anymore, in order to set the company's vision and strategy, the board must understand how technology impacts the business and its future value creation.

Consider the narratives surrounding artificial reality (AI). While ChatGPT brought large language models into the spotlight, various AI applications like face ID, image recognition, customer service chatbots, and expert systems for tasks such as self-driving cars and chess have been in use for decades.

Despite media focus on the risks of AI, such as deep fakes and cyber threats, there are significant defensive benefits, including enhancing cybersecurity and verification processes. Boards need to understand AI’s role within their organizations, lead the way in defining “responsible AI,” and ensure issues like privacy, bias, and equity are addressed in AI development and deployment.

Clients, regulators, and markets now expect rapid and effective integration of new business drivers into strategies. Building trust around new technologies with internal and external stakeholders is crucial.

Cybersecurity, augmented reality (AR), robotics, and AI are just a few examples where companies must identify, measure, disclose, and adapt to strategic opportunities and risks. Not all technology is relevant for your company, but the ones that are should be evaluated in detail.

How can a board effectively oversee the long-term growth and evolution of their company amidst ongoing new opportunities and challenges, especially if they lack specific knowledge on existing and emerging technologies and its risks?

Boards should start with leveraging internal company resources. You should seek out knowledge by visiting your company's offices, attend small group sessions, do production tours, and join town halls to witness new developments firsthand and understand their strategic alignment.

Dedicated training and workshops with relevant experts can help you grasp the business implications of key technologies within their industry. Your trainer(s) should have experience implementing technology in your industry.

What is even more important is that your trainer(s) can explain technology in a way that non-technical people can understand and are able to apply their newly won knowledge onto their business.

The aim isn’t to create a board of tech experts but to shift mindsets, open new possibilities, evaluate risks, and enhance the board’s ability to challenge management in business development.

In a nutshell: In order to set the company's vision and strategy, the board must understand how technology impacts the business and its future value creation.

How To Select a Good Project Manager for Your Large and Complex Transformation Project

2024-06-14T11:24:00.008+02:00

One of your most important jobs as a project sponsor is to select a good project manager for your project.

Selecting the right project manager is crucial for the success of your project.

Here are the five key factors to consider when choosing the right person for the role:

1) Experience

Nothing beats relevant experience when it comes to managing large and complex transformation projects. On smaller and less complex projects you can give people a chance. On your business critical projects you should not.

You will need to be looking for project managers that have managed projects that were;

> in the same industry. Bonus points when it was in your own company or a direct competitor.

> having a similar objective and scope. After a full cycle SAP implementation at three different companies you understand a thing or two. Unless it were completely different modules and products.

> having a similar size and complexity. Rolling out a new software in one country is different from doing it in twelve. Having hundreds of products, thousands of clients

Your project manager should have a track record. Check references and past project outcomes.

A project gone belly up is not necessarily the fault of the project manager, but you will need to look for successful project completions and satisfied clients or employers.

2) Leadership and Communication Skills

A good project manager should be able to lead a team, make decisions, and motivate team members. Effective communication is critical for ensuring that all stakeholders are on the same page. You will get a feeling for this during your interviews. But the easiest way to check this is by checking references and calling your own contacts that might have worked with them.

3) Problem Understanding and Solving Skills

They should be able to analyse and understand problems and come up with effective solutions quickly. Understanding your problem is half the solution. You can assess this by presenting a number of the problems you want to address with your project to the project manager in an interview and ask them to come up with a solution on the fly.

4) Team Dynamics

They should be able to work well with you and your existing team. Ensure the project manager’s work style and values align with your team and company’s culture. Micromanagement sucks for everybody. Involve key team members in the interview process to get their input on potential candidates.

5) Gut Feeling

If your intuition about a candidate’s fit is good, but one or more of the 4 factors above seems to be not good, then look for a better candidate. Don't rely only on your intuition in this case.

If your intuition about a candidate’s fit is bad, but all of the 4 factors above seem to be good, then look for a better candidate. Trust your intuition in this case.

If your candidate scores well on these five factors there is a high probability they are the right candidate for the job!

PS: What is absolutely not important are certifications. Possessing the PMP shouts to the world that they have passed a comprehensive exam and confirmed that they are aware of and understand the processes, terms, tools, and techniques as represented in the PMI's Guide to the Project Management Body of Knowledge. Thats it! The same for Prince 2, SAFe, IPMA, and others.

Passing these exams does not confirm that they are an accomplished project manager with a long history of leading successful projects. To claim or even imply that earning such a certification is any more than an indicator of general knowledge in the field is questionable.

In a nutshell: Nothing beats relevant experience when it comes to managing large and complex transformation projects. On smaller and less complex projects you can give people a chance. On your business critical projects you should not.

My Talk "Artificial Intelligence" @ Business Angels Switzerland

2023-09-19T19:04:00.025+02:00

Last week I was invited by Business Angels Switzerland to give a talk at their Academy about Artificial Intelligence.

The goal of the talk was to enable investors to make better investment decisions when it comes to startups that are leveraging AI and Machine Learning.

Many executives share this challenge with startup investors. In this case it is typically more about what projects to invest in, instead of which companies.

That is why I wanted to share the recording of this talk with you.

You will find the video below or here.

A copy of the slides you can download here.

If you or your company needs help with how AI can create value in your business just contact me.

And if you think I would be a good fit for speaking at your organisation have a look at my speaking page.

What others are saying ...

Henrico can simplify any AI/blockchain/IT topic, summarize it and extract the essence for investors to make proper technical due diligence. Well done! - Managing Director @ Reinhart Capital

Case Study 17: The Disastrous Launch of Healthcare.gov

2023-03-19T14:36:00.009+01:00

Barack Obama was inaugurated on January 20, 2009, after defeating his opponent John McCain by 365 electoral college votes to 175. One of Obama's primary campaign issues was fixing America's healthcare system by providing affordable options to the 43.8 million uninsured Americans.

In 2010, the year Obama signed the Affordable Care Act (ACA), the United States spent 17.6% of its GDP on health care, nearly double the OECD average of 9.5%, with the next closest developed nation, the Netherlands, spending 12%.

The 44th president was successful in introducing the ACA; however, the launch of the website that would connect Americans to the marketplace, Healthcare.gov, was a failure. While the platform would eventually enroll an estimated 10 million uninsured Americans in 2014, the rollout was a complete disaster that exposed the challenges the United States government faces in implementing technology.

According to a 2008 report by the Government Accountability Office (GAO), 48% of federal IT projects had to be restructured because of cost overages or changes in project goals. In addition, over half had to be restarted two or more times.

On the first day Heathcare.gov was launched, four million unique users visited the portal, but only six successfully registered. Over the next few days, the site experienced eight million visitors, but according to estimates, around 1% enrolled in a new healthcare plan. Even the users that did sign up experienced errors, including duplicates in enrollment applications submitted to insurers.

The trouble launching Healthcare.gov presents a seemingly reoccurring problem when the US government tech projects. Standish Group International Chairman Jim Johnson is on record praising the rollout based on the government's history of software failing by default. "Anyone who has written a line of code or built a system from the ground up cannot be surprised or even mildly concerned that Healthcare.gov did not work out of the gate. The real news would have been if it actually did work. The very fact that most of it did work at all is a success in itself."

However, there's far more to the failed launch of the federally facilitated marketplace (FFM). The agency responsible for the project, the Centers for Medicare and Medicaid Services (CMS), didn't follow many regulations in place to ensure transparency, proper oversight, and accountability. So was the project destined to fail from the start due to overwhelming layers of bureaucracy, or were the vendors tasked with developing the online marketplace to blame?

In this case study, we'll examine why Healthcare.gov failed to meet expectations and point out what CMS could have done differently to deliver a functioning FFM.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

2010

On March 23, 2010, President Barack Obama signed ACA, also known as Obamacare, into law. The legislation was the most comprehensive reform of the US medical system in 50 years and is still in place today.

Under the ACA, US citizens were required to have health insurance or pay a monthly fee. The law also required the establishment of online marketplaces that would allow individuals to compare and select health insurance policies by January 1, 2014. States could set up their own marketplace or use the FFM.

Each marketplace created under the ACA was intended to provide a seamless, single point of access for individuals to enroll in qualified healthcare plans and access income-based financial subsidies created under the new law.

Users were required to visit Healthcare.gov, register, verify their identity, determine their eligibility for subsidies, and enroll in a plan. The process appears straightforward; President Obama even touted the marketplace weeks before its launch by saying, "Now, this is real simple. It's a website where you can compare and purchase affordable health insurance plans, side by side, the same way you shop for a plane ticket on kayak… the same way you shop for a TV on Amazon."

However, building an identity verification platform on such a large scale alone is exceptionally challenging. The marketplace also required integration from databases in other government agencies. Once the user successfully was verified as an American citizen, income was determined, and they were filtered through state and federal government programs like Medicaid or the State Children's Health Insurance Program, then they would be matched with private health insurance plans.

The process was not simple and was far more complex than online shopping because it required integration with identification verification software, other government databases, and health insurance providers.

From day one, the project was underestimated. In addition, the requirements in the ACA that all citizens must enroll by January 1, 2014 or would be required to pay a fine created a hard deadline with economic and political consequences.

March 2010 - September 2011

Over a year passed between the ACA becoming a law and the CMS signing contracts with vendors who would build the FFM. During this period, problems directly affecting the launch were already beginning.

While the CMS was in charge of oversight of the project and hiring contractors, leadership was fractured across multiple government agencies. The project was headed by the CMS's Deputy CIO, Henry Chao, but the committee also included:

Todd Park – White House CTO

Jeanne Lambrew – Executive Office of Health Reform

Kathleen Sebelius and Bryan Sivak – Department of Health and Human Services

Members of the committee outside of the CMS executed a great deal of power and influence over the project; however, no one at the various agencies had visibility of the critical milestones that each group needed to reach to complete the project successfully.

The CMS awarded 60 contracts to 33 different vendors. The largest was granted to Conseillers en Gestion et Informatique (CGI), a Montreal-based IT company that employed more than 70,000 people. CGI grew to be worth more than $11 billion by 2013 by acquiring other companies, some of which handled US government contracts such as the 2004 purchase of American management Systems and the 2010 purchase of Stanley.

CGI’s contract consisted of developing the FFM and was valued at over $90 million. CGI was responsible for the most significant, user-facing aspect of the project but was not officially assigned a lead integrator role. CMS would later report they perceived CGI to be the project's lead integrator but didn't have written documentation outlining the agreement.

Representatives from CGI stated they did not have the same understanding at this point of the project.

US federal agencies are required to perform a procurement framework when awarding private companies with government contracts outlined by the Federal Acquisition Regulation (FAR). However, CMS failed to satisfy specific aspects of FAR, including:

> Preparing a written procurement strategy documenting the factors, assumptions, risks, and tradeoffs that would guide project decisions.

> Conduct thorough past performance reviews of potential contractors.

> Only used the federal government's contractor database (PPIRS) when evaluating bids on four of the six key contracts.

CMS leadership later claimed they were unaware that a procurement strategy was required.

December 2011 – Summer 2013

Development of the Healthcare.gov project began in December 2011 consisting of four major components:

> Front-end website for the FFM (the marketplace)

> Back-end data services hub

> Enterprise identity management sub-system

> Hosting infrastructure

CGI was responsible for the front-end website. The UI was developed with standard web tools, including Bootstrap, CSS, jQuery, Jekyll, Prose.io, and Ruby; however, it would later be revealed that common optimization features to aggregate and minify CSS and JS files were not used.

The back-end data services hub was developed by CGI and Quality Software Services, Inc (QSSI) using Java, JBoss, and the NoSQL MarkLogic database. The hub was responsible for orchestrating data and services from multiple external sources such as agent brokers, insurers, CMS, DHS, Experian, the IRS, state insurance exchanges, and the US Social Security Administration (SSA). While the integration was incredibly complex, utilizing data from multiple sources, the developers chose machine-generated middleware objects to save time.

Enterprise Identity Management (EIDM) was handled by QSSI but depended on the back-end to retrieve data from multiple sources. Before the launch, the EIDM was tested with an expected load of only 2,000 concurrent users.

The final major system component was the hardware infrastructure hosting of the website, FFM, data services hub, and EIDM. Akamai's CDN hosted Healthcare.gov's UI. The original back-end (it would be replaced after the failed launch) consisted of 48 VMWare virtual machine nodes running Red Hat Enterprise Linux and hosted on twelve physical servers in a Terremark data center. Some of the servers ran vSphere v4.1, with others running v5.1; the network was also running at 1 Gb/sec, far below its capacity of 4 Gb/sec.

Failures on all critical components of the project exemplify that CMS didn't have the personnel or experience to handle an IT project of this magnitude.

Late 2013

With only a couple of months left before the scheduled launch, CMS raised its concerns about CGI's performance but didn't take steps to hold the contractor accountable. In September 2013, CMS moved into CGI's offices for on-site support.

CMS delayed governance reviews that would have exposed the issues and did not receive the required approvals to move forward. However, they decided to continue with an on-schedule launch with all the platform's features, available to every American citizen needing affordable healthcare. The estimated project cost at this point was $500 million.

On October 1, 2013, the Healthcare.gov website was online. Most visitors experienced crashes, delays, errors, and slow performance throughout the week. By the weekend, the decision was made to take the site down because it was practically unusable.

Later in the month, HHS announced the following changes to the project:

Project management was centralized and led by Jeffrey Zients, former OMB director who had a reputation within the Whitehouse for solving tough problems and managing teams.

Todd Park, White House CTO, reorganized the technology leadership team, demoted some underperforming CMS employees and 3rd party contractors, and recruited top talent from Silicon Valley for a government sabbatical to save the site.

A Tiger team was formed with the narrow mandate of getting the FFM working properly.

The new team scrummed daily, triaged existential risks, and prioritized defects based on urgency. Over the next six weeks, the Tiger team resolved 400 system defects, increased system concurrency to 25,000 users, and improved the site's responsiveness to one second. The site went back online, and enrollment jumped from 26,000 in October to 975,000 in December.

By Christmas, most problems had been fixed, but the site was still not fully operational.

2014

CGI was replaced by Accenture as the lead contractor and awarded a $90 billion contract to replace the FFM.

The individual mandate requirement was pushed back to March 31, 2014, giving uninsured Americans more time to sign up without being penalized.

In July, the GOA released a detailed report outlining the critical failures of the project.

According to the GOA's findings, FFM obligations increased from $56 million to more than $209 million. Similarly, data hub obligations increased from $30 million to nearly $85 million from September 2011 to February 2014. The study recommended that "CMS take immediate actions to assess increasing contract costs and ensure that acquisition strategies are completed, and oversight tools are used as required, among other actions. CMS concurred with four recommendations and partially concurred with one. "

In August, the Office of Inspector General released a report finding that the total cost of the Healthcare.gov website had reached $1.7 billion. A month later, Bloomberg News reported the cost exceeded $2 billion.

By November, open enrollment on Healthcare.gov began for 2015.

What Went Wrong?

A multitude of issues caused the failed launch of the Healthcare.gov website. While it is a clear example of the federal government's continuous struggle to implement functioning, secure software, the problems go beyond Washington's bureaucracy. Nevertheless, much can be learned about releasing digital solutions and managing large-scale projects with many moving parts in general.

Overconfidence

The project started with overconfidence and unrealistic expectations set by the White House. Obama's campaign staff had a reputation for being technologically savvy because they pioneered using social media and data mining in the 2008 presidential election. However, running a social media campaign and releasing a single point of contact that pulls from multiple government agencies and insurance companies aren't comparable.

Underestimated Scale of the Project

Due to overconfidence and unrealistic expectations, the project scale was drastically underestimated, resulting in mismanagement in organizational structure, leadership, accountability, and transparency.

As the deadline approached, the project scope grew, while CMS identified 45 critical and 324 severe code defects across FFM modules.

Politics

Launching large-scale software projects are extremely challenging but adding a hostile political climate made the rollout even more difficult. Not only did CMS not have the personnel or experience to handle an FFM, but they also experienced pressure and influence from outside the agency. One of the most significant examples came in August of 2013, the White House and executive Office of Health Reform insisted on requiring site user registration before shopping for insurance so that concrete user numbers could be shown as proof of the system's success.

Members of the project committee that weren't from the CMS exhibited a great deal of influence over critical decision-making while not having access to accurate progress reports. In addition, the 2012 presidential elections likely impacted delays. Polarizing decisions, such as final rules on private insurance premiums, coverage availability, risk pools, and catastrophic plans, were put off till after the election cycle. These rules had to be translated into software and tested before a successful rollout was possible.

Lack of technology understanding and experience at CMS

The CMS was not prepared to handle a technology project at this scale. Other government agencies, such as the DOD and NASA, had decades of experience navigating the institutional challenges required to develop, deliver, and operate reliable IT systems.

Throughout procurement, development, and launch, CMS made it clear that its personnel didn't understand the requirements necessary to oversee a large-scale technology project, let alone one that had additional regulatory hurdles set by government agencies.

Poor Project Management

The project committee was spread across various government agencies, including the CMS, the White House, the Office of Health Reform, and the Department of Health and Human Services. As a result, there wasn't an organizational structure standard on even small-scale projects. Fractured leadership contributed to the lack of project management, but CMS was primarily responsible. While the problem could have been lessened if CMS had followed the guidelines from FAR, the operators from the agency pleaded ignorance in the GAO report, strengthening the case that CMS didn't have personnel suitable for the project.

Failed to Postpone Launch

All the problems accumulated, resulting in a failed launch. Typically, the release is delayed when a website or software isn't ready. The engineers perform more testing, fix the problems, and launch at a later time. Healthcare.gov was a unique project with consequences transcending a poor user experience. The time constraints pressured CMS to go forward with the launch rather than being transparent and communicating that the infrastructure couldn't handle millions of users.

Leading up to the launch, CMS was given more business rules and a broader scope. While they had no control over the pressure coming from the Whitehouse, the agency failed to be upfront, and instead of delaying the launch or releasing in stages, they scrambled to save the project.

How CMS Could Have Done Things Differently

CMS was in charge of the project, but the blame falls on the Obama administration. Appointing CMS to lead the project was the first mistake made in a number of shortcomings that led to billions of wasted tax dollars and US citizens being delayed health care coverage.

While appointing a different agency, one that had experience delivering technology projects, was the first significant error, analyzing the oversights made by CMS leading up to the launch is the most practical way to assess what could have been done differently.

Preparation

An understanding of the scale of Healthcare.gov would have dramatically influenced CMS to prepare better and implement project management best practices. One way the leadership at CMS could have prevented a launch failure was to realize they couldn't handle heading the project. Assigning lead manager and integrator roles to an outside firm or the lead vendor would have been more sensible.

Procurement

Many institutional challenges out of the hands of CMS contributed to the failed launch of Healthcare.gov. However, the agency had complete control over the procurement of government contractors. Simply following the Federal Acquisition Regulation (FAR) procurement framework could have prevented many organizational problems that led to the failure.

Had CMS adhered to standard government agency procurement guidelines, issues like the confusion around who was lead integrator wouldn't have existed. Furthermore, decisions like depending on data provided by Experian, a data source that neither the government nor the other contractors could do any data quality work on, would have likely been questioned if not denied when submitted for approval.

Adopt Iterative Software Development Framework

The project would have benefited if an iterative system development philosophy and a lean software manufacturing process such as Scrum or Kanban were adopted. Project managers could have organized sprints driven by the top priorities, including the complete end-to-end testing of the technology solution. An Iterative Development Framework would have increased visibility across multiple contractors and federal agencies, improved development quality, and reduced time to market.

Strong Leadership

Leadership was a fundamental problem that affected every aspect of the Healthcare.gov launch. Distribution of authority, management, and accountability created an environment where a functioning FFM was impossible to deliver on time. The project steering committee should have elected one project executive to make final decisions, hold contractors accountable, and communicate with other government agencies.

See "Consensus Is the Absence of Leadership" for for more insights on this topic.

Set and Guard Technical Standards

A rushed, unqualified, and fractured committee led to the development of poor technology. As a result, CGI and other contractors experience zero to very little oversight allowing for an unfinished UI, partially operating back-end, and unstable hosting.

The developers from CGI delivered an unpolished UI with excessive typos, a bloated directory, sloppy code, and even Lorem Ipsum placeholder text on the web pages. In addition, best practices were not followed or ignored regarding file compression, causing the website to take eight seconds to load and 71 seconds for user account registration pages with client-side loading, according to a report by AppDynamics.

A basic small business website delivered at this standard would be unacceptable, let alone the focal point of one of the most transformative pieces of legislation in recent US history.

CGI should have been held to higher standards and required to deliver a polished, functioning UI.

While the front end was a disaster, fixing HTML, CSS, and JS and optimizing webpages can be done overnight. Healthcare.gov's back-end was a different story requiring systemic changes to function. More oversight was needed on the database and server-side development, but it could have only gone smoothly with drastic changes to leadership and organizational structure.

Improve Security

Healthcare.gov requires an abundance of personal data to be submitted and collected. While security wasn't the primary failure of the project, the servers were hacked in July 2014. The malware was uploaded into the system but failed to communicate to any external IP addresses. In addition, multiple security defects were found, including the insecure transmission of personal data, unvalidated password resets, error stack traces revealing internal components, and violations of user data privacy.

Comprehensive security audits must be conducted before the launch rather than on the fly after a site is live.

Implement Testing and Bug Fixing Protocols

Adequate testing could have prevented many of the FFM's problems; however, CMS was well aware of the issues but failed to communicate with HHS and other government agencies. Still, testing protocols and a strategy to manage and fix bugs are necessary for an IT project of this scale.

CMS needed to coordinate unit and component testing by 3rd parties much sooner than a couple of weeks before launch. Testing conducted by teams outside of specific features of the project ensures there aren't biases and that the project works on various devices, browsers, and servers.

Another issue CMS encountered was communication with states implementing their own healthcare marketplaces. The date was pushed from November 2012 to December 2012, and some were confirmed as late as February 2013. Uncertainty of the traffic volume should have led to overpreparation and expanded capacity testing of concurrent users. Instead, a load of only 2,000 simultaneous users has been tested rather than the tens of thousands they should have expected.

Phased or Staged Rollout

One way the project steering committee could have responded to the issues without pushing back the launch was to release the project in phases or stages. Below are multiple options the committee could have taken instead of the Big Bang launch approach:

> Released certain features that were ready or could have been prepared when prioritized before October 1, 2013.

> Roll out a beta version of the platform to a small number of applicants (by region, government employees, sample group, etc.) months before the deadline.

> Release the platform in strategic phases leading up to the deadline, e.g., encourage applicants to register early in August, request eligibility in September, and shop for plans in October.

> Limit the scope of the project months before the launch and focus on minimal requirements rather than continue expanding leading up to the hard deadline.

See "How Your Rollout in Waves Can End in a Tsunami" for more insights on this topic.

Face Reality

The problems facing the Healthcare.gov launch were apparent, and there's evidence in the GAO report that suggests CMS was well aware of the issues. In addition, a McKinsey report was released just a few months before the scheduled rollout in April 2013. The report highlighted the initiative's complexity and identified more than a dozen critical risks spanning the marketplace technology and project governance.

The problems we've covered were clearly outlined in the report, as well as multiple definitions of success and concerns with a Big Bang launch approach. The McKinsey report also suggested several actionable methods to mitigate the risks. Still, the project steering committee did not act upon the McKinsey report's findings and recommendations before the system launch.

Whether CMS caved under the pressure of the deadline, the political consequences, or was just incompetent enough to expect a positive outcome is unclear. All the warning signs pointed to an unsuccessful launch and should have been taken seriously, resulting in making the necessary adjustments.

See "It Is Time to Face Your Project's Reality" for more insights on this topic.

Closing Thoughts

The Healthcare.gov project exemplifies just about everything that can go wrong with software integration between the federal government and the private sector. The project's failures are incredibly complicated due to the influence of multiple government agencies and a hostile political climate. When one problem is identified, more come to the surface with increasingly challenging solutions.

But was the project doomed to fail just because of the layers of government bureaucracy? I don't believe so.

Had the committee executed strong leadership with personnel who had experience working on institutional software, the project could have gone much differently. The remarkable aspect of Healthcare.gov is how fast it was turned around, given the state of the project after the launch. Once the Whitehouse was fully aware of the problems and competent leaders were put in place, the site was made functional in a few weeks and essentially operational in December 2013.

In a nutshell: Experienced leadership leads to realistic expectations, a healthy organizational structure, and strong communication. Never underestimate the importance of the person or group that is in charge.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> https://www.bloomberg.com/news/articles/2014-09-24/obamacare-website-costs-exceed-2-billion-study-finds

> https://oig.hhs.gov/oei/reports/oei-03-14-00231.asp

> https://hackernoon.com/small-is-beautiful-the-launch-failure-of-healthcare-gov-5e60f20eb967

> https://www.appdynamics.com/blog/product/technical-deep-dive-whats-impacting-healthcare-gov/

> https://www.gao.gov/products/gao-14-694

How Your Rollout in Waves Can End in a Tsunami

2022-11-14T18:30:00.006+01:00

Many multinational organizations are bringing larger system implementations to a screeching halt because they misunderstand what it means to do a rollout in waves.

We’re probably all familiar with the “phased rollout”. A phased rollout means you roll a project out to all targeted users at once but don’t deploy all of its planned functionality.

A good example of this would be rolling out a new CRM system to your organization. You go live in the first phase with Contact, Client, and Opportunity Management, and Account Management and Pipeline Management follow in the second phase.

Another popular type of rollout is the so-called staged rollout (also known as a rollout in waves). A rollout in waves or stages means that all the planned functionalities will be rolled out at once, but not for all users.

A rollout in waves gives you time to analyze the system’s quality, stability, and performance against your business goals. You can then decide if you want to roll out the system to more users, wait for more data, or stop the rollout.

A rollout in waves is one of the core building blocks of making continuous delivery a reality. Facebook, Netflix, Microsoft, Google, and similar companies all rely heavily on staged rollouts.

One wave rollout method frequently used by multinational companies for new system implementation is the rollout by country or geographical territory.

This is the preferred approach by companies implementing a new CRM, ERP, HCM, or some other key business application. Sometimes it’s combined with a phased approach.

Rolling out in waves is usually a good idea, especially compared to a “big bang” rollout.

But before undertaking a rollout in waves, you have to carefully consider the following three realities:

1) The moment you switch on a new system in one country, you’ll need to address a bunch of Business As Usual (BAU) activities including Release Management, Change Management, New User Training … you name it. Your users will also discover bugs in the system and/or interfaces that weren’t discovered during testing. Many of them will be critical and need to be fixed ASAP. You’ll probably find that performance issues will be more common than not. Some companies call the first few months “Hyper Care” or some equivalent, but it is nothing else as BAU.

2) As is always the case with a new system, it won’t work completely as expected. In addition to the bugs that need to be addressed within the BAU process, you’ll have a high number of Change Requests, because only now will users realize they need additional or different functionality to do their work. Again, a number of these requests will be critical and/or urgent. Users will probably ask for many additional reports because they don’t understand the data they see in the new system. If you combine your rollout in waves with a phased rollout, you’ll need to build and test the functionalities for the next phase.

3) At the same time, you’ll want to proceed with the next waves of your rollout, and you’ll need people to work on this. Think about discovery, migration, configuration, training, etc. for each new country that needs to be onboarded. The big idea is always to have one system for everyone, but local legislation and regulations and differences in how business is done in each country will force you to implement additional Change Requests in the system.

The number-one mistake I see is that organizations allocate a single team to accomplish all of the above tasks after the first-wave rollout. This approach always fails miserably and will bring the rollout to a screeching halt.

For a successful rollout in waves, you’ll need three different teams after the first wave: one for BAU activities, one to deliver Change Requests, and one to onboard additional waves. Some people may work on more than one team, but this really should be the exception.

You’ll need to plan and budget for these teams, hire and train people for them, and define their organizational setup.

And you’ll need to do all of this before you go live with the first wave – not after!

In a nutshell: You will need three teams for a successful system rollout in waves.

My Talk "Why Big Technology Projects Fail" @ Synergy DevPartner Conference

2022-11-12T13:36:00.017+01:00

In September I was invited by Synergex to give a talk at their 2022 Synergy DevPartner Conference.

The title of my talk was "Why Big Technology Projects Fail" and it covers my personal top ten reasons why this happens so often.

Many executives and organisations have challenges with bringing large and complex technology projects to a success.

That is why I wanted to share the recording of this talk with you. Note that the talk was not live. I prerecorded it.

You will find the video below or here.

A copy of the slides you can download here.

If you or your company needs help with making your large and complex technology project a success, just contact me or have a look at my services.

And if you think I would be a good fit for speaking at your organisation have a look at my speaking page.

What others are saying ...

Please accept our sincere appreciation for the outstanding presentation you made at our Synergex DevPartner Conference. We received rave reviews from customers and employees alike. It was clear that you took the time to understand our company mission and we were all thrilled with the care you took to tailor your presentation to our audience. We look forward to utilizing this presentation in our marketing efforts for the foreseeable future. - Synergex

Case Study 16: Nike’s 100 Million Dollar Supply Chain "Speed bump"

2022-10-16T09:02:00.013+02:00

“This is what you get for 400 million, huh?”

Nike President and CEO Phil Knight famously raised the question in a conference call days before announcing the company would miss its third-quarter earnings by at least 28% due to a glitch in the new supply chain management software. The announcement would then send Nike’s stock down 19.8%. In addition, Dallas-based supply-chain vendor i2 Technologies, which Nike assigned blame, would suffer a 22.4% drop in stock price.

The relationship would ultimately cost Nike an estimated $100 million. Each company blamed the other for the failure, but the damage could have been dramatically reduced if realistic expectations had been set early on and a proper software implementation plan had been put in place. Most companies wouldn’t overcome such a disastrous supply chain glitch or “speed bump,” as Knight would call it, but Nike would recover due to its dominant position in the retail footwear and apparel market.

In 1999, two years before Knight’s famous outburst, Nike paid i2 $10 million to centralize its supply, demand, and collaboration planning system with a total estimated implementation cost of $40 million. Initially, i2 was the first phase of The Nike Supply Chain (NSC) project. The plan was to implement i2 to replace the existing system and introduce enterprise resource planning (ERP) software from SAP and customer relationship management (CRM) software from Siebel Systems.

The goal of the NSC project was to improve Nike’s existing 9-month product cycle and fractured supply chain. As the brand experienced rapid growth and market dominance in the 1990s, it accumulated 27 separate order management systems around the globe. Each is entirely different from the next and poorly linked to Nike’s headquarters in Beaverton, Oregon.

At the time, there wasn’t a model to follow at the scale Nike required. Competitors like Reebok struggled to find a functional supply chain solution specific to the retail footwear and apparel industry. In an effort to solidify its position as the leader in sportswear, Nike decided to move forward quickly with i2’s predictive demand application and its supply chain planner software.

"Once we got into this, we quickly realized that what we originally thought was going to be a two-to-three-year effort would be more like five to seven," - Roland Wolfram, Nike’s vice president of global operations and technology.

The NCS project would be a success, and Nike would eventually accomplish all its supply chain goals. However, the process took much longer than expected, cost the company an additional $100 million, and could have been avoided had the operators or both companies taken a different approach to implementation.

"I think it will, in the long run, be a competitive advantage." – Phil Knight

In the end, Knight was right, but there are many valuable lessons to learn from the Nike i2 failure.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

So, before we get into the case study, let’s look at precisely what happened...

Timeline of Events

1996 - 1999

Nike experienced incredible growth during this period but was at a crossroads. Strategic endorsement deals and groundbreaking marketing campaigns gave the company a clear edge over Adidas and Reebok, its two most substantial competitors in the 80s and 90s. However, as Nike became a world-renowned athletics brand, its supply chain became more complex and challenging to manage.

Part of Nike’s strategy that separated itself from competitors was the centralized approach. Product design, factory contracting, and order fulfillment were coordinated from headquarters in Oregon. The process resulted in some of the most iconic designs and athlete partnerships in sports history. However, manufacturing was much more disoriented.

During the 1970s and 80s, Nike battled to develop and control the emerging Asian sneaker supply chain. Eventually, the brand won the market but struggled to expand because of the nine-month manufacturing cycle.

At the time, there wasn’t an established method to outsource manufacturing from Asia, making the ordering process disorganized and inefficient across the industry. In addition, Nike’s fractured order management system contained tens of millions of product numbers with different business rules and data formats. The brand needed a new way to measure consumer demand and manage purchasing orders, but the state of the legacy system would make implementing new software difficult.

1999

At the beginning of 1999, Nike decided to implement the first stage of its NSC project with the existing system. i2 cost the company $10 million but estimated the entire project would cost upwards of $400 million. The project would be one of the most ambitious supply chain overhauls by a company of Nike’s size.

i2 Technologies is a Dallas, Texas-based software company specializing in designing solutions that simplify supply and demand chain management while maximizing efficiency and minimizing cost. Before the Nike relationship, i2 was an emerging player in logistics software with year-over-year growth. Involvement in the Nike project would position the company as the leading name in supply chain management software.

Nike’s vision for the i2 phase of NSC was “achieving greater flexibility in planning execution and delivery processes…looking for better forecasting and more profitable order fulfillment." When successfully implemented, the manufacturing cycle would be reduced from nine months the six. This would convert the supply chain to make-to-order rather than make-to-sell, an accomplishment not yet achieved in the footwear and apparel industry.

Predicting demand required inputting historical sales numbers into i2’s software. “Crystal balling” the market had substantial support at the time among SCM companies. While the belief that entering numbers into an algorithm and spitting out a magical prediction didn’t age well, the methodology required reliable, uniform data sets to function.

Nike decided to implement the “Big Bang” ERP approach when switching to i2 for the supply chain management. The method consists of going live where the business completely changes without phasing out the old system. Nike also opted for a single instance strategy for implementation. The CIO at the time, Gordon Steele, is quoted saying, “single instance is a decision, not a discussion.” Typically, global corporations choose a multi-instance ERP solution, using separate instances in various regions or for different product categories.

2000

By June of 2000, various problems with the new system had already become apparent. According to documents filed by Nike and i2 shareholders in class-action suits, the system used different business rules and stored data in various formats, making integration difficult. In addition, the software needed customization beyond the 10-15% limit recommended by i2. Heavy customization slowed down the software. For example, entries were reportedly taking over a minute to be recorded. In addition, the SCM system frequently crashed as it struggled to handle Nike’s tens of millions of product numbers.

The issues persisted but were fixable. Unfortunately, the software was linked to core business processes, specifically factory orders, that sent a ripple effect that would result in over and under-purchasing critical products. The demand planner would also delete ordering data six to eight weeks after it was entered. As a result, planners couldn’t access purchasing orders that had been sent to factories.

Problems in the system caused far too many factory orders for the less popular shoes like the Air Garnett IIIs and not enough popular shoes like the Air Jordan to meet the market's demand. Foot Locker was forced to reduce prices for the Air Garnett to $90 instead of the projected retail price of $140 to move the product. Many shoes were also delivered late due to late production. As a result, Nike had to ship the shoes by plane at $4-$8 a pair compared to sending them across the Pacific by boat for $0.75.

November 2000

According to Nike, all the problems with i2’s supply chain management system were resolved by the fall. Once the issues were identified, Nike built manual workarounds. For example, programmers had to download data from i2’s demand predictor and reload it into the supply chain planner on a weekly basis. While the software glitches were fixed and orders weren’t being duplicated or disappearing, the damage was done. Sales for the following quarter were dramatically affected by the purchasing order errors resulting in a loss of over $100 million in sales.

2001

Nike made the problem public on February 27, 2001. The company was forced to report quarterly earnings to stakeholders to avoid repercussions from the SEC. As a result, the stock price dove 20%, numerous class-action lawsuits were filed, and Phil Knight famously voiced his opinion on the implementation, "This is what you get for $400 million, huh?"

In the meeting, Nike told shareholders they expected profits from the quarter to decline from around $0.50 a share to about $0.35. In addition, the inventory problems would persist for the next six to nine months as the overproduced products were sold off.

As for the future of NSC, the company, including its CEO and President, expressed optimism. Knight said, "We believe that we have addressed the issues around this implementation and that over the long term, we will achieve significant financial and organizational benefit from our global supply-chain initiative."

A spokeswoman from Nike also assured stakeholders that the problems would be resolved; she said that they were working closely with i2 to solve the problems by creating “some technical and operational workarounds” and that the supply chain software was now stable.

While Nike was positive about the implementation process moving forward, they placed full blame on the SCM software and i2 Technologies.

Nike stopped using i2’s demand-planning software for short-and-medium range sneaker planning; however, it still used the application for short range and its emerging apparel business. By the Spring of 2001, Nike integrated i2 into its more extensive SAP ERP system, focusing more on orders and invoices rather than predictive modeling.

What Went Wrong?

While the failures damaged each company’s reputation in the IT industry, both companies would go on to recover from the poorly executed software implementation. Each side has assigned blame outward, but after reviewing all the events, it's safe to say each had a role in the breakdown of the supply chain management system.

Underestimating Complexity

Implementing software at this scale always has risks. Tom Harwick, Gigi Information Group’s research director for supply chain management, said, “Implementing a supply-chain management solution is like crossing a street, high risk if you don't look both ways, but if you do it right, low risk.”

One of Nike's most significant mistakes was underestimating the complexity of implementing software at such a large scale. According to Roland Wolfram, Nike’s operators had a false sense of security regarding the i2 installation because it was small compared to the larger NSC project. "This felt like something we could do a little easier since it wasn’t changing everything else [in the business]," he says. "But it turned out it was very complicated."

Part of the reason why the project was so complicated was because of Nike’s fractured legacy supply chain system and disoriented data sets. i2’s software wasn’t designed for the footwear and apparel industry, let alone Nike’s unique position in the market.

Data Quality

Execution by both parties was also to blame. i2 Technologies is on record recommending customization not to exceed 10-15%. Nike and i2 should have recognized early on that this range would be impossible to accommodate the existing SCM system.

Choosing a Big Bang implementation strategy didn’t make sense in this scenario. Nike’s legacy system data was too disorganized to be integrated into the i2 without making dramatic changes before a full-on launch.

Poor Communication

Communication between Nike and i2 from 1999 to the summer of 2000 was poor. i2 claimed not to be aware of problems until Knight issued blame publicly. Greg Brady, the President of i2 Technologies who was directly involved with the project, reacted to the finger-pointing by saying, "If our deployment was creating a business problem for them, why were we never informed?" Brady also claimed, "There is no way that software is responsible for Nike's earnings problem." i2 blamed Nike’s failure to follow the customization limitations, which was caused by the link to Nike’s bake-end.

Rush to Market

At the time, Nike was on the verge of solidifying its position as the leader in footwear and sports apparel for decades to come. Building a solid supply chain that could adapt to market trends and reduce the manufacturing cycle was the last step toward complete market dominance. In addition, the existing supply chain solutions built for the footwear and apparel industry weren’t ready to deploy on a large scale. This gave Nike the opportunity to develop its own SCM system putting the company years ahead of competitors. Implementing functional demand-planning software would be highly valuable for Nike and its retail clients.

i2 also was experiencing market pressure to deploy a major project. Had the implementation gone smoothly, i2 would have a massive competitive advantage. The desire to please Nike likely played a factor in i2’s missteps. Failing to provide clear expectations and communication throughout the process may not have happened with a less prominent client.

Failure to Train

After the problems became apparent in the summer of 2000, Nike had to hire consultants to create workarounds to make the SCM system operational. This clearly indicates that Nike’s internal team wasn’t trained adequately to handle the complexity of the new ERP software.

Nike’s CIO at the time reflected on the situation. "Could we have taken more time with the rollout?" he asked. "Probably. Could we have done a better job with software quality? Sure. Could the planners have been better prepared to use the system before it went live? You can never train enough."

How Nike Could Have Done Things Differently

While Nike and i2 attempted to implement software that had never been successfully deployed in the global footwear and apparel industry, many problems could have been avoided. We can learn from the mistakes and how Nike overcame their challenges with i2 to build a functioning ERP system.

Understanding and Managing Complexity

Nike’s failure to assess the complexity of the problem is at the root of the situation. Regardless if the i2 implementation was just the beginning of a larger project, it featured a significant transition from the legacy system. Nike’s leadership should have realized the scale of the project and the importance of starting NSC off on the right foot.

i2 also is to blame for not providing its client with realistic expectations. As a software vendor, i2 is responsible for providing its client with clear limitations and the potential risks of failing to deploy successfully.

See "Understanding and Managing Your Project’s Complexity" for more insights on this topic.

Collaborate with i2 Technologies

Both companies should have realized that Nike required more than 10-15% customization. Working together during the implementation process could have prevented the ordering issues that were the reason for the lost revenue.

Collaboration before deployment and at the early stages of implementation is critical when integrating a new system with fractured data. Nike and i2 should have coordinated throughout the process to ensure a smooth rollout; instead, both parties executed poor project management resulting in significant financial and reputational blows.

See "Solving Your Between Problems" for more insights on this topic.

Hire a 3rd Party Integration Company

Nike’s lack of understanding of the complexity of SCM implementation is difficult to understand. If i2 had been truthful in that they did not know about problems with their software, Nike could have made a coordinated decision not to involve the software company during the process.

Assuming that is the case, Nike should have hired a 3rd party to help with the integration process. Unfortunately, Nike’s internal team was not ready for the project. Outside integrators could have prevented the problems before the damage was done.

Not seeking outside help may be the most significant aspect of Nike’s failure to implement a new SCM system.

See "Be a Responsible Buyer of Technology" for more insights on this topic.

Deploy in Stages

A “Big Bang” implementation strategy was a massive mistake by Nike. While i2 should have made it clear this was not the logical path considering the capabilities of their software and Nike’s legacy system, this was Nike’s decision.

Ego, rush to market, or failure to understand the complexities of the project could all have been a factor in the decision. Lee Geishecker, a Gartner analyst, stated that Nike chose to go live a little over a year after starting the project, while projects of this scale should take two years before deployment. In addition, the system should be rolled out in stages, not all at once.

Brent Thrill, an analyst at Credit Suisse First Boston, is on record saying he would have kept the old system running for three years while testing i2’s software. In another analysis, Larry Lapide commented on the i2 project by saying, "Whenever you put software in, you don't go big bang, and you don't go into production right away. Usually, you get these bugs worked out . . . before it goes live across the whole business."

Train Employees Sufficiently

At the time, Nike’s planners weren’t prepared for the project. While we will never know what would have happened if the team had been adequately trained, proper preparation would have put Nike in a much better position to handle the glitches and required customizations.

See "User Enablement is Critical for Project Success" for more insights on this topic.

Practice Patience in Software Implementation

At the time, a software glitch causing a ripple effect that would impact the entire supply chain was a novel idea. Nike likely made their decisions to risk the “Big Bang” strategy, deploy in a year without phases and proper testing, and not seek outside help because they assumed the repercussions of a glitch wouldn’t be as catastrophic.

Impatience resulted in avoidable errors. A more conservative implementation strategy with adequate testing would have likely caught the mistakes.

See "Going Live Too Early Can Be Worse as Going Late" for more insights on this topic.

Closing Thoughts

One of the most incredible aspects of Nike’s implementation failure is how quickly the company bounced back. While Nike undoubtedly made numerous mistakes during the process, NSC was 80% operational in 2004.

Nike turned the project around by making adjustments and learning patience. Few companies can suffer a $100 million “speed bump” without filing bankruptcy, but Nike is in that position because of its resilience. The SAP installation wasn’t rushed and resumed many aspects of its original strategy. In addition, a training culture was established due to the i2 failures. Customer service representatives receive 140 to 180 hours of training from highly skilled “super users,” All employees are locked out of the system until they complete their required training courses.

Aside from the $100 million loss, the NSC project was successful. Lead times were reduced from nine months to six (the initial goal), and Nike’s factory inventory levels were reduced from a month to a week in some cases. Implementing a new SCM system also created an integration between departments, better visibility of customer orders, and increased gross margins.

While Nike could have executed far more efficiently, Phil Knight’s early assessment of the i2 failure turned out to be true. In the long run, the process gave Nike a competitive advantage and was instrumental in building an effective SCM system.

In a nutshell: A failure to demonstrate patience, seek outside help, and rush software implementation can have drastic consequences.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> Nike says i2 hurt its profits

> I2 Technologies, Inc.

> How Not to Spend $400 Million

> i2-Nike fallout a cautionary tale

> Nike rebounds: How Nike recovered from its supply chain disaster

> Scm and Erp Software Implementation at Nike – from Failure to Success

> I2 Says: "You Too, Nike"