Управление поставками проекта

Как контролировать работу подрядчиков

0

В группе Project Managers in Ukraine подвели итоги дискуссии на тему “Как контролировать работу подрядчиков”:

  • Совет-1 Детальные требования (со стороны заказчика)
  • Совет-2 Детальные спецификации на все(!) результаты работ подрядчика. Спецификации должны быть написаны четко и ясно!
  • Совет-3 Подрядчик детально документирует описание процесса разворачивания системы. Набор документов стоит согласовать заранее
  • Совет – 4 Тщательно планировать выбор подрядчика еще до заключения договора. Необходимо проверить рекомендации, получить личное впечатление (стиль работы, зрелость процессов).
  • Совет – 5 Контракт - один из главных инструментов контроля. Заключать FP контракт с адекватными штрафными санкциями и четко проработанными основными и дополнительными положениями.
  • Совет – 6: Разделить проект на несколько этапов, в рамках которых либо получается один из финальных результатов проекта, либо уточняются требования к конечным результатам (Проектирование, Прототип).
  • Совет – 7: Провести тщательное планирование проекта. Проверить результаты планирования на всех уровнях (работы заказчика, подрядчика, субподрядчика).
  • Совет – 8 (добавил) Умеренно прессовать подрядчиков по цене чтобы не создать ситуацию когда снижение цены приведет к обнулению запасов на риски и к середине проекта модрядчик может потерять мотивацию выполнить проект либо он осознанно пойдет на снижение качества не предупредив вас. Резкий пресс по цене может в итоге больно ударить по вам – скупой заплатит дважды.

Примечание. Полезность Совета-7 была оспорена. Так что если кто-то тщательно планировать не хочет, можно этого не делать.

Дискуссию вел Евгений Петров, руководитель сектора управления проектами Киевстара.

Принято!

0

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

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

Какие документы (артефакты) нам нужны:

  • План приемочных испытаний – перечень того что включается в приемку. В идеале план должен быть согласован в проекте как можно раньше – в самом начале разработки когда есть согласованное ТЗ, проработана архитектура и согласован план проекта.
  • Форма приемочного теста – описание того что и каким способом принимается. Содержит ссылку на требования. Если сослаться на другой источник – описания требований и тестовых кейсов – то форму можно слить с планом приемочных испытаний.
  • Реестр приемочных замечаний – с первого раза обычно не выходит (не забудьте учесть это в плане проекта)
  • Протокол приемочного тестирования – здал-прынял :-) Может строиться как документ-шапка к плану приемочных испытаний.

Если приемочное тестирование подразумевает кроме тестирования качества еще и соответствие по денежным и временным показателям – то необходимо предоставить план-факт анализ выполнения работ по созданию переданных на приемочное тестирование результатов проекта.

О методах приемочного тестирования:

  • Тестирование заказчиком самостоятельно – заказчик уходит в себя и выдает результат. Это рискованно в том плане что у заказчика может не быть профессиональных ресурсов, загрузка по текущим задачам может растянуть процесс приемки. При тестировании заказчик может “выбиться” из колеи – и уйти строить воздушные замки вместо тестирования по требованиям.
  • Тестирование (Аудит) третьей стороной – для этого круто нанять специализированную компанию на тестировании или подписать договор с конкурентом вашего поставщика на оказание услуг аудита. Последнее жестко и рискованно – зато не даст никому расслабиться :-)
  • Совместное тестирование по сценариям с заказчиком – поставщик помогает готовить пакет материалов для приемочного тестирования, готовит команду заказчика к методичному приемочному тестированию, контролирует ход приемочного тестирования и сроки его выполнения. Присутствие инжинера по тестированию со стороны исполнителя поможет лучше зафиксировать расхождения, замечания и не дай бог выявленные дефекты.

Компоненты информационной среды управления проектами

0

Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.

Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.

Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)

Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM  2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)

Календарь проекта и Фактические данные – тут рулит Microsoft Project.

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

 

NASA Guidance for writing Work Statement

0

http://www.hq.nasa.gov/office/procurement/newreq1.htm

DoD Handbook for Preparation of Statement of Work

0

DOD Handbook For Preparations of  SOW.pdf

Критичность закрытия фаз/итераций. Пример из практики

0

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

 

Сам факт закрытия фазы позволяет:

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

Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что

  • аналитический документ и зменился более чем на половину
  • объем работ вырос в полтора раза
  • было потеряно около трети времени на разработку в следствии кардинального изменения
  • существенно изменились сроки проекта
  • поставщик понес убытки на потерянном объеме работ
  • клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
  • клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта

Производить или закупать? Плюсы и минусы делать самим

0

Когда в компании запускается очередной проект – всегда возникает вопрос со стратегией его выполнения:

  • Делать полностью самим
  • Отдать на outsource (объявить тендер, отдать большую часть работы подрядчику)
  • Промежуточный вариант – около половины  работ выполняется внутри компании (как правило это проектный менеджмент, анализ и тестирование) а остальное – по прямым контрактам с фрилансерами или небольшими компаниями.

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

Делать самим – плюсы:

  • Полный контроль над ресурсами
  • Низкая стоимость ресурсов (в большинстве случаев это так – если за управление проектом не берется менеджмент с очень высокими зарплатами)
  • Конфиденциальность выше
  • Накопление и сохранение опыта (если нет высокой текучести кадров)

Делать самим – минусы:

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

Типичная ситуация – развитие ИТ системы, которое требует выполнения множества мини проектов по изменению или небольшой доработке. Такие проекты не требуют уникальной и/или высокой квалификации ресурсов. Например – долгосрочная программа по развитию внутреннего корпоративного портала или системы документооборота. Для изначального развертывания и проектирования архитектуры уместно будет привлекать внешнего подрядчика с передачей опыта дальнейшей поддержки решения внутренней команде разработки.

Снижение качества продукта в проекте

0

Хотите снизить качество продукта в проекте?

  • Безбожно давите на сроки, поставьте их нереальными и прессуйте
  • Снижайте стоимость, давите поставщиков до истощения
  • Вовлекайте ваших сотрудников в 5 проектов одновременно
  • Не в коему случае не доверяйте людям в проекте
  • Увеличьте бюрократию в проекте
  • Людей их проекта рассадите в разных комнатах в пяти корпусах.
  • Писать требования? Зачем! Это бумагомарательство. И завтра все равно мы что-то переделаем. А принимать будем когда более-менее будет готово.
  • Ни в коем случае не тратьтесь на тестировщиков. Разве и так не понятно что это должно работать?

Кросс-пост.

Области знаний PMBoK

0
  • Управление интеграцией проекта
  • Управление содержанием проекта
  • Управление сроками проекта
  • Управление стоимостью проекта
  • Управление качеством проекта
  • Управление человеческими ресурсами проекта
  • Управление коммуникациями проекта
  • Управление рисками проекта
  • Управление поставками проекта
Go to Top