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

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


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

 
В избранное