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

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

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

Но только наличие процедур не решает проблему – нужна система, о которой пойдет речь ниже.

• Давайте рассмотрим, как можно снизить вероятность возникновения проблемы выделения ресурсов или уменьшить ее влияние на проект на примере нашего кейса с реализацией проекта подготовки корпоративного праздника.
• Допустим, уже при обсуждении рамок проекта его руководитель заметил потенциальную проблему, связанную с выделением времени сотрудников на проект, и сформулировал ее в виде риска:
• В случае частичной занятости сотрудников в проекте и одновременной их занятости в регулярной деятельности приоритет, скорее всего, будет отдаваться регулярной работе, а это поставит под угрозу своевременное выделение ресурсов на задачи проекта и приведет к необходимости постоянно переносить сроки реализации проекта.
• На данном примере мы можем убедиться в том, что правильная формулировка риска иногда позволяет очень быстро найти решение для устранения причин его возникновения.
• Напомню, что формулировать риск надо в виде конструкции: «Условие возникновения риска ведет к негативному последствию».
• Обратим внимание на условие возникновения описанного риска: «В случае частичной занятости сотрудников в проекте и одновременной их занятости в регулярной деятельности…».

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

Этот вариант хорош для проектов, в которых можно составить расписание работы для отдельного сотрудника так, что на некоторый период времени у него есть задачи, требующие загрузки по 8 часов в день. Выделять сотрудников на full-time (100% загрузка на задачах проекта) есть смысл далеко не всегда, т.к.

модель проекта может быть построена так, что в какие-то периоды времени сотрудник будет простаивать или его загрузка составит менее 100%.

Давайте посмотрим, можно ли в нашем проекте по организации праздника кого-то из сотрудников выделить на 100% времени в проект. Обратимся к диаграмме Ганта и заметим, что самым явным кандидатом на 100% загрузку является руководитель проекта.

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

Поэтому уже при планировании сроков проекта он закладывал себе загрузку не более 50% от рабочего времени (т.е. 4 часа в день на проектные задачи).

У юриста всего одна задача в проекте, но и его загрузку в проекте планировали с учетом того, что ему надо будет в течение выделенной на задачу недели решать параллельно оперативные задачи, выделив только 25% времени на проектную задачу.

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

Однако кроме наличия возможности уделять проекту 100% времени для организации такого режима работы (100% загрузка без простоев) в проекте должно выполняться еще как минимум одно условие.

Сформулирую это условие в виде гипотезы: для того, чтобы какой-то ресурс был загружен на 100% в определенный период времени, план проекта должен быть выстроен под его ритм работы.

Но при этом организовать работы всех остальных ресурсов со 100% загрузкой становится очень непросто.

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

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

Давайте еще раз внимательно изучим условие возникновения риска. В формулировке риска есть еще одна часть, которую нам стоит проработать: «…приоритет, скорее всего, будет отдаваться регулярной работе».

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

Для того чтобы эта система выделения ресурсов заработала, нужно:

1. Иметь работающую систему приоритетов по проектам и регулярным задачам. Грубо говоря, каждый ресурсный руководитель должен в он-лайн режиме видеть, как меняются приоритеты по задачам его подразделения. Кроме того, он должен иметь возможность моделировать загрузку всех своих сотрудников и в случае возникновения перегрузки, предлагать варианты переноса сроков по отдельным задачам.
2. У ресурсного менеджера должна быть мотивация на выполнение наибольшего количества задач в срок – и проектных и регулярных. По сути, ему должно быть все равно – это задача из проекта или из регулярной деятельности, важно, что по ней есть приоритет, определен срок и нужно выполнить ее в плановый срок. Эффективность его работы измеряется таким показателем как «доля задач, выполненных его подразделением в плановый срок».
3. Описав требования к системе выделения ресурсов, я заметил, что описал часть требований к системе Управления портфелем проектов компании.

Итак, второй вариант решения проблемы – это выстраивание системы Управления портфелями проектов (о том, что это такое я уже писал здесь). Одна из ключевых целей этой системы – это распределение ограниченных ресурсов компании между всеми стратегическими инициативами. Для внедрения Управления портфелями проектов компании надо:

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

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

Итак, поработав с условием возникновения риска, я придумал 2 варианта снижения вероятности материализации этого условия.

Оба рассмотренных варианта показались мне слишком трудоемкими и дорогими.

Нужно еще поработать с последствием возникновения риска, которое мы сформулировали так: «а это приведет к необходимости постоянно переносить сроки реализации проекта».

Одна из стратегий работы с рисками (а именно активное принятие) предполагает закладывание резерва времени в проект на случай материализации риска.

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

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

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

Напомним, что дата проведения мероприятия установлена на 18 апреля, и расписание составлено так, что стартовать проект надо 10 февраля, и никакого резерва времени в проект добавить при текущем расписании невозможно.

Добавление резерва к этому расписанию приведет к тому, что сместится плановая дата старта проекта, а это означает, что стартовать проект надо было раньше – до 10 февраля.

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

Название задачи	Длительность	Трудо- затраты	Начало	Окончание
День рождения компании	50 дней	110 ч	Вт 10.02.15

Как управлять проектом при недостатке ресурсов

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

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

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

Но в моей профильной области (сайты и веб-проекты) эта ситуация скорее обусловлена рынком, который мучительно развивался с полного нуля в 1998, к 2007 году достиг пика развития (какой у вас бюджет на сайт? меньше 15 тысяч долларов? идите нафиг), свалился со всеми в 2008 и теперь в него открыта дорога всем, кто работает по принципу “как можно дешевле и как можно быстрее”.  В ситуациях, когда до 98% дохода отводится на зарплатный фонд – трудно ожидать эластичности штата.

Как управлять проектом при недостатке ресурсов? Есть несколько принципиальных моментов:

Наиболее глупое, что вы можете сделать, это выкинуть все методики и начать “рвать жопу”.

Я в своё время ушёл из одной такой компании – это было ещё до кризиса. Возможно, та компания таки окончательно порвала себе упомянутую “ж”, потому что сейчас вместо крупных проектов она занимается предоставлением небольших сопутствующих услуг владельцам существующих сайтов. Человек, который призывает вас спешить и суетиться – провокатор. Не поддавайтесь.

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

Например, популярный SCRUM предписывает сконцентрироваться на кратком списке актуальных дел, безжалостно выкинув в общую кучу (backlog) абсолютно все остальные задачи – и ни в коем случае не планировать и не расставлять им приоритеты раньше времени. Потому что завтра всё изменится. Это ли не отражение реальных дел в небольших IT-компаниях?

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

Самое главное зло при недостатке ресурсов – это человек, который об этом не в курсе.

Это может быть, например, ваш начальник или инвестор. И ещё полбеды, когда он знает, но не хочет признавать этот факт. Гораздо хуже ситуация – через полгода работы над проектом услышать “а что ж ты раньше не сказал, что надо в 5 раз больше людей? Где я теперь найду такие инвестиции?”..

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

Документируйте все цифры и расчёты, и регулярно отправляйте “наверх”.

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

Я регулярно провожу эксперименты: собираю несколько человек вместе, показываю им багтрекер со списком в 150-200 задач (на одного исполнителя), и предлагаю им договориться между собой о приоритетах.

Моментально несколько десятков задач улетают в конец очереди, картина проясняется, и начинается продуктивная работа.

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

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

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

Планирование проектов или этапов тоже по сути противоположное:

Планируйте не то, что хотелось бы сделать, а то, без чего нельзя обойтись.

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

Наоборот, начните со списка задач, и безжалостно выкидывайте из них все несрочные. Недостаток ресурсов всегда приводит к жертвам: либо вы пожертвуете фичами, либо багами, либо своей компанией (если попытаетесь успеть и то и другое).

Выбирайте.

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

Но попробуйте задать вопрос в лоб: какие проблемы для нас сейчас наиболее критичны? Это лучший способ посеять панику в умах. В лучшем случае вы получите список из 3-5 пунктов.

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

Что касается непосредственно самого процесса разработки, то тут, как говорилось в одном известном фильме

У вас уже не будет никакого “потом”.

Всё, что вы пишете, вы пишете на века. У вас уже не будет никакого code review и никакого рефакторинга.

Хотя возможно он и будет, но через столько лет, что вы уже давно перейдёте на другую должность или в другую компанию. Поэтому прислушайтесь к рекомендации компании Apple и делайте t-y-p-e  s-l-o-w-l-y.

Не в смысле медленно набирайте код, а в смысле – вдумчиво: то, что вы наберёте сейчас, вам уже некогда будет переписать.

Задавить в себе принцип “быстренько попробую, потом нормально перепишу” бывает крайне тяжело. Считайте, что вы никогда это не перепишете, а ваш баг будет годами болтаться в багтрекере и портить настроение следующему поколению.

Используйте таск-менеджер с очередью задач.

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

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

Только одна простая очередь, понятно и недвусмысленно говорящая ЧТО сейчас надо делать, а что – потом, достойна вашего внимания.

Единственный инструмент, где это сделано естественным образом – это Acunote: можно просто двигать задачи мышкой вверх-вниз. Популярный Mantis в этом плане безжалостен: он позволит создать хоть десять “безотлагательных” задач на одного человека, и даже не пикнет. О популярных отечественных инструментах для планирования – даже говорить не хочется.

Завтра – это вчерашнее сегодня.

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

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

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

Полезные советы при управлении ограниченными проектными ресурсами

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

Управление проектными ресурсами – важный процесс для любого предприятия, которое часто работает с ограничением ресурсов.

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

Что такое управление проектными ресурсами?

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

Приведем несколько примеров ресурсов, которыми вы уже, возможно, пользуетесь: 

• ПО для управления проектами
• Инструменты организации взаимодействия
• Офис 
• Данные и отчеты по прошлым проектам

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

Что делать, если при управлении проектами ресурсы ограничены

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

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

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

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

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

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

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

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

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

 

Полезные советы от Wrike по управлению ограниченными проектными ресурсами

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

1. Учет времени 

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

2. Включение длительности задач и трудозатрат

Указывайте, сколько времени, на ваш взгляд, должно занять выполнение каждой задачи в часах, днях или неделях. Назначайте срок сдачи с люфтом не менее 5% на всякий случай. 

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

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

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

3. Использование наглядного инструмента 

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

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

Достигайте успехов в управлении проектными ресурсами

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

Что надо знать про распределение ресурсов, чтобы не загубить даже хороший план проекта

– Давайте рассмотрим проблему выделения ресурсов на проект на примере кейса. Директору по персоналу (НR-директору) поручили подготовку и проведение корпоративного праздника, посвященного дню рождения компании.

То есть фактически его назначили руководителем этого проекта. Мероприятие назначено на 18 апреля 2015. Организационная структура компании – функциональная.

Это значит, что в приоритете у сотрудников задачи, которые стоят перед их

подразделением. Полномочия руководителя проекта очень небольшие.

Директор по персоналу уже не раз готовил такие мероприятия. Он понимает структуру работ проекта, владеет программным продуктом MS Project. Вот

предварительное расписание проекта, которое он составил:

Итак, расписание проекта есть, но пока рано говорить об адекватности сроков. Еще не произошло назначение исполнителей на задачи. Из предварительной оценки трудозатрат на проект (столбец «Трудозатраты») мы видим, что чистое время равно

• 110 человеко-часам.
• Руководитель проекта должен оценить, кто в компании наиболее компетентен для выполнения каждой из задач проекта, сформировать запрос на выделение этих людей
• на нужные дни и в нужном объеме времени.
• Допустим, он оценил, что большинство задач по подготовке может выполнить самостоятельно. Кроме того, в проекте ему нужно будет время следующих
• специалистов:
• * Юрист – на выполнение задачи «Заключение договоров с подрядчиками». * Директор компании – на выполнение задач по согласованию концепции праздника
• и его программы, утверждению бюджета мероприятия.
• По каждой задаче руководитель проекта уже имеет оценку трудоемкости и понимает, на какие дни нужно выделить людей. Он составляет лист согласования ресурсов (в этот документ можно добавить столбцы «Дата старта задачи» и «Дата
• финиша задачи»):
• Документ «Лист согласования ресурсов на проект» нужно согласовать с непосредственными руководителями сотрудников, указанных в нем. И руководитель проекта (напомним, он же HR-директор), и юрист напрямую подчиняются директору
• компании.
• Директору не надо ни с кем согласовывать загрузку этих сотрудников. Он лишь уточняет у руководителя проекта, не повлияет ли выделение 90 человеко-часов на
• текущую работу.

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

Например, HR-директор понимает, что 90 часов ему нужно выделить на проект в течение 50 рабочих дней.

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

1. 10 часов в течение рабочей недели).
2. После согласия обоих сотрудников взять на себя обязательства выделить плановое время на подготовку корпоративного праздника и получить результат в нужные сроки, директор подписывает «Лист согласования ресурсов на проект». Вот как
3. выглядит диаграмма Ганта проекта в момент утверждения расписания:
4. Для создания расписания проекта:
5. * был разработан сетевой график; * были оценены трудозатраты; * были назначены ресурсы; * сотрудники согласовали плановые трудозатраты и сроки по задачам;
6. * было утверждено выделение времени сотрудников на проект в определенные даты.
7. Первой начинается работа над задачей «Разработка и согласование концепции праздника». У нее два исполнителя – предполагается, что руководитель проекта
8. разработает концепцию, а директор ее согласует.
9. Руководитель проекта, потратив выделенные 6 часов, через 3 дня подготовил концепцию праздника, выслал ее директору по почте на ознакомление и попросил его о встрече – для проведения презентации и обсуждения возникших вопросов. Однако тот не нашел время в ближайшие 2 дня и назначил встречу на 6-ой день с
10. момента старта задачи.
11. Руководитель проекта, получив новую дату встречи, внес изменения в расписание проекта и увидел новый прогноз по срокам его реализации:
12. На диаграмме Ганта базовый план (утвержденный у заказчика) отражен отрезками серого цвета, а текущий план – красного цвета. Как видим, проект уже сдвигается
13. на один день и команда не успевает все подготовить к 18 апреля.

Руководитель проекта видит, что еще есть много возможностей «подравняться» за счет сокращения длительности других задач. Он понимает, что уменьшить их срок он может, увеличив свою нагрузку. Например, вторую задачу можно сделать за 4 дня вместо 5. Но тогда придется работать над ней по 4 часа в день (ранее

планировалась ежедневная загрузка в 3 часа, кроме одного из дней).

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

На этот раз он заранее пишет директору письмо с просьбой назначить встречу на 4-й день после старта второй задачи. Тот ее подтверждает.

Но в этот раз, при выполнении второй задачи, сам руководитель проекта не успевает – во время одного из 4-х выделенных дней у него возникает срочная задача, связанная с размещением возникшей вакансии из-за

увольнения сотрудника.

Руководитель проекта уточняет у директора, какая из задач имеет более высокий приоритет: проектная или регулярная? И получает ответ, что обе.

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

• директору сырой документ он не считает правильным и просит о переносе сроков.
• Вот что произошло с точки зрения выделения ресурсов при выполнении двух проектных задач:
• * запланированное время не было выделено в нужном объеме; * в проекте произошло 2 сбоя на первых же двух задачах.

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

недовольству его участников и падению производительности. Проект будет обречен.

Проблема с выделением запланированного времени на проект понятна.

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

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

Максим Якубович, www.probusiness.by

Планирование ресурсов проекта

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

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

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

Принято выделять две основных системы управления ресурсами:

• Планирование при ограниченном времени;
• Планирование с ограниченным спектром ресурсов.

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

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

Здесь, не смотря на неограниченное время, которое даётся по умолчанию, запас ресурсов, причём, не имеет значения каких именно ограничен.

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

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

В ходе планирования, выделяют 3 основных процесса управления ресурсами проекта. Первым пунктом является выведение потребностей в том или ином ресурсе.

То есть, чтобы реализовать какой-то проект и представить готовую продукцию к эксплуатации, необходим перечень определённых резервов. Как правило, это материальные, то есть оборудование, производственный инвентарь и т.д., и трудовые, то есть сами рабочие.

Это и инженеры-архитекторы и коммерсанты и экономисты, ведущие смету и расчёты по затратам.

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

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

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

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

Второй процесс – это распределение ресурсов и назначение ответственных за их использование.

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

Допустим, если этот проект связан с запуском новой торговой площадки, то из всех закупленных ПК, какая-то часть пойдёт на осуществления недорогого SEO продвижения сайта, а другая на тех. поддержку и т.д.

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

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

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

Может случиться так, что очередная партия с материалом пришла бракованная, или специалист, который отвечает за рекламу проекта и от и до знает, как сделать нативную рекламу, внезапно «исчез».

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

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

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

Планирование материальных ресурсов проекта – это отдельная работа в самом процессе управления ресурсами. Разберёмся, как это происходит. Для начала разрабатывается сам план материального обеспечения проекта. То есть, предприятие, запуская очередной проект, оценивает требуемое количество материалов: рабочих, инвентаря материальных и нематериальных единиц и т.д.

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

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

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

Планирование трудовых ресурсов проекта

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

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

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

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

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

Проекты, ограниченные по количеству ресурсов

• Проекты, ограниченные по количеству ресурсов
• Когда количество людей и/или оборудования не соответствует удовлетворению пика потребностей и их невозможно получить в большем количестве, руководители проектов сталкиваются с проблемой ограниченных ресурсов.
• Искусство заключается в том, что необходимо определить приоритеты и распределить ресурсы таким образом, чтобы свести к минимуму задержку проекта, не превышая при этом лимит ресурсов и не изменяя технические отношения сети.
• Проблема составления календарного графика ресурсов представляет большую комбинаторную проблему.
• Огромное количество данных, которое требуются для решения крупных проблем, сделало практически нецелесообразными чисто математические решения (например, линейное программирование).
• Альтернативным подходом к проблеме было использование эвристического (приближенного метода) для решения больших комплексных проблем.
• Эвристика не всегда дает оптимальный календарный график, но весьма подходит для составления «хороших» графиков для очень сложных сетей с разными типами ресурсов.
• Ниже приводится простой пример эвристического подхода.
• Ресурсы для выполнения операций распределены так, чтобы уменьшить риск отставания проекта от заданного срока; то есть, определен приоритет выделения ресурсов на операции, а также то, какие операции задерживаются, если количество ресурсов недостаточно.
• Были выявлены следующие эвристические критерии, которые всегда сводят к минимуму задержку самых разнообразных проектов:

Минимум резерва времени начала выполнения операции. Наименьшая продолжительность выполнения операции. Наименьший порядковый номер операции.

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

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

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

Обратимся к рис. 3.4.

Период Действие 0-1 Приемлема только операция A. Она потребует 2 ресурса. Внесите операцию A в график 1-2 Нет приемлемых операций для внесения в график 2-3

Операции В, С, D приемлемы для внесения в график. Операция С имеет наименьший резерв времени (0) — примените правило 1.

Внесите операцию С в график.

Следующей операцией является операция B с резервом 2; но для ее выполнения требуется 2 ресурса и только 1 имеется в наличии.

Отложите операцию B. Скорректируйте ES =3, резерв =1.

Следующая приемлемая операция D, для ее выполнения требуется 1 ресурс.

Внесите операцию D в график

———————————-см.рис. 3.5————————————————

3-4 Операция B приемлема, но превышает лимит 3 ресурсов общего фонда. Задержите операцию B. Скорректируйте ES = 4, резерв =0 4-5 Операция B приемлема, но превышает лимит 3 ресурсов общего фонда. Задержите операцию B.

Скорректируйте ES = 5, резерв = -1. Задержите операцию G. Скорректируйте ES = 11, резерв = -1 5-6 Операция B приемлема, но превышает лимит 3 ресурсов общего фонда. Задержите операцию B. Скорректируйте ES = 6, резерв = -2. Задержите операцию G.

Скорректируйте ES = 12, резерв = -2 6-7

1. Операции B,E,F приемлемы с резервами времени выполнения -2, 2, 0 соответственно.
2. Внесите операцию B в график (правило 1).
3. Так как операция F имеет резерв 0, она следующая приемлемая операция.
4. Внесите операцию F в график (правило 1).
5. Лимит ресурсов 3 достигнут.
6. Задержите операцию E. Скорректируйте ES = 7, резерв = 1
7. 7-8

Лимит достигнут. Ресурсов в наличии нет.

Задержите операцию E. Скорректируйте ES = 8, резерв = 0

8-9

Лимит достигнут. Ресурсов в наличии нет.

Задержите операцию E. Скорректируйте ES = 9, резерв = -1

9-10

Лимит достигнут. Ресурсов в наличии нет.

• Задержите операцию E. Скорректируйте ES = 10, резерв = -2
• 10-11
• Операция E приемлема.
• Внесите операцию E в график.
• (Заметьте, операция F не имеет простоя, так как нет ресурсов в наличии — 3 максимум)
• 11-12 Нет приемлемых операций 12-13
• Операция G приемлема.
• Внесите операцию G в график

увеличить изображение

Рис. 3.4. График ресурсов, подчиненных ограничению в периоды 2-3

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

В сети на рис. 3.5 на графике календарного планирования указана новая дата в 14 единиц времени против продолжительности в 12 единиц времени проекта, подчиненного ограничениям по времени.

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

Сравните резервы времени для каждой операции на рис. 3.4 и рис. 3.5; резервы времени значительно сократились.

увеличить изображение

Рис. 3.5. График ресурсов, подчиненных ограничению в периоды 5-6

На рис. 3.6 показана другая сеть проекта, когда используются три различных типа ресурсов (A, B и С); общий фонд каждого типа состоит из 2 ресурсов.

Рис. 3.6. Первоначальный план сети

Первоначальный критический путь показан в сети пунктирной линией.

Ниже сетевого графика приводится график потребности в ресурсах. Время («план») и ресурсы показаны внизу на графике 3.6.

Время, которое ограничивает критический путь, составляет 3, 5, 8 и 11, продолжительность проекта составляет 27 единиц времени.

Ресурсы, которые ограничивают выполнение критических операций, составляют 1, 4, 5, 7, 8 и 10 при продолжительности проекта 20 единиц времени.

Операции 3 и 11 уже не являются критическими и имеют резервы времени. Операции 4, 5, 7 и 8 уже являются не параллельными, а последовательными. Резервы времени сократились. Ресурсы A, B, и С в какой-то точке проекта являются критическими.