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

Статистика

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

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


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

 

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

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

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

www.lessonslearned.ru/lessons-learned-94

 

Усвоенный урок №95. Не распыляйся. Сосредоточься на действительно важных вещах.

Ситуация:
Вы руководитель сложного и объемного проекта внедрения ERP системы. С начала проекта вы успели провести тендер, этап выбора системы и выбора подрядчика, а также Gap анализа. В настоящий момент выполняются доработки системы. С каждым днем, нарастает количество работ, которые сваливаются вам на голову. У вас нет помощника и не будет, т.к. руководство отклонило вашу просьбу о его выделении. Вся команда управления проектом зашивается также как и вы. Это стало уже нормой, рабочий день с 9 до 22 или 23 часов. И даже учитывая то, что вы и ваша команда работает по 12-13 часов в сутки уже на протяжении месяца и периодически выходит на работу по выходным, количество проблем только возрастает. В один из дней возникает проблема, которая ставит под угрозу существование проекта в принципе. Вы пытаетесь проанализировать, каким образом вы прозевали возникновение такой глобальной проблемы и понимаете, что не уделяли должного внимания многим вещам, в том числе управлению рисками. Это произошло из-за вашей перегрузки работой на проекте.
 
Вывод:

 www.lessonslearned.ru/lessons-learned-95

 

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

Ситуация:
Данный урок основан на том же примере, что и усвоенный урок №84 и похож на него. Но суть различная.
Вы - руководитель проекта, включающего в себя как организационные преобразования, так и внедрение в компании специфического компьютерного оборудования и программного обеспечения по защите информации. Вы провели тендер и согласовали договор, в котором прописали все работы, которые выполняет нанятый подрядчик. Указать в договоре номенклатуру поставляемого оборудования и программного обеспечения в настоящий момент, вы не можете, т.к. она определяется в ходе проекта, на его первом этапе. Однако, поскольку подрядчик примерно представляет объем закупаемого оборудования, вы зафиксировали в договоре верхнюю границу стоимости оборудования, т.е. риск перерасхода бюджета, выделенного на оборудование, сверх данной стоимости несет подрядчик. В процессе переговоров вы уточнили, что стоимость пусконаладочных работ входит в стоимость оборудования, но ввиду невысокой предполагаемой стоимости данных работ вы не сфокусировали внимание на данных работах и не зафиксировали однозначно в контракте, что стоимость данных работ входит в стоимость оборудования. В результате, когда работы по проекту подошли вплотную к закупке оборудования и его внедрению, оказалось, что подрядчик ошибся с расчетом предполагаемого к закупке оборудования и его объем вышел больше предполагаемого, но вы все еще укладываетесь в бюджет по оборудованию. Однако, стоимость пусконаладочных работ составляет  почти 30% от стоимости оборудования (из-за специфичности и редкости оборудования), а по причине возросшего объема закупки данная сумма стала значительной. Поставщик, видя нечеткую формулировку в договоре, пытается повесить оплату пусконаладочных работ на вашу компанию.
 
Вывод:

www.lessonslearned.ru/lessons-learned-96

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

В разделе "Книги и рецензии" размещена рецензия на книгу Peter Taylor "The lazy project manager. How to be twice as productive and still leave the office early". Книга интересна и написана профессионалом своего дела.


Опросы

 

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

 

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

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

 

Статьи

Двойные стандарты, польза или вред?

Автор: Алексей Ким, akim@lessonslearned.ru, www.lessonslearned.ru
 
  Все руководители проектов, где велика вовлеченность подрядчика в проект, наверняка сталкивались с проблемой управления проектом, которую можно сформулировать следующим образом, применять ли в отношении команды со стороны своей компании те же методы и стандарты, что и в отношении подрядчика или использовать двойные стандарты. Собственно, проблему двойных стандартов и хотелось бы рассмотреть в данной заметке.
 
  Чаще всего, проблема двойных стандартов появляется в такой области управления проектами, как управление коммуникациями. При согласовании документов, при письменном обсуждении каких-либо вопросов, при разрешении проблем и т.п. Думаю, более наглядно, данная проблема проектов будет показана на примере.
 
  Допустим, на проекте все коммуникации между вашей компанией (заказчиком) и подрядчиком происходят через менеджеров проекта со стороны подрядчика и заказчика.

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

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

b) Не принимать двойные стандарты и предложить куратору проекта другую формулировку

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

c) Принять двойные стандарты и выслать поставщику вопрос в том виде, в котором он был задан.

Плюсы:
  1. Простота коммуникаций. Вам не нужно вникать в вопрос и вам не нужно усложнять свои коммуникации. Вы работаете как ретранслятор, вы получили информацию и передали ее по адресу.
  2. Отношения с куратором проекта не ухудшатся, и вы избегаете возможного негативного влияния на ход проекта.
  3. Вы избегаете требовательности по отношению к старшему по должности внутри компании, что не ухудшит на вашу карьеру.
 
Минусы:
  1. Отношения с подрядчиком, возможно, станут хуже из-за двойных стандартов.
  2. Вы не будете уверены в том, что куратор проекта получит ответ именно на тот вопрос, который подразумевал.
  3. Если процедура коммуникаций зафиксирована в плане коммуникаций, и одинакова для обеих сторон, то вам придется нарушить ее.
  4. Вы потеряете возможность лучше разобраться в вопросе, который может повлиять на ход проекта.
  5. Сроки разрешения вопроса могут затянуться, т.к. формулировка может быть не понятной поставщику и от вас не зависит время, потраченное на выяснение ее сути.
 
  И это только один пример. Думаю, понятно, что подобная ситуация с двойными стандартами может сложиться в любой области. А вы как считаете, пользу или вред приносят двойные стандарты на проекте по отношению к команде заказчика и подрядчика?

 Обсудить статью

 
В избранное