Joypia

9. 본문 작성 하기​드디어 마지막이다. 제안서 본문 작성 요령을 살펴 보는 것으로 제안서 잘쓰기는 끝마친다.우선 본격적인 본문 작성에 앞서 제안 시나리오를 그려야 한다. 요구사항과 평가항목을 고려하고, 어떤 내용 강조할 것이며, 그에 대한 근거는 무엇인가 등 제안 작성에 대한 나름대로 설계안을 마련하는 것이다.​ ​이 제안 시나리오를 갖고 1차 검토를 한다. 검토 시에는 제안 PM, PO, 작성자, 전략 기획자등은 필히 참석해야 한다. 이후 그 시나리오를 바탕으로 본격적인 작성에 들어간다. 이런 시나리오는 별도로 작성하는 것이 아니라, 지금 작성하는 PPT 장표 여백등을 활용하는 것이 좋다. 이 부분은 앞서 얘기한 것 처럼 마지막까지 지우지 않는다.​1) 페이지 설정은 사용자 정의(21 X 29.7)로..

※ 3번 연재로 끝날 줄 알았는데, 쓰다보니 마지막 장이라 생각한 부분이 의외로 길어졌다. 부득이 기존 제목을 수정하였다. ㅠㅠ 8. 본문 작성 준비작업 제안서 잘쓰기 마지막으로 실제 내용 작성시 필요한 Tip을 알아보자. 다음과 같은 규칙을 미리 정하여 템플릿을 만들어 배포하도록 하자. 상세하게 표준을 정할수록 가이드하기에도 쉽고 제안서 품질을 통제하기도 용이하다. 여기에 설명되는 내용의 대전제는 '가독성'이다. 가독성있게 작성함으로써 심사위원이 읽기 쉽고 눈에 띄게 하는 것이 목적되시겠다. 1) 본문은 너무 복잡하지 않게 여백을 확보하여 작성 기억하는가. 2% 차이가 명품을 만드다고 하지 않았던가. 모든 장표가 안정적이고 세련되게 보이는 가장 기본은 문서 도는 도형 내에 텍스트가 있다면 상하좌우 여백..

4. 제안계획 세우기 당연한 얘기지만 제안작업도 계획이 필요하다. 짧게는 2주 이지만 길게는 몇 개월씩 걸리는 것도 있다. 보통 1.5개월에서 2개월 정도 소요된다. 제안 계획 내용은 다음과 같은 내용이 포함되며, 결정권자가 파악하는데 도움이 되도록 작성해야한다. ​ - 개요 개요는 보통 RFP 내용 중 사업관련 정보(사업명, 규모, 사업유형, 평가, 발주처 정보, 제안진행 일정)를 기본으로 기술하고, 추가자료로 경쟁사 현황, 사업여건, 고려사항, 현재까지 진행 현황 등을 기술하도록 하자 - RFP 분석 RFP 분석은 평가항목을 중심으로 분석을 하면 된다. 만약 해당 발주처의 다른 제안요청서와 평가 배점이 다르다면 그 부분도 주지할 필요가 있겠다. 또한 상세 평가항목에도 추가되거나 제외된 부분이 있다면 ..

공공 SI 제안서 잘쓰기에 대해서 말하고자 한다. 이거슨 순전히 그간 경험에서 나오는 지극히 개인적인 생각임을 전제로 한다. 2편에서는 제안서 작성 요령에 대해서 살펴 볼 것인데, 그 부분은 조금 개관적이지 싶다. ​ 1. 제안서를 잘 쓰기 위한 여건이 필요하다. 주변 환경이 좋을 수록 좋은 제안서가 나온다. ​ 제안서 작성을 돕는 전문 조직(보통 제안지원 성격으로 팀명을 정한다)이 있어야한다. SI를 주 업으로 삼고 있고, 하도급으로만 일하지 않고 직접 입찰에 참가하여 주사업자로 프로젝트를 수행한다면 제안이 그 첫걸음이다. 이는 영업보다 앞선다고 감히 말할 수 있겠다. 영업하는 인력이 없더라도 제안에 참여는 할 수 있지 않는가. ​ 가장 기본적인 제안조직은 이렇다. 팀장 1명, 기획 및 전략 1명, 진..

공공기관 SI 프로젝을 하다보면 신경 쓰이는 일이 몇몇 있다. 그 중 하나가 각종 보고시 발표하는 거다. 경험상 착수보고는 거의 하는 편이고, 그 외 중간보고와 완료보고가 있다. 사실 프로젝이 잘 진행 될수록 보고회를 갖는 경향이 있다. 그러니 발표가 꺼려 지거나 하기 싫다면 프로젝을 개판 치면 된다. ^^~ 이 발표회가 신경 쓰이는 이유는 보고를 받는 대상 때문이다. 보통 임원급이 참석하는데 금액이 크고 중요한 것은 아무래도 기관장이 참석하게 된다. 그러면 수행사도 그에 맞는 사람이 참석하게 되는데 보통 고객보다 한 지위 높은 사람이 참석하는 것이 좋다. 높은 분이 참석할수록 고객 담당자나 수행팅이나 모두 긴장할 수밖에 없다. 고객은 자기 상사만 신경 쓰겠지만 수행팀은 자사 임원까지 신경 쓰는 보통 귀..

공공 SI 에서 가장 어려운 프로젝은 전에 없던 것을 구축하는 신규 프로젝이다. 경험이나 선례가 없어 고객도 모르고, PM 도 모르고, PMO도 모르고, 감리도 모르고, 전문가도 없다. 멍청하게도 이런 프로젝에서 고객이 결정해 주길 바란다면 실패한다. 고객의 입장에서도 이런 PM 이 들어왔다면 당장 교체를 요구해야 한다. ​이 경우 다음과 같이 진행함으로써 반드시 고객을 리딩해야 한다. 1. PM 과 PL은 관련 법규, 정책, 기술, 동향 등을 졸라 공부해야 한다. 공공 기관은 해당 법령에 의해서 업무가 발생한다. 따라서 다른 조직과는 다르게 꼭 관련 법규를 서베이할 필요가 있다. 해당 업무 프로세스나 비즈니스 로직을 수립할 때 관련 기술이나 동향을 살펴 볼 필요가 있다. 가끔은 이미 해당 기술이 나와 ..

머 거창(?)하게 제목을 붙였지만 어디까지나 개인적인 생각이다. 공공SI를 하기 위해 계약과 관련된 문서 중 가장 비중이 큰 세 개가 있다. 보통 RFP 라고 하는 제안요청서, 이 걸 보고 밤새워 업체에서 만드는 제안서, 그리고 수주하게 되면 10일 이내 만들어 내는 사업수행계획서가 그 것이다. 이들의 의미를 생각해보자. 확실한 근거를 찾기 위해 여기 저기 뒤져야하지만 매우 귀찮은 관계로, 그냥 내가 이제껏 들어 왔거나,혹은 어디서 봤거나, 아무튼 내가 인지하고 있는 것으로 설명해 보겠다. 우선 제안요청서부터 살펴보자. 제안요청서가 만들어지려면 먼저 사업계획서가 만들어 져야 한다. 그래야 내부적으로 결재도 받고, 예산도 받고 할 수 있다. 이 거 만들 때, 요즘은 공공기관이나 정부부처 담당자가 직접 만드..

난 SI 프로젝트에서 고객보다 반 보(요즘은 한 보 앞서가는 건 거의 불가능하다) 정도만 앞서가길 원한다. 매번 프로젝트가 시작되면 PM 이나 PL 들에게 요구하는 첫 번째 사항이다. '고객보다 반보 앞서 가라.' 1. 이는 고객이 얘기하기 전에 먼저 선수를 치라는 얘기다. 고객이 무엇을 궁금해 하는지 미리 파악하여 준비를 하고 일정을 통보하는 것이다. 물론 고객이 전혀 생각 안할 수도 있다. 이 경우에도 고객에게 신뢰를 심어 준다. 2. 고객이 요구하는 것 보다 조금 더 확대된 서비스를 제공하는 것을 뜻한다 고객이 두 가지 안을 보자고 하면 3가지 방안을 만들어서 보여주어야 한다. 기능이나 범위를 확대하아는 얘기가 아님을 명심하자. 3. 미리 일어날 수 있는 문제를 예고할 수 있는 것을 뜻한다. 미리 ..

단일 시스템 구축의 프로젝트가 아니라 여러 개의 단위 시스템을 구축하고 그것들 간에 연계가 이루어지는 과업이 있다면, 각 시스템간 연계 부분을 정의하고 설계를 하겠지만 반드시 전체적인 관점에서 정리할 필요가 있다. 보통 연계를 정의하고 식별하기 위해서는 다음과 같은 산출물들이 생성된다. - 인터페이스 정의서 - 인터페이스 명세서 - 인터페이스 구성도 각 시스템별로 자기 입장에서 연계 부분에 대해 정의 및 명세화를 하고 나면 공통 업무로 전체를 통합하여 작성할 필요가 있다. 이 때 혹시나 서로 연계에 대한 정의를 다르게 기술하거나 누락된 것이 있는지 점검할 수 있게 된다. 통상 인터페이스 정의는 다음과 같은 항목을 정의한다. 1. 송신 항목 - 송신 시스템명 - 프로세스명(프로세스 ID 포함) - 프로그램..

차를 몰고 가다보면 가끔 '사고다발구간'이라는 표지판을 볼 때가 있다. 그 구간 또는 지역을 하나하나 살펴보면 별 문제가 없는 것처럼 보인다. 아마도 그 구간의 도로 여건, 신호체계, 교통량 등 여러 가지 주변 특성으로 인해 사고가 다른데 보다 빈번하게 일어나는 게 아닌가 싶다. 마찬가지로 SI 프로젝트에도 '사고다발 프로젝트'가 존재하는 것이 아닌가 하는 생각이 든다. 정리한 것은 없지만 괘 경험이 있는 PM 이나 개발자들은 나름대로 사고다발의 조건을 알고 있을 것 같다. 물론 도로의 사정과 교통체계 등 여러 가지가 변하듯이, 프로젝트도 환경이 변함에 따라 그 조건도 변하고 있는 것 같다. 뻔히 보이는 위험이 있는 경우가 아니라 별개로 보면 문제가 없는데 사고가 발생하는 프로젝트의 경우 또는 조건을 정..