검토, 최종 검토, 최최종 검토, 최최최종 검토, 최최최최종 검토...
가장 먼저 할 일은 공고문을 다시 펼쳐보는 거다.
제안서를 쓰는 동안 공고문을 수없이 봤지만, 마지막에 한 번 더 본다.
공고문에는 제안서 작성 양식과 제출 서류 목록이 명시되어 있다.
"제안서는 50페이지 이내로 작성"
"연구개발계획서, 참여연구원 명단, 기관 인증서류 첨부"
"PDF 파일로 제출, 파일명은 '과제명_기관명' 형식"
이런 요구사항들을 하나씩 체크한다.
페이지 수를 세고, 첨부파일 목록을 확인하고, 파일명이 맞는지 본다.
서류누락으로 가점을 못 받은 경험이 있다.
제안서를 쓰다 보면, 과업 계획을 수정하는 경우가 많다.
처음에는 시제품 3개를 만들기로 했다가, 나중에 2개로 줄이기도 한다.
문제는 과업 계획을 수정하고 나서, 예산을 따라 수정하지 않는 경우다.
과업에는 시제품 2개인데, 예산에는 3개 분량의 재료비가 남아 있는 거다.
심사위원들은 이런 불일치를 금방 발견한다.
"과업 계획과 예산이 안 맞는데요?"
그래서 최종 검토 단계에서 반드시 확인한다.
과업 계획을 다시 읽으면서, 예산 항목과 대조한다.
시제품 개수, 시험 횟수, 출장 계획, 장비 구매 항목.
이런 것들이 과업과 예산에서 일치하는지 하나씩 체크한다.
17화에서 다뤘듯이, 성과지표는 과업 계획을 반영해야 한다.
최종 검토 단계에서 이 연결고리를 다시 확인한다.
성과지표에 "재사용 횟수 10회 이상"이라고 썼으면, 과업 계획에 10회 이상의 시험이 계획되어 있어야 한다.
성과지표에 "SCI 논문 3편 게재"라고 썼으면, 과업 계획에 논문 작성 일정이 포함되어 있어야 한다.
성과지표를 하나씩 읽으면서, 과업 계획에서 해당하는 부분을 찾는다.
연결이 안 되는 성과지표가 있으면, 둘 중 하나를 수정한다.
예산은 숫자 작업이라서 실수가 생기기 쉽다.
최종 검토 단계에서 예산표를 펼쳐놓고 다시 계산한다.
먼저 총액을 확인한다.
정부출연금 + 민간부담금 = 총 연구비
이 합계가 공고문에 명시된 금액과 일치하는지 확인한다.
다음으로 정부출연금 비율을 확인한다.
중소기업은 75% 이내, 중견기업은 70% 이내.
공고문에 명시된 비율을 지키는지 계산한다.
비목별 합계도 확인한다.
인건비 + 연구재료비 + 연구장비·시설비 + 연구활동비 + 간접비 = 총 직접비
이 합계가 맞는지 검산한다.
한 번은 엑셀 수식 오류로 합계가 1,000천 원 차이가 났던 적이 있다.
최종 검토에서 발견해서 수정했지만, 놓쳤으면 큰 문제가 될 뻔했다.
제안서 제출 시스템(IRIS 등)에 입력하면 오류는 잡아주지만, 제안서의 내용이 틀리면 안 되기 때문에
제안서의 내용을 더 꼼꼼하게 검증한다.
참여연구원 명단을 작성할 때, 3책5공과 참여율을 확인해야 한다.
최종 검토 단계에서 참여연구원별로 다시 체크한다.
3책5공 확인:
각 연구원이 현재 수행 중인 다른 과제 수를 확인한다.
책임연구원으로 3개, 참여연구원으로 5개를 초과하지 않는지 본다.
참여율 확인:
모든 과제의 참여율을 합쳐서 100%를 넘지 않는지 확인한다.
(정부출연연구소는 130%까지 허용)
별도로 관리하는 시트로 참여연구원의 참여율을 관리하면서 다시 검증한다.
"A연구원: 책임 2개, 참여 3개, 참여율 합계 85%"
이렇게 정리하면 한눈에 확인할 수 있다.
공고문에는 제출해야 할 첨부서류 목록이 나와 있다.
사업자등록증, 재무제표, 참여연구원 이력서, 보유장비 목록, 협력의향서 등.
최종 검토 단계에서 이 목록을 보면서 하나씩 체크한다.
체크리스트를 만들어서 확인하면 실수를 줄일 수 있다.
체크하면서 파일을 하나씩 열어본다.
파일이 손상되지 않았는지, 내용이 제대로 들어가 있는지 확인한다.
특히, 가점이 될 수 있는 부분은 최대한 확보하여 제출한다.
제안서 전체를 처음부터 끝까지 다시 읽는다.
이때는 내용보다 문장을 본다.
오타가 있는지, 맞춤법이 틀렸는지, 문장이 어색한지 확인한다.
특히 표와 그림의 제목, 참고문헌, 약어 정리 같은 부분을 꼼꼼히 본다.
이런 부분은 작성하면서 놓치기 쉽다.
"그림 3.2 시제품 형상"인데, 본문에는 "그림 3.3"이라고 참조한 경우.
"참고문헌 [5]"인데, 참고문헌 목록에는 5번이 없는 경우.
이런 실수들이 심사위원에게는 '꼼꼼하지 못한 제안서'로 보인다.
오타 하나가 탈락의 이유는 아니지만, 인상을 나쁘게 만든다.
제안서를 혼자 쓰고 혼자 검토하면, 놓치는 부분이 많다.
내가 너무 익숙해져서 당연하게 여긴 부분들을 못 본다.
그래서 최종 검토 단계에서는 레드팀을 구성한다.
레드팀은 제안서를 객관적으로 검증하는 팀이다.
제안서 작성에 참여하지 않았던 사람들로 구성한다.
컨소시엄 참여기관과 함께 검토한다.
우리 회사뿐만 아니라, 컨소시엄에 참여하는 대학이나 연구소도 제안서를 검토해야 한다.
최종본을 공유하고, 각 기관의 담당자에게 검토를 요청한다.
"우리 기관 과업 부분이 정확한지 확인해 주세요"
"예산 배분이 적절한지 봐주세요"
컨소시엄 참여기관은 제안서의 이해관계자이기 때문에, 꼼꼼하게 본다.
회사 내부에서 제안서에 참여하지 않았던 사람을 투입한다.
같은 팀의 다른 사업관리자나, 다른 부서의 엔지니어에게 검토를 요청한다.
"이 제안서 처음부터 읽어보고, 이해 안 되는 부분 표시해 줘"
"기술적으로 말이 안 되는 부분 찾아줘"
제안서에 참여하지 않았던 사람은 심사위원의 시각으로 볼 수 있다.
"이 부분은 설명이 부족해서 이해가 안 돼"
"이 그림은 무슨 뜻인지 모르겠어"
이런 피드백이 나오면, 해당 부분을 보완한다.
레드팀 검토는 시간이 걸리지만, 제안서의 완성도를 크게 높인다.
제출 마감 3~4일 전에 레드팀 검토를 시작한다.
검토 결과를 반영할 시간을 확보하기 위해서다.
제안서를 최종 완성하면, PDF로 변환한다.
대부분의 공고는 PDF 제출을 요구한다.
PDF로 변환하고 나서, 다시 한번 파일을 열어본다.
변환 과정에서 문제가 생기는 경우가 있기 때문이다.
표가 깨지거나, 그림이 잘리거나, 페이지 번호가 사라지거나.
특히 수식이나 특수문자가 많으면 변환 오류가 생기기 쉽다.
PDF를 열어서 페이지를 넘기면서 확인한다.
모든 내용이 제대로 보이는지, 깨진 부분은 없는지 체크한다.
제출 시스템은 온라인이라서, 예상치 못한 오류가 발생할 수 있다.
제출 마감일 당일에는 시스템 접속이 폭주해서 느려지거나, 서버 오류가 발생하기도 한다.
파일 업로드가 중간에 끊기거나, 업로드 후 저장이 안 되거나, 시스템 점검으로 접속이 안 되는 경우도 있다.
그래서 제출은 마감 최소 하루 전까지 완료하는 걸 목표로 한다.
시스템 오류가 발생해도, 하루의 여유가 있으면 대응할 수 있다.
한 번은 마감 당일 오후 4시에 제출하려다가, 시스템 오류로 접속이 안 됐던 적이 있다.
시스템 오류로 추가로 받아주긴 했으나, 이 경험 이후로는 무조건 1일 전에는 제출을 마무리할 수 있도록 한다.
정부과제 제안서는 대부분 온라인 시스템으로 제출한다.
NTIS, IRIS 같은 시스템에 로그인해서 파일을 업로드한다.
파일을 업로드한 후, 시스템에서 제공하는 미리 보기 기능을 확인한다.
업로드 과정에서 파일이 손상될 수도 있기 때문이다.
미리 보기에서 제안서가 제대로 보이는지 확인한다.
그리고 파일명, 파일 크기, 업로드 시간을 확인한다.
공고문에 명시된 형식대로 파일명이 작성되었는지 본다.
"과제명_기관명_20260330.pdf"
이런 형식을 지켰는지 체크한다.
최종 제출 버튼을 누르기 전에, 한 번 더 확인한다.
"제출하시겠습니까?"
이 메시지가 뜨면, 잠시 멈춘다.
정말 모든 걸 확인했는지 다시 생각한다.
그리고 제출 버튼을 누른다.
제출이 완료되면, 제출 확인 메일이나 접수증을 저장한다.
나중에 제출 여부를 확인할 증거가 된다.
제출 버튼을 누르는 순간, 안도감과 함께 긴장감도 느껴진다.
'이제 제안서 평가를 준비해야 하는구나'
제안서 제출은 끝이 아니라 시작이다.
평가 단계가 남아 있고, 선정되면 과제 수행이 시작된다.
하지만 최종 검토를 철저히 했다면, 최소한 형식 미비로 탈락할 일은 없다.
내용으로 평가받을 수 있는 기회를 확보한 거다.
사업관리자에게 최종 검토는 단순한 확인 작업이 아니다.
모든 노력을 보호하고, 실수로 인한 탈락을 막는 마지막 방어선이다.