PoC는 이기는데 왜 수주는 못할까?

기술 검증은 이겼는데 수주는 못하는 경우가 정말 많습니다. (저도 참 많이 떠오르네요ㅠㅠ)

그럼.. 왜 이런 일이 생길까요?

PoC 초반엔 기술팀이 말합니다.

"기능은 충분합니다."

중간에 운영팀이 말합니다.

"운영 리스크가 있는데요?"

그러면 임원이 결론 내립니다.

"전략적으로 불확실하네."

검증 기간 내내 골대가 움직입니다. 성공 기준(Success Criteria)이 없으니 PoC는 기술 평가가 아니라 조직 내 발언권 경쟁이 됩니다.

그리고 요구사항도 끝없이 늘어나죠. '이거도 되나요?' '저것도 보여주세요.' 시나리오 검증이 아니라 기능 설명의 장이 됩니다.

그래서 PoC 시작 전에 이 한 가지는 꼭 합의되어야 합니다. 'PoC에서 이 요구사항을 만족하면, 구매를 전제로 다음 단계를 진행한다.'

성공 기준은 PoC의 결과물이 아니라 출발선입니다. 이 합의 없이 시작하면 PoC는 성공해도 수주는 실패할 가능성이 높습니다.

그럼 실전에서는 어떻게 확인해야 할까요? 고객한테 '정말 살 건가요?"라고 직접 물을 순 없죠. 대신, 고객 조직이 '이 요구만 충족되면 나머지는 우리가 알아서 하겠다'는 신호를 보낼 때를 포착해야 합니다.

운영, 보안, 감사 조직이 PoC에 미리 들어온다.

보통 거부권자는 늦게 등장하는데, 미리 나타났다는 건 적어도 '나중에 뒤집지 않겠다'는 뜻입니다.

아직 안 샀는데 '도입 후'를 얘기한다.

'SLA는 어떻게 가져갈까요?' 이미 마음이 있다는 거죠.

예외 승인을 얘기한다.

'이번엔 파일럿으로 예외 적용할겁니다' 조직은 웬만하면 예외를 안 만들죠? '예외로 하겠다'는 책임지겠다는 말입니다.

실무자부터 임원까지 똑같은 말을 한다.

내부 정렬이 끝났다는 신호입니다. '뒤집을 사람'이 없다는 뜻입니다.

의사결정 보고서에 리스크와 대응 방안을 명시한다.

리스크를 알지만 대응할 자신이 있다는 신호입니다.

이런 신호들을 포착했다면, 이제 확인할 차례입니다.

가장 결정적인 질문 : 'PoC에서 요구사항을 만족했는데, 나중에 운영 이슈가 생기면 재평가하게 되나요?'

여기서 '아니오'가 나오면 거의 끝난 상황입니다.

성공 기준은 '문제를 해결했나?'라는 기술 검증이 아니라, '고객이 그 해결책을 받아들일 건가?'라는 조직의 의사결정에 가깝습니다.