Projecto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exit mobile version