시스템 - 업무에 맞춘다는 것 — 과제 유형을 나누는 일부터입니다

현장의 질문들 - 4

양식이 하나뿐이면

연구소에서 계획서 양식을 열어보면 대체로 하나입니다. 목표, 일정, 투입 인력, 예산, 단계별 산출물, 성공 기준.

그리고 그 양식에 모든 과제가 들어갑니다. 될지 안 될지 모르는 탐색 과제도, 이미 하던 것을 개선하는 과제도, 3개월짜리도 3년짜리도요.

관리하는 입장에서는 통일하는 것이 편합니다. 비교도 되고, 집계도 되고, 보고 자료도 한 번에 만들어집니다.

그런데 이 방식은 반드시 한쪽을 거짓말하게 만듭니다.

예전에 업무 유형을 나눠야 한다는 이야기를 한 적이 있습니다. 오늘은 그 다음 이야기입니다. 무엇을 기준으로 나누고, 나눈 다음에 무엇이 달라져야 하는지에 대해서요.

표준 양식은 어디서 왔습니까

먼저 왜 양식이 하나로 통일되는지부터 보겠습니다.

표준 패키지 제품은 거래(Transaction) 처리를 전제로 설계되었습니다. 구매, 회계, 재고, 급여. 이 영역은 처리 규칙이 밖에 정해져 있습니다. 회계 기준이 있고 세법이 있으니 무엇이 맞는지가 명확하고, 어느 회사든 처리 방식이 크게 다르지 않습니다.

그래서 하나의 표준 양식이 성립합니다. 그리고 그건 좋은 일입니다. 검증된 방식을 그대로 쓰면 되니까요.

문제는 그 발상이 프로젝트 관리로 넘어올 때 생깁니다.

프로젝트에는 정답이 없습니다. 무엇을 개발할지, 어디까지 검토할지, 언제 접을지에 정해진 규칙이 없습니다. 그리고 회사마다 다릅니다.

과제의 성격이 다릅니다. 신약을 하는 회사와 제네릭을 하는 회사가 같을 수 없고, 소재 개발과 공정 개선이 같을 수 없습니다.

중요하게 보는 관리점이 다릅니다. 어떤 회사는 규제 대응이 핵심이고, 어떤 회사는 원가가 핵심이고, 어떤 회사는 고객사 요구 대응이 핵심입니다.

의사결정 문화가 다릅니다. 소장이 대부분 결정하는 회사와 위원회를 거치는 회사는 계획서에 담겨야 할 것이 다릅니다. 승인 단계가 다르고, 무엇을 근거로 올려야 하는지도 다릅니다.

이 세 가지를 무시하고 표준 양식을 넣으면 어떻게 됩니까. 그 회사가 실제로 일하는 방식과 어긋납니다. 그리고 사람들은 두 가지를 하게 됩니다. 양식은 양식대로 채우고, 일은 원래 하던 대로 합니다.

그래서 시스템을 업무에 맞춥니다

저희가 계속 이야기해 온 것이 이것입니다.

패키지는 업무를 시스템에 맞춥니다. 거래 처리 영역에서는 그게 맞습니다. 우리 회사 회계를 특별하게 할 이유가 없으니까요.

프로젝트 관리는 반대여야 합니다. 시스템을 업무에 맞춥니다. 그 회사의 과제 성격, 그 회사가 중요하게 보는 관리점, 그 회사의 의사결정 방식에 맞춰 관리 체계를 설계합니다.

그리고 그 첫 단추가 과제를 유형으로 나누는 일입니다. 우리 회사에 어떤 성격의 과제가 있는지 구분하는 것에서 시작해야, 유형마다 무엇을 어떻게 관리할지가 나옵니다.

통일된 양식이 만드는 일

구체적으로 무슨 일이 벌어지는지 보겠습니다.

양식을 하나로 통일하면 그 양식은 결국 가장 복잡한 과제를 기준으로 만들어집니다. 빠지는 것이 있으면 안 되니까요.

그러면 두 방향으로 문제가 생깁니다.

작은 과제를 하는 사람은 빈 칸을 채웁니다. 세 명이 3개월 하는 일에 단계별 산출물과 위험 대응 계획과 자원 배분 계획을 쓰라고 하면 형식적으로 채웁니다. 그리고 그렇게 채운 것은 아무도 안 봅니다.

불확실한 과제를 하는 사람은 지킬 생각 없는 계획을 씁니다. 이게 더 심각합니다.

탐색 과제는 이번 실험 결과에 따라 다음 단계가 달라집니다. 그런데 12개월치 일정을 월 단위로 그리라고 하면 그럴듯하게 그립니다. 그리고 매달 그 일정을 수정하는 데 시간을 씁니다.

그리고 이 상태가 몇 년 지나면 다들 압니다. 계획서는 통과시키기 위해 쓰는 문서가 되고, 실제 일은 그것과 별개로 돌아갑니다.

무엇을 기준으로 프로젝트 유형을 나눕니까

그럼 어떻게 나눠야 하는가. 축을 세 가지로 보고 있습니다.

첫째 축 — Research형인가 Development형인가

가장 중요한 축입니다.

Development형 과제는 절차가 대체로 정해져 있고 반복적으로 수행됩니다. 제네릭 개발이 전형적입니다. 무엇을 만들지가 정해져 있고, 어떤 단계를 거치는지도 이미 알고 있습니다. 기존 제품의 성능을 개선하거나 공정 수율을 올리는 과제도 여기 가깝습니다.

Research형 과제는 불확실성이 높습니다. 신약 개발이 전형적입니다. 될지 안 될지 모르고, 이번 결과에 따라 다음 방향이 달라집니다.

미리 짚어둘 것이 있습니다. 이 둘은 흑백으로 갈리지 않습니다. 실제 과제는 대부분 그 사이 어딘가에 있습니다. 그래서 "어느 쪽인가"가 아니라 "어느 쪽에 가까운가"로 보시면 됩니다.

이 축이 두 가지를 결정합니다.

하나, 계획의 성격이 다릅니다.

Development형은 계획이 약속에 가깝습니다. 언제까지 이걸 하겠다는 것이고, 그 약속을 지켰는지가 평가 기준이 됩니다.

Research형은 계획이 가설에 가깝습니다. 지금 아는 것으로는 이 방향이 맞아 보이니 여기까지 가보겠다는 것이고, 가다가 아니면 바꾸는 것이 정상입니다.

그래서 Research형에 Development형의 관리 방식을 적용하면 안 됩니다. 계획 대비 실적을 따지는 순간, 담당자는 지킬 수 있는 계획만 세우게 됩니다. 그리고 지킬 수 있는 계획은 도전이 없는 계획입니다.

둘, 실패의 의미가 다릅니다.

연구에서 실패는 지식입니다. 이 경로로는 안 된다는 것을 알아낸 것이고, 그게 결과물입니다. 다음 사람이 그 길을 안 가도 되니까요.

개발에서 실패는 손실입니다. 되는 줄 알고 시작했는데 안 됐으니 들어간 자원이 회수되지 않습니다.

이 차이는 실패를 기록하는 방식으로 이어져야 합니다.

Research형 과제는 실패한 것도 상세히 남아야 합니다. 어떤 조건으로 시도했고 어디서 막혔는지가 다음 사람에게 그대로 가치가 됩니다. 그런데 지금 대부분의 종료 보고서는 짧고 건조합니다. 실패로 기록될 것을 자세히 쓰는 사람이 없기 때문입니다.

Development형 과제는 원인 분석이 중요합니다. 판단이 틀렸는지, 실행이 부족했는지, 조건이 바뀌었는지.

같은 실패인데 남겨야 할 것이 다릅니다.

둘째 축 — 수행 주체와 확보 방식

목표가 정해졌을 때 그것을 어떻게 확보할 것인가입니다.

내부 수행, 위탁(Outsourcing), 공동연구, 기술 도입(License In), 지분 투자, 인수(M&A). 이 중 무엇이냐에 따라 관리 대상이 완전히 달라집니다.

내부 수행이면 일정과 인력과 결과물을 관리합니다.

위탁이면 관리 대상이 상대 기관입니다. 진행 상황을 어떻게 확인할지, 중간 산출물을 언제 받을지, 품질을 어떻게 검증할지. 그리고 계약 조건이 그대로 관리 항목이 됩니다.

공동연구는 여기에 지식재산권 배분과 상대 기관 일정과의 정합이 더해집니다.

기술 도입이면 관리 대상이 계약과 권리입니다. 사용 범위, 기간, 개량 기술의 귀속, 로열티 산정 방식.

지분 투자나 인수는 실사와 통합 관리가 중심이 됩니다.

이것들을 같은 양식에 넣는 것은 애초에 불가능합니다. 그런데 실제로는 "연구 과제"라는 이름으로 한 목록에 들어가 있는 경우가 많습니다. 그리고 위탁 과제 담당자가 자기와 상관없는 칸을 비워둡니다.

셋째 축 — 규모와 복잡도

인원수만 보는 축이 아닙니다. 관리 수준을 결정하는 요소가 넷 있습니다.

참여 인원. 세 명인가 서른 명인가.

기간. 3개월인가 3년인가. 기간이 길수록 중간에 조건이 바뀔 확률이 높고, 그러면 재검토 지점이 필요합니다.

투입 예산. 금액이 커지면 집행 관리의 정밀도가 달라집니다. 그리고 승인 단계도 늘어납니다.

관여하는 조직의 수. 이게 의외로 결정적입니다. 한 팀에서 끝나는 과제와, 세 부서에 외부 기관까지 얽힌 과제는 인원이 같아도 관리 난이도가 전혀 다릅니다. 조정해야 할 일정이 늘고, 정보가 새는 지점이 늘고, 책임 소재가 흐려집니다.

관리 항목의 개수는 이 넷을 함께 보고 정해야 합니다.

작은 과제에 관리 항목 서른 개를 요구하면 관리하는 시간이 일하는 시간을 잡아먹습니다. 큰 과제에 다섯 개만 두면 어디서 문제가 생기는지 아무도 모릅니다.

판단 기준을 하나 드리면 이렇습니다. 관리에 쓰는 시간이 전체의 몇 퍼센트인가. 정해진 답은 없지만 담당자에게 물어보면 대체로 감이 나옵니다. 그 비율이 과제 규모와 무관하게 같다면, 작은 과제 쪽이 과하게 관리되고 있는 것입니다.

다만 단서가 하나 붙습니다. 인원이 적어도 복잡도가 높으면 관리 항목이 필요합니다. 두 명이 하는 과제라도 외부 기관 세 곳과 얽혀 있으면, 그 관계를 챙기는 항목은 있어야 합니다.

유형마다 정할 것은 정성적인 것입니다

여기서 실무적으로 중요한 구분을 하나 하겠습니다. 유형별로 정하는 일이 부담스러워 보일 수 있는데, 실제로 사람이 정해야 하는 것은 생각보다 적습니다.

정성적인 것은 사람이 정합니다.

이 유형의 과제는 무엇을 목표로 하는가. 무엇이 되면 성공이고 무엇이면 실패인가. 어느 시점에 계속할지 판단하며, 그때 무엇을 근거로 보는가. 각 단계에서 무엇을 확인해야 하는가. 어떤 판단이 어디서 일어나는가.

이건 회사의 사정과 그 분야의 특성을 아는 사람만 정할 수 있습니다.

정량적인 것은 대부분 자동으로 나옵니다.

진척률, 경과 기간, 예산 집행률, 지연 여부, 남은 일정. 이건 사람이 매번 입력할 필요가 없습니다. 계획이 유형별 양식에서 나왔으면 비교할 기준이 이미 있기 때문입니다.

이 단계는 보통 3주 걸리는데 5주째다. 이 확인 항목이 비어 있는데 다음 단계로 넘어갔다. 이 서류의 기한이 다음 주다. 전부 계산으로 나옵니다.

유형을 나누는 일이 관리 부담을 늘리는 것처럼 보이는데, 실제로는 줄이는 쪽입니다.

유형을 구분하면 무엇이 달라집니까

유형을 나누는 것 자체가 목적이 아닙니다. 나눈 다음에 실제로 달라지는 것이 있어야 합니다.

계획의 단위가 달라집니다.

Development형 과제는 일정을 잘게 나눌 수 있습니다. 언제 무엇을 하는지가 그려지니까요.

Research형 과제는 그렇게 못 합니다. 대신 판단 시점을 잡습니다. 이 실험이 끝나면 결과를 보고 계속할지 정한다, 그 시점에 무엇을 기준으로 판단한다. 일정이 아니라 의사결정 지점으로 계획을 세우는 것입니다.

앞선 글에서 다룬 전제 이야기가 여기 붙습니다. 판단 시점마다 그때 무엇을 근거로 정할지가 미리 적혀 있으면, 나중에 그 판단이 기록으로 남습니다.

관리 항목의 개수가 달라집니다. 유형별로 필수 항목과 선택 항목을 나눕니다. 모든 과제가 채워야 하는 것은 최소한으로 두고, 나머지는 유형에 따라 붙입니다.

실패를 다루는 방식이 달라집니다. Research형 과제의 실패는 결과물이고, 그렇게 취급되어야 자세히 기록됩니다.

평가 기준이 달라집니다. 이게 가장 중요할 수 있습니다. 계획 대비 달성률로 모든 과제를 평가하면 Research형 과제는 구조적으로 불리합니다. 그러면 아무도 안 하려 합니다. Research형 과제는 무엇을 알아냈는가로 평가되어야 합니다. 접었더라도 접을 근거를 제때 확보했다면 그건 잘한 일입니다.

처음부터 완벽하게 나눌 필요는 없습니다

여기서 흔한 함정이 하나 있습니다. 유형을 너무 잘게 나누는 것입니다.

세 개 축을 조합하면 이론적으로 여러 갈래가 나옵니다. 그런데 그렇게 만들면 어느 유형인지 고르는 것부터 일이 됩니다. 그리고 유형마다 양식이 다르면 관리하는 쪽도 감당이 안 됩니다.

우리 회사에서 실제로 구분되는 만큼만 나누면 됩니다. 몇 개가 적정한지는 회사마다 다릅니다.

그리고 처음에 완벽하게 정하지 않아도 됩니다. 안 맞는 과제가 나오면 그때 유형을 추가하거나 조정합니다. 앞선 글에서 이야기한 대로, 관리 방식은 바뀌는 것이 정상입니다.

유형이 달라도 같은 것이 있습니다

한 가지를 짚고 마치겠습니다.

유형마다 절차가 다르고 관리 항목이 다릅니다. 그런데 유형과 무관하게 남아야 하는 것이 있습니다.

왜 이 과제를 하기로 했는가. 어떤 대안이 있었고 왜 그것이 아니었는가. 무엇을 전제로 계획했는가. 진행 중에 무엇을 확인했고 무엇을 판단했는가.

왜 이 일을 해야 합니까

마지막으로 이 작업이 무엇을 바꾸는지 정리하겠습니다.

연구 시간이 늘어납니다. 쓸데없는 칸을 안 채우고, 지킬 수 없는 계획을 매달 수정하지 않고, 자기 과제와 상관없는 항목을 비워두느라 신경 쓰지 않습니다. 관리에 들어가던 시간이 줄면 그만큼 연구에 쓸 시간이 늘어납니다.

시스템이 정착됩니다. 이게 더 중요할 수 있습니다.

자기 일에 맞지 않는 양식을 채우라고 하면 사람들은 형식적으로 채웁니다. 형식적으로 채운 데이터는 아무도 안 보고, 아무도 안 보는 데이터는 곧 채워지지 않습니다. 앞선 글에서 이야기한 정착 실패가 여기서도 그대로 반복됩니다.

반대로 자기 과제에 맞는 양식이면 채울 이유가 생깁니다. 그 항목이 실제로 자기 일에 필요한 것이니까요.

정리하면

표준 패키지의 단일 양식은 거래 처리에서 온 발상입니다. 그 영역에서는 맞지만, 프로젝트 관리는 과제 성격도 관리점도 의사결정 문화도 회사마다 달라서 그대로 적용되지 않습니다.

하나의 양식으로 모든 과제를 관리하면 반드시 한쪽이 거짓말을 합니다. 작은 과제는 빈 칸을 채우고, 불확실한 과제는 지킬 생각 없는 계획을 씁니다.

나누는 축은 세 가지입니다. Research형인가 Development형인가, 어떤 방식으로 확보하는가, 규모와 복잡도는 어떤가.

유형별로 정할 것은 정성적인 것입니다. 정량적인 것은 계산으로 나옵니다. 그리고 정성적인 것도 유형당 한 번 정하면 됩니다.

나눈 다음에는 계획 단위와 관리 항목과 실패 처리와 평가 기준이 달라져야 합니다.

다음 글에서는 그 관리 항목을 실제로 어디까지 둘 것인가를 다루겠습니다. 일정과 비용과 인력을 각각 어느 수준으로 관리할지에 대해서요.