Отправляет email-рассылки с помощью сервиса Sendsay

Усвоенные уроки в управлении проектами

Рассылка закрыта

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

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Февраль 2010   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Автор
lessonslearned.ru

Статистика

103 подписчиков
0 за неделю
←   Все выпуски   →

Усвоенные уроки в управлении проектами Усвоенные уроки в управлении проектами - Выпуск #2


 

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

 

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

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

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

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

 

Усвоенный урок №12. Высылай повестку совещания заранее

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

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

 

Усвоенный урок №13. Высылай протокол по завершению совещания

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

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

 

Усвоенный урок №14. Проводи регрессивное тестирование

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

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

 

Усвоенный урок №15. Периодически проверяй цели проекта

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

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

 

Усвоенный урок №16. Избегай gold plating

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

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

 

Усвоенный урок №17. Прописывай квалификацию команды проекта со стороны Подрядчика в контракте

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

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

 

Усвоенный урок №18. Не закрывай проект пока не подготовишь "усвоенные уроки"

Ситуация:
Вы руководитель проекта. Проект завершается. Вы можете написать lessons learned или закрыть проект. Вы решаете закрыть проект а усвоенные уроки написать чуть позже. Однако, через два дня часть проектной команды уже оказалась переброшена на другой проект. А еще через день, вам поручен новый проект. Вы не написали lessons learned.

Вывод:
Не закрывайте проект до написания усвоенных уроков. Это официально дает вам время и возможность для написания lessons learned.

 

Усвоенный урок №19. Необходимо всегда фиксировать сообщение об ошибке письменно

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

Вывод:
Необходимо официально фиксировать все найденные ошибки во время тестирования.

 

Усвоенный урок №20. Вовлекай техническую поддержку в проект заранее

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

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

 

 Статьи

Немного о заинтересованных сторонах проекта или кто такие stakeholders

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

В западной литературе по дисциплине «управление проектами» вводится термин stakeholders, который переводится как «заинтересованные стороны». О них, а вернее о том, как формируется и зачем в ходе проекта ведется реестр заинтересованных сторон эта статья.
 
Заинтересованные стороны это физические лица либо организации, так или иначе заинтересованные в результатах либо работах проекта. Например, на проекте внедрения ИТ системы, заинтересованными сторонами проекта будут будущие пользователи, руководители подразделений, которые затронет проект, команда проекта со стороны подрядчика, служба технической поддержки, члены управляющего комитета и т.д. Заинтересованные стороны, как правило, оказывают влияние, как минимум, на требования к продукту проекта и на коммуникации на проекте. Очень важно выявить все заинтересованные стороны проекта на ранней стадии развития проекта и в дальнейшем поддерживать выявленный список в актуальном состоянии. Это помогает избежать множества проблем на проекте. Например, в случае, если какая-то из заинтересованных сторон не будет идентифицирована на ранней стадии проекта, ее требования не будут учтены и соответственно, может оказаться, что проект не удовлетворяет бизнес целям компании.
 
При работе с заинтересованными сторонами проекта выделяют несколько процессов. Первым процессом, разумеется, является идентификация заинтересованных сторон, т.е. определение, кто именно является stakeholder. После того, как стороны проекта идентифицированы, происходит, категоризация заинтересованных сторон и оценка их влияния на проект, а также оценка степени их вовлеченности в проект. Разбивка по категориям заинтересованных сторон производится, обычно произвольным образом, под каждый проект по-своему. Примерами признаков, по которым делятся заинтересованные стороны на группы, могут служить: географическое распределение, степень вовлеченности в проект, количество выдвигаемых требований, принадлежность к компании и т.д. Деление на категории, в дальнейшем, сильно упрощает планирование коммуникаций. Оценку же степени вовлеченности в проект необходимо сделать для расстановки приоритетов по управлению заинтересованными сторонами и более четкого понимания, кто и какие полномочия имеет. Далее, планируется подход к работе с каждой из заинтересованных сторон. Т.е. необходимо четко понимать, что вам нужно для проекта от каждой заинтересованной стороны, степень выдвигаемых ими требований к проекту, как они могут помочь или помешать достижению целей проекта и, на основании данного понимания сделать выводы о действиях, которые необходимо выполнить для управления заинтересованными сторонами проекта.
 
В процессе идентификации заинтересованных сторон проекта появляется документ, называемый реестром заинтересованных сторон. В реестр вписываются заинтересованные стороны, их контактные данные, категории, степень вовлеченности и влияния на проект. Старайтесь не “раздувать” данный документ, но при этом следить за тем, чтобы он содержал в себе важную для проекта информацию. Как и при написании других документов можно ориентироваться на вопрос, задаваемый самому себе: “Если бы я сейчас был назначен на проект менеджером проекта, чем бы мне помог этот документ? Какие бы задачи он помог решить?”.
 
В дальнейшем, вы не единожды будете прибегать к помощи реестра заинтересованных сторон. Например, при выборе на какую группу высылать ту или иную информацию, при определении у кого брать интервью в процессе определения требований, кого оповещать, а с кем согласовывать изменения, с кем работать в тесном сотрудничестве, а кому достаточно уделять внимание на редких встречах, с кем работать формально, а с кем неформально и т.п. В общем, создайте реестр заинтересованных сторон проекта, если его у вас до сих пор нет и аккуратно ведите его в течении всей длительности проекта.
 
Успешных вам проектов!

В избранное