프로젝트 킥오프 발표를 마치면 팀이 범위의 경계, 각자의 책임, 첫 점검 시점을 공유하고 있어야 합니다. 다음 작업에 영향을 주는 선택을 결정하는 데 회의를 쓰세요. 프로젝트 계획 전체를 읽어 주는 시간이 되어서는 안 됩니다. 배경 설명이 긴 슬라이드보다 간결한 안건과 눈으로 확인할 수 있는 결정 기록이 더 유용합니다.
가상의 사내 신청 포털 프로젝트를 예로 들어 보겠습니다. 첫 출시에서는 직원이 장비와 출장 신청을 제출하고, 승인자가 승인하거나 반려할 수 있도록 합니다. 킥오프에서 정할 것은 접근 권한 신청도 이번 출시에 포함할지 여부입니다.
아래 안건과 범위 표로 Presenti에서 텍스트를 킥오프 슬라이드 초안으로 만들 수 있습니다. 생성 전에 실제 프로젝트 정보를 넣고, 회의에서 정한 내용은 슬라이드나 팀의 결정 기록에 남기세요.
프로젝트에 맞게 조정할 수 있는 30분 킥오프 안건
회의 전에 짧은 프로젝트 개요와 안건을 함께 보냅니다. 참석자는 어떤 결정에 의견이 필요한지, 무엇이 배경 자료인지 알아야 합니다. 미해결 쟁점에 15분이 걸릴 것으로 예상한다면 소개 시간 뒤에 끼워 넣지 말고 그만큼의 시간을 확보하세요.
| 시간 | 논의 | 남길 결과 |
|---|---|---|
| 00:00–04:00 | 프로젝트를 하는 이유와 대상 | 합의한 하나의 프로젝트 목적 |
| 04:00–12:00 | 첫 출시 범위와 접근 권한 신청의 포함 여부 | 포함·제외·미결 항목 기록 |
| 12:00–18:00 | 책임과 결정 권한 | 실행, 인수, 미해결 선행 과제의 담당자 |
| 18:00–25:00 | 첫 점검 시점과 선행 조건 | 산출물, 인수 기준, 목표 날짜 |
| 25:00–30:00 | 결정 내용을 다시 읽고 다음 행동 확인 | 결정 기록과 다음 회의 날짜 |
예시 시간표일 뿐 모든 프로젝트에 적용하는 규칙은 아닙니다. 여러 회사가 참여하는 킥오프라면 계약, 보안, 기술 설계를 위한 별도 실무 회의가 필요할 수 있습니다. 킥오프를 모든 목적을 위한 워크숍으로 늘리기보다 각각의 회의를 명확히 구분하세요.
범위 선택을 눈에 보이게 정리하기
“신청 포털 구축”만으로는 해석할 여지가 너무 큽니다. 출시 범위를 슬라이드에 적고, 미해결 선택은 별도 행에 표시합니다. 가상의 팀은 다음 정보에서 출발합니다.
| 항목 | 초기 입장 | 결정할 내용 |
|---|---|---|
| 장비 신청 | 첫 출시 포함 | 필수 입력 항목과 승인 역할 |
| 출장 신청 | 첫 출시 포함 | 재무팀으로 승인 절차를 넘기는 방식 |
| 접근 권한 신청 | 미결 | 수동 승인을 포함할지, 계정 관리 연동을 파악할 때까지 미룰지 |
| 자동 권한 부여 | 첫 출시 제외 | 이번 킥오프에서 구현을 약속하지 않음 |
프로젝트 스폰서는 인수할 팀과 연동 작업이 정해지지 않았기 때문에 접근 권한 신청을 미루기로 합니다. 선택과 이유를 함께 기록하세요. “접근 권한 신청은 첫 출시에서 제외하며, IT팀이 다음 범위 검토 전에 작업을 추산한다.” 나중에 슬라이드에서 “보류”를 “곧 제공”으로 바꾸지 마세요.
조직도 대신 세 가지 책임 질문에 답하기
누가 작업을 이끌고, 누가 결과를 인수하며, 누가 범위를 바꿀 수 있는지 정합니다. 이 예시에서는 실행 책임자가 개발을 조율하고, 운영 관리자가 기준에 따라 시범 적용을 인수하며, 스폰서가 새로운 신청 유형을 출시 범위에 넣을지 결정합니다. 재무 담당자는 출장 승인 규칙을 제공하지만, 그 때문에 자동으로 프로젝트 책임자가 되지는 않습니다.
RACI를 사용한다면 약어 옆에 실제 행동도 적으세요. “최종 책임: 스폰서”보다 “스폰서가 첫 출시 범위의 변경을 승인한다”가 더 명확합니다. 선행 작업에는 요청을 보내는 사람뿐 아니라 받는 쪽의 담당자도 적습니다.
PMI의 프로젝트 시작 회의 가이드는 목표, 범위에 포함하거나 제외할 항목, 전략, 위험, 가정, 작업 책임을 다룹니다. 킥오프 자료는 이 주제들을 논의에 올려놓는 도구이며, 프로젝트 승인이나 상세 계획을 대신하지 않습니다.
첫 점검에서 무엇을 확인할지 정하기
이 팀의 첫 점검은 “프로토타입 완성”이 아니라 장비 신청 흐름의 테스트입니다. 시범 참여 직원이 신청을 제출하고, 승인자가 사유를 적어 반려하며, 직원이 결과를 찾아볼 수 있어야 합니다. 운영 관리자는 테스트를 관찰하고 소규모 시범 적용을 시작할 준비가 됐는지 판단합니다.
날짜 옆에 선행 조건을 적으세요. 재무팀은 승인 규칙을 제공하고 IT팀은 테스트 계정을 준비해야 합니다. 하나라도 늦어지면 테스트 시간을 몰래 줄이지 말고 점검 계획을 다시 검토합니다. 이후 단계도 같은 방식으로 산출물과 인수 기준을 함께 제시하세요. 점검 일정을 확정하기 전에 업무 처리 역량 계획 발표 자료로 필요한 작업량과 팀이 실제로 투입할 수 있는 시간을 함께 비교할 수 있습니다.
회의를 마치기 전에 결정 기록 다시 읽기
발표자는 다음 기록을 회의 중에 채우고 확인하며 마무리할 수 있습니다.
결정: 첫 출시에는 장비 신청과 출장 신청을 포함한다. 제외: 접근 권한 신청과 자동 권한 부여. 이유: 접근 권한 신청의 담당자와 연동 작업이 미정이다. 다음 행동: IT팀이 다음 범위 검토를 위해 접근 권한 신청 작업을 추산한다. 첫 점검: 장비 신청 한 건을 제출하고, 반려하고, 결과를 확인한다. 인수 책임자: 운영 관리자. 선행 조건: 테스트 계정과 재무팀의 승인 규칙. 다음 검토: [날짜 및 회의 담당자].
회의 뒤에는 슬라이드와 기록을 함께 공유합니다. 새로 합류한 팀원도 합의된 범위와 논의 중 나온 아이디어를 구분할 수 있어야 합니다. 변경이 생기면 이전 기록을 지우지 말고 이유와 담당자를 붙여 결정을 갱신하세요.
안건, 범위 표, 첫 점검을 바탕으로 Presenti에서 킥오프 자료를 만들어 보세요. 유용한 자료는 회의 때 보기 좋았던 자료가 아니라, 처음 범위에 관한 질문이 나왔을 때 팀이 다시 참고할 수 있는 자료입니다.
