Проектное управление "на пальцах"

Управление в реальной практике сводится, как правило, двум схожим задачам: процессное управление и управление проектами. Попытка применить ДОТУ в отношении любой из них будет тем успешнее, чем лучше получится освоить особенности соответствующего вида деятельности. Минимальны объём теоретической подготовки любой желающий может получить прочитав работу ВП СССР «основы социологии», однако книга эта не лишена изъянов, самый главный из которых — отсутствие описания современного инструментария управленца. Это ни в коей мере не принижает значимость книги, скорее это даёт нам стимул восполнить недостающее.

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

В первую очередь надо понимать, что система условных обозначений для отображения сетевой модели обусловлена абстрактной природой дискретной математики, а в частности теорией графов. Математика работает с абстракцией в чистом виде, у нас же на практике есть вполне конкретный перечень работ. Грубо говоря, сетевая модель состоит из двух типов элементов: кружочков (вершин графа) и стрелочек их соединяющих (ребер графа). Чем является кружочек, а чем стрелка – решать нам. В СССР работу принято было отображать в виде стрелки, а кружочками – отчёты по статусу работы (какие-нибудь совещания отделов). В США пошли по иному пути: работу поместили в квадратик (так они обозначали вершину), а в стрелки использовали для упорядочивания действий. Так родился PERT. Нельзя однозначно утверждать, что одна из систем обозначений лучше другой, однако современная практика перешла к версии где в вершинах графа располагаются работы. Во многом благодаря удобному и доступному софту.

Для построения сетевой модели желательно обзавестись удобным графическим инструментом. Как ни странно, для этой задачи удобнее всего пользоваться большой доской и стикерами.
 
Рисуем сетевой график (сетевую модель)
 
Для построения сетевой модели в первом приближении, первым делом, нужно по отдельности на стикеры выписать все работы, какие нужно выполнить для достижения целей. Это можно сделать в одиночку, например, построив дерево работ, раскладывая последовательно целое на части (декомпозиция). Можно привлечь рабочий коллектив и в режиме мозгового штурма уклеить доску стикерами. А можно и просто «погуглить». Главное, что в результате у вас будет неупорядоченный перечень работ. Главное не забывать, что «согласования» и «принятия решений» - это тоже работы.

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

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

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

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

Также, одновременно с построением графика Ганта следует подготовить основу для последующего контроля:

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

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

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

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

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

Что вам обязательно пригодится в будущем:

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