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

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

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

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

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

Усвоенный урок №22. При назначении переговоров по телефону, совещаний, сроков указывайте часовой пояс

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

Вывод:
Когда высылаете повестку совещания, приглашение к переговорам или просто озвучиваете срок человеку, находящемуся в другом городе (географически), обратите внимание, на указание точки отсчета для времени, например в 14 часов по Московскому времени.

Усвоенный урок №23. Прописывайте в контракте носитель, на котором предоставляется документация

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

Вывод:
Проверяйте, что поставка документации указана в контракте именно в том виде, который вам необходим.

Усвоенный урок №24. Контролируй требования регулирующих органов

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

Вывод:
Контролируйте и отслеживайте требования регулирующих органов.

Усвоенный урок №25. Оповещай о методике оценки

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

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

Усвоенный урок №26. Проводи инвентаризацию проекта

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

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

Усвоенный урок №27. Не забывай отмечать достижения членов команды похвалой

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

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

Усвоенный урок №28. Получай отзывы от Заказчика в ходе проекта

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

Вывод:
Необходимо активно вовлекать Заказчика в проект на всех его этапах.

Усвоенный урок №29. Оформляй запросы на изменение

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

Вывод:
Запросы на изменение не всегда зло.

Усвоенный урок №30. Проверяй, что у всех членов команды есть все необходимые материальные ресурсы

Ситуация:
Вы руководитель проекта внедрения информационной системы. У вас в компании настроен и активно используется Microsoft Project Server. Один из членов проектной команды часто забывает о своих задачах. В результате страдают сроки. После анализа, оказывается, что сотруднику просто не приходят уведомления на электронную почту о назначенных ему заданиях. Сотрудник стеснялся об этом сообщить.

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

Статьи 

Характерные черты хорошего менеджера проектов

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

Введение
За все время работы на проектах, мне удалось увидеть приличное количество менеджеров проектов и различных стилей работы. Все это были разные люди, с индивидуальными особенностями и характерами, работающие в разных компаниях с разной корпоративной культурой, часть из них была из других стран. Кто-то был, на мой взгляд, слишком жестким, другие – слишком мягкими, но у всех руководителей проектов, которых уважали и чей вклад в проект был заметен, присутствовали некоторые общие отличительные черты или, скорее даже, принципы работы, характеризующие их. Ниже, я хотел бы рассмотреть их более подробно.
  
Ориентированность на цели проекта и конечный результат
Довольно забитым различными упоминаниями к месту и не к месту является характеристика “Ориентированность на результат”. Под данной характеристикой я понимаю, что руководитель проекта должен видеть цели проекта и конечный результат, что именно в конце концов должно получиться. Почему это важно? На долгосрочных проектах, обычно хватает изменений, чтобы некоторые действия из плана стали бессмысленными или неоптимальными. Когда менеджер проекта видит конечный результат, он может откинуть лишние или оптимизировать неоптимальные работы. Также, важно видеть цели проекта. Например, производство лопаты для того, чтобы вскопать участок земли имеет смысл до тех пор, пока участок не вскопан, т.о. даже произведя лопату, может оказаться, что проект по ее производству провальный, т.к. в ходе проекта кто-то другой уже вскопал участок.
 
Установление нормальных отношений с командой
Это очень важная черта характера, умение установить нормальные отношения с командой проекта. Разные руководители проектов делают это по-разному. Кто-то ведет себя расковано и неформально, с шутками и дружеским подтруниванием, другой достаточно формально, но каждый из хороших менеджеров проектов, которых я видел, находил с командой общий язык, команда проекта уважала их. Это очень важно. Не важно, какой стиль вы выберете, важны здоровые, нормальные и профессиональные отношения в команде.
 
Грамотные коммуникации
Каждый из руководителей проектов, о которых идет речь в этой статье уделял огромное внимание коммуникациям. Они планировали коммуникации заранее, документировали их, уделяли столько времени, сколько было необходимо, чтобы убедиться, что вся информация, которую они передали, дошла до адресата и тот понял ее именно так, как они задумывали. Вообще, чем они отличались, так это разнообразием подходов к коммуникациям и средств коммуникаций и выбором из них наиболее эффективных для каждого конкретного случая. Необходимо обсуждение – устроим совещание, долгий разговор с другой страной – давайте воспользуемся skype, одобрение принципиальных решений – еженедельная встреча управляющего комитета, и т.д.
 
Планирование
Все грамотные руководители проектов планируют свои действия, это факт. Вы можете выполнить простой, короткий проект без планирования, но вы не сможете выполнить мало-мальски сложный проект без составления плана проекта. Планирование в исполнении грамотного руководителя проекта – это поиск некого баланса. Они не пытаются спланировать тотально весь проект, и в то же время блоки работ оказываются именно такого размера, что бы быть управляемыми. Более того, планируются не только работы, но и коммуникации, ресурсы, риски, закупки, в общем, практически все аспекты проекта.
 
Управление рисками
Хороший менеджер проекта должен управлять рисками. У кого-то это более формальный процесс с анкетированием, мозговым штурмом, еженедельными встречами и тому подобным, у других, менее формальный. В управлении рисками многое зависит от проекта, от степени его определенности, сложности и длительности. В любом случае, управление рисками должно быть оправданным. Ни один из описываемых руководителей проектов не уделял рискам слишком много времени, одновременно с этим, ни один из них не забросил управление рисками в середине проекта (часто встречающаяся ситуация), а довел до конца.
 
Управление изменениями
Каждый из описываемых мной руководителей проекта управлял изменениями. Неконтролируемые изменения – основная беда неопытных руководителей проектов. Чем более опытными они становятся, тем более сопротивляются подаваемым запросам на изменения. Однако, действительно эффективные руководители проектов умеют отличать необходимые изменения от тех, которых можно избежать и, соответственно умеют убедить заказчика, либо не вносить изменения, либо внести их позже, в следующем релизе/на следующей фазе проекта.
 
Контроль качества
Хороший менеджер проекта всегда контролирует качество. В данном случае часто путают понятие качество и сорт. Продукт может быть низкого сорта, но нельзя допустить, чтобы продукт был низкого качества. В ИТ это решается тщательным планированием архитектуры разработок/доработок/интеграции, а также различными видами тестирования (модульное, интеграционное, регрессивное тестирование). Все руководители проектов, о которых я пишу, уделяли много внимания тестированию, в мелочах прописывая и согласовывая сначала подход к тестированию, затем тестовые сценарии и выполняя тестирования с фиксированием результатов.
 
Предупреждение возникновения проблем
Все из описываемых мною руководителей проектов старались предупреждать возникновение проблем, а не решать их. Это более логично. Собственно именно поэтому у них всегда было много работы, но мало авралов.
 
Постоянный контроль
Следующее, чем примечательны хорошие руководители проекта – постоянный контроль. Это отнюдь не значит, что они бегают от сотрудника к сотруднику, постоянно звонят подрядчикам и партнерам и интересуются, как продвигаются работы. Это значит, что руководитель проекта разрабатывает систему контроля, и затем пользуется ею. Все просто, например, сотрудники контролируются встречами по статусу проекта еженедельно, партнеры и подрядчики, отчетом о статусе проекта раз в две недели, и кроме того, отслеживаются задачи на критическом пути, по которым периодичность отчетности меняется. Разумеется, в данном случае я привел пример, только для того, чтобы показать, что в постоянном контроле важна системность подхода и у хорошего менеджера проекта она есть.
 
Использование чужого опыта
Ну и, наконец, каждый из них использовал опыт других людей. Некоторые из них, работая в крупных консалтинговых компаниях, звонили коллегам и консультировались с ними, другие искали усвоенные уроки в корпоративных базах знаний или, иногда просто договаривались с незнакомыми людьми, обладающими необходимым опытом о встрече с целью поделиться знаниями. Кстати, многие, даже незнакомые люди, идут на контакт и делятся своими знаниями, т.ч. не стесняйтесь спросить
 
Успешных вам проектов!