Есть ли пилот на борту?
"Если есть пилот на борту, он или она, пожалуйста, позвоните им кнопку вызова?" Это то, что пассажир никогда не хочет услышать. Я перечитал замечательную новостную историю из истинного инцидента, как это произошло еще в декабре 2013 года. После того, как пилот полета из Де-Мойна, Айова пострадала экстренная медицинская помощь, другой пилот сделал запрос на всех пилотов на борту. Капитан Марк Гонгол, пилот бомбардировщика B1 в ВОЕННО-воздушных силах США, вошел в брешь. Самолет, пассажиры и экипаж приземлились благополучно.
Это отличная история, но мой возврат, чтобы перечитать его недавно был спровоцирован чем-то очень другим. Потенциальный клиент нашего недавно позвонил и спросил, могут ли они "пилотировать" наш корпоративный проект расписания программного обеспечения. Такие звонки всегда заставляют меня взять паузу. Когда кто-то на самолете говорит "пилот", мы все очень ясно о том, что имеется в виду, но когда кто-то, кто оценивает варианты программного обеспечения говорит "пилот", я не так уверен.
Термин "пилотный" в мире программного обеспечения часто смешивается с другими сложными методами оценки, такими как "доказательство концепции". Давайте посмотрим, что означают эти термины и как их лучше использовать в собственном процессе оценки предприятия.
Подтверждение концепции
Это термин, который восходит к многим годам и популярен в электротехнике. "Хлебная посадка" цепи была сделана, чтобы увидеть, возможно ли канал, а не для того, чтобы начать его создание для производства. В доказательство концепции, вы можете провести больше времени на скамейке лаборатории, чем при создании производственной цепи, но единственный ущерб, который вы могли бы нанести, это плата, над которым вы работали перед вами. Это был недорогой и низкий риск метод доказательства того, что электрическая цепь может дать желаемый результат.
С точки зрения программного обеспечения, доказательство концепции должно быть разработано для того, чтобы что-то доказать. Когда потенциальные клиенты обращаются, чтобы спросить, могу ли я помочь им предоставить подтверждение концепции для корпоративного управления проектами или корпоративного программного обеспечения расписания, у меня всегда есть один и тот же ответ: "Какие концепции вы хотите доказать?"
Обычно это встречается с молчанием и запутанным выражением.
Если вы собираетесь провести доказательство концепции, и у вас нет понятия о том, что вы пытаетесь доказать, как вы будете знать, является ли это успехом или неудачей? Конечно, нет никакой возможности.
Почему, спросите вы, кто-то даже хочет сделать доказательство концепции тогда? Наиболее распространенный ответ заключается в том, что запрашивающий, вероятно, не имеет необходимого выкупа от руководства для реализации программного обеспечения, которое они исследуют, и надеются, что если бы он просто работал перед ними, они бы влюбились в идею и согласились бы, что она должна быть развернута. В этом случае «доказательство» — это управление, а «концепция» — это вся идея корпоративного программного обеспечения.
Если бы было так легко убедить руководство, что корпоративное программное обеспечение для проектов и расписаний отлично подходит для них, мы бы развернули гораздо больше из них.
Проблема с этим методом заключается в том, что работа, которую вы сможете выполнить для развертывания этого экземпляра подтверждения концепции, крайне вряд ли будет иметь ту же поддержку, что и для рабочего развертывания корпоративной системы. Когда организация развертывает корпоративную систему, например расписание или систему управления проектами, для успешного выполнения этой задачи требуется много вещей. Во-первых, необходимо будет предоставить информацию от руководства и линейного персонала для любого аспекта организации, которая связана с развертыванием. Кроме того, потребуется время на настройку, помощь со стороны технических служб для связи с другими корпоративными системами, спонсорство управления, время на обучение и, да, деньги.
Если у вас нет ни одного из этих вещей, то какова будет система, которую вы можете завершить в вашем доказательстве концепции? Это будет тень того, что вы хотите в лучшем случае. В современную облачную эпоху вы, вероятно, можете получить доступ к системе, которая полностью размещена, чтобы вы могли по крайней мере не беспокоиться о покупке серверов и программного обеспечения, но просто установка системы является частью работы, необходимой для выполнения даже базового развертывания системы подтверждения концепции.
Легко понять, почему организация не решается выделять много денег и ресурсов на реализацию чего-то, что может повлиять на всю организацию. Это упражнение с высоким риском. Мы, как правило, говорим только о преимуществах корпоративного программного обеспечения для управления проектами, но легко предположить, что тот же проект, поступив в ошибку, может иметь столь же негативное влияние. Таким образом, снижение риска является очевидной проблемой. Но если реальная задача заключается в том, чтобы убедить руководство в преимуществах системы, то, безусловно, есть лучшие способы сделать это. В HMS Software мы сосредоточились на нескольких из следующих методов:
Поговорите с реальным, уже существующим клиентом.
Мы благословлены здесь иметь некоторых великих клиентов, которые по большому счету вполне удовлетворены. Когда у нового потенциального клиента возникают опасения по поводу того, что он получает, мы получаем организацию вместе с существующим клиентом. Во многих случаях существующий клиент был достаточно щедрым, чтобы предложить провести личное собрание. В других случаях они звонят друг с другом, что мы намеренно не становимся частью. Мы призываем существующего клиента делиться как хорошими новостями, так и проблемами.
Давайте докажем это.
Если у вас действительно есть концепция, которая нуждается в доказательстве, то позвольте нам доказать это вам. Существуют законные причины, по которым некоторые аспекты некоторых реализаций должны быть проверены в первую очередь. Возможно, развертывание будет содержать очень большие объемы определенных данных. Например, нас попросили один раз показать, что наше решение работает с особенно большой нагрузкой проекта. Нам было предложено показать программное обеспечение, работающее с определенными браузерами или с определенными базами данных, или ссылку на определенные версии определенных внешних систем. Если это своего рода концепция, которая блокирует оценку, то лучшие люди, которые могут преодолеть эту проблему, являются предметные эксперты.
Вы можете пройти некоторое обучение с этим.
В случае, когда потенциальный клиент абсолютно должен показать, что система работает со своими данными, используемыми его персоналом, мы помогаем загрузить данные в размещенную систему, а затем сделать как минимум, чтобы настроить систему по желанию клиента и обучить людей, которые будут вовлечены. Мы очень предпочитаем привлекаться в компанию, чтобы помочь с самой демонстрацией, но если это невозможно, мы просим просмотреть сценарий или демонстрацию, которые будут использовать участвующие люди, и попросить помочь скорректировать его или обучить людей, чтобы доставить его.
Где пилот, когда он вам нужен?
А как насчет пилотного проекта? Это лучше, не так ли? Это может быть. Если вам было предложено создать пилотное развертывание корпоративного расписания или корпоративной системы управления проектами, вам следует начать с определения целей. Если цели связаны с подтверждением концепции, то вы вообще не находитесь в пилотной программе.
Пилотный проект — это реальное динамическое развертывание в рабочей среде. Обычно она включает в себя подмножество общей базы пользователей, которая рассматривается для оцениваемой системы, и поэтому пилотная программа, скорее всего, займет некоторое время. Хотя потребности полной целевой базы пользователей учитываются с самого начала, пилотная программа фокусируется на реальной реализации для пилотных пользователей. Они фактически будут управлять своими проектами или фактически заполнять свои расписания с помощью новой системы.
Те же проблемы, с которыми столкнется полное развертывание в рабочей среде, также сталкиваются с пилотной реализацией, за исключением объема или сложности данных. Наиболее распространенные проблемы пилотных проектов, которые я видел, включают отсутствие спонсорства, недостаточный бюджет, время и ресурсы и, вероятно, хуже всего, отсутствие четко сформулированных целей, чтобы узнать, был ли пилотный проект успешным или нет.
Это не значит, что пилотный проект плохой. Выполнение пилотного проекта может быть очень разумным и может помочь снизить риск воздействия на всю организацию при неполном или плохо настроенном развертывании. Но сделать пилотный проект успешным требует некоторого мышления.
Недавно мы начали работу над развертыванием значительного размера для организации государственного сектора. Что приятно в этом упражнении, так это то, что организация уже потратила все время, которое она должна была завершить свою оценку. Они сделали свой выбор корпоративной системы. К счастью, это наше. Мы работали с их командой оценки в течение последнего года, чтобы убедиться, что на их технические вопросы были даны ответы, но теперь основное внимание обращается к влиянию на повседневный процесс сотрудников этой организации.
Они предложили, чтобы мы работали в течение 6 месяцев с группой, которая, хотя и 10 процентов всей группы, все еще составляет около 10 процентов. Существует достаточный бюджет, пилот имеет поддержку управления на самом высоком уровне, и у нас есть достаточно времени, чтобы убедиться, что мы можем помочь во всем, что мы обычно делаем в развертывании, как это. Группа, которая будет помещена в эту среду отслеживания проекта и расписания, будет работать с ней в рабочей среде в обозримом будущем, поэтому это не просто тест. Это больше похоже на первый этап развертывания, а не на упражнение "Попробуйте, и мы посмотрим, как это происходит". При наличии всех этих факторов мы все надеемся на успешный результат в конце этого года.
Обертывание
Пилотные проекты и проекты proof of Concept являются фактом жизни корпоративного программного обеспечения, но если у вас есть один в будущем, вы можете помочь сделать его успешным, чтобы указать на некоторые ключевые факторы успеха для всех участников:
Во-первых, убедитесь, что ваши цели четко сформулированы.
Затем убедитесь, что руководство понимает, что вам нужно, и будет поддерживать вас с точки зрения денег, ресурсов и времени для достижения этих целей.
Наконец, убедитесь, что вы составляют план проекта и управляете им, как и любым другим проектом в вашем портфеле.
Об авторе
Крис Вандерслуис (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 Guidance (https://www.epmguidance.com/?page_id=39).