웹디맨의 웹기획론 웹디맨의 웹기획론

처음 제안서를 쓰게 되었을때 어려움을 접하게되는점이 많은것 같다. 많은 제안 작업 중에서 처음 제안서쓰게 되었을때가 가장 기억에 남는데 그때 썼던 제안서를 아직도 보곤 한다. 잊지 않기 위해서인지 아니면 수중한 기억때문인건지... 이거랑 똑같이 쓰면 되니까 걱정 말라던 선임의 말을 믿고 출발했던 제안작업이 수포로 돌아갈때 그렇게 아무렇지 않게 얘기 했던 선임의 호통이 떠오른다. 뭘 잘못 한건지도 모르고 그걸 가르쳐주는사람도 없었으니까.. 나혼자 해결해야만 했었다. 절치부심하고 두번째 제안땐 정말 죽을힘을 다했던거 같다. 시간도 촉박했고 양도 많았다. 이런 저런 컨셉 잡는데만도 하루가 지나갔고 목적있는 제안을 위해서 여러가지 방법의 서브제안들을 만들어갔다. 그리고 하나로 합치고 다시 읽어 보고 다시 수정하..

사이트 분석(착수 후) 초기 사이트의 분석이 끝나면 제안요청서와 제안서 기술협상에서 발생한 추가사항과 변경사항에대한 분석을 해야 한다. 사이즈 체크뿐 아니라 기능에대한 분석을 해야한다 리스크 발생요인을 체크하고 히스토리관리도 해야한다. 전체 사이트의 분석은 이정도의 수순으로 요구사항 분석 단계로 넘어간다. 이때도 작업 범위에서 벗어 나지 않도록 이해당사자들과의 협의가 중요하다. 상세한 분석과 히스토리관리 리스크 관리가 있어야 협의 시점에서 유리하게 이끌어 갈수 있다. Posted by 김상환

SLA(service level agreement) 적용 요즘 공공기관의 RFP에서 자주보는 단어가 SLA다. 언제부터인지 SLA로 사업의 성공여부를 따지는듯 하다. SLA를 높게 잡으면 그만큼 사업의 범위가 커질 수밖에 없다. 가능한 SLA범위를 잡는것이 중요하며 이범위는 사업의 전체 성공여부까지 결정할 수 있다. 솔찍히 SLA가 있어 검수단계가 깔끔해지는 경우도 있다. SLA보고만 지나면 검수는 당연한결과이기 때문이다. 다만 기준치에 못미쳤을때의 대비가 가장 중요하다. 일별, 주별, 월별 기준치 체크를 하여 못미쳤을때의 대비방안도 마련하여 SLA의 기준치를 넘어서야 한다. (예시 : 월별 SLA보고를 통하여 전반적인 서비스의 진척도를 나타낼 수 있다) 예를 들면 유지보수의 프로젝트에서 회원가입수와 P..

제안작업을 하다보면 기본을 지키지못하는경우가 있다. 제안서의 기본은 제안요청서에 있다. 제안요청서의 분석뒤에 제안서의 러프한 방향을 잡고 제안의 컨셉을 정한다. 뒤에 목차와 업무분장을 나눠 세부 장표를 도출한다. 뒤에 모든 장표를 확인하고 손을 봐야한다. 그리고 이 제안의 핵심을 클라이언트를 통해 습득하고 그에대한 장표가 돋보이도록 포장 그리고 추가제안을 하는것이다. 기본은 지켜야한다. 본전부터 시작해야 승산이 있다.제안요청서를 분석하는 방법에는 다음의 방법이 있다. SWOT 분석 기회의 요인과 위협의 요인을 장점과 약점으로 나누어 분석함으로써 제안요청서의 내용과 제안 수주의 확율을 확인할 수 있다. 요구목표 분석 제안요청서에는 이번 사업의 목표가 있다. 이런 목표에 부합되는 제안서가 나와야 한다. 업무..