Series · Project Management in the AI Era
Episode 2 · Project Management in the AI Era 2 - How Korean SI Modernized
Project Management in the AI Era 2 - How Korean SI Modernized
Part 2 of Project Management in the AI Era examines two processes that happened at once. Korean financial and public-sector projects accumulated management capability by paying for repeated failures. At the same time, new technology arrived before the ownership, learning and feedback problems from Part 1 had been solved.
Documentation, testing, Jira, Git and code review genuinely improved delivery. Yet compressed Korean schedules rarely funded enough time to operate those methods fully. The mobile explosion then forced organizations that were still struggling with old boundaries to adopt several new platforms. This is not a simple story of old incompetence and new tools. It is a history of management learning colliding with compulsory modernization.
Failure accumulated into client and vendor capability
Financial and public systems are not computerized once. Core replacements, channel upgrades, regulatory change, migration and performance programs repeat. Clients remember requirements omitted from the previous contract, disputes at acceptance, data that failed on cutover night and incidents handed to operations without ownership. Vendors learn which ambiguities explode late and which evidence protects delivery.
That experience became more explicit RFPs, requirement templates, standard deliverables, security and accessibility checklists, test classifications, migration plans and operations-acceptance criteria. eGovFrame and reusable components were never universal solutions, but they reduced the cost of rebuilding a baseline for every project.
In the author's experience, many Korean projects below KRW 1 billion converged on four-to-six-month schedules. This is not a market statistic. Project type, procurement, scope and reuse matter enormously. A short schedule may demonstrate learning and reuse, or it may hide scope and compress people and overtime.
A shorter schedule may be evidence of maturity—or evidence that management and validation time has been removed from the estimate. Duration alone does not prove progress.
Requirements are the client's quality line and the vendor's defense
Calling requirements documentation “administration” misses its contractual purpose. For the client, requirement IDs and a traceability matrix are the final minimum quality line. They provide evidence for rejecting omitted behavior, arbitrary rule changes and untested exceptions.
For the vendor, the same record is a shield. It proves that agreed work was delivered and creates a basis for refusing unlimited free work outside the contract. When REQ-117 connects to UI-023, API-014, TC-308 and a release, a memory contest becomes a conversation about evidence.
Japan makes the role of funded upstream work easier to see. The IPA 2024 Software Trends Survey says waterfall remains the leading development model. IPA's Requirements Definition Guide for Users gives detailed structures for upstream problems, agreements and document flows.
No national evidence was found for the stronger claim that Japanese design phases routinely last more than one year. Long upstream phases can be described as large-project cases and industry reputation, not a universal national rule.
Korean mid-sized work often cannot extend beyond six months, making it hard to fund analysis, design review and document synchronization at the level promised by the method. The author observed KB Kookmin Bank-related projects that emphasized design documentation, only for documents to become stale and expensive when they could not follow implementation change. This is bounded field experience, not a verdict on the bank as an institution.
The repeated attempt to document is itself important. Documentation did not fail because it was unnecessary. Projects failed to include the time required to keep evidence alive. The practical choice sits between formalism that mistakes page count for quality and unmanaged delivery that abandons traceability.
Agile and Jira exposed the specification—and its management cost
The Agile Manifesto does not abolish documentation or planning. It values individuals and interaction, working software, customer collaboration and response to change more highly. In Korean contract delivery, sprints, Scrum and Kanban were often placed partially on top of waterfall baselines.
“Agile” sometimes became marketing language for a shorter deadline. Teams renamed meetings without funding backlog refinement, giving customers weekly decision authority or creating a release architecture for small increments.
Jira boards make todo, in-progress and done visible. Their deeper function is to turn issue type, state, owner, acceptance criteria, dependency and definition of done into a management specification. Decomposition, refinement, evidence linking and state maintenance are real work. If that work is absent from the WBS, Jira becomes a reporting board decorated before meetings rather than a model of reality.
Today's contrast between vibe coding and specification-driven development repeats the same tension. Vibe coding reaches an executable result quickly but increases late regression and traceability risk when requirements and tests are weak. Specification-driven work can combine explicit acceptance with TDD, but it requires analysis and management time.
TDD is not identical to specification-driven development. It is a small test-implementation-refactor loop. A specification pipeline manages the broader relationship from requirement through design, code, tests and release. Both reflect software engineering's recurring negotiation between speed and explicit knowledge.
Git and code review turned change into team evidence
Git materially changed the economics of implementation, testing and transition. Distributed repositories and branches let people create changes independently, inspect diffs in pull or merge requests, and retain release baselines in main, staging, tags and releases. As Git's history explains, distributed and nonlinear development changed the collaboration model itself.
Git is not CI/CD. It provides change, branching and merge history. Hosting and automation platforms execute builds, tests, security scans, environment approvals, deployment and rollback. GitHub's continuous deployment guidance illustrates those environment and approval controls.
Code review also turned individual work into team knowledge. A PR retains why a change exists, its affected area, test evidence and the discussion around risk. Useful review prioritizes defects, security, API compatibility, concurrency, migration and operability over style disputes.
New bottlenecks followed: oversized PRs, ceremonial approval, review hierarchy and queues. Automated checks and peer review are not substitutes. Machines should evaluate repeatable rules; humans should evaluate intent and domain risk. The rise of CodeRabbit AI PR review shows that this boundary is moving again.
Modern web fragmented a JSP-dominated market
The mobile market did not wait for Part 1's ownership and learning problems to disappear. Smartphones, tablets, web standards, Angular, React and Node pushed a Korean market centered on server-rendered JSP into several delivery platforms.
Servers began exposing data and business capability through API contracts for web, mobile and partners. JPA symbolized wider object and domain-oriented persistence, but using JPA does not create a domain model by itself. OAuth standardized delegated authorization and helped services connect across channels without sharing user passwords. That is ecosystem extensibility, not performance scalability.
The server did not become a passive data container. It still owns domain rules, transactions, authorization, audit and integration. Frontends moved rendering and state away from server templates, reducing direct dependency on backend presentation. Asynchronous data, transitions, animation and client rendering increased UI quality across phone, tablet and desktop.
JSP-centered delivery fragmented into SPAs, native and hybrid mobile apps, API servers and BFFs. Independence increased, but so did API versioning, contract tests, CORS, token security, distributed observability and frontend-backend coordination. Korea's web development history is also a history of multiplying responsibility boundaries.
Management learning and forced modernization happened together
Korean project management did improve. Failure became requirements and test criteria. Jira made work visible. Git and code review made change reproducible evidence. Modern web increased channel and team independence.
Part 1's problems nevertheless remained. New tools and professions were added on top of short schedules, underfunded learning, stale documents and unclear ownership at boundaries. As methods became more rigorous, the number of relationships people had to maintain also increased.
This is the contradiction accumulated by Korean SI project management. Requirements documentation, Git delivery automation and modern web architecture reduced specific failures while increasing the relationship graph. Part 3 asks what happens when AI can read and update requirements, screens, design, code, tests and release evidence together.
No comments:
Post a Comment