Ситуация:

Вы - руководитель проекта внедрения ИТ системы. Проект на стадии описания требований. Часть работ выполняется вами. Однако, несмотря на обещание подрядчика предоставить сотрудников для проекта на полный день, вы, зачастую не можете дозвониться до менеджера проекта со стороны подрядчика, т.к. он находится на встречах по другим проектам.

Вывод:

Исследуйте необходимость привлечения сотрудников подрядчика на полный рабочий день еще на стадии согласования договора. Учтите, что неполный рабочий день подрядчика на проекте может сильно усложнить коммуникации, в том числе, и увеличить срок ответов на ваши вопросы. Если вы видите необходимость в работе подрядчика на основе полного рабочего дня на вашем проекте - фиксируйте это в договоре.

Ситуация:

Вы - руководитель проекта внедрения ИТ системы. Вы заключили договор на внедрение, при котором оплата подрядчику идет следующим образом: 50% предоплата, 35% в середине проекта и 15% по завершению проекта. После второй оплаты вы заметили, что вашему проекту уделяется все меньше внимания, и возникли типовые проблемы внедрения: персонал подрядчика расслаблен, а часть людей даже перевели на другой проект, возникла опасность запаздывания по срокам, а проблемы с подрядчикам решаются с каждым днем все сложнее.

Вывод:

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

Ситуация:

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

Вывод:

Использование глоссария в документах поможет всем заинтересованным сторонам одинаково понимать написанное в документе, а вам избежать многих проблем внедрения.

Ситуация:

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

Вывод:

По окончанию тендера постарайтесь подстраховаться. Не отказывайтесь от услуг №2 (компании, занявшей в тендере второе место). Постарайтесь договориться с №2 о возможном переходе к ним в случае, если контракт с №1 будет разорван.

Ситуация:

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

Вывод:

Страйтесь объявлять победителя по завершению согласования и подписания договора. Пункт об объявлении победителя можно прописать в правилах тендера.

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

Вывод:
Лучше не спешить с эскалацией проблемы выше. Написание требований - важная часть проекта, но она находится в начале проекта. Выберите срок, к которому проблема должна быть решена и решайте ее.Устройте встречу с обоими руководителями подразделений и попытайтесь определить, что будет лучше для компании. Вы руководитель проекта и ваша задача решать проектные проблемы. Заваливая руководство проблемами, вы рискуете не только своей репутацией, но и тем, что когда вам действительно понадобится поддержка руководства, вы ее получите не в том объеме, который ожидали.

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

Вывод:

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

Ситуация:

Вы руководитель проекта внедрения организационных изменений в компании, вызванных введением в действие нового закона. В вашей команде присутствует аналитик, слабой чертой характера которого является недостаточная концентрация на мелочах. Все же, вы поручаете ему отслеживать изменения в законе. Через три месяца оказывается, что два месяца назад были опубликованы изменения в законе. За эти два месяца, вы выполнили организационные изменения, которые были необходимы при старой редакции закона. В новой редакции, необходимость внесения выполненых вами изменений была отменена.

Вывод:

Изучайте слабые черты характера членов вашей команды. Это один из основных источников рисков. Старайтесь подстраховаться в части их слабостей. В данном случае, можно было поставить на периодический контроль работу аналитика в части мониторинга законодательства.

Ситуация:

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

Вывод:

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

Ситуация:

Вы - руководитель проекта внедрения ИТ системы. Вы договорились встретиться с руководителем проектов в другой компании, который ранее уже внедрял эту систему и работал с тем же подрядчиком, что и вы. Перед встречей вы потратили несколько часов, чтобы сформулировать вопросы ко встрече и записать их. Придя на встречу, вы узнаете, что у вас в распоряжении не более получаса, вместо запланированных полутора.

Вывод:

Вы поступили верно, заранее подготовившись ко встрече. Теперь вы сможете сосредоточиться на вопросах, которые действительно важны. И вы, скорее всего успеете их прояснить. Всегда готовьтесь ко встрече.

Ситуация:

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

Вывод:

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

Ситуация:

Вы - менеджер проекта внедрения ИТ системы. Вы наняли подрядчика и успешно спланировав проект приступили в доработкам системы. Как и в любом подобном проекте, у вас полно типичных проблем внедрения. При планировании вы сделали запас по срокам и чувствуете себя комфортно, т.к. работы на критическом пути не отстают, а низкоприоритетные работы, хотя и отстают, но не являются невыполнимыми. В один из моментов, вы замечаете угрозу срыва сроков по работам на критическом пути.

Вывод:

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

Ситуация:

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

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

Ситуация:

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

Вывод:

Перенесите данное мероприятие на окончание тендера. Лучше лишний раз избежать конфликта интересов, чем потом доказывать, что вы не оказали компании преференций в тендере.

Ситуация:

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

Вывод:

Вы поступаете верно. Не нужно стесняться спросить у других о чем-либо. Возможно, вам откажут, может быть расскажут о внедрении кратко, а возможно дадут подробный ответ на все ваши вопросы.