[실무 1부] 04. Reporting
엔지니어링 매니지먼트 업무를 하면서 가장 힘들었던 업무라면 ‘보고 (Reporting)’라고 단언할 수 있습니다. 특히 단순한 현황 보고가 아닌 문제가 발생해서 하는 보고는 그 누구에게도 반갑지 않을 것입니다. 보고란 기본적으로 상사라는 그렇지 않아도 편하지 않은 상대에게 하는 것인데 좋지 않은 일로 보고하는 것을 그 어느 누가 좋아하겠습니까?
보고는 기회입니다.
하지만 아무리 보고를 좋아하지 않더라도 누군가는 반드시 보고를 해야 합니다. 물론 그 누군가는 대부분 엔지니어링 매니지먼트일 것입니다. 이 '보고' 때문에 회사를 그만두겠다는 생각을 여러 번 할 정도였습니다. 하지만 오랫동안 업무를 하면서 깨달은 것은 보고가 불편함이 아닌 기회이기도 하다는 것입니다. 같은 내용이라도 어떤 생각으로 준비하고 또 어떻게 보고하느냐에 따라 불편하거나 피하고 싶은 일이 될 수도 있지만 반대로 프로젝트와 개인에게는 도움이 되는 좋은 기회가 되기도 한다는 것입니다.
엔지니어들이 보고하는 것을 달갑게 여기지 않는 이유를 크게 두 가지로 나누어 보면, 먼저 보고서 작성에 걸리는 시간과 과정에서의 피로감과 보고로 인해 파급될 영향에 대한 두려움 때문일 것입니다.
보고서를 작성하면서 받는 스트레스가 한몫하는 것이 사실입니다. 때로는 보고서 작성할 시간도 부족한데, 내용은 차치하고 보고서 양식이나 글자체, 그래프 모양 등에 사활을 건듯 지적해 대는 상사의 취향에 맞추어 보고서 작성과 수정을 반복하다 보면 ‘이런 일을 계속해야 하나’ 하는 자괴감에 빠질 때도 있습니다. 저 또한 이 보고 때문에 매니지먼트 업무를 그만두겠다고 한 적이 여러 번 있을 정도였습니다. 여하튼 보고서를 작성하거나 보고를 한다는 것은 누구에게나 스트레스인 것 많은 사실입니다.
또한, 보고를 받는 입장에서는 일단 문제가 발생하면 일단 그 문제를 조치하더라도, 향후 문제가 재발하지 않도록 하기 위해서는 당연히 원인 규명을 해야 하는데, 이 과정에서 원인 제공자는 물론 결재라인까지 모두 책임을 벗어날 수 없게 됩니다. 그러다 보니 보고를 하는 입장에서는 부담스러울 수밖에 없고, 어떻게든 회피하고 싶은 마음이 드는 것이 당연할 것입니다.
문제는, 엔지니어링 매니지먼트라면 누구보다도 보고 하는 일이 많다는 것입니다. 실제 매니지먼트 업무의 절반은 보고라고 해도 과언이 아닐 정도로 많은 보고서를 작성하게 됩니다. 하지만 이 업무를 언제까지 스트레스받아가며 할 수는 없을 것입니다.
앞서 설명한 대로 이왕 하는 일이라면 프로젝트는 물론 자신에게도 도움이 되는 기회가 될 수 있도록 하는 것이 좋을 텐데, 대체 어떻게 하면 그렇게 할 수 있을까요?
가장 중요한 것은 신속하고 정확한 보고입니다.
보고의 가장 기본은 사실 그대로 보고서를 작성하는 것입니다. 진도가 늦었으면 늦은 그대로, 문제가 발생하였으면 문제 그대로 보고서를 작성하는 것입니다. 어차피 본인이 해결할 수 없는 문제를 해결하기 위해 보고하는 것인데 조금이라도 숨기거나 축소할 필요 없습니다. 있는 그대로 솔직하게 보고해서 상사와 발주처의 협조를 구하는 것입니다. 어차피 상사나 발주처나 어떻게든 프로젝트를 성공적으로 이끌어야 하는 책임을 진 주체입니다. 다시 말하면 ‘나’와 함께 프로젝트를 수행하는 프로젝트 일원이기도 하지만 엔지니어보다 책임이 훨씬 큰 분들이라는 것입니다. 따라서 담당자보다 더 문제에 민감할 수밖에 없습니다. 단지 내 책임이 아니라는 이유나 혹은 순간의 질책이 두려워서 보고 좋고 듣기 좋은 보고서를 작성하는 것은 반드시 피해야 합니다.
책임 문제는 뒤에 가서 처리하면 될 것입니다. 플랜트 엔지니어링은 전문가 집단입니다. 전문가라면 자신이 잘못한 것에 대해서는 책임을 지는 것이 당연합니다. 어차피 드러날 문제를 억지로 감추거나 축소하여 보고하다 보면 문제가 해결되기는커녕 오히려 점점 커지게 되어 결국 엄청난 비용과 시간을 들여 수습하거나 아예 수습할 수 없을 정도로 어려운 지경으로 몰리게 될 수 있습니다. 이것은 정말 프로젝트를 더욱 어렵게 만드는 것뿐 아니라 엔지니어로서 자존심에도 큰 상처를 남기게 되는 것임을 반드시 명심해야 합니다. 책임지는 모습이 오히려 신뢰를 얻을 수 있습니다.
물론, 보고를 받는 매니지먼트도 사소한 것들은 넘어가고 '문제'에 집중해야 합니다. 보고자 입장에서는 문제 해결을 위해 어려움을 무릅쓰고 보고하는 것입니다. 문제의 지적이 아닌 해결이 보고의 1차 목적이며 책임 소재 규명과 질책은 그다음이라는 것을 명심해야 합니다. 또한, 질책보다는 잘한 점이나 격려 위주로 보고를 받는 문화가 함께 이루어져야 할 것입니다.
이렇게 문제에 집중해서 보고 하고 받다 보면 개인적으로는 어느 사이엔가 그토록 골치 아픈 문제가 자연스럽게 해결되고, 문제가 해결되니 골치 아픈 일이 없게 되는 선순환이 이루어지게 되고, 조직적으로는 상하 간에 신뢰가 쌓여 모두가 신나게 프로젝트를 수행할 수 있는 환경을 만들어 갈 수 있을 것입니다.
보고를 불편한 것에서 기회로 바꾸기 위해 가장 중요한 것은 보고자의 생각을 바꾸는 것입니다. 지금 내 주위를 보면 전혀 불가능한 것처럼 보일 수 있을 것입니다. 하지만 저의 오랜 경험을 통해 터득한 '비법'임을 기억하시면 좋겠습니다.
이제 실제로 정기 보고서에 들어가는 내용을 예를 들어 살펴보겠습니다.
아래 목차는 실제 해외 프로젝트에서 사용된 보고서 내용으로, 발주처에 제출하는 보고서(External Report)와 내부에 보고하는 보고서(Internal Report)로 크게 나누고 각각 들어가는 내용을 정리해 보았습니다.
Report for External (대 발주처 보고, Project 전체 내용)
- Contract
- Correspondence Status
- Progress
- HSE (LTI)
- Work done and to be done (Plan/Actual)
. Engineering/Procurement
. Construction/Commissioning
. Interface etc.
- Area of Concern
- Key Event
- Special Issue
Internal Report (엔지니어링 내부 보고)
- Progress (Discipline)
. Engineering
. Procurement
. Interface etc.
- Progress 지연/만회 대책
- 주요 Issue
- Work done and to be done (Plan/Actual)
. Engineering
. Procurement
. Interface etc.
- Area of Concern
- Key Event
발주처 특성에 따라 약간씩 다르기는 하지만 대부분 프로젝트는 보고서의 목차가 거의 비슷합니다. 물론 같은 제목이라도 발주처 보고서에는 프로젝트 전체 위주로, 내부 보고서에는 엔지니어링 위주로 작성한다는 것을 참조하시면 좋겠습니다.
한 걸음 더...
마지막으로 발주처에 제출하는 보고 업무와 관련하여 제 경험에서 얻은 한 가지 팁을 소개할까 합니다.
Report에는 반드시 다음 한 주간 또는 다음 1개월간 수행할 업무 계획이 포함됩니다. 하지만 이것과 별도로 향후 3개월간 수행할 주요 Event를 한눈에 볼 수 있도록 달력 형태로 작성해서 제공하는 것입니다. 아래 그림은 ‘3 Months look ahead plan’이라고 제목을 붙이고 매월 Update 하여 발주처에 제공한 실제 자료입니다.
이렇게 하면 발주처는 물론 프로젝트를 수행자 모두가 향후 3개월간 수행할 주요 업무를 한 눈으로 보고 알 수 있음은 물론, 자신들이 해야 할 일을 사전에 점검하고 준비할 수 있도록 도움을 주게 되어 모두에게 유익하므로 단순한 보고를 넘어 서비스가 되는 것입니다.
보고 하는 입장에서는 불편하다 보니 자연히 수동적으로 될 수밖에 없습니다. 하지만 보고를 단순히 현황이나 문제점을 보고하고 지침을 받는 수동적 입장에서 벗어나 문제점 해결을 위한 기회로 잘 활용한다면 프로젝트에 큰 도움이 될 것은 물론 본인도 매니지먼트로서 능력을 인정받는 계기가 될 것입니다.
보고가 필요하다는 것과 정확한 내용을 보고해야 한다는 것은 누구나 알고 있습니다. 하지만 어떻게 대하느냐에 따라 달라지는 것이 보고입니다. 알고 있는 것과 실제로 행하는 것은 다릅니다.
생각의 변화가 미래를 바꿀 수 있습니다.
대한민국 플랜트 산업의 부흥을 꿈꾸는 자, oksk