Разложение проекта на составляющие

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

Чтобы скачать версию Word в этой статье, см. в статье Они говорят, что они хотят разрешения: white paper (Project Server 2010).

Дополнительные статьи см. в статье "Из окопов".

Разложение проекта на составляющие

С извинениями перед Битлз за название, сегодняшняя тема является разрешение вашего проекта.

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

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

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

Итак, каков правильный подход?

Как долго должны выполняться задачи и сколько нужно оптимизировать расписание проекта? Я назову это разрешением проекта.

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

Различные типы проектов, естественно, призывают к различным типам расписания. Рассмотрим три различных примера:

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

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

EPC — проектирование, закупка и строительство. В проектах EPC началась методология планирования критических путей. В этом проекте разрабатывается что-то очень большое. Это может быть крупный оборонный проект, например проект Polaris Missile, который дал схемам PERT начало, или это может быть оффшорная нефтяная вышка, новый корабль или электростанция. В таких проектах существует этап проектирования, на котором зачат готовый проект. На этапе проектирования обычно имеется определенный аспект, который еще никогда не разрабатывался. На этапе закупок предусматривается поиск, контрактирование и управление доставкой поставок или субконтрактов для элементов проекта. На этапе "Строительство" конечный продукт сконструированы, а затем в эксплуатацию. Обычно мы думаем о графиках проектов EPC в течение многих месяцев или нескольких лет с продолжительностью действий, продолжительностью от нескольких недель до нескольких месяцев. Совсем не необычно иметь от 5000 до 20 000 задач для такого проекта. Планирование ресурсов здесь почти всегда назначено на уровень квалификации, а не отдельных, и (только для того, чтобы добавить в удовольствие) может быть много подпроектов, сделанных в программе или мастер-проект для простоты управления.

Отключение завода. При составлении графика проекта для остановки завода и выполнения обхода для обслуживания вы работаете в одной из наиболее сложных сред планирования. Отключение завода для обслуживания происходит в двух ароматизаторах: плановом и аварийном. Давайте оставим аварийный тип в стороне на минуту; это мир, который сам по себе. Продолжительность запланированного остановки завода в значительной степени зависит от типа растения. Например, блок атомной электростанции может сделать "быстрое" отключение и обход станции в течение 12 месяцев. Нефтепереработка может длиться 4-6 недель. Но наиболее интересным для меня является тип графика проектов завода, например сталелитейная фабрика, бумажная фабрика или что-то подобное. По всему миру существуют тысячи или десятки тысяч таких растений, которые каждый год должны регулярно проходить техническое обслуживание.

Стоимость остановки для этих ситуаций обычно измеряется в стоимости возможностей; стоимость продукта, который не будет производиться в то время как завод простаивает и проходит техническое обслуживание. Эта стоимость измеряется в часах, а стоимость может быть свыше $150 000 до $250 000 в час! Так что нагрузка на каждую минуту, чтобы получить работу. В таких ситуациях завершение обычно длится 5-8 дней, а задержка одного дня исчисляется миллионами. Если вы привыкли только к более длительным, более традиционным расписаниям, можно подумать, что за несколько дней "сколько задач обычно может быть?" но это совсем не необычно для такого отключения иметь от 2000 до 4000 задач, каждая из которых длится от 15 минут до нескольких часов. Назначения ресурсов здесь делаются с помощью навыков, но выравнивание ресурсов редко делается для персонала. Если затраты в час настолько интенсивны, не важно, если вы наберете больше людей в проекте, просто спешат. Выравнивание ресурсов в этой ситуации часто делается для узкого места с ограниченными ресурсами. Например, "мы можем вместить только двух человек в электрической комнате, так что управлять этим нужно дискретно".

Итак, у нас есть три типа примеров, и их еще много, но эти три будут служить целям обсуждения. В типе 1 (разработка программного обеспечения) мы получаем задачи, обычно от одного дня до двух недель. В типе 2 (EPC) мы получаем задачи, которые являются неделями или месяцами. В типе 3 (закрытие завода) мы получаем задачи, которые измеряются в единицах 6 минут (1/10 часа), 10 минут, 15 минут (1/4 часа), до нескольких часов. Очевидно, что в некоторых случаях короткие задачи имеют смысл, а в других — более длительные. Следуя той же логике, иногда имеет смысл выполнять огромное количество задач, а иногда просто нет.

С помощью этих трех различий легко увидеть, что двухмесячная задача проекта EPC будет выглядеть нелепо в шестидневный график отключения и что 15-минутная задача будет неаккумерной в проекте EPC или Software. Но помимо ссылаясь на эту статью и говоря: "Vandersluis говорит, что это программный проект, поэтому задачи могут быть только 1-10 дней", (и, пожалуйста, не делайте этого) какие характеристики проекта говорят нам, какой уровень разрешения выбрать? Давайте рассмотрим несколько очевидных из них:

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

Это правило? Нет, конечно, нет.

Это здравый смысл. Менее 4 заставляет задуматься, почему вы разделили работу на всех и более 20 слишком трудно держать в уме в одно время. Лично я иду с не более чем 8 элементов на элемент WBS, и это из-за некоторых статей, которые я читал лет назад, что предполагается, что октагон был наиболее сложной простой форме ум может сразу же распознать.

Подумайте об этом на минуту. Вы можете определить круг, треугольник, квадрат, пентагон, шестиугольник, который имеет 6 сторон, гептагон, который имеет 7 сторон (ОК, что трудно представить) и октагон.

Можете ли вы определить 9-сторонную фигуру без подсчета? Не могу. Это называется "nonagon" для вас мелочи buffs.

Итак, лично я стремлюсь к ограничению в 8 элементов, но мое правило 4-20.

Для каждого элемента, на который вы смотрели, подумайте о том, как разделить работу. Опять же, подумайте о правиле 4-20. Но знать, когда остановить это секрет. Новые руководители проектов будут разделять и подразделять и подразделять до тех пор, пока каждый шаг вниз по коридору не станет управляемой задачей. Некоторые хорошие вопросы, которые вы можете задать себе о длине задачи может быть:

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

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

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

Давайте применим проверку реальности к тем, о чем я только что говорил. В двухлетнем проекте EPC, если недельная задача опаздывает на день, то почти наверняка не стоит принимать меры. В шестимесячном проекте Software недельная задача с опозданием на день, вероятно, не стоит принимать меры. В шестидневных проектах отключения одна неделя, которая опаздывает на день, — это массовая чрезвычайная ситуация. Другими словами, недельная задача в проекте EPC может быть слишком тонкой на уровне детализации; в проекте программного обеспечения это, вероятно, примерно правильно; и в проекте Shutdown его почти наверняка необходимо разбить на более подробные.

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

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

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

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

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

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

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

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

Сколько времени сотруднику необходимо для перехода из одного проекта в другой?

Определяется ли работа так, чтобы и сотрудники, и руководители отдела ресурсов понимали, как правильно распределить нужные навыки?

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

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

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

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

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

Вот два ключа, чтобы определить, сколько данных можно собрать и включить:

Подумайте, как собирать данные.

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

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

При анализе данных управления проектами мы делаем некоторые предположения. Мы предполагаем, что:

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

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

Все данные были одобрены на определенном уровне. Мы ожидаем, что руководитель проекта будет стоять за представленными данными и сможет сказать: "Это справедливое и точное представление проекта".

Данные принадлежат друг другу. Мы не ожидаем, что риски будут размыты с затратами и ресурсами, если мы специально не разработали наши отчеты и анализ таким образом.

Я часто спрашиваю руководителей, которые рады концепции управления проектами в режиме реального времени, что они будут делать, если мы могли бы преодолеть точки, которые я только что поднял выше. "Готовы ли вы принимать управленческие решения в течение всей недели?" Я попрошу. Ответ должен зависеть от уровня разрешения. В проекте остановки лучше ответить "Да". В проекте программного обеспечения ответ, вероятно, заключается в том, что "Нет, мы будем делать это еженедельно". А в проекте EPC ответ будет : "Ежемесячно".

В какой-то момент в законе о снижении прибыли будет гнаться: "Доставка отчетов о проекте быстрее не даст нам повышения эффективности".

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

В некоторых случаях руководители уверены из всего, что обучение MBA "более подробно лучше", и они настаивают на этих 5-минутных или 15-минутных задачах для шестимесячных проектов.

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

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

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

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

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

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

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

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

У нас есть окно от одной до трех недель, ресурсы доступны нам, и мы назначим работу каждому ресурсу. Количество возможных задач, которые мы можем определить в этой структуре, конечно, и это поддается поддержанию соответствующего уровня разрешения. Да, вы можете получить проблемы в Agile, определяя слишком короткие задачи. "Определите поле1: 10 минут, определите поле2: 10 минут, определите поле3: 10 минут" и т. д. Но это гораздо реже.

Agile был разработан для корпоративной среды разработки, в которой мы создаем программное обеспечение для использования на дому, и его использование часто распространяется на коммерческую разработку программного обеспечения. (Мы используем метод здесь, в HMS для нашего собственного развития TimeControl.) Метод Agile позволяет получить более маневренный и ловкий отдел разработки, но он не будет применим к каждой отрасли или даже к каждой программной компании. Если вы занимаетесь управление проектами в программной среде, то я советую прочитать о Agile, изучить его, а затем принять те элементы (все, некоторые или нет), которые сделают вас наиболее эффективными.

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

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

Об авторе

Крис Вандерслуис является президентом и основателем канадской компании HMS Software, сертифицированного партнером Microsoft. Он имеет степень по экономике в Университете McGill и более 30-летний опыт автоматизации систем управления проектами. Он является давним членом Института управления Project (PMI) и помог найти главы Группы Microsoft Project пользователей (MPUG) в Монреале, Торонто и Квебеке. Публикации, для которых Крис написал: Fortune, Heavy Construction News, Computing Canada magazine и PMI's PMNetwork, и он является регулярным обозревателем для Project Times. Он преподает Project управления в Университете McGill и часто выступает на функциях ассоциации управления проектами в Северной Америке и по всему миру. HMS Software является издателем системы хронометража проекта TimeControl и с 1995 Microsoft Project партнером по решению.