ARCHEHIGH
프로젝트는 일하는 시간보다기다리는 시간에 늦어집니다
일정표에는 작업만 적히지만 실제 프로젝트의 날짜는 자료, 검토, 결정과 승인을 기다리는 동안 더 많이 지나갑니다.
작업은 멈춰 있지만
프로젝트의 날짜는 계속 지나갑니다.
제작자가 구조를 정리하는 데 사흘이 필요하다고 말합니다. 일정에는 사흘이 적히지만 필요한 자료가 이틀 늦고, 내부 검토에 나흘이 걸리면 결과는 아흐레 뒤에 도착합니다.
이때 눈에 보이는 것은 제작 기간뿐입니다. 그래서 팀은 작업자를 재촉하고 세부 일정을 더 촘촘하게 만들지만, 실제 지연을 만든 대기 구간은 그대로 남습니다.
일정을 지키려면 얼마나 빨리 만들 수 있는지만 묻지 않아야 합니다. 다음 작업이 시작되기 위해 누가 무엇을 언제까지 건네야 하는지도 같은 무게로 관리해야 합니다.
프로젝트가 늦어지는 원인은 작업 속도가 아니라 다음 사람이 움직일 조건이 준비되지 않은 데 있을 때가 많습니다.
일정표에 보이지 않는 시간이
가장 관리하기 어렵습니다
작업에는 담당자와 예상 기간이 있습니다. 반면 자료를 기다리는 시간이나 여러 부서의 의견을 모으는 시간은 누구의 일정에도 분명하게 잡히지 않습니다.
다음 단계가 시작되지 못해도 모두 각자의 업무를 하고 있으므로 지연이 늦게 발견됩니다. 검토 요청을 보낸 사람은 기다리고, 검토자는 자신의 차례가 급하다는 사실을 모를 수 있습니다.
마감이 가까워지면 그동안 쌓인 대기 시간이 제작과 수정 단계에 한꺼번에 전가됩니다. 검토 시간을 줄이고 여러 작업을 동시에 진행하면서 오류 가능성도 커집니다.
대기 시간은 쉬는 시간이 아닙니다. 프로젝트의 약속을 사용하면서도 결과를 만들지 못하는 시간입니다.
일정의 길이보다
시간이 어디에서 멈추는지 봅니다
같은 22일도 실제로 움직인 열흘과 다음 조건을 기다린 열이틀로 나누면 관리할 지점이 달라집니다.
요청부터 최종 승인까지 달력에서 지나간 전체 시간
구조 설계, 제작, 수정과 확인에 실제로 사용한 시간
자료, 피드백, 결정과 승인을 기다리며 멈춘 시간
누가 어떤 형식으로 제공할지 정하지 않은 채 제작 일정부터 시작합니다.
여러 사람이 동시에 보거나 앞선 검토가 끝나야 다음 사람이 움직입니다.
수정 의견을 모아도 우선순위와 최종 선택을 내릴 사람이 없습니다.
완성된 뒤 처음 등장한 기준이 앞선 작업을 다시 돌려보냅니다.
작업을 관리하듯
작업 사이의 전달도 관리합니다
“검토 부탁드립니다”라는 요청만으로는 충분하지 않습니다. 무엇을 판단해야 하는지, 어느 수준까지 의견을 내야 하는지, 응답이 없으면 어떤 기준으로 진행할지 함께 적습니다.
한 단계가 끝난 뒤 자료를 요청하지 않습니다. 다음 작업에 필요한 입력물을 미리 확인하고 담당자와 형식을 정하면 완료와 동시에 전달할 수 있습니다.
결정이 필요한 사안은 일반 피드백과 분리합니다. 선택지, 각각의 영향과 결정 기한을 제시하면 의견을 다시 해석하는 시간이 줄어듭니다.
빠른 팀은 모든 일을 빨리 하지 않고
멈춘 일을 빨리 발견합니다
대기 시간을 완전히 없앨 수는 없습니다. 검토와 숙고가 필요한 일도 있고, 여러 부서가 함께 확인해야 하는 결정도 있습니다.
중요한 것은 기다림에 이름과 책임을 붙이는 일입니다. 지금 무엇을 기다리는지, 누구의 응답이 다음 단계를 열며, 언제 다시 확인할지 보여야 합니다.
주간 보고에서도 완료한 작업만 나열하지 않습니다. 멈춘 구간과 필요한 결정, 기한을 먼저 공유하면 일정 문제를 마감 직전이 아니라 발생한 시점에 다룰 수 있습니다.
전체 기간 안에서 실제 작업과 대기가 차지한 비율을 봅니다.
자료 전달과 검토도 담당자와 완료 조건을 가진 일정으로 다룹니다.
의견을 받을 사람과 마지막 선택을 내릴 사람을 구분합니다.
진척률보다 다음 작업을 막고 있는 조건을 공유합니다.
작업자를 재촉하기 전에,
프로젝트가 멈춘 자리를 찾습니다.
ARCHEHIGH는 작업 일정과 전달, 검토, 결정의 흐름을 함께 설계해 프로젝트의 실제 시간을 관리합니다.