Отправляет 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
29
30
Автор
lessonslearned.ru

Статистика

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

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


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

 

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

Усвоенный урок №97. Настаивайте на своей точке зрения, если вы уверены в ней

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

www.lessonslearned.ru/lessons-learned-97

 

Усвоенный урок №98. Вносите изменения в договор последовательно

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

www.lessonslearned.ru/lessons-learned-98

 

Усвоенный урок №99. Настаивайте, чтобы от подрядчика, в продаже проекта участвовал будущий менеджер проекта

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

www.lessonslearned.ru/lessons-learned-99

 

 

Книги и рецензии

В разделе "Книги и рецензии" размещена рецензия на книгу Элияху Голдратта "Цель. Процесс непрерывного совершенствования". Книга о подходе к управлению, скорее даже об управленческой философии под названием "Теория ограничений" (TOC). Данный подход может применяться в различных областях деятельности, в том числе в управлении проектами. Книга написана в жанре ставшего популярным во всем мире бизнес-романа. Рекомендую.


Опросы

 

Продолжается второй опрос по управлению проектами. Опрос направлен на определение образования менеджеров проектов. Анкета находится здесь. Пожалуйста, заполните анкету (1-2 минуты).

 

Продолжается первый опрос по управлению проектами, направленный на выявление слабых областей знаний руководителей проектов в России и СНГ. Пожалуйста, заполните опрос, если вы этого еще не сделали. Заполнение анкеты займет всего 1-2 минуты.

Первый опрос по управлению проектами находится здесь.

 

Статьи

Рабочие документы проекта. Реестр открытых вопросов.

Автор: Алексей Ким, akim@lessonslearned.ru, www.lessonslearned.ru

Много статей написано про такие основные документы управления проектами, как, например, устав проекта, или отчет о статусе проекта или план проекта. Все эти документы повышают формализацию проекта и могут использоваться формально многими участниками проекта. Разумеется, они необходимы и никто этого не отрицает. Однако, часто, как-то забывают о рабочих инструментах менеджера проекта, тех документах, которые всегда открыты у него на рабочем столе компьютера и которые используются ежедневно. В этой заметке, я бы хотел освятить минимальный, на мой взгляд, набор документов, используемый менеджером проекта и командой управления проектом. Это набор рабочих документов, не нуждающихся в утверждении или согласовании кем-либо из руководства, но при этом значительно облегчающий жизнь руководителю проекта и его команде. Каждый документ из представленного набора представляет собой реестр. Их использование не обязательно, но очень желательно. В случае если проект длится более полугода, либо является нетиповым, данные реестры станут, практически, палочкой-выручалочкой для руководителя проекта. Также, следует помнить, что возможно в будущем, вам или вашим коллегам придется вести подобный проект, и тогда ваши рабочие документы станут неоценимым подспорьем. Заполняйте их регулярно и аккуратно и впоследствии, вы удивитесь как много пользы из них извлечете. Я использую следующий набор документов: 1. Реестр открытых вопросов 2. Реестр рисков 3. Реестр корреспонденции 4. Реестр заинтересованных сторон 5. План счетов (реестр оплат). Эти и некоторые дополнительные реестры я опишу в данной и последующих заметках. Итак, приступим.
 

1. Реестр открытых вопросов
Представляет собой файл, в который заносятся все вопросы, возникающие на проекте. Данный реестр очень важно вести постоянно и аккуратно. Для меня, данный реестр является основным рабочим документом и к концу проекта он обычно сильно разрастается. Принцип ведения реестра открытых вопросов следующий: возник вопрос – открыл реестр вопросов – поискал ответ на свой вопрос – если не нашел – занес свой вопрос в реестр. Для ведения реестра можно использовать просто таблицу Excel, хотя, например в MS Project Server, вопросы можно привязывать непосредственно к работам в плане графике. Я использую реестр вопросов со следующими полями:
 
Номер или Код – уникальный идентификатор вопроса. Как правило, просто порядковый номер с каждым вопросом увеличивающийся на единицу.
 
Наименование – собственно сам вопрос. Важно четко сформулировать вопрос и задавать его в той форме, в которой он описан в реестре. Тогда у вас не возникнет разночтений между вопросом, зарегистрированным в реестре и полученным на него ответом.
 
Реакция – описание тех действий, которые планируется выполнить для разрешения данного вопроса. Например, “направить вопрос юристам”. Данное поле помогает вспомнить, как именно решался вопрос.
 
Важность – у меня в реестре поле “Важность” может иметь только четыре значения: критическая, высокая, средняя и низкая. Данное поле помогает отобрать те вопросы, на которых необходимо сконцентрироваться в случае аврала, либо просто когда решить все вопросы вы не успеваете.
 
Статус – статус вопроса. В моем реестре все вопросы имеют статус либо “Открытый”, либо “Закрытый”. Статус “Закрытый” ставится только в случае полного ответа на вопрос.
 
Автор регистрации – в данное поле заносится автор вопроса. Помогает вспомнить в случае большого количества вопросов кого именно необходимо оповестить об ответе на вопрос помимо вас.
 
Дата регистрации – в поле заносится дата регистрации вопросов. Помогает отследить насколько быстро решаются вопросы и в дальнейшем, прогнозировать с какой минимальной скоростью могут быть решены вопросы. Например, через некоторое время после начала проекта, вы будет точно знать, какой минимум времени вам нужно закладывать на получение ответа на вопрос от финансового управления, юриста, заказчика или подрядчика. Разумеется, ориентироваться по этому полю для получения максимального срока ответа нельзя.
 
Ответственный – в случае, если вопрос достаточно сложен, его разрешение можно поручить кому-то из команды. Тогда этот человек становится ответственным за разрешение вопроса и его ФИО вписывается в данное поле.
 
Ожидаемая дата – заполняется не всегда. Дата, к которой вы ожидаете получить ответ на свой вопрос. Чаще всего, заполняется в случае, если вопрос задан кому-то из сотрудников, и получена ориентировочная дата когда вам ответят. Тогда, ориентируясь на данную дату, в случае отсутствия ответа, вы можете тактично напомнить об обещании.
 
Срок – заполняется не всегда. Если какой-то вопрос необходимо решить к определенной дате, то у него заполняется поле срок.
 
Дата решения – дата получения полного ответа на вопрос. Вместе с датой регистрации, заполнение данного поля поможет вам понять насколько быстро решаются вопросы.
 
Решение – описание ответа на вопрос.
 
Нужно отметить, что в реестр открытых вопросов я заношу не только вопросы, требующие ответа на них, но и вопросы, требующие простого контроля. Поскольку реестр вопросов – документ, с которым я работаю ежедневно, это помогает держать на контроле все что требуется. Ну и напоследок, хотелось бы сказать, что реестр вопросов – отличный источник усвоенных уроков.
 
Успехов вам в ваших проектах!

 

 
В избранное