Войти в систему
Войти с помощью соц. сетей:
Рэй Шин
В отличие от процессов, где одни и те же люди многократно выполняют одни и те же действия, проекты часто подразумевают уникальные виды действий (например, использование новых технологий, постройка новых зданий или разработка новых компьютерных программ), выполняемые людьми, которые, возможно, впервые работают вместе. Поэтому вам как лидеру проекта необходимо активно следить за ходом работы, чтобы понимать, действительно ли ваш план приближает команду к цели.
При мониторинге и контроле проекта вам следует пройти пять основных этапов.
Очень важно регулярно проводить проверки среди членов команды, чтобы точно знать, справляются ли они со своими задачами и соответствует ли их деятельность стандартам качества. Наиболее эффективный способ добиться этого — командные совещания, однако они удобны лишь в том случае, если все работают в одном месте. Но в сегодняшнем бизнесе очень распространены географически разбросанные команды, и собрать всю группу вместе в таком случае бывает непросто. При таких условиях работы я провожу рабочие совещания с отдельными сотрудниками или небольшими группами, занимающимися конкретной деятельностью. Например, однажды я участвовал в «живой» телеконференции с инженерами с трех различных заводов, которые занимались подготовкой предложения о разработке продукта для клиента. Если бы я сам написал черновик предложения, разослал его всем, а затем собрал комментарии и попытался бы их объединить, на окончательное составление документа могли бы уйти недели. Но вместо этого на то, чтобы обсудить предложение и прийти к формулировке, удовлетворяющей всех, у нас ушло примерно три часа. После подобных сеансов я сообщаю остальной группе о достигнутом, созвав расширенное совещание или разослав электронные письма.
Также я использую «товарищеские проверки», чтобы гарантировать правильное выполнение заданий. Когда кто-то заканчивает свою часть работы, другой член команды рассматривает полученные результаты. От него не требуется глубокий технический анализ, а только быстрая проверка, цель которой — убедиться в том, что сотрудник, выполнивший работу, случайно не пропустил чего-то или не понял какие-то требования неправильно. Так, например, член команды, проверяющий план тестирования новой системы, должен убедиться в том, что охвачены все отделы, которые должны в этом участвовать. Лучше всего, чтобы такую проверку по возможности проводил тот, кто впоследствии будет пользоваться результатом работы. Когда я участвовал в разработке нового продукта совместно с компанией, производящей медицинское оборудование, то попросил ее юридический отдел рассмотреть проектную документацию и проверить данные, чтобы выяснить, не упустили ли мы какую-то информацию, которая могла бы впоследствии потребоваться для сертификации продукта. Если у вас нет члена команды, который непосредственно заинтересован в результатах деятельности, можете провести такую проверку сами — но не забывайте о том, что это не оценка достижений; просто один член команды присматривает за другим.
Далеко не у всех компаний есть информационные системы управления проектами, которые могут автоматически генерировать отчеты. Если у вас такая имеется, конечно, используйте ее, но при этом также собирайте данные о работе на коротких пульс-совещаниях, где члены команды могут делиться обновлениями по своим задачам и оценивать риски. Проводить такие встречи можно как лично, так и онлайн. Я ограничиваю их продолжительность 10 минутами и обсуждаю только те задачи, которые были начаты или окончены с момента предыдущего совещания. Их цель не глубокий и всесторонний анализ, а быстрое ознакомление с положением дел. Если команда сообщает о каких-то проблемах или рисках, я устраиваю для их обсуждения и решения отдельные рабочие встречи с нужными людьми.
Обычно я провожу пульс-совещания каждую неделю, что позволяет мне должным образом следить за ходом работы и вовремя обнаруживать проблемы. Однако, если проект сталкивается с кризисом, они проводятся чаще. Однажды я управлял проектом, в ходе которого произошел сбой системы электроснабжения нового завода за три дня до его запуска. От сроков сдачи в эксплуатацию зависели важные бизнес-цели. Команда работала круглосуточно, чтобы определить причину сбоя, заменить неисправные компоненты и запустить завод в срок. Все это в обычных обстоятельствах могло занять два-три месяца, но у нас было всего три дня, так что я проводил совещания каждые три часа.
Проектная деятельность редко проходит в точности так, как было задумано. Проект может занять больше или меньше времени, может не использовать бюджет или превысить его. Отклонение от плана не всегда проблема — главное, чтобы оно не мешало целям команды. В ходе одного из моих проектов участвующий в команде инженер сообщил на пульс-совещании, что на изготовление нового шаблона уйдет на две недели больше, чем планировалось. Но, поскольку этот шаблон не относился к задачам критического пути и в этой части графика у нас было почти шесть резервных недель, команде не потребовалось предпринимать по этому поводу каких-то специальных действий. Но, если бы задержка какого-либо промежуточного результата ставила под угрозу достижение важной цели, я бы устроил отдельное совещание с ведущими членами команды, чтобы найти выход из сложившейся ситуации.
Именно в этот период тщательное планирование проекта приносит свои дивиденды. Если вы точно представляете себе критический путь, вы можете решить, какие из возникающих проблем и трудностей требуют изменений в графике. Если вы заранее определили риски, способные подорвать достижение главных целей, вам будет гораздо легче понять, какие проблемы в процессе несут реальную угрозу для всего проекта. Заранее оценивая продолжительность каждой частной задачи и затраты на нее и внимательно отмечая любые моменты неопределенности, вы сможете распознать, какие отклонения не слишком важны, а какие могут свидетельствовать о более крупных проблемах.
Если план действительно требует пересмотра, возможно, вам придется отодвинуть дату завершения проекта, привлечь дополнительные бюджетные ресурсы, ограничить спектр результатов или вообще отменить проект. В одном из проектов по разработке ПО, который я контролировал, при первом пробном запуске обнаружилось огромное количество ошибок. Прежде чем предпринимать попытки исправить ПО, я быстро сверился с требованиями и увидел, что разработчики руководствовались устаревшей версией документа. Нам пришлось изменить график выполнения задачи по данному модулю, в результате чего дата завершения отодвинулась почти на месяц, однако эти изменения определенно были необходимы.
Некоторые менеджеры проектов и члены команд считают, что отчеты перед заинтересованными лицами, подразумевающие подготовку оценок и проведение специальных совещаний, — всего лишь трата времени и сил, потому что отвлекают от основной деятельности. Однако при правильном подходе они способствуют успеху проекта. Они бывают трех типов: управленческий отчет, поэтапный отчет и технический отчет. Во всех трех случаях запишите и распространите среди участников перечень пунктов плана, по которым необходимо отчитаться, а также держите наготове записи результатов совещания по проекту, чтобы при необходимости к ним обращаться.
Цель управленческого отчета — оценка и управление рисками. Заинтересованные лица могут рассматривать одновременно несколько проектов, чтобы понять, обеспечивает ли портфолио в целом желаемые бизнес-результаты, и определить системные слабые места. Но они оценивают и отдельные проекты по их уникальным показателям. Подобные отчетные встречи обычно проводятся регулярно — к примеру, раз в месяц. Проводя их, не забывайте, что лицам, заинтересованным в результатах вашего проекта, важнее достижение целей бизнеса, а не контроль ежедневной деятельности команды. Как-то я побывал на совещании, где лидер проекта в течение почти получаса описывал технические характеристики, которые изучала и тестировала команда, что вызвало у заинтересованных лиц лишь скуку и разочарование. Ему стоило бы просто рассказать им, что проект движется по графику (так и было), что команда достигла успехов в техническом анализе (она достигла) и что никаких новых факторов риска не найдено, — и это заняло бы не более пяти минут.
Для того, чтобы суммировать ваши основные цели и показать, соответствует ли им проект в его теперешнем виде, очень хорошо подходит обобщенная диаграмма проекта, которую можно разделить на части, например, график, затраты и эффективность работ. Этот инструмент часто называют диаграммой «светофор», так как статусы различных видов деятельности и задач отображаются на ней красным, желтым и зеленым цветом. В большинстве компаний существует стандартный формат для таких диаграмм, что позволяет топ-менеджерам быстро и эффективно оценивать прогресс и риски по разным проектам. При использовании цветовой кодировки убедитесь, что назначение каждого цвета понятно всем. Например, отмечаете ли вы красным все незавершенные задачи? Или же некоторые из них отмечены зеленым, так как работа по ним ведется в соответствии с одобренным планом?
Если вам необходимо сообщить заинтересованным лицам плохие новости, всегда делайте это в терминах риска для достижения целей проекта. Например, объясните, как задержки в выполнении определенных задач мешают команде вовремя достигать поставленных целей или как нехватка ресурсов снижает качество работы и результаты. Говоря о проблемах, также предложите варианты их решения и обсудите риски, связанные с каждым из них. Заинтересованные лица должны решить, на какие риски для бизнеса они готовы пойти.
Поэтапный отчет — это совещание, на котором принимаются решения, а не проверяется состояние работы. Его проводят, когда бизнес-планы и проекты переходят из одной фазы в другую. Проектная команда подводит итоги предыдущей фазы и представляет план следующей. Заинтересованные лица оценивают план, варианты и риски, а затем принимают решение об одобрении, пересмотре или отмене проекта. Если они решают, что следует перейти к следующей фазе, то также обеспечивают команду необходимыми ресурсами, в том числе финансовыми.
При техническом отчете независимая команда экспертов — скажем, собственных или приглашенных консультантов или представителей регулирующих органов — проводит глубокий анализ результатов проекта. Его цель — убедиться в том, что команда выполняет свою работу точно, полно и в соответствии со стандартами качества. Заинтересованные лица в этот момент могут «дать добро»: если команда успешно завершила одну из фаз проекта, она может переходить к поэтапному отчету, чтобы получить дальнейшее одобрение для начала следующей фазы.
Пересматривая план, вы можете вносить в него как существенные изменения, так и мелкие коррективы, которые будут способствовать достижению командой своих целей.
Если вы представляете заинтересованным лицам предложение о серьезных изменениях, озвучьте затраты и риски их принятия в сравнении с затратами и рисками сохранения первоначального плана. Однажды я работал с подрядчиком оборонной отрасли, который получил от ВВС запрос на усовершенствование функционирования некоего компонента оружейной системы. После того, как ВВС рассмотрело предложенные варианты (с учетом затрат, рисков и графика работ) и выбрали один из них, подрядчик синхронизировал обновления с документацией по разработкам, производственными процессами, контрактами с поставщиками и бюджетом, чтобы изменения прошли как можно более гладко. При подобных существенных пересмотрах плана обязательно зафиксируйте их (вместе с обоснованиями) в специальном разделе отчетности по проекту. Для изменения плана вы можете использовать привычные для вас процессы и методы проектного планирования. Разошлите новый план членам вашей команды и объясните все изменения, которые могут их затронуть.
Потребность в мелких коррективах может возникнуть при обнаружении непредвиденных обстоятельств или при проработке деталей какой-то части проекта, план которой был спущен вам «сверху». Как правило, проектная команда способна справиться с этим самостоятельно, не обращаясь за одобрением к заинтересованным лицам, если только изменения не затронут напрямую их или их отделы.
Контролируя проект, не забывайте о том, что достижение поставленных целей превыше всего. Не старайтесь во что бы то ни стало придерживаться первоначального плана. Судя по моему опыту, практически любой план проекта в какой-то момент приходится пересматривать — особенно если вы заняты разработкой новых продуктов или систем, потому что узнанное вами на начальных этапах проливает свет на то, как лучше выполнять дальнейшие задачи. Не бойтесь менять курс, если это приблизит вас к достижению целей.
Рэй Шин — преподаватель и консультант по управлению проектами и процессами. Имеет более 25 лет опыта в руководстве проектами в оборонной отрасли, разработке продуктов, промышленном производстве, ИТ и других сферах. Руководит отделом управления проектами в подразделении GE Electrical Distribution.
Войти с помощью соц. сетей: