Где заканчивается «Управление изменениями» и начинается «Сбой проекта»?

Question

Я недавно вступил в мини-спор с моим боссом по поводу "провала проекта". Через три года наш проект по переносу кодовой базы на новую платформу (проект, которым я занимался в течение 1,5 лет, но руководитель моей команды занимался всего несколько месяцев), начал свою работу. Он вместе со старшим руководством моей компании и клиента (я один из тех ужасных консультантов, о которых вы так много слышали. Моя работа - «Аутсорсинг приложений») объявил проект успешным. Я не согласился, заявив, что старые презентации, которые я обнаружил, показали, что по сравнению с первоначальным графиком задержка развертывания лучше всего измеряется в месяцах и потенциально может измеряться годами. Я объяснил, что я знаю о неудаче проекта, а также об исследованиях и статистике частоты неудач. Он ответил, что это все академические круги и что ни один из проектов, которыми он руководил, не удался, благодаря чудесам управления изменениями / рисками - что, похоже, сводится к объяснению задержек и переоценке графика на основе новых данных.

Может быть, консалтинг, подобный этому, отличается от других проектов, но кажется, что это просто неудача, заключенная в более красивое название, чтобы избежать клейма неудачного выполнения в срок, в рамках бюджета или с полной функциональностью. Тот факт, что он объяснил, что моя компания отдала часы работы бесплатно, чтобы завершить проект в рамках максимально ограниченного бюджета, говорит о многом.

Итак, я спрашиваю вас:

• Что такое управление изменениями и как оно применяется к проекту?
• Где заканчивается «управление изменениями» и начинается «провал проекта»?

---

@ Shog9:
Я не спрашивал об игре с консультантами, особенно потому, что в этом случае я представляю консультантов. Я искал мнения о том, когда проект следует считать «проваленным», независимо от того, была ли наконец реализована необходимая функциональность . .
Я ищу разницу между «это на самом деле немного сложнее, чем мы думали, и это будет еще неделя», что, как я ожидаю, несколько типично, и «провалом проекта» - как бы вы ни хотели определить провал. Есть ли разница? Является ли этот незначительный уровень проскальзывания расписания статистическим «провалом проекта»?

Answer 1

Я думаю, что в большинстве случаев мы, разработчики, забываем о том, что все мы делаем, в конце концов, о бизнесе.

С этой точки зрения проект не является провалом, пока клиент готов за него заплатить. Все зависит от клиента, некоторые клиенты имеют больше терпения и лучше понимают риски разработки программного обеспечения, другие просто не окупятся, если есть существенная задержка.

В любом случае, по поводу вашего вопроса. Всякий раз, когда вы развиваете проект, возникают риски, возможно, вы планируете завершение проекта на определенную дату, но это займет примерно на шесть месяцев больше, чем вы ожидали. В этом случае вы должны сбалансировать то, что вы уже потратили, и то, что вы должны получить, с рисками, которые вы принимаете. На самом деле существует целая наука, называемая «принятие решений», которая изучает ее на уровне программного обеспечения, поэтому ваш начальник не ошибается вообще.

Давайте посмотрим на некоторые вопросы. Готов ли клиент ждать проекта? Готов ли он взять на себя определенные перегрузки? Даже если он этого не сделает, стоит ли завершать проект, принимая на себя дополнительные расходы, а не выбрасывать всю уже проделанную работу? Может ли компания предположить, что уже потеряно?

Реальный ответ на вашу проблему лежит за этими вопросами. Вы не можете установить точку и сказать, здесь, если проект не завершен к этому времени, то это провал. Что касается вашей конкретной ситуации, кто знает? Ваш босс, вероятно, имеет больше информации, которая у вас есть, поэтому вы должны рассказать ему, как продвигается проект, сколько он займет и сколько будет стоить (в часах / человек, если хотите)

Answer 2

Если цели не были четко определены в начале проекта, нет четких границ между «успехом» и «провалом». Часто проект имеет разную степень успеха / неудачи.

Для некоторых просто получение некоторых концепций в коде будет успешным, в то время как другие могут измерять успех как возврат всех инвестиций и получение прибыли. Двумя известными способами неудач являются проскальзывание графика и ухудшение качества, но в реальности люди, кажется, не заботятся о них.

Простые способы ускорить график - позволить менеджерам отправлять запросы в любое время (черт побери) и программистам писать то, что они считают правильным (ковбойское кодирование). Процесс управления изменениями, такой как планирование спринта scrum и планирование игры XP - вот некоторые примеры. Тезисы - некоторые из попыток руководства и разработчиков вовремя доставлять надежные продукты. Если какая-либо из сторон не заинтересована в надежных или своевременных, управление изменениями не будет полезным.

Answer 3

Что такое управление изменениями и как оно применяется к проекту?

Управление изменениями - это утверждение и передача изменений в проект до того, как они произойдут. Если кто-то в вашем проекте (пользователь, спонсор, член команды ... кто угодно) хочет добавить функцию, изменения должны быть задокументированы и проанализированы для получения эффекта. Любые результирующие изменения в объеме, бюджете и графике должны быть утверждены до того, как изменения будут предприняты Эти изменения обычно утверждаются вашим спонсором, вашим руководящим комитетом или вашим клиентом.

Как только изменения будут одобрены и приняты, это ваш новый план. Неважно, каким был первоначальный бюджет или график.

Управление изменениями в проектах основано на принципе «никаких сюрпризов». Правильные люди (ваша Комиссия по контролю за изменениями) должны утвердить любые изменения в области, расписании и бюджете, прежде чем они будут приняты.

Следует помнить, что могут существовать определенные явные или неявные ограничения и допуски на изменения. Возможно, вам придется сдать ваш проект к определенной дате, чтобы соответствовать государственным нормативным требованиям. Или у вашей организации может быть пороговое значение: если бюджет проекта на 30% превышает первоначальный бюджет, он должен перейти на уровень «С», или проект будет убит. Изучение и явное указание этих пороговых значений и допусков является хорошим способом достижения более успешных проектов.

Где заканчивается «управление изменениями» и начинается «провал проекта»?

Если проект соответствует утвержденному объему, графику и бюджету, он считается успешным.

Однако это все равно может рассматриваться как сбой. Обзоры после внедрения являются хорошим инструментом для оценки этого с вашими заинтересованными сторонами (а не только с вашим боссом). Также было бы полезно изучить преимущества реализации, чтобы увидеть за пределами черного ящика проекта и его влияние на бизнес в целом.

Answer 4

Энди Ратледж написал довольно интересную статью об успехе. Хотя заголовок Обсуждения перед началом торгов , в статье определено, есть успешный проект , что для Энди означает:

1. Будет ли мне или моей команде позволено довести нашу лучшую работу до конечного результата?
2. Готов ли клиент надлежащим образом участвовать в проекте?
3. Готов ли клиент начать этот проект?
4. Готов ли клиент доверять идеям моей или моей команды?
5. Готов ли я или моя команда выполнить или превысить требования проекта?

Эта статья была отмечена Оби Фернандесом, успешным консультантом, в его Do Hustle конференции о консалтинге.

Answer 5

Полагаю, насколько успешен проект, зависит от того, кто является клиентом. Если клиентом были директора компании, и они были довольны, тогда проект был успешным независимо от неудач на пути.