Ситуация:
Вы руководитель крупного проекта внедрения CRM системы. Вы определились с внедряемой системой, однако пока не определились с компанией-интегратором, которая будет внедрять эту систему в вашей компании. Т.к. компаний занимающихся внедрением выбранной CRM системы на рынке множество, в настоящий момент, у вас в компании проводится тендер по выбору подрядчика, который сможет провести работы по внедрению CRM, а также необходимые организационные преобразования. Вы сформировали критерии, по которым будете оценивать подрядчика (опыт успешных проектов внедрения CRM систем, квалификация предоставляемой на проект внедрения команды, наличие в компании подразделения по контролю качества, наличие сертификата ISO 9001:2000, и т.д.) и проставляете веса критериев. Среди руководства компании есть несколько заинтересованных во внедрении CRM системы лиц. Памятуя урок №61 о целях проекта и заинтересованных лицах вы провели с ними беседу, подробно рассказав о планируемых действиях и целях проекта, а затем разослали им анкету с критериями оценки поставщиков, с просьбой проставить каждому критерию вес. Результатом анкетирования должны стать оценочные критерии с весами. Далее, вы планировали провести оценку поставщиков по выработанным критериям, выделить первую десятку, разослать им RFP и пригласить для участия в тендере. В ответ получаете вопросы: "По какой методике происходит оценка? Какие максимальные и минимальные веса? Есть ли разбивка оценок по категориям?"

Вывод:

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

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

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

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

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

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