Lessons Learned - раскрой свой опыт управления проектами

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

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

Вывод:

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

Вывод:

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

Вывод:

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