실패를 보장하는 7가지 요소

직원을 높이 평가하거나 복잡성을 과소평가하거나 신화에 의존하지 마십시오. 이러한 요소와 기타 요소를 고려하면 프로젝트는 반드시 실패합니다.

그거 알아? 몇 주 또는 몇 달 동안 프로젝트 관리자는 자신의 프로젝트에 대해 보고합니다. 물론 클래식한 상태 램프도 빼놓을 수 없습니다. 그리고 이것은 지속적으로 녹색입니다. 모든 것이 정상입니다. 그런데 어느 날 신호등이 갑자기 빨간불로 바뀝니다! 결과적으로 책임자에게 매우 불쾌한 처리 프로세스가 시작됩니다. 대부분의 경우 첫 번째 질문은 범인에게 적용되고 두 번째 질문은 원인에 적용되며 그 다음에는 가능한 해결책에만 전념합니다.

다음은 거의 실패를 보장하는 7가지 일반적인 요소입니다.

요소 1: 인적 요소 무시

수년 동안 개발자, 프로젝트 관리자, 코치 및 위기 관리자로서 저는 대인 관계 긴장이 IT 프로젝트를 구현하는 데 가장 큰 장애물임을 발견했습니다. 반대로, 직원 간의 케미스트리는 정확하고 개방적이고 내결함성 있는 분위기가 있으며 모든 어려움에 대한 해결책을 찾을 수 있습니다. 심지어 중요한 상황에서도 마찬가지입니다.

갈등을 피하는 것은 인간의 본성입니다. 따라서 사람들(예: 프로젝트 관리자)이 너무 오랫동안 완전히 무시하거나 외면하는 것은 자연스러운 일입니다. 그러나 갈등은 대개 저절로 해결되지 않습니다. 절제와 적어도 변화 또는 해결책에 대한 관점으로 연구가 필요합니다.

때때로 직원의 새 직장과 같이 큰 영향을 미치는 것은 작은 일입니다. 그러나 프로젝트에 다시 평화를 가져오려면 팀 개편과 같은 더 큰 비용이 필요한 경우가 많습니다. 그러나 최악의 대안은 인적 요소를 무시하는 것입니다.

요인 2: 너무 크게 생각하거나 너무 작게 만든다

일부 회사는 프로젝트를 인수합니다. 그들은 복잡성, 위험, 막대한 인력 및 물질적 노력을 과소평가합니다. 비용에 관계없이 우리 조직에서 직원이 100명인 프로젝트를 관리할 수 있습니까? 작업, 회의실, 네트워크 용량, 개발 서버 등이 충분한가요?

회사는 지속적 통합/전달을 포함한 개발 및 테스트 트랙에 대한 대규모 애자일 개발 팀의 요구 사항을 충족할 수 있습니까? 이러한 질문을 예측했다면 비즈니스 사례를 현실적으로 계산했어야 합니다. 저는 거대한 프로젝트가 시작되기 직전에야 결과 시스템이 회사의 비즈니스 모델에 적합하지 않기 때문에 실제로 필요하지 않다는 것이 분명해지는 것을 여러 번 보았습니다. 불행히도 이전에는 아무도 그것을 알아차리지 못했습니다.

또 다른 인식 가능한 패턴: 주인공은 예를 들어 명성이나 직원 활용을 위해 SW를 구현하기를 절대적으로 원하고 비용을 무시할 수 있는 것으로 계산합니다. 후임 프로젝트 관리자가 의사 결정 기관의 맥락에서 불일치를 제시할 만큼 강력하지 않으면 위기 가능성이 높아집니다.

요소 3: 견적 및 계획에 100% 의존

널리 퍼진 신화는 견적 및 계획의 신뢰성입니다. 프로젝트의 개념은 고유성에 의해 정의됩니다. 이미 비슷한 프로젝트가 있었을 수도 있지만 원칙적으로 회사는 모든 프로젝트에서 새로운 영역에 진입하고 있습니다. 즉, 견적은 현재 프로젝트에 대한 제작자의 경험과 적응 기술만큼만 좋을 수 있습니다.

그러나 계획에는 자발적인 이벤트, 요구 사항 측면의 변경 사항, 기술 또는 예상하지 못한 위험 요소가 포함될 수 없습니다. 궁극적으로 견적과 그에 따른 계획은 미래에 대한 내기에 지나지 않습니다! 이 사실을 받아들이는 것이 첫 걸음입니다. 규율, 용기 및 시스템은 발생할 수 있는 위기를 예방하거나 완화하는 데 도움이 됩니다.

요인 4: 마법의 PM 삼각형이 지속적으로 무시됨

컴퓨터 과학, 첫 학기, 첫 강의 프로젝트 관리를 공부했습니다: "마법의 PM 삼각형" . 관리 작업에 관심이 있는 사람은 아주 일찍부터 이 삼각형의 법칙을 접하게 됩니다. 이들은 세 가지 매개변수 중 하나의 변화가 필연적으로 다른 매개변수 중 적어도 하나의 결과로 이어진다고 말합니다.

그러나 이러한 법률은 실제로 무시하기에는 너무 행복합니다. 견적 및 계획의 맥락에서 이미 언급했듯이 프로젝트는 다소 독특하며 계획되지 않은 영향의 가능성이 매우 높습니다. 그렇기 때문에 조만간 거의 모든 프로젝트에서 책임자가 이러한 영향에 반응해야 합니다. 그러나 모든 매개변수가 고정되어 있다면, 즉 고객이 계속해서 시간, 예산 및 콘텐츠 준수를 요구한다면 실패는 시간 문제일 뿐입니다.

요소 5: 모든 것의 문서화

Franz Beckenbauer 이후 무료 : "우리는 그것을 고전이라고 부릅니다!" 점점 더 많은 회사가 애자일 절차(대부분 스크럼)에 의존하고 있지만 조직과 프로젝트는 여전히 발견되고 있으며, 이는 생성할 소프트웨어보다 광범위한 문서를 더 중요하게 여깁니다. 이것은 특히 대규모 프로젝트에서 높은 위험입니다. 종종 수천 페이지에 대한 컨설턴트 및 부서 전문가의 사냥은 종종 몇 달 또는 심지어 몇 년 동안 작동했으며 나중에 SW의 다른 팀에서 번역하게 됩니다.

문서가 광범위할수록 실현 시간이 길어지고 SW가 사용자의 실제 요구 사항에 부합할 가능성이 낮아집니다. 시장의 변화에 ​​대한 대응은 불가능하거나 엄청난 노력과 시간적 양보가 있어야만 가능합니다. 문서는 제품을 제거할 수 있는 기준을 제공합니다. 불행하게도 쓰여진 내용이 반드시 명확하지는 않으며 결과는 원래 생각했던 것과 다르게 생각됩니다. 부서 직원과 최종 사용자로부터 "오, 아주 다르게 상상했습니다!"라는 말을 몇 번이나 들었습니다. .

요인 6: 균형 잡힌 프로젝트 조직이 없음

20명의 개발자와 1명의 기술 담당자로 구성된 팀? 이 구조가 조만간 실패할 것임을 인식하기 위해 전문 지식이 필요하지 않습니다. 폭포수든 애자일이든 프로젝트 초기에는 개발자가 프레임워크나 환경 설정으로 바쁘기 때문에 여전히 작동할 수 있습니다. 그러나 직원들은 곧 질문을 할 것입니다. 집중적인 전문 지원이 필요합니다.

단일 주제 전문가는 이러한 시간적, 정서적 압력을 결코 견딜 수 없으며 인력 측면과 구현 프로세스를 통해 지원이 필요합니다. 그러나 인사 병목현상을 소통의 제약으로 대응하는 것은 매우 안 좋은 생각이다.

또한 대중적인 아이디어이자 일반적인 관리 오류의 척도에 가장 앞선 것입니다. 직원이 개발자의 질문을 수집하고 기술 담당자와 논의한 다음 답변을 반환합니다. 이러한 방식으로 탁월한 병목 현상을 만들고 매우 높은 오류율을 유발하며 개발을 크게 지연시킵니다.

요소 7: 개구리를 천천히 데우기

이 이야기를 아십니까? 물이 담긴 냄비에 개구리를 넣고 요리할 때까지 계속 가열하면 개구리는 탈출을 시도하지 않습니다. 뜨거운 물에 직접 던지면 즉시 튀어 나옵니다.

최근 몇 년 동안 저에 대한 가장 중요한 지식 중 하나는 IT 프로젝트 직원이 실명 기간이 길어짐에 따라 만료된다는 것입니다. 일단 확립된 프로세스는 아마도 회고에서 의문을 가질 수 있지만 실제로 과감한 경우는 거의 없습니다. 사람들이 변화에 반응하는 능력은 프로젝트 기간에 비례하여 사라집니다.

따라서 (거대한) 프로젝트에서는 이전에 관여하지 않은 외부 컨설턴트의 산발적 조명(상태 확인)을 권장하여 잠재적으로 대상이 지정되지 않은 누출 경로를 발견합니다. 적어도 본격적인 위기를 인지하고 나면 기존 인력만으로는 턴어라운드를 만들어내기가 거의 불가능하다.

그래서 가능할 수 있습니다

설명된 일반적인 관리 오류는 SW 개발 프로젝트의 성공적인 완료를 방해하거나 방해하는 행동 패턴의 개인적인 적중 목록 중 일부에 불과합니다. 멀리서 보면 프로젝트 초기 단계에서 문제를 인식하고 수정하는 것이 쉽다는 인상을 받을 수 있습니다. 그러나 아마도 움직일 수 없는 프레임워크 조건과 언급된 무지는 종종 올바른 결정을 내리기 어렵게 만듭니다. Standish Group의 통계는 처음에 올해가 해마다 입증된다고 말했습니다.

프로젝트에 문제가 있는 경우 외부 위기 관리자가 민감성과 프로젝트 이력의 안정 없이 객관적으로 분석하고 조치할 수 있는 것이 좋습니다. 프로젝트에 사람들의 의견을 듣는 전문가의 참여만으로도 이미 긍정적인 효과를 낼 수 있습니다. 적절한 조치의 선택은 또한 변환과 최종 턴어라운드에 성공합니다.