Шрифт:
4) По каким причинам проекты оказываются неуспешными?
5) Удается ли нам эффективно разбить свой проект на этапы и договориться о результатах каждого этапа?
6) Насколько четко мы с самого начала договариваемся что, зачем и как будем делать?
7) Насколько правильно распределены роли, не перегружен ли руководитель проекта?
8) Насколько точно мы определяем содержание проекта (что конкретно нужно сделать), как сильно оно меняется после начала проекта (не решаем ли мы сделать больше, чем планировали изначально)?
9) Насколько верны в каждый момент времени наши иерархическая структура работ по проекту и диаграмма Ганта [29] ? Ведь, если нет, это означает, что проектные документы не столько помогают нам работать эффективнее, сколько существуют «для порядка»…
10) Насколько эффективно [30] наше управление рисками проектов?
11) Насколько эффективно наше управление коммуникациями в проекте? Удается ли нам договориться о том, когда/каким способом мы будем общаться по проекту, и после поддерживать эти договоренности?
29
Иерархическая структура работ по проекту – схема, в которой наглядно изображены все значимые работы по проекту и собраны в логические «кусты». На диаграмме Ганта (ее еще называют «сетевым графиком») те же работы представлены во времени и показано, какие из них должны идти последовательно или могут идти параллельно.
30
Эффективным называется управление, в результате которого мы предсказали большинство рисков точно. Понятно, почему плохо не предвидеть случившиеся риски. Но и слишком осторожное планирование рисков тоже нельзя назвать «хорошим», ведь оно «оттягивает» на себя ресурсы, которые можно было бы использовать для выполнения других задач.
12) Насколько равномерно распределены наши усилия/трудозатраты по всей протяженности проекта? Насколько экономично/эргономично мы действуем в проекте?
13) Насколько маневренна и легка наша методология управления проектами, – большая часть наших трудозатрат в проекте относится к выполнению работ в рамках проекта или к организации хода проекта, планированию, документированию и пр.?
14) Все ли в команде одинаково приоритезируют ограничения проекта, понимая, в каких случаях важнее сэкономить ресурсы, а в каких – выиграть время?
15) Что в проекте мы делаем самым последним?
Как мы управляем своими проектами [31] ?
16) Есть ли в компании Корпоративный стандарт проектного управления? Насколько он удобен/читабелен/практичен? Используется ли этот документ на самом деле? Эволюционирует ли он, т. е. появляются ли новые версии, более точные, полезные, понятные и пр.?
17) Собираем ли мы проекты в категории, выделяя группы «продуктовых», клиентских, управленческих, HR-проектов, – описываем ли мы некоторую специфику управления каждой группой?
31
В этой главе автор умышленно не вводит названий концепций проектного управления, как то PMBOK, PRINCE, ISO или agile, считая, что в каждой «школе» есть идеи и инструменты, которые подходят конкретной компании для решения ее конкретных задач, – и те, которые не подходят. Ни одну методологию из книги вы не «наденете» на вашу компанию целиком, как костюм из магазина готового платья. Тем не менее, о некоторых подводных камнях организации работы по agile сказано в главе 2 в разделе «Они вдумчиво используют new work».
18) Обучаем ли мы сотрудников принципам проектного управления вообще и по Корпоративному стандарту в частности?
19) Есть ли у нас «библиотека» как ошибок, так и хороших решений? Насколько мы собираем и передаем Best Practice?
20) Есть ли у нас промежуточные процедуры анализа качества выполнения проекта и финальная? Во время промежуточных регулярных встреч можно обсудить, что получается хорошо, а что можно делать лучше [32] , во время финальной встречи можно обсудить итоговый отчет [33] по проекту.
32
То, что в agile называется «ретроспектива»: групповая работа в режиме мозгового штурма или фасилитации, по итогам которой формируется план действий по повышению эффективности на следующем этапе проекта.
33
То, что в PMBOK называется «post-mortem report», – дословно, «посмертный» анализ, выполняемый тогда, когда проект уже завершен. PMR анализирует эффективность работы по организации управления во всех аспектах проекта: качество планирования, эффективность распределения времени и бюджета, точность управления рисками, качество коммуникаций с командой и стейкхолдерами и пр.
21) Есть ли у нас условное «табло», на котором перечислены все корпоративные проекты с указанием статуса каждого из них? Можем ли мы в любой момент времени бросить на весь наш массив проектов так называемый «helicopter view» – «взгляд с вертолета»?
22) Можем ли мы сказать, что от проекта к проекту наши навыки управления проектами становятся сильнее?
#ИксИгрек
Рис. 6. Остров погибших проектов.
В «ИксИгрек», как и в любой современной компании, в коридорах и кабинетах часто звучит слово «проект». Но у всех ли проектов есть руководители? Впрочем, иногда случается и так, что часть коллег считает руководителем проекта Икса, а часть – Игрека. Ни тот же, ни другой ничего об этом не знают…
Корпоративной методологии управления проектами нет, – каждый руководитель проекта делает то, что считает нужным. Впрочем, попытку бороться с этим предпринял в «ИксИгрек» один из руководителей, Ильдар: он написал регламент управления проектами, документ правильный, но громоздкий и абстрактный. Конечно, привычки пользоваться этим документом в компании не возникло.
Из проекта в проект «ИксИгрек» переносит недостаточную дисциплину планирования, путаные коммуникации, разночтение целей. Одни проекты заканчиваются ожидаемым результатом, но гораздо позже, другие проекты заканчиваются… стоп. А они заканчиваются?
…Другие проекты исчезают бесследно, отправляясь как будто на проектное «Кладбище погибших кораблей»: коллеги помнят, что была такая идея, но никто не может объяснить, что с ней стало.
Третья группа проектов выполняется не так уж плохо, – соблюдаются сроки, бюджет, получается результат. Почему – так? Ведь не может быть, что у каждого проекта своя «карма» от рождения?! Все-таки было бы правильно делиться лучшими практиками.