Основные ошибки при реализации проектов

Опыт менеджеров Redmadrobot.

Мы, электрические, запускаем проекты с 2009 года, и за 11 лет сформировали сильную команду робоменеджеров. Прокачивать железных помогают боевые задачи и одна из самых сложных — управлять проектом.

Ситуации, при которых появляется необходимость взять на себя обязанности PM (project manager), бывают разные: в маркетинге — при создании сайта, в HR — при организации мероприятий. Мы вспомнили десятки подобных случаев и подготовили список ошибок, которые допускают новоиспеченные руководители проектов.

Описания ошибок мы дополнили своими рекомендациями по их решению: простыми и не очень. Второй вариант для тех, кто хочет заморочиться — с референсами и ссылками на полезные ресурсы. Надеемся, что это позволит сделать ваш проект проще, качественнее и внесёт предсказуемость в процесс его создания.

На самом старте

Удачный старт — половина успеха. Вот несколько ошибок, которые могут негативно повлиять на дальнейшее развитие проекта.

Ошибка № 1: отсутствие фиксации договорённостей со стейкхолдерами

Момент, которым нельзя пренебрегать в самом начале — обсуждение ожиданий от продукта со стейкхолдерами — людьми или организациями, которые способны оказать влияние на развитие проекта.

Ожидания от продукта задают требования к результату и существенно влияют на дальнейшую работу всей команды. Согласование помогает избежать возможных недопониманий и разногласий по развитию проекта.

Простое решение: составьте текстовый документ или таблицу, где будут собраны ожидания стейкхолдеров. Чтобы упростить себе жизнь, вы можете воспользоваться нашей подсказкой по структурированию содержания.

В документе важно не просто зафиксировать ожидания всех и каждого, но и привести пожелания к общему знаменателю. Цель должна быть единой, понятной и одобрена всеми участниками.

После формирования документа синхронизируйте его с командой (наверняка вам подкинут ещё пару-тройку идей) и смело отправляйте стейкхолдерам, чтобы финально согласовать все моменты.

Вариант посложнее: железная команда аналитиков и дизайнеров Redmadrobot на этапе старта проекта всегда собирает паспорт продукта — документ с описанием характеристик и основных целей.

Он содержит в себе ключевые показатели и выступает в роли ориентира для дальнейшего развития проекта или группы проектов. Если хотите избежать проблем, то его нужно проработать, синхронизировать с командой (собрать всевозможные идеи) и согласовать со стейкхолдерами.

После этого итоги согласования нужно зафиксировать для всех — разослать письма, выложить документ в облако или создать борд в Miro.

Ошибка № 2: бездумное формулирование целей и задач в команде

Одна из причин, почему идеи не выдерживают проверку временем — отсутствие «моста реализуемости». Менеджер может понимать цели стейкхолдеров и то, как их достичь, но не представлять вижн результата. Или, всё же видеть желаемый результат, но не учитывать всех трудностей, которые, вероятно, возникнут в будущем.

На выходе мы имеем старое доброе «ничего», а прикрываемся «внешними факторами», «незапланированными активностями» и «кто-то виноват, а мы не подозревали».

Простое решение: вариант для самостоятельного использования — воспользуйтесь одной из проверенных временем методологий постановки задач, например, SMART. Мы часто используем в работе подходы DoD и DoR .

Но проект — дело командное, поэтому, если есть возможность планировать и думать над реализацией всем вместе, её нужно обязательно использовать.

Вариант посложнее: изучите вместе с коллегами одну из методологий постановки задач и грамотно её внедрите. Для этого разделите планирование результатов на несколько итераций, после чего сделайте deep dive (погружение в проект) всей команды по методологии постановки задач.

Определитесь, как вовлечь в процесс планирования и достижения результатов всех коллег и, самое важное, — проследите за тем, чтобы это сработало на нужный вам результат.

Ошибка № 3: перекладывание ответственности

Здесь всё просто: ответственность и распределение ролей в команде должны быть понятны всем участникам. В какой-то момент (а он точно может наступить, поверьте) придётся разбираться, почему что-то пошло не так и кто-то не выполнил важную задачу.

А в том случае, если в проекте что-то пойдёт не по плану, менеджер должен чётко понимать, в какой его части произошёл сбой. Иначе PM рискует поставить под угрозу результаты работы и деморализовать всю команду.

Одно из лучших решений для создания «прозрачности» — использовать матрицу ответственности. Её можно выбрать исходя из сложности проекта, размера команды и предпочтений.

Простое решение, если не хотите заморачиваться и у вас небольшой проект:

Главное — договоритесь о том, как планируете взаимодействовать в команде и зафиксируйте это любым удобным способом: текстом, в Miro или, например, набросайте mind map — как вам удобно.

Вариант посложнее: для крупных проектов можно сделать ролевую модель проекта в виде карты и добавить описание функций каждой роли (это можно сделать, например, в Miro).

Но сама по себе матрица принесёт мало пользы. Чтобы выстроенная система ответственности дала плоды, нужно постоянно контролировать её исполнение. Например, решать возможные последствия её распределения: избавляться от ненужного, улучшать текущее и добавлять новое.

По ходу реализации: про реализацию

Главная задача менеджера в ходе реализации проекта — выполнить запланированные задачи, которые приведут его и всю команду к нужному результату. Этого можно добиться, если грамотно управлять изменениями, внедрять качественные улучшения в процессах, избавляться от лишнего и постоянно получать промежуточный результат. А вот короткий список того, что может помешать вам на этом непростом пути.

Ошибка № 4: отсутствие инструментов для командной работы

В любой работе нужны инструменты, но важно внедрять лишь те, что будут способствовать развитию проекта. К сожалению, часто происходит наоборот, когда новые возможности добавляют в жизнь команды лишнюю бюрократию, вредные регламенты и другие неприятные вещи.

Потом определите ответственных за техническую поддержку и актуальность работы инструментов. Вся информация в них должна периодически обновляться, быть упорядочена в соответствии с возможными правилами и доступна команде.

Простое решение: не гонитесь за модой — используйте доступные и универсальные инструменты, такие как Trello или Google-таблицы.

Благодаря своей системе карточек, Trello отлично подойдёт для распределения задач. В них вы можете фиксировать важные части проекта: процесс выполнения работ, ведение сделок и заявок, организацию документооборота и другие вещи. Ну а Google-таблицы хороши своей многозадачностью. В Redmadrobot команды часто используют их в самых разных делах:

Задача эффективного инструмента — упростить жизнь команде. Trello и Google-таблицы хорошо с этим справляются. Но независимо от ваших предпочтений, есть типы инструментов, которые понадобятся вам в любом проекте: делегирование, встречи или «синки», риск-менеджмент, каналы коммуникации и взаимодействия.

Вариант посложнее: за долгие годы нанесения непоправимой пользы нашим клиентам мы создали систему инструментов. Её может использовать любая команда, работающая в проектах разного уровня и сложности. Вы можете использовать её как базу при формировании собственного списка нужных сервисов.

Ошибка № 5: отсутствие чётких приоритетов

В ситуации, когда приоритетно всё — на самом деле никаких приоритетов не существует. Если работа кипит и проект развивается, то это ещё не значит, что команда идёт к нужному результату.

Так вы будете знать, как распределены усилия между коллегами и убедитесь, что цели и задачи в вашей голове совпадают с их приоритетами.

Простое решение: если у вас небольшой проект, то используйте методологию MоSCоW — она хорошо подходит для определения приоритезации. Также обратите внимание на методологии RICE и ICE.

Вариант посложнее: в крупном проекте поможет формирование собственной системы приоритезации входящих задач. Её можно построить на базе Google-таблиц или Trello.

С помощью Google-таблиц или Trello можно собрать систему с упором на потребности команды. Например, Google-таблицы позволяют настроить фильтры и формулы, которые автоматизируют учёт. Исходя из баллов, выставленных по конкретному параметру, фильтры и формулы могут автоматически выстраивать итоговый список с приоритетами, что значительно экономит время.

Ошибка № 6: отсутствие контрольных точек и оценки результата

Если путь длинный, то его нужно делить на отрезки. Менеджеру такой приём помогает лучше контролировать процесс работы, а команда видит результат и мотивирована работать не снижая темп.

Решение:

Проект — это про управление изменениями, поэтому не бойтесь рисковать. Главное, убедитесь, что планируемый результат того стоит и команда одобрила вашу идею. И не переусердствуйте с ответственностью. Тотальный контроль — ваш абсолютный враг, который ведёт к хроническому недоверию к коллегам и созданию враждебной атмосферы в команде.

По ходу реализации: про взаимодействие

Проекты реализовываются людьми, которые постоянно взаимодействуют друг с другом. Ваша задача, как менеджера — понять, как нивелировать проблемную «человеческую» часть — коммуникацию и взаимодействие. Не допускайте следующих ошибок.

Ошибка № 7: неинформирование команды

Чтобы чётко определить вектор развития проекта, эскалацию, решение проблем и запросов, важно рассказывать команде обо всех рабочих изменениях. Это касается не только коллег, но и стейкхолдеров.

Решение:

Ошибка № 8: отсутствие реакции на изменения или критичные ситуации

Проблемы сами по себе не исчезают и не утихают, а как правило накапливаются и создают эффект бомбы с замедленным действием. Наивно полагать, что если проблему или конфликт не провоцировать, то он исчезнет.

Поэтому, каждой команде нужен понятный механизм эскалации вопросов и конфликтов. Менеджер проектов должен уметь принимать верные решения в критических и незапланированных ситуациях, и находить пути выхода из «застоя» (в ситуациях, которые требуют пересмотра).

Простое решение: расскажите команде про базовые правила эскалации. Для этого сформулируйте, как вы видите процесс эскалации в идеале, зафиксируйте его в виде простых тезисов. Разместите информацию в «общем пространстве», чтобы в нужный момент у всех был доступ к документу.

Вариант посложнее: сформируйте собственную систему эскалации. Для этого составьте список коллег, которые будут помогать вам в решении проблемных ситуаций и конфликтов, а также в определении стратегических действий. О возможностях инструмента эскалации и способах его организации написано много статей, поэтому, если вам интересна эта тема, просто «загуглите».

Помните, что от ваших решений зависит успех продукта. Профилактика конфликта — сигнал к тому, что команда готова открыто говорить о своих проблемах.

И в конце

Проект всегда имеет конечные точки и финал. Соберитесь силами и не допустите в них последних двух ошибок.

Ошибки № 9 и № 10: отсутствие рефлексии и подведения итогов

В условиях проекта, к ошибкам часто приводит отсутствие анализа: проделанных действий, применённых подходов и практик, а также построенных недавно процессов.

Вам, как менеджеру, необходимо слушать и слышать что происходит в вашей команде в разных отрезках времени, и своевременно вносить качественные изменения в её работу. В таких случаях помогает рефлексия, которая позволяет осмыслить пройденный путь.

Простое решение: контролируйте эмоциональный фон команды, подводите итоги на итерационной и постоянной основах. Например, проводите еженедельные или двухнедельные «синки». При подведении итогов не забывайте делать срез по выполненным и планируемым задачам.

Всегда отмечайте успехи команды и не бойтесь говорить про неудачи. И проговаривайте проблемы, не только текущие, но и уже решённые. Обязательно фиксируйте итоги с подобных встреч и преобразовывайте их в задачи на развитие.

Вариант посложнее: мы в Redmadrobot пользуемся двумя инструментами: ретроспектива проекта команды и индивидуальная рефлексия для руководителя. Ретроспектива помогает регулировать эмоциональный фон команды, снимать обратную связь по прошедшему периоду и, что важно, — благодарить друг друга.

Индивидуальная рефлексия — это инструмент управленца, помогающий проводить анализ его действий в проекте за прошедший период. Здесь важно проанализировать, что вы планировали сделать, что получили в итоге и как будете действовать в следующий раз. Достаточно простая формула успеха, если ей пользоваться вовремя и с пониманием.

Вопросы рефлексии корректируются в зависимости от ситуации, но стандарт при их составлении один. Постарайтесь найти ответ на каждый из них:

У нас получился не самый полный список ошибок, но если вы сможете не совершать хотя бы их, то сделаете работу над проектом проще и эффективнее. Мы, роботы, убеждены, что совершение ошибок — это путь к совершенству, ведь мы постоянно на них учимся. Поэтому, советуем вам не бояться рисковать. А ещё, не забывайте прислушиваться не только к коллегам, но и к самому себе. Согласны?

Число ошибок растет как снежный ком. Большая часть из них объясняется недостатками планирования или сбоями в процессе организации взаимодействия (между отдельными участниками проекта или проектной командой и ее спонсорами). Ошибки могут привести и к фатальному исходу. С другой стороны, имеется возможность их избежать. И кому, как не поставщикам решений и консультантам по вопросам управления проектами, лучше других должны быть известны наиболее распространенные ошибки. (Им же следует и предложить пути выхода.)

Предлагаемый ниже список из 14 наиболее распространенных ошибок, допускаемых при управлении проектами, призван помочь вам очертить круг неверных действий и предложить меры, которые необходимо принять для нормализации ситуации. Устранение самых общих ошибок при управлении проектами сулит огромную потенциальную выгоду. Повышается не только уровень успешности проекта, но и степень удовлетворенности внутренних клиентов, растет ценность ИТ-активов организации, а бизнес своевременно и в рамках отведенного на эти цели бюджета получает системы, укрепляющие его конкурентоспособность.

Просчеты, связанные с персоналом

Ошибка № 1: Проекту не хватает ресурсов и квалифицированных исполнителей.

Проявление: Наличие квалифицированных исполнителей имеет критически важное значение. Наряду с этим в числе наиболее существенных ошибок, связанных с управлением проектами, следует отметить неверное распределение ресурсов. Отсутствие грамотных специалистов может погубить проект. «Ключевое условие успешной реализации проекта — тщательный подбор людей, обладающих требуемой квалификацией, — отметил Джоэл Коппельман, генеральный директор компании Primavera, специализирующейся на разработке программного обеспечения управления проектами. — Решение даже самых нужных и важных задач по организации планирования не может застраховать нас от дефицита талантов».

Решение: ИТ-руководителям и менеджерам проектов необходимо внимательно следить за уровнем квалификации и загруженностью персонала, включая консультантов, поставщиков услуг аутсорсинга и сотрудников, работающих по контракту. Именно люди, относящиеся к этим категориям, обычно избегают предварительной проверки на профпригодность, хотя и выполняют львиную долю работы. Программное обеспечение управления проектами позволяет оценить квалификацию и степень загрузки каждого из сотрудников. А когда сотрудники ИТ-службы и менеджеры проектов знают, кто и что делает, им гораздо проще понять, каким образом следует распределять ресурсы, выделенные на реализацию множества проектов и решениее повседневных задач.

«Существует масса организационных моделей, — отметил Ричард Скэннелл, один из основателей компании GlassHouse Technologies, предоставляющей консультационные услуги, связанные с построением ИТ-инфраструктуры. — Но я никогда еще не видел, чтобы хорошо работало абсолютно все. На вопросы, касающиеся распределения ресурсов, к сожалению, не существует простого ответа».

«Необходимо добиваться синхронизации проектов и человеческих усилий, — считает Коппельман. — Одним из возможных выходов здесь может стать учреждение должности менеджера по распределению ресурсов между проектами, который будет отвечать за справедливую привязку специалистов требуемого уровня квалификации к тому или иному проекту».

Скэннелл предлагает формировать «команды тигров», члены которых освобождаются от своих традиционных обязанностей на год или больше ради участия в конкретном проекте. Кен Чени, директор центра HP Software’s PPM Center, рекомендует распределять ресурсы на уровне проекта, не опускаясь до конкретных задач, поскольку сделать это гораздо труднее.

Если у вас возникают трудности с поиском квалифицированных исполнителей для реализации проектов, можно попытаться освободить ресурсы, отказавшись от тех из задач, которые не связаны тесно со стратегией ведения бизнеса. Имеет смысл оценить целиком портфель проектов, над которым трудятся сотрудники ИТ-службы, выделив компоненты, имеющие критически важное значение. «Приостановив выполнение этих проектов и перераспределив ресурсы в пользу тех задач, которым отводится более существенная роль, вы добьетесь более весомого успеха для организации в целом», — подчеркнул Чени.

Ошибка № 2: Нехватка опытных руководителей проектов.

Проявление: При отсутствии грамотного руководителя проекты могут быстро выйти из-под контроля.

Решение: Нанимайте руководителей проектов, прошедших необходимую аттестацию и обладающих навыками тонкого общения с заинтересованными лицами. Мэтью Стразза, вице-президент компании CA по обслуживанию клиентов в Северной Америке, считает, что руководители проектов должны иметь не только прочные профессиональные знания, но и хорошие коммуникативные и управленческие навыки. От них требуется умело организовать совещание, управлять рисками, находить общий язык с многочисленными заинтересованными лицами — представителями бизнеса, контролирующими реализацию тех или иных функций, с ИТ-специалистами, занимающимися вопросами безопасности, а также с финансистами, которых волнует бюджет.

«Если не решать своевременно финансовые вопросы, не следить еженедельно за бюджетом и не уведомлять клиентов о любых изменениях, то очень скоро вы окажетесь в весьма непростой ситуации, — предупредил Стразза. — Кроме того, квалифицированным руководителям проектов необходимо хорошо знать те технологии, которые применяются при их реализации».

Процедурные ошибки

Ошибка № 3: Управление проектами осуществляется при отсутствии стандартных, повторяющихся процедур.

Проявление: Это вторая по своей распространенности ошибка, связанная с управлением проектами. Отсутствие методологии повышает риск срыва отдельных задач проекта, повторного выполнения одних и тех же работ, а в конечном итоге и выхода за рамки установленных сроков или бюджета.

Решение: Методология управления проектами помогает вам осуществлять их эффективную реализацию и находиться в курсе всех мероприятий, сопряженных с выполнением проекта. «Наличие базиса, включающего стандарты и методологии, позволит избежать многих рисков, связанных с претворением ИТ-проектов в жизнь», — отметил Чени.

Дуглас Кларк, генеральный директор компании Metier, поставляющей решения в области управления портфелями проектов, для определения содержания и границ проекта, сроков выполнения его отдельных этапов, порядка распределения ресурсов и взаимодействия с заинтересованными лицами рекомендует использовать повторяющиеся процедуры. «Этими вещами следует заняться в первую очередь, потому что именно
от них вы сможете получить наибольшую отдачу», — пояснил он.

Ошибка № 4: Слишком большое число процедур, ограничивающих ваши возможности.

Проявление: Слишком большое количество процедур лишает проектную команду гибкости, а это вызывает разочарование у заинтересованных лиц.

Фуми Кондо, управляющий директор консультационной компании Intellilink Solutions, однажды была свидетелем интересного разговора между разработчиком программ и руководителем проекта. Разработчик заявлял, что функционал приложения можно расширить, не прилагая никаких дополнительных усилий. Руководитель проекта убеждал разработчика не добавлять никаких новых функций, потому что пользователи об этом не просили. «Тогда я посоветовала им следующее: ступайте к пользователям и посмотрите, действительно ли им нужны эти функции, — вспоминала Кондо. — Не вижу ничего плохого в том, чтобы предоставить клиентам больше того, что они ожидают, если при этом вы не выходите за рамки бюджета и установленных сроков».

Решение: Проявляйте гибкость и поддерживайте постоянную связь со спонсорами проекта и другими заинтересованными лицами.

Ошибка № 5: Изменения не соответствуют содержанию и границам проекта.

Проявление: Бюджет проекта устойчиво растет. То же самое происходит и со сроками.

Решение: Стразза рекомендует следовать официальным запросам на изменение проекта. Индивидуальные потребности в изменении содержания (связанном, например, с реализацией дополнительных функций) должны находить отражение в соответствующих документах, а руководителю проекта следует оценить, какое влияние эти изменения окажут на бюджет и сроки. Внесение изменений необходимо утвердить у спонсора проекта.

Ошибка № 6: Отсутствие актуальной информации о состоянии проектов.

Проявление: Как говорил Питер Друкер, нельзя управлять тем, что вы не можете оценить. А Чени добавил, что в такой ситуации вам не удастся также координировать ресурсы и реагировать на изменения в содержании и границах проекта.

Решение: Программное обеспечение.

Ошибка № 7: Игнорирование возникающих проблем.

Проявление: Осложнения не рассасываются сами по себе. Чем дольше вы их игнорируете, тем сильнее они обостряются, отражаясь в конечном итоге на стоимости проекта.

Решение: «Если вы допустили ошибку, все дальнейшее будет зависеть от того, насколько хорошо вам удастся ее исправить, — заметил Скэннелл. — Многие начинают замечать, что что-то не так, и пытаются внести коррективы лишь через месяц. Необходимо как можно раньше понять, где была допущена ошибка, и постараться привлечь к ее устранению как можно больше заинтересованных лиц».

Планируемые недочеты

Ошибка № 8: Игнорирование необходимости определения содержания и границ проекта.

Проявление: Если четко не определены границы и содержание как с точки зрения бизнеса, так и со стороны ИТ-специалистов, то проект в конечном итоге может раздуться. Кроме того, у сотрудников ИТ-службы не будет ясного понимания, что все-таки им необходимо для завершения проекта в заданные сроки, не выходя при этом за рамки бюджета и не обманывая ожиданий представителей бизнеса.

Решение: Неясные проекты — повод для обсуждения ситуации с представителями бизнеса и уточнения содержания планируемых задач и их ограничений.

Ошибка № 9: Отсутствие понимания зависимостей, существующих между проектами.

Проявление: Проекты не существуют в изоляции. Как правило, они связаны с другими проектами, которые реализуются параллельно. И когда руководители проектов допускают просчеты при оценке зависимостей между различными задачами (например, если специалисты, принимающие участие в реализации одного проекта, вдруг срочно нужны для выполнения других работ), возникают задержки. Подобные простои могут негативно повлиять на все проекты.

Решение: При планировании реализации проектов необходимо учитывать зависимости между ними. А раскрыть эти зависимости вам поможет общение с заинтересованными лицами и диаграммы, описывающие ход реализации проектов.

Ошибка № 10: Игнорирование законов Мерфи.

Проявление: При реализации проекта возникают непредвиденные обстоятельства, что вызывает удивление ИТ-персонала. И пока эти сотрудники пытаются справиться с неожиданно возникшими задачами, сроки реализации проекта отодвигаются.

Одна из фирм, вошедших в состав компании GlassHouse Technologies, решила перенести свой мэйнфрейм в новый центр данных. Всю субботу ИТ-группа занималась разборкой мэйнфрейма, чтобы на следующий день переместить его в новый ЦОД. А когда в воскресенье сотрудники ИТ-службы занялись перевозкой, на пути у них выросли участники гей-парада, перекрывшие все возможные выезды. Обойти их не было никакой возможности. Пришлось возвращаться в старый ЦОД и начинать все сначала. Недостатки планирования привели к тому, что персоналу ИТ-службы пришлось выполнить гораздо больший объем работ, чем предполагалось изначально.

Решение: В рамках планирования проекта проведите оценку рисков. С помощью мозгового штурма, в котором должны участвовать члены вашей команды, постарайтесь выявить факторы, мешающие реализации проекта или замедляющие ее ход, заставляющие расширять рамки ранее определенного бюджета, а также препятствующие выполнению сформулированных требований. Затем продумайте способы снижения указанных рисков. «Остановившись на некоторое время и оценив существующие риски, можно составить весьма полезный список, — заметил Коппельман. — Это не займет много времени, но зато поможет получить представление о возможных подводных камнях, прежде чем они возникнут на вашем пути».

Ошибка № 11: Дефицит времени, выделяемого на управление изменениями.

Проявление: Время, деньги и тяжелый труд, связанный с реализацией ИТ-проектов, могут быть потрачены впустую, если пользователи не примут новую технологию.

Решение: «На этапе планирования проекта подумайте, где он может встретить сопротивление и как этого сопротивления избежать», — советует Кларк. Определите, на работу каких заинтересованных лиц новые возможности оказывают непосредственное влияние. Тщательно спланируйте потоки работ и изменения, вносимые в бизнес-процессы. Ваша задача заключается в том, чтобы изменения не воспринимались негативно.

Ошибка № 12: Незавершенность графика проектов.

Проявление: Участники проекта не знают, что и когда им нужно сделать, в результате чего сроки реализации проекта оказываются под угрозой.

Решение: По мнению Кларка, самый быстрый способ составить график проекта — это определить все необходимые мероприятия (содержание и границы проекта, предъявляемые к нему требования, процедуры тестирования и внедрения) и конкретные сроки их выполнения в соответствии с окончательными сроками реализации проекта. Составить такие графики вам поможет программное обеспечение управления проектами.

Проблемы взаимодействия

Ошибка № 13: Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить.

Проявление: ИТ-специалисты не справляются с поставленными задачами, за ними закрепляется репутация людей, не умеющих завершать проекты в установленные сроки.

По словам Кларка, представители ИТ-служб прилагают немалые усилия, для того чтобы привести сроки, установленные генеральным директором, в соответствие с реальностью. Однако все их усилия порождают лишь новые осложнения и еще больше затрудняют реализацию проекта в заданные сроки.

Решение: ИТ-руководителям следует разъяснять генеральному директору, какие последствия реализация проекта в установленные руководством сроки повлечет за собой с точки зрения финансовых затрат и необходимых ресурсов. С учетом этих обстоятельств генеральный директор должен сам выбрать компромиссный вариант с приемлемыми затратами, содержанием и границами проекта и сроками его реализации.

Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

Решение: «Взаимодействие в процессе реализации проекта должно отвечать интересам сторон», — отметила Кондо. В содержании и границах проекта, а также в системных требованиях вряд ли можно разобраться, если сотрудники ИТ-службы посылают представителям основного бизнеса электронную таблицу из нескольких тысяч строк, в которой описаны функции и спецификации системы. Поскольку у владельцев бизнеса нет времени изучать такие подробные технические документы, они их просто игнорируют.

«Возможна также ситуация, при которой одна из сторон в процессе взаимодействия изъясняется на языке, совершенно непонятном другой стороне, — заметила Кондо. — В конце концов раздосадованные ИТ-специалисты восклицают: “Но ведь мы обо всем этом говорили. Почему же полученный результат не удовлетворяет конечного пользователя?”»

Всем заинтересованным лицам со стороны бизнеса предлагается заранее раздать общий план реализации проекта в целом, начиная от изложения замысла и заканчивая процедурой развертывания. В этом обзоре должны быть особо выделены мероприятия, требующие взаимодействия с бизнес-подразделениями. Кроме того, следует пояснить, для чего именно сотрудники бизнес-подразделений здесь нужны.

ИТ-служба должна прилагать больше усилий, разъясняя представителям бизнеса этапы реализации проекта.

«Ведя открытый диалог о своих потребностях, реальных достижениях и ходе внедрения проекта, вы неизбежно будете затрагивать вопросы стоимости, а также касаться содержания и границ проекта, — пояснила Кондо. — В результате выход за рамки отведенного бюджета не обязательно будет восприниматься как просчет».

С одним из своих клиентов Кондо работала над реализацией проекта по развертыванию финансовой системы. Сотрудники этого клиента никогда ранее не принимали участия во внедрении крупных систем. Когда проектирование системы было закончено и специалисты Intellilink приступили к разработке плана тестирования, представителям клиента решено было объяснить, почему тестирование имеет такое важное значение.

«Мы говорили о различных подходах к тестированию, о вариантах с привлечением представителей клиента и без, — вспоминала Кондо. — Мы разъясняли, почему так важна обратная связь с пользователями, какой должна быть входная информация и сколько времени потребуется на ее ввод. В результате люди поняли, почему процесс тестирования отнимает так много времени».

Meridith Levinson. The 14 Most Common Project Management Mistakes. CIO.com. 07/23/2008

Часто компании тратят кучу денег и времени на идеи, которые в итоге никак не могут реализовать. Так почему интересные проекты часто оказываются провальными? В
материале мы
собрали 12 типичных ошибок по управлению проектами и объяснили, как с ними можно справиться.

Ошибка №1: Вы выбрали не того project-менеджера

Бывает, что на этапе распределения обязанностей большинство усилий уходит на поиск исполнителей проекта, а не его руководителя. Менеджера зачастую отбирают по
критерию
«свободен от поручений», а не «подходит по компетенциям». Таким образом, неверно выбранный или не имеющий необходимого опыта руководитель может
запросто
загубить полученный проект.

Решение: поручайте руководить проектом только того, кто действительно разбирается в предстоящих задачах.

Ошибка №2: В вашей команде отсутствует мотивация

Проект обречен на неудачу, если не все его исполнители вовлечены в рабочий процесс. Руководитель мог не объяснить роль каждого, либо не замотивировал работой
на результат.
Может быть, менеджер не донес значимости проекта. Это приводит к тому, что сотрудники без энтузиазма относятся к своей работе.

Решение: Project-менеджер, в первую очередь, должен собрать всю команду вместе. В том числе и сотрудников, работающих на удаленной основе (с помощью
skype или
других интернет-сервисов). Руководитель обязан подробно рассказать о проекте и выступить перед сотрудниками так, чтобы взбодрить и замотивировать их на усердную
работу.

Ошибка №3: Ваш проект никто не контролирует

«Нет начальника – значит нет постоянного отчитывания. Полная свобода действий» –, можете подумать вы. Как раз это и плохо. Без работы под наблюдением
высшего
руководства нет стимула держать себя в тонусе.

Решение: Реализация проектов всегда должна идти под контролем директора компании, в которой вы работаете. Или же «надсмотрщиком» будет ваш заказчик.
В любом
случае, когда проект выполняется сам по себе, он, скорее всего, окажется провальным.

Ошибка №4: Вы берете на себя сразу несколько проектов

Многие думают, что у них получится сделать больше, если они будут по чуть-чуть выполнять несколько задач одновременно. Такая стратегия неэффективна. Работа над
несколькими
проектами сразу только замедляет менеджеров. Что самое ужасное, они не успевают своевременно проверять работу исполнителей. Те же просто ждут проверки и какой-
то период
времени ничем не заняты.

Решение: Стоит отказаться от ведения нескольких проектов одновременно. Так вы не будете оставлять какие-то задачи незавершенными и сможете помогать
своей команде –
отвечать на их вопросы или давать консультации. Чем меньше на данный момент у вас проектов, тем быстрее и качественнее пойдет работа.

Ошибка №5: В вашей команде не налажена коммуникация

Умение найти общий язык с каждым сотрудником – один из ключевых навыков менеджера проектов. Если регулярно не поддерживать со всеми связь, вся команда
просто
разбежится, и проект будет завален.

Решение: Выделите день и точное время на неделе, когда вы будете собираться все вместе (в интернете или вживую) и придерживайтесь его. Заранее
спланированный день
позволит каждому быть в курсе дел по проекту и поможет продвижению проекта.

Ошибка №6: У вас нет четкой конечной цели проекта или вы меняете ее в ходе работы

Любой проект, у которого нет четко сформулированной цели, скорее всего, так и не будет готов. А менять цель на полпути крайне опасно. Вы можете перерасходовать
свои время и
деньги. Любые незапланированные мелочи (изменение цвета в логотипе или добавочная страница на сайте) могут привести к непредвиденным трудностям.

Решение: Четко обозначьте цель проекта на его начальном этапе. Затем регулярно следите, все ли придерживаются цели. Отдельно записывайте возможные
изменения и
сразу же оценивайте, как это скажется на графике вашей работы. Не забудьте согласовать изменения с заказчиком или руководством компании.

Ошибка №7: Вы неверно рассчитали время для реализации проекта

Сделать все как можно скорее, чтобы угодить клиенту – неплохое желание. Но если вы выделите слишком мало времени и не успеете завершить проект к сроку, это
вызовет только
недоверие и раздражение со стороны заказчика.

Решение: Правильно подобранное программное обеспечение для реализации проектов позволит организовать ваш рабочий процесс. Однако всегда важно
иметь запасные
деньги и время для экстренного случая. Особенно это касается проектов, связанных с IT-сферой.

Ошибка №8: Вы не идете на уступки

Не относитесь к плану проекта как к Библии, которая строго диктует, что и кем должно быть сделано, когда все должно быть готово. Не отвергайте новые предложения,
которые
приходят в голову сотрудникам в процессе работы.

Решение: Посмотрите на проект со стороны. Подумайте, не нужно ли в нем что-то изменить. Это не значит, что нужно постоянно что-то менять – просто будьте
открытыми к
предложениям со стороны, если они пойдут на пользу проекту.

Ошибка №9: Вы не систематично отслеживаете изменения в проекте

Проект не дойдет до финального этапа, если вы периодически не подводите промежуточные итоги. Также обязательно нужны специально отведенные место и время для
обсуждения
изменений в проекте.

Решение: Вы должны разработать четкую схему промежуточного контроля (чеклисты). Отслеживайте в них все до деталей – стоимость, значимость, влияние на
проект в
целом. А чтобы найти ошибки в уже готовом проекте, проведите полный прогон или тестовый запуск системы.

Ошибка №10: Вы руководите каждым шагом своих сотрудников

Не нянчитесь с исполнителями. Некоторые менеджеры считают, что им нужно ходить вокруг своих сотрудников и заставлять всех работать. Иначе ничего не получится.

Решение: Вместо того, чтобы отслеживать каждый шаг исполнителей проекта, установите для них индивидуальные еженедельные чеклисты. Таким образом,
команда будет
настроена на еженедельный прогресс и уже сама будет работать на результат.

Ошибка №11: Вы нечетко распределили обязанности в команде

Важно, чтобы в команде никто не дублировал обязанности другого и выполнял сугубо свою работу. Бывает, что сотрудники, желая помочь, берутся еще и за «не свои»
задачи. В
результате они не только плохо выполняют чужую работу, но и не успевают делать свою.

Решение: Не допускайте, чтобы кто-то занимался не своим делом. Максимально детально пропишите обязанности каждого и периодически проводите
индивидуальные
чеклисты по проделанной работе. Такой подход позволит придерживаться плана проекта и даст возможность равномерно распределить нагрузку на всех сотрудников.

Работая над проектом, представьте, что конкретно сделает его идеальным, и стремитесь именно к этому. Когда вы поймете, что ваш проект все-таки стал самым
масштабным, самым
стильным или самым полезным, вы будете уверены, что все сделали правильно.

Решение: Project-менеджер должен точно знать, что для заказчика будет являться успешно реализованным проектом. Этот фактор придаст уверенности, что
когда проект
закончен, все его исполнители могут спокойно расходиться.

Если мы не указали еще какую-то ошибку по управлению проектами, которая известна вам, напишите об этом в комментариях и расскажите, как ее можно избежать.

Одиннадцать ошибок управления проектами на примере трансатлантического яхтенного перехода

После 10 лет работы в качестве ИТ руководителя, когда за плечами уже достаточно выполненных проектов и компаний, а также опыт создания проектного офиса, видишь все вокруг немного иначе. Любую уникальную задачу хочется декомпозировать на подзадачи, расположить их на scrum-доске или на временной шкале, оценить приоритеты, риски, трудозатраты. К сожалению, в реальности, даже элементарные практики из проектного управления соблюдаются не всегда.

Именно о том, что всегда должно быть сделано при выполнении проекта мы и поговорим на неожиданном примере трансатлантического яхтенного перехода.

1. Согласование терминологии

Чтобы вести совместную деятельность, надо понимать друг друга. Перед тем как приступить к проекту, проверьте, что все специфические термины вы понимаете одинаково. В одном из моих проектов, в результате сравнения тезауруса двух компаний, участвующих в проекте, выяснилось, что 40% терминов несут различный смысл. Очевидно, любые документы и договоренности в такой ситуации будут только увеличивать проблемы, так как, глядя на них, люди оперируют совершенно разными объектами.

Поэтому, поясню, что такое яхтинг в моем примере. Это не яхтинг глянцевых рекламных фотографий. Это ночные переходы, сон в пол глаза, морская болезнь в первые несколько суток и бытовой комфорт на уровне походного существования. С другой стороны, это интернациональное общение, новые люди, новые страны, радость от достижения цели, и ни с чем несравнимое счастье видеть землю после многих суток в открытом океане.

Понимая, что у людей может быть совершенно иная картинка, я информирую людей, с которыми участвую в таких проектах, заранее. Тем не менее, мне известны случаи, когда модные девицы с полным маникюром (не имею ничего против, но при других обстоятельствах) сходили на берег в первом же порту и забывали об этом опыте как о страшном сне. В нашем примере, о котором пойдет речь, возможности выхода из проекта не было — яхтенный переход планировался от Азорских островов до Гибралтара. Это около 1000 морских миль, 10 дней открытого океана, без возможности сойти на берег.

Путешествие состоялось в начале мая текущего года, и проходило с интернациональным экипажем: поляки, немцы, испанец, американец и я, русский. Управлять такой командой с целью достижения общей цели, да ещё в условиях бытовых и внешних сложностей — серьёзная задача, с которой сталкивался не всякий менеджер проекта. Пикантности же ситуации добавляло то, что владелец, который прошёл с половиной этого экипажа предыдущих 2000 миль, должен был срочно отбыть на большую землю и оставил вместо себя нового капитана, поляка, лет около 30, который не знал экипаж, не знал лодку, и как мы разберем дальше, совершил практически все ошибки руководителя проекта.

При этом, на подходе к Азорским островам лодка прошла через шторм и была повреждена, что не позволяло ее нагружать на 100%. Хорошая же новость состояла в том, что большая часть экипажа шла с Канарских островов, и они уже были проверены владельцем на предмет профессионализма, личной совместимости и, что называется, «уже прикачались». Впрочем, все эти детали я узнал уже на месте, так как моя тяга к цели была сильнее природной осторожности.

И тут надо отметить правило, которое мы все знаем и все нарушаем:

2. Согласование условий

Узнавать все значимые детали и договариваться обо всех условиях проекта надо «на берегу». При этом, все свои затраты до точки принятия решения нужно записывать в возможные риски проекта и быть готовым к их невозвратности. Конечно, очень не хочется тратить время на согласование всяких мелочей и выяснение деталей, когда перед тобой интересная и увлекательная задача. Но уверен, покопавшись в своих воспоминаниях, вы найдете немало примеров, когда эти «мелочи» превращали работу не только в неинтересную, но и приводили к материальному ущербу.

Меня тоже не миновала чаша сия. Расходы на топливо, по мнению нового капитана, должны были дополнительно оплачиваться экипажем, хотя владелец говорил о других условиях. Сумма за счет многочисленности экипажа вышла небольшая, около 20 евро. Но осадок, как говорится, остался.

Следующее правило, которое я вспомнил, глядя на приемку лодки новоиспеченным капитаном:

3. Подготовка к проекту

Успех переговоров с клиентом, на которые вы мимоходом заскакиваете между еженедельной встречей с подчиненными и отчётом своему руководителю, существенно зависит от настроения и состояния клиента. Переговоры, к которым у вас есть вся информация о клиенте, история всех взаимоотношений с ним, пункты, которые надо обсудить и достоверные материалы по каждому из них — практически предрешены. К сожалению, в моей практике подготовленных встреч — единицы, в большинстве подготовка сводится к мысли «надо встретиться и поговорить», а не к «надо обсудить конкретные пункты и подготовить по ним решение или информацию для принятия решения». Да что там говорить, даже элементарная повестка встречи, рассылаемая в срок, достаточный для ознакомления и подготовки, применяется отнюдь не во всех компаниях.

Все эти риски минимизируются в проектной деятельности наличием и использованием (специально разделяю эти два пункта) проектной методики, но даже в случае ее отсутствия, рекомендую потратить один вечер в тишине, составляя перечень того, что надо не забыть.

Что касается подготовки яхты к переходу — существуют выстраданные списки пунктов, необходимых к проверке и выполнению. Метаться по яхте, думая о том, что ещё нужно «не забыть» находясь перед перспективой ближайшие десять суток провести без какой либо связи и земли на горизонте — плохая практика. Для понимания серьезности вопроса можно привести интересные цифры — спасательная операция по эвакуации океанской экспедиции Кон-тики 2 заняла около суток. Именно столько времени понадобилось ближайшему кораблю для того, чтобы прибыть к месту инцидента.

В менеджменте, конечно, у вас будет мобильная связь и возможность запросить подмоги, если что-то не проверили по списку перед началом проекта. Однако, если вспомнить о сроках принятия решений в крупных корпорациях, ваше положение гораздо хуже. Именно поэтому, до отбытия, вам нужно сосредоточиться на списке «что нужно сделать», и первым в этом списке должно быть:

4. Знакомство с командой

Все мы знаем, что необходимо знакомиться с командой. Тем не менее, это не мешает сразу после представления экипажу или сотрудникам удалиться в собственный кабинет/каюту и все дальнейшие вопросы решать через поверенных или не решать вовсе. К сожалению, такой подход не способствует повышению лояльности и дезориентирует участников. Все гораздо хуже, если в вашем проекте объединяется несколько команд из разных компаний. Вместо того чтобы вовлечь всех в единое информационное поле, вы сразу, с самого начала активизируете периферические каналы коммуникаций, порождающие слухи и противоречия.

Наш капитан, впрочем, этот пункт частично выполнил. Правда, он ограничился только самыми необходимыми вопросами — сколько яхтенного опыта, в каких водах и с каким экипажем, и только в отношении прочих членов экипажа. Упомянуть о собственном опыте и создать атмосферу доверия ему в голову не пришло.

5. Определение целей и задач

Думаю, что не менее 50% успеха проекта определяется тем, насколько участники одинаково понимают цели, результаты, и какие задачи должны быть выполнены для их достижения. О том же толкуют и все практики проектного управления — в них планирование по праву занимает существенную часть. Тем не менее, создать план понятный, достаточно детальный и при этом обозримый — целое искусство. Равно как и искусство сделать такой план, который даже при невыполнении ключевых показателей и не достижении результатов может быть преподнесен как выполненный. Мы не будем углубляться не в одну из этих областей, так как вы и так наверняка неоднократно слышали замечательные формулировки «разработан процесс», «ведется выполнение», «работает в штатном режиме» и иные, аналогичные им. Если же говорить про правильное планирование, с декомпозицией измеримых результатов — то это слишком глубокая для нашего повествования тема.

Применительно к нашей ситуации, отметим что «дойти до точки В» и «стараться не повредить яхту» — существенно отличающиеся цели. И если цель — «стараться не повредить» — не озвучена, то у экипажа будет недоумение, почему при свежем ветре капитан отдает команду снять паруса и идти под двигателем, расходуя и так недостаточный запас топлива (что в нашем примере означало еще и расход денег экипажа).

Чтобы снизить не только недоумение, но и следующее за ним сопротивление, необходимо чтобы было проведено:

6. Информирование о правилах исполнения и контроль их понимания

На яхте этот пункт носит критический характер, поскольку «правила исполнения » в этом случае включает правила поведения и затрагивает почти все области жизни на борту. Представьте что 10 мужчин находятся на площади в 30-40 м2 на протяжении нескольких дней или недель. И эта площадь включает туалеты, кровати и кухню. При этом они говорят на разных языках (часть поляков не говорила на английском), у них разные традиции в быте, еде, отправлении естественных надобностей (это тоже важно). Хорошо, если они уже не первый раз сталкиваются с такой ситуацией и имеют представление об интернациональных стандартах. Иначе — горе, сравнимое с 10, а не с двумя хозяйками на одной кухне.

Я был частым свидетелем возникающих трений, и, к сожалению, не миновали они и нас. Хотя и не были неразрешимыми при должной проработке вопроса. Так, например, наш капитан исключил область вахт по камбузу из регламентируемой и в результате питался лапшой быстрого приготовления вместо нормальной домашней пищи.

В бизнесе, к счастью, люди не столь погружены во взаимодействие, а типовые ситуации и вопросы, как правило, описаны в законах, должностных инструкциях, кадровых политиках и иных регламентирующих документах компании. Тем не менее, это всегда источник постоянных вопросов как к HR службе, так и к руководителям. «Где моя премия?», «Почему Вася уходит раньше?», «Почему я за всеми доделывать должен?» — уверен, вы сами без труда продолжите этот список как вопросами от своих подчиненных, так и своими личными. Возникают они потому, что не все знают, где посмотреть «правила исполнения», «правила игры», или туда не заглядывают.

Именно с последним связан «контроль их понимания» из рассматриваемого пункта. «Написание правил» и «жизнь по правилам» в нашем менталитете не идут рука об руку друг с другом. Правила они обычно для кого-то, а для себя — понятия. Кроме того, не стоит умалять роль такой важной вещи, как интерпретация. Даже юристы, чья профессиональная область деятельности — правила, могут трактовать законы по-разному. Куда уж нам, любителям.

Поэтому, разъясняя правила, не забудьте про пункт:

7. Оценка рисков

Строго говоря, риски вашего проекта или предприятия связаны не только с неисполнением правил. Они могут быть связаны и с отсутствием правил, или их недостаточным пониманием, или вообще с внешней средой. К сожалению, частой практикой в бизнесе и проектном управлении является «наступит – тогда будем устранять». Имеющиеся же положительные практики зачастую заканчиваются, только начавшись, в момент озвучивания бюджета превентивных мероприятий. Даже в отношении критических для бизнеса подсистем, к которым в наш высокотехнологический век относится ИТ, отнюдь не все бизнесы имеют «план В».

В яхтенной же практике, риски нельзя недооценивать, и им уделяется огромное внимание. Цена этих рисков в случае исполнения может измеряться человеческими жизнями. Ключевые вещи, которые требуют резервирования – навигация, пресная вода, средства связи и спасения, медикаменты.

Один из этих рисков, хорошо известный большинству яхтенных капитанов, исполнился и у нас. Когда на яхте несколько гальюнов, а на кухне царит нездоровая анархия, посуду моют проточной пресной водой, и если никаких правил (смотри п.6) в этой области не озвучено, то не стоит удивляться тому, что вода кончается к середине путешествия. Хорошо, если при этом у вас есть резервный бак и (или) отдельные запасы питьевой воды, и плохо если нет. У нас, к счастью, резервный бак был. Тем не менее, вторую половину маршрута все гальюны были отключены от воды, а посуду мыли только при помощи ручной помпы (что автоматически в разы снижает расход).

8. Создание плана коммуникаций

Создание плана коммуникаций является очень хорошей практикой, но, к сожалению, я ни разу не видел развернутой карты коммуникаций компании или проекта за исключением разве что карты коммуникаций с клиентами и карт эскалаций для внутренних служб.

На яхте же роль описанных и озвученных правил коммуникации исключительно прозрачна и понятна. Так как капитан, как бы ему не хотелось, не может управлять процессом в режиме 24х7, а строго говоря, и не должен, так как однотипный процесс целесообразнее контролировать по отклонениям, то на каждый нештатный случай должны быть предусмотрены коммуникации. Например, необходимо определить коммуникации для ночного расхождения с другим судном, или для случая приближения к сплошной облачности (приближение атмосферного фронта). Если не предусмотреть такие ситуации, и не проинформировать экипаж о правилах оповещения, то можно хлебнуть горя, что и произошло с нами.

Мы прошли к атмосферному фронту под всеми парусами, так как капитан не проинструктировал экипаж и вахту о необходимом оповещении его в этой ситуации для принятия решения о снятии паруса, и не определил право вахты самостоятельно снимать паруса. Результат – брочинг, хорошо, что без последствий. В плохом сценарии – поломанная мачта, порванные паруса, эвакуация экипажа с середины океана и шестизначная сумма убытка (в евро).

9. Регулярный мониторинг исполнения задач и состояния рисков

Этот пункт не вызовет вопросов не у одного менеджера, но взятый в отрыве от всех остальных он не столь эффективен. Весьма продуктивно, когда задачи, с которыми работает этот процесс, являются измеримыми (а лучше SMART), и имеют четко определенного ответственного. Если же этого не удалось достичь на этапе планирования, вас могут ждать неприятные сюрпризы.

Незнание нашим капитаном этого подхода в полном объеме стало понятно уже в самом конце путешествия, при подходе к Португалии, когда зазвучали команды вроде «Уберитесь на камбузе», «Отдайте кормовые». Несложно заметить, что такие команды брошенные в воздух останутся без должного исполнения, так как ситуация когда 9 человек (экипаж минус капитан) будут убираться на камбузе или бросятся к кормовому (какому, правому или левому?) концу – достаточно комична. С последним, правда, есть еще другая интересная особенность и она называется:

10. Внесение корректировок

Этот пункт также описан в хорошей яхтенной практике, и его также не применял наш капитан. Зачастую, ситуация меняется, и меняется динамично. Тогда наряду с заданием общих правил поведения (которые должны быть разъяснены заранее и поняты, опять смотрим пункт 6), должны своевременно подаваться команды об изменении ситуации и необходимого алгоритма действий.

Швартовка яхты – традиционно нервная и неприятная для капитана процедура, так как именно в этот момент легко повредить как свою яхту, так и чужие, стоимость которых может измеряться миллионами долларов. Именно для этой процедуры экипаж инструктируется заранее, распределяются обязанности и определяется система коммуникаций (определяется, кто и что должен говорить и делать). Команды при изменении условий швартовки должны быть громкие, четкие, понимание команд фиксируется членом экипажа повторением команды с добавлением слова «Принял!».

Так легко представить эту команду на море, так сложно в менеджменте. Зачастую нам не хочется отменять свое распоряжение или приказ, так как мы видим в этом угрозу своей репутации. Поверьте, гораздо лучше отреагировать своевременно и четко, пусть и в противоречии с предыдущими указаниями, чем продолжать мучать сотрудника очевидно бесполезной работой. Как правило, неявное все равно становится явным и ваша репутация в этот момент страдает гораздо больше, чем при своевременном распоряжении. И конечно, не забывайте контролировать понимание.

11. Приемка результата

Это самый приятный момент в управлении, и немного грустный в моем яхтенном путешествии, так как для меня он означал перерыв на значительный срок. Не знаю, менталитет тут играет роль или что-то еще, но мне редко попадались руководители, которые при завершении проекта или крупного блока работ благодарят сотрудников и тем более делают разбор выполненных работ и достигнутых результатов. Да что скрывать, я и сам не сильно склонен к похвале. Тем не менее, это очень действенный инструмент, как для мотивации вашей команды, так и для выявления новых целей собственного развития. Например, целей по выполнению в следующем путешествии или следующем проекте всех пунктов, разобранных выше.

Давайте, повторим:

1. Согласование терминологии – обмениваясь информацией, понимать смысл слов одинаково
2. Согласование условий – условия вашего участия надо обговаривать заранее в мельчайших деталях, или заносить оставшиеся невыясненными моменты в ваши риски
3. Подготовка к проекту – заранее подготовить чек лист того, что нужно будет сделать на этапе подготовки
4. Знакомство с командой – узнать о команде все, что можно. Лично познакомиться с участниками и выстроить регулярные личные коммуникации
5. Определение целей и задач – определить и довести до участников цель и задачи проекта, объяснить степень участия каждого. Стараться соблюдать SMART
6. Информирование о правилах исполнения и контроль их понимания – разъяснить и проконтролировать понимание применяемой модели управления и требований к выполнению задач
7. Оценка рисков – выявить риски, разработать и предпринять превентивные меры (в соответствии с политикой управления рисками). В отношении важнейших из оставшихся, иметь план корректировочных действий на случай их исполнения
8. Создание плана коммуникаций – обеспечить понимание каждого участника, кому и что ему необходимо сообщать
9. Регулярный мониторинг исполнения задач и состояния рисков – дополнить штатный процесс управления критериями, исключающими возможность ошибочного толкования результатов. Стараться избегать расплывчатых и неизмеримых формулировок, они сделают этот процесс неэффективным
10. Внесение корректировок – не бояться перечить самому себе. «Не меняется только дурак и покойник». Изменение, впрочем, также надо оценить по SMART
11. Приемка результата – проанализировать и разобрать результаты проекта. Провести итоговую встречу с участниками проекта, обеспечить обратную связь для всех участников.