Управление проектами
Проект Антона Витязя
Управление коммуникациями проекта
Главное слово руководителя проектов
03 years
by Антон Витязь
in Управление коммуникациями проекта
«Спасибо» — важнейший атрибут любого общения. Всегда говорите спасибо всем,даже упаковщикам в супермаркете и кондукторамв автобусе. Улыбайтесь. Уважайте труд других людей и благодарите их за него. Будьте порядочны и честны. Испытывайте высочайшее уважение к каждому человеку, с которым в вступаете во взаимодействие.
Том Питерс, “Эти важные мелочи”
Данный тезис Питерса относится не только к руководителю проектов – он относится к любому менеджеру, и, собственно, просто к людям.
Обязательства, задачи и факт
03 years
by Антон Витязь
in Управление интеграцией проекта, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление коммуникациями проекта
Если мы рассмотрим коммерческие проект – в нем обязательно найдется место следующим вещам - соглашением о том что-то будет сделано (решено, доставлено, проверено) и будут достигнуты определенные результаты. В самом начале проекта это все находится в договоре и приложением с оценками плана работ. В ходе проекта появляются вопросы, проблемы, изменения.
Все это важные составляющие менеджмента проекта и их следует учитывать – можете помнить, можете копаться в десятке различных документов и почте. А я предпочитаю фиксировать это в списке. Это список обязательств. Природа их может быть разная – часть типов обязательств мы упомянули выше. Общее – срок, стоимость, приоритет, статус и прогресс. Наличие прозрачного и понятного списка обязательств с историей их возникновения и необходимым уровнем деталей по их выполнению – не только инструмент управленческого учета и управления ресурсами но и инструмент коммуникаций с заказчиком.
С обязательствами может быть связан перечень задач. Часть это перечня задач может быть видна заказчику, часть – нет. По задачам мы собираем факт затрат – времени сотрудников, компонент, закупок и т.п. Часть затрат получают оценку (по установленным в контракте часовым ставкам, по прайсу), могут быть предоставлены скидки.
Компоненты информационной среды управления проектами
03 years
by Антон Витязь
in MS Project, Sharepoint, Инструменты, Мониторинг и управление, Планирование, Управление интеграцией проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.
Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.
Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)
Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM 2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)
Календарь проекта и Фактические данные – тут рулит Microsoft Project.
Управленческий учет – фиксация затрат, закупок, выставление счетов, поступление денежных средств, выплата заработной платы и компенсаций участником проекта). В проектах где мотивация персонала крепко связанна с их ежедневным вкладом в проект а их бонусы зависят от успеха проекта – крайне важно наладить прозрачную процедуру для перетока информации из записей проекта, плана проекта и фактических данных в управленческий учет.
Опубликована книга Collaborative Project Management Guide от brightwork
03 years
by Антон Витязь
in Sharepoint, Инструменты, Полезные ссылки, Управление интеграцией проекта, Управление коммуникациями проекта
Ссылка на книгу – правда это скорее большая статья
Заход на регистрацию для получения книги и дополнительных материалов тут – http://www.brightwork.com/webcasts/collaborative_project_management.asp?event=4
Число возможных коммуникаций: N(N-1)/2
03 years
by Антон Витязь
in Сертификация, Управление коммуникациями проекта
Сегодня небольшая формула для вашего внимания. Эта формула позволяет оценить каналы коммуникаций в проекте. Как вы могли уже догадаться N – это количество членов в команде.
Подробнее эта формула раскрыта в статье Jeff Hodgkinson - http://www.asapm.org/asapmag/articles/CommunicationKey.pdf
PS А еще это вопрос на экзамене PMI!
Сделать сделали, а передать то – забыли!
03 years
by Антон Витязь
in Внедрение, Завершающие, Инициация, Исполнение, Планирование, Управление интеграцией проекта, Управление содержанием проекта, Управление качеством проекта, Управление коммуникациями проекта, Управление рисками проекта
Среди ошибок проектных менеджеров при разработке новых ИТ сервисов встречается ошибка отсутствия блока необходимых работ по передаче сервиса в промышленную эксплуатацию.
Эта ошибка коренится в том что проектный менеджер забывает включить в перечень ключевых заинтересованных лиц ИТ менеджеров по операциям:
- менеджеров сервиса
- менеджеров по обслуживанию пользователей,
- техническая поддержка – контакт центр поддержки ИТ
Какие могут возникнуть риски? Масса!
Риск проблем с технической поддержкой. Уже во второй половине проекта часто начинается доносится тревожный звоночек – некоторые пользователи, которые участвуют в ознакомлении с первыми релизами продукта, вместо обговоренного контакта с менеджером проекта начинают по привычке звонить в техническую поддержку. Техническая поддержка может по разным причинам сделать следующее:
- Отказать пользователю в обслуживании – что создаст негативное впечатление о проекте
- Дать неверный совет по использованию ПО – что может привести к негативному впечатлению о продукте
- Дать обещание ответить пользователю и не выполнить обещание в срок – пока поддержка начнет искать кто реально может обслужить данный вопрос. Хуже всего если в технической поддержке просто забросят вопрос.
Конфликт с другим сервисом находящимся в промышленной эксплуатации. Хуже всего если это важный операционный сервис критичный для работы бизнеса. Данный конфликт может создать проблемы для текущих операций пользователей. Кроме всего прочего это может косвенно указать на архитектурные ошибки или ошибки в планировании развертывания – связанные с тем что не были учтены все сервисы работающие у конечных пользователей продукта.
Что необходимо сделать менеджеру проекта:
- Обязательно включить в перечень заинтересованных лиц менеджеров по ИТ операциям. Найти всех кто отвечает за работу с пользователями, техническую поддержку. Включить в перечень ключевых лиц в работу над архитектурой, развертыванием и тестированием. Обязательно в этап передачи в эксплуатацию и go live.
- Определить порядок приема в эксплуатацию. Какие внутренние стандарты приняты в компании по передачи ИТ сервисов в эксплуатацию?
- Вовлечь в работу и информировать. Делать рассылки о всех операциях в рамках проекта которые касаются конечных пользователей. Установить процедуру согласования подобных операций.
- Включить в план проекта работы по обучению технической поддержки и менеджеров по ИТ операциям на всех стадиях проекта – от ознакомительной на ранней стадии, совместной работы над архитектурой, планами по развертыванию и тестированию до конечного обучения.
Критичность закрытия фаз/итераций. Пример из практики
03 years
by Антон Витязь
in Анализ, Завершающие, Инициация, Исполнение, Мониторинг и управление, Планирование, Процессы, Управление интеграцией проекта, Управление содержанием проекта, Управление сроками проекта, Управление стоимостью проекта, Управление качеством проекта, Управление человеческими ресурсами проекта, Управление коммуникациями проекта, Управление рисками проекта, Управление поставками проекта
Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.
Сам факт закрытия фазы позволяет:
- показать промежуточный результат в проекте
- согласовать с заказчиком понимание где сейчас находится проект
- отметить срез ключевых показателей проекта – по срокам, стоимости и объему работ
- определить легитимную основу для дальнейших действий
- снизить риски разногласий, проблем в понимании достигнутых договоренностей и результатов
- приучить заказчика к умению закрывать проект – приучать к этому нужно с ранних этапов, делать это системно по четко определенной процедуре
- выстраивать логическую связь от достигнутых результатов к запланированном на следующем этапе
Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что
- аналитический документ и зменился более чем на половину
- объем работ вырос в полтора раза
- было потеряно около трети времени на разработку в следствии кардинального изменения
- существенно изменились сроки проекта
- поставщик понес убытки на потерянном объеме работ
- клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
- клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта
Коммуникации по документу
03 years
by Антон Витязь
in Управление коммуникациями проекта
По ключевым документам следует ответить на следующие вопросы:
- Кто готовит документ?
- Кто согласовывает документ?
- Кто визирует документ?
- Кто будет читать документ?
- Когда? (по всем вопросам выше)
- Когда будет обсуждаться документ? В каком составе?
- Кому он должен быть представлен для подписания?
- Какой шаблон документа принят в организации?
- Знакомы ли в организации с данным типом документа?
- Кому он должен быть отправлен на ознакомление?
- Какой размер документа является приемлемым для чтения?
- Должна ли быть сопроводительная записка к документу?
E-mail – наша рисковая зона комфорта
03 years
by Антон Витязь
in Завершающие, Инициация, Исполнение, Мониторинг и управление, Планирование, Управление коммуникациями проекта
Многие проектные менеджеры легко попадают в одну кмомуникационную ловушку. Они создают для себя зону комфорта в коммуникациях посредством использования электронной почты.
Что проще написать письмо? Это не подбирать на лету слова, не тратить время на сборы и т.п. Потом всегда можно сказать – я-вам-выслал-письмо-по-этому-поводу-сейчас-вам-скажу-дату-и-время …
А всегда ли это помогает нам добиваться результата, всегда ли e-mail является самым лучшим инструментом коммуникаций?
Мы забываем о том что сегодня люди завалены почтой и делами, делами и почтой. Что может произойти с электронным сообщением:
- Он будет 150 непрочитанным сегодня письмом где-то посередине этого списка
- Его прочтут по диагонали, сделают неправильные выводы и возможно сделают (или не сделают) то что вы хотите
- Даже если вам ответят – могут сослаться на то что вас не так поняли и когда отвечали то имели не это в виду
- Вы не знаете с каким эмоциональным состоянием, настроением, мотивацией отвечали вам. С другой стороны также теряют массу невербальных коммуникаций
- Ваша шутка в письме может прийтись к прочтению в очень неудачное время. В личной беседе вы можете лучше оценить обстановку и собеседника. А в оффлайне?
- Некоторые вообще мало читают электронную почту. Есть руководители у которых компьютер – атрибутика стола. Электронную почту принимает офис менеджер.
(more…)
Как часто воспринимается оценка начинающими менеджерами проектов
04 years
by Антон Витязь
in Мониторинг и управление, Управление сроками проекта, Управление коммуникациями проекта
Менеджер проекта приходит к сотруднику и спрашивает – сколько времени у тебя уйдет на эту задачу. Сотрудник отвечает – 5 дней (часто 5-10-15 – бывалые сотрудники любят мыслить неделями, округляя задачу). Менеджер проекта говорит “ok”, делает пометочку и уходит. Через 5 дней он спрашивает сотрудника о задаче и может услышать чащего все в ответ
- Задачу не начинал – были другие приоритетные вопросы
- Задача готова на 90% но еще нужно пару дней
- Ну еще пять дней (без оценки готовности, или где-то половину сделал)
- Задачу сделал 3 дня назад (реже всего – но тоже нечему радоваться – в плане провисло 3 свободных дня)
Какую ошибку допустил менеджер проекта? Возможные варианты – что менеджер проекта не уточнил, что не спросил:
- 5 дней – это длительность или объем работ
- это оптимистическая, пессимистическая или некая средняя оценка? это оценка на основе ранее сделанных замеров?
- что может пойти не так при выполнении задачи, какая вероятность этого, как это повлияет на объем работ задачи
- не согласовал выделение нужного ресурса времени с руководителем данного сотрудника
- какова текущая загрузка
- это операционная или проектная задача
- делал ли такую задачу ранее сотрудник, насколько хорошо он умеет решать подобные задачи, какие ранее были оценки времени и за сколько реально сделали
- интересная ли ему такая задача? насколько он внутренне мотивирован ее выполнять
- чем можно помочь сотруднику в выполнении поставленной задачи (обеспечить более лучшим компьютером, поставить ПО, снять с него пару рутинных задач по операционной деятельности и т.п.)
Кроме оценки следует обратить внимание на следующие моменты:
- проговорить еще раз требования к результату и попросить сотрудника своими словами повторить это, выслать ему это письменно
- тем или иным способом зафиксировать время и назначение по задаче – то ли в плане проекта, то ли в списке задач, то ли письмом.
В процессе выполнения задачи периодически надо:
- Уточнять статус выполнения задачи
- Идентифицировать возможные проблемы с ее выполнением (технические, организационные)
- Пытаться посмотреть на промежуточный результат
Next »