ЭТАПЫ ВНЕДРЕНИЯ ПРОЕКТНЫХ ТЕХНОЛОГИЙ

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объект исследования: проектный менеджмент.

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

Задачами работы выступают:

- теоретическое обоснование и цели управления проектами,

- исследование методологии управления проектами в организации,

- анализ этапов внедрения проектных технологий в организации.

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

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

Рассмотрим надежность использованных источников.

В работе были использованы статьи и монографии из научных журналов, такие как монография Шулюк Н.В. “Принципы успешного управления проектами», статья Керцера Г. «Стратегическое управление в компании. Модель зрелого управления проектами», статья Ньютона Р. «Управление проектами от А до Я», статья Павлова А.Н. “Управление проектами на основе стандарта PMI PMBOR.Изложение методотологии и опыт применения», статья Плотникова А.Н. «Актуальные проблемы управления проектами», статья Ройс У. «Управление проектами по созданию программного обеспечения», статья Ручкина А.В. «Управление проектами: Основные определения и подходы», статья Рыбкиной Е.А. «Управление проектами: область, методология, система» и др.

Были сипользованы пособие, опубликованные издательствами, например пособие Афонина А.М. “Управление проектами», учебник Володина С.В. «Стратегическое управление проектами», учебник Гонтаревой И.В. «Управление проектами», учебник Ларсона Э.У. «Управление проектами», пособие Попова Ю.И. «Управление проектами», учебник Романовой М.В. «Управление проектами», пособие Соснина Э.А. «Управление инновационными проектами» и многие другие источники.

1. СУЩНОСТЬ ПРОЕКТНОГО УПРАВЛЕНИЯ, ЕГО ОСНОВНЫЕ ЦЕЛИ И ПРИНЦИПЫ

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

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

Научно-технический прогресс, возрастающая сложность реализуемых замыслов, рост конкуренции во всех отраслях, усиление интеграции и взаимодействия производства и науки делает проектное управление актуальным в современном мире [8]. Такой вид менеджмента дает возможность:

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

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

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

- эффективно руководить трудовыми, финансовыми, материально-техническими ресурсами [12, с. 88].

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

- освоение и внедрение новых видов продукции на основе передовых технологий, которые дадут предприятию конкурентные преимущества на рынке;

- внедрение в компании современных управленческих технологий, способных повысить эффективность деятельности на всех уровнях руководства (оперативном, тактическом и стратегическом);

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

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

- привлечение инвестиций со стороны за счет внедрения перспективных инициатив;

- концентрация кадровых, научно-технических и производственных ресурсов, рациональная организация работы, как следствие, уменьшение количества времени, затрачиваемого на разработку и производство продукции, и сокращение ее себестоимости [17, с. 33].

В течение длительного времени организации и предприятия применяли традиционные методы управления. Проектный подход стал применяться только с 50-60-х годов XX века, хотя крупномасштабные замыслы люди воплощали в жизнь с давних пор, достаточно вспомнить постройку египетских пирамид, путешествия Колумба и Магеллана, освоение американского Запада [20, с. 59].

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

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

- направленность на достижение конкретной, заранее определенной цели;

- наличие ограничений по времени, ресурсам и финансам;

- взаимосвязанность большого количества процессов разного уровня и скорости протекания [24, с. 71].

Часто проектный менеджмент сравнивают с традиционным, это дает ясное понятие об их различиях [2, с. 62]. Традиционный отличается такими особенностями:

- ориентация на ход событий и организацию процессов;

- отсутствие четко ограниченных сроков выполнения работ;

- все позиции планируются, а под них расписываются ресурсы;

- концентрация на исполняемом рабочем процессе и рабочей норме;

- характерна относительная надежность, часто переходящая в монотонность;

- для выполнения задач привлекается постоянный персонал [26].

Этапы проекта рассмотрены на рисунке 1.1.

Рис. 1.1. Этапы проекта

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

- ориентация на достижение заранее определенной заданной цели;

- главное – не организация труда, а достигнутый результат;

- все действия жестко ограничены финансовыми возможностями и временными рамками;

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

- определяются достижимые цели на каждом этапе, процесс важен только в рамках достижения поставленной цели; 

- результат – финальная приемка всех работ, каждое отдельное задание рассматривается только с точки зрения общего успеха;

- надежность всех действий предсказуема в связи с достижением поставленного результата;

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

- под каждую инициативу подбирается команда со специализациями и умениями в зависимости от направленности проекта [2, с. 124].

Большая часть организаций в России использует принципы традиционного управления, несмотря на то, что имеет трудности с подбором высокопрофессиональных сотрудников для выполнения постоянно повторяющихся заданий [8]. Вместе с тем, развитие фирмы можно подтолкнуть, придумав инновационную бизнес-идею и привлекая руководителей и исполнителей задания со стороны. При этом нужно быть готовым к дополнительным расходам на обучение персонала, повышение их квалификации. Кроме того, часть сотрудников может быть не готова к переходу на новые условия работы [15, с. 209].

Варианты организации проектного менеджмента в компании.

Чтобы внедрить в организации принципы проектного менеджмента стоит подумать о том, как будут решаться межорганизационные, межгрупповые и межличностные конфликты, связанные с организацией горизонтальных и вертикальных систем взаимодействия [16, с. 33]. Когда возникает необходимость осуществить комплексный замысел, который с одной стороны охватывает деятельность уже имеющихся и функционирующих линейных подразделений, а с другой – решить целый ряд новых задач экономического, социального и технического характера, то необходимо искать самую подходящую организационную форму [6, с. 73].

Можно рассмотреть и проанализировать три наиболее часто встречающихся варианта решения проблемы:

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

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

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

Третий вариант наиболее применим в сложных проектах, связанных с большим количеством промежуточных этапов и сложными техническими заданиями (аэрокосмическая, электронная отрасли промышленности, разработки новых технологий) [12, с. 55].

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

1. Принцип дифференцированного подхода. При координации и регулировании обязательно следует учитывать и использовать разнообразные стороны проектной инфраструктуры. К ним относятся ожидания и вклады участников, специализированные стандарты project management и особенности реализации проектов по их типам и т.д.
2. Принцип экономической целесообразности. Данный принцип предполагает опережающий рост отдачи от реализации всего портфеля проектов компании в сравнении с совокупностью бюджетов на их реализацию и расходами на содержание проектного офиса. Все ресурсы, задействованные в реализации, находятся под контролем благодаря описанным в процессах процедурам [18, с. 80]. Действия вне будущей экономической целесообразности в рамках проектной деятельности не допустимы.
3. Принцип гибкости. Предполагается оперативное и гибкое реагирование команды на все вызовы и изменения внутренней и внешней ситуации по отношению к проекту. В отдельных случаях руководство уникальной задачей гибко реагирует и на изменения в компании в целом. При этом гибкость нисколько не исключает достаточное жесткое соблюдение процессуальных процедур проектной деятельности.
4. Принцип конкурентоспособности. В условиях ограниченности трудовых и финансовых ресурсов направления реализации задач подлежат ранжированию и отбору на конкурсной основе во внутрикорпоративной конкурентной среде [19, с. 165]. Выбор проектов производится, исходя из условий важности (соответствия стратегии), проблемности и ресурсообеспеченности.
5. Принцип разделения полномочий. Процессная концепция менеджмента, которая применяется при управлении проектами, требует соблюдения принципа принадлежности каждого процесса единственному владельцу [21]. Владелец процесса отвечает за этапы внутрипроцессных работ и достижение итогового результата.
6. Принцип открытости. Стандарты project management не являются догмой. Допускается, что текущая проектная практика может не соответствовать предписаниям стандартов. В таком случае предполагается и рекомендуется перепроверить основные положения процедур [21]. В этом заключается открытость стандартов управления проектами для их развития.
7. Принцип best practices. Руководство компании обязано поощрять своих менеджеров, команды на применение лучшего отечественного и мирового опыта в сфере управления проектами [23, с. 73]. Основные аспекты лучших практик подлежат заимствованию из всех доступных источников.

Выводы.

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

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

- освоение и внедрение новых видов продукции на основе передовых технологий;

- внедрение в компании современных управленческих технологий;

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

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

- привлечение инвестиций со стороны за счет внедрения перспективных инициатив;

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

Принципы проектного управления:

1. Принцип дифференцированного подхода.
2. Принцип экономической целесообразности
3. Принцип гибкости
4. Принцип конкурентоспособности
5. Принцип разделения полномочий
6. Принцип открытости
7. Принцип best practices

2. МЕТОДОЛОГИИ ПРОЕКТНОГО МЕНЕДЖМЕНТА

Несмотря на уникальность реализуемых замыслов, осуществляемые по ходу дела процессы поддаются систематизации и стандартизации. Формальные документы, разработанные на основе этих стандартов, называются методологией менеджмента. Некоторые из этих методологий носят универсальный характер, и могут быть применены для всех видов реализуемых предприятий, другие эффективны только в определенных сферах [13, с. 75]. Рассмотрим самые популярные методики руководства.

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

• разработка требований;
• проектирование и планирование;
• реализация (производство, строительство);
• завершение и внедрение;
• тестирование, настройка и отладка;
• установка и ввод в эксплуатацию;
• эксплуатация и ее последующее техническое сопровождение [18, с. 56].

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

Если поставленная конечная цель – материальный продукт, производимый путем четкой последовательности действий, то каскадная методика наиболее действенна. Однако ее гибкость невысока, поскольку составление технических условий ожидаемого результата и планирование занимает много времени и требует значительных инвестиций. Это делает ее недостаточно подходящей для задумок с нечетко определенным конечным результатом [30, с. 64].

Рис. 2.1. Надзор за проектом

Методология PRINCE2 представляет собой структурированную систему, применимую как в бизнесе, так и в органах государственной и муниципальной власти [8]. Она ориентируется на процессы верхнего уровня (организация, руководство, контроль), оставляя в стороне события нижнего уровня (составление графиков, расписание всех работ) [23, с. 261].

Основными принципами метода являются:

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

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

• запуск инициативы;
• руководство ею;
• инициация;
• контроль выполнения промежуточных этапов;
• менеджмент создания продукта;
• управление границами и отклонениями; закрытие инициативы [19, с. 387].

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

Agile – это образец итеративной и поступательной методологии. Применяется в проектах, где на начало реализации нет полной ясности относительно жизненного цикла начинания и конечного результата. При этом вся деятельность подразделяется на "спринты" – итеративные фазы, состоящие из большого количества задач со своим конечным результатом и продуктом [22, с. 108]. Суть Agile сводится к тому, чтобы менеджмент имел постоянную обратную связь и мог постоянно (после каждого "спринта") совершенствовать продукт.

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт [21]. Схема работы приведена на рисунке 2.2.

Рис. 2.2. Схема работы по Agile

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

• Владельцем продукта, который определяет цели и готовит график работ при необходимых параметрах. Он корректирует процессы при изменяющихся условиях и устанавливает приоритетные характеристики требуемого продукта.
• Scrum мастером, задающим приоритеты членам команды для решения конкретных задач и решающим все возникающие трудности.
• Членами команды, выполняющими текущие задания, осуществляющими текущий менеджмент, готовящих отчеты и контролирующих качество продукта [27, с. 425].

Метод Agile отличается гибкостью и быстрой изменяемостью, хорошо подходит для IT-сферы (графический дизайн или разработка нового ПО) [8]. При этом в проектах с четкой регламентацией параметров он не покажет своих лучших сторон [29, с. 38].

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова. Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile.

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования [25].

Слабые стороны Agile.

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу [26].

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

Scrum.

Гибкий фреймворк, созданный в 1986 году, считается самым структурированным из семейства Agile. Созданный в 1986 году, он сочетает в себе элементы классического процесса и идеи гибкого подхода к управлению проектами. В итоге получилось очень сбалансированное сочетание гибкости и структурированности [25].

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

Рис. 2.3. Схема работы по Scrum

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений [25]. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет [26]. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой [31, с. 225]. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены [25].

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта [26].

• Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
• Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
• Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
• Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
• Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

Многим Scrum может показаться сложным для внедрения – новый процесс, новые роли, много делегирования и совершенно новая организационная структура [11, с. 136]. Но это гибкий и при этом структурированный подход к реализации проектов, который, в отличие от размытых и общих принципов Agile, не позволит работе пойти не в то русло [26].

Сильные стороны Scrum.

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

Онлайн телеканал Netflix является отличным примером быстрых поставок результатов. Сайт ресурса обновляется каждые две недели благодаря Scrum, который не просто позволяет работать с высокой скорости, но и аккумулирует пользовательский опыт и даёт возможность выявить самое главное для клиентов [26].

В ходе каждой итерации, разработчики добавляют и тестируют новые функции сайта и убирают те, которыми не пользовались клиенты. По словам команды Netflix, основное преимущество Scrum в том, что он позволяет «быстро ошибаться» [3, с. 79]. Вместо того, чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Scrum имеют небольшой размер. Их легко отслеживать и, если что-то идёт не так, быстро исправлять.

Слабые стороны Scrum.

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

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

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

Lean.

Agile говорит нам, что необходимо разбивать на небольшие управляемые пакеты работ, но ничего не говорит о том, как управлять разработкой этого пакета. Scrum предлагает нам свои процессы и процедуры. Lean же, в свою очередь, добавляет к принципам Agile схему потока операций (workflow) для того, чтобы каждая из итераций выполнялась одинаково качественно [26].

В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон [25]. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие необходимые для качественной реализации проектов этапы. Схема показана на рисунке 2.4.

Рис. 2.4 Схема работы по Lean

Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов [5, с. 61].

Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean Вы можете самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами [26].

Сильные стороны Lean.

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean.

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

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

Kanban.

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства [25]. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент [8].

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban [8]. Схема показана на рисунке 2.5.

Рис. 2.5 Схема работы по Kanban

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

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

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile [25]. Но у Kanban есть 4 столпа, на которых держится вся система:

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

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

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

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

Сильные стороны Kanban.

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban.

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

RAD (ускоренная разработка приложений) обычно применяется при разработке нового программного обеспечения, нацеленного на создание приложений [25]. Она очень динамична и выделяет 4 фазы замысла:

• предварительное планирование;
• проектирование, ориентированное на пользователя;
• ускоренное конструирование;
• переключение на другой участок работы [28, с. 73].

Этот способ управления хорошо в малых и средних программных разработках, он дает возможность улучшить риск-менеджмент и поднять показатели результативности. При этом для крупномасштабных многокомпонентных IT-разработок он не подходит по причине недостаточно высокого качества программного кода и необходимости постоянно вовлекать в работу клиента.

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

Выводы.

Самые популярные методики руководства:

Водопадная (каскадная) – традиционная методология, подходящая для всех отраслей, популярна в строительстве.

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

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

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

3. ЭТАПЫ ВНЕДРЕНИЯ ПРОЕКТНЫХ ТЕХНОЛОГИЙ

Ни для кого не секрет, что внедрение проектного управления далеко не тривиальная задача [8]. Причем, примерно понятно, что должно быть «на выходе». А вот какие надо сделать шаги, как двигаться к тому, чтобы проектное управление не просто «начало быть», а стало эффективным инструментом — об этом, как правило, рассказывается весьма скупо.

Шаг 1

Во-первых, чтобы перейти к проектному управлению, надо определить объекты управления. Иными словами, решить, что такое проект [25]. И хотя у него есть понятное определение, далеко не все, что могло бы быть проектом, им является на самом деле. Для целей внедрения проектного управления важно не только ответить на вопрос «что такое проект?» применительно к организации, но и определить очередность охвата проектного управления по типам проектов. Например, в первый контур проектного управления включить стратегические проекты, во второй — значимые и т. д.

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

Шаг 2

Следующий шаг после определения типов проектов — составление реестра проектов.

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

Шаг 3

Далее происходит формирование правил включения проекта в реестр и их исключения оттуда, а также создание свода правил по работе с запросами на изменение. Данный шаг, очень важен, ведь без него однажды проделанная работа может замереть, а картина проектов — остаться статичной [31, с. 460]. Хотя любая организация — это в первую очередь динамика. И реестр проектов тому подтверждение: если все сделано правильно, он будет актуальным и полным. Кстати, несколько слов об этом. Реестр проектов хорошо иметь актуализированным с точки зрения не только классификации, но и состояния дел по каждому проекту. То есть на следующем шаге необходимо договориться о том, как и кем будет обновляться статус проектов. Нужно определить, кто будет принимать информацию о статусе, кто и как часто ее предоставлять. Кроме того, надо установить порядок работы с различными статусами: что эскалировать, что закрывать, что запускать по «рисковым» процедурам. Обычно сбор и анализ статусов — задача проектного офиса. Но иногда достаточно просто настроить информационную систему, а иногда — выделить ответственного за актуализацию информации. Зачастую эта задача решается организацией регулярных встреч руководителей проектов с выделенным сотрудником, который собирает статус.

Шаг 4

Еще один важный шаг, который можно сделать как в начале внедрения проектного управления, так и в конце процесса — определение правил управления проектами [14, с. 312]. Рассмотрим их более подробно.

Во-первых, когда стоит определять правила? Если проектов немного и они относительно понятные — правила лучше определить в самом начале, довести их до всех заинтересованных сторон. Если же проектов много, они разные и по некоторым возможна большая специфика, то, соответственно, правила можно ввести и не сразу, а по мере того, как будет какая-то ясность.

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

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

Шаг 5

Параллельно с правилами требуется выполнить еще один взаимодополняющий шаг, а именно определить правила и по возможности формы отчетности [4, с. 317].

Что это значит? Необходимо проанализировать и понять, кто в компании готовит и получает отчеты по проекту, по портфелю проектов, по всем проектам сразу [25]. При кажущейся простоте эта работа может вылиться в достаточно серьезное исследование компании — кто является заказчиком, кто спонсором, кто руководителем как для отдельных проектов, портфелей проектов и для компании в целом [26]. Более того, следует понимать и быть готовым к тому, что внедрение проектного управления, и в частности проектирования контура проектной отчетности, может вскрыть управленческие проблемы в компании, которые не решаются на уровне исключительно проектного управления. И надо быть готовым к тому, что для нормального функционирование проектного управления понадобится ряд управленческих воздействий по «спрямлению» ситуации (например, по перемещению подразделений, изменению сфер влияния и т. д.) [25].

Если же говорить по сути, то при формировании правил и форм отчетности необходимо для каждого проекта определить:

• кто и как часто предоставляет отчетность;
• кому идет отчетность (маршрут может быть зависим от многих факторов, например, от типа проекта, важности проекта и т. д.);
• при помощи какого инструмента готовится отчетность (в системе, на словах, в формате электронной таблицы, документа, требуется ли предоставление печатной формы, или подписание ЭЦП, или обычной подписью и т. д.);
• что должно составлять отчетность (какие метрики должны попасть в нее обязательно, какие — при отклонениях, а какие рассматривать не стоит);
• как обрабатывается отчетность. Грубо говоря, что должен сделать тот, кто получил отчет: прочесть его, проанализировать, применить какие-то меры управленческого воздействия;
• что будет, если кто-то нарушает регламент [8].

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

Шаг 6

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

К сожалению, риск — неотъемлемый атрибут любого проекта. Неотъемлемый настолько, что про него часто предпочитают не вспоминать [5, с. 61]. А зря. Определение «на берегу» правил работы с рисками и следование им позволяет лучше настроиться на достижение целей как отдельного проекта, так и проектного управления в целом. Для проектного управления важно определить, в какой зоне находится тот или иной проект: «все хорошо», «незначительные отклонения» (могут быть легко скорректированы), «требуется воздействие» (нужна не просто корректировка, а эскалация, и, возможно, пересмотр содержания проекта). При составлении правил проектного управления и отчетности хорошей идеей станет введение некой «системы мер и весов», которая бы численным методом определяла зону нахождения проекта. Что есть «нет проблем»? Что это значит применительно к конкретному проекту? А в каком случае и на какой уровень требуется эскалация? [21]. Решение всех этих вопросов очень индивидуально в масштабах организации, ведь для каждой организации существуют свои правила.

Введение такого рода правил обычно достаточно быстро «окупается» — ввиду того, что, к сожалению, для большинства проектов риски имеют тенденцию проявляться в самый неподходящий момент. В каком-то смысле в проекте работают все законы Мэрфи и немного больше [26].

Поэтому, собственно, РИМ-3 и вводит понятие «КТ»: если мы обозначим КТ по уровням, то получим картину точек контроля и, вероятно, сможем сработать на опережение, если заранее поймем, что КТ, например уровня 0 (уровень контроля бизнес-результатов), «поехала».

Шаг 7

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

Когда в проекте в принципе могут возникнуть изменения? Приведу следующие случаи [25]:

• «аппетит приходит во время еды». Начали проект, поняли, что хочется получить другой результат (больше, меньше или вообще отличающийся);
• проблемы в проекте. Столкнулись с ситуацией, которая вынуждает нас подвинуть КТ. Это может быть как «обычная», так и «рисковая» ситуация;
• внешние обстоятельства. Например, проект делался на заемные деньги, и в какой-то момент финансирование прекратилось.

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

Что важно помнить при проектировании правил относительно запросов на изменение? Во-первых, то, что запросы на изменение для разных типов проектов могут идти по разному маршруту [21].

Во-вторых, следует определить, как запрос на изменение влияет на мотивацию сотрудников (например, проект из полугодового становится годовым вследствие изменения конечной цели — следует ли пересмотреть мотивацию? Или, как вариант, проект требует привлечения дополнительной команды на некоторое время. Будет ли в этом случае на них распространяться мотивация, действующая на основной команде проекта?) и т. д.

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

Кроме того, необходимо определение предварительных маршрутов для разных запросов на изменение. Скажем, запрос на изменение проекта с областью охвата «отдел» и небольшим бюджетом может быть согласован только с начальником отдела [8]. А запрос на изменение проекта с областью охвата «500 сотрудников в шести городах», очевидно, следует согласовывать на уровне топ-менеджеров или менеджеров соответствующего уровня [26].

Шаг 8

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

Мне в практике встречалось два случая: первый — когда внедрение проектного управления начиналось с наиболее спокойных проектов; второй — когда проектное управление внедрялось сначала для наиболее сложных проектов [21].

Для первого случая — внедрения проектного управления от простого к сложному — есть следующие плюсы:

• технология отрабатывается на проектах, где допустим эксперимент и риски не несут больших последствий для компании;
• внедрение технологии проектного управления путем последовательного расширения сферы влияния дает очень плавный и относительно безболезненный старт для внедрения проектного управления [25].

Минусы такого подхода:

• неважные проекты обычно делаются по остаточному принципу. Соответственно, есть высокие риски не отработать технологию целиком на пилотной выборке, а постоянно ее совершенствовать, фактически затягивая проект.
• есть риск, что на сложных проектах технология может быть просто не принята. Одно из возможных возражений: «нам тут работать надо, а не ваши менеджерские штучки делать» [25].

Для второго случая — внедрения от сложного к простому — можно выделить следующие плюсы:

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

Минусами в данном случае будут:

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

Что именно выбрать в каждом конкретном случае — надо смотреть по ситуации. Универсального решения нет, потому что решение зависит от многих параметров: начиная от управленческой конфигурации компании и заканчивая сложившейся корпоративной культурой [25]. Могу лишь посоветовать при принятии решения обратить внимание на следующие моменты:

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

Шаг 9

Здесь надо составить план расширения от пилотной группы до полного объема проектного управления. Необходимо понимать, как и когда какой проект будет включаться в контур проектного управления [14, с. 338]. Как правило, на этом шаге производится обязательное согласование плана с заказчиком внедрения проектного управления и топ-менеджерами (опционально — с руководителями проектов, но, опять-таки, когда и что с кем согласовывать и что не согласовывать — зависит от конкретной ситуации и конкретной организации).

При составлении плана важно учитывать риски и по возможности закладывать резервы на разные неожиданные ситуации. Особенно внимательно следует отнестись к резервам и рискам на первом проекте: там степень неопределенности может оказаться очень высокой [21]. Поэтому оптимальной траекторией является применение на первом проекте элементов SCRUM-подхода: ввести понятие «спринт» для команды внедрения и ставить цели на спринт, а затем анализировать, достигнуты они или нет и какова средняя скорость работы команды внедрения [26]. Правда, такие конфигурации могут быть применены не всегда: культура некоторых компаний отрицает подобный подход.

Шаг 10

После того как определено, на какой пилотной группе будет проходить внедрение, необходимо дать формальный старт внедрению УП (управление проектами). Это следующий, очень важный шаг внедрения проектного управления [9, с. 87].

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

На этом этапе важно договориться о том, чтобы определить дату старта проектного управления. Затем можно начинать проект «в целом».

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

• перспективную оргструктуру подразделения, которое будет заниматься внедрением ПУ;
• оргпреобразования, которые планируется сделать (будет ли команда внедрения ПУ сохранена после проекта, если да, то в каком статусе, что потребуется изменить в оргструктуре компании по ходу и после внедрения и т. д.);
• будет ли выделен проектный офис, если да, то его задачи, полномочия и ответственность [21].

Вывод.

Этапы внедрения проеткных технологий в организации:

Шаг 1. Во-первых, чтобы перейти к проектному управлению, надо определить объекты управления. Иными словами, решить, что такое проект.

Шаг 2. Следующий шаг после определения типов проектов — составление реестра проектов.

Шаг 3. Далее происходит формирование правил включения проекта в реестр и их исключения оттуда, а также создание свода правил по работе с запросами на изменение.

Шаг 4. Еще один важный шаг, который можно сделать как в начале внедрения проектного управления, так и в конце процесса — определение правил управления проектами.

Шаг 5. Определить правила и по возможности формы отчетности.

Шаг 6. Определение рисков.

Шаг 7. На следующем шаге надо определить порядок прохождения запросов на изменение. Это тоже правила, связанные с изменениями в проекте.

Шаг 8. Далее, надо определить пилотную зону, в которой будет проведено внедрение проектного управления.

Шаг 9. Здесь надо составить план расширения от пилотной группы до полного объема проектного управления.

Шаг 10. После того как определено, на какой пилотной группе будет проходить внедрение, необходимо дать формальный старт внедрению УП (управление проектами).

ЗАКЛЮЧЕНИЕ

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

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

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

- освоение и внедрение новых видов продукции на основе передовых технологий;

- внедрение в компании современных управленческих технологий;

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

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

- привлечение инвестиций со стороны за счет внедрения перспективных инициатив;

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

Принципы проектного управления:

1. Принцип дифференцированного подхода.
2. Принцип экономической целесообразности
3. Принцип гибкости
4. Принцип конкурентоспособности
5. Принцип разделения полномочий
6. Принцип открытости
7. Принцип best practices

Самые популярные методики руководства:

Водопадная (каскадная) – традиционная методология, подходящая для всех отраслей, популярна в строительстве.

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

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

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

Этапы внедрения проеткных технологий в организации:

Шаг 1. Во-первых, чтобы перейти к проектному управлению, надо определить объекты управления. Иными словами, решить, что такое проект.

Шаг 2. Следующий шаг после определения типов проектов — составление реестра проектов.

Шаг 3. Далее происходит формирование правил включения проекта в реестр и их исключения оттуда, а также создание свода правил по работе с запросами на изменение.

Шаг 4. Еще один важный шаг, который можно сделать как в начале внедрения проектного управления, так и в конце процесса — определение правил управления проектами.

Шаг 5. Определить правила и по возможности формы отчетности.

Шаг 6. Определение рисков.

Шаг 7. На следующем шаге надо определить порядок прохождения запросов на изменение. Это тоже правила, связанные с изменениями в проекте.

Шаг 8. Далее, надо определить пилотную зону, в которой будет проведено внедрение проектного управления.

Шаг 9. Здесь надо составить план расширения от пилотной группы до полного объема проектного управления.

Шаг 10. После того как определено, на какой пилотной группе будет проходить внедрение, необходимо дать формальный старт внедрению УП (управление проектами).

СПИСОК ЛИТЕРАТУРЫ

1.  Афонин, А.М. Управление проектами: Учебное пособие / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2018. - 184 c.
2. Балашов, А.И. Управление проектами: Учебник и практикум для СПО / А.И. Балашов, Е.М. Рогова, М.В. Тихонова и др. - Люберцы: Юрайт, 2016. - 383 c.
3. Бараненко, С.П. Управление проектами: Учебно-методический комплекс / С.П. Бараненко. - М.: АП Наука и образование, 2014. - 244 c.
4. Верзух, Эрик Управление проектами: ускоренный курс по программе MBA / Эрик Верзух. - М.: Вильямс, 2015. - 480 c.
5. Володин, С.В. Стратегическое управление проектами: На примере аэрокосмической отрасли / С.В. Володин. - М.: Ленанд, 2014. - 152 c.
6. Гонтарева, И.В. Управление проектами / И.В. Гонтарева, Р.М. Нижегородцев, Д.А. Новиков. - М.: КД Либроком, 2014. - 384 c.
7. Гультяев, А.К. MS office Project Professional 2007 Управление проектами: Практическое пособие / А.К. Гультяев. - СПб.: Корона Принт, 2017. - 480 c.
8. Гулюк, Н.В. Принципы успешного управления проектами // Бизнес-образование в экономике знаний. 2017. №2 (7). [электронный ресурс] – Режим доступа. https://cyberleninka.ru/article/n/printsipy-uspeshnogo-upravleniya-proektami (дата обращения: 10.03.2019).
9. Джалота, П. Управление проектами в области информационных технологий / П. Джалота. - М.: Лори, 2014. - 224 c.
10. Зуб, А.Т. Управление проектами: Учебник и практикум для академического бакалавриата / А.Т. Зуб. - Люберцы: Юрайт, 2016. - 422 c.
11. Йордон, Э. Управление сложными Интернет-проектами / Э. Йордон. - М.: Лори, 2014. - 344 c.
12. Керцнер, Г. Стратегическое управление в компании. Модель зрелого управления проектами. / Г. Керцнер. - М.: ДМК, 2014. - 320 c.
13. Коваленко, С.П. Управление проектами: Пректическое пособие / С.П. Коваленко. - Мн.: Тетралит, 2013. - 192 c.
14. Ларсон, Э.У. Управление проектами: Учебник / Э.У. Ларсон, К.Ф. Грей; Пер. с англ. В.В. Дедюхин. - М.: ДиС, 2013. - 784 c.
15. Лич, Л. Вовремя и в рамках бюджета: Управление проектами по методу критической цепи / Л. Лич. - М.: Альпина Паблишер, 2016. - 352 c.
16. Ньютон, Р. Управление проектами от А до Я / Р. Ньютон. - М.: Альпина Паблишер, 2016. - 180 c.
17. Павлов, А.Н. Управление проектами на основе стандарта PMI PMBOR.Изложение методотологии и опыт применения / А.Н. Павлов. - М.: Бином. Лаборатория знаний, 2012. - 208 c.
18. Перевощиков, Ю.С. Управление проектами в машиностроении: Учебное пособие / Ю.С. Перевощиков. - М.: ИНФРА-М, 2014. - 233 c.
19. Полковников, А.В. Управление проектами. Полный курс МВА / А.В. Полковников, М.Ф. Дубовик. - М.: Олимп-Бизнес, 2013. - 552 c.
20. Попов, Ю.И. Управление проектами: Учебное пособие / Ю.И. Попов, О.В. Яковенко. - М.: НИЦ ИНФРА-М, 2013. - 208 c.
21. Плотников, А.Н. Актуальные проблемы управления проектами // Изв. Сарат. ун-та Нов. сер. Сер. Экономика. Управление. Право. 2014. №1-2. [электронный ресурс] – Режим доступа. https://cyberleninka.ru/article/n/aktualnye-problemy-upravleniya-proektami (дата обращения: 20.03.2019).
22. Расмуссон, Д. Гибкое управление IT-проектами: Руководство для настоящих самураев: Как мастера Agile делают выдающееся ПО / Д. Расмуссон. - СПб.: Питер, 2012. - 272 c.
23. Ройс, У. Управление проектами по созданию программного обеспечения / У. Ройс. - М.: Лори, 2014. - 424 c.
24. Романова, М.В. Управление проектами: Учебное пособие / М.В. Романова. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. - 256 c.
25. Ручкин, А.В. Управление проектами: Основные определения и подходы // Вопросы управления. 2017. №3 (46). [электронный ресурс] – Режим доступа. https://cyberleninka.ru/article/n/upravlenie-proektami-osnovnye-opredeleniya-i-podhody (дата обращения: 14.03.2019).
26. Рыбкина, Е.А. Управление проектами: область, методология, система // ВЭПС. 2014. №1. [электронный ресурс] – Режим доступа. https://cyberleninka.ru/article/n/upravlenie-proektami-oblast-metodologiya-sistema (дата обращения: 17.03.2019).
27. Сооляттэ, А.Ю. Управление проектами в компании: методология, технологии, практика: Учебник / А.Ю. Сооляттэ. - М.: МФПУ Университет, 2012. - 816 c.
28. Соснин, Э.А. Управление инновационными проектами: Учебное пособие / Э.А. Соснин. - Рн/Д: Феникс, 2013. - 202 c.
29. Фласинский, М. Управление информационными проектами / М. Фласинский. - М.: Горячая линия -Телеком, 2013. - 190 c.
30. Фласинский, М. Управление информационными проектами / М. Фласинский; Пер. с польск. И.Д. Рудинский. - М.: Гор. линия-Телеком, 2013. - 190 c.
31. Шапиро, В.Д. Управление проектами: Учебное пособие для студентов / И.И. Мазур, В.Д. Шапиро, Н.Г. Ольдерогге; Под общ. ред. И.И. Мазур. - М.: Омега-Л, 2014. - 960 c.