Проектный подход, часто понимаемый практиками как утилитарный «ящик с инструментами на все случаи жизни» требует определённой вдумчивости при его использовании на проектах различного масштаба.
Это естественно, однако на практике не всегда легко.
Руководитель проекта (далее по тексту - РП) будет встречаться с принципиально разными проблемами в зависимости от масштаба проекта.
Справедливое предположение о необходимости адаптации проектного инструментария к масштабу проекта часто ускользают от РП и в целом, на взгляд автора, недостаточно освещено в профессиональной литературе.
Предмет внимания в настоящем материале – малые проекты (далее по тексту МП).
На уровне теории управления проектами различия между масштабным и малым проектом почему-то не формулируется.
Будем считать в рамках данного материала, что численность МП – до 20 человек, при этом сохраняется прямое взаимодействие РП с каждым участником проекта.
В некоторых сферах именно малые проекты составляют абсолютное большинство ведущихся проектов.
Так происходит, например, в сфере разработки ПО.
Трудно оценить количество стартапов в масштабах планеты или даже нашей страны, но есть гипотеза (и она выглядит правдоподобной), что малых проектов в абсолютном выражении существенно больше, чем крупных проектов.
Пилотировать проекты такого типа доверяют людям с разным опытом проектного управления, так как определяющей (наиболее значимой) характеристикой часто является харизма/пассионарность РП, а не опыт проектного управления и уровень понимания PMBoK.
На сегодняшний день руководители МП находятся совершенно в ином контексте, нежели руководители крупных проектов.
Именно этот тезис и различные следствия из него являются предметом для дальнейшего рассмотрения.
Очевидно, что на малом проекте явственнее проявляются индивидуальные особенности каждого члена проекта, сильнее работают горизонтальные связи, РП пользуется инструментами индивидуального действия/направленности.
Вот с этим и надо разобраться более детально.
Термин «малый проект» ни в коей мере не должен наводить на мысли про «неполноценный проект».
Начнём с этапа инициации проекта. В основном она наполнена работой по формированию команды.
На этом этапе роль РП, на взгляд автора, крайне важна.
Дистанцироваться от работы по формированию проектной команды, перепоручать формировать команду HR-специалисту – грубая ошибка, которая, к сожалению, наблюдается примерно в половине малых проектов.
Осознание отдельно взятым человеком, погруженным в современный контекст, потребности сотрудничества не всегда происходит легко и естественно.
Это функция опыта человека.
Да и сам процесс осознания разбивается на фазы, для которых свойственны различные ментальные/психологические признаки.
«Человек сотрудничающий» далеко не всегда возникает сам по себе.
В голове человека, разумно относящегося к своей деятельности, идут параллельно два процесса – понимание (иногда весьма психически травмирующее) собственных индивидуальных ограничений и поиск других людей, способных эти ограничения элиминировать и объединёнными усилиями все-таки получить желаемый результат.
Так постепенно, возможно, за несколько итераций образуется группа/команда проекта.
РП, видя потенциального члена команды и оценивая его готовность к коллаборации, может принять решение о его привлечении.
Ощущение единения, причастности, соединенности с другими людьми, возможно, является архаичным.
Но это чувство в нашем случае не должно быть проигнорировано, ибо оно в малых проектных командах создает, помимо прочего, «единый мозг».
Это состояние коллектива пока недостаточно изучено – иногда оно даже отрицается.
Во всяком случае, со стороны специалистов по проектному управлению пока не встречалось попыток исследовать этот феномен.
Для больших проектов создание единого мозга исключено.
Бывает, что РП, пытаясь минимизировать фазу инициации проекта, перекладывает существенную часть работы по формированию команды на HR-специалиста и тот, не будучи погружен в нюансы будущего или текущего проекта, выбирает, как ему кажется, самый технологичный путь решения задачи, поступившей ему от РП – то есть предлагает потенциальным членам команды пройти анкетирование или некий (стандартный) набор тестов.
Возвращаясь к масштабным проектам, отметим, что для них это практически единственный способ собрать проект в разумное время.
Но для малых проектов, на взгляд автора, такой способ непригоден, хотя, очевидно, весьма технологичен с точки зрения минимизации усилий на рекрутинг.
Но такому способу следует предпочесть непосредственное собеседование, как способ собрать больше информации и тем самым либо избежать упомянутых выше проблем, либо получить заранее сигнал о том, к чему надо готовиться РП.
Затраты времени РП, как показывает практика управления малыми проектами, достаточно велики, но почти всегда они оказывается оправданными.
Согласно классическому взгляду, объектами управления являются элементы триады «сроки/задачи/ресурсы».
Но для случая малого проекта триада сроки/задачи/ресурсы репрезентируются через другие сущности. Например, такие как:
• Текущее состояние члена команды, текущий уровень компетенции,
• Его мотивированность,
• Отзывчивость и готовность к сотрудничеству внутри команды и с Заказчиком,
• Отсутствие боязни эскалирования возникающих проблем,
• Другие сущности, специфические и ситуативно имеющие значение для малого проекта.
Такая репрезентация позволяет РП оценить возможный вклад каждого члена проектной команды и его влияние на общепроектные параметры (сроки/задачи/ресурсы).
Имеется наблюдение, говорящее нам о том, что далеко не всегда удается гармонично пройти фазу инициации проекта.
Например, не всегда реально найти нужное количество специалистов с нужным уровнем компетенций, «правильной» мотивацией за требуемое время.
Проекты часто начинаются в условиях довольно жесткого кадрового дефицита.
Это, конечно, плохо, но такова реальность. Поэтому РП принимает решение или начинать проект с теми сотрудниками, которые есть в настоящий момент, либо его вовсе не начинать, за что он может быть наказан.
Многие проекты стартуют в предположении, что необходимых сотрудников можно добрать быстро и это не будет являться проблемой.
Или это будет проблемой HR-специалистов.
На практике количественная или квалификационная недостаточность команды может длиться долго и тогда РП принимает решение искать людей более широким фронтом, день ото дня снижая «порог вхождения» для претендентов.
Это, конечно, не означает, что на нужную позицию в команде пригласят «абы кого», но вероятность того, придётся встретиться с неожиданными или нежелательными поведенческими шаблонами из приведенного ранее списка – увеличивается многократно.
(Хотя, справедливости ради надо сказать, что от проявления членами проектной команды нежелательных поведенческих шаблонов не застраховывает и полная комплектность команды на старте проекта.)
Какими компетенциями должен обладать РП, чтобы успешно выполнять свои функции?
Корректным было бы выводить требования к этим компетенциям из характерных (видовых) признаков самого МП.
Вот элементы контекста, в котором разворачивается работа РП:
• Небольшое количество участников и, следовательно, доступность их для индивидуальной оценки/стимулирования,
• Специфический инструментарий РП,
• Наличие специфических рисков на индивидуальном уровне членов команды, необходимость в них ориентироваться со стороны РП,
• Качество межличностных отношений должно находиться в фокусе внимания РП и определяет, в конечном счете, его управленческую компетенцию,
• Малая автономность участников проекта (в смысле - недолгая «безнадзорность» со стороны РП), вследствие чего высока вероятность быстрого «выгорания»,
• Непозволительность долгого решения управленческих задач (ограниченность собственно управленческого бюджета),
• Соблазн использовать некую схожесть с методологией Agile, заимствовать определенные управленческие инструменты (по типу daily meetings, например) и считать управленческую подготовку после этого достаточной.
Задача РП в широком смысле - добиться прогнозируемого поведения каждого члена проектной команды на ограниченном временном интервале – пока идёт проект. Собственно управление, если вернуться к основам, состоит в решении возникающих проблем. То есть - в их прогнозировании (по возможности), фиксации и реагировании. А проблемы проистекают, как правило, из поведения людей, их психических особенностей и форм реагирования на те или иные проектные ситуации. Поэтому требование к психологическому анализу возникающих на проекте ситуаций – базовое для РП, находящегося в условиях МП.
Но не обязательно РП надо быть профессиональным психологом, чтобы понимать, что есть несколько параллельно существующих классификаций людей, например:
• интраверты/экстраверты,
• флегматики/меланхолики/сангвиники/холерики.
И, соответственно, можно прогнозировать проявления реакций того или иного типа. Важно уметь увязывать и отделять друг от друга суть и форму проявления реакции.
Если рассмотреть модель поведения человека в проектном контексте, то полезно не упускать из виду следующее (опять же – вполне доступное для восприятия со стороны РП).
Любой участник команды как-то себя позиционирует относительно РП, каким-то образом реагирует на те или иные производственные ситуации и действия РП по ходу реализации проекта.
Вариантов не так много, основные мы перечислим ниже.
Член команды, по мнению и опыту автора, демонстрирует следующие реакции (возможно, этот список не исчерпывающий, но весьма показательный):
• показывает определенную (понятную для РП) обратную связь на личное поощрение/наказание со стороны РП,
• показывает определенную (понятную) реакцию на обратную связь от других членов команды,
• индифферентно реагирует на личное поощрение/наказание со стороны РП или одобрение/неодобрение со стороны других членов проектной команды,
• демонстрирует определенную поддержку действиям РП, ситуативно показывает определенный уровень лояльности,
• выражает бурную, яркую поддержку действиям РП, демонстрирует неадекватно высокий уровень лояльности,
• априори настроен скептически в отношении всех действий РП и не особо скрывает это, систематически предлагает иные решения
• коллекционирует промахи и ошибки РП,
• активно и публично поддерживает РП во всех репрессивных начинаниях в отношении прочих членов команды…
Эти (и иные) реакции (или поведенческие шаблоны) как-то развёрнуто комментировать, полагаю, тут нет особого смысла.
Они становятся видны РП и осознаваемы им только после начала реальной проектной работы.
Отметим пока зависимость девиаций от нагрузки - это богатая и плохо изученная тема, но компактно её тут изложить невозможно.
Предугадать на фазе инициации проекта типы и степень девиаций достаточно затруднительно, но в этом и заключается опыт/интуиция РП.
И для этого мы рекомендуем не жалеть времени на этапе собеседований.
Собственно говоря, это и есть тот первичный материал, с которым дальше работает РП – успешно или не очень.
Члены команды репрезентируются своими поведенческими шаблонами и РП необходимо научиться не только адекватно и вовремя воспринимать эту информацию, но и использовать её с пользой в контексте проекта – собственно говоря, в этом и заключается управление.
Девиации поведенческих шаблонов членов команды для подготовленного РП не являются экстраординарным событием.
Большинство РП, имеющих необходимый уровень профессиональных компетенций, так или иначе научились или научатся адекватно реагировать на такие особенности членов проектной команды.
Другое дело, что не все готовы систематизировать накопленный опыт, используемые приёмы и сделать это достоянием сообщества.
Но правильный баланс личных убеждений РП, ценностных корпоративных установок и профессиональных компетенций (как сугубо управленческих, так и в предметной сфере проекта) не возникает сам по себе.
Для этого нужно проводить специальную подготовительную работу, основные положения которой предполагается изложить в отдельной статье.
Другие тексты, так или иначе примыкающие к этой теме:
Отличия в управлении стартапом от иных видов управления,
Малые деловые коллаборации,
Проектные команды