프로젝트 계획서는 아이디어를 현실로 바꾸는 마스터 문서입니다. 범위와 일정부터 예산과 리스크까지 모든 것을 담아내죠. Trupeer를 사용하면 무료 프로젝트 계획서 템플릿으로 시작해 브랜드 아이덴티티에 맞게 커스터마이징하고, 계획을 비디오 워크스루로 변환해 이해관계자를 빠르게 정렬할 수 있어 계획에 드는 시간을 몇 시간이나 절약할 수 있습니다.

프로젝트 계획서 템플릿이란 무엇이며, 무엇이 아닌가요?

프로젝트 계획서는 무엇을, 어떤 순서로, 누가, 언제까지 제공할지, 그리고 무엇에 의존하는지를 정리합니다. 시작할 때 한 번 작성하고 합의한 뒤, 현실을 비교하는 기준이 됩니다.

트래커는 현재 작업이 어디까지 와 있는지를 기록합니다. 매주 바뀌며 최신 위치를 반영하고, 의도를 기록하기보다는 상태를 보여주는 것이 역할입니다.

프로젝트 계획서 템플릿을 검색하면 대부분 트래커를 보게 됩니다. 이는 템플릿을 비판하려는 말이 아닙니다. 사람들이 실제로 필요로 하는 것이 무엇인지 보여주는 반영일 뿐입니다. 이 용어와 관련된 검색의 대부분이 Excel, Google Sheets 또는 트래커를 명시적으로 가리키기 때문이죠.

문제는 이 둘이 하나의 스프레드시트로 합쳐지고, 그 조합이 계획서가 존재하는 유일한 목적을 망친다는 점입니다. 날짜를 제자리에서 수정하면 원래의 약속은 사라지고, “우리는 늦었나?”라는 질문은 답할 수 없게 됩니다.

대부분의 사람들은 계획을 찾을 때 트래커가 필요합니다

이 부분은 솔직하게 말하는 게 좋습니다. 그래야 무엇을 만들어야 하는지 결정할 수 있기 때문입니다.

질문이 “무엇이 어떤 순서로 진행되어야 하고, 무엇이 무엇에 달려 있는가”라면 계획서가 필요합니다. 계획서는 한 번 작성하고, 논의하며, 순서와 의존성을 포함합니다. 저희 IT 프로젝트 계획서 템플릿은 대부분의 템플릿이 놓치는 외부 제약 조건을 바탕으로 계획서를 만드는 방법을 다룹니다.

질문이 “각 항목의 현재 상태는 무엇이고, 무엇이 늦었는가”라면 트래커가 필요합니다. 트래커는 매주 유지 관리되며, 계획서보다 훨씬 짧아야 합니다.

대부분의 팀은 둘 다 필요하지만, 대부분의 팀은 하나의 스프레드시트를 만들어 그것을 계획서라고 부릅니다. 그 스프레드시트에는 작업, 담당자, 시작일, 종료일, 완료율이 들어 있고, 계속해서 편집됩니다. 기억이 없는 트래커일 뿐입니다.

이 페이지의 나머지는 거의 모든 사람에게 실용적인 답인, 한 파일 안에서 이 둘을 분리해 유지하는 방법에 관한 내용입니다.

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

1단계: 템플릿 섹션 열기

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

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

열고 작업하고 싶은 템플릿을 아무거나 클릭하세요.

3단계: 템플릿 보기 확장

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

4단계: 템플릿 편집

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

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

• 새 섹션 추가

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

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

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

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

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

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

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

프로젝트 계획서 템플릿으로 할 수 있는 일:

• 계획에 드는 시간을 절약: 포괄적인 프로젝트 계획서 구조로 빈 페이지를 건너뛰세요.

• 모든 관점을 커버: 범위, 일정, 예산, 리스크, 커뮤니케이션을 위한 내장 섹션.

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

• 이해관계자 정렬: 밀도 높은 계획서를 모두가 5분 안에 볼 수 있는 비디오 요약으로 전환하세요.

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

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

기준선(baseline)이 없는 프로젝트 계획서는 트래커입니다

한 줄로 정리하면 이렇습니다. 계획서의 날짜가 매주 업데이트하는 동일한 셀이라면, 계획서가 아닙니다.

기준선은 합의된 날짜 집합을 고정(frozen)한 것입니다. 절대 편집하지 않습니다. 날짜가 이동하면 예측(forecast)은 바뀌지만 기준선은 바뀌지 않습니다.

이 한 가지 원칙만으로, 그렇지 않으면 가질 수 없는 세 가지를 얻습니다.

늦었는지, 그리고 얼마나 늦었는지. 감정이 아니라 숫자입니다. 작업별로, 그리고 전체로 확인할 수 있어요.

지연이 어디서 시작됐는지. 프로젝트에서 발생한 대부분의 지연은 소수의 근본 원인으로 추적됩니다. 그리고 그 모든 후속 작업이 그것을 그대로 물려받습니다. 기준선이 없으면 “많은 작업이 이동했다”는 것만 보일 뿐, “한 가지 결정 때문에 9주가 걸려 그중 40개가 이동했다”는 사실은 알 수 없습니다.

추정이 얼마나 정확한지. 여러 프로젝트에서 기준선과 실제 데이터를 비교하는 것은, 조직이 현실적으로 계획을 세우는지에 대해 갖는 유일한 피드백 루프입니다. 제자리에서 편집하는 팀은 이를 알 수 없습니다.

참고로 기준선 재설정(re-baselining)은 정당하지만, 스프레드시트를 업데이트하는 부수적 결과가 아니라 날짜와 이유를 포함한 결정이어야 합니다. 원래의 기준선도 그대로 유지하세요.

기준선과 예측을 분리해 유지하는 방법

같은 행에 두 세트의 날짜 열, 그리고 한 가지 규칙.

원인(cause) 열은 사람들이 빼먹는 열이면서, 동시에 분산(variance) 리포트를 실행 가능한 것으로 바꿔주는 열입니다. 이것이 없으면 40개의 작업이 이동했다는 것만 알 수 있습니다. 하지만 있으면, 동일한 상위 의사결정 때문에 그중 30개가 이동했다는 것을 알 수 있는데, 이는 완전히 다른 대화입니다.

기준선(baseline) 열은 실수로 편집할 수 없도록 보호하세요. 스프레드시트에서는 잠금(locking)으로, 프로젝트 소프트웨어에서는 보통 사람들이 존재를 알지 못하는 명시적 기준선 기능으로 처리합니다.

트래커는 계획서보다 행(row)이 더 적어도 되는 이유

두 번째 실패는 ‘물량(volume)’이며, 이것이 트래커가 틀려서가 아니라 버려지게 만드는 원인입니다.

계획서는 합리적으로 모든 작업을 포함합니다. 반면 트래커는 지연이 중요한 행만 있으면 됩니다. 즉, 핵심 경로(critical path)와 프로젝트 밖의 누군가에게 달린 모든 의존성이 해당됩니다.

한 사람이 매주 300개 행을 업데이트하면 90분이 걸리고, 4개월쯤 지나면 더 이상 지속되지 않습니다. 40개 행은 20분이면 되고, 계속 유지됩니다.

트래커에서 빠진 작업이 관리되지 않는 것은 아닙니다. 그 작업 스트림을 담당하는 사람이 각자의 목록에서 관리하며, 트래커에서만 위협이 되는 경우에만 표면화됩니다.

어떤 행이 트래커에 들어가야 하는지 판단하는 테스트는 이것입니다. 만약 이 작업이 2주 늦어지면 프로젝트의 종료일이 바뀌나요, 아니면 프로젝트 밖의 누군가에게 알려야 하나요? 둘 다 아니라면, 그 작업은 계획서에 있어야지 주간 업데이트에 들어가면 안 됩니다.

무료 프로젝트 계획서 템플릿: 복사할 열(columns)

여기서 복사하세요. 계획서와 트래커를 합친 한 장의 시트, 그리고 두 번째 시트는 내러티브(narrative)용입니다.

시트 1, 작업. 작업 ID. 작업 이름, 동사부터. 워크스트림. 담당자, 특정한 개인. 선행 작업 ID. 기준선 시작. 기준선 종료. 예측 시작. 예측 종료. 실제 시작. 실제 종료. 계산된 일 단위 분산(variance). 분산 원인(cause). 상태: 시작 전, 진행 중, 완료, 차단됨(blocked). 트래커에: 예 또는 아니오. 메모.

시트 2, 계획서 내러티브. 목표와 성공 기준, 프로젝트 브리프를 참조. 범위 포함/제외. 가정(assumptions)은 각각 번호를 매겨 분산 원인이 이를 가리킬 수 있게 합니다. 외부 의존성은 상대와 합의한 당사자 및 날짜를 기재. 리소싱. 점수(score) 대신 트리거(trigger가 있는 핵심 리스크. 기준선 날짜와 누가 승인했는지.

시트 3, 분산 로그(variance log). 원인(cause) 열에서 채워집니다. 각 근본 원인마다 한 행씩, 그 원인이 영향을 준 작업 수와 추가된 일 수를 기록하세요. 이 시트는 스티어링 미팅에서 읽히는 문서입니다.

여기까지 복사하세요. 분산 로그는 가치가 집중되는 곳이며, 이미 수집하고 있는 데이터로부터 파생되기 때문에 비용이 들지 않습니다.

늦었는지 말할 수 없었던 ERP 프로젝트

식품 제조사 Netherfield Foods는 새로운 엔터프라이즈 시스템을 도입했습니다. 계획서는 340개의 행을 가진 스프레드시트였고, 작업, 담당자, 시작, 종료, 완료율이 들어 있었습니다. 매주 제자리에서 업데이트했습니다.

14개월이 지난 어느 날, 스폰서가 합리적인 질문을 했습니다. “우리는 늦었나요, 그리고 얼마나 늦었나요?”

아무도 답할 수 없었습니다. 스프레드시트에는 현재 예측이 표시되어 있었는데, 이는 최초 계획보다 약 5개월 뒤에 가동(go-live)되는 내용이었습니다. 하지만 원래 날짜는 약 60번 정도 덮어써졌고, 파일 안에는 그 기록이 존재하지 않았습니다.

그들은 1개월 차에 이메일로 발송된 계획서 PDF에서 기준선을 재구성했습니다. 그 PDF는 여전히 스폰서의 받은 편지함에 있었습니다. 이 작업에는 3일이 걸렸습니다.

재구성은 누구도 예상하지 못한 것보다 더 유용했습니다. 원래 계획은 11개월이었고, 예측은 지금 16개월이었습니다. 340개 작업 중 61개는 4주 이상 이동했습니다. 그 61개 중 44개는 단 세 가지 지연의 하류(downstream)였습니다. 데이터 마이그레이션 의존성, 서드 파티 통합, 그리고 9주가 걸린 계정과목표(chart of accounts) 결정이 그것이었습니다.

세 가지 근본 원인이 전체 이동의 약 72%를 차지했지만, 그 어떤 것도 보이지 않았습니다. 모든 날짜가 제자리에서 편집되었고, 스프레드시트는 언제나 현재만 보여줬기 때문입니다.

같은 기원에서 발생한 두 번째 문제도 있었습니다. 340개 행이었기 때문에 주간 업데이트는 약 90분이 걸렸고, 한 사람이 수행했습니다. 9개월 차에는 격주로 하게 되었고, 약 190개 행의 완료율 수치는 3개월 동안 변하지 않았습니다.

5개월 지연으로 인해 외부 계약자와 내부 리소스에서 대략 48만 파운드의 비용이 들었습니다. 더 피할 수 있었던 비용은 계정과목표 결정이었습니다. 이 결정은 6주 동안 에스컬레이션되지 않은 채로, 트래커에는 아무것도 차단(blocking)으로 표시되지 않았기 때문에 22개의 하류 작업을 막고 있었습니다.

다음 단계에서는 두 가지가 바뀌었습니다. 기준선 날짜는 각자의 열에서 고정되어 잠겼습니다. 예측 날짜는 그 옆에 배치되어 계산된 분산과 원인(cause) 열이 함께 표시됐습니다. 그리고 트래커는 340개 행에서 47개 행으로 줄었습니다. 즉, 핵심 경로와 모든 외부 의존성만 남긴 것이죠. 나머지 작업은 계획서에 그대로 두고, 워크스트림 리드가 관리했습니다.

주간 업데이트는 90분에서 약 20분으로 줄었습니다. 이 단계는 7개월로 계획되어 7개월 3주 만에 제공되었습니다. 발생한 두 가지 지연은 모두 1주 안에 플래그가 지정됐는데, 핵심 경로 행에서 2주 분산이 자동으로 드러났기 때문입니다. 300개 중 하나의 셀만 바뀌는 방식이 아니었습니다.

모든 프로젝트 계획서에 필요한 핵심 요소

목표와 성공 기준. 프로젝트가 무엇을 위한 것이며, 어떻게 알 수 있는지. 여기서 말하는 성공은 ‘작동했는지’를 판단하는 기준입니다. 여기서는 브리프에서 가져오며, 임의로 만들어내지 않습니다.

범위(포함/제외). 제외 목록은 분쟁을 막아주는 목록입니다.

담당자가 있는 작업. 팀이 아니라 이름이 있는 개인.

순서와 의존성. 어떤 작업이 어떤 작업에 달려 있는지. 그래야 날짜가 의미를 갖게 됩니다.

외부 의존성. 프로젝트 밖의 어떤 당사자에 의존하는 모든 것. 가정한 날짜가 아니라, 그들이 합의한 날짜가 있어야 합니다.

기준선 날짜. 합의하고 고정하며, 누군가가 승인합니다.

가정(assumptions), 번호로 표시. 무언가가 밀리면, 실패한 가정이 원인을 가리킬 수 있도록 하기 위해서입니다.

리소스. 누가, 얼마나(시간 기준), 그리고 대신 무엇을 하지 않는지.

트리거가 있는 리스크. 가능성 점수(likelihood score)가 아니라, 관찰 가능한 조건과 실행할 행동.

가장 자주 빠지는 두 가지는 번호가 매겨진 가정과, 상대와 합의한 외부 의존성 날짜입니다. 둘 다 계획 단계에서 비용이 거의 들지 않으며, 6개월 뒤 분산 분석이 필요할 때 바로 그 둘이 필요합니다.

처음부터 끝까지 프로젝트를 계획하는 방법

작업 목록(task list)에서 시작하지 말고 브리프에서 시작하세요. 문제와 성공 기준을 말할 수 없다면, 계획서는 활동 목록이 되어버립니다.

작업 전에 산출물(deliverables)을 나열하세요. 산출물에서 도출된 작업은 완료됩니다. 반면 산출물 없이 바로 떠올린 작업은 전체 영역을 놓치기 쉽습니다.

그다음 순서를 정하고 의존성을 찾으세요. 특히 다른 팀과 공급업체에 달린 의존성을 확인해야 합니다. 저희 조달 관리 계획서 템플릿은 종종 핵심 경로에 숨어 있는 조달 리드 타임을 다룹니다.

작업을 실제로 수행할 사람들과 함께 추정하고, 정말로 불확실한 경우에는 추정을 범위로 기록하세요.

이제 기준선을 설정하세요. 누군가 승인하게 하고, 날짜를 기록한 뒤 열을 잠급니다.

위의 2주 테스트를 사용해 어떤 행이 주간 트래커에 들어갈지 결정하세요.

그다음 주기는 이렇게 설정합니다. 작업 담당자가 주간 예측 업데이트를 하고, 월간으로 분산 검토를 하며 원인을 확인합니다. 그리고 기준선 재설정은 명시적인 결정이 있을 때만 수행하세요.

프로젝트 계획서 변형: 간트(Gantt), 문서, 애자일

간트 차트 계획. 동일한 작업 데이터가 타임라인 위에서 막대 형태로 표시됩니다. 의존성과 여유(float)를 파악하기에 탁월하며, 다른 문서가 아니라 ‘보기(view)’입니다. 표를 먼저 만들고, 그 표로부터 차트를 생성하세요.

계획서 문서. 내러티브 버전입니다. 목표, 범위, 접근 방식, 가정, 리스크, 리소싱을 포함하되, 일정은 내장(embedded)하지 않고 첨부합니다. 이것이 승인되는 문서이며, 저희 프로젝트 오버뷰 템플릿은 프로젝트 밖의 사람들에게 보여주는 더 짧은 버전을 다룹니다.

애자일 계획. 작업 단위의 일정이 아니라 스프린트 또는 증분(increments)으로 구성하되, 범위는 변수가 되고 날짜는 고정합니다. 기준선은 여전히 적용되지만, 작업 기준이 아니라 결과(outcomes)와 릴리스 날짜 기준으로 기준선을 설정합니다.

간단형 또는 1페이지 계획. 마일스톤, 담당자, 날짜만. 소규모 프로젝트에는 정말로 충분하며, 관리되지 않는 300개 행 스프레드시트보다 훨씬 낫습니다.

프로그램 계획. 교차 의존성을 가진 여러 프로젝트. 여기서는 기준선의 원칙이 더 중요합니다. 덜 중요하지 않아요. 흥미로운 분산은 항상 인터페이스에서 발생하기 때문입니다.

프로젝트 계획서, 브리프 또는 오버뷰: 무엇이 필요하신가요?

세 가지 문서는 모두 스폰서에게 보여지기 때문에 혼동됩니다.

브리프는 문제를 제시하고 작업을 승인합니다. 먼저 작성하고 고정한 뒤, 계획서에 의해 대체됩니다. 저희 프로젝트 브리프 템플릿에서 확인할 수 있습니다.

계획서는 작업이 어떻게 제공될지 다룹니다. 기준선을 설정한 뒤 그 기준에 대해 추적하며, 이 페이지가 바로 그 내용입니다.

오버뷰는 프로젝트 밖의 사람들을 위해 현재 상황을 요약하며, 매달 다시 작성됩니다. 저희 프로젝트 오버뷰 템플릿에서 확인할 수 있으며, 상태 색상이 독자에게 아무 의미도 알려주지 않는 이유까지 포함합니다.

일정이 아니라 게이트 조건이 필요하다면, 저희 프로젝트 체크리스트 템플릿에서 각 항목이 실제로 실행 가능한 시점과, 프로젝트가 끝날 때까지 남아야 할 것들을 다룹니다. 또한 저희 프로젝트 문서화 템플릿에서 보관할 가치가 있는 문서 세트를 확인할 수 있습니다.

Excel 또는 Google Sheets에서 프로젝트 계획서 템플릿을 받을 수 있나요?

Excel 또는 Google Sheets이며, 대부분의 프로젝트에서는 타협안이 아니라 정답입니다. 작업 시트는 계산된 열이 있는 표이며, 수식이 필요합니다.

한 번만 설정하면 되는 세 가지가 있습니다. 기준선 날짜 열을 잠가서 편집할 수 없게 하세요. 분산 수식과 임계값을 넘는 항목을 표시하는 조건부 서식을 추가하세요. 여기서 2주는 합리적인 기본값입니다. 그리고 트래커 열에 필터를 추가해, 주간 업데이트 보기가 300개가 아니라 40개 행이 되도록 하세요.

Google Sheets에는 주목할 만한 장점이 있습니다. 버전 기록이 자동으로 제공되어, 제자리에서 편집하더라도 기준선을 복구할 수 있다는 점이죠. 이는 열을 잠그는 것에 대한 훌륭한 대체가 아니며, 그럼에도 프로젝트를 살려낸 사례가 있습니다.

계획서 내러티브에는 Word 또는 Google Docs를 사용하세요. 이 문서는 글(산문)로 작성되며 승인됩니다.

제시할 계획서에는 PowerPoint를 사용하세요. 여기에는 작업 목록이 아니라 마일스톤과 의존성이 들어가야 합니다.

승인 시점의 기준선 버전은 PDF로 내보내고 날짜를 포함해 보관하세요. 이 파일 하나를 유지하는 것이, 위의 실제 예시에서 기준선을 재구성할 수 있었던 이유에 해당합니다.

스프레드시트를 그만 쓰고 소프트웨어를 써야 하는 시점

스프레드시트는 비교적 예측 가능한 시점에서 더 이상 적절한 도구가 아니게 되며, 이는 소프트웨어 벤더들이 말하는 시점보다 더 늦습니다.

세 가지 조건이 함께 나타나면 신호입니다. 대략 100개 이상의 트래킹 작업, 같은 파일을 업데이트하는 4~5명 이상의 사람, 그리고 수동으로 순서를 다시 계산하기엔 오류가 생기기 쉬울 정도로 자주 바뀌는 의존성입니다.

그 아래라면, 기준선을 잘 설정하고 잠근 시트는 아무도 로그인하지 않는 프로젝트 소프트웨어보다 낫습니다.

그 위라면, 소프트웨어가 제공하는 특정 기능들이 자동 의존성 재계산, 실제 기준선 기능, 프로젝트 간 리소스 레벨링, 감사 추적(audit trail)입니다. 반대로 빼앗기는 것은 프로젝트 밖의 사람들이 더 이상 열 수 없다는 점인데, 그래서 많은 조직이 결국 둘 다 유지하게 되고, 그럴 필요가 없다는 것입니다.

만약 이동한다면, 기준선 재설정(re-baseline)할 때마다 기준선이 반영된 사본을 스프레드시트로 내보내세요. 5년 뒤 계획서를 읽을 수 있는 능력이 라이선스에 의존해서는 안 되기 때문입니다.

계획서를 팀이 하는 일과 연결해 유지하는 방법

계획서는 작업을 설명합니다. 그 작업이 계획서가 가정한 방식대로 진행되고 있는지는 일정(schedule)에서는 보이지 않으며, 보통 그 격차는 한 달 동안 완료율 80%에서 멈춰 있는 작업으로 나타납니다.

가장 흔한 이유는 어떤 작업이 알고 보니 아무도 설명하지 않았던 작업을 포함하고 있었고, 그 일을 하는 사람이 이제 날짜 기준으로 트래킹되면서 동시에 프로세스를 새로 만들어내고 있기 때문입니다.

Trupeer AI는 바로 이 지점에서 도움이 됩니다. 일을 하는 사람이 프로세스를 한 번 기록하면, 출력물은 단계와 화면이 캡처된 ‘문서화된 가이드’가 됩니다. 그러면 다음에 같은 일이 생겼을 때 더 빠르게 처리할 수 있고, 그에 대한 추정도 실제가 됩니다. 또한 분산 원인(cause)에 붙일 수 있는 구체적인 근거도 제공합니다. 예를 들어 “이 단계가 하나가 아니라 네 개의 시스템을 포함해서, 세 배나 오래 걸렸습니다.” 같은 식이죠.

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

이 녹화/기록물은 나중에 인수인계와 교육 자료가 되므로, 노력은 단순 보고에만 쓰이지 않습니다. 자료는 지식 베이스에 일관된 브랜딩으로 보관되며, 프로젝트가 끝날 때 무엇을 인수인계하는지에 대해서는 저희 프로젝트 인수인계 템플릿이 수령 팀이 실제로 필요로 하는 내용을 다룹니다. 설정 지침은 문서 템플릿 설정 가이드에 있습니다.

자주 묻는 질문

Excel에서 무료 프로젝트 계획서 템플릿이 있나요?

Excel은 대부분의 프로젝트에 적합한 형식이며, 위의 열 구성은 한 장의 시트로 바로 구성됩니다. 게이트가 있는 다운로드도 없고, 폼도 없습니다. 이미 사용 중인 어떤 템플릿이든 바꿔야 할 두 가지는 기준선 날짜 열을 잠그는 것과 분산 옆에 원인(cause) 열을 추가하는 것입니다.

Word에서 무료 프로젝트 계획서 템플릿이 있나요?

Word는 계획서 내러티브에 적합합니다. 목표, 범위, 가정, 의존성, 리스크, 리소싱이 포함되죠. 일정은 스프레드시트에 두고 참조하세요. Word의 작업 표는 분산을 계산할 수 없고, 약 30개 행을 넘으면 관리가 어려워집니다.

Google Sheets에서 무료 프로젝트 계획서 템플릿이 있나요?

네, 그리고 Google Sheets에는 여기서 Excel보다 진짜 장점이 하나 있습니다. 자동 버전 기록이 제공되어, 누군가 제자리에서 편집하더라도 기준선을 복구할 수 있다는 점입니다. 이를 메커니즘으로 쓰기보다는 안전망으로 활용하고, 어쨌든 기준선 열은 잠그세요.

PowerPoint에서 무료 프로젝트 계획서 템플릿이 있나요?

실행하는 계획서가 아니라, 발표하는 계획서에는 슬라이드를 사용하세요. 마일스톤, 외부 의존성, 핵심 경로. 300개 행짜리 작업 목록을 제시하는 것은 47번째 행을 두고 한 시간 이야기하게 만드는 신뢰할 수 있는 방법입니다.

PDF에서 무료 프로젝트 계획서 템플릿이 있나요?

승인 시점의 기준선 버전을 날짜가 포함된 상태로 내보내고, 그 파일을 보관하세요. 위의 실제 예시에서는 원래 계획서의 이메일 PDF가 기준선의 유일하게 남은 기록이었고, 이를 바탕으로 재구성하는 데 3일이 걸렸습니다.

Excel에서 프로젝트 트래커 템플릿은 어디에서 찾을 수 있나요?

트래커는 ‘중요한 행’만 필터링한 동일한 시트입니다. 즉, 핵심 경로와 외부 의존성만 남기면 되며, 대부분의 프로젝트에서는 300개가 아니라 40~60개 행입니다. 계획서를 먼저 만들고 필터로 트래커를 도출하세요. 2주 안에 서로 다른 두 파일을 유지하는 방식은 피하는 게 좋습니다.

프로젝트 트래커에는 몇 개의 행이 있어야 하나요?

실질적인 프로젝트라면 40~60개 정도입니다. 각 행의 테스트는 이것입니다. 2주 지연이 생기면 프로젝트 종료일이 바뀌거나, 프로젝트 밖의 누군가에게 알려야 하나요? 둘 다 아니라면, 그 작업은 계획서에 있어야지 주간 업데이트에 들어가면 안 됩니다. 그래야 업데이트가 90분이 아니라 20분으로 유지됩니다.

프로젝트 계획서와 일정(schedule)의 차이는 무엇인가요?

일정은 날짜와 순서입니다. 계획서는 일정에 더해, 그 일정을 의미 있게 만드는 모든 것—목표, 범위, 가정, 의존성, 리소스, 리스크—를 포함합니다. 가정이 기록되지 않은 일정은 왜 지연됐는지 설명할 수 없고, 기준선과 원인(cause) 열이 존재하는 이유가 바로 그 차이를 메우기 위해서입니다.