1. 해결할 문제

무엇을 하려는지가 아니라 무엇이 문제인지부터 적습니다. “AI 교육을 한다”가 아니라 “팀이 보고서 초안에 매주 6시간을 쓴다”처럼 현재 상태를 씁니다. 문제 문장이 구체적이면 해결 방식은 여러 개가 될 수 있고, 더 나은 방법을 중간에 선택할 수 있습니다.

2. 적용 범위

어느 팀, 어느 업무, 어느 기간까지인지 정합니다. 범위를 넓게 잡으면 시작이 늦어지고, 좁게 잡으면 빨리 확인할 수 있습니다. 범위에 포함되지 않는 것도 함께 적습니다. 포함되지 않은 항목을 적어 두는 것이 나중에 가장 도움이 됩니다.

3. 결과물

프로젝트가 끝났을 때 고객의 손에 남는 것을 목록으로 적습니다. 교육이라면 실습 결과물과 적용 과제 목록, 자동화라면 작동하는 흐름과 운영 안내서, 컨설팅이라면 진단과 실행 계획입니다. 형태와 전달 방식까지 적으면 기대가 어긋나지 않습니다.

4. 완료 조건

언제 끝나는지를 날짜가 아니라 상태로 정합니다. “검수 항목 전부 통과”, “담당자가 혼자 한 건을 처리”처럼 확인 가능한 조건이어야 합니다. 완료 조건이 없는 프로젝트는 끝나지 않거나, 어느 쪽도 만족하지 못한 채 종료됩니다.

5. 확인 방법

결과를 누가 어떻게 확인할지 정합니다. 확인하는 사람, 확인 시점, 확인 기준 세 가지입니다. 중간 확인 주기도 여기서 정합니다. 확인 방법이 정해져 있으면 중간 결과가 달라도 빠르게 조정할 수 있습니다.

다섯 줄이 적히지 않는 프로젝트는, 아직 시작할 준비가 되지 않은 프로젝트입니다.

한 장으로 남깁니다

이 문서는 계약서를 대신하지 않습니다. 다만 프로젝트 중간에 판단이 필요할 때 돌아올 기준이 됩니다. 우리는 첫 상담이 끝나면 이 다섯 줄을 정리해 고객에게 보내고, 같은 문서를 프로젝트 마지막 확인에도 사용합니다.