- •1. Планирование ресурсов проекта.
- •4. Календарное планирование в управлении проектом.
- •4. Метод сетевого планирования производства
- •7. Взаимосвязь программы и проекта: разновидности и особенности
- •9. Система показателей и оценка экономической эффективности выполненных проектов.
- •10. Развитие проектного управления в России сегодня.
- •11. Методы и направления проектного анализа.
- •12. Матричные методы выбора стратегии.
- •14. Подготовка и принятие управленческих решений.
- •13. Формирование и развитие команды управление проектом.
- •15. Программное обеспечение разработки проекта. Описание прикладных программ.
- •16. Модели жцп, их особенности.
- •Моделирование жцп по принципу «водопада»
- •Моделирование жцп по итеративной модели
- •Моделирование жцп по спиральной модели т.Н. Модель Боэма (Барри Боэм).
- •Моделирование жизненного цикла проекта инкрементным методом (какая-то хрень для проектов в области it)
- •17. Планирование материально-технических потребностей уп.
- •18. Календарное и ресурсное планирование в программе Спайдер Прожект.
- •19. Система участников проекта: состав, функции и их взаимодействие.
- •20. Управление рисками на стадии разработки проектами.
- •21. Метод дисконтирования в процессе обоснования управленческих решений (особенности, возможности использования).
- •Управление качеством на стадии разработки проекта.
- •Алгоритм процесса подготовки, принятия и реализации управленческих решений в проекте.
- •24.Этап концептуализации проекта: содержание и задачи.
- •25.Внешняя и внутренняя среда проекта, прямые и косвенные факторы, влияющие на управление проектом.
- •26.Определение надежности и организованности в управлении проектом.
- •27.Основные подсистемы управления проектом, их цели и задачи на стадии его реализации.
- •28.Организационная структура управления проектом.
- •29.Управление коммуникациями на стадии разработки проекта.
- •30.Резюме проекта: назначение и содержание.
- •31. Маркетинг проекта, сущность и содержание маркетинговой деятельности в проекте
- •32. Бизнес-план как результат предпроектных исследований
- •33. Понятие и выбор базовой конкурентной стратегии в уп
- •34.Методы построения структур. Декомпозиции проекта, ее значение и прим-е в уп.
- •35. Предпроектные исследования: направления и этапы
- •36. Разработка сетевых матриц уп, опред-е осн. Ее параметров
- •37. Документы финансового анализа в проекте
- •38. Метод освоенного объема (моо) и его значение на этапе реализации проекта
- •39. Управление командой проекта на различ. Стадия жизненного цикла
- •40.Возможности применения методов сетевого и календарного планирования при уп.
- •42. Сопровождение реализации проекта в программе Spider Project
- •Оценка исполнения проекта.
- •43. Планирование закупок и поставок при управлении разработкой проекта.
- •44. Маркетинг проекта и продукции проекта.
- •45. Информационно-технологическая модель управления проектом.
- •46. Разработка обоснований ценности проекта и оценка его финансовой реализуемости (на этапе концептуализации).
- •47. Организационный раздел бизнес-плана: содержание и состав
- •51. Маркетинговые исследования на этапе концептуализации п.
- •52. Окружающая среда п, факторы, влияющие на упр-ие выполнением п.
- •53. Особенности использования информационных технологий в уп.
- •54. Программа Спайдер Проджект; тип операций «длительность» и «производительность», их влияние на расчет расписания Па.
- •55. Основные показатели контроля сроков на стадии реализации п.
- •57. Использование маркетинговых инструментов в управлении проектом.
- •58. Определение целесообразности выполнения Па и разработка концепции уп.
- •1. Формирование инвест. Замысла (идеи) Па
- •2. Предварительная проработка целей и задач Па
- •3. Предварительный анализ осуществимости Па
- •3.4. Ходатайство (Декларация) о намерениях
- •59. Проблемы контроля продолжительности п методом освоенного объема и их решение.
- •60. Экологический, технический и организационный анализ на этапе концептуализации Па.
- •61.Применение стандартизации и сертификации качества в проекте.
- •62. Основные показатели контроля стоимости проекта на стадии реализации управления проектом.
- •63. Роль программного обеспечения в современном бизнесе при разработке проекта.
- •4. Все большее внимание пользователей привлекают программные средства, позволяющие организовать повседневную деятельность (Organizer фирмы Lotus)
- •64. Итм и матрица разу как инструменты проектного управления.
- •65. Правовое и материально-техническое обеспечение проекта.
- •Применение правовых процедур на разных фазах проекта
- •66. Использование информационных технологий в организации управления проектом
- •67. Планирование коммуникаций при рекламном и pr- сопровождении проекта.
- •68. Программное обеспечение и сопровождение при выполнении проекта.
- •Оценка исполнения проекта.
- •69. Состав элементов системы проектного управления.
- •70. Разработка концепции и технического задания для выполнения проекта.
- •Основные показатели контроля управления продолжительностью проекта.
- •Анализ современных программных средств по управлению проектами.
- •Использование видов организационного инструментария пои анализе и проектировании систем управления проектом
- •Управление стоимостью проекта на стадии его реализации: основные и дополнительные показатели метода освоенного объёма.
- •Взаимосвязь бизнес-плана и тэо.
- •Основные подсистемы проектного управления и их краткая характеристика
- •Маркетинговый анализ проекта, его цели и задачи.
- •Сравнительная характеристика программного обеспечения проекта.
- •Основные направления проектного анализа, их содержание
- •80. Организационный инструментарий проектного управления, краткая характеристика и возможности использования. См вопрос 73
- •81. Факторы, влияющие на увеличение продолжительности проекта
- •5. Прекращение проекта
- •82. Управление контрактами на стадии реализации проекта. Закрытие контрактов.
- •83. Методы распределения административных задач управления в проекте.
- •84.Мониторинг временных показателей реализации проекта.
- •85. Разработка матрицы разделения административных задач управления проектом. (разу)
- •87. Система календарных и сетевых планов. Использование на стадии реализации проекта.
- •88. Основные требования, предъявляемые к организационным структурам управления проектом.
- •89. Исследование основных характеристик рынка: сегментация, конъюнктура рынка, емкость рынка, доля рынка.
- •90. Этапы разработки бизнес-плана проекта.
85. Разработка матрицы разделения административных задач управления проектом. (разу)
Матрица ответственности представляет собой графо-аналитический инструмент, с помощью которого устанавливается ответственность исполнителей за совокупность работ по проекту. Первые упоминания об этом инструменте встречаются уже в 60-х гг. XX века. Матрица ответственности используется не только в проектном, но и в функциональном и процессном управлении. Однако в управлении проектом матрица ответственности является обязательным инструментом и четко согласована с другими инструментами.
Матрица ответственности обычно имеет вид таблицы, в которой по горизонтальным строкам изображают отдельные работы, функции и процессы, а по вертикальным столбцам — структурные единицы, такие как подразделения, должности или иные организационные образования (комитеты, советы и пр.). На пересечении столбцов и строк ставят условный знак, обозначающий степень ответственности структурной единицы за выполнение указанной работы (функции или процесса) или какой-либо ее части. Наиболее простым вариантом матрицы ответственности является таблица, в которой используется только один условный знак, с помощью которого обозначают ответственность сотрудника или подразделения за выполнение указанной работы в целом, без выделения какой-либо части этой работы (функции, процесса)
В проектном управлении матрица ответственности согласовывает структуру разбиения работ по проекту с организационной структурой управления проектом. С помощью матрицы ответственности на все работы назначается свой ответственный исполнитель, и при этом каждый исполнитель имеет объем ответственности, соответствующий его должностным обязанностям, правам, полномочиям и материальному вознаграждению.
Наиболее проработанной разновидностью матрицы ответственности является матрица разделения административных задач управления — матрица РАЗУ. В этой матрице используются символы, отражающие три принципиальных аспекта выполнения каждой работы.
1. Принятие решения по работе:
Я — единоличное принятие решения;
! — участие в коллективном принятии решения с правом решающей подписи;
Р — участие в коллективном принятии решения без права решающей подписи.
2. Управление работой:
1 П — планирование;
О — организация;
К — контроль;
X — координация;
А — активизация.
3. Выполнение работы и ее техническое и информационное обслуживание:
С — согласование и консультирование;
Т — выполнение рабочих операций;
М — подготовка предложений;
И — получение информации;
± — выполнение расчетных операций;
прочерк ■— неучастие в выполнении работы.
При заполнении символами матрицы РАЗУ необходимо придерживаться нескольких логических правил. В каждой строке:
• символы «!» и «Р» всегда должны соприсутствовать в строке. При этом символ «!» может присутствовать только один раз, символ «Р» — более одного раза. Если в строке присутствует символ «!» без символов «Р» или символы «Р» без символа «!», то это является ошибкой;
• символ «Я» должен присутствовать в строке только один раз;
• символ «Я» и группа символов по коллегиальному решению «!» и «Р» являются взаимоисключающими. По работе может приниматься решение либо коллегиально, либо единолично, но никак ни коллегиально и единолично одновременно;
• символы принятия решения должны присутствовать в строке обязательно;
• символы управления работой — «П», «О», «К», «А» обязательно должны присутствовать в каждой строке один или несколько раз, символ «X», т.е. символ координации, можно опускать в случае, если работа предполагает участие не более трех структурных единиц;
• символ «Т», изображающий выполнение рабочих операций, обязательно должен присутствовать в каждой строке. Таких символов может быть более одного. При этом ответственного исполнителя выделяют специальным образом, например, подчеркивани-м, кружком, жирным шрифтом или курсивом.
Приведенные правила должны выполняться в любом случае. Все остальные комбинации символов разрешены.
Помимо развитого аппарата изображения различных видов участия в выполнении работ матрица РАЗУ имеет еще достоинство: возможность перехода от символьного обозначения ответственности к численному и использования полученных относительных числовых показателей при анализе и проектировании организационных решений по проекту. Такой переход осуществляется через таблицу парного сравнения (матрицу предпочтений) видов ответственности, обозначаемых символами (табл. 9.6). В эту таблицу вносятся экспертные оценки — сравнительной значимости или трудоемкости операций, стоящих за каждым из символов.
Техника заполнения таблицы парного сравнения следующая. Прежде всего заполняются ячейки, в которых символы сравниваются сами с собой: в них ставится 1. Эти ячейки образуют диагональ. Затем заполнение таблицы осуществляется построчно для каждого символа, одновременно заполняется соответствующая графа.
Если в строке рассматриваемого символа ставится 2, одновременно в графе сравниваемого символа ставится 0. Если в строке ставится 0, в графе — 2 и т.д. Таким образом, заполняется первая строка и первая графа, затем вторая строка и вторая графа и т.д. Пример заполнения таблицы парного сравнения приведен в табл. 9.7.
Значимость каждого символа определяется как сумма значений по строке.
Правильно заполненная матрица удовлетворяет следующим условиям:
• сумма оценок символов должна равняться квадрату количества символов;
• сумма оценок любого символа по горизонтали и вертикали должна равняться удвоенному количеству символов.
Для определения относительной значимости каждого символа сумму по строке делят на общую сумму всех значений всех символов
Затем осуществляется обработка экспертных оценок. Для этого записываются индивидуальные оценки (оценки символов каждым экспертом). Наиболее приемлемым методом получения коллективных оценок является нахождение либо средней арифметической, либо статистической моды.
Подобным образом можно оценить трудоемкость или важность работ (задач, функций, процессов), представленных в первом столбце матрицы ответственности.
Имея количественные оценки трудоемкости работ и операций, отображаемых символами матрицы ответственности, можно дать общую оценку трудоемкости выполнения работ:
С,- = W,. -
где С; — расчетная оценка трудоемкости выполнения работы /;
W, — оценка сравнительной трудоемкости работы i (из матрицы парного
сравнения трудоемкости работ);
VT — оценка трудоемкости вида деятельности, обозначаемой символом;
£,Vy — сумма всех оценок символов, приходящихся на данную работу.
Также можно рассчитать оценку трудоемкости всех операций, выполняемых конкретной структурной единицей:
Оценка трудоемкости операций, выполняемых конкретной структурной единицей, особенно важна, так как позволяет в относительных величинах оценить сравнительную трудоемкость деятельности различных структурных подразделений. Такая оценка весьма полезна при проектировании или оптимизации организационных структур управления, так как дает количественные оценки себестоимости тех или иных структурных единиц. Оценка трудоемкости может быть выражена и в денежных показателях путем пересчета через общий фонд заработной платы, который равен общему количеству оценок структурных подразделений:
F. = S. • (ФОТ : Z.Sy),
где Fj — денежная оценка деятельности структурной единицы;
S} — оценка трудовой загрузки структурной единицы подразделений или
должности;
ФОТ — общий фонд оплаты труда всех структурных единиц.
Сравнивая существующий фонд оплаты труда структурной единицы с полученной денежной оценкой деятельности, можно выявить подразделения и должности, перегруженные или недогруженные работой. Для нормализации деятельности надо либо изменить содержание выполняемых работ и операций, либо изменить фонды оплаты труда структурных единиц.
Заработные платы сотрудников формируются не только на основе внутренних оценок трудоемкости, но и на основе состояния рынка труда. Поэтому часто возникают ситуации, при которых внутренняя стоимость сотрудника значительно ниже его рыночной стоимости.
Помимо внутренней трудоемкости и стоимости подразделений можно сходным образом оценить их важность с точки зрения вклада в достижение целей проекта и получить не только затратную, но и доходную оценку. Алгоритм расчетов тот же. Только при оценке значимости символов и работ необходимо их сравнивать не по трудоемкости, а по важности каждого символа и работы для достижения результата. При необходимости можно оценить в денежных показателях полезность деятельности каждой структурной единицы, осуществив пересчет не через фонд заработной платы, а через совокупный доход, создаваемый всеми структурными единицами, и получить оценку полезности структурных подразделений и должностей.
Сравнивая оценки внутренней себестоимости и полезности структурных единиц, можно провести функционально-стоимостной анализ организационной структуры управления.
Таким образом, матрица разделения административных задач управления представляет собой не только матрицу ответственности, позволяющую наглядно изобразить систему ответственности структурных подразделений и исполнителей за выполнение работ по проекту, но и является полноценным инструментом организационного анализа и проектирования.
86. Внедрение информационных систем управления проектом.
Освоение систем управления проектами может быть связано с необходимостью внедрения и использования новых управленческих технологий. Таким образом, разработка и настройка программного обеспечения еще не дает гарантии, что оно будет эффективно применено. Процедура внедрения системы призвана помочь в преодолении данной проблемы.
Любая информационная система предполагает автоматизацию тех или иных функций. В случае системы управления проектами в качестве объекта автоматизации могут выступать функции разработки календарно-сетевого графика работ, отслеживания фактического выполнения работ и т. д.
Внедрение информационной системы управления проектами включает:
» подготовку функций управления проектами к вводу информационной системы в действие. Проводятся работы по организационной подготовке подразделений, участвующих в выполнении функций;
» подготовку персонала. Проводится обучение персонала и проверка его способности обеспечить функционирование информационной системы управления проектами;
» комплектацию информационной системы программным обеспечением и техническими средствами;
» проведение опытной эксплуатации информационной системы и ее доработку;
» проведение приемочных испытаний.
Масштабы использования систем управления проектами в различных организациях могут существенно варьироваться. Сложность задач по внедрению зависит от масштабов организации, имеющейся структуры управления и степени автоматизации, масштабов и типа реализуемых проектов, степени вовлеченности в управление проектами внешних организаций. Однако, даже в относительно простых ситуациях, план внедрения системы может сыграть решающую роль для ее ввода в реальную эксплуатацию. Еще на стадии проектирования важно вовлечь потенциальных пользователей в процесс разработки, сформировать их требования к информационной системе управления проектами.
В общем случае, внедрить информационную систему, использующую «большие» и сложные программные средства оказывается гораздо труднее, чем использующую небольшие программные пакеты. Это связано и с высокой стоимостью такого решения, и с определенными организационными трудностями, и со сложностью настройки конкретного рабочего места и т. п.
Наиболее типичные проблемы при внедрении информационных систем управления проектами состоят в том, что:
» верхний уровень управления не «хочет» видеть реальную картину проекта. Из информации о ходе выполнения проекта может следовать, что необходимо большее количество времени и ресурсов для выполнения работ, чем первоначально планировалось. С другой стороны, эта же информация требуется проект-менеджеру для соблюдения жестких ресурсных ограничений;
» верхний уровень управления может и не использовать программное обеспечение для планирования, бюджетирования и принятия решений. Персонал верхнего уровня управления в большей степени использует традиционные методы, или отказывается воспринимать реальное положение вещей. В результате разрабатываемые ими планы оказываются необоснованными и далекими от реальности;
» проект-менеджеры могут и не использовать ежедневно программное обеспечение для своих проектов. Они часто полагаются на другие методы и инструменты планирования из опыта предыдущих проектов;
» верхний уровень управления может несерьезно воспринимать потребность в обучении. Проведение треннинговых курсов являются одним из обязательных условий успешного внедрения, несмотря на то, что для каждого проекта требуется отдельный поход;
» использование распределенного программного обеспечения требует четко налаженной системы внутренних коммуникаций. Ответственные за распределение и использование ресурсов должны постоянно обмениваться информацией друг с другом;
» «большие» программные продукты не всегда обеспечивают быструю обработку информации. Как правило, это является результатом не полного понимания того, как использовать возможности новой системы;
» организация может не иметь внутрифирменных стандартов в части управления проектами. Это может выражаться в плохо разработанной структуре разбиения работ, невозможности описать фазы жизненного цикла, нечетком понимании зависимостей между работами и т. п.;
» внедрение может «выставить на показ» отсутствие навыков планирования и организации у управляющих среднего звена. Их страх перед информационной системой может стать одним из основных препятствий при ее внедрении;
» область деятельности и организационная структура могут не подходить для внедрения системы управления проектами. Процессы управления проектами, и в частности процесс распределения ресурсов, могут иметь место в матричной структуре. Если организация консервативна в использовании традиционных структур управления, то вероятность успешного внедрения информационной системы достаточно невелика;
» внедрение сложных информационных систем управления проектами требует большого количество ресурсов (персонал, оборудование и т. д.).;
» необходимо знать место информационной системы в организации. Должна ли она использоваться на всех уровнях управления? Должна ли она использоваться только для высокоприоритетных проектов?
» информационная система может рассматриваться как замена живому и неформальному общению, передаче навыков и опыта внутри персонала. Она не должна ставить взамен этому жесткие каналы коммуникаций;
» внедрение информационной системы имеет меньше шансов на успех, если в организации нет понимания основных принципов управления проектами, либо у руководства отсутствует желание их изучать.
Можно сформулировать несколько наиболее часто встречающихся ошибок планирования внедрения систем для управления проектами, которые являются причинами неудач освоения подобных систем:
» цели проекта разработки и внедрения информационной системы, внешние условия и ограничения не определены заранее или определены не в полном объеме;
» планирование ввода в эксплуатацию всех функций системы управления проектами одновременно. Внедрение системы для управления проектами в полном объеме может предусматривать использование целого ряда новых технологий (например, установку глобальной информационной сети, установку серверов баз данных). Реализация различных функций может влиять на работу разных подразделений и специалистов (например, разные отделы должны быть вовлечены в поддержку информационных потоков при реализации временного, ресурсного и стоимостного видов планирования работ). Все это может привести к значительному усложнению проекта и делает проблематичным стабилизацию работы системы в целом;
» планирование перевода сразу всей организации на использование системы для управления проектами. Это подобно попытке связать сразу всех сотрудников крупной организации в локальную вычислительную сеть, вместо того, чтобы осуществлять подключение пользователей последовательно, отдел за отделом.
