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 개발업체 인력운영의 가장 큰 특징은 수행조직을 철저히 분업화하여 운영하는 것이다. 따라서 PM 및 사업관리를 제외하고는 다른 팀원들은 전체 프로젝트 기간에 투입되지 않는다. 아마도 인건비 절약이 가장 큰 이익조건이 되기 때문일 것이다. 우선 PL 및 상당한 기간의 유경험자(중급 개발자 이상)가 설계를 하고 설계에 대한 승인이 나면, 단순 코딩을 하는 일반 개발자들이 투입된다. 좀 더 규모가 크거나 예산이 풍부할 경우 또는 예산이 풍부하고 갑, 을 모두 프로젝트 성공에대한 열망이 대단한 경우 테스트 전담인력을 마지막에 투입한다. SI 업체의 경영적인 측면에서는 보기 좋을지 모르겠지만, 수행팀 입장에서는 생각보다 프로젝트가 쉽게 진행되지 못한다. 원인이나 고려해야할 사항이 여러가지가 있겠지만 여기..

다음 일반적인 공공프로젝트 수행시 체크하고 준비해야할 PM의 업무체크 리스트이다. 이외 필요한 부분을 추가 및 수정하여 원할한 사업관리가 되도록 한다. - 착수시 1. 과업내용서 작성(요즘은 작성하지 않는 경우가 더 많아지고 있다) 2. 사업수행계획서 작성 3. 착수계 작성(공문, 용역책임자계, 보안각서), 산출내역서(FP산정), 주요의사결정자 인적정보 4. 착수보고 일시 협의, 참석자, 보고서 제본, 다과(사전 발주처 담당자에게 반드시 문의 필요) 및 필기도구, 빔포인터, 착수보고 장소 5. 착수보고 후 식사 여부 확인 6. (식사를 할 경우)식사 장소 섭외(반드시 발주처 담당자와 비용 처리를 협의) 7. 작업장 파악: 책상 및 의자 등 집기류, 회의실, 프린트, 복사기, 팩스, 랜선 및 전원, 기타 ..

잘 알다시피 SI 는 맞춤복이다. 기성복과는 구매자의 요구가 사뭇 다르다. 아, 이 비유는 잘 못되었다. SI는 매우 큰 저택을 짓는 대공사다. 특히 설계와 공법은 최신 트렌드를 따르고 설비는 온갖 첨단 기술이 들어가는, 그런 저택을 짓는 것이다. 아파트에 들어가서 사는 것과는 사뭇 다르다. 이 표현이 어울린다. 해서 집주인(고객)은 저택이 완성되어 갈수록 욕심이 생긴다. 이는 처음엔 집에 대해 잘 모르다가, 시간이 지나면서 조금 이해를 하게되고 어떤 것이 가능한 지 느낌이 오기 때문이다. 따라서 만족감이 오히려 완료단계에 와서 떨어질 수가 있다. 비유를 든 것이니 SI 프로젝트에서도 마찬가지라는 이야기다. 이런 갈등이 PM의 스트레스 지수를 높이고 수행사의 자원 추가와 일정 지연을 초래한다. 이에 대한..

많은 SI 회사들이 민수와 관수 또는 공공과 사기업으로 구분 짓는데는 상당한 일리가 있다. 특징이 뚜렷이 구분된다고 생각하기 때문이다. 고객, 이른바 '갑'이 나타내는 특징은 사실 공공분야가 일반기업 분야도 포함하고 있다고 생각한다. 즉 공공 특징의 일부만 사기업이 갖고 있다고 보는 견해다. 왜냐하면 나의 경우 7 대 3 정도로 공공과 일반을 경험했지만 사기업에서만의 별다른 특징을 찾지 못했다. 모든 분야가 그렇겠지만 이 분야의 일도 경험(여기서 경험은 갑을 대하는 경험을 말한다)이 쌓일수록 베테랑이 되어가고 그만큼 미래예측이나 대처 능력이 높아진다.이는 갑의 사고방식, 행동, 일처리 순서 등에 대한 일반적인 특징을 갖고 있기 때문이다. 우리는 그것 중에 아주 심한 경우를 "갑질"이라고 표현한다. 자 공..

PM 이 사업관리 하는 것 중에 가장 모호한 것이 위험과 이슈다. 도대체 이것의 기준이 무엇인가 헷갈리기 일쑤다. 지금까지 만나본 수 많은 감리들 조차 이 두가지를 구분하는 감리인을 만나보지 못했다. 그래서 어떤 경우에는 각각 관리 대장을 따로 만드는 것이 아니라 아예 '위험/이슈 관리 대장'이라고 하나로 작성하는 경우도 있다. 나는 이것을 이렇게 이해하고 있다. 물론 나 나름의 생각이라 정답이라고 할 수 는 없다. 위험은 프로젝트가 시작되기 전에 이미 식별된 것들이다. 이슈는 사전에 인지되지 못한 즉 프로젝트 수행 도중에 예상치 못한 리스크가 발생한 경우를 말한다. 문제는 이 얘기를 하려는 것이 아니라 앞서 얘기한 위험 관리에 대해 말하고자 한다. 내 생각에 따르면 위험은 미리 예견된 리스크라고 했다...

CHAOS Report 2015 자료를 보면 조금 흥미로운 내용이 있다. 5년 전이나 지금이나 프로젝트 성공율이 비슷하 것도 놀랍기는 하지만 이것 보다는 관심이 가는 3가지 통계치가 있다. 우선 프로젝트 규모별 성공율이다. 표에서 보면 규모가 클수록 성공율이 굉장히 낮아짐을 알 수 있다. 내 경험이나 언듯 생각해 보면 작은 프로젝트든 큰 프로젝트든 성공율에 큰 차이가 없어야 한다. 큰 프로젝트 일수록 공통팀이나 PMO 등 부가적인 조직과 지원이 많이 붙기 때문에 프로젝트의 품질도 그만큼 올라간다고 생각했다. 수치를 보고 가만히 생각하니 조금은 착각을 했다는 걸 깨달았다. 2~3 년 전부터 공공기관 정보시스템의 차세대 프로젝트가 시작되고 있다. 작게는 300억대에서 크게는 2,000억대 규모이다. 들리는 ..

5. 이음새를 넣자 공공SI 제안설명은 여러 가지 개별적인 단위 과제가 사업범위로 되어 있는 것이 대부분이어서 설명을 하다 보면 자칫 하나하나 끊어지기 싶다. 왜 그런지 일반적인 PT 순서를 살펴보자. - (프롤로그) : 제안에 앞서 - 제안 개요 : 제안배경 및 목적, 제안범위 등 - 제안 전략 : 사업성공요소, VOC, 제안 전략 등 - 사업수행 방안 : 각 개발 내용 또는 단위 과제 설명 - 사업지원 방안 : 조직, 방법론, 일정, 지원 사항 등 - (에필로그) : 제안을 마치며 요즘 트렌드 중에 하나는 위순서 중 전략 부분에 대해 세부 실행전략이나 ActionItem 내용으로 '사업수행방안'을 풀어가는 방법을 많이 쓰고 있다. 다른 분야의 PT는 한 가지 주제를 갖고 소위 "기.승.전.결"로 풀어..