Вы - руководитель проекта по информационной безопасности со стороны
заказчика. Вы провели тендер на выбор подрядчика на работы по
технической защите конфиденциальной информации. Выбрав победителя, вы
уведомили остальных участников о выборе победителя и сообщили об
окончании тендера. Однако, в ходе дальнейших работ подрядчик потребовал
большую сумму денег, чем было оговорено в коммерческом предложении.
Вывод:
По окончанию тендера постарайтесь подстраховаться. Не отказывайтесь
от услуг №2 (компании, занявшей в тендере второе место). Постарайтесь
договориться с №2 о возможном переходе к ним в случае, если контракт с
№1 будет разорван.
Вы - руководитель проекта по информационной безопасности со стороны
заказчика. Вы провели тендер и, рассмотрев коммерческие предложения
выбрали наиболее выгодное. Объявили победителя тендера и согласовываете
договор. Однако, в процессе согласования договора, у вас с подрядчиком,
возникли серьезные расхождения во мнениях, которые очень сложно
урегулировать.
Вывод:
Страйтесь объявлять победителя по завершению согласования и
подписания договора. Пункт об объявлении победителя можно прописать в
правилах тендера.
Ситуация:
Вы – руководитель проекта внедрения ИТ системы. При планировании
проекта, вы предусмотрели вашу замену на случай отпуска или болезни
куратором проекта. В план коммуникаций вы включили пункт, согласно
которому, куратор проекта получает копии переписки с контрагентами,
отчеты о статусе проекта, протоколы совещаний и т.д. Проект длится уже
семь месяцев и должен завершиться через пять месяцев. Все идет согласно
плану, и вы берете отпуск. Вернувшись из отпуска, вы обнаруживаете, что
проект все еще идет так, как было запланировано.
Вывод:
Вы поступили верно. Необходимо заранее планировать вашу возможную замену
на случай отпуска или болезни. Сотрудник, который будет вас замещать
должен быть в курсе ситуации на проекте, и иметь возможность быстро
найти всю необходимую ему информацию. В таком случае, вы сможете
провести отпуск, не отвлекаясь на телефонные звонки.
Ситуация:
Вы руководитель проекта внедрения информационной системы. Проект
находится на стадии согласования требований. Вы не можете согласовать
требования, т.к. руководители двух подразделений включают
взаимоисключающие требования. У вас есть вариант эскалации проблемы на
генерального директора либо попытаться все таки решить вопрос
самостоятельно.
Вывод:
Лучше не спешить с эскалацией проблемы выше. Написание требований -
важная часть проекта, но она находится в начале проекта. Выберите срок, к
которому проблема должна быть решена и решайте ее.Устройте встречу с
обоими руководителями подразделений и попытайтесь определить, что будет
лучше для компании. Вы руководитель проекта и ваша задача решать
проектные проблемы. Заваливая руководство проблемами, вы рискуете не
только своей репутацией, но и тем, что когда вам действительно
понадобится поддержка руководства, вы ее получите не в том объеме,
который ожидали.
Ситуация:
Вы руководитель внедрения ИТ системы. Проект рассчитан на год. У вас в
подчинении команда из 3 аналитиков, 3 разработчиков и системного
администратора. В процессе планирования у вас возникает выбор:
планировать однотипную работу на один и тот же ресурс, создавая
специализацию (например, аналитик по основной операционной деятельности
компании, аналитик по финансам и бухгалтерскому учету, программист по
интеграции), либо создавать многопрофильных специалистов, распределяя
однотипную работу между разными исполнителями.
Вывод:
Старайтесь создавать специалистов. Если ваши сотрудники будут иметь
специализацию на проекте, работа по их областям пойдет быстрее.
Специализация всегда дает прирост производительности. Однако, ваши
специалисты также, должны иметь понимание что происходит вне зоны их
экспертизы.
Опросы
Второй опрос по управлению проектами планируется к запуску на следующей неделе. Опрос должен
дать ответ на на вопрос о слабых сторонах руководителей проектов в
странах СНГ с точки зрения других участников проекта. Следите за
изменениями, анкета скоро будет доступна для заполнения.
Продолжается
первый опрос по управлению проектами,
направленный на выявление слабых областей знаний руководителей проектов в
России и СНГ. В настоящий момент заполнено более 50 анкет. Пожалуйста,
заполните опрос, если вы этого еще не
сделали. Заполнение анкеты займет всего 1-2 минуты.
Первый
опрос по управлению проектами находится здесь.
Все знают, что при закрытии проекта необходимо составлять некий
документ, называемый lessons learned. У кого-то этот документ является
самостоятельным документом, у других входит как часть отчета о закрытии
проекта. Этот документ необходим для улучшения качества и упрощения
ведения последующих проектов и аккумулирует в себе весь опыт, полученный
на проекте. Документ изученные (усвоенные) уроки содержит в себе
положительные ситуации, которые возникали на проекте и которые могут
быть использованы на других проектах и отрицательные моменты, проблемы и
инциденты, а также способы их решения.
Все вышеперечисленное - известные вещи. Но вот подробности, например,
когда составляются изученные уроки или как их нужно вести, слабо
описаны. Попробую рассказать вам, как мы ведем свои lessons learned.
Прежде всего хочу сказать, что мы ведем документ усвоенные уроки в
течении всего проекта и постоянно, т.е. примерно так же, как и журнал
вопросов. Это значит, что для того, чтобы занести какой-то пример в
изученные уроки мне нет необходимости ждать встречи с командой проекта. Я
просто беру и записываю его. Это позволяет не потерять идею,
зафиксировать то, что должно быть зафиксировано в lessons learned. Все
свои записи мы ведем в Excel файле, выложенном на сервере проектов. У
нас используется Microsoft Project Server. В сервере проектов для
каждого проекта можно создать рабочую область на Microsoft Sharepoint
Services. Плюс данного решения состоит в том, что у вас сразу есть
контроль версий и коллективная работа с одним документом. В самом файле у
нас есть всего шесть полей:
- Проект
- Номер записи
- Наименование записи
- Ситуация
- Вывод
- Автор
Думаю, стоит еще добавить поле «Дата записи».
Обычно, наши lessons learned отвечают на один или несколько вопросов
из списка, приведенного ниже:
- Что было сделано правильно, а что нет
- Какие ошибки были допущены?
- Что можно было сделать лучше?
- Что бы вы сделали иначе?
- Какие уроки можно почерпнуть на будущее?
- Упущенные возможности
Источником изученных уроков, часто становятся встречи, в общем-то,
предназначенные для других целей. Например, во время обсуждения рисков
могут возникнуть идеи, которые проверяются и фиксируются в изученных
уроках. Я их записываю себе в ежедневник, а после проверки переношу в
файл.
Разумеется, используются и традиционные способы пополнения изученных
уроков. Встреча с командой управления проектом и разбор, что сделано
хорошо, что могло быть сделано лучше и т.д.
По поводу мотивации руководителя проекта писать или изучать lessons
learned могу сказать следующее: тот, кто один раз прочитал грамотно
написанные изученные уроки, впоследствии всегда будет их читать, т.к.
польза от них очень чувствительна. И никаких дополнительных действий для
мотивирования руководителя проекта читать lessons learned не требуется.
Молодых руководителей проекта, можно обязать вписывать наименования
проектов, по которым были прочитаны изученные уроки в один из документов
при инициации проекта. Ну, а обязать написать lessons learned – вообще
просто. Достаточно установить правило, что руководитель проекта не может
закрыть проект до тех пор, пока lessons learned не будут написаны. Вот,
наверное, и все, что я хотел сказать.