Алферов

Часть 1. Проект и в чем его специфика
Проекты, процессы и модель cynefin
К концу 20 века в науке о менеджменте сложилось мнение, что основная задача менеджера - организовать плановую работу вверенной ему организации и (или) подразделения. Внеплановая деятельность организации должна быть минимизировать, потому что эффективно управлять можно только плановой деятельностью. При этом выделялись два подхода к планированию, организации и контролю работу - проектный и процессный. И соответственно, два основных объекта управления - проект и процесс.
Предполагалось, что менеджеру, чтобы правильно построить работу по получению определенного результата, нужно ответить на ряд вопросов.
- деятельность периодически повторяется? Она понятна и описана? Она имеет высокую степень определенности?
- деятельность уникальна, инновационная, нет опыта выполнения таких работу? Есть ограничения: сроки, бюджет?
Если первое - опишите и вы стройте процесс работы (операционную деятельность). Если второе - запустите и выполнять по известным правилам проект.
Модель "Киневин" Определяет тактики поведения в различных условиях и контекстах.

Вначале каждый стикер (отдельный блок работ) были наклеек в центре листа, а потом в рамках брейнсторминга брали каждый стикер и обсуждали: ясно ли, что с этим делать.
 
Глава 3. Характеристики проекта. Сложность, уникальность, ограничения
Определение проекта из ГОСТ Р 54826-2011 "Проектный менеджмент. Требования к управлению проектом". Проект - это комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.
В проекте выделяют три основные особенности: сложность, уникальность и ограничения.

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

Обычно проект считается успешным, если он завершен в полном объеме, в рамках бюджета, в установленные сроки, с заданным уровнем качества и при удовлетворении заказчика.
 
Глава 4. Что дает проектное управление?
Самый известный провальный проект в современной России - строительство Зенит-Арены. В 2004 году планировали построить за 3 года и 6.7 млрд. руб. Финальный срок - почти 10 лет и затраты 43.8 млрд. руб. Основные причины: дефицит бюджета из-за девальвации рубля, незавершенный, постоянно меняющийся проект, многочисленные смены подрядчиков и отсутствие заказчика.
Отчеты разных источников показывают, что количество провальных проектов в мире сокращается из-за внедрение проектного управления. Затраты на управления проектом в диапазоне от 0.1 до 15% дает эффект от 20 до 30% бюджета. А в некоторых случаях может достигать и несколько раз.
 
Глава 5. Стандарты управления проектами
Стандарт - это:
- концентрация лучшей практики - стандарты в области управления проектами содержат лучший мировой опыт в этой области;
- системная картина - стандарты отражают системную картину отдельной области менеджмента - управления проектами;
- взаимодействие - стандарты представляют собой основу взаимодействия и общей терминологии, особенно для специалистов из разных областей знаний;
- сертификация: стандарты - основа для сертификации специалистов.
Практически все стандарты не подразумевают прямого использования. Это сборники идей в помощь проектному менеджеру, на основе которых менеджер должен создать набор, подходящий для его конкретного проекта.
 
Часть 2. Национальные особенности управления проектами
 
Глава 6. Особенность 1. А. Н. К. А. Два режима работы: стабильный и мобилизационный
Первая особенность построена на древней поговорке, что русский человек на трех сваях крепок: авось, небось и как-нибудь.
Не устраненный вовремя инцидент может разрушить даже самый проработанный проект.
Можно выделить три национальные модели работы с инциндентами.
Японская модель управления. Нацелена на то, чтобы вообще не допускать инцидентов. Много внимания уделяют именно тому, чтобы предугадать, что может пойти не так, и профилактике этих вариантов.
Американская модель управления. Фокусируется на том, чтобы устранить все нештатные ситуации как можно быстрее и таким образом не допустить настоящего кризиса.
Российская модель управления. Нацелена на борьбу с возникающие кризисом. В России нередко проекты запускаются в условиях приближающегося кризиса, когда нет ни времени, ни желания провести проработка и планирование. А проекты, которые приводятся в действие не в условиях кризиса, часто затягиваются до того момента, пока он не наступит.
 
Глава 7. Особенность 2. Авторитарный стиль: ответственность сверху не дают, снизу не берут
Осноположником национальных особенностей в управлении был Герт Хофстед. Он ввел 6 осей, по которым можно разделить культуры разных стран: 1. Дистанция власти, 2. Индивидуализм. 3. Напористость. 4. Избежание неопределенности. 5. Ориентация на долгосрочную перспективу. 6. Ориентация на наслаждение жизнью.
В России очень большая дистанция власти, т. е. любая деятельность должна быть  поддержана сверху, и должен быть четкий мандат на её выполнение. Снизу инициатива приветствуется крайне посредственно.
Как же это влияет на проектное управление? Ведь проектное управление - это способ делегирования. Нет делегирования - нет проектного управления.
А у нас очень сложно выстроить эту иерархию. Руководитель проекта и команда не получают полномочий. Принятые руководителем и командой решения могут быть оспорены в любой момент первыми лицами.
 
Глава 8. Особенность 3. Византийская система: ориентация на личные отношения
Часто говорят, что в России ориентация на процесс, а не на результат. Но это заблуждение. На самом деле в России ориентация не на процесс и не на результат, а на отношения. По опросам многие отметили ориентацию на личные взаимоотношения (византийская система) как основной фактор в своей работе.
В России с давних времен очень важны не регламенты, не таблички с критериями, а мнение уважаемых людей.
Исследование карты культурных различий Эрин Мейер, которая ввела еще одну ось - доверие. На одной оси доверия это профессионализм как основа доверия, на другой стороне оси важно есть ли рабочий контакт или нет. Если нет, то нет и доверия.
По исследованиям Эрин Мейер в России доверие на основе отношений.
 
Глава 9. Особенность 4. Несоблюдение правил: жизнь отдельно, закону / регламенты отдельно

Чтобы проектное управление работало, надо выстроить систему контроля над соблюдением правил.
 
Глава 10. Особенность 5. Консерватизм и недоверие: критический взгляд на чужой опыт и все новое.
По параметры "избежание неопределенности" у России показатель - 95. Наши люди не любят новое, не хотят видеть его и боятся любых неожиданностей, страшатся новых незнакомых ситуаций.
 
Глава 11. Адаптация: как швейцарский сыр помогает в работе с национальными особенностями
Модель швейцарского сыра, или, как ее еще называют, модель кумулятивного действия, пришла к нам из авиации. Суть ее в том, что она предлагает ставить на пути вероятного происшествия как можно больше преград. Но в каждой преграда есть дырки - отдельные упущения и ошибки. Такие дыры имеются всегда, в любой системе на любом уровне. Но на каждом уровне они образуются в разных местах, поэтому, когда на одном уровне событие проходит в дыру ошибки, то на следующем на пути события ее нет. Это останавливает развитие нежелательного явления. Такие преграды защищают систему от масштабных инцидентов, которые были бы сложно устранить.
Любой проект из-за сложности, уникальности и ограничений сталкивается с рисками.
Проектный ромб описывает 4 правильные вещи, которые необходимо делать: правильно проработать проект, правильно его приживить, правильно думать о проекте и правильно его делать.

Часть 3. Как правильно проработать проект и приживить продукт
 
Глава 12. Модели "цепочка решения проблемы" и "пентабазис"
Понимание будущего проекта нам необходимо сформировать еще до его официального запуска. Первый вопрос, на который нужно ответить инициатору еще до запуска проекта: ЗАЧЕМ и для кого он реализуется. Второй вопрос - ЧТО должно быть на выходе. Важно, чтобы цель была измерима. Следующий мы должны ответить на вопрос, КАК мы пойдем к решению проблемы, к достижению цели. После того как мы разобрались с Зачем, Что и Как, нужно думать, КТО будет реализовывать проект. Следующий вопрос - ЧЕМ надо обеспечить участников. Последнее, с чем надо разобраться, - определить УСЛОВИЯ, в которых реализуется проект. Это все его ограничения и возможности.

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

Глава 13. Пентабазис. Зачем, для кого и что?
Все вопросы пентабазиса могут уточняться по ходу реализации, расширяться и сужаться. Но самые критичные к изменениям - Зачем и Для кого. Как только происходят изменения в ответе на эти вопросы, необходимо проверить цикл вопросов всего пентабазиса - актуальны ли ещё цели и результаты?
Как правильно сформулировать проблему? Есть подборка вопросов, которая в этом поможет.
Если вы решаете проблему организации:
Что представляет собой проблему, негативно влияющую на организацию?
Кто внешний или внутренний клиент, страдающий от проблемы?
Где случается проблема?
Когда проблема впервые была обнаружена?
Насколько масштабна проблема?
Почему это для нас проблема?
Если вы решаете проблему клиента:
Кто наш клиент?
Что его не устраивает в текущей ситуации?
Где случается проблема?
Когда проблема стала широко распространена?
Насколько проблема масштабна?
Почему клиента не устраивает текущая ситуация?
Соберите ответы на эти вопросы, и у вас получится целостная формулировка проблемы, которую уже можно добавить в описание.
После того, как разобрались с болью, можно перейти в вопросу: Что? Сформулировать цель проекта, целевые показатели и результаты.
Существует целый ряд методик эффективной постановки целей. Самая известная из них - smart. Цель должна быть конкретной, измеримой, достижимой, уместной, определённой по времени.
Измеримость результатов достижения цели позволяет всё участникам понять, что они пришли туда, куда и планировали прийти.
Определить результаты поможет модель комплементарных активов.

Рис. 13.2
 
Глава 14. Пентабазис. КАК? Жизненный цикл проекта
При ответе на вопрос КАК должно сформироваться первичное понимание пути и достижения цели и результатов: как вы пойдете к цели, как планируете получать результаты. Описание проще начинать с больших шагов / этапов/ блоков работ, которые в проектном управлении и называется жизненным циклом проекта.

Глава 15. Пентабазис. КТО? Заинтересованные стороны
Заинтересованные стороны в проекте - лица или организации, чьи интересы могут быть затронуты в ходе реализации проекта.

Рис. 15.1
Корневая причина провалов проектов - задержки с принятием решений. Ценность Быстроты принятия решения Выше Качества принимаемого решения.
Самый простой способ определить заинтересованные стороны - письменно ответить на ряд вопросов.
1. Кто будет принимать решения?
2. Кто может помочь?
3. Кто может помешать?
4. Кому интересно?
5. Кто уже занимался этой темой?
6. На кого влияет проект?
7. У кого есть полезные ресурсы?
8. Кто платит?
9. Кто получит эффект?
10. Кто может повлиять на тех, кто будет принимать решения?
Инструментов для работы с заинтересованными сторонами много. Рассмотрим матрицу заинтересованных сторон.

Работайте со стейкхолдерами на протяжении всего проекта. Для ключевых стейкхолдеров нужно глубоко разобраться в интересах, связях, взаимовлиянии.
Эффективные коммуникации - 80% успеха работы со стейкхолдерами.
 
Глава 16. Пентабазис. Кто и Чем? Руководители и исполнители
Всё существующие стандарты проектного управления утверждают, что для проекта обязательно нужно выделить отдельную организационную структуру. Временную, конкретно под этот проект. И в ней должны быть определены специальные роли.
Проектная роль - сочетание задания, полномочий и ответственности (ЗПО): что человек в этой роли делает (какие его функции), какие права у него есть и за что он отвечает в проекте.
ГОСТ говорит, что в оргструктуре проекта обязательна четыре роли.
Куратор - лицо, ответственное за обеспечение проекта ресурсами и осуществляющее административную, финансовую и иную поддержку.
Заказчик - физическое или юридическое лицо, владелец результата проекта, соответственно, формулирующий требования к нему.
Руководитель проекта - лицо, осуществляющее управление проектом и ответственное за результаты.
Команда проекта - совокупность лиц, групп и организаций, объединенных во временную организационную структуру для выполнения работ по проекту.
Без хорошего Куратора шансы на успех проекта минимальны. Особенно для Российской действительности с авторитарным стилем управления.
Ключевые функции Куратора вокруг главных вопросов Пентабазиса таковы:
1. Целеполагание проекта.
Именно Куратор определяет правильность ответов на вопросы, Зачем и Для Кого нужен проект, Что мы хотим видеть в итоге. Детально на вопрос Что отвечает заказчик.
2. Контроль и принятие ключевых решений. Он хорошо понимает контекст и окружение проекта, политические аспекты, поэтому может принимать обоснованные стратегические решения и определять Как реализовать проект.
3. Административная поддержка. Куратор, будучи руководителем высшего звена, имеет значительно больше полномочий, фактической власти и влияния в организации, чем руководитель проекта. Куратор способен обеспечить взаимодействие с ключевыми заинтересованными сторонами, разруливать проблемы, которые не могут быть решены на уровне проекта.
4. Обеспечение проекта ресурсами. Именно Куратор определяет, Кто будет руководителем проекта. Куратор на уровне организации договаривается, Чем нужно обеспечить проект.
5. Обеспечение системного управления проектом. Задача Куратора - помочь руководителю проекта создать эффективную систему управления; определить ее обязательные элементы с учётом предметной области, рисков, сложности проекта и требований внешних сил.
В классическом подходе главная роль именно в управлении проектов - роль его руководителя. Он - Мозговой центр проекта. К нему сходятся всё нити управления. Он должен быть мотивирован достичь целей.
Команда - это человеческие ресурсы. Причём не все люди будут прямо входить в команду проекта.
 
Глава 17. Детальная проработка Пентабазиса
Для многих проектов первичной проработки Пентабазиса достаточно. Мы заполнили Описание, согласовали его с заинтересованными сторонами, утвердили и пошли реализовывать проект. Но когда проект сложный и на кону стоял большие деньги, одностраничного документа становится недостаточно.

Вопрос: как глубоко уходить в проработку проекта? С какого момента можно все-таки запускать его? Достаточно ли первого слоя, зафиксированного в описании, или нужно идти всё глубже?
Ответ очень не прост. Он сильно зависит от бюджета проекта, рисков, важности для заинтересованных сторон и множества других факторов. Одно можно сказать определённо: хорошая практика - не требовать детальных ответов при запуске проекта, а собирать ответы поэтапно, на каждом этапе получая всё больший объем информации, определяясь с тем, правильный ли проект выбрали и верно ли мы его распланировали.
Часто в начале проекта многие вопросы Пентабазиса лежат в области высокой неопределённости.
Две базовые практики, которые используются в, этом случае, - MVP и Hadi цикл.
 
Глава 18. Формирование требований к продукту проекта
Механизм фиксации требований к продукту необходим для получения ответа на вопрос: как должен выглядеть в деталях продукт проекта? Какие у него должны быть характеристики? Что заинтересованные стороны хотят от проекта?
Механизм обязательно отрабатывается на этапе подготовки, но может быть запущен и несколько раз в ходе проекта - при появлении новых заинтересованных сторон, новых результатов или каких-то других изменений.
Типовые шаги механизма следующие.
1. Провести предварительное выявление требований заинтересованных сторон.
2. Определить список обязательных результатов (продуктов проекта) - что будем принимать на выходе.
3. Сформировать требования под каждый из результатов.
4. Провести анализ требований - что подходит, что не подходит, какие есть противоречия и приоритеты.
5. Согласовать требованиями ключевыми заинтересованными сторонами.
6. Официально утвердить документ, фиксирующий требования.

Глава 19. Контрольные точки - "спицы, сшивающие проект"
Проработка Пентабазиса должна завершится фиксацией ключевых моментов в виде контрольных точек.
Что такое контрольная точка, можно запомнить через акроним РОКС.
- Результат. Что получим?
- Ответственный. С кого спрашивать?
- Критерий приёмки. Соответствует ли требованиям?
- Срок получения результата.
Есть контрольные точки, которые важны, для Куратора и большинства заинтересованных сторон. Следующий уровень - менеджер проекта. У него этих контрольных точек будет намного больше. У рабочей команды проекта ещё больше своих контрольных точек.

Глава 20. Механизм планирования проекта
В рамках проработки Пентабазиса получаем список ожидаемых результатов (Что), основные этапы жизненного цикла и их сроки (Как), структуру команды (Кто), список необходимых ресурсов (Чем). Условия реализации проекта  дают нам дедлайны и другие факторы, которые надо учесть при планировании. Обычно всё это должно быть зафиксированно в описании проекта. Механизм требований к результатам даёт перечень того, что нужно сделать на выходе, в виде технического задания или аналогичного документа

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

Глава 21. Проверка, приёмам и приживление продукта
Проект мало правильно сделать. Его ещё нужно правильно проверить. И не только правильно проверить, но и ещё и правильно принять. А потом его же нужно и приживить - сделать так, чтобы пользователи начали им пользоваться.
Начнём с проверки. Она должна выявить несоответствия между требованиями и тем, что получилось. В теории управления проектами это и называется контролем качества.
После того как продукт проверен, можно говорить о приёмке. Для этого должен быть отработан механизм проверки и приемки результатов. И его нужно Обязательно продумывать заранее. Как можно раньше задумайтесь о том, Кто и Как будет принимать результаты вашего проекта.
Шаги механизма проверки и приемки следующие.
1. Определение с заказчиком и подхода к приёмке. Как будет проводится приемка - по частям или в конце. Кто будет принимать, один или комиссия.
2. Фиксация правил приемки в специальном документе.
3. Непосредственно проведение проверки и приемки.
4. Фиксация несоответствий и принятие решения о дальнейших действиях.
5. Фиксация решения о приёмке.
Для приживления продукта необходимо несколько условий. Руководитель проекта должен постоянно думать о том, подходит ли продукт пользователям, будут ли его применять. Также нужно постоянно работать над вовлечением заказчика и пользователей в проект.
Следующее важное направление - работа с сопротивлением.
 
Часть 4. Как правильно думать о проекте и делать проект
 
Глава 22. Проектное мышление
Реализация проекта делится на две части: часть мышления и часть действия.
Мышление - это процесс обработки информации, направленный на установление связей и отношений между объектами и (или) явлениями окружающего мира.
Выготский: всякое мышление возникает как ответ на известное затруднение вследствии нового или трудного столкновения элементов среды. Там, где этого затруднения нет, там, где среда известна до конца, там нет мышления, там всюду работают автоматические аппараты.
Проектное мышление предполагает способность:
- сформировать образ конечного результата и удерживать его на протяжении всего пути реализации проекта.
- разложить результат на крупные смысловые части (декомпозировать), а крупные - на более мелкие, вплоть до конкретной задачи для одного человека на один день.
- обнаружить противоречия в плане достижения цели.
- фокусироваться на приоритетах.
- анализировать ход реализации проекта и текущие ситуации, быстро сориентироваться и определить ключевую проблему.
- приоритизировать проблемы по силе /скорости наступления событий и эффекту.
- видеть через призму возможностей (позитивное мышление с одной стороны / высокая тревожность с другой).
- находить оптимальное решения с учётом ограничений (время и ресурсы), уметь быстро собрать недостающую информацию из разных источников и принять решение на основе данных.
- собирать, аккумулировать как собственный опыт, так и успешный / неуспешный чужой, осмыслять его и интегрировать с текущими задачами.
 
Глава 23. Аспекты и ракурсы проекта
Индийская притча о том, как слепые изучали слона. Они подрались и победил самый сильнейший, и все согласились, что слон - это верёвка.
Нередко в итоге люди считают, что проблема не в их зоне ответственности. Поэтому они не понимают важности целей и задач других участников проекта. Чтобы этого избежать, нужно разделять проект на части. Можно сказать, что он состоит из аспектов (разрезов) - для каждого определены свои сроки, бюджеты, ресурсы, результаты и подрезультаты.
Аспектов в проекте может быть множество. Есть отличный инструмент, который  может помочь, - чек-лист. Для своих регулярных действий руководитель проекта должен иметь несколько чек-листов: ежедневный - для проверки в конце дня, еженедельный - для проверки в конце недели.
 
Глава 24. Управление проектом на разных уровнях
Согласно ГОСТу, управление проектом - это планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта.
Сюда надо добавить ещё три функции, нацеленные на людей: коммуникации со всеми участниками, мотивация участников и поддержка участников в ходе проекта.
 
Глава 25. Система управления проектом
Система управления проектом (СУП) необходима, чтобы управлять аспектами, связывать их между собой, влиять на них, принимать верные решения, учитывать риски, бороться с проблемами или предотвращать их. Система - живая и изменчивая структура. В начале проекта вы закладываете её костяк, затем постепенно улучшаете, добавляя новые инструменты или убирая то, что уже не нужно.
 
Глава 26. Механизм внесения изменений
Изменения - нормальная часть проекта. Однако всё они должны проходить организованно, поэтому нужно определить механизм их внесения.
Типовые шаги механизма внесения изменений:
- оценка влияния изменений;
- подготовить обоснование изменения;
- согласование изменения;
- фиксация решения;
- информирование всех заинтересованных сторон о произошедшем изменении.
 
Глава 27. Схема-рамка "РИМ- III . Миниморум". 20 шагов реализации проекта
 
Глава 29. 6 принципов, 10 постулатов и 20 правил проектного менеджера
Ключевая парадигма (база) проектного подхода - смотри вперёд! Управлять в проекте можно только его оставшейся частью!
Три следствия из этого утверждения:
Следствие 1: чем меньше времени осталось до окончания проекта, тем меньше возможностей у руководителя что-то изменить.
Следствие 2: для управления необходимо создать План по ключевым аспектам на весь период проекта.
Следствие 3: будущее неизвестно, поэтому план должен постоянно обновляться и уточняться.
Принципы, на которых стоит проектный подход:
Принцип 1. В начале проекта всегда определяются причины и обоснование и запуска, цели, ожидаемые результаты, ограничения.
Принцип 2. На каждом проекте своя структура ролей: распределение функций, полномочий и ответственности.
Принцип 3. Ключевые роли: Куратор, Заказчик, Руководитель проекта, команда. Куратор и Заказчик должны активно вовлечены в проект.
Принцип 4. Руководитель проекта - главная движущая сила проекта.
Принцип 5. Проработка и реализация проекта ведутся поэтапно. На каждом этапе осуществляется планирование до необходимого уровня детализации.
Принцип 6. Для управления проектом и применяются специальные практики и инструменты.
10 постулатов.
1. Нет проблемы - нет проекта!
2. Нет дедлайна - нет проекта!
3. Нет ограничений - нет проектного управления!
4. Нет полномочий - нет руководителя проекта!
5. Нет приоритета - нет результата!
6. Нет решения - нет движения!
7. Нет контрольных точек - нет понимания продвижения!
8. Нет команды - нет проекта!
9. Нет веры и мотивации - нет продукта!
10. Нет фактов - нет разговора по существу!