Куда съездить Главному конструктору и Заместителю директора по науке в Сентябре 2014 года

Первый раз я оказался на IPMA World Conference в 2010 году. Не знаю, что я ожидал увидеть. Наверное, занудные обсуждения стандартов и восхваления своих ИТ систем для управления проектами. В общем, то же, что часто происходит на аналогичных мероприятиях в России.

В реальности — несколько одновременно идущих треков насыщенных новыми идеями, результатами исследований. Например, то что тогда удалось увидеть и услышать мне: психологические аспекты управления проектами, системы метрик инжиниринговых проектов, модель для оценки качества Технического задания, исследование влияния офиса управления проектами на корпоративную культуру, опыт развития R&D, формализованная модель оценки сложности проекта и многое другое.

Все направлено на то, чтобы понять, как достигать целей проектов.
И не просто достигать, а:
  1. без провалов, достигая нужной (несущей ценность) цели;
  2. без перерасхода на это времени и/или денег (что, собственно, одно и то же);
  3. без токсичных отношений, негатива и ругани, наоборот — с развитием человеческих отношений.

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

В первую очередь на предприятии это важно для директора, главного конструктора, главного технолога, начальников конструкторских отделов и групп, директора по науке и для многих других!

Дайте им прикоснуться к свежему источнику новых знаний, увидеть людей, которые тоже управляют проектами в Нидерландах, США, Японии, Индии, Австралии, Германии. Отправьте своих руководителей по науке и разработкам на эти мероприятия. Цена вопроса — 2000-3000 USD на человека, а ущерб, который наносится даже всего лишь одному предприятию косными процессами, отсутствием видения, низкой мотивацией исчисляется миллионами и десятками миллионов долларов. Если визит на эти мероприятия позволит начать решать хотя бы 1-2% этих проблем, то эта поездка уже окупится многократно.

Ключевые два мероприятия, которые я лично советую посетить:

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

Мы также будем публиковать важные и интересные материалы по управлению проектами. Не забудьте зарегистрироваться, если вы еще этого не сделали.

Если принятие решения о поездке на эти конференции зависит не от вас, и вы не знаете, как обосновать эту поездку для своего руководства — напишите об этом мне в plm.center, и я помогу подобрать аргументы.

Хочешь внедрять PLM профессионально — осваивай предметную область

Дураки и дороги

Как известно, «в России две беды — дураки и дороги». И если по дорогам (а также разгильдяйству и бюрократизму) можно ударить автопробегом, то что делать с первой бедой? В PLM проектах зачастую возникают конфликты между его участниками, связанные с недопониманием друг друга. А некоторые ситуации приводят к серьезным проблемам.

Трудности перевода

Даже если принять как факт, что Заказчик бесконечно хорошо разбирается в бизнес-процессах предприятия, а Исполнитель в совершенстве знает инструмент, который он внедряет, мы все равно сталкиваемся с трудностями взаимопонимания:

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

02 Client&Imlementor

Проблема взаимопонимания Заказчика и Исполнителя всегда является источником одного из самых опасных рисков проекта – неконтролируемого увеличения его границ (Project scope).

Принтер не печатает gif анимации

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

Как известно, бухгалтера имеют дело с огромным количеством бумаги. Выяснив, что при подготовке документов тратится сто тысяч миллионов бумаги формата А4, руководитель решил, что назрела оптимизация. Все его требования сводились к «крутому принтеру, который быстро печатает с двух сторон». Такое задание и было поставлено перед IT специалистами.

Итог: купили супер принтер (с максимальным количеством печати бумаги в минуту) с бюджетом чуть больше чем «Очень дорого». Он умел даже раскладывать по копиям и сшивать скрепками.

Через некоторое время его эксплуатации стало понятно, что все его «крутые фишки» не востребованы, а принтер не был рассчитан на большой объем печати. Это яркий пример того, что Заказчик не описал свои потребности, а Исполнитель, не зная их, и, особо не утруждаясь, просто выбрал самый «типовой» вариант.

03 Print

Что делать и кто виноват

Выходит, что самая идеальная ситуация в проекте — это когда:

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

По какую сторону баррикад проекта внедрения PLM вы бы не находились, если хотите это делать профессионально, осваивайте предметную область. Иначе границы вашего проекта гарантировано «поплывут» в сторону увеличения.

Простой шаг к освоению предметной области

Вы сейчас читаете одну из цикла заметок, посвященных изучению предметной области машиностроения.
Заметка представляет собой сокращенный вариант статьи, потому что редакторы plm.center подозревают, что сейчас люди разучились читать длинные тексты и сократили его :-)

Поэтому, я жду вас на вебинаре «Что не знает команда проекта о предприятии».

Записывайтесь — будет интересно!

Евгений Ураски