Эксперт
Сергей
Сергей
Задать вопрос
Мы готовы помочь Вам.

Кейс Управление содержанием

Михаил, эксперт в области управления проектами, работал в качестве старшего консультанта в Дино Инк, очень известной компании в регионе. Он получил степень доктора наук в области управления проектированием в одном из ведущих университетов и впоследствии стал практикующим специалистом. Михаил, которому не нравилось, когда к нему обращаются «Доктор», работал в области управления проектами во многих компаниях и различных отраслях промышленности – от традиционных производственных фирм до сложнейших аэрокосмических объектов. Недавний клиент попросил Михаила провести семинар по управлению проектами для 30 менеджеров компании. Из-за плотного графика участников семинара было предложено провести один восьмичасовой семинар. Из всего разнообразия инструментов управления проектами (а в практике и теоретической литературе по управлению проектами их насчитывается более 50) Михаил должен был выбрать только самые важные и показать их применение в максимально возможном количестве направлений. Один из инструментов, который он включил в семинар, – техническое задание.

Что такое техническое задание.

Как правило, техническое задание – это документ, кратко описывающий задачи проекта, объем, суммарные затраты и требуемые ресурсы. В разных компаниях детали документа могут варьироваться. Но, по сути, документ отвечает на важный вопрос: «Чем мы занимаемся в рамках этого проекта?» Таким образом, техническое задание дает общее представление о том, чему посвящен проект, и устанавливает изначальные требования, которых необходимо придерживаться в ходе выполнения проекта.

Продуманное описание – половина успеха.

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

  1. Стратегические цели: в этом документе говорится о конечной цели проекта; истории возникновения проекта; владельце или заказчике; о типе крепления, конструкции, комплектации или обучении и т. д. В этом разделе сформулируйте общую цель задачи и включите туда любые значимые данные, которые помогут в описании цели. Например: «Общая цель этого проекта заключается в разработке программного обеспечения для управления проектами, которое позволит за два года завладеть 40 процентами доли рынка». Проект берет свое начало из корпоративного стратегического плана. Цели должны также включать в себя основные обязательства перед клиентом, подраздел, называемый «Цели проекта». В этом разделе четко очерчены сроки выполнения целей, расходы и технические характеристики. Например: «Эта работа будет завершена в течение одного календарного года, расходы составят не более 1 500 000 руб., и в итоге будет составлен отчет». Убедитесь в том, что вы определили приоритетность задач. Эти приоритеты будут служить критериями принятия решений в конфликтных ситуациях.
  2. Тактические цели: в этом пункте должны описываться основные задачи проекта, например, разработка концепции, подробное описание конструкции, поставка протестированной парогенераторной установки в полной комплектации; подготовка инструкций по эксплуатации; обучение персонала владельца и т. д. В качестве примера: «Мы будем разрабатывать, производить, монтировать и вводить в эксплуатацию промышленное предприятие». Данный раздел может иметь от четырех до шести основных ожидаемых результатов, таких как подробная конструкция, прототип и обучение. Эти результаты представляют собой первый уровень в структуре декомпозиции работ (СДР) и в дальнейшем будут разбиты на более подробные элементы/результаты, такие как документация, смонтированные объекты, готовая продукция согласно договору и т. д. Ее описание должно включать в себя количество, комплектность и в каком состоянии она будет доставлена. Объем работ и СДР могут повторять друг друга, чтобы объем работ был полностью отражен в СДР и также, чтобы пункты СДР были описаны в объеме работ.
  3. Ключевые этапы: выявление и определение ключевых этапов, в том числе требуемых сроков завершения работы и критерии завершения. Также в этот пункт могут быть внесены ключевые события, такие как завершение производства (заводом, который изготавливает продукцию), окончание монтажа, окончание тестирования, оформление пакета документов или приемка заказчиком. Перечислите оговоренные в контракте события и другие контрольные календарные сроки, которые имеют решающее значение для завершения работы. Часто эти этапы относятся к ожидаемым результатам/готовой продукции из предыдущего раздела.
  4. Ограничения: перечислите особые технические требования, коды и стандарты, такие как ASME или ISO. Опишите требования к оснащению для производства, монтажа, тестирования или другим средствам для выполнения работы. Определите функциональные/эксплуатационные требования, требования к данным и специальные инструкции. Определите критерии проектирования. Опишите технические ограничения, если они существуют. Ограничения по срокам могут быть связаны с прогрессом выполнения или с завершением работ. В некоторых случаях сроки поставки по графику договора могут быть очень жесткими. Финансовые трудности часто связаны с выделением денежных средств и должны быть выявлены. Требования к оснащению легче спланировать, если известны финансовые ограничения.
  5. Ключевые предположения: при выполнении любой задачи возникает набор предположений и часто сохраняется фактор неопределенности. Необходимо определить и перечислить эти предположения. Если при подготовке описания объема работ какой-то нужной информации пока не хватает, основывайтесь на своем опыте и здравом смысле или спросите тех, кто принимал участие в подобной работе. Например, можно предположить, что тестирование программного обеспечения будет осуществлено с помощью внешних ресурсов или что проектные работы проводятся в соответствии с инструкцией по проектированию. Если предположения сделаны обоснованно, описание объема работ может помочь в разработке других пунктов плана проекта.
  6. Объем работ, прямо исключенный из проекта: описать, что не входит в задачи, что запрещено по условиям договора или не включено в договор по другим соображениям. Если клиент, например, отказывается от проведения эксплуатационных испытаний, то это должно быть указано. Есть много примеров. Укажите работы, которые могут быть связаны с аналогичной задачей, но в то же время не входят в проект. Это поможет проектировщикам, инженерам, менеджерам и клиентам лучше понимать объем работы.

Форма описания проекта (Технического задания).

Стратегические цели: повысить качество обслуживания клиентов на 5% за счет разработки нового программного обеспечения для управления взаимоотношениями с клиентами.

Срок выполнения: до 15 сентября 2010 г. Затраты: $ 150 000. Качество: в соответствии с Соглашением об объеме услуг.

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

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

Ключевые этапы.

  • Проанализировать динамику рабочей нагрузки к 15 марта 2010 г.
  • Завершить конфигурацию к 15 апреля 2010 г.
  • Завершить создание прототипа к 15 августа 2010 г.
  • Закончить обучение к 15 августа 2010 г.
  • Релиз ПО к 15 сентября 2010 г.

Основные ограничения.

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

Основные предположения.

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

Объем работ, прямо исключенный из проекта.

Этот проект не предусматривает обучение навыкам обслуживания клиентов.

 

Ответьте на следующие вопросы в свободной форме.

  1. Какие есть плюсы и минусы у описания проекта?
  2. В каких случаях используется описание проекта?
  3. Нужен ли этот документ для небольших проектов? Почему да? Почему нет?

 

Кейс Управление стоимостью

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

Михаил: На прошлой неделе мне удалось поговорить с другими владельцами компании о проекте строительства гостиничного комплекса, который недавно был завершен. Они хотели, чтобы я обсудил это с тобой и чтобы мы могли внести улучшения в наш регламент для предотвращения подобных происшествий в будущем.  Для начала позволь мне сказать, что за два месяца до окончания проекта мы потеряли приблизительно 100 000 000 рублей на проекте стоимостью 300 000 000 рублей. Итак, с твоей точки зрения, в чем была наша ошибка, которая никогда не должна снова произойти?

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

Михаил: Кто-нибудь в компании проверял оценку Виталия?

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

Михаил: Разве наши оценщики не могли перестроить свой рабочий график, чтобы выделить время для проверки этой важной оценки?

Денис: Я не могу сказать точно, я могу только предполагать. Но если бы наши оценщики хотели проверить оценку этого проекта, они могли бы применить метод, которому мы научились благодаря одному из других наших проектов. Это называется «теневой оценкой». Суть такая – если мы хотим проверить смету для проекта, мы нанимаем консультанта по оценке, просим его разработать смету для проекта, но не показываем ему, что проверяем его работу. Разумеется, предполагается, что оценка консультанта точная. Затем две оценки сравниваются, и если разница равна нулю или значения близки, оценка консультанта является точной. Чем больше разница, тем менее точной считается оценка консультанта. Но есть один минус – консультанту нужно платить.

Михаил: Звучит интересно. Нужно было так поступить с проектом строительства гостиничного комплекса. Я хотел бы узнать еще кое-что. Могла ли помочь обнаружить проблемы с этим проектом на раннем этапе наша система отчетности, основанная на заработанной стоимости?

Денис: Да. Но у нас не было времени, чтобы обучить Виталия нашей системе заработанной стоимости, поэтому он не мог использовать ее в отчете. Вместо этого он сообщил, что он закончил работу, потратил рабочее время и установил кабели и оборудование – на самом деле очень оперативно.

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

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

У тебя есть что добавить?

Михаил: Да. Мне не хватает 100 000 000 рублей, которые потерял Виталий!

Ответьте на следующие вопросы в свободной форме.

  1. Как бы вы изменили работу отдела оценки Компании РКРС, чтобы он мог проверить оценку предложения Виталия?
  2. Каковы плюсы и минусы метода теневой оценки?
  3. Как отчет о заработанной стоимости мог помочь выявить проблемы с оценкой проекта строительства гостиничного комплекса на раннем этапе?
  4. Как мог бы периодический аудит, если бы Компания РКРС использовала его, помочь выявить проблему оценки в проекте строительства гостиничного комплекса на раннем этапе?
  5. Если бы вы руководили Компанией РКРС, вы бы наняли профессиональную компанию по оценке для оценки тендерного предложения данного проекта?

 

Кейс Управление закупками

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

Для Игоря, инженера-конструктора по производственной оснастке, работа была любимой. Он работал на государство, что подразумевало наличие связей. Он работал удаленно, что подразумевало наличие денег, да еще и с иностранцами, поэтому у него были и связи, и деньги. На рабочей площадке он находился вместе с отделом технического обслуживания.  Поскольку в его обязанности входила проверка и обслуживание оборудования, он заметил, что станки с ЧПУ были поставлены с меньшим количеством отверстий, чем было указано в спецификации контракта. Отверстия были маленькие, и общий вес оборудования был меньше. Игорь сообщил об этом своему начальнику Артемию, и он велел Игорю продолжать действовать, как было запланировано изначально.

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

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

Ответьте на следующие вопросы в свободной форме.

  1. Каким образом заказчик и подрядчик должны были договориться, чтобы избежать проблемной ситуации?
  2. Каким образом заказчик и подрядчик должны были договориться, чтобы избежать проблемной ситуации?
  3. Что необходимо понимать заказчику для того, чтобы избежать такой ситуации в будущем?

 

Кейс Управление заинтересованными сторонами

Крупная торгово-промышленная группа инициировала проект по внедрению ERP (Enterprise Resource Planning) системы в штаб – квартире группы и на пяти промышленных и торговых предприятиях. Инициатором внедрения системы выступил Генеральный Директор группы, который обосновал владельцам бизнеса необходимость такой системы, позволяющей консолидировать всю проектную и операционную деятельность группы через единую систему планирования и финансовой отчетности.

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

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

Ответьте на следующие вопросы в свободной форме.

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

 

  1. Предложите руководителю проекта комплекс мер, которые бы позволили реанимировать проект, и довести его до конца.
Была ли полезна данная статья?
Да
64.75%
Нет
35.25%
Проголосовало: 139

или напишите нам прямо сейчас:

Написать в WhatsApp Написать в Telegram