Как подружиться со стариком Время?

1 vote, average: 5 out of 51 vote, average: 5 out of 51 vote, average: 5 out of 51 vote, average: 5 out of 51 vote, average: 5 out of 5 (1 votes, average: 5 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Автор статьи: Максим Якубович (замдиректора по развитию TELS, бизнес-тренер РШУ, ИБМТ при БГУ, консультант компании «REZультат» Max.yakubovich@gmail.com .Статья будет напечатана в майском номере журнала «О рекламе».

                                                                              … Провести время?! Ишь чего захотела! Время не проведешь! Да и не любит он этого! Ты бы лучше постаралась с ним подружиться –– вот тогда бы твое дело было… в шляпе!

(с) Льюис Кэрролл. Алиса в стране чудес.

Введение

По данным проведенных в США исследований примерно треть мировой экономики сегодня является проектно-ориентированной, предприятия ряда отраслей полностью строят свою деятельность на управлении проектами.

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

Проблемы управления сроками проектов

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

В результате неправильного планирования сроков:

1. Сроки проектов часто срываются, заказчики остаются недовольными и рано или поздно уходят.

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

3. Имидж компании в глазах сотрудников начинает падать –– складывается устойчивая ассоциация с компанией-эксплуататором.

Сложности планирования сроков связаны с:

1. Неточными требованиями Заказчика.

Из моего опыта: на выяснение требований Заказчика уходит примерно 50% времени от фактических сроков проекта. Первичные требования Заказчика к продуктам проекта в 100% случаев по ходу проекта меняются (это у меня так, у других статистика может быть более приглядной), а с ними меняется и объем работ (как правило, резко возрастает).

2. Уникальностью выполняемого проекта для данной компании.

Уникальность может быть как самих задач, решаемых в проекте, так и продуктов, ради которых затевается проект. Раз в составе проекта есть уникальные задачи –– сложно оценить объем работ по ним, а значит и сроки проекта.

3. Закладыванием буфера времени исполнителями.

Ход размышлений опытного сотрудника при оценке сроков выполнения задачи: «Я сделаю эту задачу за 2 часа, но так как у меня еще 2 задачи по 2-3 часа, то скажу ему «2 дня». А вдруг что-то пойдет не так!» (молодец, учел закон Мерфи: Если что-то неприятное может случиться, оно обязательно случится).

4. Действием закона Паркинсона.

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

5. Студенческим синдромом.

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

6. С тем, что раннее завершение задач не поощряется.

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

7. Мультипроектностью.

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

Итак, проблемы понятны. Что с этим делать –– разберемся в данной статье.

Способы решения проблем

1. Неточные требования Заказчика.

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

2. Уникальность выполняемого проекта для данной компании.

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

3. Буфер времени, закладываемый исполнителями.

Получайте от исполнителя оценку объема работ в человекочасах. Если у вас есть эксперт, который может дать оценку по данной задаче, сверяйте оценку исполнителя с оценкой эксперта и пытайтесь найти компромисс. Некоторые гуру проектного менеджмента, например Э.Голдратт в своем «Методе критической цепи», предлагают на 50% уменьшить оценку, данную исполнителем, однако я очень сильно сомневаюсь, что в некоторых сферах бизнеса это прокатит. Как вы понимаете, у исполнителя при таком подходе может возникнуть сильная демотивация и неверие в реализуемость задачи в нереальные сроки. Буфер стоит закладывать в график проекта, но общий для критического пути. Об этом читайте в книге Голдратта.

4. Действие закона Паркинсона.

Контролируйте ход исполнения задачи. Если она длится 2 часа, то в конце второго часа узнайте, готова ли она? Если задача оценена в 16 часов и к ней приступили, узнайте в конце первого дня (8-го часа), сколько процентов физического объема работы сделано и сколько осталось. Лучше раньше узнать об опоздании и скорректировать ход выполнения, чем узнать об этом по факту. Но выбирайте оптимальную частоту контроля под задачу и исполнителя: некоторые исполнители страшно расстраиваются, когда их слишком часто контролируют –– для них это проявление недоверия.

5. Студенческий синдром.

Позвоните в момент планового начала задачи и уточните, приступил ли исполнитель к работе. Если нет, то почему и когда приступит, если да –– то какие проблемы и сложности возникли, не изменилась ли его оценка трудозатрат после ознакомления с задачей?

6. Раннее завершение задач не поощряется.

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

7. Мультипроектность.

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

Итак, первое, что необходимо сделать –– это «наложить» план-графики идущих проектов друг на друга и проверить: нет ли перегрузок у исполнителей, работающих одновременно в нескольких проектах (перегрузка –– это когда по плану проектов исполнитель должен работать больше, чем длится его рабочий день по трудовому договору).

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

Итак, для автоматизации указанных шагов можно использовать огромное количество программных продуктов, но мы остановимся на двух наиболее распространенных в нашей стране –– MS Excel и MS Project.

Для планирования и отслеживания сроков проектов в Excel можно использовать таблицу вида:

 

Рисунок 1.

Что мы можем увидеть из такого сводного плана всех проектов компании?

1. Плановую загрузку исполнителей за период времени на всех проектах.

Делается просто: фильтром по исполнителю и суммированием его планового времени за период. Если плановая загрузка выше нормативной (например, Иванова на месяц распланирована на 250 часов, но работать столько она не может или не собирается, ибо нормальная загрузка 170-180 часов в месяц).

2. Фактические и оставшиеся трудозатраты по задачам.

Чего мы не можем видеть?

1. В случае перегрузки исполнителя по плану, в какое время случится эта перегрузка?

2. Как связаны задачи проекта между собой? Выполняются ли все они последовательно или есть параллельные задачи, за счет которых проект можно «сжать»?

3. Сколько фактически из планового объема работ по проекту уже выполнено и сколько осталось?

4. Укладываемся ли мы в плановые сроки или опаздываем? Если опаздываем, то на сколько дней пересогласовать с Заказчиком сроки окончания проекта (если это возможно).

Надо упомянуть еще одну проблему –– сложность координации связанных проектов в случае возникновения изменений. Как отследить в проекте А изменения, внесенные в задачу проекта В, если ее результат из проекта B передается в A?

К недостаткам ведения в Excel надо еще отнести и то, что координатор проектов (ресурсный менеджер, task-менеджер, как его называют в разных компаниях) тратит очень много времени на сбор и сведение отчетности о ходе проектов в единый файл и перепланирование идущих задач –– это нетривиальная задача.

Каким компаниям хватит возможностей Excel для управления проектами и задачами? Компаниям, где количество одновременно идущих проектов невелико (1-5 проектов), и сотрудники редко работают в нескольких проектах одновременно, где количество сотрудников, работающих в проектах не превышает 6-7, где в проектах связи между задачами очевидны и руководителю проекта легко удержать их в голове.

Недостаток планирования и контроля в Excel нескольких проектов на общих ресурсах полностью решает использование MS Project, особенно сетевая версия этого продукта –– MS Project Server. Видимо, не зря придумали этот продукт Билл Гейтс с коллегами по Microsoft –– именно Project предназначен для управления сроками проектов.

Итак, для решения проблем мультипроектного управления в MS Project:

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

 

Рисунок 2.

2. Устранить перегрузку в большинстве случаев можно автоматически. До этого необходимо будет решить, в каком проекте использование данного ресурса приоритетнее, и с учетом этого выполнить перепланирование в одном или нескольких проектах.

3. Сотрудники проекта видят свой тайм-шит (time-sheet, лист учета рабочего времени) и тратят 5 минут в конце рабочего дня, чтобы заполнить фактическое время по задачам и в случае необходимости оставить комментарии по каждой задаче или прикрепить файлы с результатами работы.

 

Рисунок 3.

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

 

Рисунок 4.

Руководитель компании видит ход всех проектов в одном месте:

 

Рисунок 5

Руководитель компании и ресурсный менеджер (таск-менеджер) могут при желании получить отчет по плановой загрузке любого сотрудника на выбранный период времени:

 

Кроме того, в случае интеграции MS Project Server с продуктом MS SharePoint появляется дополнительная возможность для групповой работы –– создание портала проекта, на котором размещаются новости о ходе проекта, вопросы по проекту, проводятся опросы и т.д. То есть портал выступает в роли единого места коммуникации проектной команды, доступ к которому можно получить через интернет из любой точки мира при получении прав на это.

Итак, при использовании MS Project Server ресурсный менеджер обладает в несколько раз большим объемом важной для его работы информации, чем в случае с Excel, и тратит на перепланирование задач времени в несколько раз меньше. Руководитель компании получает возможность видеть «большую картину» по всем проектам и ресурсам компании. Правда, надо заметить, что освоение навыков работы в MS Project требует большего количества времени и большей квалификации ресурсного менеджера. Но эти инвестиции времени окупаются с лихвой уже через полгода-год активного использования MS Project.

Полагаю, у вас возникли вопросы по внедрению MS Project. Предвижу часть из них и сразу отвечу.

1. Сколько стоит внедрение системы автоматизации проектной деятельности на базе MS Project Server?

Это зависит от:

1) того, какие задачи вы хотите решать с помощью системы. Если никакой доработки не требуется и используется базовый функционал, то ваши затраты будут состоять из следующих статей расходов: расходы на лицензионное ПО (можете на свой страх и риск его не приобретать), расходы на установку и отладку ПО, расходы на обучение персонала работе с ПО. Порядок расходов –– 2500-4000 долларов (без лицензионного ПО).

2) того, что вы понимаете под внедрением. Если только обучение пользователей работе, то тогда ограничитесь расходами пункта 1), но если хотите сопровождение в течение 2-3 месяцев (при таком подходе вероятность положительного результата будет 80-90 %) с ответами на вопросы, с помощью в планировании, то закладывайте еще 1000 долларов.

Итак, в большинстве случаев компания сможет внедрить систему автоматизации проектной деятельности за 3500-5000 долларов.

2. Как быстро можно внедрить систему автоматизации?

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

3. Кто должен внедрять?

В проекте внедрения должен быть хотя бы один опытный внедренец, который сделал три и более подобных проектов и представители от компании –– директор по ИТ, ресурсные (таск) менеджеры, директор по проектам (по развитию), если они есть.

4. Каковы факторы успешности проекта?

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

На форуме вы можете обсудить данную статью.

Об авторе

Автором Zubry.ru размещено записей на сайте - 454.

Похожие публикации

Комментариев - 7 к записи “Как подружиться со стариком Время?”

  • Кузин Дмитрий Владимирович написал 15 Май, 2009, 17:38

    Цитата: «Некоторые гуру проектного менеджмента, например Э.Голдратт в своем «Методе критической цепи», предлагают на 50% уменьшить оценку, данную исполнителем, однако я очень сильно сомневаюсь, что в некоторых сферах бизнеса это прокатит. Как вы понимаете, у исполнителя при таком подходе может возникнуть сильная демотивация и неверие в реализуемость задачи в нереальные сроки.»

    Возражения:
    1. Демотивация возникает только в случае, если за нарушение оценочного срока исполнитель понёс наказание. При внедрении этого аспекта управления временем проекта наказаний за просрочку исполнения быть не должно.
    2. Объяснение исполнителю того факта, что 50% не забирается из проекта, а переносится в буфер проекта, тем самым защищая весь проект, а не отдельную работу, также служит дополнительным мотивирующим фактором.

    ИМХО: 50% можно «забрать» всегда. С большой долей вероятности можно утверждать, что забрать можно и 70%.

  • Шестопалов Олег Вадимович написал 15 Май, 2009, 18:11

    Статья основана на ошибочном отождествлении проектное управления с управлением проектами, каковое далее ошибочно отождествляется с использованием соотвествующего софта. Отсюда и фантастический вывод о сроках и стоимости обучения всей этой кухне, и все остальные нелепости.
    Я уж не говорю о том, что айтишнику, специализирующемуся на управлении проектами, следовало бы знать, что ни Билл Гейтс, ни его коллеги по Microsoft MS Project не резрабатывали: эта программа сначала продавалась по соглашению, а потом была куплена у фирмы разработчика (как и почти все остальные прикладные продукты Microsoft).

  • Якубович Максим Геннадьевич написал 19 Май, 2009, 15:19

    To: Шестопалов Олег Вадимович

    Статья основана на ошибочном отождествлении проектное управления с управлением проектами, каковое далее ошибочно отождествляется с использованием соотвествующего софта. «Мне кажется Вы придумали два термина, отличия которых понятны только Вам «проектное управление» и «управление проектами» – объясните. буду дискутировать, нет – не о чем говорить».

    Отсюда и фантастический вывод о сроках и стоимости обучения всей этой кухне, и все остальные нелепости.
    «Хе-хе-хе….слишком обобщенно. В чем нелепости, товарисч критик?». Я уж не говорю о том, что айтишнику, специализирующемуся на управлении проектами, следовало бы знать, что ни Билл Гейтс, ни его коллеги по Microsoft MS Project не резрабатывали: эта программа сначала продавалась по соглашению, а потом была куплена у фирмы разработчика (как и почти все остальные прикладные продукты Microsoft). «Знаю об этом, но продукт уже много раз дорабатывался Майкрософт. И как это относится к теме»?
    Олег, критика ни о чем! )))

  • Якубович Максим Геннадьевич написал 19 Май, 2009, 15:24

    To: Кузин Дмитрий Владимирович
    Возражения:
    1. Демотивация возникает только в случае, если за нарушение оценочного срока исполнитель понёс наказание. При внедрении этого аспекта управления временем проекта наказаний за просрочку исполнения быть не должно. «Сложно реализовать. У исполнителя Возникает ощущение безнаказанности.»
    2. Объяснение исполнителю того факта, что 50% не забирается из проекта, а переносится в буфер проекта, тем самым защищая весь проект, а не отдельную работу, также служит дополнительным мотивирующим фактором.

    ИМХО: 50% можно “забрать” всегда. С большой долей вероятности можно утверждать, что забрать можно и 70%. «Нужен опыт и статистика проектов, где использовался метод крит. цепочки, чтобы утверждать что нормально, а что нет и понимат ьпричины.»

  • Шестопалов Олег Вадимович написал 19 Май, 2009, 17:44

    2 Якубович Максим Геннадьевич
    Согласен: критика ни о чем. То есть, о вашей статье.

  • Якубович Максим Геннадьевич написал 19 Май, 2009, 17:47

    To Шестопалов Олег Вадимович: Кроме улыбки и пожелания удачи нечего сказать. до свидания!

  • Шестопалов Олег Вадимович написал 19 Май, 2009, 20:40

    2 Якубович Максим Геннадьевич
    И вам всяческих благ, ничего ж личного :)

Вы можете подписаться на комментарии к этому материалу, оставив свой адрес электронной почты:

E-Mail:

Ваш комментарий

Вы должны войти, чтобы оставлять комментарии.

Copyright © 2010 Зубры бизнеса. All rights reserved.
Powered by WordPress.org.