The Problems You Can’t Afford to Ignore:
From IT Project Chaos to Successful Product Delivery

Most software projects fail. That’s not opinion—that’s what the research confirms.

Bent Flyvbjerg, the world’s most prolific researcher on IT project outcomes, has shown time and again that the odds are stacked against success when building software. Projects go wildly over budget. Timelines balloon. Features underwhelm. And worst of all? Products often never reach the market, or if they do, they fail to solve the problems for which they were built.

Executives know the stakes are high, but too often, they underestimate the chaos they’re stepping into.

Crystal Peterson, CEO of STG, has spent her career in the trenches of product delivery. She’s seen what happens when software vendors promise the world and deliver a mess. She’s heard every horror story and cleaned up the aftermath. In preparing this ebook, Crystal gathered insights, industry data, and notes from her experience, and the picture that emerges is bleak.

If you’re planning to invest in custom software, you need to know what you’re up against.

The High Cost of a “Cheap” Project

A couple of years ago, a bright and passionate startup founder approached STG with an ambitious idea for a custom software product. He had a clear vision, solid industry experience, and enough seed funding to make it happen—if it was done right. He was looking for a technology partner who could bring his idea to life with professionalism, quality, and strategic clarity.

STG, true to its methodology, didn’t rush to propose a solution. Instead, the team engaged in a thoughtful discovery process. They worked closely with the founder to fully understand the business objectives, product functionality, user experience goals, technical dependencies, and potential obstacles. What emerged was a clearly defined scope. It was realistic, grounded, and designed for success.

After completing the analysis and planning, STG presented the prospective client with a comprehensive proposal. The projected cost? Mid six figures. Not pocket change—but a fair price for a fully managed, high-quality software product delivery effort built for long-term market viability.

The founder responded with appreciation. He said he was impressed with the professionalism, rigor, and honesty STG had shown. He praised the people he met during discovery, saying he felt confident in their capabilities. But then came the turn.

Another firm had quoted him a price that was a fraction of the STG cost, and, to his ears, they were offering essentially the same outcome.

He went with the cheaper bid.

STG wished him well and invited him to come to them with questions as the initiative moved forward.

One Year Later: A Hard Lesson

When the founder returned to STG one year later, it was with a very different tone. In place of his self-assured nature was something more honest — a humbled recognition of how much he’d lost chasing a discount that never existed.

He had already spent roughly the same amount of money STG originally quoted. But unlike the outcome they had promised—a working, scalable product — he had almost nothing to show for it. The code was incomplete. The architecture was flawed. The UX was incoherent. The vendor had cycled through junior developers, moved deadlines, and avoided accountability at every turn. They had no real expertise, they had no plan, no roadmap, and no realistic path to launch.

The founder asked STG to evaluate what had been built so far. The STG team did a technical audit and confirmed his worst fears: there was nothing worth salvaging. The product was, in effect, vapor.

The cost of the “cheap” solution had turned out to be lost capital, lost time, and lost momentum. The founder wasn’t just behind schedule—he was back at square one.

The Pivot to STG’s Product Delivery

This time, the conversation was different. He didn’t need to be convinced of STG’s value. He had experienced firsthand the cost of cutting corners, and he was ready to do things right.

STG took a fresh look at the business objectives and reworked the delivery plan using the STG Product Delivery Framework. That meant tight integration between business goals and technical execution. It meant complete transparency on scope, schedule, and cost. It meant a skilled team led by seasoned professionals, not a rotating cast of freelancers. It meant building a product, not just writing code.

And this time, it’s all working.

STG delivered a clear strategy with disciplined execution. The client now has a partner who cares as much about the outcome as the client does.

The Takeaway

This story is more common than it should be. The software engineering world is full of vendors who offer low prices without delivering real value. Many C-suite leaders and startup founders have learned the hard way that what looks cheap can become the most expensive mistake of all.

In the pages that follow, we’ll break down how to spot the red flags, what a real software product delivery strategy looks like, and how companies like STG are rewriting the rules of software delivery success—one product at a time.

The Uncomfortable Truth

Bent Flyvbjerg’s research exposes the uncomfortable truth: software projects notoriously veer wildly off course—many not just slightly over budget or behind schedule, but catastrophically so. Some projects spiral hundreds of percent beyond their original budgets, deliver years late, and produce outcomes that barely resemble the intended value.

Flyvbjerg’s work was recently profiled in The Economist (May 8, 2025), which highlighted the systemic and often avoidable failures of software engineering initiatives worldwide. It is a sobering reminder of how fragile large-scale technology efforts can be—and how much is at stake for the organizations that sponsor them.

This ebook is for those who want to do better. It is written for C-suite executives and the technology professionals who advise them, and it seeks to explain why so many software projects flounder and fail—and, more importantly, how to avoid becoming one of them.

In my interview with Crystal Peterson, the CEO of STG, she pointed to several examples of high-profile failures. Each of them involves organizations that should have known better: Target, the Federal Bureau of Investigation, Zappos, Denver International Airport, and the Federal Government’s Healthcare.gov

Real Case: Target Canada’s software Disaster

When Target expanded into Canada, they tried to build a custom software backbone to support their new stores. To move fast, they partnered with low-cost vendors who lacked Canadian retail experience. Additionally, Target forced aggressive fixed timelines.

The result? The complexity of managing Canadian supply chains, bilingual packaging, and localized pricing was wildly underestimated. Inventory systems failed, and shelves were empty. The software just couldn’t keep up. Just two years later, Target shut down operations in Canada, taking a $5.4 billion write-off.

Real Case: FBI’s Virtual Case File (VCF) System

In the early 2000s, the FBI launched a $170 million contract with a vendor to replace their outdated case management system. It was a fixed-price deal, tightly scoped and locked down.

But the FBI’s needs evolved during the multi-year build, especially post-9/11. Unfortunately, the contract structure made it almost impossible to adapt without costly renegotiations. The vendor delivered a system that was fundamentally unusable. The FBI had to scrap the entire thing and start over, losing years of progress and costing hundreds of millions of additional capital expense.

Real Case: Target Canada (Again)

One of the many reasons Target’s Canadian systems failed? Their software vendors outsourced much of the development to junior offshore teams with little domain expertise. When Target tried to launch advanced retail functions—like automatic replenishment—the systems couldn’t handle it. Crucial data was missing or wrong. And there was no senior talent available to fix it quickly.

Real Case: Denver International Airport Baggage System

In the 1990s, Denver International Airport tried to build an ambitious, fully automated baggage handling system. They selected a vendor on a fixed-bid contract—focused entirely on delivering to spec by a set date.

But as development progressed, real-world complications emerged: multiple airlines with different needs, harsh Colorado weather, and unpredictable cargo sizes. The vendor lacked flexibility, and the system became a maintenance nightmare. After $560 million spent, the system was largely abandoned in favor of manual baggage handling.

Real Case: Healthcare.gov Launch Disaster

In 2013, the federal government launched HealthCare.gov—and it almost immediately crashed under user load. The site was developed under a waterfall-style, fixed-price contract. The team focused on checking off deliverables rather than understanding real user behaviors or scalability.

When 250,000 users hit the site on day one, it collapsed. Core software components hadn’t been tested together. Critical software integrations were fragile. The government had to scramble a new team for an emergency rescue operation—at great political and financial cost.

As Crystal explains, STG was built to solve the problems these projects highlight. STG works with clients to balance technical excellence, business strategy, and adaptive delivery. For STG, software products are only valuable when they actually accomplish the work intended by the innovators, leaders, and organizations that commission them.

Notice that STG doesn’t talk in terms of project management. Instead, they focus on software product delivery. For them, every custom software solution is a product, whether it’s built for internal use or commercial deployment. That shift in mindset—from completing a project to delivering a product—makes all the difference. It’s not about marking tasks complete; it’s about solving business problems, achieving the right outcomes, generating real value, and delivering actual results.

Crystal points out that the cases she shared illustrate common pitfalls associated with product delivery engagements.

• Underestimated Complexity
• Change Order Trap
• Junior Teams Behind the Curtain
• One and Done Thinking
• Misalignment with Business Goals

Underestimating complexity occurs when leaders of the initiative are inexperienced or unaware of software development challenges. These leaders are exploited by low-bid vendors who oversimplify what is required. They may skip discovery or gloss over details, only to have these issues raise significant barriers to successful completion.

These issues can be avoided when leaders demand a discovery phase before final pricing estimates are delivered. Leaders should ask how the vendor has handled scope changes on other projects. Ultimately, they must choose a partner who will talk about the risks and challenges involved in delivering great software product.

Change order traps are often built into fixed price contracts. Strict definitions of scope often overlook essential functionality that was clear in the mind of the buyer but was not as clearly communicated in the written contract. Each and every deviation from the initial scope results in change orders and upcharges. As a result, budgets are blown early in the process.

Project champions should ask vendors about past performance and their real-world experience with change orders, and the effect they have on overall product delivery cost. Time-and-materials or hybrid models that provide flexibility have been proven to be far more effective in the delivery of great software product.,. Expect transparency and work with vendors who deliver in small iterations rather than shooting for a big and perfect software release.

Junior teams behind the curtain are a common practice. The problem is not having junior developers on the product delivery team. Problems arise when senior experts abdicate their responsibilities for architecture, planning, leadership, and guidance. This abdication of senior leaders is common with low-price bidders who must rely on junior developers who are located offshore in an attempt to control costs. In these cases, quality suffers, communication breaks down, and deadlines are missed.

It is essential for leaders from the buying team to ask who will actually be doing the work. Understanding team composition will help protect quality and productivity. Effective buyers will insist on the involvement of senior team members. They will pay for the level of expertise of those doing the work, not just the number of bodies involved.

One-and-done thinking is symptomatic of vendors focused on short-term delivery instead of long-term success. These vendors do the minimum necessary to complete the strict interpretation of the contract scope. That often means that buyers will need to engage in a product rescue mission down the road.

These problems can be avoided when buyers start with the end in mind. Consider the future reality of taking possession of the product. What will it look like to maintain and upgrade the system as needs and circumstances change? Discuss with the vendor their role in the transition, maintenance, and ongoing development of the product

Buyers should choose vendors that have a strong history of post-launch support and knowledge transfer. Stay focused on product maintenance and scalability, not just getting to a minimum viable product. Press vendors to answer the questions of future product functionality and what support will really look like.

Misalignment with business goals is the result of both buyers and sellers failing to do the work necessary to understand the foundational needs, instead of simply the surface list of wants and wishes. The results are that products simply miss the functional needs of the business

Summary

These challenges can be avoided by choosing a partner with the experience to penetrate surface-level wants and get to the foundational business needs. Powerful partners will ask penetrating questions. Others will simply take orders. Insist on a vendor that understands both technology and business issues.

The Emotional and Strategic Cost

These aren’t just technical failures. They’re business failures.

Every delay costs you market share. Every feature that misses the mark damages trust. Every dollar spent on poor execution is a dollar you can’t spend on marketing, hiring, or growing your business

The founder asked STG to evaluate what had been built so far. The STG team did a technical audit and confirmed his worst fears: there was nothing worth salvaging. The product was, in effect, vapor.

What’s worse, many executives don’t realize how bad things are until it’s too late. They’re lulled into complacency by friendly meetings, confident pitches, and vague progress updates. By the time they realize the wheels are off, they’re halfway off the cliff.

The STG Difference: Software Product Delivery with Integrity

At STG, we don’t just manage projects. We deliver software products. That means:

We may not be the cheapest bid. But we’ll be the last one you need.

Going with the lowest bid might give you the illusion of saving money today—it might look good on paper, it might feel like the fiscally responsible thing to do, but it often costs far more in the long run. The most successful executives don’t look for the cheapest option when building great software product; they look for the smartest investment.

At STG, we partner with business leaders to deliver results—not regrets. Let us help you build something that works today—and scales for tomorrow.

What Executives Should Expect During a Software Development Engagement (And How to Know If Things Are On Track)

Executives don’t need to know how to code—but they do need to know how to lead. Software projects can feel like a black box to non-technical leaders, especially when progress isn’t clear or problems surface late. This guide outlines what executives should expect during each phase of a software project—and how to spot signs that things are off track early, before it’s too late.

How to Control Scope, Risk, and Cost Without Gambling on Quality

1. Expectation: There’s No Such Thing as a Perfect Plan

What to expect: Your software project should begin with discovery, planning, and alignment—but keep in mind that even the best plans will change as your software is being built. That’s normal. The initial discovery has 2 primary objectives:

A. Align on the Right Problem and the Hoped-for Solution

• Understand the users, workflows, and high-level pain points, so you’re solving the right problem.
• Clarify the business goals and define what success looks like.
• Validate assumptions and explore whether software really is the right solution.

B. Define Scope, Feasibility, and Risk

• Outline the high-level solution and key features (MVP vs. future phases).
• Identify technical constraints, dependencies, and unknowns.
• Estimate effort, timeline, and cost with greater confidence.

Be careful not to overdefine scope, as this will lock you into assumptions that will inevitably change.

How to know you’re on track:

• You’re involved in kickoff and discovery conversations.
• The team is transparent about risks, trade-offs, and uncertainties.
• Adjustments are made intentionally—not reactively.

Red flags:

• Everything sounds too good to be true (e.g., “no risks,” “exact timelines”).
• Plans are presented without business trade-offs or alternative options.

Pro Tips:

• Stay focused on “must-haves” and “should-haves” and persistently prioritize them.
• The perfect plan on day one is a fantasy. Choose adaptability.
• Budget for learning and surprises.
• Leave room for post-launch improvements.

2. Expectation: Iterative Delivery and Frequent Demos

What to expect: High-performing software delivery teams show progress in small, working pieces—not just at the end. The farther you go without feedback, the more expensive and risky mistakes become

How to know things are on track:

• You’re seeing demos or progress every 2–3 weeks.
• You can give feedback and see that your feedback is being incorporated.
• Progress is tied to business outcomes—not just features.

Red flags:

• No demos or usable work is shown for long periods.
• You’re told “it’s coming soon” too often without visual proof.
• You don’t know what to expect next.

Pro Tips:

• Demand working demos every 2-3 weeks.
• Celebrate small wins that demonstrate you are on the right track.

3. Expectation: Business Involvement, Not Just Technical Execution

Expectation: Business Involvement, Not Just Technical Execution

What to expect: You or another key executive leader should be actively involved throughout the engagement just signing off at the end. Chasing features without clear business outcomes leads to bloated scope, wasted effort, and unmet goals

How to know things are on track:

• Regular check-ins include both business and technical voices.
• The project evolves based on real feedback from users or stakeholders.

Red flags:

• You’re only being brought in at the beginning and end.
• You’re not being asked for feedback or priorities.
• Business value isn’t being discussed regularly.

Pro Tips:

1. Define successes in business terms not just technical deliveries. For example, “increase lead conversion by 15%
2. Tie every feature to a measurable business outcome
3. Prioritize persistently. Not everything is equally valuable.
4. Great delivery teams will challenge you on “nice to haves” that don’t tie to business outcomes

4. Expectation: Visibility Through Metrics and Reporting

What to expect: You should see clear indicators of progress, quality, and velocity. Remember, it is not just any problem that kills a product, it is the hidden problems.

How to know things are on track:

• You’re seeing dashboards or regular status updates that include:
  • Features delivered vs. planned
  • Bugs or defects over time
  • Team velocity (how fast they’re delivering working software)
  • Blockers or risks flagged transparently
• You feel confident that someone is watching the health of the whole project.

Red flags:

• Status updates are vague or subjective (“We’re making good progress”).
• You don’t see any measurable indicators of value delivered.
• No mention of risks, dependencies, or unknowns.

Pro Tips:

• Require regular status updates that include blockers, risks, and progress
• Look for delivery partners who alert you to bad news early–and who help you to solve it.
• Measure value delivered, not just tasks completed.
• Great delivery teamsVague updates like, “everything’s fine” or “everything is going well” are red flags. Insist on clear, specific reporting.will challenge you on “nice to haves” that don’t tie to business outcomes

5. Expectation: The Team Will Need to Say No Sometimes

What to expect: A good delivery partner isn’t afraid to challenge assumptions or push back—for the sake of your success.

How to know things are on track:

• The team explains trade-offs (e.g., “we can do X or Y, but not both this sprint”).
• They ask clarifying questions instead of blindly building.
• They suggest improvements to scope, process, or direction.

Red flags:

• The team always says yes—but struggles to deliver.
• No one is helping you prioritize.
• You feel like you’re driving everything without guidance.

Pro Tips:

• Choose the right contract structure to fit your goals.
• Consider flexible models like time-and-materials with caps or a hybrid model.
• Define clear collaboration expectations including how you will make decisions together.
• A vendor who truly shares your goals will help you manage risk, not just shift it to you
• If a vendor pushes back, or challenges an idea, it is worth hearing them out.

Executives don’t need to micromanage software projects—but they do need visibility, feedback loops, and strategic alignment. The most successful outcomes happen when business and technology leaders work hand-in-hand, with shared expectations and real-time course corrections.

Executives don’t need to micromanage software projects—but they do need visibility, feedback loops, and strategic alignment. The most successful outcomes happen when business and technology leaders work hand-in-hand, with shared expectations and real-time course corrections.

Controlling scope, risk, and cost isn’t about locking everything down—it’s about staying engaged, building adaptability into your mindset and process, and working with a partner who is committed to your outcomes, not just your contract.

STG helps clients understand what success looks like—and has a proven track record of delivery and insights to stay in control throughout the journey. As a result, they help executives deliver strategic technology products with confidence and clarity.

The Role of the Executive in Successful Product Development

Great software projects don’t succeed by accident. They succeed because of strong, visible leadership—not just from the technical team, but from the executive sponsors. As an executive, your role isn’t to code, design, or manage sprints. It’s to create the conditions for success, keep the business goals front and center, and make key decisions that drive momentum. Here’s how you can be the strategic force your project needs

1. Champion the “Why” (Not Just the “What”)

Why it matters: Teams can lose sight of the business impact when buried in technical work. Your job is to keep the purpose alive.

How to do it:

• Clearly communicate the business goals behind the project.
• Tie features and priorities back to measurable outcomes.
• Remind everyone that success is about impact—not just delivery.

Pro Tip: If your team can’t explain how their work connects to business success, it’s time to realign.

2. Set Clear Priorities (And Protect Them)

Why it matters: Projects don’t fail because of a lack of good ideas—they fail because of a lack of focus.

How to do it:

• Prioritize the most valuable outcomes and features first.
• Make tough trade-off decisions early and often.
• Shield the team from “shiny object” distractions that dilute results.

Pro Tip: A great executive doesn’t say “yes” to everything—they help the team say “yes” to the right things.

3. Stay Engaged Without Micromanaging

Why it matters: Your visibility drives urgency, accountability, and alignment—but heavy-handedness can stifle innovation.

How to do it:

• Attend key demos, reviews, and steering meetings.
• Ask smart questions about risks, value, and next steps.
• Trust your delivery team to own the “how” while you own the “why.”

Pro Tip: Your presence should feel like support and partnership—not surprise inspections or interrogation.

4. Make Timely Decisions to Keep Momentum Moving Forward

Why it matters: Nothing kills velocity faster than delayed decision-making.

How to do it:

• Be available for approvals, clarifications, and critical path decisions.
• Delegate decisions where appropriate—but stay close to key inflection points.
• Prioritize project needs alongside your other executive responsibilities.

Pro Tip: “No decision” is often worse than a “wrong decision.” Momentum matters.

5. Champion the Change Management Curve

Why it matters: Launching software is about more than technology—it’s about changing how people work.

How to do it:

• Communicate early and often with users and stakeholders.
• Help manage expectations about learning curves and adoption.
• Celebrate small wins to build enthusiasm and reduce resistance.

Pro Tip: Your visible support for change is often the single biggest factor in adoption success.

Executives aren’t passengers on the journey of software development—they’re the navigators. When you lead with vision, focus, engagement, and decision-making, you set your project—and your company—up for transformational success.

STG partners with executives to ensure software products not only launch, but that they deliver real business value. They invite executives and technology specialists to join with them to build something extraordinary together.

STG believes in delivering outcomes, not just output. They help executives make smart investments that lead to long-term success—not short-term regret. Their mantra remains, “Let’s build something that works today—and scales tomorrow.”

Summary

STG was built to solve the problems these projects highlight. We work with clients to balance technical excellence, business strategy, and adaptive delivery—because software is only valuable when it works for your business.

A Better Way Forward for Executive Decision-Makers

Insights from Crystal Peterson, STG CEO

If you’ve ever found yourself reflecting on a software project that didn’t meet expectations—maybe it overran timelines, missed the mark on functionality, or quietly fizzled into irrelevance—you’re not alone. These stories are far too common.

But Crystal Peterson wants you to know: it doesn’t have to be this way.

Crystal has spent her career helping business leaders make big decisions about outsourced software development. She knows what’s at stake—not just money, but reputation, momentum, morale, and even future innovation. And she’s seen how the wrong vendor or the wrong assumptions can turn a high-potential project into a cautionary tale.

But she’s also seen something else: the incredible, game-changing success that’s possible when you take the right approach.

At STG, that’s more than a philosophy—it’s a mission. Crystal and her team believe in partnership over transactions, outcomes over optics, and long-term impact over short-term price tags.

So if you’re a senior executive with a bold vision but unsure how to bring it to life without stepping into a minefield, this message is for you:

Additional Resources

• From Vision to Victory: What I Learned About Software Development From Two Experts Who Have Seen It All

• Interview with Mel Tingey: Why Even the Biggest Enterprises Need Help Getting Software Projects Right

• Case Study: How R. L. Williams Turned Tech Challenges into A Competitive Advantage with STG