Отправляет 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 за неделю
←   Все выпуски   →

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


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

 

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

 

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

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

www.lessonslearned.ru/lessons-learned-100

 

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

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

www.lessonslearned.ru/lessons-learned-101


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

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


Опросы

 

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

 

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

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

 

Статьи

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

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

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

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

 

 
В избранное