Создание сетевого графика в классической версии Project
Project
Формат и печать
Представления
Представления
Создание сетевого графика в классической версии Project
Project Online Desktop Client Microsoft® Project профессиональный 2021 Microsoft Project стандартный 2021 Project профессиональный 2019 Project стандартный 2019 Project профессиональный 2016 Project стандартный 2016 Project профессиональный 2013 Project стандартный 2013 Project 2010 Project стандартный 2010 Еще…Меньше
Сетевой график — это графический способ просмотра задач, зависимостей и критического пути проекта. Поля (или узлы) представляют задачи, а зависимости — как линии, соединяющие эти поля. После переключения представлений можно добавить легенду, настроить вид полей и распечатать сетевой график.
-
-
Автоматическое изменение способа окна
-
Изменение способа окна вручную
-
Изменение типа линии между полями
-
Выберите тип сведений о задаче, которые нужно отбирать
Добавление легенды
Выберите «Файл>«>страницы».
На вкладке «Легенда» определите, как должна выглядеть легенда, на каких страницах она должна быть видна, а затем наклейте метки.
Нажмите кнопку ОК.
Автоматическое изменение способа окна
-
Выберите «>сетевой график».
org/ListItem»>
-
В области «Макеткоробки» выберите оптимальные расположение, выравнивание, интервалы, высоту и ширину. Чтобы поля были фиксированы, выберите «Фиксированное» в полях «Высота» и «Ширина».
Выберите «Формат > макета».
Имейте в виду, что сгруппгруппные задачи находятся в автоматическом режиме. Вам потребуется отменить группировку, если вы хотите изменить их.
Изменение способа окна вручную
Если вы дошли до этого места, но по-прежнему не нравится расположение полей, нажмите кнопку «Формат > Макет»,выберите «Разрешить расположение полей вручную», нажмите кнопку «ОК», а затем перетащите поля в нужное место.
Если вы изменили положение задачи вручную, то можете изменить макет связанных с ней задач или подзадач, щелкнув задачу правой кнопкой мыши и выбрав «Макет связанных задач сейчас».
К началу страницы
Изменение типа линии между полями
Если у вас много задач, связанных с задачами-предшественниками или последователями, связи между полями могут быть трудно проследить. Попробуйте изменить стиль линии, а затем разумять их так, чтобы их было легче увидеть.
-
Выберите «>сетевой график».
-
Выберите
-
В области «Стиль ссылки»выберите «Прямоугольник» или «Прямой». Прямоугольные ссылки выглядят так , а прямые ссылки выглядят так, как .
-
Выберите «Показывать стрелки», чтобы добавить стрелки, которые указывают на задачи-предшественники и последователи. Выберите «Показать подписи ссылок», чтобы добавить на линию связи зависимость, время запаздывания или запаздывания.
К началу страницы
Выберите тип сведений о задаче, которые нужно отбирать
Если что-то загромождается (или вы перегружается информацией), попробуйте изменить сведения о задаче в каждом поле, чтобы видеть только самое важное.
-
Выберите «>сетевой график».
-
Выберите «Формат >полей».
-
В параметрах стиля для списка выберите задачу, которую вы хотите изменить.
В области «Граница»выберите нужные параметры фигуры, цвета, ширины и линии сетки.
-
Выберите имя в шаблоне данных, чтобы применить изменения к существующему шаблону. Чтобы создать новый шаблон с вашими изменениями, выберите «Другие шаблоны», а затем — «Создать» (для создания нового шаблона), «Копировать» (чтобы создать новый шаблон на основе существующего), «Изменить (изменить шаблон») или «Импортировать» (чтобы импортировать шаблон из другого проекта).
-
Нажмите кнопку ОК.
К началу страницы
Практика составления графика проекта в MS Project
Статья предоставлена редакцией информационно-аналитического журнала «Управление Проектами» в рамках совместного проекта с Финансовой академией “Актив”.
Современные методы и средства проектного управления, статьи по развитию навыков и компетенций в области управления проектами, программами и портфелями проектов доступны при приобретении выпуска журнала или при полугодовой и годовой подписке.
Читайте больше интересных статей в журнале «Управление Проектами»
Для кого эта статья
Существует масса пособий по работе в MS Project. Почти все они рассказывают о технике: как пользоваться приложением, какие сущности в нем существуют, какие связи между задачами используются и т. д. Однако когда доходит до практики, руководитель проекта сталкивается с необходимостью принимать решения другого характера – какие задачи должны входить в график, как найти золотую середину между детальностью графика и удобством работы с ним, какие приемы лучше использовать, чтобы минимизировать трудозатраты на планирование? Как, в конце концов, обеспечить выполнение сроков проекта?
Данная статья – для тех, кто не нуждается в детальных инструкциях по использованию MS Project. Статья предназначена для практиков, которым будет интересно познакомиться с опытом других руководителей проектов. Ниже изложены некоторые приемы и принципы, которые сформировались в результате многолетнего опыта работы, и которые позволяют сделать практичный график проекта.
Планирование проекта
Хотя график проекта может служить разным целям, здесь мы сосредотачиваемся на задаче управления сроками. Как спланировать и обеспечить выполнение проекта в срок. При этом за скобками остаются задачи расчета полных трудозатрат и стоимости проекта. Решить обе задачи одновременно с помощью одного графика проекта возможно, но сложно, т.к. требования к детальности и полноте графика, в зависимости от поставленных целей, разные.
Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:
- Приспособлен для информирования заказчика и проектной команды. Для этого он должен быть понятным, компактным, логичным, хорошо структурированным.
- Легко модифицируется в случае изменений сроков и состава задач. Его легко поддерживать в актуальном состоянии.
- Позволяет контролировать сроки, обнаруживать проблемы и принимать по этому поводу решения.
Для того, чтобы составить такой график предлагаем следующий план действий:
- Принять решение о способе планирования.
- Избавиться от всего лишнего и упростить план.
- Установить взаимосвязи между задачами.
- Оценить длительность задач
- Избавиться от распараллеливания задач
- Выровнять ресурсы.
- Установить ограничения по датам.
- Выявить критический путь.
- Добавить временные буферы в график.
- Проанализировать, как можно сократить сроки.
1. Принять решения о способе планирования
1.1. Планирование от начала
Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.
В свойства проекта устанавливаете дату начала. Все новые задачи автоматически сдвигаются в начало, т.к. по умолчанию для них устанавливается тип ограничения «Как можно раньше». После выстраивания последовательности задач с помощью связей, проект растягивается. Путем манипуляций с длительностью и последовательностью задач получаете желаемую дату окончания проекта.
Это более комфортный способ планирования с психологической точки зрения. Легче планировать сначала то, что ближе и понятнее, а затем на основе ближайших результатов, переходить к последующим задачам.
Минус в том, что задачи, которые могли бы быть сделаны позже, становятся в плане слишком близко к началу проекта. Некоторые считают, что это правильно, т.к. лучше делать все как можно быстрее. Наверняка возникнут осложнения, и раннее выполнение задач создает резервы времени. В некоторых случаях это справедливо. Но это также приводит и к негативным последствиям.
В начале проекта, как правило, нужно сосредоточиться на концептуальных и стратегических задачах, отложив все второстепенные, чтобы не распыляться, не терять фокус и не тратить понапрасну ресурсы. Во-вторых, сделанные заранее работы могут оказаться не нужны, или сделаны не так, как требуется из-за недостатка информации. Например, написанные в начале проекта документы придется переписывать, потому что изменились требования заказчика.
Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».
Иногда используют задержки и сдвиги между задачами.
Рисунок 1
Однако пользоваться задержками лучше по возможности меньше.
Величина задержки выставляется произвольно, логики их применения и оценки не видна непосредственно из графика. Читать такой график сложнее. Впоследствии, при изменении графика, возможно, потребуется переоценка длительности и необходимости задержек. Вы вынуждены управлять ими вручную, трудоемкость поддержки графика увеличивается, вероятность ошибки возрастает.
Если задержка действительно необходима, то лучше добавить задачу ожидания явно. В приведенном примере, после Опытной эксплуатации, вместо задержки в 5 дней можно добавить задачу «Подготовка приемочных испытаний». Тогда будет понятно, для чего требуется 5 дней, кто должен это делать, и чем грозит изменение сроков по этой задаче.
1.2. Планирование от конца
Если конечная дата проекта жестко определена, то правильнее планировать «от конца». Устанавливается дата окончания проекта, и во всех новых задачах автоматически устанавливается тип ограничения «Как можно позже».
Логика планирования в этом случае другая, но в некотором смысле более правильная. Вы задаете себе вопрос: «что необходимо, чтобы завершить проект?». Затем определяете, что необходимо, чтобы достичь этих промежуточных результатов, добавляете предшествующие задачи, к ним в свою очередь присоединяются предыдущие задачи и т.д. Выстраивается последовательная цепочка работ, которые ведут к результатам проекта.
Такой способ хорош тем, что выстраивается четкая логика цепочки работа-результат-работа. Последовательное выстраивание плана от конца позволяет осознать, для чего нужна каждая задача, и как будет использован ее результат. И задачи не начинаются раньше, чем необходимо.
Многие скажут, что откладывать задачи на потом рискованно. Что если задача займет больше времени, чем запланировано, и результат опоздает? А она обязательно опоздает, и тогда следующая задача сдвинется и неизбежно сдвинется окончание проекта. Чтобы избежать этого, в график добавляются временные буферы. Подробнее об этом ниже.
2. Избавиться от лишнего и упростить план
Лишним считается все, что не помогает планировать сроки проекта.
2.1. Примеры задач, от которых можно избавиться
Рассмотрим группу задач «Управление проектом». Понятно, что задача управления проекта необходима, но она не определяет длительность проекта, а проект определяет ее длительность. Если мы сосредоточены на планировании сроков, можно ее убрать.
Рисунок 2
Задача «Поддержка». Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам. Можно включить ее в план проекта, но минимизировать ее детализацию. Эта задача может быть спокойно заменена в плане на две контрольные точки: Начало эксплуатации и Окончание поддержки.
Рисунок 3
План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения. Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать. В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения. Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.
2.2. Пример излишней детализации
Расписать задачи до отдельных шагов и действий можно, но что это дает? С точки зрения оценки длительности — ничего. Скорее, приводит к ошибке, т.к. в каждой задаче заложена значительная погрешность.
Рисунок 4
- «Письмо Пятнициной» — «Ответ Пятнициной». Можно спокойно исключить из плана. Если какие-то задачи зависят от получения письма от Пятнициной, и это действительно шоу-стоппер, то вводим веху «Получение списка ключевых пользователей от Пятнициной». То, что для получения списка нам нужно связаться с Пятнициной, может остаться за кадром.
- «Назначение встречи» — 1д. Скорее всего должно занять несколько минут. Вместо этого можно было бы вставить одну задачу по подготовке презентации и веху «Встреча с директорами обществ». Не нужна группировка задач. Вместо четырех строк — две.
- «Выпуск организационно-распорядительной документации» может быть одной задачей. В заметках по задаче, можно перечислить, кому нужно выслать письмо. Длительность задачи определяется суммарным временем подготовки всех документации. И эта информация будет точнее, растягивать эту задач на неделю нет никакой необходимости.
3. Установить взаимосвязи между задачами
Связи между задачам выстраивают логику плана. Связь от конца к началу, означает, что результаты предыдущей задачи, необходимы для начала следующей. По идее, в плане не должно быть задач, у которых нет последователей, кроме последней вехи завершения проекта или этапа. Каждая задача делается в плане для чего-то, ее результат всегда востребован.
Можем дать следующие рекомендации для выстраивания графика.
3.1. Используйте минимум видов связей
В MS Project вы можете использовать разные виды связей между задачами «Окончание-начало», «Начало-начало» и т. д. По возможности, избегайте разнообразия использования разных типов связей. Читать график с разными видами связей сложно. Его поведение графика при модификации становится трудно предсказуемым. Чем проще, чем однообразнее — тем лучше.
3.2. Не используйте связи с суммарными задачами
Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:
Рисунок 5
В результате мы имеем неоптимальный план. Иванов и Петров будут простаивать, ожидая завершения работы Сидорова по Этапу 1. Если у нас есть задача максимально сжать график проекта, мы начнем работы по Этапу 2, не дожидаясь завершения всех работ по Этапу 1. И тогда график будет выглядеть следующим образом. Связи между задачами, в данном случае отражают последовательность работ каждого из ресурсов.
Рисунок 6
Если же действительно нужно закончить все работы по Этапу 1 и только после этого начинать Этап 2, то можно организовать план следующим образом, не прибегая к связям между суммарными задачами — вставить вехи завершения этапа 1 и начала этапа 2.
Рисунок 7
Такой способ организации графика имеет еще одно преимущество — он делает план очень легким для чтения. Это важно для выверки логики и наличия всех необходимых связей между задачами.
3.3. Используйте Сетевую диаграмму
Для выверки связей очень удобно пользоваться при этом не привычной диаграммой Гантта, а сетевой диаграммой.
Рисунок 8
Для этого типа диаграммы важно иметь хорошо организованную группировку связей на вехи. В противном случае очень легко запутаться в стрелках, которые идут из задач в одном углу диаграммы в другой.
Очень часто довольно сложный план на сетевой диаграмме выглядит проще и логичнее, что позволяет быстро проверить наличие и корректность связей между задачами. Смотрите пример реального графика проекта:
Рисунок 9
Рисунок 10
4. Оценить длительность задач
В литературе описано много специальных и общих методик (PERT, мозговые штурмы, Дельфи и проч.). В реальности вы либо делаете оценку из собственного опыта, либо запрашиваете у экспертов или непосредственных исполнителей.
При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:
- О достоверности оценки лучше судить, если известны предположения, их которых исходил оценщик.
- Учитывайте психологические особенность каждого исполнителя
- Сделать поправку длительности. Для некоторых исполнителей, исходя из опыта работы с ними, нужно делить оценку на два, для других — умножать на три.
Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:
- «Студенческий синдром» — выучить курс в ночь перед экзаменом. И в проекте начинаем задачу когда до ее сдачи осталось минимум времени.
- Перфекционизм — если осталось время, надо работу довести до совершенства.
- Отсутствие доверия — «если сегодня я сделал быстрее, то в следующий раз моим оценкам не поверят, и урежут запрашиваемой мной время».
- Возможность работать менее интенсивно — «зачем напрягаться, если есть запас по времени?»
Поэтому придерживайтесь следующих правил при планировании работ:
- Вероятность выполнения в указанный срок установите в 50%. Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое. Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
- Ресурсы не должны быть перегружены. Люди не должны выполнять несколько задач одновременно. В этом случае их производительность будет максимально возможной.
5. Избавиться от распараллеливания задач
Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей. Например,
Рисунок 11
Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам. Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену. Наличие пяти параллельных задач не имеет смысла. Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.
Гораздо лучше было бы назначить одного исполнителя на каждую задачу, оценить каждую задачу по чистой трудоемкости с вероятностью выполнения ее в срок с 50% вероятностью, выстроить задачи в цепочку и добавить временно буфер в конце. Тогда это был бы реальный инструмент управления в руках РП.
6. Выровнять ресурсы
Часто руководители проекта не обращают внимание на то, что согласно составленному графику проекта ресурсы перегружены. Они просто не ставят задачу подгонки загрузки ресурсов под определенную планку. Действительно, если в плане ресурсы перегружены, то это не значит, что в реальной жизни они не смогут выполнить поставленные задачи. Проблема в том, что такой план нам об этом ничего не говорит, в нем нет информации о реализуемости плана. Многократная перегрузка ресурсов в плане равносильна отсутствию информации об их реальной загрузке.
Если мы хотим планировать загрузку ресурсов, нужно загрузку выравнивать. Можно это делать не для всех ресурсов, а только критических, которые мы действительно хотим планировать. Например, мы можем планировать своих сотрудников, но не планировать ресурсы заказчика, загрузка и возможности которых находятся за пределами нашего влияния.
В MS Project имеется функция выравнивания ресурсов. Эта функция расставляет задачи с учетом связей между задачами и ограничения по максимальной загрузке каждого ресурса и приоритета (поле «Приоритет»). Не всегда это приводит к нужному результату. План становится слишком длинным, а ресурсы недогружены. Задачи привязываются в плане к конкретным датам, что мешает их перепланировать. Можно добиться более адекватного плана в ходе автоматического выравнивания с помощью пересмотра зависимостей и расстановкой приоритетов, но это очень кропотливый и трудоемкий процесс.
Альтернатива — это ручное выравнивание с помощью установки последовательности задач, выполняемых одним ресурсом. Это возможно, если план не очень сложный.
Например, модифицируем предыдущий пример:
Рисунок 12
В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.
Было бы более правильно вообще разделить задачи между двумя участниками и избавиться от параллельного выполнения задач А.Теном, но в данном случае это сделать сложно. Поэтому приходится идти на нарушение правил, которые мы сами для себя установили выше. Тем не менее, такой план лучше, т.к. помогает контролировать выполнение задач не в конце 14 рабочих дней, которые мы отвели на проектирования функционального блока «Контроль», а уже через 3 дня после начала работы. Кроме того, это дисциплинирует исполнителя с первого дня, у которого нет 14 дней в запасе, а есть целевой срок 3 дня, когда нужно закончить первый документ.
7. Исключить жесткую привязку задач к датам
Следующий шаг – подгонка графика под необходимые даты. Не всегда удается это сделать естественными связями между задачами, возникает множество обстоятельств, диктующих необходимость начала или завершения задач в определенные периоды времени. Приходится привязывать задачи к датам.
Привязка к датам оправдана, если определяется внешними по отношению к плану условиями. Например, зафиксированная дата начала испытаний; контрольная точка, которая определяется внешним проектом; несдвигаемое событие. Во всех остальных случаях нужно избегать ограничений. Если их избежать не удается, то лучше использовать мягкие ограничения: «Начало не позднее», «Начало не ранее» и т. п. Это позволяет автоматически двигать задачи вслед за теми, от которых они зависят.
8. Выявить критический путь
Если задачи выстроены правильно, то MS Project покажет вам критический путь проекта — цепочку задач, которая определяет длительность. Изменение длительности или задержка начала выполнения любой задачи на критическом пути меняет дату окончания проекта.
Соответственно, чтобы уложиться в установленные сроки, нужно обеспечивать своевременное или опережающее выполнение именно задач критического пути. Для этого нужно:
- Уделять задачам критического пути ежедневное внимание, контролировать готовность всех необходимых ресурсов для их выполнения.
- Мотивировать участников на сокращение длительности выполнения задач критического пути, не допускать отвлечения на другие задачи.
- Использовать временные буферы, страхующие отклонение по срокам.
Например, заканчивается разработка функционального блока. Далее заказчик должен протестировать этот блок. Когда до окончания разработки остается 2 дня, необходимо предупредить ключевых пользователей о том, что через 2 дня они должны быть готовы принять разработку в тестирование. И зафиксировать это формально (электронным письмом, решением оперативного совещания, и т.п.). Разрыв между задачами критического пути приводит к увеличению срока проекта, поэтому управлять этим процессом нужно жестко.
При постановке задачи критического пути исполнителю нужно говорить о том, что эта задача является определяющей для проекта. Исполнитель должен полностью сосредоточиться на ней, не отвлекаться на второстепенные задачи. А в случае возникновения проблем и задержек, сразу оповестить об этом РП.
Но от осложнений никто не застрахован. Нет никаких гарантий, что задача будет выполнена в срок. Но это не означает, что нужно стремиться устанавливать такие сроки, которые гарантированно обеспечивают выполнение задачи в срок. Как известно, работа занимает ровно столько времени, сколько на нее отведено, об этом мы говорили ранее. Устанавливайте агрессивные сроки, но имейте запас для компенсации неизбежных опозданий. И лучше этот запас иметь консолидировано, в буфере, который добавляется в конец критического пути.
Рисунок 13
В приведенном примере красным выделены задачи критического пути, синие — другие задачи, зеленые — буферы. Обратите внимание, что некритические задачи тоже застрахованы буфером. Сроки по ним также с большой степенью вероятности будут нарушены. И чтобы не сорвать своевременное начало задачи критического пути, мы добавляем буфер на входе в цепочку.
Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».
9. Добавить временные буферы в график
Добавление буферов в план позволяет избежать нарушений конечной даты проекта или этапа при неизбежном изменении сроков по задачам.
Как правило, мы добавляем запас в каждую задачу, чтобы нас не наказывали за опоздания. Мы предпочитаем заложить запас на все риски, которые могут случиться — отвлечение на совещания, изменения требований заказчика, длительные согласования, технические проблемы и личные обстоятельства. Стараемся дать оценку необходимых сроков с вероятностью 90% их соблюдения. И несмотря на это, часто их срываем. Выше мы уже говорили о студенческом синдроме и прочих психологических моментах, которые приводят к нарушению сроков несмотря на все резервы, которые мы делаем в каждой задаче
В результате, опоздания всегда накапливаются, а опережения — практически никогда.
Выход следующий – избавиться от резервов в задаче и вынести их в общий буфер проекта. Установить целевую вероятность выполнения задачи в срок в 50% Это значительно сокращает оценку сроков по каждой задаче, согласно статистике – вдвое. В половине случаев он будет нарушен. И это может быт не вина исполнителя, а влияние обстоятельств и неправильной оценки. При таком подходе вы не будете наказывать исполнителей за нарушение сроков, а относиться к этому как к неизбежному.
При этом вы будете иметь запас, чтобы компенсировать отставание. Для этого в график добавляются буферы. Когда задачи опаздывают и сдвигают последующие, вы используете буфер. По скорости расходования буфера можно судить, насколько удачно вы спланировали проект, достаточно ли у вас ресурсов и правильно ли организованы работы. Если буфер расходуется слишком быстро, то необходимо принимать меры.
Рисунок 14
Различаются буферы проекта (этапа) — запас создаваемый в конце критической цепочки. И питающие буферы — временные резервы на входе в критическую цепочку, страхующие поток задач вне критического пути.
Размер буфера определяется длиной цепочки, которую он страхует, а также степенью неопределенности и рисков. Классики рекомендуют отводить на буферы около 50% длительности всей критической цепочки. Руководитель проекта должен исходить из собственной оценки рисков и возможностей графика проекта.
Нужно понимать, что проект с маленьким запасом скорее всего опоздает. Проектов, в которых все идет, как запланировано, не бывает. Невозможность добавить буфер может быть либо в результате явной недооценки сроков проекта, либо из-за явной переоценки длительности проектных задач, что случается, когда мы закладываем запас в каждую задачу. Даже если запас есть, но он заложен в задачи, проект все равно опоздает, по перечисленным выше причинам.
Подробнее об этом методе построения графика проекта можно прочитать в книге Э.Голдратта «Критическая цепь», которая написана в форме бизнес-романа, легко читается и действует крайне вдохновляюще.
10. Проанализировать график
Далее мы переходим к тому, для чего, собственно мы проделывали все предыдущие шаги, непосредственно к работе с графиком.
Хороший график показывает, какие потенциальные проблемы есть в проекте; какие есть возможности для сокращения сроков; достаточно ли ресурсов для выполнения проекта.
10.1. Сокращение сроков
Рассмотрим пример:
Рисунок 15
Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.
Нельзя ли детализировать и разделить эти задачи на части? Оказывается, это разработка отчетов, каждый из которых занимает в среднем по 1 дню. Не обязательно, чтобы их разработку вел один человек последовательно. Можно разделить их на порции и распределить между несколькими разработчиками. Добавили одного разработчика, разделили на неравные части и получили следующий график.
Рисунок 16
Таким образом, график наглядно показал, что необходим еще один человек в команду. Стало понятно, как нужно распределить задачи, чтобы сократить сроки и снизить риски зависимости от исполнителей, которые, например, могут в самый неподходящий момент заболеть.
10.2. Риски, связанные с графиком
Интересно посмотреть на график проекта с точки зрения управления рисками. Какие риски может обнаружить график проекта?
- Параллельное выполнение множества блоков работ или функциональных направлений. Необходимо решить, влечет ли опоздание одного из них серьезные последствия для всего проекта? Сложные проекты включают в себя до десятка направлений. Внедряется одновременно финансы, бюджетирование, HR, логистика и т.д. Если не предусмотрены работы по интеграции и координации направлений, не заложены резервы на отклонения по каждому из направлений, нет этапа интеграционного тестирования, велика вероятность неуспеха проекта в целом, а не только срыва сроков.
- Отсутствие периода опытной эксплуатации. Если ОПЭ невозможна, то нужно рассматривать возможность поэтапного запуска, по функциональным областям или организационным единицам.
- Излишне агрессивный график, отсутствие или недостаточный размер резервов. Об этом уже говорили. Такой проект вероятнее всего опоздает.
- Этапы проекта или ключевые работы идут внахлест, с перекрытием. Во многих случаях это увеличивает риск переделки по уже выполненным задачам.
- Если в графике отсутствуют работы и вехи, закрепленные за заказчиком, то возможно, мы плохо контролируем работы со стороны заказчика. Необходимо обратить внимание на то, что некоторые работы могут быть некорректно отнесены к зоне ответственности исполнителя.
- Отсутствие в графике вех, означающих формальную приемку работ, может означать, что мы не до конца понимаем, какие промежуточные результаты и в какой момент должны подтвердить. А это чревато проблемами при сдаче результатов в конце проекта.
Заключение
На практике часто бывает, что график проекта составляется, потому что так принято, так требуется, для галочки. Но реальное управление проектом идет без его использования, потому что это сложно, трудоемко, и жизнь значительно богаче.
График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам. Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.
Изложенные здесь принципы не являются исчерпывающими, единственно правильными и безусловными. Вы можете следовать другим правилам, если они доказали свою работоспособность.
Научитесь контролировать работу проекта в режиме реального времени с помощью дашбордов Power BI на курсе «ACPM: Бизнес-анализ данных в финансах». Зарегистрируйтесь и пройдите 1-й урок бесплатно!
Посмотреть занятие по бизнес-анализу
Создать сетевую диаграмму в рабочем столе Project
Проект
Формат и печать
Взгляды
Взгляды
Создать сетевую диаграмму в рабочем столе Project
Project Online Desktop Client Project профессиональный 2021 Project Standard 2021 Project профессиональный 2019 Project Standard 2019 Project профессиональный 2016 Project Standard 2016 Project профессиональный 2013 Project Standard 2013 Project 2010 Project Standard 2010 Дополнительно… Меньше
Сетевая диаграмма — это графический способ просмотра задач, зависимостей и критического пути вашего проекта. Блоки (или узлы) представляют задачи, а зависимости отображаются в виде линий, соединяющих эти блоки. После переключения представлений вы можете добавить легенду, настроить внешний вид полей и распечатать сетевую диаграмму.
Добавить легенду
Автоматически изменять способ расположения ящиков
Вручную измените способ размещения ящиков
Изменение стиля линии между блоками
Выберите, какую информацию о задаче отображать
Добавить легенду
Выберите Файл > Печать > Параметры страницы .
На вкладке Легенда решите, как должна выглядеть ваша легенда, на каких страницах она должна отображаться, а затем выберите нужные метки.
Выберите OK .
Автоматическое изменение расположения ящиков
Выберите Просмотр > Схема сети .
Выберите Формат > Макет .
org/ListItem»>
В разделе Макет блока выберите расположение блока, выравнивание, расстояние, высоту и ширину, которые лучше всего подходят для вас. Для равномерного размещения блоков выберите Фиксированный в полях Высота и Ширина .
Имейте в виду, что сгруппированные задачи позиционируются автоматически. Вам нужно будет отменить группировку, если вы хотите изменить их.
Вручную изменить расположение ящиков
Если вы зашли так далеко, но вам все еще не нравится, как расположены ваши блоки, щелкните Формат > Макет , выберите Разрешить позиционирование блоков вручную , выберите OK , а затем перетащите блоки на место вы хотите.
Если вы вручную переместите задачу, вы можете изменить макет любых связанных задач или подзадач, связанных с ней, щелкнув задачу правой кнопкой мыши и выбрав Задачи, связанные с компоновкой Сейчас .
Верх страницы
Изменить стиль линии между блоками
Если у вас есть много задач, которые вы связали с предшествующими или последующими задачами, связи между блоками может быть очень сложно отследить. Попробуйте изменить стиль линий, а затем расположить их так, чтобы их было легче увидеть.
Выберите Просмотр > Схема сети .
Выберите Формат > Макет .
В разделе Тип соединения выберите Прямолинейный или Прямой . Прямолинейные ссылки выглядят так, а прямые ссылки выглядят так.
Выберите Показать стрелки , чтобы добавить стрелки, указывающие на предшествующую и последующую задачи. Выберите Показать метки ссылок , чтобы добавить зависимость и время опережения или задержки к линии связи.
Верх страницы
Выберите, какую информацию о задаче отображать
Если все выглядит загроможденным (или вы начинаете испытывать информационную перегрузку), попробуйте изменить информацию о задаче в каждом поле, чтобы видеть только самое важное.
Выберите Просмотр > Схема сети .
Выберите Формат > Стили блоков .
В списке Настройки стиля для выберите задачу, которую хотите изменить.
В разделе Граница выберите форму, цвет, ширину и параметры линии сетки, чтобы создать желаемый вид.
Выберите имя в разделе Шаблон данных , чтобы применить изменения к существующему шаблону. Чтобы создать новый шаблон, который будет использовать ваши изменения, выберите More Templates , а затем выберите New (для создания нового шаблона), Copy (для создания нового шаблона на основе существующего), Редактировать (чтобы изменить шаблон) или Импортировать (чтобы импортировать шаблон из другого проекта).
Выберите OK .
Верх страницы
Что такое сетевая диаграмма в управлении проектами?
В наше время сложных проектов, охватывающих разные регионы, часовые пояса, быстро меняющиеся технологии и требования, наличие инструментов, повышающих эффективность, может значительно увеличить шансы на успех проекта. Инструменты управления проектами, которые помогают лучше управлять ресурсами и бюджетами и помогают отслеживать ход проекта, являются благом для стрессовых и перегруженных работой менеджеров проектов. Чтобы быть хорошим руководителем проекта, нужно иметь полное представление о необходимых инструментах и управлении конфликтами.
Одним из таких инструментов является сетевая диаграмма в управлении проектами, которая дает визуальное представление рабочего процесса проекта, что позволяет пользователям отслеживать ход проекта в любое время. В этом блоге мы рассмотрим различные характеристики и преимущества сетевых диаграмм в управлении проектами.
Вот статья с описанием проекта.
Что такое проектная сеть?
Визуальные средства, такие как проектные сети, широко используются в управлении проектами, чтобы помочь руководителям проектов и членам группы быть в курсе хода выполнения проектов и делиться информацией со всеми, кто участвует в проекте.
Сеть проекта, также называемая сетью действий по проекту, представляет собой графическое описание последовательности, в которой должны быть завершены конечные события или этапы проекта. Сеть проекта похожа на блок-схему. Конечные события сети представляют действия и результаты, полученные из структуры декомпозиции работ, и располагаются последовательно, как на блок-схеме
. Сети проектов могут быть созданы с использованием таких методов, как диаграммы Ганта, диаграммы PERT и управление критическим путем. В сети проекта есть несколько путей, но каждый конечный элемент должен лежать только на одном пути сети.
Узнайте больше о Agile и традиционном управлении проектами.
Сетевая диаграмма управления проектом
Сетевые диаграммы используются руководителями проектов для отслеживания хода выполнения операций в ходе проекта. Другими словами, они представляют рабочий процесс проекта. Те, кто участвует в проекте, могут получить более полное представление о мероприятиях и графике проекта. Сетевые диаграммы проекта помогают всем, кто участвует в проекте, визуально отслеживать ход каждой фазы проекта от его начала до завершения. Сетевая диаграмма представляет собой диаграмму и содержит прямоугольники и стрелки. Ящики обозначают задачи и обязанности, а стрелки обозначают последовательность, в которой задачи должны быть выполнены, и график.
Сетевая диаграмма также показывает, как одно действие связано с другим, и последовательность действий, которые необходимо выполнить. Приоритет действий, как показано на диаграмме, важен, так как некоторые действия должны быть завершены до начала следующего.
Сетевые диаграммы также помогают определить влияние раннего или позднего завершения задач на общий проект. Менеджеры могут использовать сетевые диаграммы, чтобы лучше распределять ресурсы и планировать свои сроки.
Но создание схемы сети требует тщательного планирования. Все действия должны быть идентифицированы и оценены, так как исключение даже одной задачи из сетевой диаграммы может привести к каскадному эффекту на запланированный график, обязательства, распределение ресурсов и стоимость проекта.
Узнайте больше о характеристиках управления проектами.
Типы сетевых диаграмм
Сетевые диаграммы проекта могут быть двух типов:
1. Метод стрелочных диаграмм (ADM): Как следует из названия, в этом типе диаграмм используются стрелки для изображения конечных элементов/действий. Длина стрелок обычно представляет продолжительность или время, необходимое для выполнения определенного действия или задачи. Хвост показывает начало задачи, а голова показывает завершение задачи. Порядок действий или их приоритет представлен кружками, соединенными стрелками.
Диаграмма также может содержать фиктивные задачи, которые используются для демонстрации взаимозависимости между задачами. Тем не менее, фиктивные задачи не представляют собой какую-либо реальную последовательную деятельность, а представляют собой скорее контрольные точки или вехи, которые, возможно, необходимо выполнить на пути к переходу к следующей задаче.
Преимущества PDM:
- Простота создания
- Легкость понимания
- Помогает отслеживать график проекта
- Помогает в анализе «что, если»
PDM, как и ADM, используются в управлении проектами. Действия представлены прямоугольниками или узлами. Стрелки, соединяющие их, представляют отношения между действиями. В зависимости от приоритета действия стрелки представляют разные отношения. Например, стрелку можно использовать, чтобы показать, что действие не может начаться до завершения предшествующего ему действия или что оба действия могут быть запущены одновременно.
Вот четыре способа построения диаграммы и соединения задач на основе приоритета:
- Окончание-Начало: действие должно быть завершено до начала следующего действия
- Начало-Начало: оба действия могут начинаться вместе
- Окончание-окончание: обе задачи должны быть завершены вместе
- От начала до конца: это редкая зависимость, требующая начала одного действия до завершения другого
Продолжительность выполнения определенного действия может быть указана над стрелкой подключение действия к его преемнику.
Преимущества PDM следующие:
- Делает планирование более эффективным, фокусируясь на взаимосвязях и зависимостях между действиями
- Помогает определить недостающие задачи Помогает делиться сроками проекта между командой и заинтересованными сторонами
- Помогает руководителю проекта лучше управлять проектом и контролировать его
Преимущества сетевых диаграмм
Являясь наглядными пособиями, сетевые диаграммы имеют множество преимуществ, таких как:
- Помощь в отслеживании проектов
- Последовательное расположение проектной деятельности помогает лучше планировать и планировать визуально контролировать статус проекта
- Подробное представление помогает определить критические действия
- Помогает определить риски с точки зрения задержки
- Помогает определить взаимозависимые действия для задач
- Помогает решать проблемы, которые могут возникнуть в ходе проекта
- Может быть предоставлен членам проектной группы
- Полезен для членов проектной группы, которые лучше понимают визуальные представления
- Повышает производительность проекта
- Представляет масштаб проекта на макроуровне
- Используется для составления графика проекта
- Помогает в распределении бюджета
- Помогает установить четкие сроки
- Используется для оценки продолжительности проекта
- Помогает в распределении ресурсов, так как элементы четко представлены
- Точное описание мероприятий помогает получить финансирование и собрать правильную команду
- Повышает эффективность, поскольку команды хорошо осведомлены о сроках Преимущества сетевых диаграмм, есть и определенные недостатки:
- Может быть дорогим инструментом для создания
- Может включать слишком много действий и задач и может быть трудным для понимания
- Возможны ошибки при создании сетевых диаграмм
- Сетевые диаграммы могут быть неверно истолкованы, что может привести к серьезным ошибкам в реализации проекта
- На это могут повлиять внешние факторы
обладать необходимыми навыками и передовым опытом для управления проектами любого размера и сложности.
Разработка сетевой диаграммы
Разработка сетевой диаграммы — непростая задача, в том смысле, что перед ее созданием необходимо выполнить много домашней работы. Руководители проектов или другие лица, вовлеченные во все аспекты проекта и знающие требования проекта на очень детальном уровне, являются идеальными кандидатами для создания сетевой диаграммы.
Сетевая диаграмма требует участия людей, ответственных за различные виды деятельности проекта. Хорошо сделанная сетевая диаграмма упрощает ход проекта и обеспечивает раннее выявление проблем и узких мест.
Требования для создания схемы сети
Как упоминалось выше, создание схемы сети требует тщательного предварительного планирования. Перед созданием схемы сети должна быть под рукой следующая информация:
- Начальная и конечная точки проекта должны быть идентифицированы и определены
- Все действия проекта должны быть определены
- Должна быть выполнена точная оценка времени завершения каждого действия
- Должны быть определены зависимости
Передовой опыт При создании сетевых диаграмм проекта
Сетевые диаграммы при правильном создании могут принести массу преимуществ. Давайте рассмотрим лучшие практики, которых следует придерживаться при построении сетевой диаграммы.
- Используйте общеизвестные и общепринятые стандартные символы для построения сетевых диаграмм
- При использовании различных символов убедитесь, что они правильно определены используется слева направо
- Используйте только одну начальную точку или начальное событие и одну кульминационную точку или конечное событие
- Используйте инструменты для большей точности и ясности
- Убедитесь, что ваша диаграмма содержит актуальную и актуальную информацию
- Сетевая диаграмма должна содержать необходимое количество деталей
- Убедитесь, что данные, используемые для создания сетевой диаграммы, точны и хорошо управляются
Инструменты построения сетевых диаграмм
Существует несколько инструментов для построения сетевых диаграмм, которые являются точными и облегчают нашу работу. Некоторые из них включают:
- Microsoft Visio
- Google Draw
- Lucidchart
- ConceptDraw Diagram
- InterMapper
- EdrawMax и другие.