Общие ошибки управления проектами
13 апреля 2009 в 12:54

Общие ошибки управления проектами

Уважаемые дамы и господа! Пару месяцев назад опубликовали переводную статью об общих ошибках управления ИТ-проектами: http://www.osp.ru/cio/2009/02/5337322/. Она производит впечатление достаточно полной, тем не менее, меня не покидают сомнения — все ли существенные ошибки здесь упомянуты? Буду Вам признателен за критический анализ и дополнения.

Спасибо!

329
Комментарии (7)
  • 14 апреля 2009 в 10:17 • #
    Эдуард Семенов

    Пока вижу только один "ляп" - мне совершенно непонятно как програмный продукт может отценить квалификацию и компетенции персонала.
    А в целом статья очень полезная и актуальная. И действительно перечислены основные проблемы возникающие в ИТ проектах.

  • 14 апреля 2009 в 22:22 • #
    Борис Вольфман

    Михаил!
    Главная ошибка управления проектами: не руководствоваться методиками управления проектами.

    Или другими словами: менеджер делай все правильно, как учит PMI, RUP, MSF и т.п. и не будут выходить флуд-статьи: "Общие ошибки управления проектами".

    Например, основной ОБЯЗАННОСТЬЮ менеджера является расчет РЕАЛЬНЫХ сроков и управление рисками
    и указывать ошибкой13 "Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить",
    все равно, что перечислять ошибки хирурга: Не помыл руки, не наточил скальпель, использовал спирт не по назначению.

    Я эту мысль уже писал в обсуждении 29 ошибок менеджера из бывших программистов

    https://professionali.ru/Topic/1109399#reply1140502

    можно перечислить 129 ошибок, если он не стал менеджером, а остался программистом.

    А выполнить Вашу просьбу- дополнить общие ошибки управления проектами можно очень просто: добавить префикс НЕ к обязанностям менеджера:

    Не оформляет паспорт проекта
    Не управляет рисками
    Не управляет бюджетом
    Не управляет качеством
    Не расчитывает сроки проекта
    Не контролирует исполнение проекта
    и т.д.

    Всего доброго.

  • 14 апреля 2009 в 22:38 • #
    Борис Вольфман

    В дополнение:
    Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

    Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

    свидетельствует, что автор статьи (переводчик) не отвечает ожидаемым требованиям.

    Правильный ответ:
    Чтобы техническая реализация в максимальной степени отвечала ожидаемым требованиям, необходимо согласовать ТЗ с высокоуровневыми требованиями, запланировать на ранних стадиях разработки прототип реализации, показать прототип спонсору и заинтересованным лицам и учесть их замечания в детальных требованиях.

  • 21 апреля 2009 в 16:07 • #
    Дмитрий Лукьянов

    C моей точки зрения у нас, в принципе - одна ГЛАВНАЯ ошибка. Мы верим в "счастье". В свое маленькое отдельное локальное счастье. И в то, что все остальные ИДИОТЫ, а вот в НАШЕМ проекте ВСЕ ПОЛУЧИТСЯ. Может быть потому, что мы - славяне. Может быть потому, что прогуляли теорию вероятности и матстатистику в ВУЗе... Мы все умеем планировать - сроки, объемы, деньги, исполнителей... В конце концов, даже если это планирование - в "одно касание" - сразу одновременно с назначением. Чтобы начать говорить об ошибках - согласен с примером хирурга, который не помыл руки, стоит поговорить о культуре управления вообще. И насколько мы признаем научный подход и готовы ПРИЗНАВАТЬ факты, а не верить на АВОСЬ.
    В управлении рисками есть такой хороший показатель - называется НЕИЗБЕЖНОСТЬ - мультипликатор вероятности события и его (события) влияния (другой характеристики). Если применять к рискам - можем оценить общее "попадалово" на проекте - как в деньгах, так и в сроках... Потом - рассмотреть антирисковые стратегии - для негативных событий и рассмотреть как увеличить позитив... Потом - мероприятия. И! О чудо! Одно из наиболее часто вспоминаемых мероприятий - "помыть руки" (для хирурга)! Для строителя - "носить каску" (почти не-шутка), для ИТ-шника - еще что-то, потом.... еще... еще... А, так, если верить в чудо... Зачем эта методология? Зачем учить сотрудников? Зачем внедрять системы управления? Ведь это все другие ИДИОТЫ - а мы - ПРОСКОЧИМ!!! И так, раз за разом - по граблям ;-))) Какое еще КАЧЕСТВО? На поле с граблями? И с завязанными глазами? И еще и когда часть граблей - о ужас! - детские...
    А ошибок какие бывают... Да - можно добавить НЕ- ко всем девяти областям знаний PMI PMBOK, потом ко всем процессам - сколько их там - штук 40 сейчас? Потом еще взять IPMA ICB и проехаться по элементам компетенций, и тоже добавить НЕ-... А можно взять пива и заказать баньку, и порассказывать свои "военно-морские истории"... Если не утопим диктофон - может на книжку наговорим... Способов ошибиться много... И мы, похоже, готовы найти их все. И пока не найдем - не успокоимся ;-)
    Вот как... Прорвало...
    Статью почитаю...

  • 21 апреля 2009 в 17:34 • #
    Дмитрий Лукьянов

    М-да... Статью-то я уже читал ;-)
    Могу, разве что отметить то, что бросилось в глаза и при первом прочтении: "...Ошибка № 12: Незавершенность графика проектов.

    Проявление: Участники проекта не знают, что и когда им нужно сделать, в результате чего сроки реализации проекта оказываются под угрозой.

    Решение: По мнению Кларка, самый быстрый способ составить график проекта — это определить все необходимые мероприятия (содержание и границы проекта, предъявляемые к нему требования, процедуры тестирования и внедрения) и конкретные сроки их выполнения в соответствии с окончательными сроками реализации проекта. Составить такие графики вам поможет программное обеспечение управления проектами. ..."

    Насчет решения... Легко сказать - сложно сделать. К словам Кларка еще добавить - что к этим задачам и прочему добру, получаемому при корректной работе с управлением содержанием, прибавить не просто сразу следующий раздел - управление сроками, а вот еще и правильно его (сетевой график) скорректировать-оптимизировать, увязав с последующими управлением стоимостью, качеством и человеческими ресурсами... Одно только формирование управляемого пула человеческих ресурсов организации чего стоит! А тут - "...Составить такие графики вам поможет программное обеспечение управления проектами..." Ну да, поможет. Но не сделает за вас... И уж тем более не сделает эти планы реальными только то, что они не на бумаге, а в компьютере...

  • 21 апреля 2009 в 23:33 • #
    Сергей Громов

    Планирование! о чем вы говорите господа? Заказчику нужна пролукция в четверг на следующей неделе, денег вот столько, но половину вернешь. а то что надо в два раза больше денег только на комплектацию и 6 месяцев на разработку не считая изготовления, испытаний, сертификации, и т.д и т.п. это твои проблемы. У нас основные проблеммы начинаются с ТЗ. Его понять самим невозможно... А потом проблеммы с разработчиком, а потом с производством, а параллельно еще Д.С. на сроки и деньги и планирование по новому. Ошибки не в планировании, там все делатся как надо, только это у нас никому не надо кроме МП. Так что самая главная ошибка это принципы "Клиент всегда прав" и "Любой каприз за ваши деньги". Планирование начинается с убеждения заказчика что ему надо то что у нас есть. Вот когда желание заказчика будет соответсвовать нашим возможностям и его (заказчика) кошельку, только тогда можно начинать планировать.

  • 22 мая 2009 в 12:40 • #
    Максим Смирнов

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

    1. В тексте ни разу не встретилось слово «ответственность». Между тем, в проектной деятельности оно является ключевым. Размывание ответственность приводит сразу к серии серьезных ошибок. Первая из них анонимность (требований, рисков, тех или иных работ и т.п.) Рассмотрим эту ошибку на примере требований. Очень часто в проекте все требования сваливаются в единый документ без указания заинтересованных в их реализации лиц. В результате, проект перестает понимать что важно, а что не важно, какие требования можно скорректировать, а какие являются ключевыми и делает все подряд. Управлять scope, рисками, изменениями в такой ситуации просто нереально. Вторая ошибка: отсутствие координации действий. Когда нет абсолютно четкого понимания кто за что отвечает, начинается перевод стрелок

    2. Отсутствие внятного, разделяемого всеми участниками ответа на вопрос «Зачем?». Говоря другими словами цели проекта. Вроде бы все банально, но в большинстве проектов цели у shareholder-ов разные. Например, подрядчик хочет закрыть контракт и получить вознаграждение. Владелец проекта решает не анонсированные политические задачи, а спонсор просто осваивает бюджет. В такой ситуации крайне важно, прежде чем спускать корабль проекта на воду, договориться о правилах игры на берегу. Кстати, здесь уместно вспомнить, что цель проекта должна отвечать хотя бы двум критериям: быть достижимой и не ложной

    3. И, пожалуй, последнее. В ходе проекта нельзя забывать о будущем. Рано или поздно любой проект завершается, и его участники обнаруживают себя в совершенно другой ситуации, чем была до начала проекта. Кто-то становится богаче. Кто-то делает шаг по карьерной лестнице. Все становятся старше… Очень плохо, если в точке финиша проекта кто-то из заинтересованных лиц будет чувствовать себя хуже, чем в точке старта. А если «обиженный» stakeholder догадается об этом в ходе проекта, то наверняка он приложит все усилия чтобы этот проект развалить

  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?