КАЛЕНДАРНО-СЕТЕВОЕ ПЛАНИРОВАНИЕ
Временные ограничения
Построенное программой расписание (календарный график) может нас не устраивать. Какую-то задачу нельзя начать в день, определенный программой из-за того, что помещение для этой задачи будет арендовано только через неделю. Для какой-то задачи сроки уже определены договором с подрядчиком, и менять их нельзя. Для другой исполнитель может участвовать в работе только до определенной даты.
Для корректировки расписания могут быть использованы временные ограничения.
По умолчанию, у каждой задачи уже есть временное ограничение –Как можно раньше (As soon as possible) при планировании от начала, или Как можно позже (As late as possible) при планировании от окончания. Эти ограничения считаются гибкими, с их помощью можно построить гибкий динамический график, который будет автоматически пересчитываться при изменении условий проекта.
На самом деле, многие из пользователей программы неосознанно устанавливают временные ограничения, когда вручную заполняют даты начала и окончания каждой задачи (столбцы Начало и Окончание). При ручном заполнении столбца Начало к задаче применяется ограничение Начало не ранее (указанной даты), при заполнении столбца Окончание – Окончание не ранее (указанной даты). Эти ограничения могут привести к неоправданному затягиванию сроков проекта. Например, Project рассчитал с учетом длительностей и связей дату начала задачи – 1 июня, а вы установили дату начала – 15 июня. В итоге получаем «дырку в проекте» длиной в две недели. Также средние временные ограничения мешают гибкости календарного графика и его автоматическому пересчету.
Все временные ограничения можно условно разделить на 3 группы: гибкие, средние и жесткие. Рекомендуется свободно использовать гибкие, а средние и жесткие – только, если даты обусловлены внешней средой проекта. Не нам лично захотелось задачу закончить к 10 июня, а этого требуют условия договора, например.
Средние ограничения могут привести к затягиванию сроков проекта, а жесткие – привести к конфликту планирования. Например, мы считаем, что задача обязательно должна быть завершена к 10 июня, а программа рассчитала с учетом длительностей и связей дату завершения – 15 июня. В итоге – конфликт.
Что делать, если мы все же нарвались на конфликт планирования? Пересмотреть сроки выполнения работ ДО конфликтной даты. Применить к предшествующим конфликту задачам методы сокращения сроков, такие как быстрый проход или сжатие. Если же конфликта избежать не удается – надо выполнить эскалацию вопроса на более высокий уровень – спонсора проекта или руководства компании, аргументировав невозможность соблюсти определенную дату.
См. также статьи Классификация временных ограничений, Как устанавливать временные ограничения
Для корректировки расписания могут быть использованы временные ограничения.
По умолчанию, у каждой задачи уже есть временное ограничение –Как можно раньше (As soon as possible) при планировании от начала, или Как можно позже (As late as possible) при планировании от окончания. Эти ограничения считаются гибкими, с их помощью можно построить гибкий динамический график, который будет автоматически пересчитываться при изменении условий проекта.
На самом деле, многие из пользователей программы неосознанно устанавливают временные ограничения, когда вручную заполняют даты начала и окончания каждой задачи (столбцы Начало и Окончание). При ручном заполнении столбца Начало к задаче применяется ограничение Начало не ранее (указанной даты), при заполнении столбца Окончание – Окончание не ранее (указанной даты). Эти ограничения могут привести к неоправданному затягиванию сроков проекта. Например, Project рассчитал с учетом длительностей и связей дату начала задачи – 1 июня, а вы установили дату начала – 15 июня. В итоге получаем «дырку в проекте» длиной в две недели. Также средние временные ограничения мешают гибкости календарного графика и его автоматическому пересчету.
Все временные ограничения можно условно разделить на 3 группы: гибкие, средние и жесткие. Рекомендуется свободно использовать гибкие, а средние и жесткие – только, если даты обусловлены внешней средой проекта. Не нам лично захотелось задачу закончить к 10 июня, а этого требуют условия договора, например.
Средние ограничения могут привести к затягиванию сроков проекта, а жесткие – привести к конфликту планирования. Например, мы считаем, что задача обязательно должна быть завершена к 10 июня, а программа рассчитала с учетом длительностей и связей дату завершения – 15 июня. В итоге – конфликт.
Что делать, если мы все же нарвались на конфликт планирования? Пересмотреть сроки выполнения работ ДО конфликтной даты. Применить к предшествующим конфликту задачам методы сокращения сроков, такие как быстрый проход или сжатие. Если же конфликта избежать не удается – надо выполнить эскалацию вопроса на более высокий уровень – спонсора проекта или руководства компании, аргументировав невозможность соблюсти определенную дату.
См. также статьи Классификация временных ограничений, Как устанавливать временные ограничения
#ProjectProfessional #ProjectOnlineProfessional #Задачи #КалендарноСетевоеПланирование #Задачи
