비교 가능한 제안은 명확한 의뢰 설명에서 시작됩니다: 반드시 알려야 할 12가지 정보

현재 영국 Sourcing Playbook은 명확한 요구사항이 제안자에게 참여 여부를 충분한 정보에 근거해 판단할 수 있을 만큼 정보를 제공해야 한다고 설명합니다. 또한 요구사항에 대한 공통 이해가 없으면 제시된 가격을 구매자가 이해하는 비용과 의도한 결과에 연결하기 어렵다고 지적합니다. [1]

Government Commercial Function은 더 직접적으로 설명합니다. 좋은 요구사항은 공급자가 상품이나 서비스 비용을 정확히 산정할 수 있는 충분한 정보를 포함해야 하며, 그래야 구매자가 제안을 같은 기준에서 비교할 수 있습니다. [2]

동시에 영국 Digital, Data and Technology Playbook은 해결책을 지나치게 구체화하는 것을 경고합니다. 사용자, 문제, 기대 결과에 집중하면서 공급자가 효과적인 실행 방법을 제안할 여지를 남길 것을 권고합니다. [3]

따라서 결론은 **"모든 것을 최대한 자세히 적어라"**가 아닙니다. 더 나은 원칙은 다음과 같습니다.

모든 제안에서 공통이어야 하는 것은 정확히 설명하고, 유능한 전문가가 합리적으로 설계할 수 있는 부분까지 미리 정하지 마세요.

전문적인 두 제안이 완전히 같을 수는 없으며, 그것이 목표도 아닙니다.

비교 가능하다는 것은 전문가가 대체로 비슷한 가정 아래 같은 문제에 답하고 있다는 뜻입니다.

따라서 다음에 대해서는 대략 같은 이해가 있어야 합니다.

• 목적,
• 범위,
• 시작 상태,
• 기대 결과,
• 중요한 제약,
• 일정,
• 고객 책임,
• 가격 제시 방식,
• 제안 평가 기준.

반면 다음은 달라도 됩니다.

• 제안하는 접근법,
• 작업 순서,
• 방법,
• 팀 구성,
• 도구,
• 단계 구분,
• 위험 감소 방식.

이런 차이는 오히려 가치가 있으므로 보이도록 남겨야 합니다.

기능 목록이 아니라 문제부터 시작하세요.

예를 들어:

"대시보드, 알림, 보고서가 있는 앱이 필요합니다."

보다는:

"현재 다섯 명이 스프레드시트와 이메일로 절차를 관리합니다. 각 건의 현재 상태, 담당자, 다음 작업을 확인하기 어렵습니다. 수작업 추적을 줄이고 최신 상태를 한곳에서 보고 싶습니다."

두 번째 설명은 아직 어떤 앱을 만들어야 하는지 결정하지 않습니다.

하지만 전문가가 왜 이 프로젝트가 필요한지 이해하도록 돕습니다.

성과 중심 서비스에 관한 Federal Acquisition Regulation은 작업을 수행 방법이나 제공 시간보다 필요한 결과를 중심으로 설명하도록 권고합니다. 목표 설명의 최소 요소에는 목적, 범위, 배경, 필요한 결과, 운영상 제약 등이 포함됩니다. [4]

따라서 작업 완료 후 무엇이 가능해야 하는지 적으세요.

예:

• 사용자가 정해진 절차를 스스로 완료할 수 있음,
• 팀이 모든 건의 현재 상태를 확인할 수 있음,
• 고객이 우선순위를 포함한 분석을 받음,
• 시스템이 새 환경으로 이전되고 합의된 기준대로 작동함,
• 준비된 자료가 지정된 채널에 게시 가능한 상태가 됨.

결과는 양측이 작업 방향을 이해할 만큼 구체적이어야 합니다.

그러나 시장, 사용자 행동, 공급자가 통제할 수 없는 다른 요소에 좌우되는 사업 성과까지 보장한다는 뜻은 아닙니다.

같은 최종 요구라도 어디서 시작하느냐에 따라 필요한 작업량이 크게 달라집니다.

다음을 알려 주는 것이 좋습니다.

• 이미 존재하는 것,
• 작동하며 유지해야 하는 것,
• 작동하지 않는 것,
• 원본 파일이 있는지,
• 문서가 있는지,
• 이전해야 할 자료가 있는지,
• 기존 시스템에서 작업해야 하는지,
• 이미 준비된 자료가 무엇인지.

**"새 웹사이트"**는 처음부터 새로 만드는 것일 수도 있고, 콘텐츠, 주소, 분석 설정, 연동, 자료를 유지한 채 기존 사이트를 다시 만드는 것일 수도 있습니다.

최종 모습이 비슷해도 서로 다른 작업입니다.

범위는 전문가가 문제의 어느 부분을 견적해야 하는지 추측하게 만들어서는 안 됩니다.

예:

범위에 포함:

• 현재 해결책 분석,
• 새 화면 디자인,
• 구현,
• 정해진 자료 일부 이전.

범위에서 제외:

• 새 콘텐츠 제작,
• 사용권 구매,
• 첫 달 이후 유지관리,
• 결제 시스템 재구축.

세계은행의 Terms of Reference 예시는 컨설팅 서비스의 요구와 기대를 명확하게 표현하고 구체적인 프로젝트에 맞추어야 한다고 강조합니다. [5]

두 작업이 자연스럽게 연결되어 한쪽이 다른 쪽을 포함한다고 오해하기 쉬울수록 경계가 중요합니다.

특정 자료나 결과물을 기대한다면 이름을 분명히 적으세요.

예:

• 작동하는 해결책,
• 원본 파일,
• 보고서,
• 문서,
• 시각 디자인,
• 자료 묶음,
• 환경 설정,
• 교육,
• 녹화,
• 코드와 접근 권한 인계.

"디자인", "분석", "구현" 같은 말은 사람마다 다르게 해석할 수 있습니다.

주요 결과물 목록을 공통으로 정하면 한 제안이 다른 제안보다 훨씬 많은 내용을 포함하지만 비슷한 서비스 이름 때문에 차이가 가려지는 일을 줄일 수 있습니다.

모든 제약이 기술적인 세부사항은 아닙니다.

중요할 수 있는 예:

• 필수 시스템 또는 환경,
• 특정 서비스와의 필수 연동,
• 접근성 요구사항,
• 업계 규정,
• 자료 보관 제한,
• 기존 기반시설 유지 필요,
• 특정 기기나 브라우저,
• 지정된 시간대의 작업,
• 자료 접근 제한.

FAR는 목표 설명에 운영상 제약을 명시적으로 포함하며, Digital, Data and Technology Playbook은 실제 제약이 없다면 해결책을 미리 강제하지 않아야 한다는 점도 보여 줍니다. [4] [3]

유용한 원칙:

전문가가 바꿀 수 없는 것은 명확히 적되, 단지 한 가지 해결 방식에 익숙하다는 이유로 제약을 만들지는 마세요.

전문가는 제안을 어떤 수준의 협조를 전제로 만들 수 있는지 알아야 합니다.

다음을 제공할 수 있는지 적으세요.

• 의사결정자,
• 시스템 접근 권한,
• 기존 자료,
• 데이터,
• 시험 계정,
• 팀의 정보,
• 사용자 접근,
• 콘텐츠,
• 정기 회의,
• 정해진 기간 내 답변.

아직 무엇을 제공할 수 있는지 모른다면 그 사실도 유용한 정보입니다.

자료, 문서, 사람에 대한 접근 부족은 방법, 비용, 일정을 바꿀 수 있습니다. 작은 행정 문제가 아니라 제안이 성립하는 조건의 일부입니다.

모든 날짜가 같은 의미를 가지는 것은 아닙니다.

다음을 구분하세요.

• 선호 시작일,
• 움직일 수 없는 마감일,
• 외부 행사와 연결된 날짜,
• 예상 날짜,
• 특정 순서로 진행해야 하는 단계.

마감일이 실제로 움직일 수 없다면 이유를 설명하세요.

유연하다면 그 사실도 적으세요.

그러면 전문가는 모든 날짜를 절대 조건으로 보지 않고 다른 범위, 순서, 단계적 전달을 제안할 수 있습니다.

고객이 항상 전체 예산을 공개해야 한다는 단일한 규칙은 없습니다.

상황에 따라 다음을 제공할 수 있습니다.

• 최대 예산,
• 예산 범위,
• 첫 단계 예산,
• 먼저 범위 제안을 받고 이후 가격을 받고 싶다는 정보,
• 원하는 가격 세부 구조.

비교에서는 전문가가 비용을 비슷한 구조로 제시하는 것이 특히 중요합니다.

예:

"분석, 디자인, 구현, 월 유지관리 가격을 각각 제시해 주세요. 포함되지 않은 외부 서비스 비용도 밝혀 주세요."

각 총액이 서로 다른 내용을 포함하는 네 개의 숫자보다 훨씬 비교하기 쉽습니다.

쓰지 않았다고 불확실성이 사라지는 것은 아닙니다.

다음을 모른다면 분명히 적으세요.

• 이전해야 할 자료의 양,
• 외부 인터페이스가 필요한 작업을 지원하는지,
• 모든 콘텐츠가 준비될지,
• 현재 코드를 합리적으로 확장할 수 있는지,
• 필요한 승인이 제때 나올지.

GAO의 신뢰할 수 있는 비용 추정 가이드는 명시적 가정과 위험 및 불확실성 분석의 중요성을 강조합니다. [6]

좋은 전문가는 이후:

• 여유분을 포함하고,
• 사전 조사 단계를 제안하고,
• 대안을 각각 견적하고,
• 가격을 바꿀 조건을 밝히고,
• 아직 정직하게 달성할 수 없는 정밀도를 가장하지 않을 수 있습니다.

명시된 미확정 사항은 숨겨진 가정보다 낫습니다.

결정에서 무엇이 중요할지 이미 알고 있다면 제안 작성 전에 알려 주세요.

예를 들어:

• 제안한 접근법의 적합성,
• 비슷한 문제 경험,
• 이전 작업 증거의 품질,
• 일정의 현실성,
• 가용성,
• 위험 관리 접근법,
• 실제 프로젝트 담당자의 역량,
• 가격,
• 유지관리 비용,
• 소통 품질.

세계은행의 현재 Rated Criteria 자료는 비가격 기준에 방법과 작업 계획의 품질, 위험 관리, 수행 능력과 역량, 핵심 인력 등이 포함될 수 있다고 설명합니다. 기준은 해당 조달에 맞춰 조정되고 상대적 중요도에 따라 가중됩니다. [7]

작은 의뢰에 공식 점수제가 필요하다는 뜻은 아닙니다.

요청을 보내기 전에 다음 질문에 답할 수 있으면 충분합니다.

"가격 외에 어떤 점이 한 제안을 다른 제안보다 나에게 더 좋게 만드는가?"

제안을 정말 비교하려면 모든 사람에게 같은 기본 질문에 답하도록 요청하세요.

예:

1. 문제와 기대 결과를 어떻게 이해합니까?
2. 어떤 접근법을 제안합니까?
3. 제안에는 구체적으로 무엇이 포함됩니까?
4. 무엇이 제외됩니까?
5. 어떤 가정을 하고 있습니까?
6. 일정은 어떻게 됩니까?
7. 고객에게서 무엇이 필요합니까?
8. 주요 위험은 무엇입니까?
9. 가격은 얼마이며 정확히 무엇을 포함합니까?
10. 이 의뢰에 관련된 비슷한 경험이나 작업 증거는 무엇입니까?

공공 조달에서는 답변, 기준, 가격 제시 형식을 공통화하여 제안을 같은 기준에서 평가할 수 있게 합니다. Government Commercial Function은 정확한 비용 산정과 같은 조건에서의 비교를 위해 충분한 정보가 필요하다고 강조합니다. [2]

공통 형식은 전문가 간 차이를 없애는 것이 아니라 같은 위치에서 차이가 보이게 해야 합니다.

요청의 목적에 따라 다릅니다.

예산을 공유하면 도움이 되는 경우:

• 가용 예산에 맞춰 범위를 조정할 수 있음,
• 정해진 상한 안에서 최선의 선택을 추천받고 싶음,
• 프로젝트의 재정 현실에 맞지 않는 제안을 빨리 걸러내고 싶음.

전체 예산을 공개하지 않는 것이 합리적인 경우:

• 먼저 적절한 범위에 대한 독립적 의견을 듣고 싶음,
• 현실적인 비용을 아직 모름,
• 서로 다른 해결 모델을 비교함,
• 절차상 다른 가격 수집 방식이 필요함.

가장 나쁜 상황은 반드시 예산이 없는 것이 아니라 어떤 형태의 가격 답변을 원하는지 설명하지 않는 것입니다.

전문가는 총액, 범위, 여러 선택안, 단계별 가격, 더 정확한 추정에 필요한 가정 중 무엇을 제시해야 하는지 알아야 합니다.

좋은 의뢰 설명이 모든 질문에 답할 필요는 없습니다.

정직하게 다음과 같이 쓸 수 있습니다.

• "현재 시스템을 안전하게 확장할 수 있는지 아직 모릅니다.",
• "이전해야 할 기록의 정확한 수를 모릅니다.",
• "두 번째 언어 버전을 첫 단계에 포함할지 아직 결정하지 않았습니다.",
• "가장 좋은 선택을 정하는 데 도움이 필요합니다."

이것도 가치 있는 정보입니다.

불확실성은 제안을 준비하는 방식에 영향을 주어야 하며 문서에서 사라져서는 안 됩니다.

어떤 상황에서는 첫 서비스로 전체 구현보다, 결정, 더 정확한 범위, 더 신뢰할 수 있는 추정으로 끝나는 짧은 사전 조사 단계가 더 적절할 수 있습니다.

1. 전문가마다 다른 정보를 제공하기.

2. 문제와 목적을 설명하지 않고 기능만 나열하기.

3. 이미 무엇이 있는지 설명하지 않기.

4. 나중에 실행 방식을 바꾸는 제약을 숨기기.

5. 무엇을 포함해야 하는지 말하지 않고 최종 총액 하나만 요청하기.

6. 스스로 미리 정하지 않은 기준으로 제안을 평가하기.

7. 문제를 자세히 설명하는 것과 해결책을 자세히 강제하는 것을 혼동하기.

1. 내가 생각한 해결책만 아니라 문제 자체를 명확히 설명했는가?
2. 원하는 결과가 분명한가?
3. 전문가가 현재 상태를 이해할 수 있는가?
4. 무엇을 유지해야 하는지 분명한가?
5. 첫 범위의 경계가 명확한가?
6. 주요 결과물을 적었는가?
7. 실제 제약을 밝혔는가?
8. 고객 측에서 제공할 것이 분명한가?
9. 일정과 그 유연성을 함께 설명했는가?
10. 가격 형식이 제안 비교를 가능하게 하는가?
11. 중요한 미확정 사항을 공개했는가?
12. 가격 외에 무엇을 평가할지 알고 있는가?
13. 모든 전문가가 비슷한 질문에 답하는가?
14. 내가 생각한 것보다 더 좋은 해결책을 제안할 여지를 남겼는가?

좋은 의뢰 설명에는 겉보기에는 서로 반대되는 두 가지 목표가 있습니다.

여러 전문가가 같은 문제를 견적할 수 있도록 충분히 구체적이어야 합니다.

동시에 각 전문가가 자신만의, 더 나을 수 있는 접근법을 제안할 수 있도록 충분히 열려 있어야 합니다.

유용한 순서는:

문제 -> 결과 -> 현재 상태 -> 범위 -> 결과물 -> 제약 -> 고객 책임 -> 일정 -> 가격 형식 -> 미확정 사항과 위험 -> 선정 기준 -> 공통 답변 형식.

제안을 받은 뒤 한 사람은 전체 프로젝트, 다른 사람은 분석만, 세 번째 사람은 추가 연동까지 포함해 견적했다는 사실을 알게 된다면 문제는 가격에만 있지 않을 수 있습니다.

모두에게 같은 글을 보냈더라도 실제로는 각자가 서로 다른 의뢰를 받은 셈일 수 있습니다.

[1] UK Government - The Sourcing Playbook
출처 열기

[2] Government Commercial Function - How to write a procurement specification
출처 열기

[3] UK Government - The Digital, Data and Technology Playbook
출처 열기

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
출처 열기

[5] World Bank - Sample Consultants Terms of Reference
출처 열기

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
출처 열기

[7] World Bank - Rated Criteria
출처 열기

방법론 참고: 출처는 주로 공공 조달과 비용 관리의 맥락에서 나옵니다. 민간 전문가 시장에 직접 적용되는 규칙으로 제시하지 않습니다. 이 글은 요구사항의 명확성, 결과 중심, 명시적 가정과 위험, 비교 가능한 가격 정보, 가격 외 품질 기준을 통한 평가처럼 실제로 출처가 뒷받침하는 원칙만 사용합니다.