Добавлен: 06.07.2023
Просмотров: 36
Скачиваний: 1
Планирование ресурсов по проекту является основой определения во времени потребностей в ресурсах и определения возможности обеспечения ресурсами для заключения контрактов по закупкам ресурсов, планирования поставок ресурсов, а также основой распределения уже закупленных ресурсов по работам проекта.
Как основная составляющая управления проектами ресурсное планирование включает ряд составляющих, в том числе:
- разработку и сбалансированный анализ комплексов работ и ресурсов, направленных на достижение целей проекта;
- разработку системы распределения ресурсов и назначение ответственных исполнителей;
- контроль за ходом работ — сравнение плановых параметров работ с фактическими и выработка корректирующих воздействий.
В принципе при планировании обеспечения потребности в ресурсах по работам проекта следует учитывать одно общее правило: общий объем потребностей в каждом виде ресурса в каждый момент времени в пределах жизненного цикла проекта должен быть не меньше общего объема наличия этого ресурса на этот момент с учетом запасов.
1.4. Оценка стоимости проекта
Чтобы оценить стоимость проекта, требуется знать стоимость составляющих проект ресурсов, время выполнения работ и стоимость этих работ. Таким образом, оценка стоимости начинается с определения структуры ресурсов и работ проекта. Данные задачи решаются в рамках планирования проекта, а в модуль оценки стоимости должны поступать результаты выполнения этого процесса. Стоимость проекта определяется ресурсами, необходимыми для выполнения работ, в том числе:
- оборудование (покупка, взятие в аренду, лизинг);
- приспособления, устройства и производственные мощности;
- рабочий труд (штатные сотрудники, нанятые по контракту);
- расходные товары (канцелярские принадлежности и т. д.);
- материалы;
- обучение, семинары, конференции;
- субконтракты;
- перевозки и т. д.
Все затраты можно классифицировать как:
- прямые и накладные расходы;
- повторяющиеся и единовременные. Например, ежемесячные платежи за использование производственных мощностей — повторяющиеся затраты, закупка комплекта оборудования — единовременные затраты;
- постоянные и переменные по признаку зависимости от объема работ;
- плата за сверхурочное рабочее время.
1.5. Анализ и планирование рисков
Управление отклонениями в основном сводится к борьбе с неприятностями, которые в общем случае может включать три стадии:
- Управление рисками. Цель этой стадии – предотвратить неприятности до их возникновения или, по крайней мере, встретить их во всеоружии.
- Управление проблемами. способы преодоления. Цель этой стадии – преодолеть проблемы и обеспечить проекту возможность идти так, как запланировано.
- Управление изменениями. Цель этого этапа – то, , - это модификация ранее согласованного технического задания, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.
Причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть “известные" те, которые определены, оценены, для которых возможно планирование. Риски “неизвестные” – те, которые не идентифицированы и не могут быть спрогнозированы.
1.6. План реализации проекта
После согласования документов "Постановка Задачи" и "Экономическое обоснование",они должны быть подписаны сторонами - "Заказчиком" и "Исполнителем". На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза. Одновременно в виде пошаговых сценариев пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.
Важное замечание о юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять волевое решение на уровне топ-менеджера и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки "Постановки задачи" с учетом надбавок на риск, рекомендуется пересмотреть трудоемкость/цену проекта или прекратить его. Указанная возможность прекращения проекта должна быть предусмотрена в договоре.