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

Вывод:

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

 
Вывод:

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

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

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

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