[an error occurred while processing the directive]
[an error occurred while processing the directive]

1.2 Определи работу / Приемы

Работайте над Уставом проекта и Графиком одновременно

(1.2.P1)

Между определением работы (шаг 1.0) и построением графика и бюджета (шаг 2.0) последовательный порядок вовсе не подразумевается. То есть, Вам нет необходимости вначале полностью определить работу, а затем только строить график и бюджет. Вы можете заметить, что некоторые части Устава проекта, такие, как оценка трудозатрат и длительности, не могут быть выполнены без начального формирования общего плана работ. В тоже время, Вы не можете полностью завершить план работ и бюджет без согласования Устава проекта. Например, Вы не можете спланировать работы без наличия согласованных с заказчиком выходных результатов и продукции проекта. Кроме того, Устав проекта включает описание общих проектных допущений, которые важно знать перед тем, как будет составлен план работ.

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

Разбивайте большие проекты на малые части

(1.2.P2)

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

Таким образом, очень большие объемы работ слишком затрудняют и усложняют управление, чтобы оставлять их в виде единого проекта. Лучшим выходом является разделение такой работы на более управляемые части. Каждая из таких частей считается отдельным проектом со своим собственным Уставом и планом работ и имеет более высокие шансы на успех.

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

Создайте программу для координации взаимосвязанных проектов

(1.2.P3)

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

Клиент может не знать достаточно для полного определения проекта

(1.2.P4)

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

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

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

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

Организация проекта - роли и ответственности

(1.2.P5)

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

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

Один из важных аспектов определения проекта – определить его организационную структуру, роли и ответственность всех основных участников. Обычно описания типовых ролей и их обязанностей могут заранее разрабатываться для всей организации, а затем многократно использоваться от проекта к проекту как рекомендованные. Многие из общих проектных ролей описаны в 1.2.2 Определи работу / Роли и ответственности .

Утверждение проекта

(1.2.P6)

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

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

Установите тройственное ограничение

(1.2.P7)

По завершению процессов Определения и Планирования (Шаги 1 и 2) у Вас со спонсором должно сложиться соглашение относительно будущей работы, а также о стоимости и сроках, необходимых для завершения этой работы. Эти три аспекта затем формируют понятие, называющееся “тройственное ограничение”. Если один из трех аспектов изменяется, то хотя бы один другой, если не оба остальных также должны измениться. Тройственное ограничение может быть записано в нескольких аналогичных видах. Например, стоимость может рассматриваться как трудозатраты, что имеет смысл, если проект выполняется внутренними ресурсами, и в его стоимости отсутствуют иные затраты, кроме зарплаты сотрудников. Иногда в описании ограничения вместо объема фигурирует качество, которым будет обладать выходной результат, полученный за конкретную стоимость и в определенные сроки. Это более узкий вариант тройного ограничения, но общая концепция все еще остается верной.

Эту концепцию легко представить, если думать о тройственном ограничении, как о треугольнике со сторонами, показывающими стоимость, длительность и объем работы.

Если объем работы увеличивается, то стоимость и/или сроки также должны увеличиваться. В этом есть смысл. Если Вам нужно выполнить больше работы, на это уйдет больше денег (трудозатрат) и, возможно, больше времени. Аналогичным образом, если объем работы уменьшается, стоимость (трудозатраты) и/или длительность также должны уменьшиться.

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

План проекта

(1.2.P8)

План проекта – единый итоговый документ, который может создаваться для включения других документов по управлению проектом, созданных в шагах 1.0 Определи Работу и 2.0 Составь План Работ и Бюджет. Хотя документы остаются фактически самостоятельными, План Проекта можно использовать для того, чтобы сгруппировать их вместе. В План проекта обычно входят:

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

Старайтесь понять не только выраженные клиентом, но и истинные потребности

(1.2.P9)

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

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

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

[Пред. стр. - Выбор поставщика ]   [След. стр. - Назначение и цели проекта ]