[DIV]

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

Был бы интересен опыт участников форума в решении подобных задач .

[elephanta]

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

[DIV]

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

[Bug]

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

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

[DIV]

Спасибо, Bug, за дельные советы. Вовлечение заказчика в работу проекта обычно декларируется во всех проектах. Однако в действительности в половине случаев заказчик только имитирует свое участие в проекте. Уверен, что такая ситуация не редкость. Проектная группа со стороны заказчика обычно боится признать собственную некомпетентность, в результате начинается затягивание сроков, паузы и т.п.

[yarg]

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

[Alexa]

elephanta (07 января 2010 - 20:13):

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

Наткнулась на Хабре на интересную статью - "Как растянуть создание проекта на пару лет или искусство эффективного планирования" . Конечно, в идее чувствуется определенная IT-специфика, тем не менее, мысли здравые и полезные для более широкого использования .

[Colambus]

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

[Alexa]

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

[ratm]

Главная рекомендация менеджеру при управлении проектом с нереальными сроками - управлять планом работ и бюджетом проекта. Сборник отличных рекомендаций для данной ситуации:

Управление проектами при нереальных сроках:

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

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

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

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

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

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

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

• Находите возможности для улучшения процессов. Наконец, посмотрите беспристрастно на Ваш план работ и подход к выполнению проекта. Поговорите с командой, с клиентами и с руководством о наличии каких-либо идей относительно того, как помочь проекту двинуться вперед быстрее. Это позволит всем участникам ощущать себя причастными к разработке результатов проекта. К примеру, Вам, возможно, удастся применить методику Joint Application Development (JAD), чтобы более быстро собрать требования к продукту, чем это могло бы получиться при традиционном интервьюировании.

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

[tess]

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

[ratm]

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

[Kareg]

Вообще-то в управлении проектами риск понимается как вероятное событие:

PMBOK:

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

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

[ratm]

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

[Bazilio]

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