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

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

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

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

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

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

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