[Skill set] 답을 위해 던져야 할 질문들 @ 프로젝트

이전 Article

[Skill set] 질문이 나오면, 답 또한 나온 것! feat. 문제정의

 

그렇다면,

어떤 질문을 던져야 문제를 밝히고,

결과를 이끌어낼 수 있을까요?

대표적으로 8개가 있습니다.

 

#1. Main Issue : 뭐가 문제인가?

가장 먼저 던져야할 질문은

"핵심 이슈가 무엇인가?"

과녁이 세워졌다면, 이미 반은 된겁니다.

핵심이슈는 그때그때 다르겠으나,

공통되게 갖춰야할 조건을 말해보면

1) 얻고자 하는 것(목적),

2) 그것을 얻었다고 할 수 있는 판단기준

이 2가지가 포함되어야 합니다.

 

예를 들자면, "IT투자의 필요성을 전달하여,

올해 내 프로세스 현행화 프로젝트를 착수시킴"라 하면

앞 부분이 얻고자 하는 것을,

뒷 부분으로 그것이 성공했음을 증명할 기준(사건)을

알 수 있겠죠.

 

#2. 보고대상/이해관계자 : 누가 타겟인가?

컨설팅이든, 다른 서비스든 고객이 있습니다.

그리고 고객은 직접적인 평가를 주는 그룹과,

평가에 간접적으로 영향을 주는 그룹으로 나뉘죠.

사람을 상대로 하는 서비스 중 대표적인 것이 컨설팅

1) 보고대상 = 의사결정권자

주로 회사 or 담당 조직의 최고 임원급으로

직접적으로 프로젝트를 승인했고, 

평가와 함께 후속 프로젝트를 결정할 사람입니다.

 

당연히 최우선 고객이며, 

요구사항 또한 최우선적으로 경청 및 충족시켜야합니다.

즉, 요구사항이 Capa를 넘어 다 수행하지 못할 때,

가장 마지막까지 사수해야할 요구사항이란 뜻입니다.

 

2) 미팅/보고 참석자 = 이해관계자

프로젝트를 직접 평가하는 역할까진 아니지만,

각자의 의견이 프로젝트 방향, 내용에 영향을 미치거나

의사결정자의 판단에 영향을 끼칠 수 있는 사람입니다.

 

주로 보고 또는 실무 미팅에 참석하는 고객쪽 인원으로

팀장 이하 실무진 급이라고 보면 비교적 명확할 것입니다.

 

#3. 선도사례/참고자료

가장 먼저 확보하고, 검토되야할 것은

프로젝트와 관련된 "바로 직전 프로젝트 or 논의자료"입니다.

이미 회사에는 많은 정보와 꿀팁이 있습니다. 찾는게 문제

구두 논의가 흔한 초기 문제정의 단계에서 

비교적 문서화되어 있어 명확히 정보파악이 쉬우며,

당시 목적, 결과물, 진행방안, Lessons Learned 등

참고할 만한 것들이 가장 많고, 제일 적합하기 때문입니다.

 

 그뒤로 파악되어야 할 것들은 크게 2가지 관점에서

1) 고객 도메인 : 동일 or 유사업종의 고객사 대상의 프로젝트

2) 프로젝트 유형 : 유사한 문제(질문) 해결을 했거나,

                              산출물을 도출한 프로젝트

 

#4. 결과물(Output)

이따금 컨설팅은 Paper Work다 라는 말을 듣기도 합니다.

맞습니다. Paper Work

다만 그 Paper가 의미있냐가 중요하겠죠.

메시지가 논리정연히, 행동유발하는 형태까지 되도록

 

Paper(컨설팅 보고서)가 의미있기 위해 크게 3가지가 필요합니다.

1) Message : 고객의 의사결정에 대한 제언 or 전략을 제시

2) Insight : 그런 Msg가 나온 이유가 무엇인지 논리정연하게,

                 근거자료와 분석결과와 함께 전달되어야 합니다.

3) How-to : 실제 성과창출로 이어지도록 방법까지 나와야 합니다.

                  해야할 것(과제), 순서(우선순위), 타이밍(로드맵)까지...

 

#5. 성공 판단 기준

프로젝트의 성공여부가 애매모호한 경우가 굉장히 많습니다.

정량적 수치로 판별되면 좋겠으나, 그런 경우는 거의 없죠.

그땐, 정성 기준이라도 구체적으로 만드는 지혜가 필요합니다.

평가표가 없다면, 그걸 만드는 것까지도 과업입니다.

 

1) 의도했던 (고객사의) 행동을 유발했는가?

- 프로젝트가 만족스러웠다면, 후속 프로젝트로 연결되는 경우가 흔하고

- 프로젝트 내용에 따라 연관된 투자(사업화)가 발생하기도 합니다.

- 보고 받은 사람이 이를 본인 보스에서 보고하는 것 또한 

  굉장히 긍정적인 Signal이라도 볼 수 있죠.

 

2) Impact 있는 사건이 발생했는가?

보고를 다 받은 뒤, 의사결정권자(임원)이 극찬을 했다던가,

프로젝트를 의뢰했던 부서측에서 Thank you Mail을 보내는 등의

이벤트는 업계에서 줄수 있는 (비물질적) 좋은 보상 중 하나입니다.

 

#6. 스케쥴

프로젝트는 제한된 시간에 목표로한 문제를 해결하는 일련의 업무묶음 입니다.

특히 "시간과의 싸움"이란 면이 실제 투입되면 부각되기도 하죠.

몇달안에 결과를 내야하는 것이 프로젝트...

시간관리를 잘하기 위해 문제정의에서는

1) 마일스톤 세팅
   : 착수/중간/종료 등 보고일정, 워크샵, 정기 실무회의 등

     다른 기간의 Task에 영향을 주거나, 하루 이상 드는 경우를 파악해야 합니다.

 

2) 이해관계자 참여 확보

: 이해관계자의 경우, 많은 경우 본인의 과업을 프로젝트 결과물을 통해

해결하려고 시도하는 경우가 많습니다. 이것이 추가 요구사항으로 나오기도 하고요.

그 외에도 별도의 이슈였던 이해관계자의 과업이 프로젝트에 영향을 주기도 하죠.

 

단순히 방어적으로 대응하는 것은 그리 스마트한 방법이 아닐 것입니다.

그보다, 그들과 공동의 목표를 세우고 이를 위해 서로 할일을 분배하고

서로 도움을 주고 받는 관계를 형성하는 것을 적극 추천드리고 싶습니다.

 

#7. 해결 범위/제약요건

"어디까지 다룰 것인지, 어떤 수준까지 다룰 것인지"를 정리합니다.

기준선(Base line)이 잘 그여질수록 혼란이 없고, 몰입 또한 쉬워지겠죠.

선 긋기에 명확히해야, 집중할 대상이 드러납니다.

 

이를 위해 몇가지 조언드리자면,

- 범위는 매출증대, 고객 확보 등 Biz 목표와 같은 추상적인 표현보다는

               조직/시스템과 같이 단순하고, 명확한 근거로 잡혀야 합니다.

- 프로젝트 기간 및 범위, 목적에 따라 집중하지 않은 영역의 이슈로 인해

  프로젝트 내용이 바뀌는 경우가 있습니다. 그때는 어떻게 해야할까요?

 

  그저 인정하고 가는 수밖에 없습니다. 

  다만, 이를 미리 파악하고, 해결불가능하며 수용할 대상이라고 합의해야 합니다.

  모르고 당하는 것과 알고 있다가 상황발생을 직시하는 것은 큰 차이가 있습니다.

 

 그러기에 모르고 당하는 경우가 없도록,

추가로 요구할만한 이슈는 미리 체크하고, 발라내는 작업이 필요합니다.

*프로젝트 팀 뿐만 아니라, 고객쪽에서도 함께 체크할 것을 적극 권유

 

#8. 스토리라인

구슬도 꿰어야 보배죠?

문제정의에서 부터 스토리를 갖춰 정리하면 뒤에 편합니다.

고객에게 성공적으로 전달되야, 성공입니다.

스토리 유형은 프로젝트 목적에 따라 크게 2종류로 나뉘는데

 

1) 전략 / 제안 중심이라면?  "Why ▷ What  ▷ How"

현재 고객사가 문제의식이 크지 않은 상황이라면?

그 문제의 규모와 심각도를 먼저 짚어주면서 집중시키는 것이 우선입니다.

• Why : 놓치고 있는 가치 or 원하는 바가 존재함
• What : 해결하기 위해서 "무엇이" 필요함
• How : 그걸 확보하기 위해 어떤 과정을 거치겠음

 

2) 이행 / 운영방안 중심이라면? "What ▷ Why ▷ How"

고객이 과제를 이행하는 상황이라면?

지금 하는 일(개선)을 어떻게 더 잘할 수 있을지에 집중해야죠.

• What : 어떤 문제로 이러저러한 현상이 발생함
• Why : 그것의 근본 원인은 "ㅇㅇ" 때문이었음
• How : 근본원인 해결을 위해 어떤 방법을 쓰겠음