IT 프로젝트는 다른 어떤 유형보다 더 자주 실패합니다. 보통 범위가 불명확하거나, 의존성이 누락되었거나, 커뮤니케이션이 약하기 때문입니다. Trupeer를 사용하면 무료 IT 프로젝트 계획 템플릿으로 시작해 브랜드 아이덴티티에 맞게 커스터마이징하고, 기술 및 비즈니스 이해관계자를 같은 방향으로 정렬해 주는 비디오 업데이트로 계획을 전환하여 계획 수립에 드는 시간을 몇 시간이나 절약할 수 있습니다.

IT 프로젝트 계획이 무엇인지, 왜 일반 템플릿이 어긋나는지

프로젝트 계획서는 무엇을, 언제, 누가 제공할지, 그리고 그 일이 일어나기 위해 무엇이 사실이어야 하는지를 명시한 문서입니다. 이 검색에서 상위에 노출되는 모든 템플릿은 대개 작업 목록 형태로 시작 날짜, 종료 날짜, 담당자, 그리고 간트 바(Gantt bar)를 포함해 그 내용을 제공합니다.

작업 목록 자체가 문제는 아닙니다. 문제는 그 목록을 채우는 순서입니다.

일반 템플릿은 먼저 여러분의 업무부터 시작합니다. 작업을 나열하고, 소요 기간을 추정한 뒤, 순서를 정하고, 담당자를 추가하면 종료 날짜는 맨 아래로 밀려납니다. 의존성은 그다음에 열(column) 형태의 메모로 추가됩니다.

IT 프로젝트가 잘 미뤄지는 이유는 그 추정치가 틀려서가 아닙니다. 계획에 없던 무언가가 도착해서, 그 사실을 두고는 논쟁할 수 없기 때문입니다. 예를 들어, 고-live 주간을 포함하는 변경 동결(change freeze), 6주 대기열이 있는 보안 검토, 분기 말까지 예약된 벤더의 구현 컨설턴트, 교체 준비가 되기 전에 갱신되는 라이선스, 환경을 한 달간 잠그는 감사(audit) 등이죠.

이 모든 것은 리스크가 아닙니다. 리스크는 일어날 수도 있는 무언가입니다. 이들은 계획을 시작하는 날 이미 사실이며, 누군가가 첫 주에 물어보기만 하면 각각을 모두 알 수 있습니다.

그래서 이 템플릿은 순서를 뒤집습니다. 먼저 움직일 수 없는 날짜를 그립니다. 그다음 남은 기간이 실제로 얼마나 넓은지 확인합니다. 마지막으로 그 안에 작업 일정을 배치합니다. 작업 목록은 여전히 존재하지만, 가장 먼저 쓰는 것이 아닐 뿐입니다.

Trupeer에서 이 템플릿을 커스터마이즈하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿(Templates) 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업하려는 템플릿을 클릭해 열어 주세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 명확히 확인하세요.

4단계: 템플릿 편집

선택한 템플릿을 수정하기 시작하려면 Edit을 클릭하세요.

편집기에서 다음을 할 수 있습니다:

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이즈한 템플릿 저장

필요한 모든 변경을 마친 후 Save를 클릭해 업데이트된 템플릿을 본인만의 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이즈한 템플릿이 어떻게 보이는지 확인하려면 Preview를 여세요.

미리보기 화면에서 필요하다면 계속해서 직접 조정할 수 있으며, 템플릿이 원하시는 그대로 정확히 표시되도록 할 수 있습니다.

IT 프로젝트 계획 템플릿으로 할 수 있는 것

• 계획 수립 시간을 절약: IT 이니셔티브에 맞게 구조가 잡힌 빈 페이지를 건너뛰세요.

• 기술적 복잡성 관리: 아키텍처, 의존성, 리스크를 위한 내장 섹션.

• 브랜드에 맞게 유지: Trupeer의 브랜드 키트로 로고, 폰트, 색상을 적용하세요.

• 비즈니스와 IT 정렬: 기술 계획을 비디오 업데이트로 전환해 비즈니스 이해관계자가 이해할 수 있게 하세요.

• 프로젝트 전반 표준화: 모든 IT 이니셔티브에 동일한 템플릿을 사용하세요.

• 글로벌 팀에 도달: 한 번의 클릭으로 계획과 업데이트를 65+개 언어로 번역하세요.

움직일 수 없는 것들, 그리고 어디서 찾는지

움직일 수 없는 것은 프로젝트에 보고하지 않는 누군가가 정한 어떤 날짜나 기간입니다. 프로젝트 내부에서는 협상할 수 없고, 늦게 발견하면 제약에서 위기로 바뀝니다.

1주차에 실행할 목록은 다음과 같습니다. 각 담당자에게 두 가지 질문을 하세요. “당신의 날짜는 언제인가요?” 그리고 “리드 타임(소요 리드)은 얼마나 되나요?”

이 중 두 가지는 특히 주의할 만합니다. 가장 자주 놓치기 때문입니다. 계약서의 통지 기간은 갱신일보다 앞에 놓이는 움직일 수 없는 날짜이며, 즉 실제 마감일은 다이어리에 적힌 날짜보다 더 이릅니다. 그리고 소스 시스템의 데이터 품질은 크기를 조회할 수 없는 유일한 움직일 수 없는 항목입니다. 직접 가서 측정해야 하므로, 소스 데이터를 프로파일링하는 일은 마이그레이션 단계가 아니라 1주차에 포함되어야 합니다.

무엇을 추정하기 전에 이들을 단일 캘린더에 그려 보세요. 찾고 있는 것은 ‘갭(gap)의 형태’입니다. 아주 자주, 그 갭은 프로젝트 기간보다 훨씬 좁고, 범위에 대한 솔직한 대화는 7개월째가 아니라 2주차에 일어납니다.

계획서에 들어갈 내용

움직일 수 없는 항목을 그려 놓으면, 계획서 자체에는 12개의 섹션이 있습니다. 제목을 복사하고, 아래 순서대로 채우세요.

1. 요약. 한 문장: 무엇이 바뀌고, 누구에게 어떤 변화가 생기며, 그 이후에는 무엇이 더 이상 사실이 아니게 되는지.

2. 결과 및 성공 기준. 측정 가능해야 하며 날짜가 있어야 합니다. 예를 들어, 레거시 시스템이 특정 날짜까지 트래픽이 없고 라이선스 비용이 없다는 식으로, 교체되는 대상에 대한 기준을 최소 하나 포함하세요. go-live에서 끝나는 계획은 기업이 두 개의 시스템 비용을 지불하게 되는 방식으로 이어집니다.

3. 제약 캘린더. 위의 움직일 수 없는 항목 표를 채우고, 그 결과로 생기는 납기 창(delivery window)을 날짜 범위 형태로 쉬운 문장으로 명시합니다.

4. 범위. 세 가지 목록: 포함(in), 제외(out), 보류(deferred). 보류 목록이 유용한데, 범위가 잘려 나갈 때 그 범위가 들어가는 곳이기 때문이며, 같은 대화가 네 번 반복되는 것을 막아 줍니다.

5. 단계와 마일스톤. 마일스톤은 관찰 가능한 답이 있는 이벤트입니다. 예: “보안 검토 통과” 또는 “첫 매장 라이브”처럼요. “디자인 단계 완료”처럼 모호한 표현이 아닙니다.

6. 작업 분해. 작업, 담당자, 추정치, 순서. 이 부분이 다른 모든 템플릿이 시작하는 지점입니다.

7. 의존성. 내부와 외부를 분리하세요. 모든 외부 의존성에는 다른 조직의 지정된 담당자와, 그들이 합의한 날짜를 적어야 합니다. 여러분이 가정한 날짜가 아니라요.

8. 환경과 데이터. 어떤 환경이 존재하는지, 각 환경에 어떤 데이터가 있는지, 테스트에서 프로덕션 데이터가 어떻게 보호되는지, 그리고 소스 데이터 프로파일링 결과가 무엇인지.

9. 전환(Cutover)과 롤백(Rollback). 전환을 위한 시간대별(hour by hour) 순서, 멈추는 결정 지점, 그 결정을 내리는 사람, 그리고 다시 돌아오는 방법. 이것은 실행 가능한 절차로 작성해야 하며, 여기에는 method of procedure template가 들어갈 자리입니다.

10. 트리거가 있는 리스크. 가능성과 영향의 매트릭스가 아닙니다. 각 리스크에는 관찰 가능한 트리거와, 그 트리거를 확인했을 때 실행되는 조치가 있어야 합니다. “5월 12일까지 벤더 컨설턴트가 확정되지 않음”은 트리거입니다. “벤더가 늦을 수도 있음”은 트리거가 아닙니다.

11. 커뮤니케이션, 교육 및 도입. 누가 무엇을 언제 전달받는지, 그리고 1일차에 사용자가 무엇을 할 수 있어야 하는지에 대한 기대치를 명시합니다.

12. 거버넌스 및 종료. 누가 결정하는지, 누가 에스컬레이션하는지, 결정 기록이 어떤 형태인지, 그리고 프로젝트가 완료되었다고 선언되어 운영으로 인계되는 조건이 무엇인지.

실제 사례와 그 비용

Ashmore Retail은 84개 매장과 3개의 물류센터(DC)를 보유하고 있으며, 2월에 모든 3개 DC의 창고 관리 시스템(WMS)을 교체하기 위해 계획을 시작했습니다. 9개월의 작업이었고, 11월 중순에 go-live를 계획했으며, 킥오프 덱(kickoff deck)에서는 피크보다 충분히 앞서 안착할 것처럼 설명했습니다.

그 킥오프 당일에 존재했던 움직일 수 없는 항목은 두 가지였습니다. 둘 다 공개되어 있었지만, 둘 다 계획에는 없었습니다.

첫 번째는 변경 동결(change freeze)이었습니다. 리테일 운영은 매년 1월에 이를 게시하며, 11월 1일부터 1월 15일까지 진행되어 피크 트레이딩을 커버합니다. 그 11주 동안 어떤 종류의 프로덕션 변경도 들어가지 않습니다.

두 번째는 레거시 계약이었습니다. 이 계약은 12월 31일에 추가 12개월 동안 갱신되었고, 금액은 186,000파운드였습니다. 90일 통지가 필요했기 때문에 실제 마감일은 10월 2일이었습니다.

프로젝트는 봄까지 계획대로 진행됐습니다. 보안 검토는 명시된 SLA가 2주였는데 4주가 걸렸습니다. 벤더의 구현 컨설턴트는 10월까지 사용할 수 없었는데, 7월에 요청했기 때문입니다. 두 번의 지연은 go-live를 11월 중순에서 11월 말로 옮기는 방식으로 흡수되었습니다. 아무도 동결 캘린더를 보고 있지 않았기 때문에, 누구도 이를 문제로 표시하지 않았습니다.

동결은 9월 초 변경 자문 위원회(change advisory board) 회의에서 드러났습니다. 11월의 go-live는 불가능했고, 다음으로 실행 가능한 창은 1월 16일에 열렸습니다.

그러면 10월 2일까지 하나의 선택만 남았습니다. 레거시 계약에 통지를 하고, 1월 1일부터 시작하되 비즈니스 전체가 의존하던 시스템에는 지원이 없는 상태로 갈 것인지, 아니면 계약을 갱신하고 11월에 꺼버릴 계획이었던 시스템의 1년 비용을 계속 지불할 것인지.

그들은 갱신을 선택했습니다. 새 시스템은 3월 4일에 라이브되었습니다. 레거시 계약은 52주 중 9주 동안 사용되었는데, 이는 186,000파운드 청구서 대비 약 32,000파운드의 가치에 해당합니다. 대략 154,000파운드는 아무것도 사지 못한 셈이었습니다.

교훈이 되는 부분은, 사람들이 ‘늦었다’고 말할 때의 의미로 프로젝트가 실제로 늦어진 적은 없었다는 점입니다. 작업은 합리적인 수준과 속도로 수행되었습니다. 잘못된 것은, 그 창이 누구도 그려 보지 않았던 것보다 6주 더 좁았고, 그 창을 정의한 두 날짜가 프로젝트가 존재하기도 전부터 공개 캘린더와 서명된 계약서에 이미 자리하고 있었다는 것입니다.

만약 2월에 제약 캘린더를 그렸다면 순서는 분명했을 겁니다. 11월 1일 이전에 go-live를 해야 하고, 실제로는 6주였던 4주짜리 보안 검토를 거꾸로 계산해 보며, 6주짜리 조달 경로와 분기 단위의 통지가 필요한 컨설턴트를 고려하면, 벤더 계약은 4월 중순까지 서명되어야 했습니다. 하지만 서명은 7월에 이루어졌습니다. 프로젝트는 더 빠르게 진행될 필요가 없었습니다. 움직일 수 없는 의존성을 11주 더 일찍 시작해야 했던 겁니다.

다섯 가지 IT 프로젝트 형태, 그리고 어떤 섹션이 무게를 지는지

이 검색에서는 ITSM 구현부터 인프라 업그레이드, PMO 구축까지 다양한 내용을 다루는 20개 IT 프로젝트 템플릿 목록이 흔합니다. 하지만 실제로는 다섯 가지 형태로 축약되며, 그 형태가 위의 어떤 섹션이 상세함을 요구하는지 알려줍니다.

교체(Replacement). 실행 중인 시스템을 다른 시스템으로 바꾸는 것. WMS, ERP, ITSM 툴링, 헬프데스크 플랫폼, HR 시스템이 포함됩니다. 섹션 3, 9, 2가 무게를 집니다. 어려운 부분은 창(window), 전환(cutover), 그리고 기존 것이 실제로 꺼졌음을 입증하는 일이기 때문입니다.

구현(Implementation). 선행 시스템이 없는 새로운 것. SLA 관리, IT 거버넌스 및 컴플라이언스 프로그램, 자산 관리, 지식 관리가 포함됩니다. 섹션 11과 2가 무게를 집니다. 이전에 아무것도 깨진 적이 없으므로, 도입(adoption)만이 그것을 현실로 만듭니다. 이에 대해 더 깊게 다루는 디지털 도입 구현 가이드가 있습니다.

마이그레이션 또는 제자리 업그레이드(Migration or upgrade in place). 동일한 시스템에 새 버전, 새 호스트 또는 새 리전. 가상화, 통합(consolidation), 클라우드 마이그레이션, 데이터베이스 업그레이드가 포함됩니다. 섹션 8과 9가 무게를 집니다. 롤백이 전부이기 때문입니다.

구축(Build). 소프트웨어 개발과 프로세스 자동화. 섹션 4가 무게를 집니다. 범위(scope)는 움직이는 변수이고, 수용 기준(acceptance criteria)이 조용히 움직이지 못하게 막는 것이기 때문입니다.

프로그램 및 보증(Programme and assurance). PMO 구축, IT 감사, 포트폴리오 관리, 리스크 관리, 보안 컴플라이언스. 섹션 12가 무게를 집니다. 전달물(deliverable)은 작동하는 시스템이 아니라 증거와 승인(sign-off)이기 때문이며, 마일스톤은 다른 누군가가 정한 검토 날짜입니다.

만약 프로젝트가 이 다섯 가지 중 어느 하나에 깔끔하게 들어맞지 않는다면, 보통은 하나의 이름으로 묶어 놓은 두 개의 프로젝트가 있는 경우입니다.

하루 만에 계획서 만들기

오전에는 움직일 수 없는 항목을 그립니다. 표에 있는 각 담당자에게 두 가지 질문을 보내고, 꼬리가 가장 긴 답이기 때문에 먼저 벤더와 보안 쪽 답을 추적하세요. 돌아오는 모든 날짜를 하나의 캘린더에 정리하고, 그 결과로 생기는 창을 한 문장으로 명시합니다.

오후에는 섹션 1, 2, 4를 작성한 다음 마일스톤을 적습니다. 상세한 작업 분해는 배송(납품) 팀이 그 주에 채우도록 남겨 두세요. 계획은 창과 범위가 합의되는 순간부터 유용해지며, 그 안에 400줄이 들어간다고 해서 더 유용해지지는 않습니다.

모든 거버넌스 회의에서 창과 대조해 검토하세요. 물어볼 만한 단 하나의 질문은 “우리가 일정대로 가고 있나”가 아니라 “움직일 수 없는 항목 중 하나라도 움직였나”입니다. 동결은 연장되고, 감사는 재조정되며, 벤더는 컨설턴트를 잃습니다. 이런 변화는 밀린 작업이 만들어내는 방식과는 다른 형태로 계획을 재구성합니다.

빼야 할 것

모든 작업에 대한 간트 차트(Gantt chart)는 계획서 문서에 들어가면 안 됩니다. 그것은 일정을 잡는 데 사용하는 어떤 도구에 들어가야 하며, 문서로 중복하면 2주 안에 서로 다른 두 버전이 생깁니다.

점수까지 포함한 전체 리스크 레지스터(risk register)도 여기 두면 안 됩니다. 트리거와 날짜가 있는 리스크만 유지하고, 나머지는 레지스터에 넣으세요.

작업이 어떻게 수행되는지에 대한 상세 절차는 IT SOP에 두고, 무엇을 만들었는지에 대한 설명은 계획서가 아니라 IT documentation에 두는 것이 맞습니다. 인계(handover)를 운영(run) 팀에 제대로 계획하는 것은 knowledge transfer SOP가 하는 일입니다.

문서를 멈추고 소프트웨어를 써야 하는 시점

문서는 계획을 두고 논의하는 동안에는 올바른 컨테이너입니다. 보통 첫 한 달이 그 기간입니다. 동시에 세 가지가 참이 되면 문서는 더 이상 올바른 컨테이너가 아닙니다. 30개가 넘는 작업이 라이브 상태가 되고, 4명 이상이 상태를 업데이트하고 있으며, 작업 간 의존성이 매주 바뀌기 시작할 때입니다.

그 시점에는 작업 분해를 일정 소프트웨어로 옮기고, 문서는 섹션 1~5와 12만 남기세요. 이 부분은 도구를 절대 열지 않을 사람들이 읽는 영역이기 때문입니다. 문서는 합의를 담고, 도구는 일정을 담습니다.

계획서를 배송(납품) 팀이 실제로 따르는 형태로 전환하기

계획서는 킥오프와 스티어링 미팅에서 읽힙니다. 전환(runbook)은 새벽 2시에, 둘 중 어느 회의에도 참석하지 않았던 누군가가 읽습니다.

Trupeer AI는 화면 녹화를 문서화된 프로세스로 바꿔 주므로, 섹션 9의 전환 단계와 섹션 11의 1일차 작업이 그것을 설명하는 문단이 아니라 실제 시스템을 따라가는 워크스루가 됩니다. 순서를 한 번 기록하면, 지식 베이스에 있는 여러분의 고유 브랜딩으로 단계별 가이드, 비디오, 문서를 얻을 수 있습니다.

기록하세요. 브랜딩하세요. 번역하세요. Trupeer하세요.

섹션 11의 도입 작업에서는 변경 관리와 교육 비디오가 롤아웃 측면을 다루고, 문서는 계획, runbook, 인계 자료를 한데 묶어 둡니다. 설정 안내는 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Excel에서 사용할 수 있는 무료 IT 프로젝트 계획 템플릿이 있나요?

저희가 파일 형태로 제공하는 것은 아니며, 그 트레이드오프에 대해서는 솔직하게 말할 가치가 있습니다. Excel은 섹션 6의 작업 분해를 담는 데 실제로 더 나은 컨테이너입니다. 날짜, 의존성, 롤업은 셀에 들어가야 하기 때문입니다. 작업(task), 담당자(owner), 시작(start), 종료(end), 의존성(dependency), 상태(status), 움직일 수 없는 항목 플래그(immovable flag)를 위한 열을 만들어 직접 그 시트를 작성하세요. 섹션 1~5, 9, 12는 문서로 유지하세요. 이들은 글로 논의되며, 스프레드시트에서는 아무도 범위를 협상하지 않기 때문입니다.

Word 버전도 있나요, Word 문서를 무료로 다운로드할 수 있나요?

위의 12개 섹션 구조는 Word 또는 Google Docs에 그대로 복사해 넣을 수 있도록 작성되었습니다. 제목을 붙여넣고 번호를 유지한 뒤, 제시된 순서대로 채우세요. 잠금 다운로드가 없다는 것은, 여러분과 구조 사이에 양식이 없다는 뜻이기도 합니다.

PDF 버전도 있나요?

섹션을 편집기에 붙여넣고 계획이 합의되면 PDF로 내보내세요. 계획서는 서명 승인 시점에서 PDF로 고정해 두는 것이 가치가 있고, 그 이전에는 편집 가능하게 유지하는 것도 가치가 있으므로, 고정 파일에서 시작하는 것보다 적절한 순간에 본인 복사본을 내보내는 편이 더 좋습니다.

킥오프 덱용 PPT 버전도 있나요?

덱은 다른 문서이며, 다른 역할을 합니다. 보통 6장 정도가 적당합니다. 결과(outcome), 제약 캘린더에서 나온 납기 창(delivery window), 범위의 포함/제외(in and out), 마일스톤, 지정된 외부 의존성, 그리고 무엇을 누가 결정하는지. 작업 분해를 덱에 넣지 마세요. 아무도 프로젝터에서 간트 바를 읽지 않습니다.

무료로 다운로드할 수 있나요?

구조, 움직일 수 없는 항목 표, 그리고 실제 사례는 무료이며 제한이 없습니다. 사용하고, 편집하고, 본인 이름으로 본인 템플릿 라이브러리에 넣으세요.

프로젝트 납품 계획은 프로젝트 계획과 같은 건가요?

구분이 거의 의미 없을 정도로 충분히 가깝습니다. 조직에서 이를 분리하는 경우, 프로젝트 계획은 비즈니스 케이스와 종료를 포함해 프로젝트 전체 생애주기를 다루고, 납품 계획은 구축과 릴리스 부분만 다룹니다. 거버넌스에서 둘 다 요구한다면, 위의 계획서를 작성하고 섹션 5~9를 납품 계획으로 취급하세요.

별도의 프로젝트 관리 보고서 템플릿도 필요하나요?

네, 그리고 예상보다 훨씬 짧게 유지하세요. 계획을 반복하는 상태 보고서는 한 달 안에 무시됩니다. 네 가지를 보고하세요. 움직일 수 없는 항목 중 하나라도 이동했는지, 창이 여전히 충분히 넓은지, 오늘 이 그룹에서 어떤 결정을 받아야 하는지, 그리고 지난번 이후 리스크 목록에서 어떤 것이 트리거되었는지.

IT 프로젝트 계획서는 얼마나 상세해야 하나요?

새로 합류한 사람이 다음에 무슨 일이 일어나는지 알 수 있을 만큼, 그리고 그 이상은 필요 없습니다. 실제로 9개월 프로젝트의 계획서 문서는 대략 8~15페이지이며, 그 대부분은 섹션 8과 9입니다. 문서가 전환(runbook)보다 길다면 균형이 맞지 않는 것입니다.

계획서는 얼마나 자주 업데이트해야 하나요?

섹션 6과 7은 매주 바뀌며, 팀이 이미 작업하는 곳 어디든 두면 됩니다. 섹션 1~5는 드물게 바뀌어야 하며, 이들에 대한 변경은 모두 누군가가 승인해야 하는 결정입니다. 범위 섹션이 매주 조용히 편집되고 있다면, 계획이 있는 게 아니라 다이어리가 있는 것입니다.