LessonsLearned.Ru - раскрой свой опыт управления проектами

Усвоенные уроки

Усвоенный урок №31. Заполняйте простои полезными действиями

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

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

Усвоенный урок №32. Твой оппонент сегодня может стать твоим партнером завтра

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

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

Усвоенный урок №33. Используй видео для демонстрации воспроизведения ошибок в ПО

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

Вывод:
Попробуйте понять производителя системы. Чтобы быстро найти ошибку, нужно знать действия, выполняемые пользователем. Для записи действий пользователя можно использовать видео. В сети есть много программ, позволяющих записывать действия пользователя на компьютере. Это сильно сокращает трудозатраты на описание ошибки у вас и воспроизведение ее у производителя ПО.

Усвоенный урок №34. Используй чужой опыт

Ситуация:
Вы руководитель проекта внедрения специализированного программного обеспечения. Производитель данного ПО - крупная компания в Великобритании. В России уже есть одно внедрение данного программного обеспечения. Вы на страдии инициации проекта и планируете свои действия. Вам очень помогла бы информация от менеджера проекта с проекта первого внедрения в России.

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

Усвоенный урок №35. Планируй окончание критических работ на следующий день после встречи по статусу проекта

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

Вывод:
Запланировав окончание работы подобным образом, вы подстраховываете себя четырехдневным запасом до следующего отчета о статусе проекта.

Усвоенный урок №36. Прислушивайся ко всем участникам проекта

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

Вывод:
Прислушивайтесь ко всем участникам проекта, не только к тем, которые говорят громко и четко. Иногда люди стесняются, смущаются или просто боятся предлагать дорогостоящие изменения. Однако это не значит, что в этих изменениях нет необходимости. Умейте слушать.

Усвоенный урок №37. Веди лист версий в документах

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

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

Усвоенный урок №38. Не позволяй себя шантажировать

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

Выводы:
Никогда не идите на согласие, в результате шантажа. Это опасно не результатом (в данном случае подписанием отчетов), а самим фактом.

Усвоенный урок №39. Утверждай список поставщиков до начала тендера

Ситуация:
Вы менеджер проекта. Ваш проект находится на стадии тендера на заключение договора с подрядчиком. Вы составили long list поставщиков и разослали RFP участникам конкурса. Через неделю, ваш Заказчик просит вас добавить в список еще одного участника. Вы его добавляете, но как быть со сроками? Участник начал готовить коммерческое предложение на неделю позже, а вы находитесь в затруднении в перепланировании тендера.

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

Усвоенный урок №40. Пиши подробные описания версий в лист версий документов

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

Вывод:
Пишите в лист версий причины изменений. Это поможет вам избежать ситуации, подобной описанной.

Статьи 

Управление рисками проекта: введение

 Алексей Ким, akim@lessonslearned.ru

Ну, для начала, неплохо было бы дать определение проектного риска и, собственно, процесса управления рисками проекта. Риск проекта – событие в будущем, имеющее некую вероятность не равную 100%, которое может позитивно или негативно сказаться на целях проекта. Т.е. риск – это событие, которое может произойти, а может не произойти. Это определение довольно важно, для понимания, что такое управление рисками. Если мы можем с уверенностью сказать, что какое-то событие точно произойдет, то это уже не риск. Риски бывают как негативные, так и позитивные. Например, изменение курса валют. Допустим, мы планируем приобретение оборудования за $100 000 через два месяца. Оплачивать будем в рублях. Если курс доллара вырастет, мы заплатим больше, это негативный риск. Если же курс доллара упадет, то мы заплатим меньше чем, если бы покупали сегодня, соответственно, это позитивный риск. Отсюда вытекает определение управления рисками проекта как, процессов, включающих в себя планирование рисков, идентификацию, анализ, планирование ответных действий, мониторинг и контроль, направленные на повышение вероятности и степени влияния позитивных рисков и снижение вероятности и ущерба негативных рисков.
 
В данной статье я рассматриваю управление рисками со своей точки зрения, основанной на стандартах PMI. Существуют другие стандарты, которые имеют совершенно отличный от описанного мною подход к управлению рисками.
 
В условиях России, большинство руководителей проектов, к сожалению, рассматривают управление рисками проекта как нечто необязательное, в лучшем случае, предназначенное для создания красочной странички в отчете о статусе проекта для управляющего комитета. На мой взгляд, необходимость в какой-то мере управлять рисками есть на любом проекте. Просто, на крупных проектах управление рисками должно быть реализовано в большей степени, на небольших проектах, в меньшей. Например, на крупных проектах, может использоваться различное специализированное программное обеспечение для оценки вероятности риска, в то же время, бюджет небольших проектов может не осилить приобретение и использование подобного ПО. Или же, например, на небольших проектах, команда проекта может обходиться идентификацией рисков и примерной их оценкой “на глазок”. Усилия, затрачиваемые на управление рисками должны быть пропорциональны выгоде, получаемой от этого. Работы по управлению рисками необходимо прописывать в плане-графике работ, т.к. это такие же работы по управлению проектом, как встреча управляющего комитета или написание отчета о статусе проекта.
 
Вообще, риски влияют на все области проекта. Если бы не риски, можно было бы прописать тщательный каждодневный план действий на проекте и спокойно его реализовывать. Управление расписанием проекта и управление стоимостью проекта сводились бы к оценке длительностей и стоимостей и грамотной установке связей работ. Наличие рисков проекта делает подобное планирование бессмысленным, т.к. при срабатывании первого же риска ситуация станет отличной от плана и придется все перепланировать. Таким образом, наличие рисков сильно осложняет процессы во всех областях проекта: и управление расписанием проекта и управление стоимостью, управление качеством и т.п.
 
Управление рисками проекта необходимо выполнять в течении всего жизненного цикла проекта, начиная от стадии инициации проекта и заканчивая закрытием проекта. Обязательными условиями для успешного и эффективного управления рисками являются: интеграция работ по управлению рисками в работы по управлению проектом, ясное понимание и уверенность в необходимости управления рисками, ответственность, открытые и честные коммуникации, поддержка со стороны руководства организации, оценка рисков относительно проекта.
Поясню эти условия:
∙ Интеграция работ по управлению рисками в работы по управлению проектами – управление рисками не существует отдельно от проекта. Изменения в рисках могут повлиять на любую другую область проекта, равно, как и изменения в любой области проекта могут вызвать изменения рисков, соответственно, процесс управления рисками должен быть интегрирован в процесс управления проектом.
∙ Ясное понимание и уверенность в необходимости управления рисками – команда проекта, заинтересованные стороны, заказчик, спонсор и руководитель проекта должны быть уверенны в необходимости управления рисками. Иначе, эффективность снизится, и процесс управления рисками превратится в фарс.
∙ Ответственность – все заинтересованные стороны и участники проекта должны принимать на себя ответственность за действия, связанные с риском (его устранением, срабатыванием и т.д.), в случае необходимости.
∙ Открытые и честные коммуникации - в управление рисками проекта должны быть так или иначе вовлечены все участники проекта, соответственно, успешные коммуникации являются очень значимыми для эффективного управления рисками.
∙ Поддержка со стороны руководства организации – управление рисками проекта может так или иначе затронуть цели и задачи всей компании, соответственно, может потребоваться согласие высшего руководства компании (не управляющего комитета, а именно руководства компании) для выполнения тех или иных действий.
∙ Оценка рисков относительно проекта – управление рисками проекта должно вести к достижению целей проекта, и оцениваться относительно проекта.
Необходимо постоянно контролировать соблюдение данных условий при управлении рисками проекта. Откиньте любое из этих условий и эффективность управления рисками снизится. Придерживайтесь их и все будет “ок”.
 
В следующей статье управление рисками проекта будет рассмотрено более подробно.
 
Успешных вам проектов!