Series · Project Management in the AI Era
Episode 1 · Project Management in the AI Era 1 - Why Traditional SI Failed
Project Management in the AI Era 1 - Why Traditional SI Failed
Project Management in the AI Era is a three-part history of traditional systems-integration stages and limits, financial and public-sector modernization, and the way AI reconnects requirements, design, delivery and validation. Part 1 asks why proposal, analysis, design, implementation, testing and transition became the standard sequence—and why the sequence repeatedly produced bottlenecks.
It is easy to dismiss the old method as obsolete. Financial and public systems, however, had to control budgets, contracts, audits, security, personal data, acceptance and the responsibilities of multiple vendors. Stages and documents were mechanisms for governing that complexity. The deeper failure was not the existence of stages. Knowledge returned too late, documents drifted away from reality and nobody clearly owned work at organizational boundaries.
What really moved through the six SI stages
Each stage created more than an artifact. It created a basis on which the next group was expected to act.
| Stage | Core question | Typical evidence | Common failure |
|---|---|---|---|
| Proposal | What can be delivered, when and for how much? | Proposal, estimate, WBS, assumptions and exclusions | Ambiguous scope sold at an optimistic price |
| Requirements | What does the client actually need? | Requirement specification, glossary, RTM | Verbal decisions, omissions and contradictions |
| Design | How will screens, data and integrations realize the need? | UI, API, database, batch and authorization design | Only the happy path is designed |
| Implementation | Can the design become working software? | Code, baseline and unit tests | Interpretation gaps and framework constraints |
| Testing | Can contracted quality be demonstrated? | Test plans, results, defects and retest evidence | Missing oracle and unrealistic data |
| Transition | Can production change be reversed safely? | Migration, release, rollback and handover plans | Gaps in access, data and recovery ownership |
The hardest work was judgment, not writing. A responsible lead had to decide technical feasibility, labor, schedule, cost, regulatory exposure and operational risk at once. A chain such as RFP-042 → REQ-117 → UI-023/API-014 → TC-308 → release 1.2 was necessary because change impact cannot be calculated when requirements, implementation and evidence are disconnected.
Trouble began when requirement counts became progress percentages. “Analysis is 90 percent complete” sounds safe, but the remaining ten percent may contain authentication, settlement or migration—the decisions that define the system boundary. Declaring the document complete does not remove uncertainty. It simply moves uncertainty into implementation and testing.
Waterfall's deeper weakness was delayed feedback
Winston Royce's 1970 paper is frequently used as the origin image for waterfall. The source is more complicated. Royce presented a sequence from requirements to operations, but did not recommend passing through it once. He argued for preliminary design, prototyping, building twice, documentation, early test planning, customer involvement and feedback into earlier stages. The Royce paper was concerned with the cost of discovering large-system errors late.
Contract baselines and acceptance remain necessary. Yet “the requirement document is approved” and “the user and delivery team understand the same problem” are different states. Users may not recognize what they need until they see behavior. Developers may not understand cost until they examine data, exceptions and failure paths.
The weakness was therefore not documentation itself. It was treating documents as a substitute for feedback and treating change only as a failure of control rather than evidence of learning. The same distinction remains visible in modern AI coding: producing an executable result quickly is not the same as solving the right problem.
Technology changed faster than Korean education and organizations
The provocative complaint that “professors are old and industry has no answer” identifies frustration but not cause. Korean IT changed faster than educational and organizational knowledge-renewal cycles. Policy, market demand, English documentation, translation, curricula, corporate standards and procurement all moved at different speeds.
The policy timeline was dense. Korean e-government records show eleven major initiatives in 2001–2002 and a 31-project roadmap in 2003–2007. The 2008 enforcement of disability anti-discrimination law pushed accessibility into system requirements. The first eGovFrame release arrived in June 2009. Public IT moved rapidly from basic computerization toward interagency integration, shared standards, accessibility and common frameworks.
International technology shifted just as quickly. Apache Struts began in 2000, Spring Framework 1.0 arrived in 2004, Node.js in 2009, React was open-sourced in 2013, and both Spring Boot 1.0 and the HTML5 Recommendation appeared in 2014. Korean teams experienced EJB, vendor and company frameworks, Struts or custom MVC, and Spring in compressed succession. That story connects to Korea's broader web development history.
The author experienced technology generations roughly three years apart, but this is not a national statistic. It describes an era when English source material moved through translation, books, courses, enterprise standards and procurement just as another generation appeared. Before social video and instantly searchable communities became normal, the information delay in a Korean-language market was substantial.
Age is not a useful proxy for competence. Curriculum revision, research and course preparation are slow; commercial tooling changes quickly. A professor who studied a recent decade could still lack production-level modern-web collaboration. A working developer could finish one framework migration only to meet the next. Knowing the newest library and understanding large-scale collaboration or production operations are also different capabilities.
The credit-card crisis and IT workforce expansion need separate evidence
The event sometimes called the “2000 card crisis” is more accurately the 2002–2003 Korean credit-card debt crisis. KDI and the IMF's 2004 Korea consultation show rapidly expanded card use, delinquency, impaired assets and liquidity pressure during this period. The IMF reported roughly 2.3 million delinquent borrowers and impaired assets of 34.2 percent in November 2003.
The government's contemporary policy record documents that it anticipated a large IT labor shortage around 2001 and expanded training while e-government investment grew. What has not been verified is a direct national causal claim that SI absorbed unemployment from the card crisis at scale.
The author remembers large numbers of career changers entering development. That should remain field memory, not be upgraded into statistics. The stronger structural point is that an industry can add people quickly without simultaneously creating deep expertise, stable role definitions and funded learning time.
Mixing development testing and operations architecture erased ownership
Listing WAS clusters, connection pools, memory, threads, files and monitoring does not demonstrate expertise. The useful question is: who verifies what, at which point, and who has the authority to recover when it fails?
Development should own functional completeness, unit, integration, contract and regression testing, application memory leaks and thread safety, file lifecycle policy, and the instrumentation required for logs, metrics and traces. Operations or platform teams should own production access, WAS and load-balancer topology, deployment approval, infrastructure capacity, backup, recovery, alerting and runbooks.
Connection pools, performance targets, load and recovery testing, and observability schemas cross that boundary. A connection pool is application configuration constrained by database session limits and the number of runtime instances. A memory incident may be a code leak or a runtime limit. It cannot be assigned responsibly without evidence.
An organization that delegates production code, server and database privileges, monitoring and tuning entirely to an external vendor has abandoned service ownership. An operator who labels every unfamiliar area “not my role” has also failed the service. Mocking individuals does not solve either problem. Organizations must provide a RACI, approval authority, learning time, runbooks and incident command.
The central failure of traditional project management was not the number of stages. Feedback was late, documents were not synchronized with real knowledge, and boundary work lacked a final owner.
The next technology wave began on top of unresolved limits
Traditional project management was not useless because it lacked one universal answer. It was a minimum language for contracts, acceptance, large-team coordination and operational risk. Its cost was the human effort required to update documents, remember dependencies and translate intent at every handoff.
Technology did not wait for those limits to be solved. Mobile, web standards, Git, SPAs and APIs arrived on top of incumbent organizations. These traditional project management, SI project stages, SI requirements analysis and Korean financial IT controls were the minimum structure supporting contracts and operations. Part 2 follows the way projects strengthened documentation and testing through repeated failure while simultaneously absorbing a new delivery platform.
No comments:
Post a Comment