Where Projects Become Outcomes

"프로젝트를 성과로 전환하다"

IT 인사이트 92

RFP에서 계약까지, 문서는 이어져야 한다 (08/08)

발주자를 위한 RFP 가이드 · Ep.08RFP의 문장은계약서에서 다시 만난다.RFP에서 계약까지, 문서는 이어져야 한다 · HFC Consulting계약 검토 회의에서 누군가 물었다. "이 조항은 어디서 왔습니까." 아무도 답하지 못했다. RFP에는 있었는데 계약서에서 사라진 요구가 있었고, RFP에 없었는데 계약서에 나타난 조항이 있었다. 문서와 문서 사이에서 사업의 조건이 조용히 바뀌어 있었다.연재의 마지막 화는 추적성에 관한 이야기다. RFP에서 계약까지, 문장이 끊기지 않고 도착하게 하는 방법. 마지막 도구는 표 한 장이다. RFP의 요구 번호가 계약서의 조항과 만날 때까지 문장의 생존을 관리하는 표.문서의 족보가 끊기는 세 지점발주의 문서는 넷이다. RFP, 제안서, 기술협상 결과, 계약서. ..

검수기준은 계약이 아니라 RFP에서 태어난다 (07/08)

발주자를 위한 RFP 가이드 · Ep.07끝났다는 말의 뜻을아무도 합의하지 않았다.검수기준은 계약이 아니라 RFP에서 태어난다 · HFC Consulting"끝났습니다." 수급인 PM이 말했다. 발주 담당자가 물었다. "무엇이 끝났다는 뜻입니까." 짧은 침묵이 흘렀다. 두 사람은 열여덟 달을 같은 프로젝트에서 일했지만, 끝의 정의를 합의한 적은 한 번도 없었다.이번 화는 검수기준을 어디서, 언제 정의하는가에 대한 이야기다. 답은 검수 단계가 아니다. RFP다. 완료의 정의가 늦게 태어날수록 검수는 시끄러워지고, 일찍 태어날수록 조용해진다.완료의 정의는 상속된다검수기준의 족보를 따라가 보면 이렇다. 계약서의 검수 조항은 제안서의 약속을 근거로 쓰이고, 제안서의 약속은 RFP의 요구를 근거로 쓰인다. RFP..

제안 평가 기준: 점수표가 사업의 방향을 정한다 (06/08)

발주자를 위한 RFP 가이드 · Ep.06제안서는 화려했다.점수표가 그것만 물었기 때문이다.제안 평가 기준: 점수표가 사업의 방향을 정한다 · HFC Consulting제안 발표회의 시연은 완벽했다. 질문 하나에 화면이 그려지고, 보고서가 생성되었다. 평가위원들의 점수가 올라갔다. 여섯 달 뒤, 그 시연을 만든 팀은 프로젝트에 없었다. 시연과 수행은 다른 물건이었다.이번 화는 제안서 평가 기준을 설계하는 법이다. 점수표는 채점 도구가 아니다. 입찰자에게 보내는 첫 번째 메시지다. 배점의 골격은 규정이 정하지만 질문의 내용은 발주자가 정한다. 그 질문의 설계가 주제다.점수표는 예언서다제안사는 점수표를 역산해서 제안서를 쓴다. 평가 항목이 "AI 역량"이면 제안서에는 AI라는 단어가 늘어나고, 평가 항목이 ..

AI 활용 조건, RFP에 먼저 쓴다 (05/08)

발주자를 위한 RFP 가이드 · Ep.05계약 테이블에서 처음 나온 질문은이미 늦은 질문이다.AI 활용 조건, RFP에 먼저 쓴다 · HFC Consulting우선협상 대상자와의 첫 회의였다. 발주 담당자가 물었다. "개발에 생성형 AI를 씁니까." 제안사 PM이 되물었다. "제안요청서에는 관련 조건이 없었습니다만." 둘 다 맞는 말이었다. 그래서 문제였다.이번 화는 AI 활용 조건을 계약이 아니라 RFP 단계에서 요구하는 방법이다. 도구와 데이터와 권리, 세 조건이 공고문에 먼저 실려야 하는 이유와 실을 때 쓸 문구를 다룬다.협상에서 처음 꺼내면 늦는 세 가지 이유첫째, 가격에 반영되지 않는다. 데이터 반출 금지, 승인 도구 한정 같은 조건은 수급인의 원가에 영향을 준다. 낙찰 후에 꺼내면 조건은 "추..

AI 생산성 시대의 예산과 사업기간 책정 (04/08)

발주자를 위한 RFP 가이드 · Ep.04AI로 싸졌다는데,왜 예산은 그대로입니까.AI 생산성 시대의 예산과 사업기간 책정 · HFC Consulting예산 심의 자리에서 나온 질문이었다. "AI로 개발 생산성이 몇 배가 됐다면서요. 그러면 이 사업 예산은 왜 작년 기준 그대로입니까." 발주 담당자는 답을 준비하지 못했다. 질문은 정당하다. 답이 없는 것이 문제다.이번 화는 소프트웨어사업 대가산정과 사업기간을 책정하는 근거, 그리고 그 근거가 AI 시대에 어떻게 갈라지는지를 다룬다. 예산을 지키는 무기는 항변이 아니라 산정 근거이고, 근거는 문서로만 존재한다는 것이 결론이다.M/M라는 오래된 자투입공수(M/M) 기반 산정은 하나의 전제 위에 서 있다. 사람이 들인 시간이 만들어진 가치의 대리 지표라는 전..

요구사항은 어디까지 쓰고 어디부터 맡기나 (03/08)

발주자를 위한 RFP 가이드 · Ep.03다 쓸 수는 없었다.그래서 다 쓴 척을 했다.요구사항은 어디까지 쓰고 어디부터 맡기나 · HFC Consulting요구사항정의서는 팔백 줄이었다. 발주 담당자에게 물었다. 이 중 확정된 요구가 몇 줄입니까. 대답까지 시간이 걸렸다. "절반쯤 될 겁니다." 나머지 사백 줄도 확정과 같은 문장으로 적혀 있었다.이번 화는 확정하지 못한 요구를 다루는 법이다. 요구사항(RFP 요구정의) 전체를 상세화하라는 이야기가 아니다. 그 반대다. 확정할 수 없는 것을 확정된 문장으로 쓰는 관행이 만드는 비용을 계산하고, 그보다 싼 대안을 제시한다.다 쓴 척의 비용미확정 요구를 확정처럼 쓰면 무슨 일이 벌어지는가. 입찰자는 팔백 줄을 전부 확정으로 읽고, 가장 값싼 해석으로 견적을 ..

과업범위: "등"이라는 한 글자의 대가 (02/08)

발주자를 위한 RFP 가이드 · Ep.02범위는 두 페이지였다.분쟁은 여섯 달이었다.과업범위: "등"이라는 한 글자의 대가 · HFC Consulting제안요청서의 과업범위는 두 페이지였다. "주문관리 고도화 등 관련 기능 일체." 문장은 짧았고, 그 짧음이 여섯 달의 분쟁이 되었다. 과업범위는 RFP에서 가장 많이 읽히고 가장 적게 다듬어지는 문단이다.이번 화는 범위를 쓰는 법, 정확히는 범위의 바깥을 쓰는 법이다.열린 단어는 보험이 아니다발주 담당자가 "등"을 쓰는 심정은 이해할 수 있다. 빠뜨린 것이 있을까 봐, 나중에 필요한 것을 요구할 근거를 남기려고 쓴다. 보험이라고 생각한다. 그러나 입찰자의 눈에 열린 단어는 다르게 읽힌다. 원가를 계산할 수 없는 항목이다.계산할 수 없는 원가 앞에서 제안사..

RFP는 프로젝트의 첫 산출물이다 (01/08)

발주자를 위한 RFP 가이드 · Ep.01그 분쟁의 원본은계약서가 아니라 RFP였다.RFP는 프로젝트의 첫 산출물이다 · HFC Consulting제안요청서(RFP)는 발주자가 만드는 첫 산출물이다. 그런데 많은 조직에서 RFP는 산출물이 아니라 통과 의례로 취급된다. 지난해 문서를 복사하고, 과업 내용에 "등"을 붙이고, 조달 일정에 맞춰 공고한다.그 대가는 반드시 늦게, 더 비싸게 돌아온다. 검수 회의에서, 협상 테이블에서, 때로는 법정에서.모든 분쟁에는 원본 문서가 있다검수를 앞둔 회의실의 풍경은 대개 비슷하다. 발주 담당자가 화면을 가리킨다. "이 기능은 왜 없습니까." 수급인 PM이 제안서를 편다. "제안 범위에 없던 항목입니다." 발주자가 RFP를 편다. "여기 있지 않습니까. 통계 분석 기능..

테일러링 결과서 작성 실무 - 판정을 문서로 남기는 법 (08/08)

AI 시대의 방법론 테일러링 · Ep.08 · 완결자른 이유를 적지 않으면자른 것이 아니라 빠뜨린 것이다.테일러링 결과서 작성 실무 · HFC Consulting감리 현장. 감리원이 산출물 목록과 실물을 대조하다가 물었다. "프로그램명세서가 없습니다." PM이 답했다. "코드 자동 문서화로 대체했습니다." 감리원이 다시 물었다. "그 결정은 어디에 기록되어 있습니까." 같은 대체라도, 결과서에 판정과 근거가 남아 있는 사업은 개선 권고로 끝나고, 없는 사업은 산출물 미비로 지적된다. 차이는 실물이 아니라 문서 한 장이다.완결편이다. 일곱 편의 판정을 감리와 검수 앞에서 통하는 문서로 바꾸는 법 — 테일러링 결과서를 다룬다.존재 이유 — 무단 생략과 테일러링을 가르는 문서테일러링 결과서는 산출물에 대한 산..

데이터와 모델 산출물 - 신설 산출물 2 (07/08)

AI 시대의 방법론 테일러링 · Ep.07코드에는 버전이 있었다.데이터에는 없었다.신설 산출물 2 - 데이터와 모델 산출물 · HFC Consulting오픈 1년 뒤, AI 기능의 응답 품질이 눈에 띄게 떨어졌다. 원인 회의가 소집됐다. 코드는 형상관리 이력이 있어 반나절 만에 혐의를 벗었다. 문제는 그 다음이었다. 모델이 어느 버전이었는지, 참조 데이터가 언제 어떻게 바뀌었는지 — 아무도 문서로 답하지 못했다. 코드에는 있던 것이 데이터와 모델에는 없었다. 이력이다.신설 산출물의 두 번째 편. 시스템에 AI 기능이 들어가는 사업이라면, 납품 목록에 새로 올라야 할 세 가지 문서를 다룬다.존재 이유 — 소프트웨어가 아닌 것이 품질을 결정한다전통적 산출물 체계는 소프트웨어를 증명 대상으로 설계됐다. 그런데..