Как в проджекте изменить название проекта

Изменение сведений о проекте в Project Online

После создания проекта в Project Web App может потребоваться изменить некоторые общие сведения о нем, например название, описание проекта или его владельца. Способ внесения изменений в проект зависит от того, является ли он проектом списка задач SharePoint, в котором управление задачами осуществляется с использованием списка задач на сайте проекта, или корпоративным проектом, в котором управление задачами осуществляется в Project Web App.

Примечание: Вы также можете изменить шаблон, используемый в проекте. Дополнительные сведения см. в статье Изменение шаблона проекта.

Чтобы изменить сведения о проекте списка задач SharePoint, выполните указанные ниже действия.

1. Перейдите на страницу Сведения о проекте.
   • На панели быстрого запуска в Project Web App выберите пункт Проекты. Щелкните имя изменяемого проекта, чтобы открыть сайт проекта. На панели быстрого запуска для сайта проекта выберите пункт Сведения о проекте.
   • На сайте проекта выберите на панели быстрого запуска пункт Сведения о проекте.
2. Внесите изменения на странице Сведения о проекте, а затем на вкладке Проект в группе Проект выберите команду Сохранить.
3. Завершив внесение изменений в проект, откройте вкладку Проект и в группе Проект выберите команду Закрыть.

Чтобы изменить сведения о корпоративном проекте, выполните указанные ниже действия.

1. Откройте проект для редактирования.
2. Если вы используете Project Server 2013, на панели быстрого запуска выберите под именем проекта пункт Сведения о проекте или щелкните одну из других ссылок на страницы со сведениями о проекте, чтобы внести необходимые изменения. Если вы используете Project Server 2016, сразу откроется раздел Сведения о проекте, где вы сможете внести необходимые изменения.
3. Внеся изменения, выберите на вкладке Проект в группе Проект команду Сохранить, чтобы сохранить изменения и опубликовать их для других пользователей.
4. На вкладке Проект выберите в группе Проект команду Закрыть. При этом можно вернуть проект или оставить его извлеченным.

Переименование проекта в классической версии Project

Классический клиент Project Online Project профессиональный 2021 Project стандартный 2021 Project профессиональный 2019 Project стандартный 2019 Project профессиональный 2016 Project стандартный 2016 Project профессиональный 2013 Project стандартный 2013 Project 2010 Project стандартный 2010 Еще. Меньше

При первом сохранение проекта заголовокпроекта или его название устанавливаются. После этого его можно изменить в любое время.

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

1. Выберите команды Файл >Сведения.
2. Справа выберите «Сведения о проекте» >дополнительные свойства.
3. На вкладке Документ введите новое имя в поле Название.

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

Основные настройки системы MS Project Pro

Видео материала «Основные настройки системы MS Project Pro»

Описание особенностей настройки системы управления проектами MS Project Pro

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

Общие настройки MS Project Pro

Для установки основных параметров системы MS Project Professional:

• Для установки основных настроек перейдите на пункт меню «Файл» и подпункт «Параметры«
• В открывшимся окне «Параметры Project» перейдите на пункт «Общие«
• В поле «Представление по умолчанию» Вы можете выбрать представление системы загружаемое по умолчанию.
• В поле «Формат даты» Вы можете установить формат вывода дат проекта.
• В поле «Имя пользователя» указывается имя и фамилия пользователя.

Настройка валюты проекта в MS Project Pro

В MS Project Professional может быть использована единая валюта для всего проекта. Для настройки валюты проекта:

1. Зайдите на пункт меню «Файл» и подпункт «Параметры«.
2. В открывшемся окне «Параметры Project» выберите пункт «Отображение«.
3. Вы можете установить параметры валюты для любого открытого проекта. Выберите проект «Параметры валюты для этого проекта»
4. В поле «Валюта» указывается значение валюты. При установке валюты все остальные параметры устанавливаются автоматически.
5. В поле «Символ» введите символ валюты если он не совпадает стандартным символом валюты системы.
6. В поле «Расположение» укажите где должен располагаться символ валюты.
7. В поле «Десятичные знаки» укажите сколько знаков после запятой должно быть при выводе валют. Для валют которые на практике не используют копейки укажите нулевое значение.

Свойства проекта в MS Project Pro

Вы можете указать дополнительные сведения о Вашем проекте. Для этого необходимо перейти на вкладку «Файл» в пункт меню «Сведения«. На открывшейся странице выберите пункт «Сведения о проекте» и подпункт «Дополнительные свойства«. В результате откроется окно «Свойства» со следующими закладками:

• Общие
• Документы
• Статистика
• Состав
• Прочие

Описание организатора в MS Project Pro

Организатор – механизм настройки основных элементов системы. Организатор помогает настроить систему под специфические потребности пользователя. В файле системы global.mpt система сохраняет все настройки системы. Данный файл привязан к локальной версии программного продукта, так что при переносе плана проекта с одного компьютера на другой, уникальные представления могут не переноситься. Так же при открытии нового плана-графика не перенесенные элементы не отображаются. При создании новых элементов в системе необходимо перенести данные элементы в файл global.mpt.
В организаторе можно сохранять: Представления, Таблицы, Модули, Поля, Группы, Календари, Панели инструментов, Схемы, Формы, Фильтры.

Для доступа к организатору зайдите на страницу «Файл» и выберите пункт «Сведения» и на открывшейся странице нажмите на кнопку «Организатор». Для работы с элементами системы откроется окно «Организатор»:

1. Для сохранения элементов выделите элемент и нажмите на кнопку «Копировать >>», кнопка работает в обе стороны.
2. При нажатии на кнопку «Переименовать…» Вы можете изменить название элемента.
3. Для того чтобы удалить элемент нажмите на кнопку «Удалить…».

Данный материал рассматривается на практических тренингах на ресурсе Онлайн-курсы.

Как в проджекте изменить название проекта

MS Project. Планирование работ. Планирование ресурсов и создание назначений, планирование стоимости проекта

Анализ и оптимизация загрузки ресурсов. Анализ рисков. Согласование плана проекта

Планирование работ

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

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

Определение состава проектных работ начинается с определения этапов (или фаз) проекта. Например, в проекте Издание номера журнала могут быть выделены фазы Планирование номера, Подготовка материалов, Верстка и Предпечатная подготовка.

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

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

Скелетный план работ

План работ лучше всего составлять в представлении Gantt Chart (Диаграмма Ганга). Для добавления задачи в план проекта нужно установить курсор в таблицу слева от диаграммы и ввести название задачи в поле Task Name (Название задачи).

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

Рис. 1. Начинаем составлять план проекта Издание журнала

Добавление в план фазы не отличается от добавления задачи — любая задача автоматически становится фазой, как только у нее появляется вложенная задача, то есть задача, находящаяся на следующем уровне структуры плана. До тех пор пока у задачи нет вложенных задач, она не является фазой.
Чтобы поместить задачу на следующий (более низкий) уровень структуры, нужно установить курсор на строку с задачей и нажать на панели инструментов Formatting (Форматирование) кнопку со стрелкой вправо (или сочетание клавиш Alt+Shift+-»). Для перемещения задачи на предыдущий (более верхний) уровень структуры нужно нажать кнопку со стрелкой влево (или Alt+Shift+

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

Теперь, когда скелетный план готов и вы знаете, как работать со всеми тремя типами задач MS Project, можно переходить к добавлению в план остальных задач и подфаз. На рис. 3 видно, как стал выглядеть наш план издания журнала после того, как в него были добавлены все проектные работы. Увеличилось число не только обычных задач, но и завершающих, поскольку в некоторые фазы были добавлены подфазы, каждая из которых имеет отражающую свой результат завершающую задачу.

Рис. 3. После добавления задач фазы в плане проекта выглядят так, как им положено

Рис. 4. Так выглядит план проекта после добавления в него всех задач

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

Определение длительностей задач

Длительность задач определяется значением, введенным в колонке Duration (Длительность). Длительность фаз вводить нельзя — она рассчитывается автоматически.

При создании задач MS Project автоматически задает им длительность в 1 день, добавляя после ее обозначения вопросительный знак (см. рис. 4). Вопросительный знак обозначает, что указанная длительность — Приблизительная (Estimated) и требует дальнейшего уточнения. После того как вы отредактируете значение, вопросительный знак пропадет. Если вы хотите пометить для себя, что указанную длительность задачи стоит уточнить, то можете сами добавить вопросительный знак

После ввода длительности задачи MS Project пересчитывает дату ее окончания, прибавляя к дате начала задачи длительность и выходные дни (в соответствии с календарем проекта). Однако некоторые задачи выполняются круглосуточно и без выходных, после того как выполнение начато, например засыхание цементного раствора или выполнение расчетов компьютерной программой. В таком случае для обозначения длительности задачи используется символ е (п), соответствующий термину Elapsed days (Прошедшие дни). Например, для обозначения длительности в 14 дней в поле Duration (Длительность) нужно ввести 14ed (14пд). При вводе длительности таких задач можно применять и вопросительный знак.

Определение связей между задачами

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

Задача, влияющая на другую, называется Predecessor (Предшественник), а задача, зависящая от другой, называется Successor (Последователь). Например, Обложка готова является предшествующей задачей, а Окончательная сборка — последующей.

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

Связи могут объединять и фазы, и все принципы организации связей между задачами применимы и к фазам. При этом связи могут объединять между собой и задачи, и фазы, например фаза может начинаться по завершении задачи.

Типы связей задач

В MS Project есть четыре типа связей между задачами. Связь типа Finish-to-start (Окончание-начало), или сокращенно FS (ОН), — наиболее распространенный тип зависимости между задачами, при которой задача В не может начаться, пока не завершена задача А:

Связь типа Start-to-start (Начало-начало), или сокращенно SS (НН), обозначает зависимость, при которой задача В не может начаться до тех пор, пока не началась задача А. Например, Техническое редактирование не может начаться раньше, чем Редактирование материалов, но и для того, чтобы начать Техническое редактирование, не обязательно дожидаться окончания Редактирования материалов. С помощью такой связи обычно объединяются задачи, которые должны выполняться почти одновременно.

Связь типа Finish-to-Finish (Окончание-окончание), или сокращенно FF (00), обозначает зависимость, при которой задача В не может закончиться до тех пор, пока не закончилась задача А. Обычно такой связью объединяются задачи, которые должны выполняться почти одновременно, но при этом одна не может закончиться, пока не завершена другая. Например, сдача-приемка программы идет одновременно с исправлением ошибок (найденных в процессе сдачи-приемки), и пока исправление ошибок не завершено, сдача-приемка тоже не может завершиться.

Связь типа Start-to-Finish (Начало-окончание), или сокращенно SF (НО), обозначает зависимость, при которой задача В не может закончиться до тех пор, пока не началась задача А. Обычно такая связь используется в том случае, когда А является задачей с фиксированной датой начала, которую нельзя изменить. В таком случае дата начала последующей задачи не изменяется при увеличении длительности предшествующей.

Связь создается перетаскиванием мыши с одного отрезка диаграммы Ганта на другой, при этом по умолчанию тип связи определяется как FS. Предшествующей задачей считается та, с которой началось перетаскивание, а последующей — та, на которой перетаскивание закончилось (на последующую задачу указывает стрелка в конце связи). Для удаления связи или изменения ее типа нужно дважды щелкнуть на диаграмме и произвести соответствующие операции в открывшемся диалоговом окне.

Способы редактирования связей

Создание и редактирование связей с помощью мыши единственная возможность, предоставляемая MS Project для работы со связями. Их можно редактировать прямо в таблице, куда вводятся данные, в особой форме или в диалоговом окне определения свойств задачи. Кроме того, создавать связи можно с помощью кнопки Link Tasks (Связать задачи) стандартной панели инструментов (см. представленный ниже рисунок). Для этого нужно выделить две или больше задач и нажать эту кнопку. Задачи будут соединены последовательно связью типа Finish-to-start (Окончание-начало). Например, если выделены задачи 1, 2 и 3, то после нажатия кнопки задача 2 будет следовать за задачей 1, а задача 3 — за задачей 2. Выделив все связанные задачи и нажав кнопку Unlink Tasks (Разорвать связи задач), можно быстро удалить все связи между ними.

Редактирование связей в таблице

Чтобы в процессе ввода задач быстро указать предшественника задачи, используется колонка Predecessors (Предшественники), по умолчанию включенная в таблицу Entry (Ввод). Например, на рис. 8 представлен фрагмент этой таблицы из файла проекта Издание номера журнала, где уже введена информация о связях между задачами.

Рис. 8. Фрагмент таблицы из плана проекта с введенными связями между задачами

Связью по умолчанию является Finish-to-start (Окончание-начало), поэтому если в поле Predecessors (Предшественники) просто указать номер задачи1, это будет означать, что данная задача является предшественницей текущей. Например, предшественницей задачи Предварительная редколлегия является задача с номером 3, то есть Подготовка плана номера. Соответственно, Предварительная редколлегия начинается 01.11.01, то есть после того, как 31.10.01 завершена Подготовка плана номера.

В тех случаях, когда связь отличается от стандартной, в поле нужно указать номер предшествующей задачи и аббревиатуру, соответствующую типу связи (например, как в строках 26, 27 и 28). Если у связи есть запаздывание или опережение, то его нужно указать рядом с типом связи, используя знаки + или -. Если запаздывание или опережение используется со стандартной связью FS (ОН), то ее аббревиатуру тоже нужно указать (как в строке 12). А если у задачи есть несколько предшественниц, то связи с ними нужно указать через точку с запятой (как, например, в строке 30).

Колонка Predecessors (Предшественники) по умолчанию включена только в таблицу Entry (Ввод). Если вам покажется удобным редактировать данные о связях с ее помощью, то вы можете добавить ее в любую таблицу с информацией о задачах.

Редактирование связей в форме

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

Если же использовать в проекте разнообразные типы связей, то удобнее будет воспользоваться специальными диалоговыми окнами для работы с ними. Наиболее удобным является диалоговое окно Task Form (Форма описания задачи). Эта отображается, если, находясь в диаграмме Ганта, выбрать команду меню Window > Split (Окно > Разделить). Ее также можно вызвать из диалогового окна View > More Views (Вид > Все виды).

По умолчанию отображается форма для редактирования задействованных в задаче ресурсов и связей с предшественницами, но с помощью контекстного меню формы можно вызвать диалоговое окно Predecessors & Successors (Предшественники и последователи), в котором можно редактировать связи выбранной задачи как с предшествующими, так и с последующими задачами (рис. 9). Форма разделена на две таблицы с одинаковой структурой, содержащие колонки с номером задачи, ее названием, типом связи и величиной задержки. Левая таблица содержит информацию о предшественницах, а правая — о последующих задачах.

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

Рис. 9 Редактирование связей с помощью формы описания задачи

Чтобы удалить связи из таблицы, нужно установить курсор на строку с информацией о связи и нажать клавишу Delete. Для добавления связи нужно установить курсор на свободную строку в таблице и в раскрывающемся списке выбрать название задачи, с которой нужно связать текущую. Тип связи тоже выбирается из раскрывающегося списка.

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

Редактирование связей в диалоговом окне сведений о задаче

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

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

Рис. 10. Вкладка Predecessors (Предшественники) в диалоговом окне сведений о задаче

Рис. 11. Такой вид принял план проекта после указания длительностей задач и связей между задачами

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

Дата начала проекта

Определять ключевые даты проекта надо начинать с определения даты начала проекта.

Дата, предложенная MS Project по умолчанию, — 20.10.01. То есть если не указать задаче определенную дату начала и не связать ее с другой задачей, то MS Project приравнивает ее к дате начала проекта.

Привязывание задачи к определенной дате в MS Project осуществляется при помощи элемента Constraint (Ограничение). Используя ограничения, можно, например, указать, что задача должна начаться в определенный день или закончиться не позднее определенной даты.

В MS Project выделяется несколько типов ограничений (табл. 1) в зависимости от того, насколько они влияют на гибкость расчетов.

Два наиболее негибких ограничения в MS Project, привязывающие задачу к определенной дате, — это Must Start On (Фиксированное начало) и Must Finish On (Фиксированное окончание). Использовать негибкие ограничения нужно тогда, когда задача обязательно должна начаться или закончиться в определенный день, например, если срок исполнения задачи обусловлен договором и не может быть нарушен.

Как ограничения влияют на расписание

Когда требуется контролировать дату начала или конца задачи, можно добавить ограничение. Гибкие ограничения учитывают связи между задачами, чтобы перенести задачу как можно раньше или как можно позже, насколько позволяет связь. Например, задача с ограничением As Soon As Possible (Как можно раньше) и связью FS (ОН) будет начинаться сразу по завершении предшественницы.

Ограничения со средней гибкостью запрещают задаче начаться или окончиться до или после выбранной даты. Например, задача с ограничением Start No Later Than (Начало не позднее) на 17 марта и связью типа FS (ОН) с другой задачей может начаться в любое время, если ее предшественница закончится, например, до 15 июня, но не может быть начата после 17 марта.
Негибкие ограничения не подвергаются влиянию связей и «привязывают» задачу к выбранной вами дате. Например, задача с ограничением Must Start On (Фиксированное начало) на 10 апреля и связью типа FS (ОН) с другой задачей всегда будет находиться в расписании на 10 апреля вне зависимости от того, закончится ее предшественница раньше или позже.

Ввод ограничений

В проектах, планируемых от даты начала, по умолчанию все задачи имеют ограничение As Soon As Possible (Как можно раньше), а в проектах, планируемых от даты окончания, — As Late As Possible (Как можно позже).

Изменять ограничения по умолчанию можно, вводя дату начала или окончания задачи в колонках Start (Начало) и Finish (Окончание) в таблице Entry (Ввод) или любой другой таблице, содержащей эти колонки. После ввода даты MS Project установит ограничение в соответствии с табл. 1.
Например, на рис. 12 мы изменили дату начала задачи. Сразу после этого в поле Indicators (Индикаторы) появился значок, указывающий на наличие у задачи ограничения (вторая строка сверху, второй столбец). Кроме того, уголок измененной ячейки выделен и рядом с ячейкой отображается кнопка раскрывающегося списка.

Рис. 12. Установка ограничения путем изменения даты начала задачи в таблице

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

Пункт списка Choose different options to schedule the task (Выбрать другие параметры планирования задачи) откроет диалоговое окно для изменения параметров ограничения задачи. Пункт Keep the task constrained to (Оставить ограничение на) сохранит текущее ограничение и скроет его значок и список. А вариант Undo the constraint on (Отменить ограничение на) and allow MS Project to reschedule the task (и разрешить MS Project перепланировать задачу) отменит изменения.

Вводя данные в таблицу, нельзя установить негибкие типы ограничений. Для этого, а также для редактирования установленных ограничений предназначена вкладка Advanced (Дополнительно) в диалоговом окне сведений о задаче (рис. 13). Чтобы вызвать это диалоговое окно, нужно сделать двойной щелчок в таблице на строке задачи.

Тип ограничения выбирается в раскрывающемся списке Constraint type (Тип ограничения), а дата, которой ограничивается начало или окончание задачи, указывается в поле Constraint date (Дата ограничения).

Рис. 13. Настройка ограничений в диалоговом окне сведений о задаче

Иногда для отмены ограничения нужно удалить введенную дату в поле Constraint date (Дата ограничения). Но MS Project не дает оставить это поле пустым, и поэтому для удаления даты из поля нужно заменить ее на текст NA (НД).

Изменять ограничения задачи можно в любой из ее таблиц. Для этого в таблицу нужно добавить столбцы Constraint Date (Дата ограничения) и Constraint Type (Тип ограничения). Использовать эти столбцы удобно в фильтрах и при настройке стилей отрезков. Например, в файле constraint.mpp приведен пример форматирования диаграммы Ганта, при котором отрезки задач со средними и негибкими ограничениями выделены особым цветом.

Крайние сроки

Deadline (Крайний срок) — дата, обозначающая крайний срок исполнения задачи. Отличие использования крайнего срока от ограничений заключается в том, что наличие этой даты не влияет на расчет графика проекта. Если для задачи указан крайний срок, то на диаграмме Ганта отображается соответствующая отметка, и если выполнение задачи не укладывается в этот срок, то в колонке Indicators (Индикаторы) появляется особый значок.

Для ввода крайнего срока задачи нужно воспользоваться вкладкой Advanced (Дополнительно) в диалоговом окне сведений о задаче (см. рис. 13). Крайний срок исполнения задачи определяется в одноименном поле, расположенном над полем выбора типа ограничения. Дату крайнего срока можно ввести или выбрать в календаре, а для удаления этой даты нужно ввести в поле NA (НД), как на рис. 13.

Когда вводить ограничения в план проекта

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

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

Планирование ресурсов и создание назначений, планирование стоимости проекта

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

Планирование ресурсов начинается с определения состава ресурсов, то есть составления списка людей и оборудования, необходимого для выполнения проектных работ. Работа со списком ресурсов осуществляется в представлении Resource Sheet (Лист ресурсов), и наиболее удобной для ввода данных является таблица Entry (Ввод).

Для добавления нового ресурса в список нужно установить курсор в поле Resource Name (Название ресурса) и ввести его название. Затем в поле Туре (Тип) нужно выбрать один из двух пунктов раскрывающегося списка: Work (Трудовой) или Material (Материальный). Первый вариант нужно выбрать, если ресурс — сотрудник, а второй — если оборудование. До тех пор пока не установлено значение этого поля, другие поля таблицы редактировать не удастся, а после того как значение выбрано, многие поля заполняются стандартными значениями.

Поле Material Label (Единицы измерения материалов) можно редактировать только для материальных ресурсов. В него вводятся единицы измерения ресурса, например Коробка для ресурса Бумага для типографии или Бочонок для ресурса Краска для вывода пленок.

Определение рабочего времени ресурсов

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

Определение времени участия в проекте и максимальной загрузки

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

Кроме того, по умолчанию все сотрудники, которых вы добавляете для участия в проекте, считаются доступными на 100%, то есть при планировании MS Project будет считать, что они могут работать над выполнением проектных задач полный рабочий день. Однако в жизни все бывает сложнее, и часто сотрудник одновременно задействован в нескольких проектах. В таком случае нужно определить степень его максимальной загрузки в проекте. Например, если сотрудник может работать в вашем проекте не больше половины рабочего дня, то его максимальная загрузка равняется 50%.

Просматривать информацию о доступности и максимальной загрузке можно и в таблице, добавив в нее поля Available From (Доступен с), Available To (Доступен до) и Max Units (Максимальная нагрузка). При этом отображаемые данные будут соответствовать данным из первой строки в таблице Resource Availability (Доступность ресурса). Даты в таблице редактировать нельзя, а информацию о максимальной нагрузке можно. Использовать таблицу для просмотра и редактирования удобно только в том случае, если ресурсы имеют по одному интервалу доступности. Например, ресурс Сергеева выделен в наш проект только наполовину, поэтому его доступность можно определить прямо в таблице.

Персональное время работы

По умолчанию в MS Project считается, что все сотрудники работают по основному календарю проекта. Но часто отдельные сотрудники или даже целые отделы имеют собственный календарь.

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

Для определения рабочего времени, по которому работает ресурс, а также его личных рабочих и выходных дней предназначена вкладка Working Time (Рабочее время) в диалоговом окне сведений о ресурсе (рис. 16). Выбор календаря осуществляется с помощью раскрывающегося списка Base calendar (Базовый календарь).

Рис. 16. Определение рабочего времени ресурса

Например, на рис. 16 мы устанавливаем рабочее время для сотрудника отдела предпечатной подготовки Борисова. Соответственно, в качестве базового выбран календарь Отдел предпечатной подготовки. Если после этого выбрать один из рабочих дней календаря, то справа от него можно просмотреть рабочее время: с 8 до 12, с 13 до 17 и с 18 до 23.

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

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

Для выбора ресурсов, обеспечивающих выполнение задач, удобнее всего воспользоваться представлением Task Usage (Использование задач. Для создания назначения нужно дважды щелкнуть на задаче в списке и в открывшемся диалоговом окне сведений о задаче выбрать вкладку Resources (Ресурсы).

Рис. 17. Диалоговое окно выравнивания загрузки ресурсов

Вкладка содержит таблицу, состоящую из двух колонок (рис. 17), в одной из которых, Resource Name (Название ресурса), указывается название задействованных ресурсов, а во второй, Units (Единицы), — сколько ресурсов выделяется на задачу.Нематериальные ресурсы измеряются в процентах или десятичных числах, где под 100%, или 1, понимается полная задсйствованность ресурса в выполнении задачи (сотрудник будет.

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

Рис. 18. Распределение затрат после назначения ресурсов на задачу

Задачи в плане проекта могут быть трех типов: Fixed Duration (Фиксированная длительность), Fixed Work (Фиксированные трудозатраты) или Fixed Units (Фиксированный объем ресурсов). Тип задачи выбирается на вкладке Advanced (Дополнительно) в диалоговом окне сведений о задаче (рис. 19) и определяет, как редактирование одного из свойств задачи — длительности, трудозатрат или назначений — будет влиять на два других свойства.

Рис. 19. Тип задачи определяется в диалоговом окне сведений о задаче

От того, какой тип задачи выбран, зависит, значение какого из трех свойств фиксируется. Например, если вы определите тип задачи Fixed Duration (Фиксированная длительность), то изменение трудозатрат или числа назначенных на исполнение задачи сотрудников не изменит ее длительность.

Таблица 12. Взаимосвязь свойств для задач разных типов

Изменение объема ресурсов

Изменение длительности приводит к пересчету

Фиксированный объем ресурсов

Фиксированный объем работ

В дополнение к указанию типа задачи можно использовать признак фиксированного объема работ. Этот признак можно добавить, установив флажок Effort driven (Фиксированный объем работ) рядом со списком типов задач если задача не относится к типу Fixed Work (Фиксированные трудозатраты).

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

Фиксация объема работ не учитывается при первом назначении ресурсов на задачу и влияет на логику работы MS Project только после первого назначения. Кроме того, признак фиксации объема работ не учитывается, когда вы изменяете длительность, трудозатраты или единицы уже назначенных ресурсов.

Например, когда на задачу фиксированной длительности 5 дней назначался второй сотрудник, трудозатраты увеличивались с 40 часов до 80. Если же задача будет фиксированной длительности и фиксированного объема работ, то добавление второго сотрудника не повлияет на трудозатраты, а приведет к понижению загрузки первого сотрудника до 50%, и второй сотрудник будет также задействован на 50% (рис. 20).

Рис. 20. При назначении дополнительных ресурсов на задачу уменьшается процент их загрузки

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

Рис. 21. При выделении дополнительных ресурсов сокращается длительность задачи

Каждое из связанных с задачей назначений имеет набор свойств, с помощью которых его можно настроить так, чтобы оно в большей степени соответствовало требованиям вашего проекта. Настройка свойств назначения осуществляется в диалоговом окне Assignment Information (Сведения о назначении), открывающемся по двойному щелчку на назначении в таблице представления Task Usage (Использование задач).

Диалоговое окно содержит три вкладки, из которых на этапе составления плана проекта нам понадобится лишь первая, General (Общая). На ней (рис. 22) можно изменить задействованный в назначении ресурс, указав новое название в поле Resource (Ресурс), процент участия, выбрав нужную величину в счетчике Units (Единицы), или трудозатраты, указав их в счетчике Work (Трудозатраты). Но самое важное в данном диалоговом окне не это, а возможность определить точные даты участия ресурса в задаче и профиль загрузки.

Рис. 22. Диалоговое окно сведений о назначении

Даты начала и окончания назначения

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

У задач с фиксированной длительностью и фиксированным объемом ресурсов это приводит к уменьшению трудозатрат при сохранении длительности. При этом перерасчет трудозатрат ресурса происходит по формуле трудозатраты = длительность назначения х процент загрузки. Поэтому если вы хотите, чтобы при уменьшении длительности назначения трудозатраты ресурса сохранились, нужно увеличить процент его загрузки. Это можно сделать либо в диалоговом окне сведений о назначении, либо на вкладке Resources (Ресурсы) в диалоговом окне сведений о задаче.

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

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

Анализ и оптимизация загрузки ресурсов, то есть равномерное распределение работы между ресурсами, — одна из наиболее сложных операций, осуществляемых при составлении проекта в MS Project.

Есть несколько методик планирования стоимости проекта: по аналогии, «сверху вниз», по параметрам и «снизу вверх». Определение стоимости проекта по аналогии (analogous estimating) можно применять, когда планируемый проект аналогичен ряду других, выполнявшихся в организации ранее. В таком случае общая стоимость проекта определяется исходя из накопленного опыта, а затем общая стоимость распределяется между задачами.

Этот метод наименее точен, но его применение занимает меньше всего времени. Как правило, стоимость проекта оценивается таким образом только на начальном этапе планирования, когда объем работ еще окончательно не определен и нельзя использовать более точные методики. Чтобы использовать этот метод в MS Project, достаточно вручную заполнить в таблице соответствующие поля (о них пойдет речь в этом уроке).

Определение стоимости проекта по параметрам (parametric modeling) является довольно популярной методикой. Типичным примером является оценка стоимости строящегося дома по площади или определение стоимости мебели по погонным метрам.

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

Методика определения стоимости проекта «снизу вверх» (bottom-up estimating) заключается в расчете стоимости отдельных задач проекта и формировании общей стоимости проекта из суммарной стоимости всех работ.

Именно эта методика является наиболее точной, и именно на ее использование ориентирована программа MS Project. Правда, для ее применения требуется больше всего времени, поскольку ее точность во многом зависит от степени детализации состава работ и ресурсов..

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

Планирование стоимости в MS Project

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

Стоимость ресурсов

Стоимость использования ресурса определяется на вкладке Costs (Затраты) в диалоговом окне сведений о ресурсе. На этой вкладке в разделе Cost rate table (Таблицы норм затрат) расположены пять таблиц норм затрат с одинаковой структурой, переключаться между которыми можно с помощью вкладок А, В, С, D и Е (рис. 23).

Рис. 23. Определение стоимости ресурса. Редактируем таблицу норм затрат А

Иногда ставка ресурса (например, зарплата или плата за аренду материального ресурса) изменяется во время исполнения проекта. Чтобы предусмотреть изменения оплаты ресурса в плане проекта, таблица содержит колонку Effective Date (Дата действия). В ней можно указать дату, начиная с которой действительны параметры оплаты выбранного ресурса, указанные в одном ряду с ней. Ставки, указанные в первом ряду таблицы, действуют со дня начала проекта, поэтому поле Effective Date (Дата действия) в нем заполнить нельзя.

Например, на рис. 14.1 мы ввели ставку использования ресурса Иванов, равную 1000$/то (1000$/мес) с начала проекта и 1100$/то (1100$/мес) с 01.03.2002. Это значит, что при расчете стоимости назначения Иванова начиная с 01.03.2002, программа будет использовать новые ставки. Результат этой настройки виден на рис. 24. Задача В с теми же трудозатратами (5 дней), что и А, стоит дороже потому, что начинается после 1 марта 2002 года и расчет стоимости ресурса происходит по новым ставкам.

Рис. 24. Начиная с 1 марта ставки оплаты ресурса вырастают

Во втором и далее рядах таблицы можно указывать ставки как в числовом виде, так и в процентном отношении от ставок в ряду выше. Например, для увеличения ставки на 10% от предыдущей суммы нужно ввести +10%, а для уменьшения —10%.

Стоимость назначений

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

Стоимость задачи складывается из суммарной стоимости назначений и ее фиксированных затрат. Фиксированные затраты (Fixed Cost) на задачу — это затраты, не связанные с использованием проектных ресурсов. Например, для задачи «Подготовка проекта дома» фиксированными затратами будут $10 на подготовку брошюры с чертежами, предоставляемыми заказчику.

Методы начисления затрат

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

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

Для материальных ресурсов метод начисления затрат стоит выбирать исходя из плана приобретения материалов для задачи. Если вы планируете приобрести сразу все необходимые для выполнения задачи материалы, то нужно использовать метод начисления в начале, а если материалы приобретаются по мере надобности, то затраты тоже должны начисляться пропорционально. Например, в нашем проекте Фотопленка приобретается сразу, до начала задачи, а дорогостоящая Краска для вывода пленок — по мере надобности.

Метод начисления фиксированных затрат определяется в зависимости от того, когда вы собираетесь их осуществить. Например, в задаче «Подготовка проекта дома» брошюра с чертежами будет готовиться в конце, значит, и затраты должны быть начислены по завершении работы.

Рис. 25. Деньги на оплату работы будут резервироваться в начале ее выполнения

Метод начисления затрат может определяться как для ресурса, так и для фиксированных затрат задачи. Метод начисления фиксированных затрат задачи определяется в столбце Fixed Cost Accrual (Начисление фиксированных затрат) для каждой задачи.

Анализ и оптимизация плана проекта

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

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

Анализ и выравнивание загрузки ресурсов

Чтобы определить равномерность загрузки ресурсов, нужно открыть представление Resource Sheet (Лист ресурсов). В нем все ресурсы, загрузка которых превышает их доступность, выделены красным цветом, а в колонке Indicators (Индикаторы) рядом с их названиями отображается специальный значок (рис. 26).

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

Рис. 26. Названия ресурсов с превышением загрузки выделены цветом

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

Для выравнивания загрузки ресурсов в Microsoft Project можно воспользоваться автоматизированными средствами, а можно перераспределить загрузку вручную. Как правило, используются оба способа, поскольку команда автоматизированного выравнивания использует только второй из перечисленных методов выравнивания и поэтому обычно не может выровнять загрузку всех ресурсов.

Автоматическое выравнивание загрузки ресурсов

Диалоговое окно выравнивания загрузки ресурсов открывается с помощью команды меню Tools > Level Resources (Сервис > Выравнивание загрузки ресурсов). В разделе Leveling calculations (Вычисления для выравнивания) определяются общие параметры выравнивания загрузки (рис. 27). Переключатели Automatic (Выполнять автоматически) и Manual (Выполнять вручную) определяют, как будет осуществляться выравнивание: непосредственно при создании назначений (первый вариант) или при нажатии кнопки Level Now (Выровнять) в этом диалоговом окне (второй).

Рис. 27. Диалоговое окно выравнивания загрузки ресурсов

Раскрывающийся список Look for overallocations (Поиск превышений доступности) определяет величину временного блока, в рамках которого программа будет искать превышение доступности. Например, если сотрудник назначен на две 4-часовые задачи, начинающиеся в 8 утра, то при поиске превышения доступности по часам (пункт списка Hour by Hour (По часам)) одна из задач будет отложена на 4 часа, чтобы ни в одном из часов дня не было превышения доступности. Если же в списке выбран пункт Day by Day (По дням), то расписание не изменится, поскольку в пределах дня объем работы не превышает нормы.

При установленном флажке Clear leveling values before leveling (Очистка данных предыдущего выравнивания перед новым выравниванием) перед новым выравниванием.

Ручное выравнивание ресурсов

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

Согласование плана проекта

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

Готовый план проекта нужно распространить для утверждения. Есть несколько способов это сделать: можно разослать файл в формате .mрр о электронной почте, включить фрагменты данных из файла проекта в другие документы офисных форматов, полностью конвертировать файл в другой формат и, наконец, можно распространить файл в распечатанном виде.

Рассылка плана по электронной почте

Чтобы отослать план по электронной почте, нужно выбрать команду меню File> Send To > Mail Recipient (as Attachment) ( Файл > Отправить > Сообщение ( как вложение )). В результате создается сообщение, к которому прикреплен файл проекта, и от вас потребуется лишь выбрать адресатов письма и отправить его.

Отправка по маршруту

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

Для автоматизации пересылки файла в определенной очередности можно создать маршрут, по которому файл будет автоматически перенаправляться от одного руководителя к другому. Для этого предназначено диалоговое окно настройки маршрута открываемое с помощью команды меню File > Send To > Routing Recipient (Файл > Отправить > По маршруту).

После того как вы настроите параметры отправки файла по маршруту, вместо этой команды в меню появится команда Other Routing Recipient (Другой адресат).

Публикация на сервере Microsoft Exchange

Если в организации используется сервер Microsoft Exchange и компьютер подключен к нему, то в подменю File > Send To (Файл > Отправить) будет доступна команда Exchange Folder (Папка Exchange). При щелчке на этой команде откроется диалоговое окно со списком папок, в которые вы можете поместить файл. Для сохранения файла в общей папке у вас должны быть соответствующие разрешения, полученные от администратора системы.

Экспорт плана в файлы других форматов

MS Project содержит удобные команды для экспорта данных в другие форматы, среди которых есть как форматы документов семейства Microsoft Office (Excel и Access), так и межплатформенные (HTML и XML). Начнем обучение экспорту данных из MS Project именно с универсальных форматов.

Экспорт данных в HTML

Экспорт данных в HTML используется очень часто для публикации информации о проекте на веб-странице. Именно поэтому для сохранения файла в этом формате предназначена отдельная команда Save As Web Page (Сохранить как вебстраницу) в меню File (Файл).

Для экспорта проектных данных в XML достаточно выбрать этот формат в диалоговом окне, вызываемом командой меню File > Save As (Файл > Сохранить как). Программа сохранит в этом формате всю проектную информацию, включая как план проекта, так и значения всех параметров, список календарей, настраиваемых полей и пр. — одним словом, файл проекта целиком. Правда, следует иметь в виду, что файлы получаются большими (например, XML-файл с данными нашего небольшого проекта занимает около 700 Кбайт).

Чтобы начать экспорт плана проекта в Microsoft Excel, в диалоговом окне File > Save As (Файл > Сохранить как) нужно выбрать для сохранения файла формат *.xls. MS Project может сохранить данные в одном из двух форматов — в формате рабочей книги (Workbook) Excel или сводной таблицы (PivotTable), и мастер экспорта данных будет действовать в зависимости от выбора формата.

MS Project позволяет экспортировать данные в любую базу данных, имеющую интерфейс ODBC. Для этого нужно средствами Windows создать подключение к этой базе данных через ODBC и затем в диалоговом окне File > Save As (Файл > Сохранить как) нажать кнопку ODBC и выбрать созданное подключение в списке.

MS Project позволяет экспортировать данные в текстовые форматы (txt, csv). Чтобы экспортировать план проекта в один их этих форматов, нужно выбрать в списке типов файлов диалогового окна, вызываемого командой меню File > Save As (Файл > Сохранить как), пункт Text (Текст) или CSV. После этого запускается мастер экспорта.

Анализ опасностей, которые могут возникнуть при выполнении составленного плана, — один из самых интересных и сложных этапов планирования проекта. От того, как проведен анализ, зависит, будет ли проект успешно завершен. В этом уроке вы научитесь определять риски с помощью MS Project, описывать их и разрабатывать стратегии их смягчения. Для проведения анализа мы задействуем все имеющиеся в нашем арсенале средства: настраиваемые поля, формулы, стандартные и настраиваемые фильтры, сортировки. Но и это не все — в конце урока мы освоим средства анализа проектных данных в Microsoft Excel и с их помощью проведем исследование нашего проекта.

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

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

Часто в процессе определения рисков невозможно детально проанализировать весь план проекта в разумное время (например, если план состоит из нескольких сотен задач). В таких случаях в первую очередь нужно анализировать риски у задач, которые находятся на критическом пути проекта или могут стать критическими. Чтобы определить, какие задачи могут стать критическими, можно воспользоваться оптимистической и пессимистической диаграммами Ганта, полученными в результате анализа методом PERT.

При определении рисков информацию нужно заносить в план проекта. Для этого нужно подготовить настраиваемые поля Мы переименовали поле для задач Text2 (Текст2) в Описание риска, а поле для задач Texts (ТекстЗ) — в Вероятность осуществления риска, причем для последнего мы создали список значений: Высокая, Средняя и Низкая, что позволит быстро заполнять это поле. Кроме того, на основании таблицы Entry (Ввод) для задач мы создали таблицу Ввод информации о рисках и оставили в ней лишь необходимый набор полей. И наконец, на базе таблицы мы создали два представления: Риски, в котором эта таблица находится рядом с диаграммой Ганта, и комбинированное представление Риски2, в верхней части которого находится представление Риски, а в нижней — Task Form (Форма задач). Теперь можно переходить к определению рисков.

Риски определяются для трех аспектов проекта: расписания, ресурсов и бюджета. Так выявляются события, осуществление которых может помешать завершить проект в срок или создать нехватку ресурсов или денег в определенный момент его выполнения. Если при определении риска становится ясно, как уменьшить его, то нужно сразу же вносить соответствующие изменения в план проекта.

Разработка стратегии смягчения рисков

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

План сдерживания рисков (mitigation plan) состоит из работ, которые включаются в план проекта и, будучи выполненными, существенно снижают вероятность осуществления риска. План реакции на риски (contingency plan) определяется в плане проекта, но не оформляется в виде задач до осуществления риска. Если риск осуществляется, нужные задачи добавляются в план проекта.

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

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

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

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

Часто в процессе определения рисков невозможно детально проанализировать весь план проекта в разумное время (например, если план состоит из нескольких сотен задач). В таких случаях в первую очередь нужно анализировать риски у задач, которые находятся на критическом пути проекта или могут стать критическими.

При определении рисков информацию нужно заносить в план проекта.

Риски определяются для трех аспектов проекта: расписания, ресурсов и бюджета. Так выявляются события, осуществление которых может помешать завершить проект в срок или создать нехватку ресурсов или денег в определенный момент его выполнения. Если при определении риска становится ясно, как уменьшить его, то нужно сразу же вносить соответствующие изменения в план проекта.

Риски в расписании

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

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

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

Задачи с предварительными длительностями

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

Главная проблема в планировании таких задач заключается в том, что их длительность не известна заранее, поскольку нет опыта в их выполнении. Поэтому обычно при планировании длительность этих задач остается предварительной (estimated). Такие задачи можно обнаружить в плане проекта с помощью стандартного фильтра Tasks With Estimated Durations (Задачи с оценкой длительности).

Слишком короткие задачи

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

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

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

Рис. 16.1. Настраиваем фильтр для отбора коротких задач

Фильтр отбирает задачи, у которых длительность меньше либо равна одному Дню или значение настраиваемого поля Durationl (Длительность!) равно значению настраиваемого поля Duration2 (Длительность2). (Эти настраиваемые поля используются при анализе по методу PERT для хранения информации об оптимистической и ожидаемой длительности.) Среди задач, отобранных по одному из этих критериев, фильтр отбирает те задачи, у которых значение поля Milestone (Веха) равно No (Нет), то есть задачи, не являющиеся вехами. Результат применения фильтра в нашем проекте представлен на рис. 16.2 Коротких задач оказалось только три, из них две Редколлегии, на которые отведено по 3 часа, и Окончательная сборка журнала, на которую отведено 2 дня. Кроме того, оптимистическая и ожидаемая длительности совпали у (разы Редактирование материалов)

Рис. 16.2. Просматриваем короткие задачи с помощью фильтра

После того как короткие задачи отобраны, определим реалистичность отведенного на них времени. В нашем случае 3 часа на редколлегию — это вполне нормально. Два дня на сборку журнала — срок оптимистичный, но учитывая, что работать будут двое, справиться вполне можно. К тому же, они задействованы на 25% (то есть за 2 дня отработают всего 6 часов), значит, если они не будут укладываться в срок, то будет возможность увеличить загрузку и успеть завершить задачу вовремя.

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

Слишком длинные задачи и задачи с большим числом ресурсов

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

Обнаружить в плане задачи с большой длительностью очень просто. Достаточно воспользоваться автофильтром и отфильтровать задачи по столбцу Duration (Длительность), отобрав задачи с длительностью, превышающей, например, 5 пли 10 дней

Оптимистическая длительность может совпадать с ожидаемой не точцо, а с определенным допущением, например различаться на 1 или 2 часа. Чтобы такие задачи тоже можно было обнаружить, в этом же файле мы создали фильтр Слишком короткие задачи — 2, в котором можно внести это допущение.

А вот автоматически отобрать задачи с большим числом ресурсов нельзя, поскольку в MS Project нет специального столбца «внутренней» таблицы, в котором было бы указано число ресурсов, назначенных на задачу. Поэтому нам, как обычно, придется воспользоваться настраиваемым полем Переименуем поле задач Number2 (Число2) в Число ресурсов и поместим в него формулу Len ([Resource Names]) (Len ([Названия ресурсов])) (рис. 16.3).

Рис. 16.3. Настраиваем формулу для определения числа ресурсов

Функция Len определяет длину текстовой строки, переданной ей в качестве параметра. В нашем случае этой строкой является значение поля Resource Names (Названия ресурсов). Чем больше ресурсов назначено на задачу, тем длиннее строка и тем больше будет значение поля Число ресурсов.

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

После завершения настройки поля отсортируем задачи по этому полю. Для этого с помощью команды меню Project к Sort > Sort by (Проект > Сортировка > Сортировать по) откроем диалоговое окно сортировки и выберем созданное поле в качестве критерия. Сортировать задачи будем по убыванию, чтобы задачи с наибольшим числом ресурсов оказались в верхней части списка, и сбросим флажок Keep outline structure (Сохранить структуру), чтобы сортировка осуществлялась в рамках всего проекта, а не в рамках отдельных фаз

На рис. 16.5 задачи в верхней части представления отсортированы по числу ресурсов. В задачах в начале списка задействовано по 4-5 сотрудников, в задачах чуть ниже — по 2-3 человека. В нижней части представления отображена Форма задач (Task Details Form), в которой можно просмотреть детальную информацию о задаче, выбранной в верхней части представления.

Определив задачи с большими длительностями или большим числом назначенных ресурсов, нужно разбить их на серию более коротких задач или превратить в фазы, поскольку, как правило, в рамках длинной задачи решается несколько коротких. Еще одно подтверждение тому — много назначений на задачу: как правило, над решением одной задачи работает не больше двух человек, а если их назначено больше, то это значит, что задача может быть разделена на несколько составляющих.

Рис. 16.4. Сортируем задачи по созданному полю

Рис. 16.5. План проекта после сортировки задач по числу ресурсов

Список всех предшественниц задачи приведен в поле Predecessors (Предшественники), причем номера задач-предшественниц разделены точками с запятой. И если в этом поле встречается хотя бы одна точка с запятой, значит, у задачи есть как минимум две предшественницы. Поэтому наш фильтр будет отбирать те задачи, у которых в поле Predecessors (Предшественники) содержится точка с запятой.

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

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

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

Рис. 16.9. Анализ зависимостей у задачи Верстка обложки

Создавать такие резервы можно, когда дата начала одной из задач-предшественниц связана с другой задачей или имеет ограничение, а у другой задачи такого ограничения нет. Если перенести задачу, дату начала которой ничто не ограничивает, на более ранний срок, то это создаст ей временной резерв.

Задачи с внешними зависимостями

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

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

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

Чтобы эти задачи можно было определить на формальной основе, при создании списка задач можно добавить настраиваемое поле типа Flag (Флаг) и изменять его значение для задач с внешними зависимостями.

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

Рис. 16.10. Заносим информацию о риске в план проекта

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

Использование неопытных сотрудников

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

Чтобы выделить сотрудников без опыта работы, настроим столбец FlagZ (Флаг2), назвав его Опыт есть, и определим отображение красного индикатора для тех случаев, когда значением поля является No (Нет), и зеленого — когда значением является Yes (Да). Добавим настроенное поле в представление Resource Sheet (Лист ресурсов) и установим в нем значение No (Нет) для тех ресурсов, у которых нет опыта работы. В нашем случае в проекте задействованы только два ресурса без опыта: Тарасова и Жуков (рис. 16.11).

Теперь разделим окно, отобразим в нижней части представление Task Usage (Использование задач) и откроем таблицу Ввод информации о рисках. Для того чтобы в ней отобразились только те задачи, в которых задействованы неопытные сотрудники, выделим этих сотрудников в списке в верхнем представлении, щелкнув на их фамилиях при нажатой клавише Ctrl (рис. 16.12).

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

Рис. 16.11. Ресурсы без опыта отмечены красными индикаторами

Рис. 16.12. Вводим информацию о рисках для задач, где задействованы сотрудники без опыта работы

Ресурсы с большим объемом работы

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

Определить ресурсы с большим числом назначений можно с помощью представления Resource Usage (Использование ресурсов). Откроем в этом представлении таблицу Work (Трудозатраты) и отберем для отображения только человеческие ресурсы, воспользовавшись фильтром Resources — Work (Ресурсы — трудовые). Затем отсортируем ресурсы по убыванию по колонке Work (Трудозатраты). Теперь участники проекта с наибольшей загрузкой отображаются в начале списка.

Для того чтобы просмотреть, какое место в плане проекта занимают назначения наиболее занятых сотрудников, разделим окно и в нижнем представлении отобразим диаграмму Ганта. Теперь при выборе ресурса в верхнем представлении в нижнем отображаются все его назначения, как в таблице, так и на диаграмме (рис. 16.13).

Рис. 16.13. Просматриваем задачи, в которых задействованы наиболее загруженные ресурсы

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

Чтобы внести в план информацию о ресурсных рисках и использовать ее в дальнейшем при разработке стратегии смягчения рисков, изменим настраиваемые поля для ресурсов Text2 (Текст2) и Texts (ТекстЗ). Переименуем их в Описание риска и Вероятность осуществления риска. Поскольку во втором поле можно использовать список значений, уже составленный нами в аналогичном поле для задач, импортируем его с помощью кнопки Import Custom Field (Импорт настраиваемого поля).

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

Рис. 16.14. Вводим информацию о ресурсных рисках

Наиболее «рискованными» ресурсами проекта являются Иванов, Петров и Сидоров, задействованные в самом большом числе задач, большинство из которых лежит на критическом пути. Соответственно, в поле Описание риска введем Срыв работ из-за недоступности ресурса, а в поле Вероятность осуществления выберем значение Высокая.

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

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

Чтобы определить такие ресурсы и внести в план информацию о рисках, связанных с их использованием, откроем представление Resource Sheet (Лист ресурсов) и отобразим в нем таблицу Ввод информации о рисках ресурсов. Затем нужно определить риски с уникальными знаниями и ввести в таблицу описание рисков и вероятность их осуществления.

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

Рис. 16.16. Вводим в план проекта описание рисков для сотрудников с уникальными знаниями и материалов с единственным поставщиком

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

В нашем проекте задействовано не так много ресурсов, и поэтому просмотреть весь список и внести информацию о рисках можно довольно быстро. Если же проект, в котором вы оцениваете ресурсные риски, содержит большое число ресурсов, то при их анализе стоит воспользоваться стандартными фильтрами Resources — Material (Ресурсы — материальные) и Resources — Work (Ресурсы — трудовые), с помощью которых можно отобрать для анализа только сотрудников или только материалы.

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

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

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

Наш анализ исходит из предположения, что при увеличении длительности задачи объем работ всех назначенных ресурсов и, соответственно, цена возрастают пропорционально. Например, если задача длится 2 дня и стоит $100, то при увеличении длительности до 4 дней стоимость возрастет до $200. Этот метод оценки не очень точен, но он и не претендует на точность. Ведь при планировании рисков сложно предсказать, как именно будут задействованы ресурсы при увеличении длительности назначения. Задача анализа — определить возможный бюджет проекта при неблагоприятном развитии событий и задачи, цена которых сильно увеличится при осуществлении рисков.

Переименуем таблицу PA_PERT Entry (Ввод PA_PERT) в Бюджетные риски. Затем на основе фильтра Milestones (Вехи) создадим фильтр Not Milestones, изменив условие в исходном фильтре на противоположное. После его применения на плане не будут отображаться задачи с нулевой длительностью.

При анализе PERT программа автоматически помещает значения оптимистической, ожидаемой и пессимистической длительности в поля Durationl-З (Длительность1-3). Если разделить длительность каждого из типов на длительность, внесенную в план проекта (поле Duration (Длительность)), то в результате мы получим коэффициент, который можно использовать для расчета стоимости. Например, если длительность задачи в плане составляет 2 дня, а пессимистическая длительность составляет 4 дня, то коэффициент будет равняться 2. Соответственно, пессимистическая стоимость задачи будет равняться стоимости, умноженной на этот коэффициент, и в случае неблагоприятного развития событий будет в два раза больше запланированной.
Настроим три поля типа Cost (Затраты) для расчета стоимости каждого из типов по этой формуле. На рис. 16.17 представлена формула для поля Cost3 (ЗатратыЗ), переименованного в Opt. Cost. В формуле используется поле Durationl (Длительность!), хранящее оптимистическую длительность задач.

После настройки всех трех полей таблица примет вид, представленный на рис. 16.18. Видно, что в случае неблагоприятного развития событий стоимость проекта может увеличиться более чем на $15 000 (вычитаем из пессимистической стоимости планируемую стоимость), что составляет лишь 15,5% от общей стоимости проекта. Но у отдельных задач или фаз отклонение цены может быть значительным, и нужно проанализировать план, чтобы понять, у каких задач в случае осуществления риска стоимость может существенно измениться. Для этого рассчитаем для каждой задачи процент отклонения пессимистической стоимости от запланированной.

Рис. 16.17. Настройка поля для расчета оптимистической стоимости проекта

Рис. 16.18. Варианты стоимости проекта при разных вариантах развития событий

Переименуем поле Numbers (ЧислоЗ) в Разница стоимости и введем в него формулу, представленную на рис. 16.19. Сначала определяется разница между пессимистической ценой и запланированной, для чего из поля Cost5 (Затраты5), где хранится пессимистическая стоимость, рассчитанная в предыдущем примере, вычитается планируемая стоимость, хранящаяся в поле Cost (Затраты). Затем мы определяем, какой процент от запланированной стоимости составляет полученная разность. Для этого полученное в результате вычитания число делится на запланированную стоимость и результат умножается на 100.

Чтобы полученный результат было легче обрабатывать, настроим отображение индикаторов для поля (рис. 16.20). Те задачи, у которых отклонение при неблагоприятном развитии событий составит более 50%, пометим красным индикатором. Задачи с отклонением больше 25% пометим желтым, а с отклонением больше или равным 10% — зеленым. Задачи с отклонением менее 10% пометим флажком (эта настройка не видна на рис. 16.20). Установим флажок Show data values in ToolTips (Показывать значения данных во всплывающих подсказках), и тогда значение поля будет отображаться при наведении курсора на индикатор.

Рис. 16.19. Формула для определения процента отклонения стоимости при пессимистическом сценарии

Рис. 16.20. Настройка графических индикаторов для отображения данных об отклонении стоимости

Определение количественных характеристик отклонений (чтобы решить, какое отклонение считать слишком высоким, а какое приемлемым) зависит от принятых в организации стандартов. В нашем случае будем считать отклонение менее 10% приемлемым, а более 50% — слишком высоким и нуждающимся в коррекции.

На рис. 16.21 представлена таблица Бюджетные риски после того. как настройка поля завершена. К таблице применен фильтр Not Milestones для отбора всех задач, кроме вех. Задачи плана, помеченные красным индикатором, нуждаются в коррекции: нужно или уменьшить пессимистическую оценку стоимости для них, или увеличить планируемую стоимость.

Рис. 16.21. Анализируем отклонение по стоимости при помощи индикаторов

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

Разработка стратегии смягчения рисков

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

План сдерживания рисков (mitigation plan) состоит из работ, которые включаются в план проекта и, будучи выполненными, существенно снижают вероятность осуществления риска. План реакции на риски (contingency plan) определяется в плане проекта, но не оформляется в виде задач до осуществления риска. Если риск осуществляется, нужные задачи добавляются в план проекта.

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

План сдерживания рисков

Для сдерживания рисков в план нужно включить работы, выполнение которых понизит вероятность осуществления риска. Например, у задачи Статьи поступили в редакцию есть высокий риск задержки из-за того, что авторы сдадут статьи позже срока. Чтобы снизить его, добавим в план задачу Проверка состояния статей, выполняя которую редакторы разделов свяжутся с авторами и напомнят им о сроках сдачи текстов (рис. 16.22). При этом длительность проекта не увеличилась.

Рис. 16.22. Добавляем задачу для обеспечения своевременной поставки текстов

Аналогично можно предотвратить и ресурсные риски. Например, чтобы избежать риска срыва работ из-за несвоевременной поставки материалов, добавим в план работ задачу Оформить предварительный заказ материалов для типографии, которая должна быть выполнена за три дня до завершения верстки журнала (рис. 16.23). Добавление этой задачи тоже не повлияло на длительность проекта.

Рис. 16.23. Добавляем задачу для обеспечения своевременной поставки материалов

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

План реакции на риски

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

План реакции на риски хранится в плане проекта в виде текстовой информации, связанной с определенными задачами или ресурсами. Для хранения информации о реакции на ресурсные риски настроим ресурсное поле Text4 (Текст4), переименовав его в План реакции на риски . Пример заполнения его данными представлен на рис. 16.24.

Рис. 16.24. Составляем план реакции на риски

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

Финансовый буфер можно создать простым увеличением стоимости проекта на коэффициент, который принято использовать в вашей организации в таких случаях. Например, если бюджет проекта составляет $100 000, а пессимистический бюджет — $120 000, то с учетом буфера бюджет проекта может равняться $130 000. Формирование временного буфера рассмотрим более подробно.

Формирование временного буфера

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

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

Для анализа существующего в плане временного резерва удобно воспользоваться представлением Gantt Chart (Диаграмма Ганга) и таблицей Schedule (Календарный план), в которой отображается информация о существующем временном запасе. Для того чтобы эта же информация отображалась и на диаграмме, настроим ее с помощью мастера Gantt Chart Wizard (Мастер диаграмм Ганта).

На первом шаге мастера (определение типа информации для отображения на диаграмме) выберем переключатель Custom Gantt Chart (Настроить диаграмму Ганта). На следующем шаге выберем переключатель Yes ( Да) для отображения информации о критических и обычных задачах разными способами. После этого пропустим все диалоговые окна с настройками цветов отрезков и дойдем до пятого, в котором определяются типы дополнительных отрезков, отображаемых па диаграмме (рис. 16.25).

Рис. 16.25. Выбираем дополнительные отрезки для отображения на диаграмме Ганга

В этом диалоговом окне выберем переключатель Total slack (Общий временной резерв). Данные о существующем у задач резерве будут отображаться в виде тонких отрезков. На образце в области предварительного просмотра видно, что временной резерв может быть только у обычных задач (они более темные), поскольку у критических его не бывает. Теперь самые важные настройки завершены и можно нажать кнопку Finish (Готово) прямо в этом диалоговом окне. Представление настроено, и можно начать работу с временным буфером (рис. 16.26).

Рис. 16.26. Данные о временном резерве отображаются в таблице и на диаграмме

Таблица Schedule (Календарный план) содержит несколько колонок, с помощью которых можно определить степень устойчивости к рискам как расписания проекта в целом, так и его отдельных задач. В колонке Total Slack (Общий временной резерв) содержится информация о времени, на которое исполнение задачи можно отложить, чтобы длительность проекта не изменилась. Колонка Free Slack (Свободный временной резерв) содержит информацию о времени, на которое можно отложить исполнение задачи, чтобы не задерживать последующие задачи. A в колонках Late Start (Позднее начало) и Late Finish (Позднее окончание) содержатся самые поздние даты, когда можно начать и окончить задачу, чтобы не изменить дату окончания проекта.

На диаграмме информация об общем временном резерве задачи (Total Slack) отображается с помощью тонких отрезков. Например, у задачи 21 на рис. 16.26 значение поля Total Slack (Общий временной резерв) составляет 31,87 дня, и рядом с отрезком, обозначающим задачу, расположен тонкий отрезок такой же длительности.

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

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

Если задачи с ограничениями имеют предшественниц, заканчивающихся слишком поздно для того, чтобы ограничение было удовлетворено, у последующих задач образуется отрицательный резерв. Чтобы задачи с ограничением и с отрицательным резервом помещались в расписании в соответствии со связями, а не с датами ограничений, в диалоговом окне Options (Параметры) на вкладке Schedule (Планирование) нужно сбросить флажок Tasks will always honor their constraint dates (Для задач всегда соблюдаются заданные для них даты).

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

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

Для подготовки данного доклада использовалась книга В.В. Богданов. Управление проектами в Microsoft Project 2002: Учебный курс. – СПб.: Питер, 2003. – 640с.