ИТ-архитектура от А до Я: Теоретические основы. Первое издание. Концепция Управления Проектами (Вадим Алджанов)

Общие Положения

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

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

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

•Есть конкретная дата начала. Ключевой признак проекта «временная составляющая», т. е. есть начало и конец проекта.

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

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

•Ресурсы и бюджет – ограничены.

•Специфический порядок выполнения заданий. Он может предполагать временное изменения в иерархии подчинения и управления от установленного в организации.

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

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

Ключевые аспекты Управления Проектами

Тройственная ограниченность или Треугольник проекта – описывает баланс между содержанием (объем работ или scope), стоимостью (cost) и временем (time, schedule) проекта, что влияет на конечный результат – качество (quality). Качество – это четвертый элемент проектного треугольника, который находится в центре, и любое изменение сторон влияет на него.

Как говорится в популярном слогане «Сделаем хорошо, быстро, дешево. Нужное подчеркните».

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

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

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

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

Идея всех методик и подходов сводится к фокусированию внимания на одном или нескольких факторах с контролем воздействия на оставшиеся.

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

Цель руководителя проекта – достижения критериев успешности проекта.

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

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

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

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

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

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

•Административные проекты – связанны с изменениями в организации как правило не влияющие на состояние ИТ инфраструктуры, или без привлечения ИТ ресурсов.

•Внутренние проекты – происходящие, как правило, внутри одного подразделения организации и характеризуются незначительными изменениями в ИТ инфраструктуре или с незначительным привлечением ИТ ресурсов

•ИТ проекты – проекты, происходящие внутри организации, в значительной степени влияют на состояние ИТ инфраструктуры, имеющие цель изменить ИТ инфраструктуру организации, или с привлечением значительных ИТ ресурсов организации.

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

•Бизнес подразделения

•ИТ департамент.

Вводной информацией на данном этапе может служить стратегия организации или бизнес план.

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

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

•Задает направление работ по реализации проекта.

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

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

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

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

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

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

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

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

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

Подходы и методы управления проектами

Выбор правильной методологии управления проектами (Project Management Methodologies PMM) – первый шаг к успеху вашей команды. Управление проектами помогает улучшать их реализацию с точки зрения эффективности и затрат, одновременно снижая риски. Но одного лишь декларирования приоритетов для этого недостаточно. Нужно хорошо понимать, какое позитивное воздействие оказывает каждая из методологий управления проектами и чем она может помешать успешной реализации проекта.

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

Процессно-ориентированное проектное управление (Process-Based Project Management PBPM)

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

Классическая Методология Управления Проектами «ВОДОПАД» (WATERFLOW)

«ВОДОПАД» (WATERFLOW) – Традиционная, классическая методология управления проектом. Она также носит название «каскадной» или «поточной» модели, вследствие того, что предлагаемая ею последовательность фаз напоминает водопад. Наиболее очевидный способ сделать свой проект более управляемым – это разбить его процессы реализации на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. Данный подход не предполагает возврата к предыдущим этапам по их завершению и принятию, или внесение изменений в требования проекта. Данная методология управления проектами предполагает разбиение проекта на ряд последовательных задач, с четким определением целей и сроков. Члены проекта выполняют задания в установленном порядке, завершая каждое задание перед тем, как преступать к последующему. В «водопадной» модели, в применении к ИТ проектам разработки программного обеспечения, стадии идут в следующем порядке:

•Определение требований

•Проектирование

•Конструирование («реализация» или «кодирование»)

•Интеграция

•Тестирование и отладка («верификация»)

•Инсталляция

•Поддержка

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

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

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

Гибкая Методология Управления Проектами (Agile Project Management Methodology)

AGILE – семейство процессов и методов разработки гибких методов управления и ведения проектов. Сам по себе Agile – скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют – фреймворк (frameworks). Примеры: Scrum, Kanban, Crystal, LeSS, SAFe, Nexus и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам. Гибкие методы предполагают изменения требований к продукту в течении всего времени проекта. Такое проектирование подразумевает совершенно иной подход к управлению проектами. Изначально методология разрабатывалась для проектов, которым требуются высокая гибкость и быстрая реализация. Гибкое управление проектом представляет собой поступательную и итеративную проектную методологию. Ее главной особенностью является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта. Вместо этого, проектная деятельность разбивается на несколько итеративных фаз – короткие циклы, называемые «спринтами». Каждый спринт состоит из множества задач и имеет свой конечный продукт и результат. Методология Agile позволяет менеджерам проектов постоянно получать обратную связь и улучшать продукт после каждой итерации. В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

•Владелец продукта – определяет проектные цели, разрабатывает оптимальный график при заданных проектных параметрах, адаптирует процесс выполнения проекта к изменившимся требованиям и устанавливает приоритеты в характеристиках продукта

•Scrum мастер – устанавливает приоритеты в выполнении задач командой проекта и устраняет возникающие затруднения, препятствующие этому

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

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

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

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

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

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

Метод SCRUM семейства Гибких Методов Управления Проектами

SCRUM – («схватка») классический метод, с описанием процессов планирования, контроля и анализа на всех этапах ведения проекта, базирующийся на идеях Agile. Методология реализации agile-разработки предполагает использование интерактивного подхода. «Скрам-сессии», или «30-дневные спринты», используются для определения приоритетных задач. Роль менеджера проекта для упрощения передается скрам-мастеру. Для независимого решения конкретных задач формируются небольшие команды. В ходе встреч со скрам-мастером оцениваются достигнутые результаты, после чего определяется приоритетность невыполненных задач. Основная особенность методики:

•Совещания и анализ по определённым отрезкам времени «спринтов» (sprints).

•Небольшая команда

•Ограничение по определенным промежуткам времени (sprint) для выполнения WIPs.

•Определённых «кусок» продукта (Work in Process WIPs)

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов («W» – product backlog). Затем владельцем продукта – представителем заказчика в команде определяются приоритеты этих частей. Самые важные «кусочки» первыми отбираются для выполнения в спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце спринта заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему спринту. Длительность у спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям заказчика, которые имеют свойство изменяться со временем, перед началом каждого спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, лидер команды проекта (Scrum Master) и владелец продукта. И ответственность за этот процесс лежит на всех. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача – следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены. Основная структура процессов Scrum вращается вокруг 5 основных встреч:

•упорядочивания заделов (backlog),

•планирования Спринта,

•ежедневных летучек

•подведения итогов Спринта

•ретроспективы Спринта.

Встреча по упорядочиванию заделов (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него зависит, какую ценность получит Заказчик по итогам спринта.

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

Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

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

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

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

Слабые стороны – очень требователен к команде проекта. Она должна быть небольшой (5—9 человек) и кросс-функциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например, разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга. Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь само-организовываться.

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

Метод KANBAN семейства Гибких Методов Управления Проектами

KANBAN – также представляет из себя гибкий, итеративно-инкрементальный подход к управлению проектами базирующийся на идеях Agile. Является противоположностью «SCRUM» метода. Основные особенности методики:

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

•Работа вносится в карточку (Sticker)

•Количество «незавершённой» работы (WIPs) ограничено для каждой стадии

•Новая работа берется только тогда, когда существующая выполнена или «вытянута» (LEAN).

•Больше внимания к управлению изменениями, визуализация узким мест, незавершенной работы и т п

•Ограничения по количеству WIPs и их статусы

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

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

Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть, как настоящей, так и электронной – даже здесь Kanban не накладывает никаких ограничений на пользователей. Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile.

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

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

•Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.

•Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.

•Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

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

Слабые стороны – Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких сроков. Для жёстких сроков проекта лучше подходит классический подход или Scrum.

Гибридная Методология Управления Проектами

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

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

Прочие методы и специфические подходы к Управлению Проектами

Методология Быстрой Разработки Приложений (Rapid Application Development RAD)

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

Диаграмма: Сравнение WATERFLOW и RAD подходов

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

•Планирование

•Пользовательское проектирование

•Быстрое конструирование

•Переключение

Основные преимущества применения различных подходов RAD:

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

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

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

Методология Экстремального Программирование (Extreme Programming XP)

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

Методология моделирования событий Event Chain Methodology (ECM)

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

Метод Адаптивные Рамки Проектов APF (Adaptive Project Framework)

Использование адаптивных/регулируемых рамок проектов APF (Adaptive Project Framework) позволяет улучшать проект на каждом этапе, основываясь на полученном опыте от предыдущих результатов. Определив цели проекта и постоянно контролируя работы проекта, менеджер может обеспечить успех максимально возможной стоимости бизнеса и создать бизнес-ценность для потенциального потребителя.

Метод «Реализация Выгоды» (Benefit Realization BF)

Цель метода «Реализация Выгоды» (Benefit Realization BF) – выгода от реализации проекта Успех определяется как достижение желаемой/ожидаемой выгоды. Если клиенты хотят увеличить продажи CRM (система управления взаимоотношениями с клиентами – customer relationship management software), проект не будет выполнен/реализован до того момента, пока продажи не повысятся на 15% – даже если Вы установили и наладили работу CRM вовремя и с соблюдением/в соответствии с бюджетом.

Методология PRISM (проекты со встроенными устойчивыми/жизнеспособными методами)

Сочетание проектного планирования с экологической устойчивостью мер. Хотите пойти в «зеленом» направлении? В таком случае, PRISM точно для Вас! Сокращение расходования энергии и издержек обращения (распределение затрат), все это при одновременном снижении Вашего воздействия на окружающую среду.

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

•функционально-ориентированная разработка (feature driven development, FDD),

•разработка динамических систем (dynamic systems development, DSDM),

•адаптивная разработка программного обеспечения, Rational Unified Process (RUP),

•Концепции Шесть сигм (six sigma) и Бережливого Производства (LEAN). Управление проектом на основе принципов «контроля качества». Будут детально рассмотрены в следующей главе.

Методология Управления Проектами в Контролируемой Среде (PRINCE2)

PRINCE2 (Projects in Controlled Environments PRINCE2) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология (PBPM), которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков).

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

Принципы методологии PRINCE2

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

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

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

Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;

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

Фокус на продуктах – необходимо концентрироваться на определении и достижении результатов проекта.

Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска.

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

Темы методологии управления проектами PRINCE2

Обоснование проекта: какую ценность проект принесёт организации?

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

Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить

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

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

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

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

Семь процессов управления PRINCE2

И наконец, PRINCE2 подразумевает следующие семь процессов управления проектом:

•запуск проекта

•руководство проектом

•инициация проекта

•контроль этапов

•управление созданием продукта

•управление границами этапов

•закрытие проекта

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

Сильные стороны PRINCE2:

•Адаптируемость к особенностям организации;

•Наличие чёткого описания ролей и распределения ответственности;

•Акцент на продуктах проекта;

•Определённые уровни управления;

•Фокус на экономической целесообразности;

•Последовательность проектной работы;

•Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2 – Отсутствие или нехватка отраслевых практик и отсутствие конкретных инструментов для работы.

Управление проектами на основе методологии «PROJECT MANAGEMENT INSTITUTE PMI»

Общие положения

Данная методология является представителем Процессно-ориентированное подходом у Управлению Проектами (Process-Based Project Management PBPM) и основывается на методологии традиционного, классического подхода к управлению проектами. Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. Все процессы в руководстве PMBooK разделяются на следующие группы (фазы):

Группа процессов инициации проекта (Initiating)

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

Группа процессов инициации состоит из процессов, способствующих формальной авторизации начала нового проекта.

•Разработка Устава проекта (Develop Project Charter)

•Определение заинтересованных сторон (Identity Stakeholders)

Группа процессов планирования проекта (Planning)

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

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

•Задача четко определяет, что должно быть сделано для достижения целей

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

Метод «SMART» помогает сформулировать цели и задачи проекта как:

•Specific – Быть точным при постановке цели

•Measurable – Установить измеримые показатели состояния

•Assignable – Иметь возможность поручить выполнение задания кому-нибудь

•Realistic – Определить, могут ли быть реально выполнены в срок и в рамках выделенных ресурсов

•Time related – Определить временные рамки, т. е. продолжительность ее выполнения

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

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

•финансовые ресурсы (как прямые необходимые для реализации проекта, так и на управление проектом)

•людские ресурсы (кто, когда, как и на какой срок участвует в проекте)

•материальные ресурсы (имеющиеся в наличие, требуемые и т п)

•административные ресурсы (полномочия, организация)

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

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

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

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

•Его состояние и срок завершения легко определить, оно имеет четко определенное начало и конец

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

•Включает в себя работы, которые поддаются контролю и не зависят от работ, составляющих другие задания

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

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

•уровнем квалификации сотрудников, выполняющих задание

•использованием различного оборудования

•доступностью материалов

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

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

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

•Рабочая сила

•Материалы

•Другие прямые затраты (командировки, телефон, услуги по контрактам)

•Косвенные затраты (накладные расходы)

Далее необходимо определить последовательность выполнения заданий по проекту. Для простых проектов можно выполнять задания по одному по порядку. Другой путь – провести анализ всех заданий и определить, какие из них необходимо завершить до начала выполнения других. Такой анализ позволяет выявить порядок, в котором можно одновременно выполнять несколько заданий Методом критического пути (МКП) определяет последовательность одновременно выполняемых заданий, который позволяет завершить проект в установленные сроки. Выявление критических заданий, определение критического пути и построение диаграмма приоритетов – представить проект в графическом виде. Для этого необходимо освоить несколько простых правил построения схем проектов. Задание является основной «единицей анализа» в упорядоченной схеме. Задания представляются на схеме в виде прямоугольников, называемых «узлами заданий». Символы, изображенные в прямоугольнике, описывают временные свойства задания. Некоторые из них описывают характеристики самого задания (например, номер задания), тогда как другие представляют собой расчетные величины (ES, EF, LS, LF), связанные с заданием. Время выполнения проекта – это самый длинный временной путь на схеме. Последовательность заданий, составляющая самый длинный путь, называется критическим путем. До тех пор, пока задания, находящиеся на критическом пути, выполняются в срок, проект идет по графику. Определим теперь четыре расчетных параметра (ES, LS, EF, LF), связанные с каждым узлом задания. Следующие расчетные величины будут использованы для определения времени выполнения проекта и критического пути:

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

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

Самое позднее время начала (LS) и самое позднее время окончания (LF) задания – это самые поздние моменты времени, когда можно начать (LS) или закончить (LF) задание, не увеличивая время выполнения проекта в целом.

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

Резерв времени – это допустимая величина задержки начала или окончания задания, которая не приводит к задержке выполнения проекта в целом. Резерв времени математически представляет собой разность LS – ES (или LF – EF, что-то же самое). По определению, последовательность заданий, имеющая нулевой резерв, является критический путь.

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

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

•полное описание заданий по проекту, необходимых затрат времени и ресурсов;

•такое подробное описание необходимо администрации, чтобы решить, следует ли перейти к этапам реализации проекта

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

•справочную документацию для административного контроля;

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

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

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

•Название проекта

•Цели проекта

•Руководитель проекта

•Владелец проекта или заинтересованные лица

•Состав рабочей группы

•Задания – Этот раздел состоит из трех подразделов: номер задания, краткое, но смысловое имя, присвоенное заданию и описание задания. В нем должно содержаться в (точных выражениях) конкретное изложение содержания работы, которую необходимо выполнить.

•Оценочные даты начала и завершения работ.

•График выполнения проекта

•Смета проекта – Информация о смете в этом отчете обобщается на уровне задания.

•Метрики и критерии достижения целей

•Дополнительные условия

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

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

В группу процессов планирования входят следующие процессы:

•Разработка плана управления проектом

•План управления содержанием

•Сбор требований

•Определение содержания

•Создание иерархической структуры работ

•Разработка плана управления расписанием

•Определение операций

•Определение последовательности операций

•Оценка ресурсов операций

•Оценка длительности операций

•Разработка расписания

•Разработка плана управления стоимостью

•Оценка стоимости

•Определение бюджета

•Планирование качества

•Разработка плана управления человеческими ресурсами

•Планирование коммуникаций

•Планирование управления рисками

•Идентификация рисков

•Качественный анализ рисков

•Количественный анализ рисков

•Планирование реагирования на риски

•Планирование закупок

•Разработка плана управления заинтересованными сторонами

Группа процессов реализации проекта (Executing)

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

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

•Образование и опыт

•Лидерство и стратегическое мышление

•Техническая компетентность

•Умение работать с людьми

•Доказанные способности к управлению

Выбор рабочей группы зависит от ряда факторов:

•от задачи и целей проекта

•от характера работы, которая должна быть сделана

•от квалификации, необходимой для найма, назначения, получения полномочий, контроля, связи и выполнения требуемой работы на каждом из этапов проекта

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

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

•Этап формирования – члены рабочей группы знакомятся друг с другом, «ломается лед» и налаживаются отношения.

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

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

•Этап выполнения – Рабочая группа готова к реализации проекта.

•Этап роспуска – Это этап окончания проекта или задачи, на котором рабочая группа распускается

Ре-интеграция участника проекта – процесс ввода/вывода участника проекта в/из проекта. Руководитель проекта осуществляет подготовку к ре-интеграции сотрудников после завершения проекта (проводит личные собеседования с персоналом и их линейным руководством). Задачи руководитель проекта:

•осуществлять контроль развития членов своей команды,

•обучение участников проекта,

•предоставление проектных инструкций, документацию

•ре-интеграцию новых или вернувшихся членов команды.

•По окончанию проекта, осуществлять возврат участников проекта в свои подразделения или к линейному руководителю.

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

В группу процессов исполнения входят следующие процессы:

•Руководство и управление исполнением проекта

•Обеспечение качества

•Набор команды проекта

•Развитие команды проекта

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

•Управление коммуникациями

•Осуществление закупок

•Управление вовлеченностью заинтересованных сторон

Группа процессов мониторинга и управления проектом (Monitoring & Controlling)

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

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

Мониторинг – является неотъемлемой частью и прозрачно участвует на всех этапах управления проектом. Основная задача данной фазы по проекту – проведение мониторинга состояния по выбранным метрикам на соответствие требованиям заказчика и заинтересованных сторон. Выявленные недостатки продукта устраняются на фазе выполнения проекта.

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

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

Подготовка

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

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

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

•Подготовить повестку дня и довести ее до сведения участников до начала совещания.

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

Проведение:

•Начать вовремя.

•Поручить кому-нибудь вести протокол заседания.

•Рассмотреть повестку дня с каждым из участников до окончания совещания

•Представить участников друг другу.

•Придерживаться повестки дня. Не отклоняться от темы.

•Поблагодарить всех выступавших на совещании.

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

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

•Объем работ, качество – все ли разрабатывается в соответствии с планом работ, не упущено ли что-нибудь.

•Сроки – соблюдаются ли сроки проекта, вез, задач

•Деньги – соблюдается ли запланированный бюджет, отток, приток капитала

Алгоритм работы проектного контроля:

•Установить плановые показатели

•Получить статус проекта, текущие показатели

•Сравнить план с фактом

•Установить отклонение, тенденции и степень влияния на цели проекта

•Изменить план и/или назначить меры для устранения помех ведущих к отставанию по плану.

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

•Отслеживание состояния проекта

•Обнаружение отклонений от плана

•Принятие корректирующих мер

Различают два вида контроля:

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

•Стратегический контроль – анализирует будущие шансы компании, пути развития, возможные риски. Все это инструменты, позволяющие идти в будущее. Планирование включает долгосрочное развитие, до 10 лет.

Для любого проекта характерны отклонения от плана. При этом отклонения могут быть двух типов:

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

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

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

В группу процессов мониторинга и управления входят следующие процессы:

•Мониторинг и управление работами проекта

•Управление изменениями и контроль изменений

•Подтверждение содержания

•Контроль и управление содержанием

•Контроль и управление расписанием

•Контроль и управление стоимостью

•Процесс контроля качества

•Мониторинг и контроль коммуникаций

•Мониторинг и контроль рисков

•Контроль закупок\контрактов

•Контроль вовлеченности заинтересованных сторон

Группа завершающих процессов управления проектом (Closing)

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

•официальное завершение работ по контрактам с поставщиками, производителями и заказчиками.

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

•приемка работы по проекту и конечных продуктов заказчиком;

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

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

•выпуск и визирование окончательного отчета или отчета о состоянии проекта, которое показывает, что ожидаемые конечные результаты получены;

•прекращение всех работ по проекту как внутри организации, так и за ее пределами.

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

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

посредством включения – означает, что проект увенчался успехом, а его конечные продукты внедрены

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

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

•приемка конечного продукта заказчиком,

•документирование проекта,

•проведение проверки после реализации проекта

•выпуск окончательного отчета

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

•Согласуется ли все еще проект с поставленными целями?

•Является ли он практичным? Полезным?

•Достаточно ли руководство заинтересованно в проекте, чтобы поддержать его реализацию?

•Имеет ли организация достаточно финансовых средств для реализации проекта?

•Является ли поддержка данного проекта достаточной для его успешной реализации?

•Имеет ли организация требуемую квалификацию для реализации проекта?

•Лишился ли проект ключевой фигуры или поддержки?

•Заинтересована ли рабочая группа в успехе проекта?

•Какова вероятность достижения минимума поставленных целей проекта?

•Является ли он все еще прибыльным и своевременным?

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

Группа завершающих процессов содержит следующие процессы:

•Закрытие проекта или фазы (Close Project or Phase)

•Закрытие контрактов (Close Procurement)

Завершение может состоять из:

•Тестов разработанной системы (протокол тестирования)

•Процедура сдачи-приемки, передача рабочей документации

•Аттестация персонала, извлечение уроков (Lesson Learning), обмен опытом

•Финансовый расчет и анализ фактических расходов

•Ликвидация рабочих мест и ре-интеграция персонала

Область знаний по управлению проектами (PMBooK)

Руководство PMBooK (Project Management Body of Knowledge) описывает десять областей знаний, которыми должен обладать руководитель проекта. В стандарте рассматривается каждая область знаний в отдельности, описываются её процессы входов и выходов. Процессы областей знаний представлены в PMBooK в виде дискретных элементов, которые имеют четко определенные границы. Правда на практике эти процессы являются итеративными – могут взаимодействовать между собой и накладываться друг на друга. Стандарт рассматривает следующие области знаний по управлению проектами:

Управление интеграцией проекта (Project Integration Management)

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

Управление содержанием проекта (Project Scope Management)

Под управлением содержанием понимаются процессы, позволяющие производить выборку, фильтрацию и группировку по проекту тех и только тех работ, которые понадобятся руководителю проекта для успешного завершения проекта. Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ – ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием. При разработках WBS используется правило «8/80» (1 день – 2 рабочие недели). Пакет Работ (Work Breakdown Package WB) должен быть разработан за период от 8 до 80 часов. Каждый Пакет Работ должен быть назначен на конкретное подразделение или сотрудника.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

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

В качестве механизмов и техник оценки расчета стоимости проекта можно использовать: Экспертное мнение, Аналогичный проект, Параметрический, Ballpark Estimate (Rough Order of Magnitude ROM), Top-down, Three-point Estimate или Button-up метод.

Наиболее точный метод (Button-up), но при этом он требует наличие Структуру Рабочих Пакетов (Work Breakdown Structure WBS).

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

Управление качеством проекта (Project Quality Management)

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

Управление коммуникациями проекта (Project Communications Management)

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

•Определение заинтересованных сторон проекта,

•Планирование коммуникаций,

•Распространение информации,

•Управление ожиданиями заинтересованных сторон

•Отчеты об исполнении.

Движение информации распространяется по следующим каналам:

•Руководитель проекта – проектная комиссия, руководитель предприятия. Отчеты по проекту, расходы, анализ тренда вех и расходов, причины отклонений.

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

•Пользователи, потребители продукта – руководитель проекта. Информация о развитии проекта.

•Руководитель проекта – план проекта. Планы постоянно отслеживаются, т. к. это основа проектного контроллинга.

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

Управление рисками проекта (Project Risk Management)

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

•Планирование управления рисками,

•Идентификация рисков,

•Качественный анализ рисков,

•Количественный анализ рисков,

•Планирование реагирования на известные риски,

•Мониторинг и управление рисками.

Управление поставками проекта (Project Procurement Management)

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

•Планирование закупок,

•Осуществление закупок,

•Управление закупочной деятельностью,

•Закрытие закупок.

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Методы и техники Управления Проектами

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

Анализ дерева решений (Decision Tree Analysis)

Анализ дерева решений (Decision Tree Analysis).

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

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

•Квадраты – места принятия решений.

•Круги – места появления исходов.

•Пунктирные линии – возможные решения.

•Треугольники или прямые линии – возможные исходы.

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

Анализ сильных и слабых сторон, возможностей и угроз (SWOT Analysis)

SWOT-анализ (Strengths Weakness Opportunities Threats Analysis) – это метод оценки внутренних и внешних факторов, которые влияют на развитие компании. Он поможет вам оценить сильные и слабые стороны вашего дела, найти новые возможности и определить возможные угрозы. SWOT-анализ разделяет факторы влияния на компанию на четыре категории, что помогает оценить её со всех сторон, это:

S-strengths (сильные стороны). Например, продажа товаров непосредственно покупателю, прибыль больше, чем у конкурентов, клиент-сервис – лучший на рынке и т. д.;

W-weaknesses (слабые стороны). Например, недостаточно партнёров, неэффективная реклама, маленькая целевая аудитория;

O-opportunities (возможности). Например, потенциальные клиенты узнают всё, что им нужно о вашем товаре из Интернета, покупки совершаются круглосуточно, не зависимо от того, работаете вы или нет;

T-threats (угрозы). Например, бренд ваших конкурентов более известный на рынке, качество товаров, которые предлагают конкуренты выше.

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

Внутренние факторы – сильные и слабые стороны относятся к внутренним факторам, а значит, вы их легко можете оценить:

•Финансовые ресурсы. Это финансирование, возможности получения дохода;

•Физические ресурсы. Это ваше оборудование, здания, местоположение;

•Человеческие ресурсы. Сотрудники, иногда волонтёры, целевая аудитория;

•Доступ к природным ресурсам, авторские права, патенты;

•Текущие процессы. Сюда относится всё, что происходит в компании, мотивационные программы, программы обучения, система иерархии отделов и т. д.

Чтобы найти сильные стороны своего бизнеса ответьте на такие вопросы:

•Какие преимущества у вашего бизнеса?

•Что вы делаете лучше, чем все остальные?

•Какие ваши сильные стороны видят ваши клиенты?

•Какое у вас уникальное торговое предложение (УТП)?

•Как вы можете увеличить свою прибыль?

Рассмотрите свои сильные стороны, как с внутренней точки зрения, так и с точки зрения ваших клиентов. Оценивайте свои сильные стороны относительно к конкурентам.

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

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

•Экономические тенденции. Это местные, национальные, международные финансовые направления;

•Финансирование. Такие, как пожертвования, государственные влияния, налоги и т. д.;

•Демографические данные. Это возраст, пол, раса, национальность, культурные ценности целевой аудитории;

•Отношения с поставщиками и партнёрами;

•Политическая, экологическая, экономическая ситуация в стране.

Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT)

Метод PERT (Program Evaluation Review Technique PERT), Техника Оценки и Анализа Программ и проектов часто используется при управлении проектами и проведении анализа производственных процессов. Метод PERT является инструментом, который вычисляет ожидаемое значение продолжительности проекта или отдельного процесса. При управлении проектами метод PERT практически всегда используется в сочетании с методом критического пути (англ. CPM, Critical Path Method).

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

O – оптимистичная оценка длительности задачи,

M – наиболее вероятная оценка длительности задачи,

P – пессимистичная оценка длительности задачи.

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

Диаграмма «PERT Chart»

Диаграмма Гантта (Gantt Chart)

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

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

Начало, конец и длина отрезка на шкале времени соответствуют началу, концу и длительности задачи.

Анализ освоенного объема (EVA)

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

Задачу (ЗП1) должен выполнить один исполнитель (ИС1). Выделено по плану – два дня (2 х 8 часов = 16 часов) времени, стоимость работ исполнителя $ 10.00 в час (плановый расход = $ 10.00 х 16 часов = $ 160.00).

По факту: исполнитель закончил работу на третий день, дополнительно истратив два часа, сверх запланированных. Показатели: Факт по времени (2 х 8 часов +2 часа = 18 часов), и фактические расходы = $ 10.00 х 18 часов = $ 180.00.

Результат:

На утро третьего дня: результат выполнения задачи ЗП1 = 16/ (16+2) * 100% = 89% и стоимость выполнения ЗП1 = $ 180.00

Вывод: Здравый смысл говорит нам о том, что мы тратим деньги быстрее, чем получаем результат.

Основные показатели метода:

Плановый объем (Planned Value PV) – объем запланированных работ в базовых ценах. Или другое название – БСЗР (базовая стоимость запланированных работ). В нашем примере PV равен 160$, т. к. базовый объем работ, который должен быть выполнен к среде, равен 16 чел-часам, а базовая цена равна 10$ за час работы.

Освоенный Объем (Earned Value EV) – выполненная часть работ от запланированного объема. Измеряется как % завершения работы, умноженный на базовый бюджет задачи. Ранее этот показатель назывался БСВР (базовая стоимость выполненных работ). В нашем примере EV равен 142$, т. к. % выполнения по задаче равен 89%, а ее базовый бюджет составляет 160$.

Фактическая стоимость (Actual Cost AC) – реальная стоимость выполненных работ. Измеряется количеством денег, которые мы по факту уже должны за выполненную работу. В нашем примере AC равен 160$, т. к. фактически исполнитель затратил 16 часов, а каждый час стоит 10$.

Бюджет по завершению БПЗ (Budget At Completion BAC) фиксируется на старте проекта как сумма утвержденного бюджета на весь проект. В нашем кейсе он равен 160$.

Отклонение по стоимости (Cost Variance CV) – отклонение по стоимости (формула: CV=EV-AC). $ 142.00 – $ 160.00 = – $ 18.00. Отрицательное значение – превысили бюджет, положительное – экономим бюджет. В нашем случае – Мы перерасходовали бюджет.

Отклонение от календарного плана ОКП (Schedule Variance SV) – отклонение по срокам (формула: SV=EV-PV). $ 142.00 – $ 160.00 = – $ 18.00. Отрицательное значение – отстаем от плановых сроков, положительное – опережаем сроки. Мы отстаем от графика.

Индекс отклонения по стоимости ИОС (Cost Performance Index CPI) – индекс выполнения стоимости (формула: CPI=EV/AC). Индекс больше 1 – идем с экономией бюджета, меньше 1 – превышаем бюджет. В нашем случае $ 142.00/$ 160.00 = 0,89. Перерасход бюджета по задаче на 11%

Индекс отклонения от календарного плана ИОКП (Schedule Performance Index SPI) – индекс выполнения сроков

(формула: SPI=EV/PV). Индекс больше 1 – опережаем график работ, меньше 1 – отстаем от базового графика.

В нашем случае: SPI = $ 142.00/$ 160.00 = 0,89. Отстаем по срокам задачи на 11%

Предварительная оценка по завершению ПОПЗ (Estimate At Completion EAC) – Представляет ожидаемую общую стоимость проекта после завершения оставшихся работ (Формула: EAC=BAC/CPI). В нашем случае: $ 160.00/0,89= $ 180.00. На сегодняшний день оценочная стоимость задачи проекта = $ 180.00.

Оценка до завершения ОДЗ (Estimate To Complete ETC) – Сколько еще нужно денег, чтобы завершить проект (Формула: ETC=EAC-AC). В нашем случае: ETC=EAC-AC=$ 180.00 – $ 160.00= $ 20.00 – еще нужно на сегодняшний день, чтобы завершить задачу.

Отклонение бюджета по завершению ОБЗ (Variance At Completion VAC) – Ожидания по перерасходу или экономии бюджета (формула: VAC = BAC-EAC). В нашем случае: VAC = BAC-EAC= $ 160.00 – $ 180.00 = – $ 20.00. На 20$ мы перерасходуем бюджет.

Формулы для расчета состояния проекта: EAC = AC + Button-up ETC, EAC = AC + BAC – EV, EAC = BAC/Cumulative CPI, EAC = AC + [(BAC – EV) / Cumulative CPI x Cumulative SPI], EMV = probability x impact, EV = BAC / % of completion, TCPI = (BAC – EV) / (BAC – AC),

Анализ тренда расходов

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

Постоянно контролируемые значения:

•Плановые расходы – то, что было запланировано изначально на реализацию.

•Фактические расходы – то, что было затрачено по факту на сделанную работу.

•Стоимость сделанных работ – то, что было запланировано и в действительности потрачено на сделанную работу. Сюда входит стоимость работ, материалов, внешних услуг.

•Остаток производства – то, что осталось сделать. Вычисляется как разница между запланированным объемом работы и сделанные к определенной точке во времени. Остаток производства = плановые расходы – стоимость сделанных работ.

•Дополнительные расходы – это разница между фактическими расходами и плановыми.

•Дополнительные расходы = фактические расходы – плановые расходы.

V-факт – предварительные фактические расходы. Выступает, как сигнал пере-расходования средств.

V-факт = бюджет + дополнительные расходы + остаток производства.

Анализ тренда этапов проекта (вех проекта)

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

•Что сделано?

•Что нужно еще сделать для завершения вехи?

•Успели ли в срок?

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

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

По вертикале: такая же шкала, с отметками вех. Отметка вех при X=0, соответствует запланированным показателям вех на этапе старта проекта.

Биссектриса – обозначает положение достигнутых вех.

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

Идеальное состояние, когда линия четко идет без изменений по оси Y.

Отклонения по вертикале (отклонение прогнозируемого срока от первоначально запланированного):

Вверх: отставание по срокам

Вниз: опережение графика

Анализ с помощью Треугольника целей

Анализ с помощью Треугольника целей – Углы треугольника обозначаются, как:

•Сроки. Время на реализацию проекта.

•Расходы. Деньги, люди, бюджет.

•Объем работ. Цели, задачи, качество.

Пример хорошего развития проекта – Объем работ соблюден и даже превышен при меньших расходах и сроках.

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

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

Сроки – измеряется затраченным временем на проект.

Расходы – измеряются фактическими затратами.

Объем работ – измеряется в процентном соотношении запланированных и выполненных работ.

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

Прочие Методы и Техники

Анализ допущений (Assumptions Analysis)

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

Анализ ожидаемого денежного значения (Expected Monetary Value Analysis EMV)

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

Анализ отклонений (Variance Analysis)

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

Анализ сети (Schedule Network Analysis или Network Analysis)

Анализ сети расписания (Schedule Network Analysis) – Метод определения ранних и поздних стартов и ранних и поздних финишей для невыполненных плановых операций проекта. См. также метод критического пути, метод критической цепи, анализ возможных сценариев и выравнивание ресурсов.

Анализ тенденций (Trend Analysis)

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

Анализ резервов (Reserve Analysis)

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

Анализ чувствительности (Sensitivity Analysis)

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

Быстрый проход (Fast Tracking)

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

Выравнивание ресурсов (Resources Leveling)

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

Декомпозиция (Decomposition)

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

Метод «операции в узлах» или метод предшествования (Precedence Diagramming Method, PDM)

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

Метод сетевых графиков

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

Метод критического пути (Critical Path Method, CPM)

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

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

•цели и ограничения (рассмотрение проекта по нескольким аспектам – длительность, рас, качество и проч.);

•продолжительность работы;

•сетевой график работ;

•построение диаграммы Гантта

Метод критической цепи. Метод критической цепи (Critical Chain Method CCM)

отличается от метода критического пути тем, что он ориентирован на использование ресурсов проекта, а не проектных работ. Для решения потенциальных проблем с ресурсами формируются буферы, гарантирующие своевременную реализацию проектов с соблюдением всех необходимых мер безопасности. Управление проектом по методу критической цепи помогает избегать отставаний и задержек в проекте, определяя критический путь работ, а также резервы ресурсов (запас времени) для этих работ. Поскольку графики строятся, учитывая доступность ресурсов, срок проекта может быть дольше, но вероятность срыва сроков ключевых событий может быть снижена. Основа методологии критических цепочек – формирование основных работ критически важных для проекта и удержание сроков работ, соответственно и финальной даты завершения проекта. Критические работы проекта провязываются логическими связями с учетом ресурсных и административных ограничений; Если в проекте ресурсы не ограничены, расчётные показатели будут схожими с PERT. Если в проекте все же ограничены ресурсы, то необходимо:

•Определить околокритические работы в графике, такие работы очень часто идут параллельно основной «красной»

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

•Определить критическую цепочку проекта при помощи ресурсных связей

Метод Монте-Карло (Monte Carlo Analysis)

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

Метод оптимизации выгод (Value Engineering, VE)

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

Метод освоенного объема (Earned Value Technique, EVT)

Особый метод для измерения исполнения работ для элемента иерархической структуры работ, контрольного счета или проекта. Другое название – «метод правил освоения и начисления дохода» (earning rules and crediting method).

Оценка «снизу-вверх» (Bottom-up Estimating)

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

Оценка «С вверху вниз» (Top-down Estimating)

Метод оценки элемента работ. Обратный методу «снизу-вверх».

Планирование методом набегающей волны (Rolling Wave Planning)

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

Управление освоенным объемом (Earned Value Management, EVM)

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

Иерархическая структура рисков (Risk Breakdown Structure, RBS)

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

Матрица вероятности и последствий (Probability and Impact Matrix)

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

Матрица ответственности (Responsibility Assignment Matrix, RAM)

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

Расписание контрольных событий (Milestone Schedule)

Укрупненное расписание работ, отображающее сроки наступления основных контрольных событий.

Метод аналогий

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

Метод Экспертной Оценки (Expert Judgment)

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

Метод показателей

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

Фаза анализа – 20%

Фаза проекта – 35%

Фаза реализации – 30%

Фаза тестирования – 15%

Оценка «Навскидку» Poker Estimate

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

•Собирается рабочая группа (разработчики, аналитики, представители бизнеса и т п).

•Озвучивается задача,

•Каждый участник оценивает сроки проекта основываясь на своем опыте и уровню,

•Каждый участник высказывает свое мнение.

•Для обсуждения рабочей группой выбираются самый короткий и самый длинный срок проекта.

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

Оценка времени или часов разработки

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

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

Для устранения данных проблем можно воспользоваться следующими методами и техниками:

•Poker Estimate,

•Сравнение с аналогом,

•Bottom up & Top down

•Экспертная оценка.

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

•15—20% процентов времени для покрытия рисков и непредвиденных случаев

•Принимаем в расчетах 80% процентов рабочего времени (а не 100% формальных) разработчика, как основной рабочей единицы занятой на проекте

Диаграмма: Стоимость проекта

Ведение документации по проекту

Документация проекта – это набор документов, описывающих проект и регламентирующих деятельность в рамках проекта.

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

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

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

•Внутренняя

•Внешняя.

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

•Планы

•Статусы

•Протоколы совещаний

•Документация по дефектам, тестам

•Договоры с поставщиками

Анализ рисков

Пример информации, которую можно отдать во вне:

•Матрица компетенций

•Журнал распределения обязанностей

•Статусы проекта

•График вех

•Заключительные отчеты

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

Устав проекта

•Описание содержания проекта

•Реестр заинтересованных сторон проекта

План управления проектом

Запрос на изменение в проекте

Лист согласования участия в проекте

Положение об управлении рисками

•План управления рисками

•Реестр рисков

Протокол совещания

Отчеты

•Отчет об исполнении работ по проекту

•Отчет о статусе проекта

•Отчет по завершению проекта

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

•Какие артефакты и документы нужны для вашего проекта?

•Насколько детально нужно их прорабатывать?

•Стоимость времени, потраченное на создание документа по отношению к ценности документа?

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

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

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

•Сначала выбирается минимальный набор документов.

•Заполняете на основании здравого смысла. Если что-то кажется лишним, отбрасывайте.

•Затем оцениваете, сможете ли вы с помощью этой информации достичь нужных результатов.

•Если нет, то включите недостающие разделы или документы.

•Заполните их и снова проведите оценку.

•И так далее до достижения результатов.

Инструменты по Управлению Проектами

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

Какие минимальные требования к инструментам? Что они должны помогать вам делать?

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

•Размещать их на общедоступном ресурсе, регулировать права доступа к информации, обсуждать эти материалы.

Набор инструментов:

•Для составления документов, схем, таблиц и презентаций можно использовать стандартный офисный пакет, например, MS Office. Для него есть готовые шаблоны для документов. Есть расширения для Visio, при помощи которых можно нарисовать все нужные схемы.

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

Профессиональные инструменты по Управлению Проектами такие как:

•Microsoft Project 2016 Server / Professional

•JIRA Project Management

Для развитых организаций или проектных ИТ компаний желательно дополнительно использовать профессиональные системы, если они не входят в составе систем Управления Проектами, такие как:

•Система санкционирования выполнения работ (Work Authorization System).

•Система управления изменениями (Change Control System).

•Система управления конфигурацией (Configuration Management System).

Ключевые факторы успеха проекта

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

Можно выделить следующие ключевые факторы успеха проекта:

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

Быстрые результаты. Проект должен обеспечивать достижение краткосрочных целей. Важно поддерживать интерес спонсора к проекту. Для этого нужно быстро достигать необходимых для компании результатов, которые он сможет записать себе в актив. Если ближайшие результаты будут через 3 года, то интерес к проекту сильно упадет.

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

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

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

Обеспечить максимальное повторное использование ИТ активы организации. Все сломать и переделать – это долго и дорого. А ломать то, что действительно работает, глупо. Зачастую информационные системы и оборудование компании используются на 15—30% возможностей. Это отличная возможность для получения быстрых результатов с минимальными затратами.

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

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

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

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

Начинайте с пилотного проекта. На старте ваша основная цель – показать реальные результаты.

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

•Достаточно знаний и умений для того, чтобы сделать шаг

•Шаг кратковременный по времени

•Шаг имеет низкий уровень риска

•Шаг поведенческий-конкретный

•Понятно, что будет успехом шага

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

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

Не изобретайте велосипедов.

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

Громко скажите «спасибо» руководству за поддержку, коллегам за помощь и терпение и т. д.

Основные причины провала проекта

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

•Проект представляет собой решение, приводящее к проблеме

•В конечном результате заинтересована только группа, работающая над проектом

•Никто ни за что не отвечает

•План проекта недостаточно структурирован

•План проекта недостаточно детализирован

•На реализацию проекта выделено недостаточно средств

•Выделенных ресурсов недостаточно для выполнения работ

•Проект не сверяется с планом его реализации

•Отсутствует взаимодействие между членами рабочей группы проекта

•Проект отклоняется от поставленной цели

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

Заключение

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

•Классические методы как «трактор» (если удачное завершение проекта, то как немецкий трактор) – «… сказали пахать – пашем с раннего утра и пока не вспашем…». Ориентирован на результат – выполнить любой ценной (как правило это конечный продукт, а стоимостью и временем как получится). Все делается по порядку и по инструкции.

•Методология «PRINCE2» – тоже самое, но задаются вопросом «… а на кой нам это нужно если дохода нет?…»

•«Вот „бабули“, больше нет – крутись как хочешь, но к завтрашнему утру чтобы было все готово. Что конкретно готово не знаем – но клиент сказал – ВСЕ». Это больше подходит на пример использования гибких методов управления проектами.

•«Пашем как молотилка» – метод «SCRUM»

•«KANBAN» присмотрит за тем, чтобы работники не были перегружены, а то «… сдохнут кони раньше времени…»

•Методологии «LEAN» и «SIX SIGMA» присмотрят за вопросом «… а не много ли косячат?…»

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