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

Вывод:

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

Вывод:

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

Вывод:

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

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

Вывод:

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

Вывод:

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