Телефон Бэтмена

Название этой статьи ссылается на либеральное использование Комиссар Гордон бэтфон всякий раз, когда город Готэм был в тяжелом проливе (из 1970-х "Бэтмен" телесериал).

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

Чтобы скачать версию этой статьи в Word, см. раздел Batphone.

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

Бэтфон

В 1966 году в эфир вышел оригинальный сериал «Бэтмен». Он длился только 120 эпизодов, но он изменил культуру способами, которые продолжаются по сей день. В мире Бэтмена и Робина (в роли Адама Уэста и Берта Уорда), было "летучая мышь" решение для всего. Независимо от того, что проблема, Бэтмен будет иметь решение. Batmobile, Batboat, Batplane, и Batcave все было свое место. И если бы вы были кем-то, кто нуждался в помощи, независимо от того, как трудно, как вы могли бы связаться с Бэтменом? Ну, с Бэтфоном, конечно! Забрать Бэтфон и помочь будет на пути.

Изображение красного Бэтфона (из сериала

Комиссар Гордон обратится к Бэтфону, когда вещи, где безнадежные, что произошло, конечно, каждый эпизод. Это не имеет значения, как трудно вызов, забрать Batphone и через 22 минуты (плюс время для рекламы) злодей будет побежден и Готэм Сити вернулся к мирному статусу.

Каждое решение в мире Бэтмена было сделано, чтобы выглядеть как летучая мышь. Наручники? Летучая мышь в форме. Служебный ремень? Логотипы летучих мышей. Перехватчик? Конечно — похоже на крылья летучей мыши. К моему удивлению, оглядываясь назад на изображения бэтфона он выглядел расстроенно нормально. Красный телефон с циферблатом (помните их?) Я не знаю, почему у него был циферблат. Он назвал только одно место: Бэткав, где спасение было под рукой.

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

Их злодеи разнообразны. Некоторые из них являются техническими; им необходимо обновить версию x до версии y. Некоторые из них являются архитектурными; они должны заставить свою внутреннюю систему EPM общаться с пользователями во внешнем мире. Некоторые из них являются культурными; пользователи отказываются использовать систему. И некоторые из них являются процедурными; процесс, за который они следят, кажется, не обеспечивает ожидаемый результат.

Независимо от того, что вызов, запрос для консалтинговой фирмы тот же: можете ли вы исправить его за 22 минуты?

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

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

Попадая в беду

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

  • Недооценка проблемы Это, безусловно, самая распространенная ошибка в развертывании EPM. Это не значит, что каждое развертывание должно быть большим и сложным. Это, конечно, не всегда так. Но, возможно, из-за желаемого за действительное, невероятно часто недооценивать, что потребуется для получения преимуществ от развертывания EPM. Первая ошибка при заниждении — выбор целевого объекта. Некоторые пользователи выбирают установку средства как успешный проект. Конечно, нет. Некоторые пользователи выбирают первое использование средства или первый отчет, который выходит из него в качестве целевого. Это тоже не все. Решение любых проблем, для которых были выбраны средства EPM, — это место, где вам нужно нацелиться. Это означает, что язык изменился, обучение завершено, использование в рабочей среде, инструменты работают, данные есть. Да, это может быть большой вещью, но если вы на один дюйм от этой цели, у вас по-прежнему ничего нет. (Ну, почти ничего, так или иначе.)

  • Сделать его техническим проектом Для тех из нас, кто в технологическом бизнесе, мы наиболее виновны в этом, и на самом деле, большинство из нас знают лучше. Тем не менее, как-то искушение поверить, что доступность технологий означает, что проблема решена, трудно устоять. Так что многие организации, которые мы посещаем, говорят некоторые варианты", но мы установили Project Server, почему наш персонал перегружен? Как мы уже говорили в течение некоторого времени, создание корпоративного управления проектами — это сочетание людей, технологий и процессов, а также большое количество управления изменениями, брошенное для хорошей меры. Это не происходит автоматически, когда программный DVD-диск проходит через дверь.

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

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

  • Не применяется управление проектами к системе управления проектами Если вы читали что-нибудь, что я написал, скорее всего, вы видели это раньше. Руководители проектов восприимчивы к синдрому "сапожника, чьи дети босиком". Результатом является общее отсутствие устава проекта, утвержденного бюджета, отслеживаемого расписания, выделенных ресурсов и всех других средств для собственного проекта, которые являются общими для всех других проектов, которыми они управляют.

Чего они ожидали?

Хорошо, вот как люди так часто попадают в беду. Преимущества, ожидаемые руководством от развертывания системы EPM, обычно приходят непосредственно из бизнес-задач. Это обещание решения этих проблем, которые приводят к тому, что руководство будет утверждать расходы на программное обеспечение, оборудование, инфраструктуру и, возможно, даже услуги. Наиболее распространенные из этих проблем могут показаться знакомыми:

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

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

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

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

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

Разделы справки держаться в беде?

Вы не хотите, чтобы когда-либо добраться до точки, когда вы чувствуете, что вам нужен Бэтфон. Итак, что можно сделать со средой EPM, чтобы не оказаться там?

Хорошо, все, что мы сказали в первом разделе, очевидно:

  • Сделайте хорошую оценку

  • Не думайте, что EPM — это просто технический проект

  • Привлечение высшего руководства с самого начала

  • Создайте реалистичный график и дайте ему проверку реальности, сравнив его с другими в вашей отрасли

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

Что еще можно сделать?

Во-первых, начните проект с пониманием того, что в какой-то момент в будущем вы захотите использовать Batphone. Вы. Зная это, одна вещь, которую вы можете сделать, это бюджет на помощь, что у вас нет текущего плана. Мы рекомендуем нашим клиентам выделить от 10% до 20% от проекта для "нераспределенных требований". "Зачем это?" Нас всегда спрашивают. "Вы скажете нам позже", мы всегда отвечаем. Обычно не использовать все эти деньги. Но это также невероятно часто использовать некоторые из него. Наличие квалифицированного эксперта, уже выделенного и бюджетного бюджета для вашего проекта, значительно изменится позже.

Начните с ожидания, что план и люди изменятся. Мой любимый проект руководства цитата из Наполеона Бонапарта, который сказал: "План битвы длится до контакта с врагом". Это верно и для планов EPM, тоже. Учитывая, что реализация, скорее всего, продлится несколько месяцев, вероятность того, что некоторые сотрудники изменят план, огромна. Итак, планируйте избыточность.

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

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

Поместите это в письменном виде

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

  • Бизнес-вариант Я не знаю, что речь идет о первоначальном бизнес-случае, который делает его настолько непривлекательным, но это самая распространенная вещь, чтобы потерять отслеживание и во многих отношениях, это ядро, почему у вас есть среда EPM в первую очередь. В бизнес-случае отмечается ожидаемые преимущества организации; чего организация ожидает от системы EPM? Когда мы получаем телефонный звонок, одна из первых вещей, которые мы спрашиваем, это: "Что система, как ожидается, будет доставлять для вас?" Мы не просто спрашиваем администратора. Мы также запрашиваем руководство, пользователей и бенефициаров бизнеса. Наиболее распространенный ответ — это ответ, отличный от каждой стороны. Это потому, что первоначальная бизнес-предпосылка стала потеряна.

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

  • Руководство по процессу и блок-схема Это часто забывается, когда мы приступаем к процедурным руководствам. Люди остались шаги "Что делать" в руководстве по процедуре, но не контекст того, почему эти шаги важны и что мы делаем с результатом каждого шага. Руководство по процессу и, что лучше всего, визуальная блок-схема, позволят будущим руководителям понять, что предоставляет система, и значительно облегчит адаптацию системы в будущем.

  • Критерии выбора системы При выборе системы EPM и любых сторонних средств, которые вы могли выбрать на этом пути, сообщите будущим поколениям, на чем основано ваше решение. Мы пошли в организации через 5, 7 или даже 10 лет после развертывания системы и увидели систему с несколькими инструментами, связанными с ней, и спросили: "Почему вы делаете это? Было бы гораздо проще сделать это!" Причины этих решений нигде не найдены. В некоторых случаях клиент потратил годы, делая что-то в чрезвычайно сложной манере, что могло бы быть гораздо проще, учитывая более текущие версии существующих инструментов. Они не могут принять простое решение изменить инструмент или использовать более текущую версию, потому что у них больше нет доступа к тому, почему они решили сделать что-то определенным образом много лет назад.

Там действительно нет Бэтфона.

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

  1. Прислушайтесь к советам, которые вы получаете. Глупо платить эксперту, чтобы дать вам совет, а затем решить, что вы знаете лучше, чем они. Если вы собираетесь попросить совета и вы имеете дело с экспертом, попробуйте выслушать и, по крайней мере, рассмотреть совет. Бэтмен не продолжал бы появляться к комиссару Гордону снова и снова, если бы каждый раз он делал это, Гордон сказал: "Теперь, когда вы здесь, Бэтмен, пожалуйста, сделайте то же самое, что и все мои другие полицейские делают".

  2. Бэтмен может сделать это за 22 минуты, но вы, вероятно, не будете. Если вы звоните эксперту, пусть он скажет вам, сколько времени должно занять, чтобы решить вашу проблему. Вы можете выбрать не исправлять это после того, как он закончит, но устранение проблем EPM, даже технических, редко занимает всего несколько минут. В конце концов, Бэтмен должен был сделать это за 22 минуты, потому что 8 минут были выделены для рекламных роликов, и они необходимы.

  3. Комиссар Гордон никогда не говорил Бэтмену решение, только проблема. Слишком часто мы получаем звонок от панического администратора EPM, который знает, что мне нужно применить исправление, написать отчет и обучить двух человек. Я всегда слушаю это терпеливо, а затем прошу клиента описать проблему, как они только что описали мне решение. Прежде чем взять трубку, чтобы позвонить эксперту, сначала подумайте о том, какую проблему вы хотели бы положить на их стол.

Заключение

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

Об авторе

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