Как подружиться со стариком Время?
М. Якубович
журнал "О рекламе", май 2009
Провести время?! Ишь чего захотела! Время не
проведешь! Да и не любит он этого! Ты бы лучше
постаралась с ним подружиться - вот тогда бы
твое дело было... в шляпе!
(с) Льюис Кэрролл. Алиса в стране чудес
Введение
По данным проведенных в США исследований, примерно треть мировой экономики сегодня является проектно-ориентированной, предприятия ряда отраслей полностью строят свою деятельность на управлении проектами.
Все больше российских и белорусских компаний, осознают, что их деятельность так или иначе связана с динамичной средой, и обращают внимание на проектный подход к управлению. Основная проблема при управлении проектами – как повысить вероятность завершения проектов компании в срок? В статье я предлагаю некоторые методы и инструменты, внедрение которых позволит Вам подружиться со временем.
Проблемы управления сроками проектов
Как показывает мой опыт работы, большинство компаний испытывают огромные сложности с планированием сроков проектов. Особенно это касается компаний, где основная деятельность (приносящая прибыль) носит так называемый проектный характер: рекламные агенства, девелоперские и строительные компании, разработчики программного обеспечения, где одновременно идет много проектов.
В результате неправильного планирования сроков:
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 надо еще отнести и то, что координатор проектов (ресурсный менеджер, таск-менеджер, как его называют в разных компаниях) тратит очень много времени на сбор и сведение отчетности о ходе проектов в единый файл и перепланирование идущих задач – это нетривиальная задача.
Для каких компаний хватит возможностей Excel для управления проектами и задачами? Для компаний, где количество одновременно идущих проектов невелико (1-5 проектов) и сотрудники редко работают в нескольких проектах одновременно, где количество сотрудников, работающих в проектах не превышает 6-7, где в проектах связи между задачами очевидны и руководителю проекта легко удержать их в голове.
Недостаток планирования и контроля в Excel нескольких проектов на общих ресурсах полностью решает использование MS Project, особенно сетевая версия этого продукта - MS Project Server. Видимо, не зря придумали этот продукт Билл Гейтс с коллегами по Microsoft – именно Project предназначен для управления сроками проектов.
Итак, для решения проблем мультипроектного управления в MS Project:
1. Необходимо в MS Project создать сетевой график задач проекта, назначить ресурсы на выполнение задач. При назначении ресурсов уже можно увидеть в какой день возникнет перегрузка, на какой период и по какому исполнителю.
Рисунок 2
2. Устранить перегрузку в большинстве случаев можно автоматически. До этого необходимо будет решить в каком проекте использование данного ресурса приоритетнее и с учетом этого выполнить перепланирование в одном или нескольких проектах.
3. Сотрудники проекта видят свой тайм-шит (лист учета рабочего времени) и тратят 5 минут в конце рабочего дня, чтобы заполнить фактическое время по задачам и в случае необходимости оставить комментарии по каждой задаче или прикрепить файлы с результатами работы.
Рисунок 3
Ресурсный менеджер при сборе и вводе данных о ходе проекта данных тратит время только на принятие/отклонение отчетов исполнителей, что занимает несколько минут в день.
увеличить рисунок
Рисунок 4
Руководитель компании видит ход всех проектов в одном месте:
увеличить рисунок
Рисунок 5
Руководитель компании и ресурсный менеджер (таск-менеджер) могут при желании получить отчет по плановой загрузке любого сотрудника на выбранный период времени:
увеличить рисунок
Рисунок 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. Кто должен внедрять?
В проекте внедрения должен быть хотя бы один опытный внедренец, который сделал 3 и более подобных проектов и представители от компании – директор по ИТ, ресурсные (таск) менеджеры, директор по проектам (по развитию), если они есть.
4. Каковы факторы успешности проекта?
Первое – это понимание директора компании (или его представителя в проекте, выступающего в роли Заказчика) о том, какие проблемы он хочет решить, готовность сотрудничать и помогать, готовность выделить премиальный фонд участникам проекта или замотивировать их другим способом. Второе – это понимание того, что проблемы компании и особенности ее процессов знают только сотрудники компании и готовность этих сотрудников делиться знаниями. Третье – это доверие к консультанту.
