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

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

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