Отслеживать или рассуждать: технический документ

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

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

Отслеживать или рассуждать

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

Распространенность планирования вместо управления

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

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

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

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

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

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

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

Что означает отслеживание?

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

Определение процентного значения

Если руководитель проекта говорит: "Мы примерно на полпути", то мы знаем, что выполнили приблизительно 50 процентов запланированной работы. Хотя это можно назвать отслеживанием и это лучше, чем не отслеживать проект вообще, полезность таких данных весьма низка. Если бы в соответствии с планом я должен был завершить задачу за 10 дней и сообщил, что она выполнена на 50 процентов, средства управления проектами, такие как Microsoft Project и Project Server, сделали бы определенные предположения. На основе имеющихся ограниченных данных они бы рассчитали, что на работу затрачено 5 дней и осталось еще 5 дней работы. Возможно, это верно, но может быть и так, что на выполнение 50 процентов работы вам потребовалось 20 дней, а значит на завершение задачи, вероятно, уйдет еще 20 дней.

Оценка оставшегося объема работы

В старом комедийном фильме "Прорва" с Томом Хэнксом в главной роли была бригада работников, которые никогда не могли завершить начатое. Когда у них спрашивали: "Когда вы закончите работу?", они неизменно отвечали: "Через три недели".

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

Оценка затраченных усилий

Один из способов оценки хода выполнения — определение затраченного времени. Иногда этот показатель называют масштабом работ (LOE). Масштаб работ дает неплохое представление о фактической скорости работы над проектом, но имеет одно слабое место. С одной стороны, этот метод позволяет ясно понять, сколько усилий было затрачено на выполнение задачи на данный момент. С другой стороны, может быть не совсем понятно, сколько осталось сделать. Занимаясь разработкой продуктов для управления расписаниями, мы часто имеем дело с организациями, пытающимися внедрить этот метод. Какое-то время наши специалисты считали, что его целесообразно использовать только в сочетании с другими более изощренными приемами отслеживания проектов, но опыт показал, что зачастую он вполне самодостаточен. "Если бы мы могли определить, на что тратится наше время, — сказал мне однажды клиент, — мы могли бы гораздо яснее представить, как движется работа, и практически сразу повысить эффективность". И он был прав. Мы реализовали расписание, которое позволяло отслеживать время выполнения запланированных задач, и это само по себе существенно повысило эффективность наших клиентов. Позднее они смогли внедрить дополнительные методы отслеживания, чтобы еще более увеличить производительность.

Мы собираемся использовать метод освоенного объема

Метод освоенного объема был разработан примерно 30 лет назад для управления крайне сложными проектами, однако его базовая концепция проста. Если мы составляем бюджет для задачи, то вне зависимости от затрачиваемого времени мы не можем освоить более чем 100 % бюджета. Метод освоенного объема ориентирован на отслеживание процента завершения "физических" работ: для некоторых типов проектов он подходит, для других — не совсем. Например, если вы строите дорогу и вам нужно сделать 100 километров, то достигнув отметки в 50 километров, вы можете считать, что проделали половину работы. Но если при этом вы потратили 75 % общей отведенной суммы, то у вас большие проблемы, и метод освоенного объема делает это очевидным. Это означает, что, завершив работу, вы, вероятно, превысите бюджет на 50 %.

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

Проекты "последней стадии"

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

Как представляются эти показатели

Вне зависимости от используемого средства управления проектами отображение хода выполнения обычно является стандартным элементом. Ниже приведен снимок экрана с окном Microsoft Project, на котором показана одна полоса хода выполнения со значением 50 %:

Отрезок диаграммы Ганта с процентом выполнения 50 %

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

Диаграмма Ганта с направляющей

Здесь мы можем видеть, что на данный момент задача должна была быть выполнена на 50 % и так и есть, но началось ее выполнение на неделю позже. В правой части видно, что мы затратили 50 % запланированного времени и (с учетом выходных) заполнили 50 % полосы. Если бы мы ввели трудозатраты ресурсов, то на данный момент у нас было бы 80 часов трудозатрат, а израсходовано было бы 40 часов. Это приемлемые цифры, если рассматривать задачу изолированно, но даже хотя задача выполняется с планируемой скоростью, такие сроки могут негативно сказаться на последующих задачах.

Хорошо, я отслеживаю проект, что дальше?

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

Если x, то y

Под этим я имею в виду то, что эффективное отслеживание должно следовать причинно-следственному принципу: если происходит x, то необходимо предпринять действие y.

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

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

Рисковать или отслеживать

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

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

"Я не понимаю, — заявил старший вице-президент, — почему при получении сведений из расписания состояние выполнения задач не обновляется соответствующим образом".

"Если бы у меня была задача, рассчитанная на 40 часов, и я бы выделил 40 часов из расписания на эту задачу, каким был бы результат?" — спросил я.

Вице-президента этот вопрос привел в замешательство.

"Думаю, задача была бы завершена", — сказал он.

"А что если нет?" — поинтересовался я.

"Я не понимаю, — ответил озадаченный вице-президент, — если задача рассчитана на 40 часов и на нее было затрачено 40 часов, то она должна быть завершена".

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

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

Отслеживание проекта может дать преимущества не только его руководителям, но и всей организации.

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, которая является партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×