Записи

Управление проектом: часть 4 — контроль

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

Это завершающая часть статьи про Управление проектами. Первая часть здесь, вторая здесь, третья здесь

Контроль в проекте

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

Читать/смотреть далее

Как управляется PLM программа PHENIX в EADS

В прошлых статьях по программе PHENIX мы разобрали организационный ландшафт и убедились в его невероятной сложности, обсудили цели и задачи программы. Очевидно, что в таких условиях программа жизнеспособна только при условии грамотно выстроенного управления.
Давайте обсудим все с организационными диаграммами в руках!
 structure

Читать/смотреть далее

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

После просмотра фильмов «Каждое воскресение» и «Огни ночной пятницы» мне непременно захотелось узнать, что же такое Американский футбол. Мое знакомство с ним началось с Супер Кубка 2008, после которого я стал фанатом команды New York Giants и по сей день я не пропускаю ни одной их игры. За это время я узнал много «тонкостей» футбола, и повторный просмотр фильмов был значительно интереснее нежели первый. Понимание правил и сути самой игры заставили меня смотреть на фильм с разных сторон, открылась вся его красота и смысл. Помимо красоты на поверхность вылезли и откровенные «ляпы» переводчиков фильма, когда, например, квотербека называли полузащитником. Это говорит о том, что люди, отвечающие за перевод, не знали игру, не знали термины и правила – не знали предметную область. Понимание предмета позволит Вам рассматривать его с разных сторон и убережет от многих ошибок.

Читать/смотреть далее

Управление проектом: часть 3 — выполнение

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

Это продолжение статьи про Управление проектами.Первая часть здесь, вторая здесь.

Выполнение проекта

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

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

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

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

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

  • Определение текущего состояния дел в проекте;
  • Определение невыявленных требований и работ в проекте;
  • Определение рисков проекта на текущем этапе его выполнения.

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

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

Управление проектом: часть 2 — планирование

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

Это продолжение статьи про Управление проектами. Начало здесь.

Планирование в проекте

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

В предыдущем разделе («Общие принципы организации проектных работ») мы уже говорили о том, что обычно проект разбивается на несколько временных отрезков, в рамках которых выполняется планирование. Продолжительность каждого из этих отрезков устанавливается по-разному. Она может определяться исходя из времени, необходимого для завершения определенного этапа работ (для этапов), или же задаваться определенным календарным промежутком времени – неделей, месяцем (для итераций).

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

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

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

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

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

При планировании проекта, и в частности, при планировании работ в проекте, очень важное место отводится определению и документированию требований к результатам работ, и в особенности – требованиям к качеству. Для каждой из работ, включенной в план, у нас должны быть определены критерии приемки результата. Критерии приемки могут разрабатываться как для групп задач, включенных в план, так и для отдельных задач. Например, для задачи разработки эскизного чертежа детали критериями приемки результата могут являться результат проверки эскизного чертежа экспертной группой и соблюдения правил соответствующей серии ГОСТ при разработке чертежа. Важно помнить, что задача может считаться выполненной только тогда, когда соблюдены все требования к результатам работ для этой задачи. В случае если эти требования не выполняются, необходимо отвести определенное время на доработку, в результате которой будет достигнут нужный результат.

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

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

Управление проектом: планирование, выполнение, контроль — часть 1

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

Общие принципы организации проектных работ

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

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

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

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

Этапы проекта связаны с завершением определенного вида работ (проработка требований, проектирование всего продукта или отдельных его подсистем и узлов, производство опытного образца или опытной серии, тестирование полученного образца в лаборатории и приемка результатов, пользовательское тестирование, доработка при необходимости и повторная приемка, подготовка к запуску в производство). Этапы проекта могут иметь длительность несколько месяцев и более.

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

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

Куда съездить Главному конструктору и Заместителю директора по науке в Сентябре 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 подозревают, что сейчас люди разучились читать длинные тексты и сократили его :-)

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

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

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

База рисков PLM проекта: Вам заплатили? Вот вы и внедряйте!

Сотрудники некоторых предприятий относятся к проекту PLM как к проекту укладки кафеля. Кафель закуплен, узор в виде китайского орнамента со вставками из золотых слитков утвержден, все! После этого заказчику в совмещенном санузле не место.

 

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

 

Очень занятые люди

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

 

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

 

Как минимизировать этот риск

Поэтому, стоит заранее решить этот вопрос с руководством, менеджерами и инженерами. Решать его можно в нескольких аспектах:
  • Получить личные письменные гарантии от топ-руководства предприятия.
  • Добиться назначения молодого, энергичного и профессионального менеджера PLM проекта со стороны Заказчика.
  • Отдельно собрать и «зажечь» PLM проектом больше десяти человек ИТР моложе 35 лет.
  • В договоре на внедрение PDM/CAx явно прописать объем привлечения сотрудников предприятия и предусмотреть денежные штрафы за срыв привлечения.
  • Вести таймшиты участия сотрудников предприятия в проекте внедрения PLM.
  • На предприятии должны быть назначены премии за деятельное участие в проекте, в объеме не менее 50% общего размера премии.
  • Раз в две недели информировать всех сотрудников о ходе проекта с помощью стендов и рассылок.

Будьте начеку!

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

Сталкивались ли вы с такой ситуацией? Или описанная ситуация не встречается в жизни? Напишите Ваше мнение на нашем форуме.

Анатолий Суздальцев
Мы продолжаем цикл статей про риски в PLM проектах. Этот проект безусловно важен для отрасли. Если Вы хотите принять участие и описать риски, с которыми сталкивались в своих проектах, обязательно напишите нам.
Анатолий Суздальцев

Портфолио