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

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

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

Отслеживание или лечение

Это сезон Хэллоуина здесь в Северная Америка поэтому я думал, что мы поговорим о чем-то страшном: отслеживание наших проектов. Что? Это не страшно, что ты говоришь? Сведения из поля могут отличаться.

Планирование не управление по-прежнему настолько распространено

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

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

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

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

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

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

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

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

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

Угадывание в процентах

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

Измерьте, сколько осталось

Много лет назад темный комедийный фильм под названием "Денежная яма" с участием Тома Хэнкса признакам экипаж дома подрядчиков, которые никогда, казалось, не было сделано. Бегущий кляп через весь фильм был ответом на "Когда вы будете делать?" "Еще три недели" все подрядчики скажут.

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

Измерьте, сколько мы потратили

"Я провел 10 дней до сих пор", является одним из способов посмотреть на прогресс. Иногда называется LOE или "Level or Effort". Уровень усилий является отличным способом посмотреть на нашу фактическую скорость ожога, но он несет в себе слепой стороны. Что касается хорошей стороны этого метода, у нас есть хорошее представление о том, сколько мы потратили на эту задачу до сих пор. С плохой стороны, мы, возможно, не имеем большого понимания того, что осталось сделать. Находясь в компании расписания, мы часто имеем дело с организациями, пытающимися реализовать этот метод. В свое время наши сотрудники считали этот метод подходящим только в сочетании с другими более сложными методами отслеживания проектов, но нам было показано, что он часто очень сильный только сам по себе. "Если бы мы могли просто определить, где идет наше время", сказал мне клиент, "это поставило бы нас так далеко впереди того, что мы делали, мы могли бы стать почти мгновенно более эффективным". Он тоже был прав. Мы реализовали расписание, которое позволяло отслеживать время для выполнения запланированных задач и само по себе сделало организации чрезвычайно эффективными. Позже они смогли добавить дополнительные методы отслеживания, чтобы еще больше повысить свою производительность.

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

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

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

Проект «Слоновая кость снега»

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

Как все это будет выглядеть?

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

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

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

Ладно, я отслеживаю, теперь что?

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

Если x, то y

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

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

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

Трюк или отслеживание

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

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

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

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

VP посмотрел на смущенный вопрос.

"Я ожидаю, что это будет завершено", сказал он.

"Но что, если это не так?" Я ответил.

"Я не понимаю", сказал теперь расстроенный VP. "Если это 40-часовая задача и вы выполнили 40 часов работы, то она должна быть закончена".

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

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

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

Об авторе

Крис Вандерслуис (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).