프로젝트 품질은 프로젝트를 진행할 때 기본 특성이 요구 사항을 충족시키는 정도를 의미합니다. 이해 관계자들이 프로젝트를 통해서 만들어지는 인도물을 수용하기 위해서 기능 요구 사항 뿐만 아니라 품질 요구 사항들에 대해서도 충족해야 합니다. 상위 수준의 품질 요구 사항은 요구 사항 문서에서 정의하고, 개별 인도물의 품질 요구 사항은 개별 인도물에 인수 기준이나 완료 정의 형태로 정의합니다.
프로젝트 품질 관리와 품질 비용의 이해
대부분의 회사들에서는 품질 활동을 전문 부서나 전문 조직에서 진행하도록 하게 됩니다. 다만, 프로젝트 팀 자체적으로도 품질 활동을 해야 합니다. 만약, 회사에서 전사적으로 품질 관리의 역할을 담당하는 부서가 있다면, 회사에서 진행하는 모든 프로젝트들에 대해서 적용할 정책을 수립하고 품질 활동에 대한 비용도 일부나 전체를 회사에서 부담하는 형태로 진행하게 됩니다. 그럼 이어서 프로젝트 품질 관리와 품질 비용에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 품질 관리에 대한 설명
프로젝트를 통해서 결과물을 인도할 때, 범위와 요구 사항과 더불어 품질에 대해서도 중요하게 다루고 초점을 맞춰야 합니다. 범위와 요구 사항은 제공해야 할 사항에 대해서 중점을 두고 집중한다면, 품질은 충족해야 할 성과의 수준에 대해서 초점을 맞추는 것입니다. 품질 요구 사항은 요구 사항 문서, 작업 기술서(SOW), 인수 기준, 완료 정의(DoD)에 반영될 수 있습니다. 품질과 관련된 대부분의 비용은 스폰서 조직에서 부담하게 되고 정책, 절차, 프로세스에 대해서 반영하게 됩니다.
고등급과 고품질은 구분되어야 합니다. 품질은 제품이 제공하는 기능이 정확하고 일관되게 작동하는 특징입니다. 고객이 잘 사용하지 않는 다양한 기능들을 제공하는 제품은 성공하기 어렵습니다. 기능이 많아지면 많아질수록 기업 입장에서는 원가가 높아지고 개발 기간은 길어지며 유지 보수도 어려워집니다. 고객 입장에서는 기능이 많아지면 오히려 사용의 편의성도 낮아질 수 있습니다. 따라서 무조건 기능이 많다고 해서 좋은 것이 아닙니다. 고객이 요구하지 않는 기능을 만드는 것보다 고객이 요구하는 기능을 만드는 것이 중요합니다. 불필요하게 고품질을 만드는 것을 골드 플레이팅이라고 부릅니다. 고등급과 저품질의 상황을 만들면 안됩니다. 사실 인도물에 대한 품질 수준에 대해서 이해 관계자의 인수 여부와 상관이 있을 수도 있고 없을 수도 있습니다.
회사에서는 일반적으로 정책 상 품질 이슈와 오류는 조치 되어야 합니다. 오류가 있는 상태에서 시스템을 인도하는 것은 올바르지 않습니다. 이해 관계자는 품질 문제가 있으면 인수하지 않을 것입니다. 하지만 품질 문제가 있어도 인수하는 경우도 있습니다. 또한 반대로 품질 문제가 없어도 인수하지 않는 경우도 있습니다. 품질도 중요하지만 품질이 인수 여부와 상관이 없는 경우가 있는 이유는 인도물이 필요한 시기가 있고 품질 문제의 내용에 따라 이해 관계자의 인수 기준이 다를 수 있기 때문입니다.
프로젝트 품질 비용에 대한 이해
품질 비용는 품질 관점에서 결함이나 고장 방지, 품질 요구 사항에 대한 적합성을 판단하고 발견된 결함과 오류를 조치하고 없애며 문제 해결을 위해서 필요한 비용을 언급하는 것입니다. 품질 활동을 수행하기 위해서 발생하는 비용을 품질 비용이라고 하는 것입니다. 품질 비용은 적정 수준의 품질을 확보하기 위해서 투입되는 비용입니다. 품질 관리에서는 중요한 원칙이 있습니다. 결함을 만들지 않고 결함이 있는 제품은 고객에게 전달하지 않으며, 고객에게 전달된 결함이 있는 제품은 빠르게 회수하는 것입니다. 품질 비용은 예방 비용, 평가 비용, 실패 비용이 있습니다. 실패 비용은 내부 실패 비용과 외부 실패 비용이 있습니다.
예방 비용은 제품과 서비스를 개발할 때 결함을 만들지 않기 위한 활동에 투입되는 비용입니다. 결함 예방은 이상적이지만 현실에서 효과를 보기는 힘듭니다. 결함을 예방하는 체계를 갖춘 회사에서 돌아가는 보상은 크다고 볼 수 있습니다. 예방 비용은 제품의 결함과 고장을 방지하기 위해서 예방 비용이 발생하며 품질 관리 시스템의 설계, 구현, 유지 보수와 관련되어 있습니다. 제품과 서비스 요구 사항, 품질 계획 수립, 품질 체계 구축과 관리, 교육이 여기에 해당합니다. 평가 비용은 품질 요구 사항에 대한 적합성을 판단하기 위해서 발생하고 품질과 관련된 측정과 감시 활동과 관련되어 있습니다.
평가 비용은 제품이 출시되거나 서비스 제공 전에 품질 평가를 위해서 투입되는 비용입니다. 평가 활동에는 품질 활동 프로세스의 이행 여부를 확인하는 품질 보증 활동이 있으며, 개발 단계에서 품질 검토 활동, 자재와 부품 입고 검사 활동이 있습니다. 제품과 공급 업체를 선정한 후 품질 성과를 평가하는 활동이 포함됩니다. 내부 실패 비용은 고객이 제품을 받기 전에 결함을 찾고 수정하는 것과 관련되어 있습니다. 작업 결과가 설계 품질 표준에 미치지 못할 경우 발생합니다. 결함 분석, 재 작업과 수리, 그리고 재 작업이 불가능한 제품에 대한 폐기가 여기에 해당합니다. 내부 실패 비용은 프로젝트 팀이 이해 관계자들에게 인도물을 제공하기 전에 발견한 결함을 수정할 때 발생하는 비용으로 볼 수 있습니다.
실제 필드에서는 개발 일정 준수에 대한 부담으로 개발을 먼저하고 프로젝트 후반에 테스트를 통해서 오류를 고치는 프로젝트가 많습니다. 이러한 프로젝트들은 후반으로 갈수록 평가를 통한 결함 수정에 많은 리소스와 비용이 발생하기 때문에 테스트 단계 만을 믿고 테스트를 통해서 품질을 확보하려고 하는 전략은 실패하게 될 가능성이 매우 높습니다. 비효율적인 작업 과정에서 발생하는 자재는 낭비될 수 있습니다.
외부 실패 비용은 고객이 제품을 구입한 다음 발견된 결함이나 문제를 해결하는 것과 관련되어 있습니다. 제품과 서비스가 고객에게 전달되기 전에 결함을 감지하지 못하는 경우에 발생합니다. 수리와 서비스, 보증 요청이 여기에 해당합니다. 불만이 발생할 수 있고 반품이 발생할 수 있으며, 이는 평판의 손상으로도 이어질 수 있는 문제입니다. 가치 최적화를 위해서 가능한 빨리 품질 문제를 찾는데 집중해야 하며 조기 검사와 검토가 올바릅니다. 개발 후반에 품질 문제를 발견하게 되면 이는 더 많은 시간과 비용이 발생할 수 있습니다.
프로젝트 변경 비용의 추가 설명
프로젝트에서는 결함을 수정하기 위한 변경과 결함이 아닌 요구 사항의 변경 때문에 수정하는 경우도 있습니다. 이러한 두 가지 유형 모두 가능하면 빨리 발견되어 조치할 수록 변경 비용이 적게 들게 됩니다. 변경 비용은 결함이 나중에 발견될 수록 이를 해결하는데 들어가는 비용이 더 커진다는 것을 의미합니다. 일반적으로 결함이 있는 구성 요소를 기반으로 설계와 개발 작업이 이미 진행되고 이루어졌기 때문에 이는 더 많은 이해 관계자가 영향을 받게 되고, 프로젝트 생애 주기가 진행됨에 따라서 활동을 수정하는데 들어가는 비용도 증가하게 됩니다.
변경 비용 곡선의 영향에 대응하기 위해서 품질 향상을 위한 프로세스 설계가 필요하게 됩니다. 프로젝트 생애 주기의 각 단계 별로 품질을 달성할 수 있는 방법을 결정하여 적용해야 합니다. 품질 측면에서 사전에 조치를 취하는 것은 프로젝트 생애 주기 후반에 발견된 품질 이슈 해결과 관련된 높은 품질 비용을 방지하는 것을 지원하는 것입니다. 많은 고객에게 영향을 미치는 리콜 문제를 해결하는 것 보다 설계 문서를 해결하기 위한 노력이 더 빠르고 비용이 효율적입니다.
기술 부채는 제대로 개발을 하지 않으면 그 부분이 빚이 되고 그 빚은 향후에 이자가 붙어서 나중에 해당 빚을 갚아야 할 시기에 더 많은 노력과 재 작업이 필요하게 된다는 것을 의미합니다. 이를 은유적으로 표현한 용어로 볼 수 있습니다. 부실한 설계 작업과 단계 별 산출물의 누락, 불충분한 테스트가 진행되고 미뤄진 리팩토링이 있다면 이러한 요소들은 기술 부채를 발생 시키는 요인으로 작용할 수 있습니다. 보엠은 분석 단계의 변경 비용이 있을 때 설계 단계에서의 변경 비용은 이보다 더 크고, 구축 단계에서는 더 크며, 테스트 단계와 생산 단계에서는 기하급수적으로 커지는 것을 의미 있게 주장하였습니다.
프로젝트 후반부로 갈수록 잘못된 오류나 잘못된 요구 사항을 기반으로 이미 많은 작업들을 진행하였기 때문에 수정해야 할 범위가 넓고 수정하기도 어렵기 때문입니다. 변경 비용을 최소화하기 위해서는 개발과 테스트의 간격을 짧게 유지해야 합니다. 또한 핵심 기능을 중심으로 개발하는 것이 좋습니다. 결함과 변경 절감과 관련하여 작게 나누어서 빨리 개발하는 것도 하나의 방법입니다. 핵심 기능 개발에도 반복 주기 개발 방식을 적용하면 결함을 더 빨리 발견하고 더 빠르게 조치할 수 있게 됩니다.