Элементы управления проектами

⇐ ПредыдущаяСтр 8 из 18Следующая ⇒

Проект — это комплекс взаимосвязанных мероприятий, которые имеют уникальный результат и ограничены временными рамками и ресурсами.

Операционная деятельность, однако, не подпадает под данное определение. Но тонкость в том, что даже операционную деятельность (например, квартальный план работ производственного цеха серийной продукции) можно рассматривать в Microsoft Project как проект. Эта деятельность ограничена временем и ресурсами. Результат уникален по временной характеристике его достижения. Польза от рассмотрения операционной деятельности в виде проекта есть. Используя данный подход можно внедрить средства проектного планирования и добиться большей управляемости квартальных работ.

Стандартный ход проекта

Стандартный подход к проектному управлению состоит из следующих этапов:

1 Постановка задачи (фиксация цели проекта).

2 Планирование (выработка плана и бюджета).

3 Контроль и анализ исполнения, коррекция планов.

4 Закрытие проекта по формальной процедуре и анализ статистики.

Схема стандартного хода проекта показана на рисунке 1.17

Рисунок 1.17

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

Техника планирования

Этап планирования является одним из самых важных. На этом этапе определяются задачи, бюджет и сроки проекта. Довольно часто планирование понимают только как составление графика работ, упуская из вида управление ресурсами, составление бюджета и т. д.

Полноценная техника планирования включает в себя следующие этапы:

1 Определение цели проекта и ее описание. Довольно часто проекты начинаются без четкой цели.

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

3 Для технологических стадий необходимо определить список задач, указать их последовательность и прогнозируемую длительность (зависит от назначенных ресурсов).

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

5 График работ в таких системах, как MS Project, получается автоматически, если определены задачи и ресурсы.

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

7 Письменное задание, бюджет и график работ образуют формальный документ " План проекта". Довольно часто перед началом проекта некоторые из указанных документов отсутствуют, последствия этого мы рассмотрим ниже.

Основные задачи планирования схематически показаны на рисунке 1.18.

Рисунок 1.18

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

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

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

Типовые методы планирования. Бюджет и материальные ресурсы

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

Постановка задачи

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

Документ «Постановка задачи» («Техническое задание») должен отвечать на следующие вопросы:

1 В какие сроки должна быть достигнута цель?

2 Какие условия достижения цели есть в наличии (бюджет, ресурсы, технология)?

3 Каким способом измерить достижение цели?

4 Как распределены обязанности в проекте (кто за что отвечает)?

5 Согласен ли инвестор (заказчик) с определением цели и условиями ее достижения?

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

Список этапов

Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи, изложенную в техническом задании. Менеджер запускает Microsoft Project и приступает к планированию. Окно программы с перечислением этапов проекта представлено на рисунке 1.19. Этапы просто переписаны из технического задания.

Рисунок 1.19

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

Список и длительность задач

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

При постановке задачи необходимо иметь шаблоны проектов (project patterns). Такие типовые фрагменты (подпроекты) должны представлять собой корпоративный стандарт выполнения стандартных этапов. Тестирование вряд ли сильно отличается для разных задач и менеджеру не нужно каждый раз изобретать новые шаблоны.

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

Проанализировав задание, менеджер составил свое представление об их трудоемкости и ввел информацию о длительности работы, представленную на рисунке 1.20.

Рисунок 1.20

В MS Project появилась возможность указывать, что некоторые сроки являются ожидаемыми, а не точными. Рядом с такими сроками выставляется знак вопроса.

Последовательность задач

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

Рисунок 1.21

Советы и комментарии:

1 Точный срок следует указывать только для задачи " Начало проекта", все остальные сроки должны быть относительными. Таким образом, вы всегда можете легко перенести окончание проекта на другую дату, все сроки будут пересчитаны автоматически. Начало проекта в MS Project нужно отмечать в его свойствах или milestone.

2 Все технологические этапы следует завершать контрольными точками. Дело в том, что по технологии некий законченный результат может быть получен только в определенное время, и именно в данный момент следует провести контрольный осмотр проекта. Жестко и по дням контролировать исполнение отдельных задач часто не имеет смысла, так как исполнителям обычно приходится исполнять задачи не в том порядке, как указано в плане. Но отчетность по дням нужна в виде отчетов о затратах рабочего времени, о чем речь пойдет далее. Конкретный характер отчетности по дням определяется спецификой проекта.

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

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

Ресурсы

После определения состава задач и их сроков менеджер назначает ресурсы для каждой задачи. Пример распределения кадровых ресурсов приведен на рисунке 1.22.

Рисунок 1.22

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

Расценки на ресурсы

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

Рисунок 1.23. Лист ресурсов

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

2 В MS Project возможно использование материальных ресурсов. MS Project может запоминать инвентарные номера, что очень удобно для учета. Повременную амортизацию ОС можно учитывать через параметр Std. Rate (" затраты по времени использования" ). Списание на манер МБП можно учитывать через параметр Cost/Use (" единовременные затраты на использование" ). В нашем примере для проекта требуется закупка сервера, по применяемой нами учетной политике затраты на сервер целиком списываются в проект.

3 Наличие перегрузки (overtime) — это, скорее всего, ошибка планирования, связанная с тем, что вы поставили одному исполнителю две задачи одновременно.

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

Кроме людских ресурсов могут быть и другие компоненты затрат. MS Project умеет учитывать и материальные ресурсы. Кроме того, существуют так называемые общефирменные расходы (ОФР). Однако их большинство софтверных компаний включает в стоимость человеко-часа специалиста, т.е. стоимость месяца Петрова это не его ЗП в $500, а еще $1000 общефирменных расходов отнесенных на него. В вопросе ОФР менеджеру следует обратиться к финансовому директору компании, если его беспокоит прибыльность проектов, то он вычислит норму ОФР на каждого сотрудника. В MS Project надо ее только ввести и автоматически получатся полные затраты. Если нужны более сложные механизмы разноски затрат интегрированные проектной системой, стоит поискать проектную систему более высокого уровня.

Поясним некоторые тонкости ценообразования на контрактные работы. Сначала вы договариваетесь на стоимость человеко-месяца и заносите ее в MS Project как Standart Cost Rate. Затем вы торгуетесь с исполнителем только о сроке, цена получается автоматически. После этого срок фиксируется в Base Line и превышение сроков по вине исполнителя не оплачивается (если вы не оговорили иное). Альтернативным вариантом является каждый раз согласование и цены и сроков, при этом цена записывается в Fixed Cost. В данном варианте стоимость человеко-месяца будет плавать, что усложнит планирование расходов, но возможно полезно в случаях, когда работы по своему характеру (стоимости за час) сильно отличаются.

Поясним значение округлений. При вычислении стоимости часа и дня из стоимости месяца, день в 8 раз точнее часа по количеству действительных знаков после запятой. Приведем пример. Стоимость человеко-месяца $1500, значит стоимость дня с точностью до 2-х знаков $68.18 (погрешность $0, 04 за месяц), а для часа - $8.52 (погрешность $0.48 за месяц). Видно, что если начислять стоимость как $1500 за месяц, погрешности не будет совсем, но многие менеджеры для небольших работ в несколько дней находят это неудобным, т.к. на глаз не сверить дневную ставку с Cost-задачей.

План с бюджетом

После назначения расценок на ресурсы менеджер автоматически получил план с бюджетом.

Из этого документа видны следующие основные параметры проекта:

- длительность;

- трудоемкость;

- себестоимость;

- сроки;

- исполнители и ответственные лица.

Данные по трудоемкости (Work) и себестоимости можно использовать для ценообразования проекта. В нашем случае можно умножить трудоемкость на выходную цену человеко-месяца и получить внешнюю цену проекта.

Чем трудоемкость в этом примере отличается от длительности? MS Project понимает это так. Если упрощенно, то Work = Duration*N, где Work — трудоемкость, Duration — длительность, N — количество занятых ресурсов в задаче.

Отслеживание проекта. Управление рисками. Модификация плана по ходу проекта

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

Риски и косвенные работы

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

Рисунок 1.24

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

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

- планируйте обучение и качество. Это предотвращает типичные технологические риски;

- исследуйте риски и планируйте действия по их предупреждению. Об этом мы расскажем далее.

Управление рисками по PMI

Рассмотрим кратко основы теории управления рисками (рисунок 1.25).

Рисунок 1.25

По теории нужно выполнять следующие действия:

1 Определение рисков. Необходимо провести анализ проекта с целью идентификации причин рисков.

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

3 Исполнение плана с отслеживанием рисков. Необходимо планирование антирисковых мероприятий и поиск новых рисков.

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

⇐ Предыдущая 3 4 5 6 789 10 11 12 Следующая ⇒