Разложение проекта на составляющие
Эта статья является частью нашей коллекции "Из окопов". В ней описаны некоторые распространенные проблемы, с которыми вы можете столкнуться при планировании проектов. В ней описывается оптимальный подход, когда вы пытаетесь определить, сколько задач должно быть длинным и сколько должно быть для оптимизации расписания проекта. В нем рассматривается, как в разных отраслях обычно требуются различные типы расписаний (например, разработка программного обеспечения, EPM (проектирование, закупки и строительство) и завершение работы завода). В нем также рассматриваются несколько факторов при выборе решения проекта (например, длина проекта, задействованные ресурсы, управление или разделение ресурсов, скорость и усилия, необходимые для сбора данных, а также расписание обновления данных).
Чтобы скачать версию этой статьи в Word, см. статью Пользователи говорят, что им нужно разрешение: технический документ (Project Server 2010).
Дополнительные статьи см. в технических документах "Из окопов".
Разложение проекта на составляющие
С извинениями перед Beatles за название, сегодняшняя тема является решением вашего проекта.
Существует много материалов о том, как составить расписание, но один из самых важных уроков очень трудно получить: сколько задач должно быть в расписании проекта и сколько времени должна быть каждая из них?
На регулярной основе я сталкиваюсь с расписаниями проектов, которые кажутся невозможными сложными, или с руководителями проектов, которые кажутся беспомощными, чтобы точно определить проблемы в своем расписании, потому что расписание находится на таком сводном уровне. Я видел проект, который был более ста лет (да, действительно), который был совершенно подходящим по длине и в котором были некоторые задачи, которые были десятилетиями. Я также видел графики проектов, которые длились всего час или меньше, которые были совершенно подходящими и в которых некоторые задачи длились всего одну минуту. Я видел проекты только с несколькими задачами и другие с более чем 100 000 задач.
Программное обеспечение, которое мы используем сегодня, может выполнять тысячи задач и широкий диапазон длительности.
Итак, каков правильный подход?
Сколько должно быть задач и сколько необходимо для оптимизации расписания проекта? Я назову это решением проекта.
Разные штрихи для разных людей
Так как требования могут быть разными для разных отраслей, разных типов проектов и разных ситуаций, давайте посмотрим, как решить, сколько задач вложить в расписание и сколько времени должно быть.
Различные типы проектов, естественно, требуют различных типов расписаний. Давайте рассмотрим три разных примера:
Разработка программного обеспечения. Многие проекты программного обеспечения имеют общие характеристики. Хотя каждый программный проект уникален, обычно существует этап проектирования, этап программирования, этап контроля качества, этап документа и этап развертывания. Проекты программного обеспечения обычно измеряются в неделях или месяцах, и это поддается задачам, которые выполняются от дня до нескольких недель. Выделение ресурсов здесь часто назначается на отдельный уровень.
Те, кто принял гибкий процесс разработки программного обеспечения, смотрят на короткие "спринты" в одну или две недели и в этом спринте ставят задачи, которые имеют кратковременную длительность, но общая длительность проекта по-прежнему измеряется в неделях. Подробнее о гибкой разработке мы поговорим чуть позже.
EPC — проектирование, закупки и строительство. В проектах EPC началось с методологии планирования критических путей. В этом проекте разрабатывается нечто очень большое. Это может быть крупный оборонный проект, как проект ракеты Polaris, который дал диаграммы PERT их старт, или это может быть морской нефтяной вышке, новый корабль или электростанция. В таких проектах есть этап проектирования, на котором создается готовый проект. Этап проектирования обычно имеет некоторый аспект, который никогда не разрабатывался ранее. На этапе закупок рассматривается поиск элементов проекта, заключение контрактов на поставку или субконтракты, а также управление ими. На этапе строительства окончательное изделие создается, а затем сдается в эксплуатацию для использования. Обычно мы думаем о планах проектов EPC в течение нескольких месяцев или нескольких лет с длительностью активности в любом месте от нескольких недель до нескольких месяцев. От 5000 до 20 000 задач в таком проекте не является необычным. Планирование ресурсов здесь почти всегда назначается уровню навыков, а не индивидуальному, и (просто чтобы добавить в удовольствие) может быть много вложенных проектов, сделанных в программе или главном проекте для упрощения управления.
Завершение работы завода. Когда вы выполняете расписание проекта для завершения работы предприятия и обхода для обслуживания, вы работаете в одной из самых сложных сред планирования. Отключение завода для выполнения технического обслуживания происходит в двух вариантах: плановое и аварийное. Давайте оставим тип аварийной ситуации в стороне на мгновение; это мир сам по себе. Продолжительность запланированной остановки завода в значительной степени зависит от типа завода. Например, атомная электростанция может выполнить "быструю" остановку и обход в течение 12 месяцев. Нефтеперерабатывающий завод может длиться 4-6 недель. Но тип плана проекта завода, что я считаю наиболее интересным является производственный завод, как сталелитейный завод, бумажная фабрика, или что-то подобное. Существует тысячи или десятки тысяч таких растений по всему миру, и они должны проходить регулярное обслуживание каждый год или около того.
Стоимость завершения работы в таких ситуациях обычно измеряется в альтернативных затратах; стоимость продукта, который не будет производиться, пока завод простаивает и проходит техническое обслуживание. Эта стоимость измеряется в часах, и стоимость может быть выше $ 150000 до $ 250000 в час! Таким образом, давление на поминутно, чтобы сделать работу. В такой ситуации завершение работы обычно длится 5–8 дней, а задержка на один день вычисляется в миллионах. Если вы привыкли только к более длинным, более традиционным расписаниям, вы можете подумать, что в течение нескольких коротких дней, "сколько задач обычно может быть?", но это не является необычным для такого завершения работы, чтобы иметь от 2000 до 4000 задач, каждая из которых длится от 15 минут до нескольких часов. Назначения ресурсов здесь выполняются по навыку, но выравнивание ресурсов редко выполняется персоналом. С стоимостью в час настолько интенсивным, это не имеет значения, если вы поставить больше людей на проект, просто получить его сделать в спешке. Выравнивание ресурсов в этой ситуации часто выполняется для узких мест с высоким уровнем ограничений. Например, "мы можем поместить только двух человек в электрической комнате, так что это должно управляться дискретно".
Хорошо, теперь у нас есть три вида примеров, и их гораздо больше, но эти три будут служить целям обсуждения просто отлично. В первом типе (разработка программного обеспечения) мы получаем задачи, которые обычно выполняются от одного дня до двух недель. В типе 2 (EPC) мы получаем задачи длиной в несколько недель или месяцев. В типе 3 (завершение работы завода) мы получаем задачи, измеряемые в единицах 6 минут (1/10 часа), 10 минут, 15 минут (1/4 часа) и до нескольких часов. Очевидно, что в некоторых случаях короткие задачи имеют смысл, а в других более подходящими являются длинные. Следуя той же логике, иногда имеет смысл иметь огромное количество задач, а иногда просто нет.
Факторы при выборе разрешения проекта
С этими тремя различиями легко увидеть, что двухмесячная задача проекта EPC будет выглядеть нелепо в шестидневном графике завершения работы и что 15-минутная задача будет неуместна в проекте EPC или Software. Но помимо ссылки на эту статью и сказать: "Вандерслуис говорит, что это программный проект, поэтому задачи могут быть только 1-10 дней", (и пожалуйста, не делайте этого), какие характеристики проекта говорят нам, какой уровень решения выбрать? Давайте рассмотрим несколько очевидных из них:
Сколько времени составляет проект?
Начнем с самого очевидного. Если ожидается, что проект будет иметь несколько дней, как в нашем примере завершения работы, то выполнение задач длиной в несколько дней вообще не имеет смысла. Начиная с подхода сверху вниз часто бывает продуктивным, когда мы думаем о разделении области. Используйте структуру работы и разбивки. Начните с основных компонентов. Подумайте о наличии не менее 4 и не более 20 элементов.
Это правило? Нет, конечно, нет.
Это здравый смысл. Меньше 4 заставляет вас задаться вопросом, почему вы разделили работу на всех и более 20 слишком трудно держать в своем уме в одно время. Лично я иду с не более чем 8 предметов на элемент WBS, и это из-за некоторых статей я читал много лет назад, что предложил, что восьмиугольник был наиболее сложной простой формой ум мог сразу распознать.
Подумайте об этом на мгновение. Вы можете определить круг, треугольник, квадрат, пятиугольник, шестиугольник с 6 сторонами, шестиугольник с 7 сторонами (хорошо, что один трудно визуализировать) и восьмиугольник.
Можете ли вы определить 9-стороную фигуру без подсчета? Не могу. Это называется "нонагон" для вас тривиа баффы.
Итак, лично я стремлюсь к ограничению в 8 пунктов, но мое правило большого пальца 4-20.
Для каждого элемента, на который вы смотрели, подумайте о том, как следует разделить работу. Опять же, подумайте о правиле 4-20. Но знать, когда остановиться, это секрет. Новые руководители проектов будут разделять и разделять и разделять до тех пор, пока каждый шаг вниз коридора не будет управляемой задачей. Некоторые хорошие вопросы, которые вы можете задать себе о продолжительности задачи, могут быть следующими:
Какие действия я предпримечу, если эта задача запаздынет? Если ответ " ничего", то это хороший признак того, что задача, которую вы думаете, слишком мала, чтобы ее стоит управлять. Если это так, вы ищете слишком много деталей. Создайте резервную копию уровня, сделайте шаг назад и посмотрите, все готово.
Будет ли сбор данных об обновлении этой задачи занимать больше времени, чем сама задача? Мы не всегда думаем о том, какие усилия потребуются для управления запланированной задачей, но стоит подумать, даже если на мгновение. Если для управления задачей потребуется больше усилий, чем потребуется для ее завершения, это хороший признак того, что задача определена слишком подробно.
Сколько времени эта задача? Когда мы разделяем работу, иногда мы упускаем из виду, насколько незначительной становится задача. Большие фазы на верхнем уровне были, возможно, неделями, но по мере того как мы спустимся на пару уровней детализации, мы можем легко попасть в ловушку определения задачи, которая будет управляться, что всего несколько минут. Когда мы дойдем до крошечных задач, мы должны спросить, в чем преимущество управления ими.
Давайте применим проверку реальности к тому, о чем я только что говорил. В двухлетнем проекте EPC, если однонедельная задача является на день с опозданием, это почти наверняка не стоит принимать меры. В шестимесячном проекте программного обеспечения задача на одну неделю, которая является на день с опозданием, вероятно, не стоит принимать меры. В шестидневном проекте завершения работы одна неделя, которая является с опозданием на день, является массовой чрезвычайной ситуацией. Другими словами, однонедельная задача в проекте EPC может быть слишком тонкой с уровнем детализации; в проекте программного обеспечения, это, вероятно, примерно правильно; и в проекте завершения работы он почти наверняка должен быть разбит на более подробные сведения.
Сколько ресурсов задействовано?
Я знаю, что мы просто работаем над областью, но когда мы смотрим на то, какое решение мы требуем, стоит подумать о том, сколько людей будет работать над задачей. Например, в крупном проекте EPC могут быть десятки работников из одного навыка, участвующих в этапе работы. Но когда мы в конечном итоге имеем много различных навыков в одной и той же задаче, управление этой задачей становится очень сложной, если не невозможной. Таким образом, в этой ситуации задачи, требующие много различных навыков, вероятно, должны быть разделены.
В программном проекте мы склонны рассматривать почти каждого человека как высокотехнических ресурсов с уникальными возможностями. Кроме того, в проектах программного обеспечения часто много задач, которые можно повторно назначить в отделе, но только одна задача назначается одному человеку. Поэтому, когда у нас есть задачи, которые выделяются на уровне одного пользователя определенной группы ресурсов или отдела (например, программирование интерфейса), мы достаточно близки, чтобы сказать, что нам не нужны дополнительные сведения.
Как ресурсы управляются или делятся на вложенные ресурсы?
Управление ресурсами является большим фактором, определяющим способ разделения задач. Например, в крупных проектах EPC проекты часто разбиваются на подпроекты, которые положены в огромные субподрядчики. В этой ситуации нам нужно сделать несколько действий:
Определите работу таким образом, чтобы руководитель проекта наблюдал за субподрядчиком с уверенностью в том, что достигнутый прогресс является важным фактором.
Определите задачи таким образом, чтобы руководители проектов и инженеры субподрядчика понимали, что они означают без неоднозначности.
Убедитесь, что уровень резолюции, принятый в качестве вашего стандарта, понимается и согласован с субподрядчиком.
Когда мы смотрим на такие проекты, как программное обеспечение, биологические исследования или инженерия, мы, скорее всего, столкнемся со структурой управления матрицами, в которой руководители проектов не владеют ресурсами, и мы должны работать с руководителями отделов, которые распределяют эти ресурсы по множеству различных проектов. В этом случае ключевые вопросы будут следующими:
Сколько проектов ресурс может работать в течение одного дня?
Сколько времени требуется сотруднику для перехода с одного проекта на другой?
Определена ли работа таким образом, чтобы сотрудники и руководители отдела ресурсов понимали, как выделить ему нужный навык?
Когда мы смотрим на проект завершения работы или строительства, мы, как правило, работаем между бригадами, которые специально построены. В таких ситуациях руководитель группы ресурсов может управлять группой по электротехнике (даже если в ее состав входят столяра и слесаря), группу сантехники или команду по ремонту котлоагрегатов. Работа должна быть организована таким образом, чтобы экипаж был занят в течение всей смены, и что они не прибудут на вершине другого экипажа, уже работающего в чем-то в этом районе. Учитывая интенсивное давление на завершение работы над проектом завершения работы, работа часто сначала организована по расписанию, а затем перегруппирована и разделена на руководителя группы ресурсов, чтобы каждый руководитель команды смог обходить только свои задачи в одном документе, а весь проект — в контексте другого. Поэтому задачи должны быть определены таким образом, чтобы сотрудник и руководитель группы ресурсов были понятны. Задачи здесь, вероятно, определены до часа или с еще большей степенью детализации до десятой или четверти часа.
Как быстро можно собрать данные и сколько усилий это потребуется?
Это звучит как глупый вопрос, когда вы привыкли видеть данные проекта все хорошо выстраивается в конце недели для проверки, но когда вы пытаетесь определить уровень разрешения проекта, это может быть ключевым вопросом. Например, при работе с многочисленными субподрядчиками, скорее всего, вы получите какое-то еженедельное или ежемесячное обновление. На самом деле важно создать предложение об обновлении управления проектами в контракте. В этой ситуации необходимо интегрировать данные из этих разных компаний в свои собственные, проверить, что данные о ходе выполнения имеют смысл, а затем выполнить собственный анализ и отчеты. В режиме EPC это, вероятно, ежемесячное событие.
В проекте завершения работы необходимо обновлять проект каждую смену, быстро обновлять его и получать обновления для руководителей группы ресурсов в середине следующей смены. В этой ситуации сотрудники проекта роятся по всему заводу во время смены, собирая данные как можно ближе к реальному времени, а руководители группы ресурсов и руководители групп ресурсов используют листы "выноса вниз", чтобы "снять" ход выполнения своих заданий. В программном обеспечении или исследовательском проекте вы, вероятно, работаете по еженедельный график или что-то вроде него с людьми, сообщая о своем собственном прогрессе и проходя через утверждения в течение дня или двух.
Это важный момент, который следует учитывать при просмотре количества задач в проекте, так как сбор данных требует затрат.
Поэтому важно думать о том, как быстро можно собирать, утверждать, интегрировать, анализировать и сообщать данные на регулярной циклической основе, а также учитывать затраты на сбор данных и окупаемость инвестиций в собираемые данные.
Как часто мы будем обновляться?
Ниже приведены два ключа для определения объема данных, которые можно собирать и включать:
Подумайте о том, как вы будете собирать данные.
Подумайте о том, как часто можно разумно обновлять проект и предоставлять управлению средства принятия решений, необходимые для направления проекта и ресурсов в правильном направлении.
Я видел, как некоторые руководители проектов настаивают на том, что они хотят перейти к управлению проектами в режиме реального времени и сбору проектов, и хотя это может быть возможно в теории, это очень трудно реализовать на практике.
Когда мы смотрим на данные управления проектами, мы делаем некоторые предположения. Предполагается, что:
Все данные есть. Мы не ожидаем рассматривать некоторые задачи, которые обновляются, а другие — нет.
Все данные были обновлены в одно и то же время. Мы не ожидаем, что половина задач была обновлена несколько минут назад, но другая половина не обновлялась в течение двух недель.
Все данные имеют определенный уровень утверждения. Мы ожидаем, что руководитель проекта будет стоять за представляемые данные и что он или она может сказать: "Это справедливое и точное представление проекта".
Данные принадлежат вместе. Мы не ожидаем, что риск будет размыт с затратами и ресурсами, если мы специально не разработали наши отчеты и анализ таким образом.
Я часто спрашиваю руководителей, которые рады концепции управления проектами в режиме реального времени, что они будут делать, если мы сможем преодолеть точки, которые я только что поднял выше. "Готовы ли вы принимать решения по управлению на протяжении всей недели?" Я спрошу. Ответ должен зависеть от уровня разрешения. В проекте завершения работы лучше ответить "Да". В программном проекте ответ, вероятно, будет "Нет, мы будем делать это еженедельно". И в проекте EPC ответ будет: "Ежемесячно".
В какой-то момент закон уменьшения возвращает удар в сказать: "Доставка проектных отчетов любой быстрее не даст нам никакого повышения эффективности".
Просмотр работы
Теперь у вас есть пища для размышлений, вы использовали метод разбивки по трудоемким данным, чтобы разделить данные, и вы наблюдали за некоторыми предупреждающими знаками о том, что данные слишком точно определены. Теперь настало время опираться на расписание о стену, отойти назад и взглянуть на проект с некоторой перспективой. Удивительно, но многие руководители проектов никогда этого не делают. Они настолько увязли в получении последних деталей определены и настолько заняты под-деления задач снова и снова, что они толкают себя прямо до срока идти жить и никогда не смотреть вверх, чтобы увидеть, то, что они сделали, будет кошмаром для управления.
В некоторых случаях руководители уверены из всего, что обучение MBA, что "больше деталей лучше", и они настаивают на этих 5-минутных или 15-минутных задач на шестимесячных проектах.
Изменить проект до его запуска всегда проще, чем в любое время позже, поэтому время сборки в вашем действии по созданию расписания, чтобы при необходимости переработать расписание.
Это слишком много?
Иногда руководители проектов смотрят на область того, что они создали, и понимают, что они находятся на слишком тонком уровне детализации. Если это так, исправление очевидно. Это может быть много работы, но вы отблагодарите себя позже, чтобы сделать расписание проще, продвигаясь вверх по уровню.
Иногда картина не так проста. В некоторых случаях только после сборки всего расписания руководитель проекта может увидеть, насколько сложным оно является. Сложные проекты по своей природе более рискованны, а риск в современной экономике является ключевым фактором выбора проектов. Некоторые вопросы, которые стоит рассмотреть до начала такого сложного проекта, могут быть следующими:
Можем ли мы сделать это по частям? Некоторые рискованные проекты могут быть разбиты на части меньшего размера и, как небольшие проекты, их риск падает. Однако если вы используете эту стратегию, каждый дискретный проект должен иметь собственное значение по завершении.
Следует ли переосмыслить область? Иногда проще всего вернуться к конструкторам работы, объяснить сложность, которая кажется очевидной в расписании, и посмотреть, можно ли перепросмотреть работу. Это часто приводит к инновационному мышлению, которое никогда не имело бы шанса произойти.
Должны ли мы делать это вообще?
Некоторые проекты никогда не должны были быть, и самое дешевое время для их отмены - день до их начала. Если риск проекта очевиден только сейчас, лучше реализовать его сейчас, чем позже. Когда вы вплетаете результаты выполнения расписания обратно в процесс управления портфелем проектов (PPM), вы можете обнаружить, что риск более сложного проекта имеет оценку работы гораздо хуже в масштабе рентабельности инвестиций.
Ловкие... Нет, гибкий проект
Я обещал сказать несколько вещей об управлении проектами Agile, и если вы поклонник Agile, и вы читали так далеко, я ценю ваше терпение. Управление проектами программного обеспечения с помощью метода Agile является чем-то вроде философии, но это все более и более популярная философия среди тех, кто был сожжен на массовых проектах разработки программного обеспечения, которые потерпели неудачу.
В мире гибкой разработки программного обеспечения мы пытаемся разбить наш проект на спринты размером от одной до трех недель, и цель каждого мини-проекта — получить пригодный для использования код. В этом случае мы работаем в рамках некоторых довольно хорошо известных ограничений, с тем чтобы наш уровень разрешения в значительной степени был выбран для нас.
У нас есть период от одной до трех недель, ресурсы доступны для нас, и мы собираемся назначить работу каждому ресурсу. Количество возможных задач, которые мы можем определить в этой структуре, ограничено, и это позволяет сохранить соответствующий уровень разрешения. Да, вы можете возникнуть проблемы в Agile, определив слишком короткие задачи. "Определение поля 1: 10 минут, определение поля 2: 10 минут, определение поля 3: 10 минут" и т. д., но это гораздо реже.
Agile был разработан для корпоративной среды разработки, в которой мы создаем программное обеспечение для собственного использования, и его использование часто распространяется на коммерческую разработку программного обеспечения. (Мы используем метод здесь в HMS для собственной разработки TimeControl.) Гибкий метод дает более маневренный и ловкий отдел разработки, но он не будет применяться к каждой отрасли или даже к каждой программной компании. Если вы выполняете управление проектами в программной среде, я рекомендую ознакомиться с Agile, учиться на нем, а затем принять те элементы (все, некоторые или нет), которые сделают вас наиболее эффективными.
Обертывание
Как и в случае с большинством аспектов управления проектами, нет ответов на вопросы, которые поначалу кажутся столь очевидными. Сколько задач у вас есть в проекте и сколько времени каждая из этих задач должна быть то, что вам нужно искать самостоятельно, чтобы решить ... но решите, что вы должны.
Выбор уровня решения проекта — это ответственность за управление проектами, которая может быть ключевым фактором успеха в управлении расписанием проекта.
Об авторе
Крис Вандерслуис (Chris Vandersluis) — президент и основатель канадской компании HMS Software( Монреаль), сертифицированного партнера Майкрософт. Он имеет степень экономики в Университете Макгилла и более 30 лет опыта в автоматизации систем управления проектами. Он является давним членом Института управления проектами (PMI) и помог основать отделения Монреаля, Торонто и Квебека группы пользователей проекта (MPUG). Публикации, для которых Крис написал, включают Fortune, Heavy Construction News, Computing Canada magazine, PMNetwork PMI, и он является регулярным обозревателем Project Times. Он преподает расширенное управление проектами в Университете Макгилла и часто выступает в функциях ассоциации по управлению проектами в Северная Америка и по всему миру. HMS Software является издателем системы хронометрирования, ориентированной на проекты TimeControl, и с 1995 года является партнером по решению проектов Майкрософт.
С Крисом Вандерслуисом можно связаться по электронной почте по адресу: chris.vandersluis@hms.ca
Если вы хотите прочитать дополнительные статьи Криса Вандерслуиса, связанные с EPM, см. на сайте руководства по EPM HMS (https://www.epmguidance.com/?page_id=39).