현재 프로젝트의 (미래) 성공이 어떤 것인지 잘 이해하는 것이 항상 모든 프로젝트 시작의 궁극적인 목표가 되어야 합니다.
확실하게 이를 달성할 수 있는 한 가지는 잘 정의된 프로젝트 범위입니다. 그러나 하나를 만드는 것은 사소한 활동이 아닙니다.
프로젝트 범위는 단지 프로젝트 목표 및 이정표, 결과물 목록, 처리해야 할 필수 작업, 열거된 세부 비용, 필요한 리소스 또는 충족해야 하는 약속된 기한에 대한 설명이 아닙니다.
종종 프로젝트가 제공하지 못할 내용을 구체적으로 설명하기도 합니다. 프로젝트가 범위 내에 있는 것 외에는 제공되지 않을 것이라고 주장하고 싶기 때문에 이것은 약간 까다롭게 들릴 수 있습니다. 어쨌든, 일부 사람들은 추가적인 개인 안전을 위해 이를 강조하고 싶어합니다.
모든 이해관계자 간의 합의를 기술하는 문서이며 프로젝트 기간 동안 모든 사람이 이를 참조할 것으로 기대됩니다. 그럼, 그러한 문서의 구성에 어떻게 접근할 수 있는지 살펴보겠습니다.
목차
범위 개발
무엇이든 존재하기 전에 잠재적인 미래 프로젝트 범위를 형성할 많은 양의 아이디어와 콘텐츠를 생성하는 접근 방식이 필요합니다. 이를 위해 사용할 수 있는 몇 가지 기술이 있으며 여기에 그 중 몇 가지 목록이 있습니다.
#1. 브레인스토밍
너무 오래된 방법이라 다들 들어보셨겠지만, 실제로 좋은 브레인스토밍 세션을 보는 것은 20년 전과 마찬가지로 놀라운 일입니다.
이해관계자 그룹을 모아 가능한 한 많은 아이디어를 창출하려는 의도입니다. 그런 다음 한 번 더 검토하고, 필요한 사항을 다듬고, 결과의 우선순위를 지정하고, 마지막으로 프로젝트 요구 사항을 구성하는 최종 진술 세트에 동의합니다.
이러한 토론의 진행자는 아이디어 생성의 자유를 유지하면서 토론이 항상 목표를 향해 전진하고 올바르게 진행되어야 하기 때문에 성공의 매우 중요한 요소입니다.
또한 포커스 그룹을 만들고 기본적으로 동일한 작업을 수행할 수 있지만 단 하나보다 더 많은 이해관계자 그룹을 포함할 수 있습니다. 어쩌면 이해관계자들에게는 뛰어난 역량 영역이 거의 없을 수도 있으며, 이는 의미가 있을 수 있습니다.
#2. 인터뷰
또 다른 접근 방식은 이해관계자를 하나씩 개별적으로 인터뷰하는 전용 일대일 세션을 설정하는 것입니다. 이를 통해 약간의 혼란을 없앨 수 있지만 면접관의 높은 기대치를 설정해야 합니다.
#삼. 설문조사
덜 효과적이지만 여전히 가능한 방법은 답변에 대해 사전 정의된 옵션을 사용하여 몇 가지 상세한 설문 조사를 수행하는 것입니다. 이로 인해 이해관계자로부터 상당한 양의 진정성이 제거됩니다. 하지만 아마도 당신은 다른 사람들보다 옵션을 더 잘 알고 있을 것입니다. 그러면 이것이 다시 이해가 될 것입니다.
#4. 벤치마킹
시작하려는 프로젝트와 유사한 여러 프로젝트의 프로젝트 범위 결과를 조사하고 수집할 수 있습니다. 그런 다음 모범 사례와 잠재적인 과제를 수집하면 전체 프로세스를 단순화할 수 있습니다. 또한 특별히 돌파구가 필요하지는 않지만 그것이 궁극적인 목표라면 그렇게 하십시오.
#5. 프로토타이핑
이것은 매우 흥미로운 방법이지만 아마도 충분히 자주 사용되지는 않을 것입니다. 최종 프로젝트의 모형을 만들고 이 (이미 작동하는) 프로토타입에서 바로 요구 사항과 잠재적인 문제까지 식별하는 작업을 진행합니다. 이를 통해 프로젝트가 시작되기 전에 문자 그대로 접할 수 있는 정보를 얻을 수 있습니다.
#6. 작업분류체계(WBS)
WBS는 프로젝트의 향후 작업을 구성하는 방법에 대한 구식 기술입니다. 이것의 문제는 처음부터 프로젝트 중에 필요한 모든 작업을 알고 예상해야 한다는 것입니다.
당연히 이런 경우는 거의 없으므로 프로젝트 중에 WBS가 업데이트, 재작업 또는 리팩터링됩니다. 그래서 그것은 기원의 목적을 잃어버린 것 같습니다. 그럼에도 불구하고 프로젝트에서 수행할 것으로 예상되는 모든 작업을 나열하여 프로젝트 범위를 정의하는 방법은 유효한 방법입니다.
프로젝트 범위가 중요한 이유는 무엇입니까?
프로젝트 범위는 프로젝트의 경계를 정의하고 프로젝트가 제공할 내용에 대한 기대치를 설정합니다. 프로젝트 범위가 중요한 몇 가지 구체적인 이유는 다음과 같습니다.
#1. 명쾌함
결과물이 어떤 모습일지에 대한 명확한 이해가 필수적입니다. 이러한 비전이 없으면 누구도 좋은 것이 어떤 모습일지 명확하게 말할 수 없습니다.
#2. 기대치 설정
범위는 팀, 이해관계자 및 사용자에 대한 기대치를 설정합니다. 이는 향후 갈등이나 오해를 제거하거나 (적어도) 크게 최소화합니다. 이는 코너 상황에서 무엇을 해야 할지 정의합니다(아무도 일어날 것이라고 가정하지 않지만 당연히 일어날 것입니다).
#삼. 지침
좋은 프로젝트 범위는 의사결정에 대한 지침을 정의합니다. 궁극적인 목표는 모든 결정이 프로젝트 목표에 부합하도록 하는 것입니다.
지침은 또한 프로젝트가 원래 경계 내에 머물고 그 이상으로 확장되지 않도록 도와줍니다.
#4. 자원 관리
프로젝트 범위는 프로젝트를 완료하는 데 필요한 작업과 결과물을 식별하여 자원을 관리합니다. 이는 결국 적절한 리소스 할당을 보장하는 데 도움이 됩니다.
프로젝트 범위의 구성요소
이제 범위 개발을 시작하는 방법과 범위 개발이 필요한 이유를 알았으므로 좋은 프로젝트 범위에 포함되어야 하는 구성 요소가 무엇인지 이해하는 것이 중요합니다.
- 이는 프로젝트의 전반적인 목표와 목적, 그리고 프로젝트가 달성할 정확한 목표를 설명합니다.
- 프로젝트의 예상 결과의 일부인 문서, 서비스 또는 완제품 목록입니다.
- 프로젝트 일정이 특정 기간에 대한 것임에도 불구하고 프로젝트 타임라인에는 전체 프로젝트의 올바른 진행 상황을 선언하는 주요 시간 하이라이트 또는 체크포인트가 있습니다. 이들의 정확한 정의는 이정표가 달성되면 프로젝트가 제대로 진행되고 있음을 보장합니다.
- 이는 범위 내에 있는 것과 잠재적으로 범위를 벗어나는 것에 대한 명시적인 정의입니다. 범위 외 목록에 포함하는 것이 공정하며, 특히 일부 이해관계자가 실제로 범위 내에 있다고 가정할 수 있는 항목을 포함하는 것이 좋습니다.
- 프로젝트에 대한 모든 가정을 문서화하십시오. 예를 들어 프로젝트 기간 동안의 타임라인, 마일스톤, 예산 예측 또는 리소스 할당이 포함될 수 있습니다. 또한 특정 결과물에 대한 콘텐츠 관련 가정도 포함될 수 있습니다.
- 프로젝트 진행에 영향을 미칠 수 있는 제약 조건이 있는 경우 여기에 나열하세요.
- 실제 문제가 발생할 경우 프로젝트를 위태롭게 하거나 큰 영향을 미칠 수 있는 잠재적 위험을 식별해야 합니다. 더욱 중요한 것은 이러한 위험을 프로젝트에서 어떻게 완화할 수 있는지에 대한 전략을 정의하는 것입니다.
- 이 섹션에서는 역할 및 책임과 함께 프로젝트에 참여하는 모든 주요 이해관계자를 식별하려고 합니다.
- 이는 정확히 언제 결과물이 성공 또는 완료로 간주되는지 정의하는 중요한 섹션입니다. 프로젝트가 완료된 것으로 표시하려면 정확히 무엇을 이행해야 합니까?
프로젝트 범위 생성을 위한 템플릿
이 모든 것을 하나로 모아 프로젝트의 전체 수명을 정의하는 프로젝트 범위를 성공적으로 생성하는 방법에 대한 템플릿을 형성합니다. 다음은 소프트웨어, 앱 또는 웹 개발 프로젝트에 대한 프로젝트 범위 기술서를 작성하는 단계별 방법입니다.
➡️ 위에서 설명한 개발 기술 중 하나를 사용하여 프로젝트 목표를 정의합니다. 전반적인 목표를 정의하는 것부터 시작한 다음 특정 요구 사항으로 전환하세요. 여기에는 소프트웨어나 웹사이트가 최종 결과로 무엇을 달성해야 하는지에 대한 정의가 포함되어야 합니다.
➡️ 제품, 문서, 서비스 또는 프로젝트 중 성공 척도가 적용되는 중요한 활동과 같은 프로젝트 결과물을 식별합니다. 여기에는 소프트웨어 또는 웹사이트의 모든 기능 목록이 포함될 수 있습니다.
➡️ 프로젝트 범위에 포함되는 것과 포함되지 않는 것을 포함하여 프로젝트의 경계를 정의합니다. 여기에는 프로젝트의 제한 사항 및 제외 사항에 대한 명확한 설명이 포함되어야 합니다.
➡️ 자원, 일정 또는 예산에 대한 가정과 같이 프로젝트에 유효한 프로젝트 가정을 식별합니다.
➡️ 프로젝트에 영향을 미칠 수 있는 프로젝트 제약 조건을 정의합니다. 여기에는 가정 섹션과 유사한 영역도 포함될 수 있지만 이번에는 제한적인 관점에서 볼 때(이전에 합의한 것 대신에 이것이 발생하거나 저것이 발생하면 어떻게 될까요?)
➡️ 프로젝트 리스크와 이를 극복하기 위한 전략을 파악합니다. 리스크는 기본적으로 아직 개발되지 않은 문제이므로 실제 문제가 되기 전에 해결하는 것이 좋습니다.
➡️ 역할과 책임을 포함하여 프로젝트에 관련된 프로젝트 이해관계자를 나열합니다.
➡️ 프로젝트가 완전하고 성공적인 것으로 간주되기 위해 충족해야 하는 프로젝트 승인 기준을 정의합니다. 이는 기본적으로 프로젝트의 성공적인 결과가 무엇을 의미하는지에 대한 포괄적인 설명입니다.
프로젝트 범위 생성 모범 사례
이 템플릿을 따르고 다음 프로젝트를 위한 완벽한 범위를 구성하는 동안 과거의 몇 가지 경험을 고려하는 것이 항상 좋습니다.
결국 이미 많은 프로젝트가 전달되었고 당연히 그렇습니다. 이 주제는 이미 광범위하게 탐구되었으며 따라서 모든 새로운 프로젝트 정의는 성공해야 한다고 가정할 수 있습니다.
이것이 실제로 진실과 거리가 멀다는 것을 아는 것은 흥미 롭습니다. 그럼에도 불구하고 오늘날에도 성공하지 못한 엄청난 양의 프로젝트가 있습니다. 그 이유는 여러 가지가 있을 수 있지만 그 중 하나는 확실히 프로젝트 범위에 대한 정의가 부족하다는 것입니다. 따라서 신뢰할 수 있는 프로젝트 범위를 만들기 위한 몇 가지 모범 사례는 다음과 같습니다.
#1. 이해관계자 참여
가능한 한 빨리 모든 이해관계자를 참여시키십시오. 가정이 적을수록, 실제 사실이 많을수록 프로젝트에 더 좋습니다. 주요 이해관계자의 아이디어와 바람을 제쳐두면 프로젝트 기간 동안 심각한 문제가 발생할 가능성이 있습니다.
대부분은 프로젝트의 승인 기준 단계에서 밝혀질 것입니다. 이는 프로젝트의 원래 일정 내에서 문제를 해결하기에는 최악의 시기입니다.
#2. 템플릿과 프로세스를 고수하세요.
덜 견고한 프로세스일수록 혼란과 예측 불가능성을 더 많이 받아들입니다. 프로세스는 프로젝트에 구조를 제공합니다. 템플릿은 양식 기대치를 암시적으로 정의하므로 결과물이 더 빨리 승인될 가능성이 높아집니다.
#삼. 구체적이고 측정 가능해야 합니다.
모든 이해관계자에게 친숙한 잘 알려진 언어를 사용합니다. 감정이나 모호한 진술이 아닌 구체적인 사실로 소통하세요. 어떤 일이 원하는 대로 진행되지 않을 경우 누군가의 등을 덮을 수 있는 방식으로 진술을 작성하지 마십시오. 공식이 개방적이고 정직하며 모든 부분에 대해 측정 가능하다면 이는 좋은 관계에 대한 최고의 확신입니다.
#4. 협업적 접근 방식
결정이 필요할 때마다 협력적인 접근 방식을 사용하십시오. 그들의 입장을 표현하는 경우에도 가능한 한 많은 당사자와 이해관계자를 참여시키십시오. 그런 다음 결론을 내릴 때 이를 고려하여 결론을 내릴 수 있습니다. 모든 사람의 비전과 관점은 어떤 면에서든 중요합니다. 따라서 이해관계자가 당신을 이해하기 전에 먼저 이해를 구하십시오.
#5. 자주 검토하고 업데이트하세요
프로젝트 일정 내에서 가능한 한 빨리 범위를 수정하고 업데이트합니다. 그러한 변화가 나중에 적용될수록, 그것이 가져올 영향을 해결하는 것이 더 어려워질 것입니다. 잠재적인 문제가 스스로 사라지는지 확인하기 위해 기다리는 것은 결코 올바른 전략이 아닌 것으로 판명되었으므로 적용 가능한 모든 상황에서 정반대의 작업을 수행하십시오.
좋은 프로젝트 범위의 이점
따라서 위의 모든 좋은 조언을 따르고 견고한 템플릿과 프로세스를 만들고 모든 이해관계자를 참여시키고 정확하게 구조화된 프로젝트 범위를 구성했습니다. 지금 이 모든 좋은 노력과 노력의 이점이 무엇인지 묻는다면, 조만간 알아차릴 수 있는 실제 이점 중 일부는 다음과 같습니다.
첫째, 프로젝트 기획에 있어 큰 개선을 기대할 수 있습니다. 어쨌든 이미 계획에 상당한 시간을 투자했기 때문에(예: WBS 정의) 프로젝트 중 모든 계획 활동에 더 잘 대비할 수 있습니다.
또한 내부 팀 내부뿐만 아니라 모든 당사자와 이해관계자 간에 더 나은 커뮤니케이션을 볼 수도 있습니다. 간단히 말해서, 모든 사람은 같은 생각을 갖고 있으며 모두에게 동일한 명확한 목표를 염두에 두고 있습니다. 사람들이 같은 말로 성공을 설명한다면 이는 귀하가 포트폴리오 내에서 동기화되어 있음을 의미합니다.
계획되지 않은 위험의 감소는 좋은 프로젝트 범위의 또 다른 큰 부작용입니다. 프로젝트 범위 내에서 위험을 정의하고 완화하는 데 더 많은 노력을 기울일수록 예상치 못한 또 다른 위험 시나리오가 발생할 가능성은 줄어듭니다. 또한 현재 상황에서 요구되는 경우 프로젝트 계획에 대한 변경 사항을 동적으로 실행할 수 있는 더 나은 위치에 있습니다.
다음으로 자원 관리가 개선되었습니다. 좋은 계획은 프로젝트의 올바른 단계에 적합한 인력을 최적으로 할당하는 결과를 가져옵니다. 이것은 마술이 아니라 좋은 프로젝트 계획의 자연스러운 암묵적 결과입니다.
또 다른 직접적인 부작용은 이해관계자가 만족하고 만족도 측정이 높은 수치에 도달한다는 것입니다. 사람들은 프로젝트 작업을 좋아할 것이며 이것이 옳은 일이라고 느끼기 때문에 프로젝트에 더 창의적인 시간을 투자할 것입니다. 정말 의미가 있을 것입니다. 분명히, 잘못된 프로젝트 범위 정의는 어쨌든 잘 작동하지 않기 때문에 아무 것도 중요하지 않다는 의견으로 직접적으로 이어집니다.
마지막으로, 프로젝트 결과의 품질이 향상됩니다. 결과는 프로젝트 일정 동안 실행한 활동의 직접적인 결과입니다. 활동에 좋은 계획과 설명이 있으면 결과가 주도권을 따를 가능성이 훨씬 더 높습니다.
결론
거기 있어요. 프로젝트 범위 생성에 접근하는 방법에 대한 구체적인 계획입니다. 분명히 이것이 이 작업을 성공하는 데 필요한 전부는 아니지만 바라건대 이를 통해 올바른 길을 보여줄 몇 가지 중요한 지침이 제공될 것입니다.
다음으로, 프로젝트를 원활하게 시작하기 위한 최고의 프로젝트 헌장 템플릿을 확인하세요.