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

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

Усвоенный урок №104. Избегайте избыточных требований

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

Вывод:

www.lessonslearned.ru/lessons-learned-104

Усвоенный урок №105. Не бойтесь менять подходы для решения проблем

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

Вывод:

www.lessonslearned.ru/lessons-learned-105

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

В разделе "Книги и рецензии"ожидается пополнение в ближайшее время будет опубликована книга одного из российских менеджеров проектов - практиков.

Опросы

На сайте открылся новый опросник. Добро пожаловать. 

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

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

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

Статьи

Ключевые пользователи, команда технической поддержки и успешное внедрение

Источник: Алексей Ким. Написание устава проекта.
Управление проектами - №1 (18) 2010 - с.24. Публикуется с разрешения редакции.
 
В данной небольшой заметке хотелось бы рассказать о положительном опыте одного проекта внедрения. Как правило, запоминаются негативные моменты, но от положительного опыта пользы для будущих проектов больше, чем от отрицательного. Часто, во время проектов внедрения информационных систем недооценивается роль ключевых пользователей и службы технической поддержки для успеха проекта. Разумеется, многие скажут, что пользователи системы будут увольняться, что система и реализация процессов в системе не должны быть ориентированы на нужды конкретных людей, что этап технической поддержки наступает после завершения проекта. Все вышесказанное верно. Но, тем не менее, очень важно уделять внимание ключевым пользователям и службе технической поддержки. Мы ведь хотим внедрить систему, которой будут пользоваться, и пользоваться с удовольствием, а не которая будет установлена просто “для галочки”. Начну последовательно.
 

В одной компании (как всегда, это была компания “Рога и Копыта”) открыли крупную и амбициозную программу. Программа подразумевала открытие нового направления бизнеса, под который необходимо было, в том числе, приобрести и внедрить новую ИТ систему. Проект по внедрению системы благополучно инициировали, наняли консультантов, провели тендер, выбрали систему и приступили к внедрению. Разумеется, внедрить крупную систему без доработок невозможно. Поэтому, был проведен этап анализа разрывов (GAP analysis) между функциональностью системы и требованиями бизнеса. На каждый найденный разрыв была написана техническая спецификация, а на настройки самой системы – техническое задание. С момента написания технического задания на проекте активно использовалась группа сотрудников, выступавших экспертами в своих областях. Эти эксперты планировались как ключевые пользователи системы. Именно они должны были обучиться работе в системе и в будущем, составить некий центр экспертизы компании по ИТ системе. Так оно и получилось. Момент обучения работе в системе предшествовал утверждению технических спецификаций и технического задания, поэтому у группы сформировалось понимание работы системы до того, как она была доработана и запущена.
 
Обучение группы ключевых пользователей системы проводилось в два этапа. Первый этап подразумевал обучение пользователей стандартной функциональности системы. Уже на этом этапе возникло большое количество вопросов и список разрывов был пополнен. Результатом данного обучения стало понимание принципов работы системы, того что в ней реализуемо, а что нет. На втором этапе, обучение проходило на прототипе системы, созданном для компании. На данном этапе обучения “всплыли” тонкие нюансы и достаточно сумбурное понимание функционирования системы, полученное в результате первого обучения, структурировалось. В результате, команда экспертов в различных областях бизнеса компании превратилась в экспертов по системе. Они не лезли в дебри технологий и технических нюансов, но отлично понимали настройки системы и знали тонкости использования функционала. Кроме того, побочным эффектом длительного совместного обучения явилось сплочение команды, возникновение командного духа, интереса к внедрению. Впоследствии, эти ключевые пользователи стали опорой в своих подразделениях в части внедряемой системы. Они выполняли функции аналитиков и консультантов, перекладывали требования своих бизнес подразделений на функциональные требования к системе, обучали пользователей, продумывали возможное будущее развитие системы. После внедрения, приказом генерального директора, эти ключевые пользователи были назначены лицами, ответственными за различные функциональные области системы.
 
Вторым фактором успешного внедрения стало раннее подключение команды технической поддержки производителя системы. Переход проекта на стадию технической поддержки, как правило, болезненный процесс. Руководитель проекта уже снял с себя полномочия и ответственность, пользователи уже начали находить ошибки в системе, а техническая поддержка еще не имеет экспертизы в доработках системы. Так обычно происходит. На данном проекте было сделано немного иначе. Команду технической поддержки со стороны заказчика начали привлекать к проекту еще со стадии написания технического задания (правда, в весьма умеренном объеме), со стороны производителя – со стадии тестирования системы. Раннее привлечение команд технической поддержки к работам над системой позволило оперативно исправлять выявленные пользователями ошибки (количество которых, к окончанию проекта, удалось снизить благодаря тщательному тестированию системы), а также регламентировать все спорные административные моменты, которые не были прописаны в соглашении об уровне сервиса.
 
Таким образом, наличие грамотных, обученных системе ключевых пользователей, имеющих экспертизу во всех областях бизнеса компании, привлечение их и служб технической поддержки на ранних стадиях проекта явилось ключевыми факторами успешного внедрения. Систему не только внедрили, но внедрили в рамках требований, и в соответствии с ожиданиями пользователей

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

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

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

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

 www.lessonslearned.ru/lessons-learned-102

Усвоенный урок №103. Не допускайте разрастания списка лиц, согласующих документ

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

www.lessonslearned.ru/lessons-learned-103

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

В разделе "Книги и рецензии" размещена информация по книге "Управление проектами. Полный курс MBA", авторы: Полковников Алексей Владимирович и Дубовик Михаил Федорович.

Опросы

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

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

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

Статьи

О gold plating и вреде "экстра"

 Источник: Алексей Ким. О gold plating и вреде "экстра".
Управление проектами - №1 (18) 2010 - с.23. Публикуется с разрешения редакции.
  
Как правило, на проектах внедрения информационных систем длительностью от полугода, где работы проходят в более-менее нормальном режиме, представители подрядчика (внедряющей компании) и заказчика успевают установить товарищеские отношения. Это не секрет, и происходит подобное по причине того, что представители заказчика и подрядчика на проекте решают совместные проблемы, идут на компромиссы, пытаются понять друг друга. Как правило, подобные отношения устанавливают руководители проектов, а также представители команды проекта, активно вовлеченные в проектную работу. Подобные товарищеские отношения полезны для проекта, они повышают мотивацию, эффективность, кроме того, общаясь между собой, члены команды получают знания и опыт друг друга, повышая уровень квалификации, но иногда, подобные отношения могут принести вред. Предлагаю рассмотреть подобную ситуацию.
 

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

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

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

Изученный урок №100. При разработке документов ориентируйся только на авторизованный источник информации

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

www.lessonslearned.ru/lessons-learned-100

Изученный урок №101. Оценивайте работы с точки зрения их влияния на проект при оценке и расстановке приоритетов

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

www.lessonslearned.ru/lessons-learned-101

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

В разделе "Книги и рецензии" размещена информация по книге "Управление проектами. Полный курс MBA", авторы: Полковников Алексей Владимирович и Дубовик Михаил Федорович.

Опросы

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

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

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

Статьи

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

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

Реестр рисков
На проектах я веду реестр рисков в файле Excel. Вообще, насколько я знаю, в Microsoft Project Server есть возможность привязки рисков и вопросов проекта к работам проекта и к проекту в целом используя представления Sharepoint Portal и Sharepoint Services. Однако, я ими не пользуюсь, привычка, наверное. Впрочем, большинство полей в моем Excel файле совпадают с полями рисков в Project Server. Реестр рисков на проекте используется не так часто, как реестр открытых вопросов, однако данный реестр важен для успеха проекта. У меня реестр рисков содержит следующие поля:
 
Номер или код – уникальный идентификатор вопроса. Служит для идентификации рисков.
 
Риск – поле содержащее наименование риска. Я именую риски их содержимым, тем самым избегаю необходимости введения дополнительного поля.
 
Категория – для себя мы выделили четыре категории рисков (внешние, организационные, управленческие и технологические риски). Категоризация помогает сгруппировать риски для более подробного рассмотрения.
 
Вес – вес риска помогает отделить те риски, которые признаются весомыми для проекта и требуют плана реагирования от прочих рисков проекта. Вес риска является произведением вероятности риска на возможный ущерб от реализации этого риска.
 
Дата открытия риска – дата регистрации риска, т.е. занесения его в реестр.
 
Дата реализации риска – дата когда риск реализовался.
 
Срок – если риск актуален до какой-то даты, то у него заполняется поле срок.
 
Триггер – если реализация срока привязана к какому-то событию, то в данное поле заносится это событие.
 
Последствия – в это поле заносится информация о последствиях реализации риска.
 
Владелец – в данное поле заносится владелец риска, т.е. сотрудник, отвечающий за реализацию/нереализацию данного риска. По умолчанию – менеджер проекта, но может меняться.
 
Статус – статус риска. У меня в реестре, данное поле может принимать только три значения (Открыт, Активен, Закрыт).
 
Дата закрытия – дата закрытия риска. Теоретически, один раз закрытый риск может быть повторно открыт, но на практике я с этим не сталкивался.
 
Стратегия – в данное поле заносится стратегия работы с риском, описание в общих словах, что именно планируется сделать по данному риску.
 
Комментарии – поле, куда заносятся комментарии.
 
Реестр рисков на наших проектах ведется с самого начала проекта (как и прочие реестры). Изначально его формирует менеджер проекта. В этом очень помогают усвоенные уроки с других проектов. После формирования команды проекта мы работаем с реестром рисков следующим образом. Для начала мы заполняем его всеми мало-мальски реалистичными рисками проекта, определяемыми коллективно на первой сессии по управлению рисками проекта. Цель первой сессии – идентификация как можно большего количества рисков, существующих на проекте. На данном этапе мы не смотрим на их важность или вероятность, т.к. исходим из предпосылки, что и важность и вероятность риска в ходе проекта могут меняться и риски невероятные сегодня могут вполне стать реальной угрозой через квартал или полугодие. После идентификации рисков команда присваивает каждому риску категорию. Затем, выбирается порог для отслеживания рисков (обычно, среднее значение между максимальным весом риска и минимальным). Независимо друг от друга каждый член команды проекта присваивает оценки для вероятности и ущерба каждого риска, после чего вычисляется значение веса риска (произведение вероятности на возможный ущерб), по мнению каждого сотрудника. Вес риска в реестре берется как среднеарифметическое значение из весов, проставленных членами проектной команды. В случае, если вес риска выше порогового значения, для него разрабатывается стратегия реагирования на риск. PMI рекомендует, помимо указанного плана, разрабатывать план на случай, если план реагирования не сработает. Честно признаюсь, такой план мы не разрабатываем.
 
Риски пересматриваются раз в неделю, либо раз в две недели. Наиболее важные на момент отчета риски включаются в отчет о статусе проекта, предоставляемый руководству вместе с информацией о ходе работы с риском. Все работы на проекте ведутся с учетом всех идентифицированных рисков. Очень важно начать работу с рисками на наиболее ранней стадии проекта, т.к. учет рисков и их последствий для проекта может значительно повлиять на решения и работы, принимаемые и выполняемые на проекте.
 
Не забывайте про риски и успешных вам проектов!

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

  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% от стоимости оборудования (из-за специфичности и редкости оборудования), а по причине возросшего объема закупки данная сумма стала значительной. Поставщик, видя нечеткую формулировку в договоре, пытается повесить оплату пусконаладочных работ на вашу компанию.
 
Вывод:

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

В разделе "Книги и рецензии" размещена рецензия на книгу 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. Сроки разрешения вопроса могут затянуться, т.к. формулировка может быть не понятной поставщику и от вас не зависит время, потраченное на выяснение ее сути.
 
  И это только один пример. Думаю, понятно, что подобная ситуация с двойными стандартами может сложиться в любой области. А вы как считаете, пользу или вред приносят двойные стандарты на проекте по отношению к команде заказчика и подрядчика?

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

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

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

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

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

www.lessonslearned.ru/lessons-learned-92

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

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

www.lessonslearned.ru/lessons-learned-93

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

 Запущен новый раздел "Книги и рецензии". В данном разделе публикуются рецензии на книги, а также книги, распространяемые в электронном виде на тему управления проектами и смежные темы.

Опросы

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

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

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

Статьи

Проведение тендеров (торгов) как часть процесса управления закупками. Часть 2.

Автор: Алексей Ким, akim@lessonslearned.ru, www.lessonslearned.ru
 
Первая часть статьи находится здесь.
 
Параллельно с подготовкой тендерной документации вам необходимо определить список участников. Обычно, рынок компаний, будущих участников тендера известен, но, на данном этапе важно зафиксировать критерии, по которым производится отбор участников. В PMBoK 4-й редакции, критерии выбора поставщика являются выходом процесса планирования закупок.
 
Для примера, возьмем проект, описанный в предыдущей части. Проект по приведению компании в соответствие с 152-ФЗ «О персональных данных». Давайте подумаем, откуда можно взять информацию о компаниях, работающих на рынке информационной безопасности? Правильно, можно поискать рейтинги компаний, занимающихся информационной безопасностью, можно почитать специализированные издания, посетить выставки и семинары по информационной безопасности и т.д. Уверен, компаний наберется множество и на просмотр их презентаций уйдет огромное количество времени. Чтобы сократить список, определите критерии выбора, критерии попадания в короткий список потенциальных поставщиков. Например, вы доверяете компаниям, которые работают на рынке информационной безопасности менее года? Вот и первый критерий. Другими критериями отсева могут стать наличие завершенных проектов в компаниях вашей отрасли, наличие у компании сертификатов по контролю качества, наличие в компании сертифицированных специалистов для вашего проекта, и т.п.