A ticking bomb in IT outsourcing projects that has caught the U.S. government as well

Do you remember the 'Healthcare.gov' chaos in 2013 that caused a stir across the United States? The government official website, which was supposed to handle the enrollment of healthcare for all Americans, crumbled tragically on its opening day despite the investment of hundreds of billions of won. It was a disaster where only a few hundred people managed to register in the first week, let alone sign up or even connect properly.

Was it a server crash? Or were there only incompetent developers gathered? Surely the U.S. government, the largest organization in the world, wouldn't do that. Many experts analyzed the causes of this failure, and surprisingly, they identified this as the main culprit: a total failure in requirements management.

With dozens of government agencies and insurance companies entangled as stakeholders, conflicting requirements poured in. Under the vague goal of 'it should be easy for all citizens to use', specific policies and function definitions kept changing and weren't communicated properly. In fact, the detailed policies and regulations of the ACA bill were continuously revised during development, with key decision-making bodies like the White House and the Department of Health and Human Services frequently requesting changes and additions to functions. The official report from the U.S. Government Accountability Office (GAO) sharply pointed out this issue. Ultimately, the development team ended up wandering endlessly, creating a monster that was unusable.

Obama "Connection issues are not the essence" Former President Obama of the United States faced attacks on the policy itself due to the website connection issues. Source: AP photo/Evan Vucci

You might think, 'Hey, isn't that a special example of a massive project tangled with the whole country?' But some of you might feel a sense of déjà vu. Working in the IT outsourcing industry, you hear clients every day say things like "Please make this part more refined", "Oh, this part has been revised", "Make it fit the MZ generation's tastes". How different are these from the issues that paralyzed Healthcare.gov?

These seemingly trivial vague requirements are, in fact, ticking bombs quietly eating away at the project, and today I want to properly discuss how to defuse this bomb.

1. A project that began with 'feel' ends in a 'nightmare'

"Client, what direction do you want for the design of the renewed website?" "Hmm... I would like it to be refined and intuitive. In today's style."

If you have ever done an outsourcing project, this conversation will not sound unfamiliar to you. This 'feel' conversation often becomes the seed of tragedy. The development team cannot enter and exit the client's mind, so they begin imagining their own notions of 'refinement' and 'intuitiveness'.

The PM would relay it to the designer like this.

"Designer, the client wants something refined. Shall we draft an idea in the trendy minimalism style? A lot of white space and a clean Gothic font."

A few days later, the designer confidently presents a draft worked on overnight. However, the client's reaction is cold.

"Ah... the 'refinement' I was thinking of is not like this... it's too bland. I would prefer it to be more elaborate... with richer colors. Like Apple."

At this moment, the minds of the PM and the designer turn blank. Apple is the essence of minimalism, yet they want something elaborate and rich in color? What the client referred to as refinement was closer to the luxurious image conveyed by brands like Apple. Ultimately, the design work goes back to square one. In this process, several days of time and designer resources have already vanished into thin air.

Is it just design? The functionality development is even more serious. A one-liner requirement like "Please add an editor that allows users to conveniently write" hides dozens of questions. For example:

• The swamp of missing questions:

  • Is file attachment possible? If yes, what are the size limits? (Image? Video? PDF?)

  • Is an auto-save feature needed? How often should it save?

  • Where can the temporarily saved document be retrieved?

  • Should there be a 'preview' feature before publishing?

  • Should special formatting like tables or code blocks be supported?

  • Should it work the same way in mobile environments?

Developers spend more time organizing these questions and getting answers from the client through the PM than actually coding. If responses are delayed, the development schedule halts. Imagine this process repeating throughout the project. Productivity drops in an instant.

2. The cost of ambiguity: your money and time are melting away 

From the client's perspective, they might think, "Aren't professionals supposed to suggest and create things well on their own? That's why I'm paying them." This is, of course, a valid point. But the problem lies in the fact that the standard of 'doing it well on their own' varies greatly from person to person.

We can refer to the costs arising from this process as interpretation costs and rework costs.

• Interpretation Cost: This refers to all the time and effort the development team uses to interpret the client's vague words, infer hidden intentions, and ask endless questions.

• Rework Cost: The cost incurred from discarding a result created due to incorrect interpretation and remaking it. This goes beyond simple waste of time and personnel; it often becomes a major factor in lowering team morale.

This is akin to telling an architect to "build a wonderful house on their own" without a blueprint. Once all the walls are up, saying, "The living room is smaller than I thought; please tear it down and rebuild it" is like that. Who ultimately bears the costs of building and tearing down the walls? The property owner, i.e., the client.

In fact, according to the authoritative report from the Standish Group on IT project management, one of the biggest causes of project failure is consistently cited as 'Unclear Requirements'. This means it's not just an issue for a few companies, but a chronic problem faced by the entire industry.

There's an even scarier cost: the destruction of trust. The client thinks that they are dealing with a frustrating developer who keeps asking questions without competence, while the developer sees the client as a frustrating person who doesn't even know what they want. Once trust is broken, it grinds everything to a halt and becomes a burden until the project's end.

Nothing is more painful than the absence of shared understanding. Source: Gemini Generation

3. Clearing the fog to clarity: How to save 'our' project

So how can we break this vicious cycle? It doesn't require an elaborate methodology. Simply clearing the fog of ambiguity and bringing the project onto the ground of clarity with a few promises is sufficient.

First, translate abstract language into concrete 'data'.

Instead of subjective expressions like 'refined', 'intuitive', and 'user-friendly', establish verifiable standards that can be seen visually.

In this process, tools like wireframes, prototypes, and user stories become not just simple planning outputs but powerful languages that help the client and development team visualize the same picture.

Second, share 'user scenarios' and 'policies' rather than just a list of functionalities.

Saying something like "Please add a 'content approval' feature to the admin page" is one of the worst communication methods. If there's no context about why the feature is needed and who uses it in what order, developers will get lost.

• Bad example: "Add content approval feature"

• Good example: "When a marketing team intern (role) drafts content, an automatic notification goes to the manager (role). The manager should be able to review and approve or reject the content (scenario). When rejected, they must leave a reason for rejection in text (policy), and approved content is automatically published on the website at the scheduled time (automation policy)."

By sharing this context, developers can go beyond simply creating an 'approval button' to consider how to effectively convey rejection reasons and how to handle if automatic publishing fails. This process transforms developers from mere coders to problem-solving partners.

Third, create a single 'source of truth' that everyone agrees on.

All requirements, policies, and decisions related to the project should be recorded and managed in a single document. Collaboration tools like Notion or Confluence can be excellent tools for this. Why is Figma considered good? Isn’t it because it allows you to share a single link, avoiding the hassle of dealing with numerous PPTs and Word files that claim to be the “final versions”? This source of truth is needed in all processes, from organizing client requirements to giving instructions for development.

Verbal agreements made in meetings are like gasoline. At the moment, everyone seems to understand, but once they turn away, they each remember differently. All discussion outcomes must be documented in this source of truth, and any changes must be immediately updated to synchronize all team members on the same content, including getting confirmation from the client. This document will be our most robust shield and compass to protect our project.

Conclusion: A good blueprint makes a great developer

So far, we have examined how vague requirements and frequent policy changes can sink billion-won projects (the Healthcare.gov incident) and jeopardize our everyday outsourcing projects. A project lost in the fog of ambiguity ultimately reaps bitter fruits of distrust, waste, and failure.

Ultimately, the solution lies in a very simple truth: transforming 'feel' into 'data', 'feature lists' into 'clear user scenarios', and 'verbal agreements' into 'documented commitments.' This does not mean simply making more documents to annoy developers. It is a promise to communicate in the same language and look at the same picture towards the shared goal of project success.

Since outsourcing development has a greater distance between clients and developers, it is all the more essential to have accurate and clear planning and design, i.e., a great blueprint. When clients provide clear guiding keys for problem-solving and developers become powerful engines that move in that direction, we can finally reduce the risks of failure and move closer to success.

As important as a developer's coding skills is providing a clear roadmap to ensure that their exceptional skills are not wasted in the wrong places. I hope everyone remembers that great results are not solely created by outstanding developers but are products of collaboration among people who share clear goals.

manyfast.io