프로젝트의 진짜 성과는 완료보고서 다음에 시작된다

새 시스템이 열린 지 두 달 뒤, 현업에는 일이 하나 늘었다.

직원들은 시스템에 내용을 입력한 뒤 같은 내용을 엑셀 장부에도 적었다. 관리자는 시스템이 만든 보고서보다 익숙한 예전 양식을 요구했다. 줄어들 줄 알았던 일은 그대로였고, 입력할 곳만 하나 더 생겼다.

프로젝트 완료보고서에는 초록색 표시가 가득했다. 일정을 지켰고 예산도 넘지 않았다. 요구한 기능은 모두 만들었고 사용자 교육도 끝났다. 프로젝트 팀은 성공을 선언하고 해산했다.

보고서에는 성공이 남았다. 현장에는 일이 하나 더 남았다.

만든 것과 달라진 것은 다르다

시스템을 만든 것은 프로젝트의 결과다. 그 시스템을 써서 중복 입력이 사라진 것은 회사에 생긴 변화다.

설비를 설치한 것과 불량률이 줄어든 것도 다르다. 교육을 끝낸 것과 직원의 행동이 바뀐 것도 다르다. 하나는 프로젝트 팀이 만든 것이고, 다른 하나는 현업이 실제로 달라진 것이다.

여기에는 두 개의 시계가 있다.

첫 번째 시계는 시스템을 여는 날 멈춘다. 날짜, 예산, 기능을 확인한다. 두 번째 시계는 그날부터 움직인다. 사람들이 실제로 쓰는지, 일이 줄었는지, 실수와 비용이 낮아졌는지를 본다.

회사는 첫 번째 시계만 보고 성공을 선언하기 쉽다. 하지만 오픈일은 현장의 변화가 끝난 날이 아니다. 변화를 확인하기 시작할 날이다.

그렇다고 일정과 예산이 중요하지 않다는 뜻은 아니다.

Zhiwen Zheng과 Ofer Zwikael은 미국 프로젝트 198건과 세계은행 프로젝트 154건을 살폈다.[1] 일정·비용·품질을 잘 관리한 프로젝트가 장기적인 성과를 낼 가능성도 높았다. 특히 결과물의 품질이 낮으면 좋은 성과를 기대하기 어려웠다.

그러나 날짜와 비용을 지켰다고 장기적인 성과가 저절로 생기지는 않았다. 좋은 결과물은 필요하지만, 사용자가 예전 방식을 버리지 않으면 중복 입력은 남는다. 관리자가 새 보고서를 신뢰하지 않으면 예전 양식도 남는다.

완료율 100%가 변화율 100%를 뜻하지는 않는다.

프로젝트가 끝나면 팀은 해산한다. 외부 업체는 계약을 마치고 빠져나간다. 현업은 시스템을 넘겨받고, 정보기술 부서는 장애를 처리한다.

그런데 중복 입력이 줄었는지는 누가 확인할까. 사용률이 낮을 때 누가 업무 절차를 바꿀까. 예상한 효과가 나오지 않으면 누가 원인을 다시 찾을까.

각자의 일은 있지만 이 질문을 맡은 사람은 없을 수 있다. 이 글에서는 이 상태를 책임의 빈칸이라고 부르려 한다. 프로젝트 팀의 책임은 끝났지만, 약속한 변화를 확인할 다음 책임은 시작되지 않은 상태다.

2024년 공공 프로젝트 연구도 결과물을 만드는 사람과 약속한 변화를 확인하는 사람의 역할이 다르다고 본다.[2] 역할을 나눠 놓는 것만으로는 부족했다. 앞사람의 책임이 끝날 때 뒤사람의 책임이 분명하게 시작돼야 했다.

많은 프로젝트에서 현업은 마지막에 등장한다. 사용자 교육을 받고, 인수확인서에 서명하고, 운영 매뉴얼을 넘겨받는다.

하지만 현업은 시스템의 문제가 가장 먼저 드러나는 곳이다. 화면의 순서가 실제 일과 맞지 않는지, 새 절차가 고객 응대를 느려지게 하는지, 예외적인 상황을 처리할 수 있는지는 직접 써 봐야 알 수 있다.

Tom Olsson과 동료들은 핀란드 방위군의 네 개 프로젝트를 살폈다.[3] 개발 중인 결과물을 실제 사용 환경에서 시험하고, 현장의 반응을 다시 프로젝트에 반영하는 것이 장기적인 성과에 중요했다.

이 연구는 장기간 진행된 방위 프로젝트에 관한 사례다. 짧은 민간 프로젝트에 그대로 적용할 수는 없다. 그래도 현업을 마지막 인수자로만 보면 문제를 발견할 기회가 늦어진다는 점은 유용하다.

현업은 완성품을 받는 마지막 사람이 아니다. 개발 중에 직접 써 보고, 문제를 찾고, 수정을 요구해야 하는 사람이다.

완료보고서에는 무엇을 만들었는지가 자세하게 남는다. 하지만 그 결과로 무엇이 달라져야 하는지, 그 변화를 누가 확인할지는 비어 있기 쉽다.

그 빈칸에는 긴 계획서보다 한 줄이 먼저 필요하다.

변화 인수자: 영업관리팀장 / 확인일: 오픈 60일 후 / 확인할 변화: 중복 입력 시간 50% 감소

수치와 날짜는 프로젝트에 맞게 달라질 수 있다. 중요한 것은 완료 시점에 변화 인수를 분명히 하는 일이다. 시스템이나 설비만 넘기지 말고, 약속한 변화와 그것을 확인할 책임까지 넘겨야 한다.

프로젝트 팀은 오픈일에 일을 마칠 수 있다. 회사의 변화는 그날부터 시작된다.

프로젝트의 종료일은 변화 책임자의 첫 근무일이다.

Zheng, Z., & Zwikael, O. (2025). From Outputs to Outcomes: Meeting a Threshold of Short-Term Project Management Success as a Necessary Condition for Achieving Long-Term Impact. International Journal of Project Management, 43(8), 102789. https://doi.org/10.1016/j.ijproman.2025.102789
Sun, N., Ning, Y., & Li, Y. (2024). Tackling Tensions Between Project Owner and Project Manager in Benefits Realization of Public Projects: A Paradox Perspective. IEEE Transactions on Engineering Management. https://doi.org/10.1109/TEM.2024.3454165
Olsson, T., Artto, K., Hauhia, A., & Kivinen, S. (2024). When Project Outcomes Matter: Organizational Integration in Managing Long-Term Target Benefits. International Journal of Project Management, 42(8), 102648. https://doi.org/10.1016/j.ijproman.2024.102648