Управление проектами для чайников

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

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

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

Ниже — наш вариант управления проектами для чайников. Расскажем, что, где, как и почему.

Сразу оговоримся, материал не имеет никакого отношения к одноимённой книге Стэнли Э. Портни.

Что такое проект

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

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

Фактически все источники приписывают проектам следующие ключевые свойства:

• Конкретная цель действий.
• Сроки (фиксированные с дедлайном или возобновляемые по новым задачам, выявленным в процессе реализации целей).
• Определённые ресурсы (материальное обеспечение и человеческие ресурсы, выделяемые для реализации проекта).

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

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

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

Ещё один нюанс – чтобы исключить перерасход ресурсов, команды должны формироваться исходя из объёмов задач. То есть без лишних специалистов.

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

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

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

Даже если такие обязанности не прописаны явно, они всё равно подлежат исполнению. Более того, часть работ может быть распределена между участниками команды или поручена конкретному лицу для разгрузки руководителя, например, проектному администратору (о его обязанностях мы рассказывали отдельно здесь). Но что ни в коем случае нельзя перепоручать, это контроль. Контроль всегда должен оставаться за наиболее ответственным лицом, то есть за руководителем или лидером команды.

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

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

Но это не единственная проблема, из-за которой проекты терпят неудачи. Мы собрали целый список таких проблем.

Стадии проектов

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

Обычно выделяют 5 основных стадий существования проектов:

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

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

Стадия планирования

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

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

План должен предусматривать ключевые пункты:

• Базовые практические и теоретические обоснования – насколько возможен проект и какую выгоду вы получите от его реализации.
• Формирование технических требований (техзадание, ТЗ) к результату.
• Составление списка задач, которые необходимо реализовать для получения результата проекта.
• Описание ролей и задач членов команды (не стоит пропускать этот пункт, если вы хотите, чтобы команда работала слаженно и каждый знал свою зону ответственности).
• Расчёт ресурсов (можно с привязкой к задачам).
• Список рисков (как планировать и управлять рисками, мы рассмотрели в отдельном материале – здесь).

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

Стоит понимать: чем выше ответственность, тем детальнее должны быть планы. А значит, должен применяться профильный софт, способный реализовать все необходимые функции: контроль, обеспечение обратной связи, оповещения о наступающих сроках, ведение личных календарей, хранение документов и не только. Например, Projecto идеально подходит для малых и средних проектов, работающих с гибкими методологиями, предоставляется по SaaS-модели (без необходимости установки и внедрения).

Как правильно формулировать цели и задачи

Как составить идеальный план проекта

Начальная стадия

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

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

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

Чтобы сэкономить ваше время, мы подготовили список ТОП-10 методологий для ведения проектов.

Многие IT-проекты, в том числе крупные компании корпоративного сектора, выбирают Agile-подход. Это Scrum и Kanban. Они выделятся на общем фоне простой и понятной реализацией, хорошо документированы и предполагают небольшие циклы итераций для промежуточного контроля, а так же непрерывный общий контроль за счёт совместной работы с представителем клиента.

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

Стадия реализации

Когда методология выбрана, а притирка уже прошла, вы можете сконцентрироваться непосредственно на работе проекта:

• Выбираются исполнители.
• Ставятся задачи.
• Контролируется их исполнение.
• Проводятся встречи, обсуждаются сложности, ищутся лучшие пути решения.
• И прочие шаги.

В реализации многих задач управления опять-таки могут помочь BPM-системы (чем они отличаются от ERP и CRM).

Завершающая стадия

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

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

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

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