프로젝트 변경 요청 발표에서는 승인된 계획과 제안한 변경의 차이를 보여 줘야 합니다. 의사결정자에게 현재 확정된 사항, 추가 요청, 그 영향, 명확한 선택지를 제시하세요. 최신 슬라이드에 새 요구사항이 들어갔다고 해서 승인된 것은 아닙니다.
관련 담당자와 영향 분석을 확인했다면 Presenti로 변경 요청 원고를 슬라이드 초안으로 정리할 수 있습니다. 전제 조건과 승인 상태도 함께 입력하세요. 요약하면서 덜어 낼 세부 사항이 아니라 요청 자체를 이루는 정보입니다.
승인된 기준 계획부터 제시하세요
팀이 사내 예약 시스템의 시범 운영을 준비한다고 가정하겠습니다. 합의된 범위는 예약 양식, 확인 이메일, 주간 이용 현황 보고서입니다. 시범 운영 시작은 6주 차 말이고, 승인 예산은 미화 40,000달러입니다. 여기에 프로젝트 스폰서가 시범 운영 전에 싱글 사인온을 추가해 달라고 요청했습니다.
이 예시에서 쓰는 계획 수치는 모두 가상입니다. 팀의 견적은 설명을 위한 가정이며, 실제 연동 작업의 가격이나 납기를 약속하는 수치가 아닙니다.
첫 슬라이드에는 이미 확정된 내용과 새로 요청한 내용을 구분해 적습니다. 범위 옆에 기준 계획의 버전이나 승인 기록의 참조 정보를 넣어 참가자가 확인할 수 있게 하세요. 현행 계획이 이미 바뀌었다면 새 제안과 비교하기 전에 기록부터 맞춰야 합니다.
Microsoft의 프로젝트 변경 평가 안내(영어)는 요구사항, 자금, 일정에 미치는 영향과 요청을 승인할 권한을 함께 다룹니다. 발표 자료도 프로젝트의 실제 승인 규칙을 따라야 합니다. 일반적인 템플릿이 승인권자를 정해 주지는 않습니다.
새 합계뿐 아니라 얼마나 늘어나는지 보여 주세요
이 예시에서 기술 책임자는 싱글 사인온 추가에 승인 예산 외 미화 8,000달러와 현재 일정 외에 근무일 기준 10일이 필요하다고 추정했습니다. 필요한 시점에 인증 설정, 테스트 계정, 검토 인력의 시간을 확보할 수 있다는 가정입니다. 이 조건을 견적 옆에 적으세요.
| 항목 | 승인된 계획 | 변경안 | 승인될 경우 |
|---|---|---|---|
| 범위 | 예약 양식, 확인 이메일, 주간 보고서 | 싱글 사인온 추가 | 기존 범위에 연동 기능과 합의된 인수 확인 작업 추가 |
| 예산 | 미화 40,000달러 | 추가 견적 미화 8,000달러 | 예상 합계 미화 48,000달러 |
| 시범 운영 시작 | 6주 차 말 | 근무일 기준 10일 연장 예상 | 예시의 주 5일 일정에서는 8주 차 말. 공휴일이나 자원 배정 충돌이 없다고 가정 |
| 선행 조건 | 현재 시범 운영의 전제 조건 | 인증 설정, 테스트 계정, 연동 검토 | 선행 조건이 지연되면 견적 재검토 필요 |
추가 금액은 8,000 ÷ 40,000으로, 원래 예산의 20%입니다. 이 비율은 판단 자료이지 자동 승인 규칙이 아닙니다. 또한 작업량이 10일이라고 해서 시작이 반드시 10일 늦어지는 것도 아닙니다. 여기서는 추가 작업이 시작까지의 일정 경로를 늘린다고 명시적으로 가정했습니다. 실제 계획에서는 일정 영향을 뒷받침하는 의존 관계와 가용 인력을 보여 주세요.
팀이 작업 기간과 미확정 선행 조건만 제시했다면 정확한 시작 날짜가 정해진 것처럼 쓰지 마세요. 실제 날짜가 필요하면 일정 담당자와 프로젝트의 근무일 달력을 기준으로 계산합니다.
실제로 승인할 수 있는 선택지를 제시하세요
“수락 또는 거절”만 제시하면 유용한 중간 대안이 가려질 수 있습니다. 이 요청에서는 다음 세 가지를 같은 기준으로 비교합니다.
| 선택지 | 바뀌는 점 | 주요 영향 | 확인할 사항 |
|---|---|---|---|
| 시작 전에 연동 기능 추가 | 현재 산출물을 모두 유지하고 싱글 사인온 추가 | 예상 합계 미화 48,000달러, 근무일 기준 10일 연장 | 선행 조건, 검토 인력의 가용 시간, 변경 승인 |
| 현행 시범 운영을 유지하고 이후 연동 검토 | 승인된 시범 운영 범위를 유지하고 별도 후속 릴리스 검토 | 기준 계획의 시작일을 계속 계획 기준으로 사용 | 기존 접근 방식이 계속 허용되는지, 이후 연동이 추가 작업을 만드는지 |
| 시범 운영 범위 안에서 일부 작업 교체 | 다른 산출물의 대체 또는 연기 검토 | 비용과 일정 영향은 아직 미산정 | 옮길 수 있는 산출물, 관련 의존 관계, 수정 견적 |
세 번째 선택지가 자동으로 “같은 예산, 같은 일정”이 되는 것은 아닙니다. 보고서를 없앤다고 그 담당자나 시간을 연동 작업으로 옮길 수 있다는 보장은 없습니다. 견적이 없는 선택지는 미산정으로 표시하고, 여전히 유력하다면 영향 분석을 요청하세요.
두 번째 선택지에도 조건이 필요합니다. 새 요구사항이 시범 운영을 위한 필수 조건이라면 나중으로 미룰 수 없을 수 있습니다. 편리하지만 쓸 수 없는 대안을 표에 남기지 말고, 그 제약을 드러내야 합니다.
변경 요청을 설명하는 슬라이드 6장 구성
- 요청하는 결정. 변경 내용, 권고안, 결정이 필요한 기한을 밝힙니다.
- 현재 확정된 사항. 승인 범위, 예산, 주요 일정을 기준 계획의 참조 정보와 함께 보여 줍니다.
- 요청 이유. 누가 변경을 필요로 하는지, 미루면 어떤 일이 생기는지 설명합니다. 필수 요건과 선호 사항을 구분합니다.
- 영향. 추가 비용, 일정, 작업, 의존 관계를 보여 줍니다. 각 견적의 책임 담당자를 명시합니다.
- 대안. 실행 가능한 선택지와 각각의 미해결 질문을 비교합니다.
- 결정 기록. 실제 결정, 조건, 결정자, 날짜를 기록할 칸을 명확히 남깁니다.
기술 설계의 세부 사항과 견적 내역은 부록에 넣습니다. 본문만으로도 승인자가 모든 작업을 들여다보지 않고 영향을 이해할 수 있어야 합니다. 새 요구사항을 기존 작업 속에 숨긴 일반 로드맵보다 변경 전후의 범위를 나란히 보여 주는 방식이 더 명확할 때가 많습니다.
회의 중 불확실성과 새 정보를 다루세요
회의 중 선행 조건이 바뀌면 권고안의 어느 부분에 영향을 주는지 표시합니다. 예를 들어 테스트 계정이 준비되지 않으면 10일 연장이라는 견적이 더는 유효하지 않을 수 있습니다. 오래된 수치를 고집하지 말고 갱신된 견적이 필요하다고 기록하세요.
조건부 결정도 구체적으로 적어야 합니다. “기술 책임자가 견적을 확인하고 스폰서가 추가 예산을 승인하면 진행한다”와 “승인됨”은 다릅니다. 두 상태를 모두 초록색으로 표시하거나 마지막 슬라이드에서 조건을 없애지 마세요.
회의 후에는 논의한 요청 버전을 보관하고 결정 기록을 그 버전과 연결합니다. 실행 계획은 프로젝트에서 합의한 변경 절차에 따라 갱신하세요. 발표 자료를 고친 것만으로는 팀이 어떤 범위, 날짜, 예산을 공식 기준으로 삼아야 하는지 알 수 없습니다.
승인 여부를 분명히 남기는 원고로 초안을 만드세요
검토한 원고를 Presenti에 붙여 넣어 편집 가능한 슬라이드 초안으로 정리합니다. 기준 계획, 견적, 가정을 원본 텍스트에 포함하세요. “변경 요청”이라는 주제만 입력하면 판단 근거가 되는 정보가 너무 많이 빠집니다.
가상의 사내 예약 시스템 시범 운영에 대한 변경 요청 발표 자료 6장을 만들어 주세요. 승인 범위는 예약 양식, 확인 이메일, 주간 이용 현황 보고서입니다. 승인 예산은 미화 40,000달러이고 시작 계획은 6주 차 말입니다. 추가 요청은 시범 운영 전 싱글 사인온 도입입니다. 기술 책임자의 견적은 추가 비용 미화 8,000달러와 시작까지의 경로를 늘리는 근무일 기준 10일이며, 인증 설정, 테스트 계정, 검토 인력의 시간이 준비된다는 가정입니다. 이 예시에 한해서만 공휴일 없는 주 5일 근무를 사용하세요. 지금 추가하는 안, 현행 시범 운영을 유지하고 후속 릴리스를 검토하는 안, 새 견적을 전제로 일부 작업을 교체하는 안을 비교하세요. 견적이 없는 교체안에 비용이나 날짜를 부여하지 마세요. 필수 요건, 가정, 승인 조건을 명시하세요. 실제 결정과 승인자 칸은 비워 두고 승인을 만들어 내지 마세요.
생성된 초안에서는 미묘하게 달라진 의미를 확인하세요. “추정”이 “확정”으로, 조건부 선택지가 약속으로, 빈 결정란이 승인으로 바뀌지 않았는지 살펴봅니다. 이런 확인은 테마를 고르는 일보다 중요합니다. 완성된 자료는 원래 확정된 사항을 지키면서 변경 요청을 판단하기 쉽게 해야 합니다.
