Основные этапы реализации проекта

Вопросы для обсуждения
1. Методы управления проектами на этапе их реализации (классическое проектное управление, Agile, Scrum, Lean, Kanban).
2. Оценка хода реализации проекта.
2.1 Мониторинг и контроль.
2.2 Действия на этапе реализации.
2.3 Информирование заинтересованных лиц
2.4 Отчетность в проекте
2.5 Изменения в проекте
3. Сдача-приёмка продукта проекта.
3.1 Закрытие проекта
3.2 Задачи на этапе завершения проекта
3.2 Задачи на этапе завершения проекта
3.4 Итоговое представление результатов проекта

Вопрос 1.
Методы управления проектами
на этапе их реализации
(классическое проектное управление, AGILE, SCRUM, LEAN, KANBAN).
«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было, наверное,
самой сложной задачей»
Роджер Лаунис, историк НАСА

Управление проектами – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту.
3 основные группы методов управления проектами
на этапе их реализации
Методы на основе стандартов
регламентируют основные процессы и процедуры управления проектом, предлагают варианты оргструктур и документационного обеспечения для ведения проекта
2. Гибкие методы
ориентированы на получение ценного для заказчика результата за счет фокусирования на получении этого результата и постоянной работе с образом продукта.
3. Комбинированные и «интуитивные» методы
формируются из команд, которые пришли к самоорганизации самостоятельно либо скомбинировали подходящие для них подходы, взятые из известных им методов

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

2. Agile
Agile (с англ. проворный) – семейство гибких итеративных методов к управлению проектами.
- проект разбивается не на последовательные фазы, а на небольшие подпроекты, которые постепенно превращаются в финальный продукт проекта.
- этапы инициации и планирования проводятся для всего проекта в целом, а последующие этапы проводятся для каждого подпроекта отдельно.
- Agile – это культура сотрудничества, адаптивности, принятия неопределенности, набор ценностей и принципов того, как нужно реализовывать проекты. На основе этих принципов были разработаны гибкие методы: Scrum,Kanban, Crystal и т.д. Эти методы следуют одним и тем же принципам, хотя имеют значительные отличия.
Сильные стороны Agile: гибкость и адаптивность. Подход позволяет осуществить быстрый запуск проекта, быстро реагировать на изменения, поддерживать связь между командой проекта и заинтересованными сторонами.
Сфера Agile – разработка инновационных продуктов.
Слабые стороны Agile: Agile—это просто набор ценностей и принципов. Основной минус подхода состоит в том, что требуются высококвалифицированные и мотивированные сотрудники, которым придется самостоятельно выстраивать свою систему управления, руководствуясь данными принципами. Также требуется значительно количество времени от Заказчика.
Существуют готовые методы, которые облегчают использование Agile подхода. К таким методам относятся Scrum, Kanban, Crystal, SAFe, Nexus и т.д.

3. Scrum
Scrum (англ. хватка) – метод, признанный в семействе Agile
наиболее структурированным.
Scrum используется для проектов, в которых необходимы «быстрые победы»
в сочетании с толерантностью к изменениям.
При таком подходе продукт проекта разбивается на части, подходящие для немедленного применения Заказчиком.
Части оформляются в виде «беклога»
(задел продуктов, ProductBackLog).
Чаще всего такой метод применяется для разработки программного обеспечения.

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

Пять встреч для реализации проекта
1. Упорядочивание (планирование) BackLog. Проводится перед началом нового спринта. Обсуждается то, что уже удалось сделать по проекту и что ещё нужно сделать. Инициатор ставит задачи, соответствующие новому этапу.
2. Планирование спринта. После расстановки приоритетов и определения задач инициатором команда принимает решение о своих действиях на протяжении наступающей итерации и ищет способы достижения цели. Планировать спринт нужно в самом начале итерации, но по окончании упорядочивания Беклога.
3. Летучки – ежедневные встречи для обмена сведениями (до 15 минут). Члены команды делятся информацией о статусе своей работы и состоянии проекта, однако никакие решения не принимаются и проблемы не обсуждаются.
4. Подведение итогов спринта. На этом этапе исследуется и адаптируется созданный продукт. Члены команды делятся своими результатами со всеми заинтересованными лицами. Важно удостовериться, что продукт спринта соответствует целям проекта.
5. Ретроспектива спринта. Этап проводится сразу же после предыдущего, но до планирования нового спринта. Оценивается слаженность пройденного этапа, исследует новые проблемы в работе. Команда может сделать выводы и повысить эффективность следующего спринта.

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

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

4. Lean
Метод Lean дополняет принципы Agile за счёт внедрения схемы потока операций (workflow – англ. work – работа; flow – поток) для выполнения отдельной итерации.
В Lean работу разбивают на некоторые части (пакеты), которые реализуются независимо друг от друга.
В отличие от Scrum каждый пакет различается своим потоком операций с этапами (планирование, тестирование, разработка и т.д.) – главное, чтобы эти этапы были важны для качественного осуществления проекта.
Метод Lean допускает параллельное выполнение нескольких задач на разных этапах. Это повышает гибкость и сокращает скорость выполнения проекта.

Сильные стороны Lean:
∙ подходит для проектов, требующих чёткого исполнения и ровного качества;
∙ сочетает в себе структурированность и гибкость.
Слабые стороны Lean:
∙ предполагает детальную проработку всех задач и этапов проекта (в реальности во многих проектах далеко не все части проекта требуют к себе такого внимания).

5.Kanban
Метод Канбан – набор принципов, ориентированный на выполнение задач проекта.
Роль руководителя проекта – определить приоритетные задачи, команды – выполнить как можно больше задач.
Основы системы Канбан
карточки создаются для каждой отдельной задачи;
фиксированное количество задач для каждого этапа;
непрерывное улучшение: постоянный анализ рабочего процесса и поиск путей повышения его эффективности.
Отличия Канбан от Scrum
∙ при подходе Канбан оценка сроков выполнения задачи может не делаться;
∙ при Канбан задачи крупнее, но их количество меньше;
∙ Канбан позволяет приостановить выполнение одной задачи, если появились иные более срочные или изменился приоритет текущей. Незавершенные задачи, подвешенные даты – норма для этого метода;
∙ отсутствуют роли членов команды и участников (кроме инициатора проекта). Один член команды в одно и то же время может выполнять несколько задач.

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

Вопрос 2. Оценка хода
реализации проекта
2.1 Мониторинг и контроль - это процесс отслеживания, проверки и ведения отчетности о ходе исполнения для достижения целей исполнения, определенных в плане управления проектом
Возникающие задачи в рамках процесса мониторинга и контроля можно рассматривать условно с двух сторон:
со стороны команды проекта и со стороны выполняемых ими работ.
1.Команда проекта. Для успешной реализации проекта важно, чтобы вся команда была в курсе текущей ситуации в проекте, чтобы любой член команды мог свободно сообщать о возникающих трудностях и предлагать собственные решения, а не только критиковать и перекладывать ответственность за проект. После того, как будет выбран режим коммуникаций, распределена ответственность, стоит выстроить систему информирования о текущем состоянии, в том числе систему отчетности и контроля.
2.Работы проекта. Работы проекта могут быть выполнены по-разному, с разным качеством, и не всегда члены команды готовы приложить достаточно усердия и стараний без напоминания. Но если итог не будет удовлетворять поставленным требованиям, то проект с большой вероятностью будет провален. Кроме того, в процессе выполнения могут возникать новые задачи, которые не были учтены на этапе планирования; выполняемые задачи могут оказаться на порядок сложнее, чем представлялось в начале проекта; могут поменяться внешние условия и т.п.

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

2.3 Информирование заинтересованных лиц
«Всё, что может быть понято неправильно, будет понято неправильно»
Фрэнсис Чизхолм
Кто именно должен понимать статус проекта,
кого стоит информировать о ходе проекта?
1. Руководитель проекта. Именно он отвечает за весь проект, ему принимать важные решения, касающиеся проекта. Соответственно, руководитель проекта должен обладать полной информацией о ходе проекта.
2. Команда проекта. Для успешной реализации проекта важно, чтобы любой член команды понимал, что происходит в проекте, какие ему необходимо выполнять задачи, и как эти задачи могут повлиять на проект. Основываясь на этой информации, команда проекта сможет сообщать о возникающих трудностях и изменениях, предлагать решения.
3. Заказчик и другие заинтересованные лица. Информирование с заданной периодичностью заинтересованных лиц помогает удерживать их вовлеченность в проект и управлять их ожиданиями, а значит, позволяет повысить вероятность поддержки проекта и минимизировать их сопротивление. Кстати, по мере развития проекта состав заинтересованных сторон и уровень их вовлечения могут меняться, и это стоит учитывать.

2.4 Отчётность в проекте
В простом отчете может содержаться следующая
информация об исполнении:
∙выполнена задача или нет (% выполнения задачи);
∙сколько осталось дней до завершения текущей задачи;
∙возможные смещения по срокам или бюджету будущих задач.
В расширенных отчетах может дополнительно содержаться
следующая информация:
∙выполненные задачи за определенный период и их показатели (срок, бюджет, ресурсы);
∙прогнозные значения показателей будущих задач или проекта в целом;
∙анализ выполненных работ;
∙сводная информация о рисках проекта;
∙сводная информация об изменениях в проекте;
∙другая значимая информация, которая рассматривается и обсуждается.
Оценка выполнения работ проекта может производиться с разной периодичностью в зависимости от требуемой точности:
∙контроль в моменты окончания работ (0%–работа не выполнена, 50%–работа в процессе выполнения, 100% –работа выполнена);
∙контроль в заранее определенных ключевых точках проекта (контроль по вехам);
∙регулярный оперативный контроль с заданной периодичностью (например, ежедневно, еженедельно).

Существует два основных подхода к подготовке отчета членами команды проекта (выбор подхода зависит от принятых в организации стандартов, типа проекта, важности подсчета потраченных трудозатрат, в том числе количества свободного времени для обновления данных в плане работ, и т.д.)
А) Идея подхода обновления информации по ресурсам заключается в том, что команда проекта отражает как фактические трудозатраты на назначенные задачи, так и предстоящие в своих периодических отчетах. Такой подход обеспечивает более точную картину о состоянии проекта, но требует достаточно больших затрат времени руководителя проекта и команды проекта. Обычно такой подход используется, когда выплаты сотрудникам зависят от потраченных часов, скорости работы. Тогда процент завершения по трудозатратам обозначает долю фактически отработанных часов по отношению к запланированным часам.
Б) Смысл подхода обновления информации по задачам состоит в том, что собираются данные о фактической и оставшейся длительности, о датах начала и окончания задачи. Такой подход менее трудоемок, но и является менее точным.
При таком подходе процент завершения показывает долю фактической длительности выполненной части работы по отношению к запланированной длительности работы. По сути, это значение показывает –насколько выполнена работа с точки зрения запланированной длительности.
∙текстовые редакторы (MS Word, Pages, GoogleDocs);
∙табличные редакторы(MSExcel, Numbers, GoogleSheets);
∙информационные системы управления проектами (MS Project, OpenProj, OraclePrimavera, др.).

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

ШАГИ ПО УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ
1.Запрос на изменение отправляется руководителю проекта. Важно: запрос предоставляется в письменном виде (в свободном изложении или в форме, которая определена в организации).
2.Команда проекта рассматривает запросы и оценивает их (потенциальные последствия для проекта, стоимость их реализации и т.д.). В зависимости от категории запроса решение о включении в проект принимается сразу или отправляется на согласование с другими заинтересованными лицами.
3.После утверждения запроса на изменение вносятся необходимые корректировки в документы, которые затронуло данное изменение. Дальше они становятся частью проекта, и работа идет свои чередом.

КАКИЕ ШАГИ МОЖЕТ ДЕЛАТЬ РУКОВОДИТЕЛЬ ПРОЕКТА ПРИ ВНЕСЕНИИ ИЗМЕНЕНИЙ?
1.Манипулирование ресурсами:
∙Замена ранее планировавшихся исполнителей на других, обладающих нужной компетенцией и имеющихся в наличии.
∙Наращивание ресурсов (привлечения ресурсов со стороны, расширение собственных ресурсов предприятия).
∙Выполнение задач сверхурочно, материальное стимулирование.
2.Работа со временем:
∙Смещения задач за счет временного резерва следующих задач.
∙Выполнение задач параллельно.
∙Продление срока завершения проекта.
3.Изменение качества продукта (работа
с содержанием):
∙Снижение качества продукта проекта (исключение каких-либо требований к продукту, замена технологии, материалов и т.п.).
∙Замена продукта проекта на аналогичный и другие меры.

Вопрос 3. СДАЧА-ПРИЁМКА ПРОДУКТА ПРОЕКТА

3.1 Закрытие проекта
Под закрытием проекта понимается процесс официального завершения всех процедур проекта
ОРГАНИЗАЦИОННЫЕ ЗАДАЧИ
действия, необходимые для формального завершения проекта
ПСИХОЛОГИЧЕСКИЕ ЗАДАЧИ
работа с командой проекта, которая близка к роспуску и смене деятельности
ОДНА ИЗ КЛЮЧЕВЫХ ПРОБЛЕМ, С КОТОРЫМИ СТАЛКИВАЕТСЯ РУКОВОДИТЬ ПРОЕКТА, ПО МЕРЕ ПРИБЛИЖЕНИЯ К ЗАВЕРШЕНИЮ ПРОЕКТА
Поддержание высокой производительности работы команды проекта

3.2 Задачи на этапе завершения проекта
Основные задачи на этапе завершения проекта:
1.Сдача-приёмка работ, как итог –получение подтверждения заказчика для формального закрытия проекта.
Для успешного завершения проекта уже на предыдущих этапах необходимо:
В начале проекта
∙ Согласовать и зафиксировать объем работ с заказчиком, которые должны быть сделаны; определить порядок сдачи-приемки работ (каким образом заказчик будет проверять полученный результат: демонстрация, приемочные испытания и т.д.).
∙ Договориться и зафиксировать критерии приемки работ (количественные показатели по работе продукта проекта).
В середине проекта
∙Предоставлять периодические отчеты о проделанной работе, предстоящих задачах, возникающих трудностях.
∙ Проводить промежуточные демонстрации результата, чтобы оценить в том ли направлении движется проект.
На этапе завершения проекта сдача-приемка работ состоит из следующих шагов:
∙ Провести внутри команды проверку выполненных работ и убедиться, что все договоренности выполнены. В зависимости от типа проекта, приемка работ может быть выполнена в виде тестирования, испытания, сверки с техническим заданием. Как итог, команда проекта должна подтвердить внутри себя, что продукт проекта готов согласно всем договоренностям.
∙ Провести финальную демонстрацию результата Заказчику и получить подтверждение о закрытии проекта. На этом шаге передается продукт проекта, Заказчик проверяет его на соответствие заданию. Если будут выявлены недочеты, то в зависимости от первоначальных договоренностей, их нужно будет зафиксировать и доделать в рамках текущего или следующего проекта. Подтверждение о закрытии проекта зачастую оформляется в виде документа «Акт приемки-передачи».
О сдаче проекта необходимо задумываться еще на этапе инициации или планирования. Именно тогда оформляются критерии приемки результатов проекта, на основании которых Заказчик будет судить о полученных результатах.

2. Итоговый анализ проекта
После подтверждения приемки работ внутри команды проводится анализ хода проекта. Это встреча, на которой можно обсудить и осознать, как продвигался проект, что пошло не так и как разрешать такие трудности в дальнейшем, а также обсудить, какие удачные решения были предприняты. Такой анализ позволяет расставить все на свои места, зафиксировать полученный опыт.
Важно, чтобы решения, принятые на встрече,
были задокументированы!
Итоговый отчет может содержать следующую информацию:
∙ описание достигнутых в проекте результатов;
∙ описание незапланированных полезных результатов (если такие были получены);
∙ решения, как можно было бы избежать негативных ситуаций;
∙ успешно принятые решения в неоднозначных ситуациях;
∙ предложения по улучшению процесса управления проектом и др.

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

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