Применение проектного подхода в бизнесе. Шаблон проекта

Процесс принятия решений в организации зависит много от чего и много чего влияет на качество таких решений.

Если посмотреть на определение,то:

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

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

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

Проект (в управленческой деятельности) (англ. project от лат. projectus — брошенный вперёд, выступающий, выдающийся вперёд) — временно́е предприятие, направленное на создание уникального продукта, услуги или результата.

Другие определения данного понятия из международных стандартов:

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

С такими определениями далеко не поедешь слишком уж они заформализированы.

Антонио Ньето Родригес в своей книге «Цель как проект» (именно она вдохновила написать эту статью и далее я буду буду брать из нее основные тезисы) дает такое определение проекта:

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

Чем же проекты отличаются от операционки:

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

Что такое проектное управление?

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

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

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

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

Все тот же Антонио Ньето Родригес дает такое определение:

Управление проектами — компетенции, методы и инструменты, которые помогают людям успешно определять, планировать и реализовывать проекты.

Но необходимо учитывать следующие моменты:

• Управление проектами — это не бесплатное удовольствие и затраты на этот процесс могут достигать от 7 до 15% общей стоимости проекта.
• Последней тенденцией есть возрастание роли лидерства и оно становится более приоритетным чем управление проектами.

Не вся деятельность есть проектом, необходимо четко различать операционку и проекты и руководствоваться здесь стоит практическим подходом:

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

Проектное управление не стоит на месте и эволюционирует. Зародившись в 1970-х и 1980-х годах оно обрастало все новыми методиками и идеями и это привело к публикации в 1996 году PMBOK, где были описаны процессы управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также целям, которым они служат.

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

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

Модель управления проектом и ее применение

Давайте я попытаюсь несколько все упростить и посмотрим на проект с точки зрения обычного человека, который принимает в нем участие.

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

• Зачем — обоснование целесообразности проекта и ожидаемых выгод, а также замысел и страсть, необходимых для успешной реализации проекта (20%);
• Кто — участники, ответственные за подотчетность и управление, которые должны обеспечить проект ресурсами и гарантировать достижение результатов (20%);
• Что, как и когда — аспекты проекта (содержание, сроки, стоимость, качество, управление рисками, поставки, мотивация, навыки, управление измениями, коммуникация) (50%);
• Где — организация, культура, приоритеты и контекст осуществления проекта (10%).

Принципы успеха применения данной модели:

1. Перед тем как начать проект, нужно оценить его необходимость, определить цель и связь с общей стратегией компании — а нужен ли он нам?
2. Вам не обойтись без активного и постоянно вовлеченного куратора проекта, если такового нет — ваш проект будет бесхозным и никому ненужным и вряд ли он закончится успешно;
3. Проект — это всегда изменения, которые вызывают сопротивление и надо его учитывать с самого старта проекта;
4. Менеджеры проектов должны быть лидерами — хорошо понимать содержание проекта и контролировать все действия и направлять их для успешного завершения проекта;
5. Люди важнее процессов и их нужно мотивировать;
6. Неудачные проекты — это опыт, который нужно применять в следующих проектах (избегать ошибок);
7. Управление рисками — неотъемлемая часть управления проектами;
8. Необходима гибкость при управлении проектами;
9. Необходимо устанавливать приоритеты;
10. Показатели эффективности проекта должны быть привязаны к результатам, а не к вложениям в проект;
11. Проектно-ориентированные организации как правило более гибкие, чем компании с традиционной иерархической структурой;
12. Проект не может длиться вечно и должен быть завершен, даже если выполнены не все задачи.

И давайте расмотрим каждый блок более детально.

Зачем

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

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

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

SMART является аббревиатурой, расшифровка которой: Specific, Measurable, Achievable, Relevant, Time bound. Каждая буква аббревиатуры SMART означает критерий эффективности поставленных целей.

Замысел и страсть тоже важные элементы любого проекта. Определение замысла это вопрос ясности и согласованности. Замысел проекта помогут определить следующие вопросы:

• Почему проект важен?
• Какая возможность будет потеряна, если проект не будет реализован;
• Для кого проект важнее всего?
• Зачем кому-то тратить время на участие в проекте?

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

Эта область связана с обеспечением подотчетности и распределения обязанностей. Она включает куратора проекта и структуру управления.

Куратор проекта должен ему уделять достаточно времени и не должен курировать сразу несколько проектов.

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

Структура управления содержит информацию о роляч участников и ключевых лиц принимающих решения.

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

Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность.

Расшифровка RACI:

1. R (Responsible) – тот, кто будет делать работу. Например, модуль Х будет писать разработчик Вася. Для каждой задачи должен быть как минимум один “R”, можно больше.
2. A (Accountable) – тот, кто примет итоговую работу и будет нести за нее ответственность. Принимать у Васи модуль Х и отвечать перед руководителем проекта головой за то, что он заработает, будет его тимлид Петя. “А” для каждой задачи должен быть только один, отсутствовать “А”, также как и “R”, в задаче не может. В исключительных случаях (обычно для совсем маленьких команд) “А” и “R” будут одним и тем же человеком, тогда достаточно указать просто “А”. Но вообще это нехорошая практика.
3. C (Consulted) – тот, кто будет в обязательном порядке консультировать остальных при выполнении задачи. Чтобы модуль Х работал как надо, и Васе и Пете надо будет согласовать свои идеи по реализации с Инной, главной за информационную безопасность в компании, и Еленой, архитектором проекта. “C” в задаче может быть, а может и не быть.
4. I (Informed) – тот, кто должен быть в курсе принимаемых решений или хода выполнения задачи, но влиять на них никак не будет. Руководитель поддержки Иван, которого пользователи уже запинали в ожидании модуля Х, будет грустно читать статусы и рассылки о ходе разработки модуля, смотреть таски в JIRA и тяжело вздыхать. По аналогии с “C”, “I” в задаче может быть, а может и не быть.

Что, когда и как

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

Содержание

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

В 1980-х гг. компания Cap Gemini создала модель BOSCARD, которая предназначена для определения содержания проекта и состоит из 7 вопросов:

1. Каковы условия, в которых реализуется проект (Background)?
2. Каковы основные цели проекта (Objectives)?
3. Что будет сделано в результате проекта (Scope)?
4. Каковы основные ограничения, мешающие успешной реализации проекта (Constraints)?
5. Какие допущения были сделаны (Assumptions)?
6. Какие риски могут привести к провалу проекта (Risks)?
7. Каковы желаемые результаты проекта (Deliverables)?

Время

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

Стоимость

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

Бюджетированием проекта называется определение стоимости проекта в целом и работ, выполняемых в ходе его реализации, а также процесс формирования проектного бюджета, который содержит утверждённое распределение затрат по:

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

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

Для расчета бюджета можно воспользоваться тем же самым инструментом планирования «сверху вниз» и «снизу верх». И в бюджет желательно накидывать 10-20% сверху.

Качество

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

Недостаток качества может привести к отмене проекта.

Для успеха проекта требуется как обеспечение качества (Quality Assurance, QA), так и управление им (Quality Control, QC).

Управление рисками

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

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

Процесс управления рисками проекта обычно включает выполнение следующих процедур:

1. Планирование управления рисками — выбор подходов и планирование деятельности по управлению рисками проекта.
2. Идентификация рисков — определение рисков, способных повлиять на проект, и документирование их характеристик.
3. Качественная оценка рисков — качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.
4. Количественная оценка — количественный анализ вероятности возникновения и влияния последствий рисков на проект.
5. Планирование реагирования на риски — определение процедур и методов по ослаблению отрицательных последствий рисковых событий и использованию возможных преимуществ.
6. Мониторинг и контроль рисков — мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков.

Для оценки рисков можно воспользоваться матрицей рисков

Поставки

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

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

Персонал

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

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

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

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

Заинтересованные стороны

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

Для выявления заинтересованных сторон и определения их влияния на проект можно воспользоваться матрицей анализа заинтересованных сторон.

Эта область охватывает внешние аспекты проекта, оказывающих на него влияние.

Проектно-ориентированная организация

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

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

В таком случае необходимо создание корпоративного офиса управления проектами.

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

Более детально про офис управления проектами можно почитать на Википедии.

Источник https://www.antonpiskun.pro/primenenie-proektnogo-podhoda-v-biznese-shablon-project/

Источник

Источник

Источник