LiVE LG LG전자 소셜 매거진

여러분의 프로젝트는 어떠한가요? 아무런 문제가 없다면 모르겠지만, 만일 요구사항과 관련된 문제가 있다면 아마도 위의 항목들 중에서 단 한가지에만 해당하는 경우는 별로 없을 겁니다. 문제가 있는 프로젝트라면 위의 항목들 세 가지 모두 해당될 가능성이 큽니다.

프로젝트에도 첫 단추라는 게 있습니다. 첫 단추를 잘못 끼웠는데 다른 단추들이 제대로 끼워질 리 없습니다. 프로젝트는 요구사항으로 인해 개시되고 요구사항을 구현함으로써 완료됩니다. 즉, 중요한 요구사항이 프로젝트 초반에 제대로 분석되고 작성되지 않았다는 것은 프로젝트의 핵심 이해관계자들이 ‘요구사항 관리’의 중요성에 대해 무지하다는 뜻입니다. 요구사항 관리의 중요성을 몰라서 그랬다면 ‘순수한 무지’이고, 알면서도 무시했다면 ‘안다고 착각하는 더 나쁜 무지’라고 볼 수 있습니다. 알면 실천을 해야죠.

그리고 프로젝트의 비극이 시작됩니다. 요구사항은 프로젝트의 방향성을 결정하고 결과물을 만들기 위한 중요한 기반입니다. 그런데 그것이 불분명하거나 누락되어 있다는 것은 프로젝트라는 배가 바다가 아니라 산으로 가게 될 가능성을 확실히 높여줍니다.

그러니 아무리 일정이 빡빡하다고 할지라도 요구사항 분석 및 작성에 충분한 시간을 할애해야 합니다. 아니, 일정이 빡빡할수록 요구사항 작성에 더욱 신경을 써야 합니다. 시행착오를 할 여유시간이 없다는 뜻이니까요. 어디로 화살을 쏠 지 분명히 알아야 과녁을 정확히 맞힐 수 있지 않겠습니까?

요구사항 관리에 대한 무지, 시간이 없다는 핑계, 또는 고객의 지원 부족 등으로 인해 초반에 제대로 작성되지 못한 요구사항은 프로젝트 내내 발목을 잡게 됩니다. 중요한 기능이 누락되거나, 오해한 나머지 잘못 만들거나, 제대로 만들었다고 생각됐다가도 새롭게 추가된 다른 기능과의 상충 때문에 수정을 하거나 다시 만들어야 할 수도 있습니다.

요구사항은 변경될 수 있다!

요구사항은 프로젝트 수행 중에 불가피한 이유나 납득 가능한 이유로 변경될 수 있습니다. 예를 들어 중간에 시장 상황이 바뀌었거나, 경쟁업체가 새로운 기능을 가진 신제품을 출시했거나, 초반에는 발견되지 않은 중요한 요구사항이 나중에 발견될 수도 있고, 필요하다고 생각했던 기능이 필요 없어졌거나 등등의 요구사항의 변경을 가져오는 여러가지 이유들이 존재합니다. 이처럼 납득 가능한 이유로 인한 변경이라면 긍정적으로 검토를 하는 것이 타당하겠죠.

그렇지만 만일 여러분이 합리적인 대화가 어려운데다 ‘한국형 갑을문화’에 통달한 고객을 만난다면 그의 온갖 요구사항을 다 들어줘야 하는 상황에 처하게 될 수도 있습니다. 지옥문이 열리는 것이죠. (이 대목에서 저는 무려 16년 전 경험한 프로젝트의 트라우마가 떠오릅니다. 장면 장면이 지금도 생생할 정도입니다.)

요구사항이 변경된다면?

앞서 살펴봤다시피, 프로젝트를 진행하다 보면 요구사항 변경이 발생할 수 밖에 없는 경우가 적지 않습니다. 요구사항의 변경 자체가 나쁘다고 볼 수는 없습니다. 프로젝트에 필요한 것일 수도 있기 때문입니다. 정확히 말하면, 요구사항의 변경이 나쁜 게 아니라 요구사항의 변경이 가져오는 영향을 분석하고 프로젝트에 반영하지 않는 게 나쁜 것입니다.

현실의 프로젝트들이 처한 상황을 보면, 프로젝트 초반에 제대로 요구사항을 작성하지 않는 프로젝트일수록, 고객의 기호나 즉흥적인 아이디어에 의해 빈번하게 요구사항이 변경되는 프로젝트일수록, 그러한 요구사항의 변경이 프로젝트의 일정 및 비용에 미치는 영향을 분석하고 반영하지 않는 경우가 대부분입니다.

프로젝트 관리의 기본 개념 중에 ‘프로젝트 관리의 삼각형’이라는 것이 있습니다. 삼각형의 세 변은 각각 범위(Scope), 비용(Cost), 시간(Time)으로 구성돼 있으며 하나의 변을 변경시키면 다른 두 변이 영향을 받는다는 개념입니다. 즉, 기능이 늘어나면 비용과 시간이 늘어가든지 아니면 최소한 둘 중의 하나라도 늘어나야 합니다. 이것이 프로젝트 관리의 기본입니다.

프로젝트 관리자는 어떻게 해야 할까?

프로젝트 관리자는 이러한 기본을 지키지 위해 필사의 노력을 경주해야 합니다. 요구사항은 변경될 수 있습니다. 그러므로 고객 등 프로젝트 이해관계자에 의해 요구사항 변경의 요청이 발생하면 그것을 무작정 반영하거나 거부할 게 아니라, 그것이 범위/비용/시간에 미치는 영향을 분석한 다음에 변경관리위원회(CCB: Change Control Board, 변경통제위원회 또는 변경승인위원회라고도 함)에 상정해서 결정토록 해야 합니다.

물론 이때 모든 요구사항 변경을 이와 같이 처리할 필요는 없고, 일정 수준 이상의 영향이 발생하는 주요사항들만 변경관리위원회에서 결정하면 됩니다. 또한 변경관리위원회를 굳이 따로 소집할 필요는 없고 정기 프로젝트 미팅 때 함께 개최하면 됩니다. 각자의 프로젝트 형편에 맞는 방법을 찾아내서 실행해야 합니다.

요구사항 변경이 미치는 영향을 한가롭게 분석할 시간이 어디 있냐고요? 변경관리위원회 같은 거 있지도 않고, 설사 있다고 해도 언제 소집해서 의사결정 하냐고요? 저는 그런 매너리즘에 빠진 생각이 프로젝트를 실패하게 만드는 게 아닌지 반문하고 싶습니다. 중대한 요구사항의 변경이 프로젝트 일정, 비용, 품질 등에 미칠 영향을 제대로 파악하지도 않는 채 그것을 반영하는 위험을 감수하시겠습니까? 아니면 무조건 거부해서 고객과의 불화를 자초하시겠습니까?

해당 요구사항의 변경이 반드시 필요하다면 그것이 영향을 미치는 프로젝트 일정 또는 비용에도 변경이 필요합니다. 만일 그렇게 할 수 없다면, 해당 요구사항의 변경을 원점에서 재검토해야 하지 않을까요?

물론, 프로젝트의 현실은 합리적이지 않습니다. 오히려 비합리적이죠. 제가 얘기한 게 맞는다고 하더라도 현장에서는 “현실적으로 그게 어렵다”는 얘기를 많이 듣습니다. 바로 그렇기 때문에 유능한 프로젝트 관리자는 프로젝트 초반에 집중하고 프로젝트라는 기차가 탈선하지 않도록 온갖 장치를 만드는 것입니다. 프로젝트의 현실이 비합리적이기 때문에 우리는 더욱 더 철저한 준비를 해야 합니다.

 “프로젝트 관리는 무질서와의 투쟁이다”

만일 여러분이 프로젝트의 성공 가능성을 높이고자 한다면, 프로젝트 초반에 어떻게든 시간과 인력을 확보하여 충분히 요구사항을 분석하고 작성해야 합니다. 그렇지만 초반에 아무리 정리를 잘했다고 하더라도 프로젝트 진행 중에 요구사항의 변경이 발생할 겁니다. 그게 요구사항의 본질이니까요. 그것을 잘 알고 있는 여러분은 요구사항의 변경 요청이 있을 시 그것이 미치는 영향을 분석하는 절차를 프로젝트에 반영해 놓아야 합니다. 그것은 사치스러운 작업이 아니라 프로젝트 관리자의 역할이자 의무입니다.

그리고 변경관리위원회(그 형태와 이름이 무엇이든지)를 필히 만들어 프로젝트에 일정 수준 이상의 영향을 미치는 요구사항의 변경을 핵심 이해관계자들이 평가하고 논의한 후 결정할 수 있도록 해야 합니다. 그래야만 해당 요구사항의 변경을 승인하든지 아니면 거부하든지 간에 프로젝트에 미치는 나쁜 영향을 최소화할 수 있을 겁니다. 그렇지 않으면 모든 것을 운에 맡겨야 합니다.

제가 서두에서 언급했던 “프로젝트 관리는 무질서와의 투쟁이다”라는 말을 다시금 생각해봅니다. 프로젝트 관리자가 적시에 챙기지 않으면 바로 무질서해지는 게 프로젝트의 속성입니다. 사실 요구사항 말고도 챙길 게 참 많습니다만, 일단 요구사항이라도 프로젝트 초반부터 확실히 챙기고, 요구사항 변경이 미치는 영향을 분석하는 절차를 수행하고, 그리고 해당 내용을 평가하고 결정하는 변경관리위원회가 제대로 작동될 수 있도록 챙긴다면 많은 무질서를 바로 잡을 수 있을 겁니다.

물론, 이는 결코 쉬운 일이 아닙니다. 하지만 그런 것들을 챙기지 않은 나머지, 어느 순간 실패를 향해 폭주하는 프로젝트를 살리는 것보다는 훨씬 쉬운 일이 아닐까요?