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

Вывод:

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

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