Split View: IT사업 기획과 제안서 작성 완전 가이드: RFP 분석·ISMP·WBS·비용 산정·SLA까지
IT사업 기획과 제안서 작성 완전 가이드: RFP 분석·ISMP·WBS·비용 산정·SLA까지
- 들어가며
- IT사업의 유형과 생명주기
- RFP 분석과 대응 전략
- ISMP와 정보화 전략
- 제안서 작성 핵심 전략
- 프로젝트 계획 수립
- 비용 산정과 ROI 분석
- SLA와 서비스 수준 관리
- 성공적인 IT사업 수행 사례
- 마치며
- 참고자료

들어가며
IT사업은 단순히 시스템을 개발하는 것이 아니라, 조직의 전략적 목표를 기술로 구현하는 종합적인 활동이다. 성공적인 IT사업을 위해서는 사업 기획 단계부터 제안서 작성, 프로젝트 수행, 그리고 서비스 운영까지 체계적인 접근이 필요하다.
한국의 IT사업 환경은 공공과 민간 영역에서 서로 다른 특성을 보인다. 공공 IT사업은 조달청 나라장터를 통한 입찰 절차, 소프트웨어 진흥법에 따른 사업 대가 산정 기준, 그리고 국가정보화 기본법에 근거한 정보화전략계획(ISMP) 수립 의무 등 엄격한 규정이 적용된다. 민간 IT사업은 상대적으로 유연하지만, 비용 대비 효과(ROI)를 명확히 증명해야 하는 비즈니스 논리가 더욱 중요하다.
이 글에서는 IT사업의 유형과 생명주기를 시작으로, RFP 분석 전략, ISMP 방법론, 제안서 작성 핵심 기법, 프로젝트 계획 수립, 비용 산정과 ROI 분석, SLA 관리, 그리고 실제 성공 사례까지 IT사업 기획의 전 과정을 실무 관점에서 체계적으로 다룬다.
IT사업의 유형과 생명주기
IT사업의 주요 유형
IT사업은 수행 목적과 방식에 따라 크게 다음과 같이 분류된다.
| 유형 | 설명 | 주요 특징 |
|---|---|---|
| SI (System Integration) | 새로운 정보시스템의 분석, 설계, 개발, 구축 | 명확한 시작과 종료, 산출물 중심 |
| SM (System Management) | 구축된 시스템의 운영, 유지보수 | 연단위 계약, SLA 기반 관리 |
| 컨설팅 | IT전략 수립, 진단, 개선 방안 도출 | 지식 기반 서비스, 보고서 산출 |
| SaaS 도입 | 클라우드 기반 소프트웨어 서비스 도입 | 구독 모델, 커스터마이징 범위 제한 |
| 클라우드 전환 | 온프레미스에서 클라우드로의 마이그레이션 | 인프라 재설계, 리팩토링 필요 |
| 데이터 분석 | 빅데이터, AI/ML 기반 분석 시스템 구축 | 데이터 품질이 성패 좌우 |
IT사업 생명주기
IT사업은 기획에서 폐기까지 뚜렷한 생명주기를 거친다.
사업 기획 → 예산 확보 → RFP 작성 → 입찰/제안 → 평가/선정 → 착수 → 수행 → 검수/종료 → 운영/유지보수
각 단계별 핵심 활동은 다음과 같다.
1단계: 사업 기획
- 현행 시스템 분석(As-Is) 및 목표 시스템 정의(To-Be)
- 사업 타당성 분석 (기술적, 경제적, 운영적 타당성)
- 이해관계자 식별 및 요구사항 수집
- 사업 범위 및 추진 전략 수립
2단계: 예산 확보 및 조달
- 사업 대가 산정 (SW사업 대가산정 가이드 기준)
- 예산 요구서 작성 및 승인
- 조달 방식 결정 (일반경쟁, 제한경쟁, 수의계약)
3단계: 제안 및 선정
- RFP 작성 및 공고
- 사전 설명회(Pre-bid Conference) 개최
- 제안서 접수 및 기술/가격 평가
- 우선협상대상자 선정 및 계약 체결
4단계: 사업 수행
- 착수 보고, 중간 보고, 최종 보고
- 단계별 산출물 검토 및 품질 관리
- 변경 관리(Change Management) 프로세스 운영
- PMO에 의한 거버넌스 관리
공공 IT사업과 민간 IT사업의 차이
# 공공 IT사업 특징
규제_환경:
- 국가정보화 기본법
- 소프트웨어 진흥법
- 전자정부법
- 조달청 계약 규정
대가_산정:
기준: SW사업 대가산정 가이드 (과학기술정보통신부)
방식:
- 기능점수(FP) 방식
- 투입공수(Man/Month) 방식
입찰_방식:
- 일반경쟁입찰 (기본)
- 제한경쟁입찰 (자격 제한)
- 협상에 의한 계약 (기술 중심 평가)
# 민간 IT사업 특징
의사결정:
- C-Level 승인 중심
- 비즈니스 케이스(ROI) 기반
- 벤더 관계 및 레퍼런스 중요
계약_방식:
- 정액(Fixed Price)
- 실비정산(Time and Material)
- 성과기반(Outcome-based)
RFP 분석과 대응 전략
RFP의 구조 이해
RFP(제안요청서)는 발주 기관이 IT사업의 목적, 범위, 요구사항, 평가 기준 등을 정리하여 제안사에 전달하는 핵심 문서다. 잘 작성된 RFP를 정확히 분석하는 것이 제안 성공의 첫걸음이다.
RFP 일반 구조:
1. 사업 개요
- 사업 배경 및 목적
- 사업 범위
- 추진 일정
- 사업 예산
2. 현행 시스템 현황
- 인프라 구성도
- 응용시스템 현황
- 데이터 현황
3. 요구사항
- 기능 요구사항 (FR)
- 비기능 요구사항 (NFR)
- 데이터 요구사항
- 인터페이스 요구사항
- 보안 요구사항
4. 제안 요건
- 기술 부문 (시스템 구성, 아키텍처)
- 관리 부문 (방법론, 조직, 일정)
- 지원 부문 (교육, 유지보수, 기술 이전)
5. 제안서 평가 기준
- 기술 평가 항목 및 배점
- 가격 평가 방식
- 프레젠테이션 평가
6. 제안 안내
- 제출 일정 및 방법
- 제안서 작성 규격
- 문의처
RFP 분석 체크리스트
RFP를 수령하면 다음 항목을 체계적으로 분석해야 한다.
| 분석 영역 | 핵심 확인 사항 | 분석 목적 |
|---|---|---|
| 사업 배경 | 발주 동기, 상위 계획과의 연계 | 고객의 진짜 니즈 파악 |
| 사업 범위 | 포함/제외 범위의 명확성 | 리스크 및 추가 비용 예측 |
| 요구사항 | 기능/비기능 요구의 구체성 수준 | 제안 방향 및 차별화 포인트 |
| 평가 기준 | 배점 구조, 가점/감점 항목 | 제안서 역량 집중 영역 |
| 일정 | 사업 기간의 현실성 | 투입 인력 및 공수 산정 |
| 예산 | 사업비 적정성 | Go/No-Go 의사결정 |
| 기술 환경 | 지정 플랫폼, 기존 시스템 연동 | 기술 아키텍처 설계 방향 |
Go/No-Go 의사결정 프레임워크
모든 RFP에 제안하는 것은 비효율적이다. 체계적인 Go/No-Go 분석이 필요하다.
Go/No-Go 평가 매트릭스 (100점 만점)
전략적 부합성 (25점)
- 회사 사업 전략과의 일치도 0-10점
- 레퍼런스 확보 가치 0-8점
- 장기 관계 구축 가능성 0-7점
경쟁력 (25점)
- 유사 사업 수행 경험 0-10점
- 핵심 기술 보유 여부 0-8점
- 전문 인력 확보 가능성 0-7점
수익성 (25점)
- 예산 대비 수익률 전망 0-10점
- 추가 사업 연계 가능성 0-8점
- 투입 리소스 대비 효율성 0-7점
리스크 (25점)
- 기술적 난이도 0-10점
- 일정의 현실성 0-8점
- 발주처 협력 수준 전망 0-7점
판정 기준:
80점 이상: Go (적극 참여)
60-79점: Conditional Go (조건부 참여)
60점 미만: No-Go (불참)
RFP 질의응답 전략
사전 설명회와 질의응답은 RFP의 모호한 부분을 명확히 하고, 경쟁사 대비 우위를 확보하는 중요한 기회다.
효과적인 질의 전략:
- 핵심 기술 요건의 해석 범위를 확인하는 질문
- 발주처가 가장 중요시하는 가치가 무엇인지 간접적으로 파악하는 질문
- 현행 시스템의 운영 현황과 애로사항을 확인하는 질문
- 기존 유사 사업과의 차별성을 확인하는 질문
주의할 점:
- 자사의 제안 방향을 노출하는 질문은 피한다
- 경쟁사에게도 도움이 되는 범용적 질문은 최소화한다
- 핵심적이고 구체적인 질문으로 발주처의 신뢰를 확보한다
ISMP와 정보화 전략
ISMP의 개념과 목적
ISMP(정보화전략계획, Information Strategy Master Plan)는 조직의 중장기 정보화 비전과 전략을 수립하고, 이를 실현하기 위한 단계별 실행 로드맵을 도출하는 체계적인 계획 수립 활동이다.
공공 부문에서는 대규모 IT사업(일정 규모 이상)을 추진하기 전에 ISMP 수립이 의무화되어 있으며, 이를 통해 사업의 타당성과 추진 방향을 사전에 검증한다.
ISMP 수립 절차
Phase 1: 환경 분석 (약 전체 기간의 25%)
├── 경영 환경 분석
│ ├── 조직 전략 및 비전 분석
│ ├── 업무 프로세스 분석 (BPR)
│ └── 이해관계자 인터뷰
├── 정보화 현황 분석
│ ├── 현행 시스템 아키텍처 분석
│ ├── 정보자원 현황 분석
│ └── 정보화 성숙도 평가
└── 벤치마킹
├── 동종 업계 사례 분석
└── 선진 기술 트렌드 조사
Phase 2: 미래 모델 수립 (약 전체 기간의 35%)
├── 목표 아키텍처 설계
│ ├── 비즈니스 아키텍처 (BA)
│ ├── 데이터 아키텍처 (DA)
│ ├── 응용 아키텍처 (AA)
│ └── 기술 아키텍처 (TA)
├── 갭 분석 (As-Is vs To-Be)
└── 정보화 과제 도출
Phase 3: 실행 계획 수립 (약 전체 기간의 40%)
├── 과제 우선순위 평가
│ ├── 전략적 중요도
│ ├── 시급성
│ ├── 기술적 실현 가능성
│ └── 과제 간 선후행 관계
├── 단계별 추진 로드맵
│ ├── 단기 (1년 이내)
│ ├── 중기 (1-3년)
│ └── 장기 (3-5년)
├── 투자 소요 예산 산정
└── 추진 체계 설계
정보화 아키텍처(EA) 프레임워크
ISMP에서 목표 아키텍처를 설계할 때는 EA(Enterprise Architecture) 프레임워크를 활용한다.
| 아키텍처 영역 | 주요 내용 | 산출물 |
|---|---|---|
| 비즈니스 아키텍처(BA) | 업무 프로세스, 조직 구조, 기능 분류 | 업무 기능 분해도, 프로세스 맵 |
| 데이터 아키텍처(DA) | 데이터 모델, 데이터 흐름, 데이터 표준 | 개념/논리 데이터 모델, 데이터 흐름도 |
| 응용 아키텍처(AA) | 응용시스템 구성, 시스템 간 연동, 기능 배치 | 응용 구성도, 인터페이스 정의서 |
| 기술 아키텍처(TA) | 인프라, 네트워크, 보안, 플랫폼 기술 스택 | 인프라 구성도, 기술 표준 정의서 |
ISMP 성공 요인
핵심 성공 요인:
- 경영진의 적극적 참여와 지원 (Executive Sponsorship)
- 현업 부서와의 긴밀한 협업 및 의견 수렴
- 현실적이고 실행 가능한 과제 도출
- 기존 정보화 자산의 활용도를 고려한 점진적 전환 전략
- 명확한 성과지표(KPI) 설정과 추적 체계
흔한 실패 원인:
- 경영 전략과 괴리된 기술 중심 계획
- 현업의 참여 없이 외부 컨설턴트 주도로 수립
- 과도한 목표 설정 (Big Bang 접근)
- 예산 확보 없는 로드맵 수립
- 수립 후 실행 관리 체계의 부재
제안서 작성 핵심 전략
제안서의 구성 체계
제안서는 크게 기술 제안, 관리 제안, 가격 제안의 세 영역으로 구성된다. 각 영역에서 RFP의 평가 기준에 맞춰 전략적으로 내용을 구성해야 한다.
제안서 표준 목차 구조:
제1편 기술 부문
제1장 사업 이해
1.1 사업 배경 및 환경 분석
1.2 현행 시스템 분석
1.3 핵심 과제 도출
제2장 제안 시스템
2.1 시스템 아키텍처
2.2 기능 설계
2.3 데이터 설계
2.4 인터페이스 설계
2.5 보안 설계
제3장 개발 방안
3.1 개발 방법론
3.2 단계별 수행 방안
3.3 품질 관리 방안
제2편 관리 부문
제1장 프로젝트 관리
1.1 프로젝트 추진 체계
1.2 프로젝트 관리 방안 (범위, 일정, 품질, 위험)
1.3 의사소통 관리
1.4 변경 관리
제2장 투입 인력
2.1 투입 조직도
2.2 핵심 인력 역량
2.3 인력 투입 계획
제3장 사업 수행 일정
3.1 마스터 스케줄
3.2 단계별 상세 일정
제3편 지원 부문
제1장 교육 및 기술 이전
제2장 하자 보수 및 유지보수
제3장 유사 사업 수행 실적
기술 제안 작성 전략
기술 제안은 제안서의 핵심이며, 발주처의 문제를 어떻게 해결할 것인지를 기술적으로 증명하는 영역이다.
아키텍처 설계 원칙:
| 원칙 | 설명 | 적용 사례 |
|---|---|---|
| 확장성 (Scalability) | 사용자/데이터 증가에 유연하게 대응 | 마이크로서비스 아키텍처, 오토스케일링 |
| 가용성 (Availability) | 장애 시에도 서비스 연속성 보장 | 이중화, 페일오버, DR 구성 |
| 보안성 (Security) | 데이터 보호 및 접근 통제 | 암호화, 인증/인가, 네트워크 분리 |
| 호환성 (Interoperability) | 기존 시스템과의 원활한 연동 | 표준 API, ESB, 메시지 큐 |
| 유지보수성 (Maintainability) | 변경과 개선이 용이한 구조 | 모듈화, 클린 아키텍처, CI/CD |
차별화 전략:
- 고객의 숨겨진 니즈(Hidden Needs)를 발굴하여 반영
- 업계 트렌드와 혁신 기술을 접목한 미래지향적 아키텍처 제시
- 유사 프로젝트 수행 경험에서 도출한 베스트 프랙티스 제시
- 구체적인 PoC(Proof of Concept) 결과나 프로토타입 시연
관리 제안 작성 전략
관리 제안은 프로젝트를 성공적으로 수행할 수 있는 관리 역량을 증명하는 영역이다.
# 프로젝트 추진 체계 예시
추진_조직:
발주처:
역할: 사업 총괄, 요구사항 확정, 검수
구성:
- 사업 책임자 (PO)
- 현업 담당자
- 정보화 담당자
수행사:
역할: 시스템 분석/설계/개발/테스트
구성:
PM:
역할: 프로젝트 총괄 관리
자격: PMP 또는 유사 사업 PM 경력 10년 이상
PL:
역할: 기술 리더십, 아키텍처 설계
자격: 해당 기술 분야 전문가
개발팀:
역할: 설계/개발/단위테스트
QA팀:
역할: 통합테스트, 성능테스트, 품질 관리
DBA:
역할: 데이터 모델링, DB 튜닝
PMO:
역할: 사업 감리, 품질 감독
구성:
- 감리원
- 품질 관리 전문가
가격 제안 전략
가격 제안은 기술력을 합리적인 비용으로 제공할 수 있음을 증명하는 영역이다. 공공사업에서는 대가산정 기준에 따라 투명하게 산출해야 하며, 민간사업에서는 경쟁력 있는 가격과 가치 제안의 균형이 중요하다.
| 가격 구성 요소 | 산정 기준 | 비중 (SI 기준) |
|---|---|---|
| 직접인건비 | 등급별 노임단가 x 투입공수 | 약 60-70% |
| 직접경비 | 장비, 소프트웨어, 출장, 교육 | 약 10-15% |
| 제경비 | 직접인건비의 110-120% | 포함 계산 |
| 기술료 | (직접인건비+제경비)의 20-40% | 포함 계산 |
| 일반관리비 | 직접인건비의 일정 비율 | 포함 계산 |
| 이윤 | 총원가의 일정 비율 이내 | 약 10-15% |
프로젝트 계획 수립
WBS(작업분해구조) 작성
WBS는 프로젝트의 전체 범위를 관리 가능한 단위(Work Package)로 계층적으로 분해하는 기본 도구다. 효과적인 WBS 작성이 프로젝트 성공의 기초가 된다.
WBS 구조 예시 (차세대 시스템 구축 사업)
1.0 프로젝트 관리
1.1 착수 단계
1.1.1 착수 보고서 작성
1.1.2 착수 보고회
1.1.3 프로젝트 계획서 수립
1.2 실행 관리
1.2.1 주간 보고
1.2.2 월간 보고
1.2.3 이슈/리스크 관리
1.3 종료 단계
1.3.1 최종 보고서 작성
1.3.2 최종 보고회
1.3.3 산출물 인수인계
2.0 분석
2.1 현행 시스템 분석
2.1.1 업무 프로세스 분석
2.1.2 데이터 현황 분석
2.1.3 인터페이스 현황 분석
2.2 요구사항 분석
2.2.1 요구사항 수집
2.2.2 요구사항 정의서 작성
2.2.3 요구사항 검토 및 확정
2.3 분석 보고
2.3.1 분석 보고서 작성
2.3.2 분석 단계 검토회
3.0 설계
3.1 아키텍처 설계
3.2 UI/UX 설계
3.3 데이터베이스 설계
3.4 인터페이스 설계
3.5 설계 보고
4.0 구현
4.1 개발 환경 구축
4.2 공통 모듈 개발
4.3 업무별 기능 개발
4.4 인터페이스 개발
4.5 데이터 이행 개발
5.0 테스트
5.1 단위 테스트
5.2 통합 테스트
5.3 시스템 테스트
5.4 성능 테스트
5.5 사용자 수용 테스트 (UAT)
6.0 이행
6.1 이행 계획 수립
6.2 데이터 이행
6.3 시스템 전환
6.4 안정화 운영
일정 계획 (스케줄링)
WBS를 기반으로 각 작업의 소요 기간, 선후행 관계, 자원 할당을 고려하여 상세 일정을 수립한다.
| 기법 | 설명 | 활용 시점 |
|---|---|---|
| CPM (Critical Path Method) | 가장 긴 경로를 식별하여 최소 사업 기간 산정 | 전체 일정 최적화 |
| PERT (Program Evaluation and Review Technique) | 낙관/비관/최빈 3점 추정으로 불확실성 반영 | 불확실성 높은 작업 |
| 간트 차트 (Gantt Chart) | 작업별 시작/종료 일정을 막대 그래프로 시각화 | 일정 현황 보고 |
| 마일스톤 (Milestone) | 주요 체크포인트 정의 | 진척 관리 기준점 |
자원 할당 계획
# 인력 투입 계획 예시 (12개월 SI 사업)
투입_인력_계획:
분석_단계: # 1-3개월
PM: 1명 (100%)
PL: 1명 (100%)
분석가: 3명 (100%)
DBA: 1명 (50%)
합계: 약 5.5 M/M per month
설계_단계: # 3-5개월
PM: 1명 (100%)
PL: 1명 (100%)
설계자: 4명 (100%)
DBA: 1명 (100%)
UI_설계자: 1명 (100%)
합계: 약 8 M/M per month
구현_단계: # 5-10개월
PM: 1명 (100%)
PL: 1명 (100%)
개발자: 8명 (100%)
DBA: 1명 (100%)
QA: 2명 (50%)
합계: 약 12 M/M per month
테스트_이행: # 10-12개월
PM: 1명 (100%)
PL: 1명 (100%)
개발자: 6명 (80%)
DBA: 1명 (100%)
QA: 3명 (100%)
합계: 약 10.8 M/M per month
리스크 관리
프로젝트 리스크는 사전에 식별하고, 대응 전략을 수립해야 한다.
| 리스크 유형 | 사례 | 대응 전략 |
|---|---|---|
| 범위 확장 (Scope Creep) | 고객의 추가 요구사항 빈발 | 변경관리 프로세스 엄격 적용, 요구사항 동결 시점 명확화 |
| 인력 이탈 | 핵심 개발자 퇴사 | 지식 공유 체계, 백업 인력 확보, 문서화 강화 |
| 기술 리스크 | 신기술 적용 실패 | PoC 사전 수행, 기술 검증 단계 포함 |
| 일정 지연 | 선행 작업 지연 누적 | 크리티컬 패스 집중 관리, 버퍼 확보 |
| 품질 리스크 | 테스트 커버리지 부족 | 자동화 테스트 도입, 품질 게이트 설정 |
| 외부 의존성 | 외부 시스템 연동 지연 | 인터페이스 사전 협의, Mock 개발 |
비용 산정과 ROI 분석
기능점수(Function Point) 방식
기능점수 방식은 소프트웨어의 기능적 크기를 측정하여 개발 비용을 산정하는 국제 표준(ISO/IEC 20926) 방법이다. 한국 공공 IT사업에서 가장 널리 사용되는 대가 산정 방식이다.
기능점수 산정 절차:
1. 기능 유형 식별
- 내부논리파일 (ILF: Internal Logical File)
- 외부연계파일 (EIF: External Interface File)
- 외부입력 (EI: External Input)
- 외부출력 (EO: External Output)
- 외부조회 (EQ: External Inquiry)
2. 기능 복잡도 평가
- 단순 (Low), 보통 (Average), 복잡 (High)
- DET(데이터 요소 유형)과 RET/FTR 기준 적용
3. 미조정 기능점수 계산
- 각 기능 유형별 복잡도에 따른 가중치 적용
기능 유형별 가중치:
ILF: 단순=7, 보통=10, 복잡=15
EIF: 단순=5, 보통=7, 복잡=10
EI: 단순=3, 보통=4, 복잡=6
EO: 단순=4, 보통=5, 복잡=7
EQ: 단순=3, 보통=4, 복잡=6
4. 보정계수 적용
- 규모 보정, 애플리케이션 유형 보정, 언어 보정 등
5. 최종 개발비 산정
기능점수당 단가 x 보정된 기능점수 = 개발원가
투입공수(Man/Month) 방식
# 투입공수 기반 비용 산정 예시
인건비_산정:
등급별_노임단가: # 2026년 기준 (가상)
기술사: 월 12,500,000원
특급기술자: 월 10,800,000원
고급기술자: 월 9,200,000원
중급기술자: 월 7,600,000원
초급기술자: 월 5,800,000원
투입_계획:
PM_특급: 12 M/M
PL_고급: 12 M/M
분석가_고급: 9 M/M (3명 x 3개월)
설계자_중급: 12 M/M (4명 x 3개월)
개발자_중급: 48 M/M (8명 x 6개월)
QA_중급: 9 M/M (3명 x 3개월)
DBA_고급: 12 M/M
직접인건비_합계: 약 900,000,000원
총_사업비_산정:
직접인건비: 900,000,000원
제경비: 990,000,000원 # 직접인건비의 110%
기술료: 378,000,000원 # (직접인건비+제경비)의 20%
직접경비: 150,000,000원 # 장비, SW 라이선스, 교육 등
총원가: 2,418,000,000원
이윤: 241,800,000원 # 총원가의 10%
총_사업비: 2,659,800,000원 # 약 26.6억원
TCO(총소유비용) 분석
TCO는 시스템 도입부터 폐기까지 전체 생애주기에 걸친 총비용을 분석하는 방법이다.
| 비용 항목 | 초기 비용 | 연간 운영 비용 | 5년 TCO |
|---|---|---|---|
| 하드웨어/인프라 | 5억원 | 5천만원 (유지보수) | 7억원 |
| 소프트웨어 라이선스 | 3억원 | 6천만원 (유지보수) | 5.4억원 |
| 개발비 | 26.6억원 | - | 26.6억원 |
| 운영 인력 | - | 4억원 | 20억원 |
| 교육/훈련 | 5천만원 | 1천만원 | 9천만원 |
| 데이터 이관 | 1억원 | - | 1억원 |
| 합계 | 36.1억원 | 5.2억원 | 60.9억원 |
ROI(투자수익률) 분석
ROI 계산 프레임워크:
1. 정량적 효과 (Tangible Benefits)
- 업무 처리 시간 단축: 연 2억원 (인건비 절감)
- 수작업 오류 감소: 연 5천만원 (재작업 비용 절감)
- 운영 효율화: 연 3억원 (프로세스 자동화)
- 합계: 연 5.5억원
2. 정성적 효과 (Intangible Benefits)
- 의사결정 속도 향상
- 고객 만족도 증대
- 데이터 기반 경영 역량 강화
- 규제 준수 리스크 감소
3. ROI 계산
5년 총 효과: 5.5억원 x 5년 = 27.5억원
5년 TCO: 60.9억원
단순 ROI = (총 효과 - 총 비용) / 총 비용
= (27.5 - 60.9) / 60.9
= -54.8%
그러나 정성적 효과와 기회비용을 포함하면:
보정된 총 효과: 연 15억원 (정성적 효과 포함)
5년 보정 효과: 75억원
보정 ROI = (75 - 60.9) / 60.9 = 23.2%
손익분기점(BEP): 약 4년 1개월
SLA와 서비스 수준 관리
SLA의 구성 요소
SLA(서비스 수준 협약)는 IT서비스의 품질을 정량적으로 정의하고, 이를 모니터링하며, 미달 시 패널티를 적용하는 체계적인 관리 도구다.
# SLA 정의서 예시
서비스_수준_협약:
서비스_가용성:
목표: 99.95%
측정_기간: 월 단위
제외_시간: 계획된 점검 시간 (매월 둘째 주 일요일 02:00-06:00)
산정_방식: '(전체 서비스 시간 - 장애 시간) / 전체 서비스 시간 x 100'
패널티:
99.90_이상_99.95_미만: 월 유지보수비의 5% 감액
99.50_이상_99.90_미만: 월 유지보수비의 10% 감액
99.50_미만: 월 유지보수비의 20% 감액
응답_시간:
온라인_거래: 평균 3초 이내 (피크 시간 5초 이내)
배치_처리: 정해진 시간 내 완료
보고서_생성: 30초 이내
장애_대응:
심각(Critical): 인지 후 30분 내 대응, 4시간 내 복구
주의(Major): 인지 후 1시간 내 대응, 8시간 내 복구
경미(Minor): 인지 후 4시간 내 대응, 24시간 내 복구
정보(Info): 인지 후 8시간 내 대응, 업무일 기준 3일 내 복구
SLA 모니터링 체계
| 모니터링 항목 | 측정 도구 | 측정 주기 | 보고 대상 |
|---|---|---|---|
| 시스템 가용성 | APM(Application Performance Monitoring) 도구 | 실시간 | 월간 보고 |
| 응답 시간 | 실사용자 모니터링(RUM) | 실시간 | 주간 보고 |
| 장애 건수/복구 시간 | ITSM(IT Service Management) 시스템 | 이벤트 기반 | 월간 보고 |
| 배치 처리 현황 | 작업 스케줄러 | 일 단위 | 일간 보고 |
| 보안 이벤트 | SIEM(Security Information and Event Management) | 실시간 | 월간 보고 |
SLA 개선 사이클
효과적인 SLA 관리는 지속적인 개선 사이클을 통해 이루어진다.
SLA 개선 사이클 (PDCA):
Plan (계획)
- SLA 지표 정의 및 목표 수준 설정
- 모니터링 체계 구축
- 이해관계자 합의
Do (실행)
- SLA 기반 서비스 운영
- 실시간 모니터링
- 장애 대응 프로세스 실행
Check (점검)
- 월간/분기별 SLA 달성률 분석
- 미달 항목 원인 분석
- 트렌드 분석 및 예측
Act (개선)
- 개선 과제 도출 및 실행
- SLA 기준 재설정 (필요 시)
- 운영 프로세스 최적화
성공적인 IT사업 수행 사례
사례 1: 공공기관 차세대 시스템 구축
프로젝트 개요:
- 대상: 정부 산하 공공기관의 핵심 업무 시스템 차세대 전환
- 규모: 약 50억원, 18개월
- 범위: 기존 메인프레임 기반 시스템을 오픈 플랫폼(Java/Spring)으로 전환
핵심 성공 요인:
- 철저한 현행 분석: 3개월간의 As-Is 분석을 통해 1,200개 업무 기능과 800개 화면을 정밀하게 매핑
- 단계적 전환 전략: Big Bang 방식이 아닌 업무 영역별 순차 전환으로 리스크 최소화
- 현업 참여 극대화: 업무 영역별 현업 담당자를 프로젝트 전담으로 배치
- 자동화 테스트: 회귀 테스트 자동화로 전환 오류를 사전에 90% 이상 차단
- 데이터 이행 리허설: 3회에 걸친 데이터 이행 리허설로 본번 이행 시 무결성 확보
교훈:
- 차세대 사업에서 가장 중요한 것은 기존 업무 로직의 정확한 이해
- 데이터 이행은 프로젝트 초기부터 별도 트랙으로 관리해야 한다
- 사용자 교육 시간을 넉넉히 확보해야 오픈 후 혼란을 최소화할 수 있다
사례 2: 금융권 클라우드 전환 사업
프로젝트 개요:
- 대상: 중견 금융사의 비핵심 업무 시스템 클라우드 전환
- 규모: 약 30억원, 12개월
- 범위: 20개 응용시스템의 클라우드 마이그레이션
마이그레이션 전략 (6R 프레임워크 적용):
| 전략 | 적용 시스템 수 | 설명 |
|---|---|---|
| Rehost (리호스트) | 8개 | 변경 없이 클라우드 인프라로 이동 |
| Replatform (리플랫폼) | 5개 | 일부 플랫폼 요소만 클라우드 최적화 |
| Refactor (리팩터) | 4개 | 클라우드 네이티브 아키텍처로 재설계 |
| Retire (폐기) | 2개 | 사용 중단 시스템 폐기 |
| Retain (유지) | 1개 | 온프레미스 유지 (규제 요건) |
핵심 성공 요인:
- 금융 규제 사전 검토: 금융감독원 클라우드 이용 가이드라인 준수 확인
- 보안 아키텍처 설계: 네트워크 분리, 데이터 암호화, 접근 통제 체계 수립
- 비용 최적화: 리저브드 인스턴스와 오토스케일링 조합으로 연 40% 비용 절감
- 점진적 전환: 비핵심 시스템부터 전환하여 운영 경험 축적 후 확대
사례 3: 대기업 ERP 고도화 컨설팅
프로젝트 개요:
- 대상: 제조 대기업의 ERP 시스템 고도화 전략 컨설팅
- 규모: 약 8억원, 6개월
- 범위: ISMP 수립 및 ERP 고도화 로드맵 도출
수행 방법론:
- 글로벌 14개 법인의 업무 프로세스 표준화 수준 진단
- 산업별 베스트 프랙티스 대비 갭 분석
- ERP 확장 모듈(SCM, PLM, MES) 도입 타당성 분석
- 3개년 단계별 고도화 로드맵 수립
주요 산출물:
- 현행 업무/시스템 분석 보고서
- 목표 아키텍처 설계서
- 과제 정의서 (32개 실행 과제)
- 3개년 추진 로드맵
- 투자 소요 예산서 (총 150억원 규모)
마치며
IT사업의 성공은 기술적 역량만으로 이루어지지 않는다. 사업의 본질을 이해하고, 고객의 니즈를 정확히 파악하며, 이를 체계적인 방법론과 관리 체계로 실현하는 종합적인 역량이 필요하다.
IT사업 기획자와 제안서 작성자가 기억해야 할 핵심 원칙:
- 고객 관점에서 생각하라: 기술이 아닌 비즈니스 가치를 먼저 이야기하라
- 숫자로 증명하라: 정성적 효과도 가능한 한 정량화하여 설득력을 높여라
- 리스크를 숨기지 마라: 리스크를 인지하고 대응 방안을 제시하는 것이 신뢰를 준다
- 실행 가능한 계획을 세워라: 과도한 약속은 프로젝트 실패의 시작이다
- 소통을 게을리하지 마라: 이해관계자와의 지속적인 커뮤니케이션이 변경 리스크를 줄인다
- 교훈을 축적하라: 모든 프로젝트의 경험을 조직 자산으로 관리하라
IT사업 환경은 클라우드, AI, 디지털 전환 등으로 빠르게 변하고 있지만, 체계적인 기획과 탄탄한 제안 역량의 중요성은 변하지 않는다. 이 글에서 다룬 내용이 IT사업을 기획하고 제안서를 작성하는 실무자에게 실질적인 도움이 되기를 바란다.
참고자료
- 한국정보화진흥원(NIA), 정보화전략계획(ISMP) 수립 가이드
- 과학기술정보통신부, SW사업 대가산정 가이드 (2025년 개정판)
- PMI, PMBOK Guide 7th Edition
- IFPUG, Function Point Counting Practices Manual (CPM) 4.3.1
- 한국소프트웨어산업협회, 소프트웨어 기술자 평균 임금 공표
- ITIL 4 Foundation, Service Level Management Practice
- 조달청, 협상에 의한 계약 제안서 평가 기준 가이드
- 금융감독원, 금융 부문 클라우드 이용 가이드라인
Complete Guide to IT Business Planning and Proposal Writing: RFP Analysis, ISMP, WBS, Cost Estimation, and SLA
- Introduction
- Types and Lifecycle of IT Projects
- RFP Analysis and Response Strategy
- ISMP and IT Strategy
- Proposal Writing Strategies
- Project Planning
- Cost Estimation and ROI Analysis
- SLA and Service Level Management
- Success Stories in IT Project Execution
- Conclusion
- References

Introduction
IT projects are far more than building software systems -- they are comprehensive endeavors that translate organizational strategy into technology solutions. Successful IT projects demand a systematic approach spanning business planning, proposal writing, project execution, and service operations.
The IT business landscape varies significantly across public and private sectors. In Korea, public sector IT projects follow strict regulations including procurement through the Public Procurement Service (PPS), cost estimation standards under the Software Promotion Act, and mandatory Information Strategy Master Plan (ISMP) establishment under the National Informatization Act. Private sector IT projects offer more flexibility but require clear Return on Investment (ROI) justification grounded in business logic.
In this article, we walk through the entire IT business planning lifecycle: from understanding project types and their lifecycles, analyzing RFPs, applying ISMP methodology, writing winning proposals, developing project plans, estimating costs and ROI, managing SLAs, and examining real-world success stories -- all from a practitioner's perspective.
Types and Lifecycle of IT Projects
Major Types of IT Projects
IT projects are classified by their purpose and delivery model as follows:
| Type | Description | Key Characteristics |
|---|---|---|
| SI (System Integration) | Analysis, design, development, and deployment of new IT systems | Clear start/end dates, deliverable-focused |
| SM (System Management) | Operation and maintenance of deployed systems | Annual contracts, SLA-based management |
| Consulting | IT strategy formulation, assessment, and improvement recommendations | Knowledge-based services, report deliverables |
| SaaS Adoption | Cloud-based software service introduction | Subscription model, limited customization |
| Cloud Migration | Migration from on-premises to cloud infrastructure | Infrastructure redesign, refactoring required |
| Data Analytics | Big data and AI/ML analytics system implementation | Data quality determines success |
IT Project Lifecycle
IT projects follow a distinct lifecycle from planning to decommissioning:
Business Planning -> Budget Approval -> RFP Creation -> Bidding/Proposal -> Evaluation/Selection -> Kickoff -> Execution -> Acceptance/Closure -> Operations/Maintenance
Key activities at each stage include:
Stage 1: Business Planning
- Current system analysis (As-Is) and target system definition (To-Be)
- Feasibility analysis (technical, economic, operational)
- Stakeholder identification and requirements gathering
- Scope definition and execution strategy
Stage 2: Budget Approval and Procurement
- Cost estimation based on official software cost guidelines
- Budget request preparation and approval
- Procurement method determination (open competition, limited competition, negotiated contract)
Stage 3: Proposal and Selection
- RFP creation and public announcement
- Pre-bid conference hosting
- Proposal submission and technical/price evaluation
- Preferred bidder selection and contract execution
Stage 4: Project Execution
- Kickoff report, interim report, final report
- Phase-by-phase deliverable review and quality management
- Change management process operation
- PMO-driven governance oversight
Public vs. Private IT Projects
# Public IT Project Characteristics
regulatory_environment:
- National Informatization Act
- Software Promotion Act
- Electronic Government Act
- PPS Contract Regulations
cost_estimation:
standard: Software Business Cost Estimation Guide (Ministry of Science and ICT)
methods:
- Function Point (FP) method
- Man-Month method
bidding_methods:
- Open competitive bidding (default)
- Limited competitive bidding (qualification restricted)
- Negotiated contract (technology-focused evaluation)
# Private IT Project Characteristics
decision_making:
- C-Level approval driven
- Business case (ROI) based
- Vendor relationships and references critical
contract_types:
- Fixed Price
- Time and Material
- Outcome-based
RFP Analysis and Response Strategy
Understanding RFP Structure
An RFP (Request for Proposal) is the critical document through which an issuing organization communicates the project's objectives, scope, requirements, and evaluation criteria to potential vendors. Accurately analyzing a well-crafted RFP is the first step toward a winning proposal.
Standard RFP Structure:
1. Project Overview
- Background and objectives
- Project scope
- Timeline
- Budget
2. Current System Status
- Infrastructure architecture
- Application system inventory
- Data landscape
3. Requirements
- Functional Requirements (FR)
- Non-Functional Requirements (NFR)
- Data requirements
- Interface requirements
- Security requirements
4. Proposal Requirements
- Technical section (system configuration, architecture)
- Management section (methodology, organization, schedule)
- Support section (training, maintenance, technology transfer)
5. Evaluation Criteria
- Technical evaluation items and scoring
- Price evaluation method
- Presentation evaluation
6. Submission Guidelines
- Submission schedule and method
- Proposal format specifications
- Contact information
RFP Analysis Checklist
Upon receiving an RFP, the following items should be systematically analyzed:
| Analysis Area | Key Verification Points | Analysis Purpose |
|---|---|---|
| Background | Motivation, alignment with higher-level plans | Understanding the client's true needs |
| Scope | Clarity of inclusions/exclusions | Risk and additional cost prediction |
| Requirements | Specificity level of functional/non-functional requirements | Proposal direction and differentiation points |
| Evaluation Criteria | Scoring structure, bonus/penalty items | Focus areas for proposal effort |
| Timeline | Realism of project duration | Staffing and effort estimation |
| Budget | Budget adequacy | Go/No-Go decision |
| Technology | Specified platforms, existing system integrations | Technical architecture design direction |
Go/No-Go Decision Framework
Responding to every RFP is inefficient. A systematic Go/No-Go analysis is essential.
Go/No-Go Evaluation Matrix (100 points)
Strategic Fit (25 points)
- Alignment with company business strategy 0-10 points
- Reference acquisition value 0-8 points
- Long-term relationship potential 0-7 points
Competitiveness (25 points)
- Relevant project experience 0-10 points
- Core technology capability 0-8 points
- Key personnel availability 0-7 points
Profitability (25 points)
- Revenue margin forecast vs. budget 0-10 points
- Follow-on business potential 0-8 points
- Resource efficiency 0-7 points
Risk (25 points)
- Technical complexity 0-10 points
- Schedule realism 0-8 points
- Client cooperation level expectation 0-7 points
Decision Criteria:
80+ points: Go (active participation)
60-79 points: Conditional Go (conditional participation)
Below 60 points: No-Go (decline)
RFP Q&A Strategy
Pre-bid conferences and Q&A sessions are crucial opportunities to clarify ambiguities in the RFP and gain competitive advantage.
Effective Questioning Strategies:
- Questions that clarify the interpretation scope of key technical requirements
- Questions that indirectly reveal what the issuing organization values most
- Questions about current system operational status and pain points
- Questions that clarify differences from similar past projects
Important Considerations:
- Avoid questions that reveal your proposal direction
- Minimize generic questions that equally benefit competitors
- Ask focused, specific questions to build trust with the issuing organization
ISMP and IT Strategy
Concept and Purpose of ISMP
ISMP (Information Strategy Master Plan) is a systematic planning activity that establishes an organization's mid-to-long-term IT vision and strategy, and derives a phased implementation roadmap to realize it.
In the Korean public sector, ISMP preparation is mandatory before pursuing large-scale IT projects (above a certain threshold), validating the business justification and strategic direction in advance.
ISMP Development Process
Phase 1: Environmental Analysis (approximately 25% of total duration)
+-- Business Environment Analysis
| +-- Organizational strategy and vision analysis
| +-- Business process analysis (BPR)
| +-- Stakeholder interviews
+-- IT Status Analysis
| +-- Current system architecture analysis
| +-- IT resource inventory analysis
| +-- IT maturity assessment
+-- Benchmarking
+-- Industry peer case studies
+-- Advanced technology trend research
Phase 2: Future Model Design (approximately 35% of total duration)
+-- Target Architecture Design
| +-- Business Architecture (BA)
| +-- Data Architecture (DA)
| +-- Application Architecture (AA)
| +-- Technology Architecture (TA)
+-- Gap Analysis (As-Is vs To-Be)
+-- IT Initiative Identification
Phase 3: Execution Planning (approximately 40% of total duration)
+-- Initiative Prioritization
| +-- Strategic importance
| +-- Urgency
| +-- Technical feasibility
| +-- Inter-initiative dependencies
+-- Phased Roadmap
| +-- Short-term (within 1 year)
| +-- Mid-term (1-3 years)
| +-- Long-term (3-5 years)
+-- Investment Budget Estimation
+-- Governance Structure Design
Enterprise Architecture (EA) Framework
When designing target architecture in ISMP, the EA (Enterprise Architecture) framework is utilized.
| Architecture Domain | Key Contents | Deliverables |
|---|---|---|
| Business Architecture (BA) | Business processes, organizational structure, function taxonomy | Function decomposition diagrams, process maps |
| Data Architecture (DA) | Data models, data flows, data standards | Conceptual/logical data models, data flow diagrams |
| Application Architecture (AA) | Application system composition, inter-system integration, function allocation | Application configuration diagrams, interface specifications |
| Technology Architecture (TA) | Infrastructure, network, security, platform technology stack | Infrastructure diagrams, technology standard specifications |
ISMP Success Factors
Critical Success Factors:
- Active executive sponsorship and support
- Close collaboration with business departments and opinion gathering
- Realistic and actionable initiative identification
- Incremental transformation strategy considering existing IT asset utilization
- Clear KPI definition and tracking framework
Common Failure Causes:
- Technology-centric plans disconnected from business strategy
- Plans developed exclusively by external consultants without business participation
- Overly ambitious goals (Big Bang approach)
- Roadmaps created without budget commitment
- Lack of execution management framework after plan completion
Proposal Writing Strategies
Proposal Structure
Proposals are typically composed of three major areas: technical proposal, management proposal, and pricing proposal. Content in each area should be strategically aligned with the RFP's evaluation criteria.
Standard Proposal Table of Contents:
Part 1: Technical Section
Chapter 1: Project Understanding
1.1 Business Background and Environmental Analysis
1.2 Current System Analysis
1.3 Key Issue Identification
Chapter 2: Proposed System
2.1 System Architecture
2.2 Functional Design
2.3 Data Design
2.4 Interface Design
2.5 Security Design
Chapter 3: Development Approach
3.1 Development Methodology
3.2 Phase-by-Phase Execution Plan
3.3 Quality Assurance Plan
Part 2: Management Section
Chapter 1: Project Management
1.1 Project Organization
1.2 Management Approach (Scope, Schedule, Quality, Risk)
1.3 Communication Management
1.4 Change Management
Chapter 2: Staffing
2.1 Organizational Chart
2.2 Key Personnel Qualifications
2.3 Staffing Plan
Chapter 3: Project Schedule
3.1 Master Schedule
3.2 Detailed Phase Schedules
Part 3: Support Section
Chapter 1: Training and Technology Transfer
Chapter 2: Warranty and Maintenance
Chapter 3: Relevant Project Experience
Technical Proposal Writing Strategy
The technical proposal is the core of the entire submission, demonstrating how you will solve the client's problems through technology.
Architecture Design Principles:
| Principle | Description | Application Examples |
|---|---|---|
| Scalability | Flexible response to user/data growth | Microservices architecture, auto-scaling |
| Availability | Service continuity assurance during failures | Redundancy, failover, DR configuration |
| Security | Data protection and access control | Encryption, authentication/authorization, network segmentation |
| Interoperability | Seamless integration with existing systems | Standard APIs, ESB, message queues |
| Maintainability | Structure facilitating change and improvement | Modularization, clean architecture, CI/CD |
Differentiation Strategies:
- Uncover and address the client's hidden needs
- Present future-oriented architecture incorporating industry trends and innovative technology
- Showcase best practices derived from similar project experience
- Provide concrete PoC (Proof of Concept) results or prototype demonstrations
Management Proposal Writing Strategy
The management proposal demonstrates your capability to successfully deliver the project.
# Project Organization Example
project_organization:
client:
role: Project oversight, requirement confirmation, acceptance
members:
- Project Owner (PO)
- Business stakeholders
- IT department staff
vendor:
role: System analysis, design, development, testing
members:
PM:
role: Overall project management
qualification: PMP certified or 10+ years PM experience in similar projects
PL:
role: Technical leadership, architecture design
qualification: Domain technology expert
development_team:
role: Design, development, unit testing
QA_team:
role: Integration testing, performance testing, quality management
DBA:
role: Data modeling, database tuning
PMO:
role: Project audit, quality oversight
members:
- Auditor
- Quality management specialist
Pricing Strategy
The pricing proposal demonstrates your ability to deliver technical excellence at a reasonable cost. For public projects, costs must be calculated transparently based on official estimation standards. For private projects, the balance between competitive pricing and value proposition is crucial.
| Cost Component | Estimation Basis | Proportion (SI projects) |
|---|---|---|
| Direct Labor Cost | Grade-specific daily rate x effort | Approximately 60-70% |
| Direct Expenses | Equipment, software, travel, training | Approximately 10-15% |
| Overhead | 110-120% of direct labor cost | Included in calculation |
| Technical Fee | 20-40% of (direct labor + overhead) | Included in calculation |
| General Administrative Expenses | Fixed percentage of direct labor | Included in calculation |
| Profit | Within fixed percentage of total cost | Approximately 10-15% |
Project Planning
Creating a WBS (Work Breakdown Structure)
WBS is the fundamental tool for hierarchically decomposing the entire project scope into manageable Work Packages. Effective WBS creation is the foundation of project success.
WBS Structure Example (Next-Generation System Build)
1.0 Project Management
1.1 Initiation Phase
1.1.1 Kickoff Report Preparation
1.1.2 Kickoff Meeting
1.1.3 Project Plan Development
1.2 Execution Management
1.2.1 Weekly Reports
1.2.2 Monthly Reports
1.2.3 Issue/Risk Management
1.3 Closure Phase
1.3.1 Final Report Preparation
1.3.2 Final Presentation
1.3.3 Deliverable Handover
2.0 Analysis
2.1 Current System Analysis
2.1.1 Business Process Analysis
2.1.2 Data Landscape Analysis
2.1.3 Interface Inventory Analysis
2.2 Requirements Analysis
2.2.1 Requirements Gathering
2.2.2 Requirements Specification Document
2.2.3 Requirements Review and Sign-off
2.3 Analysis Reporting
2.3.1 Analysis Report Preparation
2.3.2 Analysis Phase Review Meeting
3.0 Design
3.1 Architecture Design
3.2 UI/UX Design
3.3 Database Design
3.4 Interface Design
3.5 Design Reporting
4.0 Implementation
4.1 Development Environment Setup
4.2 Common Module Development
4.3 Business Function Development
4.4 Interface Development
4.5 Data Migration Development
5.0 Testing
5.1 Unit Testing
5.2 Integration Testing
5.3 System Testing
5.4 Performance Testing
5.5 User Acceptance Testing (UAT)
6.0 Deployment
6.1 Deployment Plan
6.2 Data Migration
6.3 System Cutover
6.4 Stabilization Operations
Schedule Planning
Based on the WBS, a detailed schedule is developed considering task duration, dependencies, and resource allocation.
| Technique | Description | Use Case |
|---|---|---|
| CPM (Critical Path Method) | Identifies the longest path to determine minimum project duration | Overall schedule optimization |
| PERT (Program Evaluation and Review Technique) | Three-point estimation (optimistic/pessimistic/most likely) reflecting uncertainty | Tasks with high uncertainty |
| Gantt Chart | Visualizes task start/end dates as bar graphs | Schedule status reporting |
| Milestones | Defines major checkpoints | Progress management reference points |
Resource Allocation Planning
# Staffing Plan Example (12-month SI project)
staffing_plan:
analysis_phase: # Months 1-3
PM: 1 person (100%)
PL: 1 person (100%)
analysts: 3 persons (100%)
DBA: 1 person (50%)
total: approximately 5.5 person-months per month
design_phase: # Months 3-5
PM: 1 person (100%)
PL: 1 person (100%)
designers: 4 persons (100%)
DBA: 1 person (100%)
UI_designer: 1 person (100%)
total: approximately 8 person-months per month
implementation_phase: # Months 5-10
PM: 1 person (100%)
PL: 1 person (100%)
developers: 8 persons (100%)
DBA: 1 person (100%)
QA: 2 persons (50%)
total: approximately 12 person-months per month
testing_deployment: # Months 10-12
PM: 1 person (100%)
PL: 1 person (100%)
developers: 6 persons (80%)
DBA: 1 person (100%)
QA: 3 persons (100%)
total: approximately 10.8 person-months per month
Risk Management
Project risks must be identified proactively and response strategies developed in advance.
| Risk Type | Example | Response Strategy |
|---|---|---|
| Scope Creep | Frequent additional requirements from client | Strict change management process, clear requirements freeze point |
| Staff Turnover | Key developer resignation | Knowledge sharing framework, backup personnel, enhanced documentation |
| Technical Risk | New technology adoption failure | Pre-project PoC, technology validation phase |
| Schedule Delay | Cascading delays from predecessor tasks | Critical path focused management, schedule buffers |
| Quality Risk | Insufficient test coverage | Test automation adoption, quality gates |
| External Dependency | External system integration delays | Early interface coordination, mock development |
Cost Estimation and ROI Analysis
Function Point (FP) Method
The Function Point method measures software functional size to estimate development costs and is an international standard (ISO/IEC 20926). It is the most widely used cost estimation method in Korean public IT projects.
Function Point Estimation Procedure:
1. Identify Function Types
- ILF (Internal Logical File)
- EIF (External Interface File)
- EI (External Input)
- EO (External Output)
- EQ (External Inquiry)
2. Assess Function Complexity
- Low, Average, High
- Based on DET (Data Element Types) and RET/FTR criteria
3. Calculate Unadjusted Function Points
- Apply weights based on function type and complexity
Weights by Function Type:
ILF: Low=7, Average=10, High=15
EIF: Low=5, Average=7, High=10
EI: Low=3, Average=4, High=6
EO: Low=4, Average=5, High=7
EQ: Low=3, Average=4, High=6
4. Apply Adjustment Factors
- Scale adjustment, application type adjustment, language adjustment, etc.
5. Calculate Final Development Cost
Cost per Function Point x Adjusted Function Points = Development Cost
Man-Month Estimation Method
# Man-Month Based Cost Estimation Example
labor_cost_estimation:
grade_based_monthly_rates: # 2026 baseline (illustrative)
professional_engineer: 12,500,000 KRW/month
senior_engineer: 10,800,000 KRW/month
advanced_engineer: 9,200,000 KRW/month
intermediate_engineer: 7,600,000 KRW/month
junior_engineer: 5,800,000 KRW/month
staffing_plan:
PM_senior: 12 person-months
PL_advanced: 12 person-months
analysts_advanced: 9 person-months (3 persons x 3 months)
designers_intermediate: 12 person-months (4 persons x 3 months)
developers_intermediate: 48 person-months (8 persons x 6 months)
QA_intermediate: 9 person-months (3 persons x 3 months)
DBA_advanced: 12 person-months
direct_labor_total: approximately 900,000,000 KRW
total_project_cost:
direct_labor: 900,000,000 KRW
overhead: 990,000,000 KRW # 110% of direct labor
technical_fee: 378,000,000 KRW # 20% of (direct labor + overhead)
direct_expenses: 150,000,000 KRW # equipment, SW licenses, training
total_cost: 2,418,000,000 KRW
profit: 241,800,000 KRW # 10% of total cost
total_project_budget: 2,659,800,000 KRW # approximately 2.66 billion KRW
TCO (Total Cost of Ownership) Analysis
TCO analyzes the total cost across the entire system lifecycle from introduction to decommissioning.
| Cost Item | Initial Cost | Annual Operating Cost | 5-Year TCO |
|---|---|---|---|
| Hardware/Infrastructure | 500M KRW | 50M KRW (maintenance) | 700M KRW |
| Software Licenses | 300M KRW | 60M KRW (maintenance) | 540M KRW |
| Development | 2,660M KRW | - | 2,660M KRW |
| Operations Staff | - | 400M KRW | 2,000M KRW |
| Training | 50M KRW | 10M KRW | 90M KRW |
| Data Migration | 100M KRW | - | 100M KRW |
| Total | 3,610M KRW | 520M KRW | 6,090M KRW |
ROI (Return on Investment) Analysis
ROI Calculation Framework:
1. Tangible Benefits
- Business processing time reduction: 200M KRW/year (labor savings)
- Manual error reduction: 50M KRW/year (rework cost savings)
- Operational efficiency: 300M KRW/year (process automation)
- Subtotal: 550M KRW/year
2. Intangible Benefits
- Improved decision-making speed
- Enhanced customer satisfaction
- Strengthened data-driven management capability
- Reduced regulatory compliance risk
3. ROI Calculation
5-year total benefits: 550M KRW x 5 years = 2,750M KRW
5-year TCO: 6,090M KRW
Simple ROI = (Total Benefits - Total Cost) / Total Cost
= (2,750 - 6,090) / 6,090
= -54.8%
However, including intangible benefits and opportunity costs:
Adjusted total benefits: 1,500M KRW/year (including intangible benefits)
5-year adjusted benefits: 7,500M KRW
Adjusted ROI = (7,500 - 6,090) / 6,090 = 23.2%
Break-even Point (BEP): Approximately 4 years and 1 month
SLA and Service Level Management
SLA Components
SLA (Service Level Agreement) is a systematic management tool that quantitatively defines IT service quality, monitors compliance, and applies penalties for non-compliance.
# SLA Definition Example
service_level_agreement:
service_availability:
target: 99.95%
measurement_period: monthly
excluded_time: planned maintenance (2nd Sunday monthly 02:00-06:00)
calculation: '(Total service time - Downtime) / Total service time x 100'
penalties:
99.90_to_99.95: 5% reduction of monthly maintenance fee
99.50_to_99.90: 10% reduction of monthly maintenance fee
below_99.50: 20% reduction of monthly maintenance fee
response_time:
online_transactions: average under 3 seconds (under 5 seconds during peak)
batch_processing: completed within designated time window
report_generation: within 30 seconds
incident_response:
critical: response within 30 minutes, resolution within 4 hours
major: response within 1 hour, resolution within 8 hours
minor: response within 4 hours, resolution within 24 hours
informational: response within 8 hours, resolution within 3 business days
SLA Monitoring Framework
| Monitoring Item | Measurement Tool | Frequency | Reporting Audience |
|---|---|---|---|
| System Availability | APM (Application Performance Monitoring) tools | Real-time | Monthly report |
| Response Time | RUM (Real User Monitoring) | Real-time | Weekly report |
| Incident Count/Recovery Time | ITSM (IT Service Management) system | Event-driven | Monthly report |
| Batch Processing Status | Job scheduler | Daily | Daily report |
| Security Events | SIEM (Security Information and Event Management) | Real-time | Monthly report |
SLA Improvement Cycle
Effective SLA management operates through a continuous improvement cycle.
SLA Improvement Cycle (PDCA):
Plan
- Define SLA metrics and target levels
- Establish monitoring framework
- Stakeholder alignment
Do
- SLA-based service operations
- Real-time monitoring
- Incident response process execution
Check
- Monthly/quarterly SLA achievement analysis
- Root cause analysis for non-compliance items
- Trend analysis and forecasting
Act
- Identify and execute improvement initiatives
- Adjust SLA standards (as needed)
- Optimize operational processes
Success Stories in IT Project Execution
Case 1: Public Agency Next-Generation System Build
Project Overview:
- Target: Core business system modernization for a government-affiliated public agency
- Scale: Approximately 5 billion KRW, 18 months
- Scope: Migration from mainframe-based systems to open platform (Java/Spring)
Critical Success Factors:
- Thorough As-Is Analysis: Three months of current state analysis precisely mapping 1,200 business functions and 800 screens
- Phased Migration Strategy: Sequential business domain migration instead of Big Bang to minimize risk
- Maximum Business User Participation: Dedicated business domain representatives assigned full-time to the project
- Test Automation: Regression test automation intercepted over 90% of migration errors before production
- Data Migration Rehearsals: Three full data migration rehearsals ensured data integrity during actual cutover
Lessons Learned:
- The most critical factor in modernization projects is accurate understanding of existing business logic
- Data migration must be managed as a separate track from the very beginning of the project
- Ample user training time must be secured to minimize post-launch disruption
Case 2: Financial Sector Cloud Migration
Project Overview:
- Target: Non-core business system cloud migration for a mid-tier financial company
- Scale: Approximately 3 billion KRW, 12 months
- Scope: Cloud migration of 20 application systems
Migration Strategy (6R Framework):
| Strategy | Systems Count | Description |
|---|---|---|
| Rehost | 8 | Move to cloud infrastructure without changes |
| Replatform | 5 | Optimize select platform elements for cloud |
| Refactor | 4 | Redesign with cloud-native architecture |
| Retire | 2 | Decommission discontinued systems |
| Retain | 1 | Keep on-premises (regulatory requirements) |
Critical Success Factors:
- Regulatory Pre-Review: Confirmed compliance with Financial Supervisory Service cloud usage guidelines
- Security Architecture Design: Established network segmentation, data encryption, and access control framework
- Cost Optimization: Combined reserved instances and auto-scaling for 40% annual cost reduction
- Incremental Migration: Started with non-core systems to build operational experience before expansion
Case 3: Enterprise ERP Enhancement Consulting
Project Overview:
- Target: ERP system enhancement strategy consulting for a major manufacturer
- Scale: Approximately 800 million KRW, 6 months
- Scope: ISMP development and ERP enhancement roadmap
Methodology:
- Business process standardization assessment across 14 global subsidiaries
- Gap analysis against industry best practices
- Feasibility analysis for ERP extension modules (SCM, PLM, MES)
- Three-year phased enhancement roadmap development
Key Deliverables:
- Current business/system analysis report
- Target architecture design document
- Initiative definition document (32 execution initiatives)
- Three-year implementation roadmap
- Investment budget plan (total approximately 15 billion KRW scope)
Conclusion
IT project success is not achieved through technical capabilities alone. It requires comprehensive competence -- understanding the essence of the business, accurately identifying client needs, and realizing them through systematic methodology and governance frameworks.
Core Principles for IT Business Planners and Proposal Writers:
- Think from the client's perspective: Lead with business value, not technology
- Prove it with numbers: Quantify even qualitative benefits to strengthen your argument
- Do not hide risks: Acknowledging risks and presenting mitigation strategies builds trust
- Create executable plans: Over-promising is the beginning of project failure
- Never neglect communication: Continuous stakeholder engagement reduces change risk
- Accumulate lessons learned: Manage every project's experience as organizational assets
The IT business landscape is evolving rapidly with cloud, AI, and digital transformation, but the importance of systematic planning and strong proposal capabilities remains constant. We hope this guide provides practical value to practitioners planning IT projects and writing proposals.
References
- National Information Society Agency (NIA), ISMP Development Guide
- Ministry of Science and ICT, Software Business Cost Estimation Guide (2025 Revised Edition)
- PMI, PMBOK Guide 7th Edition
- IFPUG, Function Point Counting Practices Manual (CPM) 4.3.1
- Korea Software Industry Association, Software Engineer Average Wage Publication
- ITIL 4 Foundation, Service Level Management Practice
- Public Procurement Service, Negotiated Contract Proposal Evaluation Guide
- Financial Supervisory Service, Financial Sector Cloud Usage Guidelines