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

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


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

 
В избранное