ИМХО по проблемам.  

29 Jun 2012

Проблемы:
1. Заказчик не видит текущую ситуацию на проекте;
2. Не прописана в договоре обоюдная ответственность сторон о срыве сроков;
3. Руководство заказчика уделяет недостаточное внимание ходу проекта;
4. Сотрудники заказчика игнорируют работы по проекту, считая свои текущие дела важнее, чем изучение, приемка и освоение новой системы;
5. В ходе проекта у заказчика появляются новые хотелки, не описанные в ТЗ;
6. Оправдывая свое разгильдяйство, заказчик готов сносить сроки;
7. Не возможно повлиять на руководство заказчика, чтобы оно заставило подчиненных укладываться в сроки;
8. Заказчик не может качественно и в срок сделать свою часть работы по проекту (например, написать ТЗ, хотя сам вынудил подрядчика отдать это ему, чтобы сэкономить деньги на разработку ТЗ подрядчиком);
9. В ходе опытной эксплуатации заказчик месяц может не подавать признаков недовольства и выкатить свои претензии наспех в последний день опытных работ;
10. Непредвиденные при проектировании технические проблемы (встают, как правило, при внедрении нового софта в первый раз);
11. Неточность планирования (занижены сроки и объемы при составлении плана работ, не предвидели новые объемы работ);
12. Не хватка ресурсов (при продвижении нового продукта в отсутствии специалистов по продукту);
13. Нет механизма управления изменениями при отклонениях факта от плана;
14. Подрядчик прогибается под заказчиком идя на всевозможные скидки себе в ущерб, не предвидя рисков, которые могут возникнуть;
15. Слабое влияние руководителя проекта на руководство (ТОПов и собственников) компании, не хватает статуса и уровня влияния (как обеспечить руководителю проектов диктаторские полномочия?);
16. Неправильно договорились на берегу: заказчик думал одно, а подрядчик другое;
17. Руководство заказчика не достаточно замотивировано на сроки;
18. Подрядчик не может замотивировать сотрудников заказчика на соблюдение сроков;
19. Открытый и скрытый саботаж сотрудников заказчика;
20. Неразбериха и отсутствие должного контроля над ходом проекта у подрядчика.

Мнение:
SMART говорит что срыв задачи возможен по трем причинам:
1. Не правильно выбран исполнитель.
В данном случае это Мы, а мы судя по описанным проблемам Идеал, который со всем справиться и все проблемы лежат в поле Заказчика. Только 12 условно сюда подходит
2. Заказчик не предоставили исполнителю достаточно ресурсов для выполнения задачи
1. 3. 4. 5. 6. 7. 8. 9. 12. 14. 15. 17. 18. 19. 20.
3. У заказчика недостаточно ресурса что бы исполнитель выполнил задачу.
Редко так бывает. В большинстве ресурсы есть, иначе не было бы косынки и паука.
15 из 20 проблем лежит в нехватке различных видов ресурса: внимания со стороны заказчика, исполнительности, административного ресурса, времени на проектировку и т.д. и т.д.На лицо системная общая проблема в подходе в работе с Заказчиком. Подходы srcam и agile помогут уйти от проблем:
2. 3. 5. 6. 8. 9. 10. 11. 13. 14. 16. 20.
Естественно что нужно растить свои компетенции, для того что бы правильно назначать руководителя проекта. Руководитель проекта нужно два качества (в рамках описанных проблем):
1. Правильно понимать что хочет Заказчик. Именно понимать что хочет Заказчик. А не интерпретировать желания Заказчика. Если Заказчик говорит - мне нужен механизм сверки документов в разных базах. То это не значит что заказчик нуждается:
1. В аудите работы в какой либо базе
2. Исследования потребности в сверки
3. Продаже инструмента помогающего все со всем сверить и проверить
4. И т.д.
2. Правильно определять Решателей в каждой задаче. Т.е. выявлять человека который действительно способен помочь в решении поставленной задаче. В нашем примере задача может исходить от Директора, а Решатель может быть девочка в очках в бухгалтерии, которая идеолог этой сверки и она ей нужна что бы компния Х составляющая 0.002%... Почему она Решатель? Потому что как то она добилась что бы Директор позвонил нам и озадачил такой проблемой. Значит эта девочка знает и умеет влиять на Директора, а это именно то что нам нужно.

Конечно под всем этим лежит еще и экономическая болезнь. Потому что сегодня рыночная цена решения много больше фактической понятной клиенту себестоимости. Тут много проблем:
1. Поставщик решений перезакладываеться на всем чем только можно, что бы застраховать себя.
2. Это происходит от того что Поставщик в лице Руководителя проекта или Руководитель руководителя проекта плохо ориентируются в предметной области, а чаще всего некомпетентны. К примеру мой менеджер в Билайне который продает мне телефонные услуги не понимает чем отличается Avaya от Asterisk. Что такое VPN и где заканчивается контур безопасности за который отвечаем Мы как потребители, и начинается ИХ как поставщиков.
3. 1 и 2 можно обобщить что слишком много менеджмента. На каждого фактического специалиста (который работает и способен производить продукт) приходиться как минимум по одному менеджеру. Высокий уровень административных издержек угнетает Поставщика, который старается заложить это все в стоимость Услуг. Услуги дорожают - клиенты готовые потреблять сокращаются. Остаются только клиенты - которые не способны объективно оценивать фактический объем и стоимость работ. А отсюда возникают все 20 причин срыва проекта.

Вывод: необходим рефакторинг собственной работы. Нужна революция в собственном сознание. Нужно допустить мысль что ты ошибаешься и что завтра тебя могут уволить (кто то читай обонкротиться) и тогда что то измениться...
Читайте: Деминга, Уэлча, Друкера (эффективные менеджеры). Читайте: Кейнса, Аумана, Самуэльсона (экономисты), Читайте: Бэрна, Фрейда, Скиннера (психологи)
lj, Мысли