프로그램 관리
프로그램은 팀 내부가 아니라 팀 간의 이음새에서 실패합니다. 그 임무는 바로 그 이음새입니다.
설정
- 하나의 결과물, 비즈니스 결과로 명시되고 날짜 포함 — 동등한 목표가 여러 개인 프로그램은 사실상 목표가 없는 것입니다.
- 지명된 책임 소유자 — 위원회가 아닌 한 사람. 프로그램 매니저는 추진하고, 소유자는 결정합니다.
- 범위는 포함 사항과 제외 사항으로 작성 — 제외 사항이 실제 작업을 정의합니다. 문서화되지 않은 제외 사항은 가정으로 돌아옵니다.
- 의존성은 이를 제공해야 하는 팀이 매핑하고 합의하며, 실제로 약속한 날짜 포함. 계획에 포함된 의존성이 제공 팀이 동의하지 않은 것이라면 그것은 희망사항일 뿐입니다.
일정 수립
팀 편의가 아니라 의존성과 리스크에 따라 순서를 정하세요. 계획을 무효화할 수 있는 것들(기술적 미지수, 벤더 결정, 승인이 안 될 수도 있는 사항)을 앞당기세요. 4개월 차에 계획이 불가능했음을 발견하는 것이 전형적인 프로그램 실패입니다.
통합 지점에 여유를 두고, 마지막에 몰아넣지 마세요. 마지막에 쌓인 버퍼는 일찍 그리고 조용히 소진됩니다.
읽을 가치가 있는 상태 보고
매번 세 가지만: 약속된 날짜에 맞춰 진행 중인지, 지난번 이후 무엇이 변경되었는지, 어떤 결정이나 차단 해제가 필요한지. 나머지는 부록입니다.
약속된 날짜에 대해 상태를 추적하고, 노력이 아닌 결과를 기준으로 하세요. "80% 완료"는 정보가 아닙니다. "통합 완료, 마이그레이션 월요일 시작, 서명이 리스크"가 정보입니다.
조기에 그리고 구체적으로 에스컬레이션하세요. 필요한 결정과 필요한 날짜를 명시한 에스컬레이션은 해결됩니다. 막연한 우려 표명은 인정받고 아무 일도 일어나지 않습니다.
지연될 때
범위 문제인지, 용량 문제인지, 의존성 문제인지 파악하세요 — 해결책은 완전히 다르며 잘못된 것을 적용하면 상황이 더 악화됩니다.
그런 다음 결과와 함께 옵션을 제시하세요: 범위 축소(무엇을), 기간 연장(얼마나, 무엇에 영향을 미치는지), 또는 용량 추가(후반에는 거의 도움이 안 되며 오히려 해가 될 수 있음).
일주일씩 미루지 말고 한 번, 가시적으로 기준을 다시 설정하세요. 연속적인 작은 지연은 한 번의 정직한 재설정보다 훨씬 빠르게 신뢰를 파괴합니다.
절대 하지 말아야 할 것
- 해결되지 않은 차단기가 있는 프로그램을 녹색으로 보고하지 마십시오.
- 제공 팀이 확인하지 않은 의존성 날짜를 수락하지 마십시오.
- 지연된 프로그램에 사람을 추가하고 가속화될 것이라고 가정하지 마십시오.