요구사항 변경에 성공적으로 대응하는 방법
요구사항 변경의 책임을 규명하려고 하는 시도는 바람직하지 않습니다.
프로젝트 팀이 요구사항 변경에 대응할 때 흔히 하는 실수는 변경의 책임규명에 집착하는 것입니다. 상대방이 인정할 수 있는 객관적인 근거 없이 주관적인 관점에서 상대방의 귀책을 주장하면, 프로젝트 팀이 원하는 것을 얻기 힘들 뿐 아니라 부작용이 발생하기 쉽습니다.
계약에 의한 프로젝트(예:SI 프로젝트, 시공 프로젝트)는 요구사항 변경에 잘못 대응하면 조직에 큰 손실을 초래하기 때문에 프로젝트 관리자가 변경에 민감하게 반응하는 경우가 많습니다. 계약에 의한 프로젝트에서 요구사항 변경에 대한 논쟁이 심해지면 쌍방은 다시 보지 않을 것처럼 요구사항 변경에 대한 귀책을 논쟁합니다. 고객사의 관리자는 변경이 아니라고 주장하고 프로젝트 관리자는 변경이라고 하는 상황이 대부분입니다. 실무 관리자 선에서 타협점을 찾기 어려우면 양사의 법무인력이 만나서 각 사의 책임을 최소화하기 위한 논쟁을 합니다. 소위 말하는 ‘법대로’하는 상황까지 간 것입니다. 그러나 그 상황까지 가면 정도의 차이가 있을 뿐 쌍방 모두 패자가 됩니다. 고객사는 비용을 들여 발주한 프로젝트가 지연되고 프로젝트 목표는 달성하기 힘듭니다. 프로젝트를 수행하는 회사는 더 심한 타격을 받습니다. 프로젝트 지연에 대한 추가 원가를 부담할 뿐 아니라 프로젝트에 투입된 팀원들은 변경으로 인한 영향력을 최소화하기 위해 정신적, 육체적으로 힘들어지기도 합니다.
계약에 의한 프로젝트보다는 덜 하지만, 조직내부 프로젝트의 변경에 대응하는 것도 힘듭니다. 조직내부 프로젝트의 요청부서와 프로젝트 개발팀은 같은 회사에서 근무하기 때문에 극한의 갈등은 피할 수 있습니다. 그러나 그러한 갈등이 축적되면 조직의 생산성에 부정적인 영향을 미치기 때문에 요구사항 변경으로 인한 갈등을 줄여야 합니다.
실패하는 변경통제와 성공하는 변경통제의 차이는 다음과 같습니다.
- 실패하는 변경통제는 변경에 대한 책임규명에 집착하기 때문에 과거지향 적지만, 성공하는 변경통제는 요구사항의 가치를 기반으로 개발의 우선순위에 집중하기 때문에 미래지향적입니다.
- 실패하는 변경통제는 주관적 관점에서 win lose에 집착하지만, 성공하는 변경통제는 객관적 관점에서 절충가능한 방안을 찾습니다.
- 실패하는 변경통제는 상대방에게 책임을 넘기기 위해 논쟁하지만, 성공하는 변경통제는 상대방의 입장에 역지사지로 공감합니다.
- 실패하는 변경통제는 문제해결을 에스컬레이션 하지 않지만, 성공하는 변경통제는 사안에 따라 문제해결을 에스컬레이션 합니다.
실패하는 변경통제와 성공하는 변경통제요구사항 변경은 예방하는 것보다 발생한 변경에 대응하는 것은 더 힘듭니다. 그 이유는 쌍방의 이해관계를 절충할 기회를 잃어버리고 감정이 대립되는 상황까지 가는 경우가 많기 때문입니다. 그런 상황에서는 성공하는 변경통제의 방안들이 사치스러운 교과서의 말이 됩니다. 요구사항 변경에 대해 슬기롭게 대응하기 위해서는 요구사항 변경에 대해 다음의 순서대로 대응해야 합니다.
- 변경하고자 하는(오해한) 요구사항의 가치를 먼저 판단합니다.
원인이 무엇이던 요구사항의 변경이 발생하면 변경하고자 하는 요구사항이 누구에게 어떤 가치를 제공하는지 확인해야 합니다. 요구사항의 가치를 확인하기 전에 “이번 요구사항을 반영하려면 일정연장과 추가원가가 필요합니다.”는 말부터 하는 것은 같은 배를 탄 파트너의 도리가 아닙니다. 상대방의 입장에서 변경 요구사항(또는 오해한 요구사항)의 내용과 가치를 먼저 확인하는 것이 파트너의 자세입니다. 프로젝트 관리자는 파트너의 입장에서 이해관계자 옆에 앉아 같은 방향의 미래를 봐야 합니다. 프로젝트 관리자가 프로젝트 팀의 실속만 챙긴다고 상대방이 느끼면 프로젝트는 성공하기 힘듭니다. 이해관계자가 프로젝트를 잘 되게 하기는 힘들지만, 프로젝트를 힘들게 하는 것은 쉽기 때문입니다.
- 요구사항의 오해인지, 오류인지, 변심인지를 객관적으로 판단합니다.
요구사항의 변경의 발생원인을 정확하게 판단해야 향후 논의가 수월해집니다. 프로젝트 관리자 입장에서는 고객이나 이해관계자의 변심이 많은 것 같지만 실제로는 오해나 오류가 많습니다. “~ 때문에 요구사항을 이해하는 과정에서 오해가 있었습니다.”라고 말하는 것과 “당신이 요구사항을 바꾸었기 때문에~”라고 말하는 것은 큰 차이가 있습니다. 말 한마디가 천냥의 빚을 갚을 수도 있지만 없는 천냥의 빚도 만들 수 있는 것이 프로젝트의 소통입니다. 요구사항 변경의 원인을 객관적으로 판단하기 위해서는 상대방의 입장을 이해해야 하고, 상대방의 입장을 이해하기 위해서는 열린 마음으로 상대방의 이야기를 청취해야 합니다.
- 개발하지 않은 요구사항의 우선순위를 판단합니다.
변경하고자 하는 요구사항이 많은 사람들에게 유용한 가치를 제공한다면 우선순위를 조정할 요구사항이 있는지 검토해야 합니다. 이때 비슷한 규모의 요구사항을 제외를 주장해서는 안됩니다. 요구사항의 가치에 대한 판단은 이해관계자의 몫입니다. 예를 들어 3OMM규모의 변경사항을 반영해야 하는데 30MM규모의 요구사항을 제외하기는 쉽지 않습니다. 요구사항의 가치는 이해관계자가 판단하도록 해야 하며 가치를 판단하는 방법은 우선순위를 결정하는 기법과 동일합니다.
- 상생 또는 절충의 방안을 토의합니다.
지금까지 파악했던 내용을 바탕으로 이해관계자와 함께 요구사항 변경의 반영여부를 결정하고 반영에 대한 대응방안을 협의합니다. 예를 들어 다음과 같습니다.
· 금번에 협의 중인 요구사항의 내용을 분석해 보니 조직의 관점에서 유용한 가치를 제공하기 때문에 요구사항 변경의 필요성을 공감합니다.
· 요구사항이 변경이 발생한 원인을 살펴보니 요구사항을 협의하는 과정에 있어 오해가 있었습니다. 00요구사항에 대한 협의를 하는 과정에서 프로젝트 팀과 고객사 조직이 전제조건을 명확히 소통하지 못한 것이 원인이었습니다.
· 변경된 요구사항을 반영하기 위해서는 1개월이 지연되고, 20MM가 추가로 필요한데 아쉽게도 프로젝트팀에서 감당하기 힘듭니다. 기존 요구사항 중 우선순위가 낮은 A와 B 기능을 다음에 개발하면 납기와 예산의 변동 없이 반영 가능합니다. 특히 A와 B 기능은 새로운 기술이 적용되면 더 이상 필요하지 않을 수도 있습니다.
· 기존 요구사항의 우선순위 조정 없이 변경된 요구사항을 모두 수용하는 것은 안타깝게도 제 권한 밖의 일입니다. 저는 요구사항 변경의 필요성에 공감하지만 본사 경영층의 입장은 다를 수 있습니다. 저의 입장으로서는 본사 경영층의 지시에 따를 수밖에 없음을 이해 부탁드립니다. (악역은 경영층에게 위임하는 것이 좋습니다.)
지금까지 요구사항 변경통제의 순서를 설명드렸습니다. 요구사항 변경통제가 파국으로 치닫는 것을 예방하는데 도움이 되는 추가적인 팁은 다음과 같습니다.
- 급하게 결정하지 않습니다. 시간이 약이 될 수 있습니다.
프로젝트를 진행하는 도중 고객과 협의하는 과정에서 고객이 번뜩이는 아이디어를 제시할 수 있습니다. 예를 들어 고객이 흥분하여 “○○ 씨 내가 어젯밤에 고민해 봤는데, 설계를 이렇게 변경하고 이 기능을 추가하는 것이 좋겠어요”라고 의견을 제시하는 겁니다. 고객으로부터 요구사항 변경에 대한 내용을 들은 프로젝트 관리자는 등에 식은땀이 흐릅니다. 전체 프로젝트를 힘들게 만들 수 있는 아이디어이기 때문입니다.
시간이 경과할수록 상대방의 의견을 수용하는 것 같아 빨리 프로젝트 팀에 피해가 없는 의사결정으로 상대방을 설득하고 싶습니다. 그러나 요구사항 변경을 확정하기 위해서는 일정 기간 동안 아이디어 숙성 기간을 가지는 것이 좋습니다. 고객이 번쩍이는 아이디어를 냈을 때 그 자리에서 프로젝트 팀이 방어적인 논리를 강하게 펼친다면 고객은 자신을 변호하기 위하여 더 튼튼한 로직을 만들 수 있습니다. 뿐만 아니라, 논리적 대화에서 상대방을 이기고 싶은 욕구를 자극하게 됩니다. 말 그대로 긁어 부스럼을 만드는 상황이 됩니다. 그냥 “좋은 아이디어입니다. 다양한 측면을 고려해 보겠습니다”라고 긍정도 부정도 하지 않고 가볍게 넘어가는 것도 좋은 방법입니다.
시간이 지나 고객의 요구사항을 다시 이야기하지 않거나 강도가 약해진다면 다행이지만 그렇지 않더라도 프로젝트 팀에서 여러 가지 대응방안을 고민하는 것이 필요합니다.
- 이기려고 하지 않습니다.
고객이나 이해관계자를 이기는 것은 불가능에 가깝습니다. 이기려고 하는 마음은 행동이나 말로 드러나기 때문에 이슈 해결에 도움이 되지 않습니다. 힘들지만 공감하고 배려하는 마음을 가지는 것이 문제해결에 도움이 됩니다. 이타적인 마음이 아니라 이기적인 목적에서라도 그렇게 해야 합니다.
- 상대방도 나만큼 합리적이라고 생각합니다.
스스로 ‘나는 비합리적이야’라고 생각하는 사람이 있을까요? 모든 사람들은 스스로 합리적이라 생각하고 상대방에게는 엄격한 잣대를 적용합니다. 상대방을 나만큼 합리적이라고 생각하면 내가 놓쳤던 관점들이 보입니다. 나의 행동에 대해서 내가 아는 것의 절반정도만 상대방의 행동에 대해 이해해도 많은 것들이 달라집니다.
- 요구사항 변경을 이해관계자들의 이해관계 또는 조직내 정치의 맥락에서 이해합니다.
고객 요구사항의 이면에는 조직의 비즈니스 니즈와 이해관계자의 정치적인 니즈가 있을 수 있습니다. 표면적인 요구사항 변경의 이유보다 숨겨진 이유가 있을 수 있습니다. 요구사항의 변경과 관련하여 이해관계자의 이해관계의 크기를 정확하게 파악해야 합니다. 프로젝트 초기와 다른 상황의 변화가 대표적인 이유입니다. 특히 개인의 승진 또는 퇴사의 위협에 직면한 임원들에게는 요구사항 변경은 협상의 대상이 아닙니다. 오히려 그런 이해관계자들에게 다른 요구사항을 제외를 설득하는 것은 쉽습니다.
https://brunch.co.kr/@kbhpmp/160
