Split View: IT 프로젝트 산출물 완전 가이드: 기획부터 종료까지 모든 문서 정리

IT Project Deliverables Complete Guide: All Documents from Planning to Closure

• Introduction
• 1. Pre-Project Phase — Planning and Proposal
  • 1-1. RFP (Request for Proposal)
  • 1-2. Proposal
  • 1-3. Project Management Plan (PMP)
  • 1-4. Contract and NDA (Non-Disclosure Agreement)
  • 1-5. WBS (Work Breakdown Structure)
  • 1-6. Kick-off Report and Presentation
  • 1-7. Stakeholder Register
• 2. Analysis Phase — Requirements
  • 2-1. As-Is Analysis Report
  • 2-2. Software Requirements Specification (SRS)
  • 2-3. Business Requirements Specification (BRS)
  • 2-4. Use Case Specification
  • 2-5. Interview and Survey Results
  • 2-6. Legal and Regulatory Requirements Analysis
  • 2-7. Benchmarking Report
  • 2-8. Analysis Review Report
• 3. Design Phase
  • 3-1. System Architecture Design
  • 3-2. Application Architecture Design
  • 3-3. UI Storyboard (Screen Design)
  • 3-4. Database Design (including ERD)
  • 3-5. Table Definition Document
  • 3-6. Interface Design Document (I/F Design)
  • 3-7. Coding Standards and Conventions
  • 3-8. Security Design Document
  • 3-9. Deployment Architecture Design
  • 3-10. Design Review Report
• 4. Implementation Phase — Development
  • 4-1. Source Code
  • 4-2. Unit Test Cases and Results
  • 4-3. Code Review History
  • 4-4. Build and Deployment Scripts
  • 4-5. Issue Tracker Log
  • 4-6. Weekly/Monthly Progress Report
  • 4-7. Technical Meeting Minutes
• 5. Testing Phase
  • 5-1. Test Plan
  • 5-2. Test Case Definition
  • 5-3. Unit Test Results
  • 5-4. Integration Test Results
  • 5-5. System Test Results
  • 5-6. Performance Test Results
  • 5-7. Security Vulnerability Assessment Report
  • 5-8. Defect List and Remediation Record
  • 5-9. UAT (User Acceptance Test) Results
  • 5-10. Test Completion Report
• 6. Migration/Go-Live Phase — Cutover
  • 6-1. Data Migration Plan
  • 6-2. Data Migration Results
  • 6-3. Cutover Plan (Migration Scenario)
  • 6-4. Cutover Checklist
  • 6-5. Go-Live Report
• 7. Closure Phase — Delivery and Project Wrap-Up
  • 7-1. User Manual
  • 7-2. Administrator Manual (Operator Manual)
  • 7-3. System Operations Guide
  • 7-4. Incident Response Runbook
  • 7-5. Software Configuration Management (SCM) List
  • 7-6. Project Completion Report
  • 7-7. Warranty and Maintenance Plan
  • 7-8. Lessons Learned
  • 7-9. Knowledge Transfer Materials
• 8. Public Sector — Specialized Deliverables
  • 8-1. Information Strategy Plan (ISP)
  • 8-2. Privacy Impact Assessment (PIA)
  • 8-3. Information Security Plan
  • 8-4. Software Project Cost Estimation Document
  • 8-5. Software Audit Report (SW 감리 보고서)
  • 8-6. Copyright Ownership Confirmation
  • 8-7. Delivery Acceptance Certificate (납품 확인서)
• 9. Practical Tips for Deliverable Management
  • 9-1. Document Numbering Scheme
  • 9-2. Configuration Management
  • 9-3. Tool Recommendations
  • 9-4. PMBOK Deliverables vs. Korean Practice
• Quizzes: Test Your Knowledge
• Conclusion

Introduction

Successfully delivering an IT project requires more than writing good code — it demands systematic production and management of deliverables at every phase. In the Korean IT industry, particularly in public sector projects, deliverable requirements are strictly regulated by law and administrative guidelines.

This guide covers every document that must be produced from the pre-project planning and proposal stage through analysis, design, implementation, testing, migration (go-live), and closure. For each document, we explain who produces it, what it must contain, and the practical pitfalls to watch out for.

1. Pre-Project Phase — Planning and Proposal

This phase covers procurement and planning activities between the client and prospective vendors before the project officially starts.

1-1. RFP (Request for Proposal)

• Owner: Client organization
• Key contents: Project purpose, scope, high-level requirements, budget ceiling, delivery schedule, evaluation criteria
• Caution: Technical requirements and pricing requirements must be submitted separately. For public sector projects, the RFP must satisfy posting requirements on the G2B (Government-to-Business) procurement platform (나라장터). Overly detailed functional requirements may limit competition.
• Practical tip: An ambiguous RFP multiplies risk at the proposal stage. Use the formal Q&A period aggressively to clarify intent.

1-2. Proposal

• Owner: Vendor
• Key contents: Technical proposal (methodology, staffing plan, schedule, technology stack) and price proposal (total cost, basis for person-day estimates) submitted separately
• Caution: The price proposal must be physically separated from the technical proposal so that evaluators assess technical merit without knowing the price.
• Practical tip: Match the proposal length to the client's requirements, and place your key differentiators at the front.

1-3. Project Management Plan (PMP)

• Owner: Vendor PM
• Key contents: Project scope definition, chosen methodology (waterfall / agile / hybrid), staffing plan, draft WBS, deliverables list, risk management plan
• Caution: Some projects require this before contract signing; others require a final version at kick-off. For public sector projects it is typically submitted at the kick-off meeting.

1-4. Contract and NDA (Non-Disclosure Agreement)

• Owner: Legal/contracts team for both parties
• Key contents: Contract scope, payment terms, liquidated damages for delays, warranty period and conditions, IP ownership, confidentiality
• Caution: The warranty period (usually one year) and SLA conditions must be explicitly stated. Software copyright ownership must also be specified.

1-5. WBS (Work Breakdown Structure)

• Owner: PM + Lead developer
• Key contents: Hierarchical decomposition of all project work, milestone definitions, owner/duration/dependencies for each work package
• Caution: A WBS is not just a Gantt chart. Decompose to the work package level so every task has a clear, accountable owner.

1-6. Kick-off Report and Presentation

• Owner: PM
• Key contents: Official project start declaration, team introductions, overall schedule, communication plan, weekly reporting cadence, issue escalation path
• Caution: The kick-off meeting must produce expectation alignment between client and vendor. All agreements made at kick-off must be captured in meeting minutes.

1-7. Stakeholder Register

• Owner: PM
• Key contents: Contact details, roles, decision-making authority, and interest/influence classification for all stakeholders on the client, vendor, and third-party sides
• Caution: PMBOK recommends pairing the register with a Stakeholder Engagement Plan.

2. Analysis Phase — Requirements

This phase captures the current state and defines what the new system must do.

2-1. As-Is Analysis Report

• Owner: Business analyst / consultant
• Key contents: Current business processes (BPM), existing system function inventory, data flows, operational staffing, bottlenecks and pain points
• Caution: This document must be written from the perspective of frontline users gathered through interviews and workshops. Skipping As-Is analysis leads to rampant requirements omissions.

2-2. Software Requirements Specification (SRS)

• Owner: Analyst + client stakeholders
• Key contents:
  • Functional requirements: Specific functions the system must perform
  • Non-functional requirements: Performance, availability, security, scalability, maintainability
  • MoSCoW prioritization: Must Have / Should Have / Could Have / Won't Have
• Caution: Assign a unique ID to every requirement to ensure traceability. These IDs map one-to-one with test cases later.

2-3. Business Requirements Specification (BRS)

• Owner: Business analyst + client
• Key contents: Business-level requirements, business rules, glossary, organizational charts
• Caution: The BRS sits above the SRS. It captures business intent before technical details are specified in the SRS.

2-4. Use Case Specification

• Owner: Analyst
• Key contents: Actor definitions, use case diagram, basic/alternative/exception flows per use case, pre- and post-conditions
• Caution: Follow UML notation strictly. As use case count grows, management complexity grows with it. Supplement complex use cases with sequence diagrams.

2-5. Interview and Survey Results

• Owner: Analyst
• Key contents: Interviewee details, date, question list, summarized answers, derived requirements
• Caution: Always obtain the interviewee's signature confirming the summary. This prevents "I never said that" disputes later.

2-6. Legal and Regulatory Requirements Analysis

• Owner: Analyst + legal/security team
• Key contents: Analysis of applicable laws: Electronic Financial Transactions Act, Personal Information Protection Act, Act on Promotion of Information and Communications Network Utilization, ISMS-P, PCI-DSS, and public sector information security guidelines
• Caution: Regulatory requirements are mandatory, not optional. Identify them before the design phase so they can be incorporated into the architecture.

2-7. Benchmarking Report

• Owner: Analyst / consultant
• Key contents: Case studies of similar systems or services, feature comparison matrix, technology trends, rationale for benchmark targets
• Caution: Benchmarking results must genuinely feed into requirements. A benchmarking report that sits in a drawer is wasted effort.

2-8. Analysis Review Report

• Owner: PM + client stakeholders
• Key contents: Completeness, consistency, and traceability review of requirements; issues found and action items; sign-off on the analysis phase
• Caution: For public sector projects, this ties into the phase-level software audit (감리) report.

3. Design Phase

The design phase translates analyzed requirements into technical specifications that can be implemented.

3-1. System Architecture Design

• Owner: Architect / technical lead
• Key contents: Overall system diagram, HW/SW/NW specifications, rationale for technology stack choices, redundancy and high-availability (HA) design, disaster recovery (DR) plan
• Caution: Documenting Architecture Decision Records (ADRs) lets you trace the rationale for design choices when changes are requested later.

3-2. Application Architecture Design

• Owner: Architect / senior developer
• Key contents: Layer structure (Presentation/Business/Data), component diagrams, microservice boundary definitions, API gateway design, inter-service communication patterns
• Caution: The monolith vs. microservices decision must account for the team's operational maturity, not just technical preference.

3-3. UI Storyboard (Screen Design)

• Owner: UX designer + analyst
• Key contents: Wireframes for every screen, screen flow diagrams, UI component descriptions, validation rules, error message definitions
• Caution: Development must not begin until the client approves the screen design. Starting without approval typically results in large-scale rework.

3-4. Database Design (including ERD)

• Owner: DBA + developer
• Key contents:
  • Logical data model: Entities, attributes, relationships (ERD)
  • Physical data model: Table names, columns, data types, PK/FK, index strategy
  • Normalization level, partitioning strategy, archiving policy
• Caution: Keep logical and physical models separate. Mixing them causes confusion.

3-5. Table Definition Document

• Owner: DBA
• Key contents: Column name / Korean name / data type / length / nullable / default value / description per table; PK/FK/index list; code table definitions
• Caution: Data standards (terminology, domain, code) must be applied consistently. Public sector projects must follow the Ministry of the Interior and Safety data standards guidelines.

3-6. Interface Design Document (I/F Design)

• Owner: Interface developer + analyst
• Key contents: List of external system integrations; per-interface method (REST API / SOAP / file / batch / EAI-ESB / message queue); request/response message specs; error code definitions; interface testing approach
• Caution: Agreements reached with external system owners must be documented. API contracts must be explicit.

3-7. Coding Standards and Conventions

• Owner: Technical lead
• Key contents: Naming conventions (variables, classes, functions, DB objects), commenting rules, exception handling patterns, logging standards, code style guide, linting configuration (ESLint, Checkstyle, etc.)
• Caution: Standards not enforced by tooling are rarely followed. Integrate linting checks into the CI pipeline.

3-8. Security Design Document

• Owner: Security architect / specialist
• Key contents: Authentication and authorization framework (OAuth2, JWT, SSO); access control design (RBAC/ABAC); encryption strategy (in transit and at rest); security logging policy; API security (rate limiting, input validation)
• Caution: Use OWASP Top 10 as a checklist to identify and mitigate threats at the design stage.

3-9. Deployment Architecture Design

• Owner: DevOps / infrastructure engineer
• Key contents: Server/container (Docker/Kubernetes) configuration, network diagram, load balancer/CDN setup, CI/CD pipeline design, monitoring stack (Prometheus/Grafana/ELK)
• Caution: Differences between production and development/test environments must be documented.

3-10. Design Review Report

• Owner: PM + technical lead + client
• Key contents: Review of design completeness, consistency, and implementability; review comments and action plan; sign-off on the design phase
• Caution: A design review is not a rubber-stamp formality. Genuine technical scrutiny at this stage dramatically reduces risk in the implementation phase.

4. Implementation Phase — Development

This phase covers writing code according to design specifications and performing initial validation.

4-1. Source Code

• Owner: Developers
• Key contents: Git repository management, branching strategy (GitFlow or trunk-based development), commit message conventions, code review policy
• Caution: Source code is the most critical deliverable. Final delivery is based on a clearly tagged release version.

4-2. Unit Test Cases and Results

• Owner: Developers
• Key contents: Test cases per module/function, input/expected output pairs, execution results, coverage report (JaCoCo, Istanbul, etc.)
• Caution: Agree on a coverage target (e.g., minimum 70% code coverage) upfront and measure it automatically in the CI pipeline.

4-3. Code Review History

• Owner: Entire development team
• Key contents: PR (Pull Request) / MR (Merge Request) records, reviewer comments, revision history, quality checklist compliance
• Caution: Code reviews serve not only to catch bugs but also to share knowledge and enforce coding standards.

4-4. Build and Deployment Scripts

• Owner: DevOps / developer
• Key contents: CI/CD pipeline definition files (Jenkinsfile, GitHub Actions YAML, GitLab CI), Docker image build scripts, Kubernetes manifests, Terraform/Ansible infrastructure code
• Caution: Applying Infrastructure as Code ensures environment reproducibility.

4-5. Issue Tracker Log

• Owner: PM + developers
• Key contents: Issues registered in Jira/Redmine/GitHub Issues, issue type (bug/feature/improvement/tech debt), priority, assignee, resolved date, resolution details
• Caution: The issue tracker is the most important tool for real-time project visibility. Issues resolved only via chat or email leave no traceable history.

4-6. Weekly/Monthly Progress Report

• Owner: PM
• Key contents: Tasks completed this week, progress rate (planned vs. actual), issues and risks, next week's plan, change log
• Caution: Reports must be factual. Overly optimistic reporting only makes later problems worse.

4-7. Technical Meeting Minutes

• Owner: Designated note-taker
• Key contents: Date/attendees/agenda, discussion summary, decisions made, action items (with owner and due date)
• Caution: Technical decisions must always be documented. Verbal-only agreements breed "we never decided that" disputes later.

5. Testing Phase

This phase verifies that the developed software satisfies the requirements.

5-1. Test Plan

• Owner: QA lead / PM
• Key contents: Test scope, test types (unit/integration/system/performance/security/UAT), test environment, entry/exit criteria, schedule, owners, test tools
• Caution: Test planning should begin during the design phase. Planning after development is finished is too late.

5-2. Test Case Definition

• Owner: QA engineers
• Key contents: Test case ID, requirement ID (traceability), test scenario, preconditions, inputs, expected result, actual result, verdict (Pass/Fail)
• Caution: Maintain a Requirements Traceability Matrix (RTM) mapping requirement IDs to test case IDs.

5-3. Unit Test Results

• Owner: Developers
• Key contents: Test results at module/component level, pass/fail list, coverage figures
• Caution: Unit testing is the developer's responsibility. Offloading it to QA lowers development quality.

5-4. Integration Test Results

• Owner: QA engineers + developers
• Key contents: Inter-module integration, external interface testing, batch/scheduler integration, data flow validation
• Caution: Secure a test environment from external system owners well in advance of the integration testing window.

5-5. System Test Results

• Owner: QA team
• Key contents: Full system functional testing, end-to-end (E2E) scenarios, regression testing, installation/deployment testing
• Caution: The system test environment should mirror production as closely as possible.

5-6. Performance Test Results

• Owner: Performance test engineer
• Key contents: Target TPS (transactions per second), response time target (e.g., under 2 seconds), concurrent user count, load/stress/soak test results, bottleneck analysis
• Caution: Performance targets must be specified in the requirements. Vague language like "should be fast" is a recipe for disputes.
• Common tools: Apache JMeter, Gatling, k6, nGrinder

5-7. Security Vulnerability Assessment Report

• Owner: Security specialist / automated tool
• Key contents: OWASP Top 10 findings (SQL injection, XSS, CSRF, authentication flaws, etc.), KISA secure coding checklist results, vulnerability severity ratings (Critical/High/Medium/Low), remediation evidence
• Caution: Public sector projects must comply with the Ministry of the Interior and Safety "Software Security Weakness Diagnosis Guide."

5-8. Defect List and Remediation Record

• Owner: QA team + development team
• Key contents: All defects found, severity (Critical/Major/Minor), defect type, assignee, fix description, re-verification results
• Caution: All Critical defects must be resolved before go-live. Remaining Major defects require client sign-off before proceeding.

5-9. UAT (User Acceptance Test) Results

• Owner: Client users (QA support)
• Key contents: Acceptance test results performed directly by the client, verdict per test case, final acceptance signature
• Caution: UAT is the legal basis for client acceptance. The sign-off carries contractual weight — manage it carefully.

5-10. Test Completion Report

• Owner: QA lead / PM
• Key contents: Overall test summary, defect status (found/resolved/remaining), performance results summary, go-live readiness opinion, residual risks
• Caution: This report is the basis for the go-live decision. The "ready to go live" judgment should be made jointly by the PM and the client.

6. Migration/Go-Live Phase — Cutover

This phase transitions from development/test environments to live production.

6-1. Data Migration Plan

• Owner: DBA + data engineer
• Key contents: List of data to be migrated, source-to-target mapping tables, data transformation rules, migration approach (full vs. incremental), schedule, rollback plan
• Caution: For large-volume migrations, always run a dry-run to measure elapsed time before the actual cutover window.

6-2. Data Migration Results

• Owner: DBA + QA
• Key contents: Record count comparison before and after migration, error count and type, exception handling log, data integrity verification results
• Caution: "Migration went fine" verbally is not sufficient. Count comparisons and sampled verification must be documented.

6-3. Cutover Plan (Migration Scenario)

• Owner: PM + infrastructure team
• Key contents: D-Day task sequence and timeline, owner and contact per step, Go/No-Go criteria, rollback procedure, emergency contact list
• Caution: The cutover plan must be validated through a cutover rehearsal. Running it for the first time in production is high-risk.

6-4. Cutover Checklist

• Owner: PM + each workstream lead
• Key contents: Final pre-go-live checks (server startup confirmed, DB connection confirmed, interface connections confirmed, user accounts confirmed, backup completed, etc.), Go/No-Go status per criterion
• Caution: Checklist items should include actual measured values (e.g., "DB connection response time under 0.5 seconds"), not just "checked."

6-5. Go-Live Report

• Owner: PM
• Key contents: Go-live completion confirmation, initial stabilization period (typically 2–4 weeks) monitoring results, post-go-live issues and resolutions, stabilization completion declaration
• Caution: Maintain intensive monitoring immediately after go-live. Operating a War Room is strongly recommended.

7. Closure Phase — Delivery and Project Wrap-Up

This phase formally closes the project and hands over to the operations team.

7-1. User Manual

• Owner: Technical writer / developer
• Key contents: End-user-oriented operating instructions per screen, FAQ, instructions for handling common errors
• Caution: Write the manual using screenshots of the final production screens. Manuals written during development become obsolete when screens change.

7-2. Administrator Manual (Operator Manual)

• Owner: Developer / infrastructure engineer
• Key contents: System administrator-oriented: deployment procedures, configuration file descriptions, monitoring approach, log locations, routine maintenance checklist, first-level incident response
• Caution: Handing over without an administrator manual creates permanent dependency on the development team for operational support.

7-3. System Operations Guide

• Owner: Infrastructure engineer / DevOps
• Key contents: Server inventory and specs, key process management procedures, backup and recovery policy, capacity planning notes, security patch management
• Caution: Keep the infrastructure diagram up to date and store it in a configuration management tool.

7-4. Incident Response Runbook

• Owner: Infrastructure engineer / DevOps
• Key contents: Symptoms, causes, and step-by-step response procedures per expected failure type; escalation criteria; RTO (Recovery Time Objective) and RPO (Recovery Point Objective)
• Caution: A runbook must be specific enough for an inexperienced operator to follow during a high-pressure incident.

7-5. Software Configuration Management (SCM) List

• Owner: Configuration manager / PM
• Key contents: Delivered source code inventory (filename/version), binary inventory, open-source license list, build instructions, configuration file list
• Caution: Open-source license violations can lead to legal disputes. Perform open-source scanning (generate an SBOM) before delivery.

7-6. Project Completion Report

• Owner: PM
• Key contents: Full project summary, objectives achievement assessment, cost close-out (planned vs. actual), schedule close-out, quality close-out, key achievements and challenges
• Caution: This report is the basis for final payment. It must be signed off (physical or electronic signature) by the client's representative.

7-7. Warranty and Maintenance Plan

• Owner: PM + support team
• Key contents: Warranty period (typically one year from delivery), SLA definitions (response time / resolution time), contact information, defect classification (usage questions vs. genuine defects), patch deployment procedure
• Caution: Warranty (bug fixes within original scope) and enhancements (new features outside original scope) must be clearly distinguished. "The requirements changed, please update the system" is not a warranty item.

7-8. Lessons Learned

• Owner: PM + entire project team
• Key contents: Best practices to repeat, areas for improvement, mistakes not to repeat, tool/methodology evaluations, recommendations for future projects
• Caution: Lessons learned are an organizational process asset. Don't keep them within the team — register them with the PMO for future projects to benefit.

7-9. Knowledge Transfer Materials

• Owner: Development team / analysis team
• Key contents: System architecture overview slides, operations team training materials, hands-on lab guides, common support questions and answers
• Caution: Documentation alone is insufficient for knowledge transfer. Pair it with hands-on training and provide support until the operations team can operate independently.

8. Public Sector — Specialized Deliverables

Projects commissioned by government or public agencies require additional deliverables mandated by law and administrative directives.

8-1. Information Strategy Plan (ISP)

• Overview: Document establishing a medium- to long-term IT roadmap
• Related guideline: Ministry of the Interior and Safety "Information System Construction and Operation Guidelines"
• Key contents: Current state diagnosis, IT vision and goals, task prioritization, budget estimates, implementation schedule, expected benefits
• Caution: ISP is often procured as a standalone project; system construction projects are then launched based on the ISP output.

8-2. Privacy Impact Assessment (PIA)

• Legal basis: Personal Information Protection Act, Article 33 (mandatory for public agencies above certain thresholds)
• Key contents: Personal data items processed, legal basis for collection, retention period, security measures, risk analysis and remediation
• Caution: PIA must be conducted by an assessment institution designated by the Personal Information Protection Commission (개인정보 보호위원회).

8-3. Information Security Plan

• Related laws: E-Government Act, Act on Promotion of Information and Communications Network Utilization, ISMS-P certification criteria
• Key contents: Threat analysis, security requirements, security architecture, vulnerability response plan, security operations center (SOC) approach
• Caution: For systems requiring ISMS-P certification, the plan must align with certification audit criteria.

8-4. Software Project Cost Estimation Document

• Related laws: Software Industry Promotion Act, NIPA "SW Project Cost Estimation Guide"
• Key contents: Function Point (FP) count and derivation, adjustment factor application, person-day estimation, unit price application
• Caution: Cost estimates in public projects are frequently reviewed by third parties. The derivation must be transparent and well-documented.

8-5. Software Audit Report (SW 감리 보고서)

• Legal basis: Software Industry Promotion Act, Article 65 (mandatory for public projects over KRW 10 billion)
• Key contents: Phase-specific audit findings (analysis / design / implementation / closure), deficiencies noted, remediation plan and results
• Caution: Audits are performed by registered audit firms. All audit findings must be addressed before progressing to the next phase.

8-6. Copyright Ownership Confirmation

• Key contents: Document confirming that copyright of all project deliverables (source code, documents, data) is vested in the client
• Caution: The handling of copyright for common modules or libraries that the vendor intends to reuse must be negotiated and explicitly stated before contract signing.

8-7. Delivery Acceptance Certificate (납품 확인서)

• Key contents: Final deliverable list (source code / documents / training / licenses etc.), delivery confirmation per item, client acceptance manager's signature
• Caution: Signing the delivery acceptance triggers the payment condition. If any items are incomplete, negotiate conditional acceptance terms in advance.

9. Practical Tips for Deliverable Management

9-1. Document Numbering Scheme

A consistent numbering scheme is the foundation of deliverable management. Example:

PJ-2024-001-ANALYSIS-001  → Project 001 in 2024, analysis phase, document 001
PJ-2024-001-DESIGN-005    → Project 001 in 2024, design phase, document 005

9-2. Configuration Management

• Baseline setting: Freeze approved deliverables at the completion of each phase.
• Change control: Any change after a baseline is established requires CCB (Change Control Board) approval.
• Version management: Track document versions as v1.0, v1.1, v2.0 and maintain a change history table within each document.

9-3. Tool Recommendations

9-4. PMBOK Deliverables vs. Korean Practice

Deliverable names and structures defined by PMBOK (Project Management Body of Knowledge) do not always align directly with those used in the Korean IT industry. For example, the PMBOK "Project Charter" roughly corresponds to what Korean practitioners call the "착수보고서" (Kick-off Report) or "사업수행계획서" (Project Management Plan), but the scope and format differ. Practitioners working on Korean projects for the first time should map familiar PMBOK terms to their Korean-language equivalents.

Quizzes: Test Your Knowledge

Conclusion

IT project deliverables are not merely paperwork produced to satisfy an auditor. Each deliverable is a checkpoint confirming the team is moving in the right direction, a record of agreement between stakeholders, and a knowledge asset for the teams who will maintain the system for years to come.

The difference between a good PM and an average one lies not in whether they produce the required documents, but in whether those documents genuinely serve the project. Make it a habit to write deliverables that add real value — not just deliverables that check a box.