Уроки проектов (lessons learned)
23 декабря 2008 в 05:36

Уроки проектов (lessons learned)

Тема открыта по просьбе Аркадия Курова (Менеджер по развитию ИТ-систем, ОАО «Вымпелком»)
Обсуждается опыт решения реальных проблем в проектах.

998
Комментарии (50)
  • 23 декабря 2008 в 08:43 • #
    Сергей Михайлюк

    Я согласен

  • 23 декабря 2008 в 09:26 • #
    Наталья Антропова

    С удовольствием

  • 23 декабря 2008 в 09:46 • #
    Владимир Пастушенко

    Прошу пояснить о чём в данном разделе будет идти речь. Описание реального опыта?

  • 23 декабря 2008 в 09:52 • #
    Денис Свиридов

    Подразумевается опыт решения проблем в проекте. Первый кирпичик с моей стороны. Проблема: что такое project scope. Для кого то это банально, но когда речь идет о многомиллионном и долгосрочном проекте - на этапе планирования определения scope project может стать реальной проблемой ввиду различного перевода этого термина на русский язык. И проблема часто не в голове у рук-ля проекта, а в голове спонсора, инициатора, активных участников высокого полета и т.д.. Прошу высказываться. Свое решение данной проблемы выложу через несколько дней, т.к. очень хочется услышать мнения других.

  • 23 декабря 2008 в 11:05 • #
    Валерий Грачев

    Содержание проекта (Project Scope) Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и
    функциями. - PMBoK.
    Но к указанной теме дискуссии эт не имеет отношения

  • 23 декабря 2008 в 11:32 • #
    Денис Свиридов

    Валерий, если для вас (для ваших проектов) это не проблема, то я только рад за вас, честное слово.
    Для вас project scope = границы проекта = работы .... я правильно понял?

  • 23 декабря 2008 в 18:27 • #
    Людмила Семенюта

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

  • 4 января 2009 в 15:46 • #
    Вячеслав Великопольский

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

  • 23 декабря 2008 в 13:45 • #
    Константин Редченко

    В общем-то, обсуждение scope project в нашем консалтинговом бизнесе в основном сводится к решению проблемы - что есть проектом, а что проектом не есть. Иначе говоря, это предмет нашего договора с Заказчиком, причем этот предмет (содержание) должен быть глубоко и системно проанализирован и одинаково воспринят заинтересованными сторонами. Хорошей практикой тут является предварительная сессия, на которой присутствуют все "важные люди" проекта и где обсуждается предварительно (или оперативно) выстроенная в MindManager иерархия сущностей (понятий, определений) project scope, ну а далее уже проходит обсуждение иерархии действий (работ). Таким образом, есть возможность обменяться мненими и прийти к общему пониманию как статических, так и динамических составляющих проекта.

  • 23 декабря 2008 в 15:06 • #
    Аркадий Куров

    Это скорее pre-sale стадия, после чего должен проводиться бизнес-анализ предложенного решения.

  • 23 декабря 2008 в 14:53 • #
    Аркадий Куров

    В общих чертах выскажусь.
    Мне кажется, что проблема не в переводе термина на русский язык, а в несогласованных БФТ, не зафиксированных результатах (с учетом KPI), ограничениях и допущениях будущего проекта на стадии инициации. Как решать - привести в порядок документацию, ознакомить с ней ключевых участников проекта, провести согласование по документам, доработать после этого документацию и уведомить всех, кого требуется (заказчика и спонсора в первую очередь). Далее, при возникновении недопонимания всегда можно будет ссылаться на документацию.

  • 23 декабря 2008 в 19:44 • #
    Костенков Сергей

    Я думаю очень полезно пользоваться ГОСТами и СНИПами, там все описано и регламентировано. А если на них ссылаться в совместной работе с Заказчиком то и база общая и пресловутый scope выливается во всем знакомые ТЗ и ТТ и т.д.

  • 23 декабря 2008 в 20:32 • #
    Аркадий Куров

    Есть несколько моментов:
    1. Работа по ГОСТ-ам приводит к написанию большого количества документации, которая будет невостребованна.
    2. На написание этой документации требуется время и ресурсы, которые Заказчик вряд ли оплатит в таком объёме.
    3. Это ещё может работать в национальных проектах, но как только появится иностранный поставщик, задача сильно усложнится - никакой общей базы и всем знакомых ТЗ

  • 23 декабря 2008 в 10:39 • #
    Иван Киселев

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

  • 23 декабря 2008 в 12:02 • #
    Илья Мондин

    Проекты проектами.. А как наладить и стимулировать сбор идей?

  • 23 декабря 2008 в 12:12 • #
    Светлана Кабанова

    По поводу "наладить и стимулировать сбор идей"

    Есть несколько уровней работы с идеями: исполнительский и управленческий. Задачи, соотвественно, разные.
    "Наладить", если я правильно поняла Вашу мысль, это значит на уровне линейного менеджмента выстроить систему "обратной связи", ее обработки и интеграции.
    Управленческий сложнее - поскольку связан с идеями стратегических решений.

    Но методики отработаны и осталось найти людей, которые способны применить их эффективно:))))

  • 23 декабря 2008 в 12:26 • #
    Анастасия Мещерякова

    Аркадий, я в ИТ и консалтинговых проектах уже 10 лет. Могу сказать, что уроки надо извлекать зная методологию управления проектом. В этой методолгии есть направления, которые позволяют планировать, управлять проектами, отслеживать процесс реализации проекта, а также точно оценить процесс управления проектом каждой рабочей группой или компанией группы в холдинге.
    Уверена, что я заложила не "кирпичик", а "фундамент" данной темы, инициатор темы Вы,тогда Вы и определяете project scope.

  • 23 декабря 2008 в 13:11 • #
    Аркадий Куров

    Анастасия, вы, вероятно, хотели ответить не мне, а Денису Свиридову, я в этой теме первый раз пишу.

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

    Возьмем кейс Дениса:
    Проблема - нет четкого понимания термина project scope у всех заинтересованных участников проекта
    Причина - неоднозначная трактовка термина
    Решение - ... (здесь Денис рассказывает как он решал эту проблему или предлагает вариант решения для обсуждения)

  • Цена: $2,000,000

  • 23 декабря 2008 в 14:42 • #
    Денис Свиридов

    Аркадий, я с вами абсолютно согласен, а вот комментарий Анастасии я не понял.

  • 23 декабря 2008 в 16:05 • #
    Анастасия Мещерякова

    Денис, project scope - опредение "рамок проекта", с целью согласования и соблюдения границ проекта. Более подрабно написала в ответе Аркадию.

  • 23 декабря 2008 в 16:01 • #
    Анастасия Мещерякова

    Аркадий, извините, просто тема была открыта по вашей просьбе.....
    У меня был проект по организации и автоматизации кольцевой логистики в энергетическом холдинге - 6 компаний. Как руководитель проекта представляла презентацию "Управление проектом: организация и процессы деятельности" ген.директору. Были описаны рамки проекта (география, функциональные области, процессы), график работ проекта по этапам и основные результаты. Вот вобщем-то все по термину project scope .
    Финансирование проекта организовала в рамках программы развития холдинга. Ключевыми факторами успешной реализации проекта в рамках определения объема проекта были реалистичный, управляемый объем проекта. Т.Е. на этапе определения более точно формулируются цели и задачи, состав и сроки выполнения проекта(ов), определяющие необходимые ресурсы, масштаб и порядок действий. Определенность описываемых процессов (функционал).

  • 23 декабря 2008 в 16:38 • #
    Аркадий Куров

    На самом деле, я так понимаю, проблема заключается в том, что требования (scope ) бывают плохо прописаны и в какой-то момент заказчик интересуется - "А как у нас обстоят дела с А?", PM удивляется и говорит, что про это он слышит первый раз. Заказчик тоже удивляется и уточняет - "В фазе два проекта есть активность В и в неё входит реализация функционала А" , менеджер проекта понимает о чем идёт речь и пытается донести до заказчика мысль, что "функционал А" - это вообще out of scope. В тоже самое время этот самый "функционал А" оказывается критичен и возникает конфликт. Возможные варианты:
    1. Эскалировать проблему (переложить решение на чужие плечи)
    2. Решить проблему в срок без дополнительных затрат (без увеличения бюджета и расширения проектной команды)
    3. Какой-то иной вариант

  • 23 декабря 2008 в 17:28 • #
    Анастасия Мещерякова

    Вы хорошо описали частые "хотелки" и "непонимания" в проекте, в результате чего возникает конфликт интересов. "Иной вариант" из практики, когда разрабатываются варианты проектных решений (ПР) по функционалу и ролям (последовательности действий) в ИТ системе.
    По хорошему, конечно, надо договариваться "на берегу" сначала, а потом пускаться в плавание. Поэтому предлагаю описать Процедуру управления проектом:
    - планирование работ
    - отчетность и мониторинг
    - управление изменениями и преобразованиями
    - управление реализацией преимуществ (выгод)
    - управление рисками.
    С п.1,2 сталкивалась на проекте внедрения SAP, они имели место когда
    п.1 компетенция местных ИТ специалистов была средней,
    п.2 команда внедренцев, пересматривала концептуальный проект, и изменила функционал (разработала ПР), роли (конечных пользователей).

  • 23 декабря 2008 в 20:04 • #
    Костенков Сергей

    19, 24, 34 ГОСТ

  • 23 декабря 2008 в 20:18 • #
    Аркадий Куров

    По поводу разработки Процедуры Управления Проектом - интересная мысль, особенно если получится небольшой документ на 50-100 страниц, своего рода конспект. Анастасия, формализуйте, пожалуйста, основную цель и задачи документа, далее обсудим идею в отдельной теме и у нас вполне может получиться полезный всем коллегам документ!

  • 24 декабря 2008 в 09:28 • #
    Денис Свиридов

    Аркадий, для такого дела наверное подойдет корпоративная система управления проектами (КСУП), которая и включала бы описание процедур управления проектами и много чего еще. Если организация серьезно основывает свою деятельность на проектах, то такая система просто необходима.

  • 24 декабря 2008 в 10:33 • #
    Александр Левыкин

    Вопрос не про процедуру управления проектом. А про рамки и границы, которые в дальнейшем, превращаются в работы - затраты. И мне кажеться, очевидным, что перед крупным проектом необходимо проводить детальное обследование. Т.к. без оплаты этим подрядчику заниматься накладно, то пишеться проект. Тем более, что без договора на разработку проекта зачастую заказчика не имеет права передавать подрядчику информацию, а вместе с договором подпсывается соглашение о неразглашении.
    В любом случае определить точные трудозатраты невозможно и подрядчик вынужден и должен, закладывать страховой резерв в деньгах и сроках. Как собственно и подрядчик. Другое дело, что во время тендора эти резервы тают, что приводит к молодцам продавцам и плохим внедренцам. Но такова жизнь...
    По поводу ГОСТов, коллеги, не смешно ... откройти PMBok и ГОСТ не находите ни чего схожего? Это же рекомендации-стандарты вышедшие из жизни....

  • 24 декабря 2008 в 11:30 • #
    Аркадий Куров

    Денис, это при идеальным подходе и хорошем проектном офисе в компании. А если рассматривать стартап или небольшую компанию у которых нет:
    1. Средств на покупку КСУП
    2. Времени установку и настройку freeware КСУП
    Опять же, заходя с другой стороны - по этой процедуре можно будет формализовать требования к КСУП

  • 24 декабря 2008 в 11:55 • #
    Денис Свиридов

    Аркадий под КСУП я вовсе не понимал только ПО, но и свод правил в том числе.

  • 24 декабря 2008 в 12:23 • #
    Аркадий Куров

    Внедрение КСУП является само по себе проектом. Для реализации такого проекта и потребуется процедура.

  • 24 декабря 2008 в 12:40 • #
    Игорь Цесельский

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

  • 24 декабря 2008 в 15:02 • #
    Анастасия Мещерякова

    Абсолютно. ГОСТы применяла, когда внедряла на 3-х проектах AXAPTA, а когда SAP, тогда методология управления проектами большого консалтинга (IBM...) потому как мало знать только ASAP.

  • 24 декабря 2008 в 17:21 • #
    Анастасия Мещерякова

    Основная цель Процедуры УП - точно оценить, насколько успешно осуществляется процесс управления проектом.
    Направление Задача
    1.Рамки проекта - согласование и соблюдение границ проекта.
    2.Управление разработкой и приемкой - контроль подготовки и приемки отчетных материалов в рамках согласованных ранее сроков, средств бюджета и уровня качества выполненных работ.
    3. Управление рисками и проблемами - определение, оценка и разработка плана снижения всех рисков проекта.
    4. Реализация бизнес преимуществ проекта - оценка, сравнение и отслеживание преимуществ проекта (финансовых и нефинансовых результатов).
    5. Управление заинтересованными сторонами - привлечение ключевых сотрудников к процессу реализации проекта и стратегии компании (рабочая группа).
    6. Управление и организация рабочей группы и процесса разработки - проверка распределения управленческих обязанностей, выделенных ресурсов и их компетенции, навыков, опыта работы и знаний на протяжении всего процесса реализации проекта.
    7. Управление знаниями - контроль передачи документов Заказчику.

    Аркадий, вашипредложения??

  • 24 декабря 2008 в 19:44 • #
    Аркадий Куров

    Анастасия, я до конца не понимаю конечную цель - это аудит проекта или шаблон ведения проекта?
    И вопрос по пунктам 5 и 6, я правильно понимаю, что 5 - это формирование рабочей группы проекта (команды проекта), а 6 - управление рабочей группой?

  • 24 декабря 2008 в 20:11 • #
    Анастасия Мещерякова

    Аркадий,
    процедура управления проектом - СТП, т.е. шаблон ведения поректа,
    Процедура аудита проекта - СТП по "урокам проекта".
    п.п.5,6 - всё правильно поняли!

  • 24 декабря 2008 в 20:40 • #
    Анастасия Мещерякова

    АЛЕКСАНДР!
    1. Процедура управления проектом - это прежде всего планирование, т.е. рамки и границы проекта, план проекта, бюджет проекта и т.д. Это ВСЕ поняли, даже уточнили определения.
    2. Детальное обследование (диагностика) - проект управленческого консалтинга, или же концепт - дизайн.
    Я подписывала соглашение о неразглашении на этапе pre-sale.
    3. общепризнанную формулу расчета проекта внедрения (ERP)ИТ системы ВСЕ знают, включая страховой резерв в деньгах . В моих проектах во время тендора эти резервы не таяли.
    4. И наконец, о не смешном, эти рекомендации - стандарты, кот. надо уметь применять в жизни. Об этом и речь: Процедура управления проектами - должна быть руководством по ведению проектом.

    Резюмируя п.п.1-4 ясно, что надо предложить поэтапную модель заключения контракта для малых проектов, т.к. выше речь шла о комплексных проектах и корпоративной системе управления проектами (КСУП). Согласны?

  • 24 декабря 2008 в 21:06 • #
    Аркадий Куров

    То есть за основу берем СТП ИСО?

  • 24 декабря 2008 в 21:22 • #
    Анастасия Мещерякова

    Не совсем, методология управления проектом мирового консалтинга соответствует ИСО 9000, для того чтобы можно было не просто управлять, а ещё и качественно. Процедура УП описывает процессы управления проектом с целью достижения его задач и исключения возможных проблем.
    Иначе говоря, надо показать умение применять в жизни стандарты мирового опыта.
    Причем, надо описать поэтапную модель заключения контракта, чтобы у руководителей не таял бюджет проекта уже на этапе тендера.

  • 24 декабря 2008 в 21:26 • #
    Аркадий Куров

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

  • 24 декабря 2008 в 21:28 • #
    Анастасия Мещерякова

    Cм. мою конференцию с Алексадром Левыкиным (ниже)

  • 24 декабря 2008 в 21:34 • #
    Аркадий Куров

    Учел - https://professionali.ru/Topic/269650, если что-то ещё надо добавить - говорите, добавлю!

  • 8 января 2009 в 18:51 • #
    Азат Зайдуллин

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

  • 8 января 2009 в 19:15 • #
    Азат Зайдуллин

    общепризнанную формулу расчета проекта внедрения (ERP)ИТ системы ВСЕ знают
    Я не знаю. Серьезно. Не могли бы Вы ее предоставить. Можно в личку. Ниже приводил пример, который сам придумал, на своем опыте.

  • 8 января 2009 в 19:06 • #
    Азат Зайдуллин

    У меня уже проблема с переводом на русский язык(хотя для меня русский - основной язык общения). Я правильно понимаю, что project scope - это Цель проекта? Если да, то в шутку можно представить так:

    Проблема - нет четкого понимания термина project scope у всех заинтересованных участников проекта
    Причина - неоднозначная трактовка термина
    Решение - перевести на русский язык. :-)

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

  • 23 декабря 2008 в 13:17 • #
    Svetlana Kalashnikova

    Доброго дня всем!
    Если честно, не очень понятно о чем дискусс.
    Урок первый чему посвящен? Как работать с понятием проект? или с чего начинать?
    Как я понимаю, любое проектирование начинается с определения концепции самого проекта. Что вы хотите создать, для чего собственно вы это делаете?
    Определить "три кита" (три "И") проекта: Интерес (который движет вами), Идея (что инновационного в вашем проекте), Идеал (идеальная модель, недосягаемая имеющимися на сегодня инструментами).

    Ну, и так.. пара поэтических фраз на тему :)

    Какой подход ближе?

    Проетируя проектирую -
    Заработаю ли на квартиру я!

    Проектируя проектирую -
    Скажу ли слово новое миру я!

    (автор - однокурсник)

  • 23 декабря 2008 в 15:14 • #
    Дмитрий Ковалев

    Project scoope ::
    1. Критерии достижения целей проекта
    2. Задачи и результаты проекта
    3. Границы проекта (функциональные - организационные)
    4. Ограничения проекта
    5. Допущения проекта
    6. Идентифицированные риски проекта
    если коротко, то примерно так

  • 23 декабря 2008 в 16:28 • #
    Дмитрий Якимов

    безусловно, да

  • 23 декабря 2008 в 18:34 • #
    Людмила Семенюта

    Хочу спросить: никому не захотелось на фоне текущего состояния инвестиционной деятельности посмотреть на свою личную деятельность в сфере проектного менеджмента отстраненным взглядом и извлечь для себя какие-то уроки?

  • 23 декабря 2008 в 20:48 • #
    Аркадий Куров

    Речь про окупаемость инвестиций (ROI) или что-то ещё?

  • 12 января 2009 в 15:38 • #
    Юлия Шабанова

    Дамы и господа, здравствуйте. У нас ведь здесь "уроки проектирования". Мы договорились обсуждать какие-либо проблемы и находить решения. Уже были разъяснены основополагающие аспекты ведения и стартапа проекта.

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

    И вопрос второй: как вы считаете, является ли непрофессионализм исполнителей краеугольным камнем и причиной фатального результата!


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008