Управление персоналом

Содержание

 

Введение…………………………………………………………………………3 стр.

1. СОДЕРЖАНИЕ УПРАВЛЕНИЯ ПРОЕКТАМИ……………….............4 стр.

1.1. Понятие «проект»………………………………………………………. ..4 стр.

1.2. Структуризация  проекта…………………………………………….......6 стр.

2. ЖИЗНЕННЫЙ  ЦИКЛ ПРОЕКТА………………………………………10 стр.

3. Понятие «Управление проектом» ............................................................15 стр.

Заключение……………………………………………………………………17 стр.

Список  используемой литературы…………………………………………18 стр.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

 

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

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

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

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

 

 

 

 

 

 

 

 

1.  СОДЕРЖАНИЕ УПРАВЛЕНИЯ ПРОЕКТАМИ

1.1. Понятие  «проект»

 

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

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

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

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

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

Проект  (от  лат. projectus, буквально – брошенный  вперед), 1) совокупность  документов (расчетов,  чертежей  и  др.)  для  создания какого-либо сооружения или изделия. 2) Предварительный текст  какого-либо документа. 3) Замысел, план.  

Чаще  всего  в  отечественной  практике  понятие "проект" связывается  с  первым  его  значением,  т.е.  комплексом  технической  и сметной  документации  для  создания  чего-либо.  Однако  на  западе  для обозначения  такого понятия чаще применяется термин design, а понятие "проект" (project) трактуется  более  широко.  С  этой  точки  зрения  ни сообщенная нам устно, ни изложенная на бумаге какая-либо идея сама по  себе  никаким  действием  не  является,  это  есть  лишь  описание предполагаемого  действия.  Тем  не  менее,  довольно  часто  под  этим термином  понимается  некая  кипа  бумаг,  на  титульном  листе  которой написано «проект». Проект  (project) - целенаправленный,  заранее проанализированный  и  спланированный  комплекс  взаимосвязанных мероприятий  по  созданию  или  изменению  какого-либо  объекта (совокупности  объектов)  направленный  на  достижение  заранее определенных  целей  в  течение  заданного  периода  времени,  при установленном бюджете и определенном качестве.

Проектные  материалы  (project documents) – документ (система документов), содержащий описание и обоснование  проекта. Проектирование  (projecting, designing) – процесс  подготовки (разработки) проектных материалов. Проектировщик  (designer) – лицо,  разрабатывающее или участвующее в разработке проектных материалов.

 

1.2. Структуризация  проекта

 

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

СТРУКТУРИЗАЦИЯ (декомпозиция)- это разделение сложного объекта на составляющие компоненты с более простыми свойствами и функциями.

СТРУКТУРА ПРОЕКТА  представляет собой совокупность взаимосвязанных  элементов и процессов проекта, представленных с различной степенью детализации, необходимой и достаточной  для реализации проекта на его  этапах и уровнях.

СТРУКТУРНЫЙ ПЛАН - графическое представление структуры проекта.

С одной стороны, к структуризации проектов можно  подходить дедуктивно, а с другой – индуктивно. При дедуктивной  структуризации элементы структурного плана определяются на основе так называемого top-down approach(подход «вверх вниз»). При индуктивном подходе возможные элементы плана определяются «творческим» путем, например с помощью интуитивно – креативного способа.

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

Структурный план проекта должен удовлетворять следующим  правилам:

1. Совокупность элементов каждого уровня иерархии декомпозиции проекта должна представлять весь проект.
2. Исходя из первого правила суммарное значение характеристик проекта (объемы работ, стоимость, потребляемые ресурсы, количество исполнителей) на каждом уровне структуры проекта должны совладать.
3. Нижний уровень декомпозиции проекта должен содержать такие элементы работ, на основе которых могут, определены количественные значения характеристик работ, необходимые и достаточные для оперативного управления проектом.

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

Структуризацию  проекта осуществляют одним из двух методов:

-  "сверху - вниз", когда сначала определяют  общие задачи, а затем их детализируют;

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

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

 К основным  задачам структуризации проекта следует отнести:

- разбивку проекта  на поддающиеся управлению блоки; 

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

- оценка  необходимых  затрат (средств,  времени  и  материальных ресурсов и т.д.);

- создание  единой  базы  для  планирования,  составления   смет  и контроля за затратами; 

- увязка работ  по проекту с системой учета  в организации; 

- переход   от  общих  целей  к  определенным  заданиям, выполняемым подразделениями организации;

- определение комплексов  работ/подрядов.

 Для  структуризации  проекта  используют  ряд   специальных моделей: 

-  Дерево  целей –  графы,  показывающие  как  генеральная   цель проекта разделяется на подцели следующего уровня.

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

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

Наконец,  могут  быть  определены  подразделы  и  отдельные  группы (пакеты) работ. Эта процедура  известна как структура разбиения  работ (СРР) . В  американской  практике  УП  процедуре  СРР (в  английской танскрипции этот термин звучит как WBS - work breakdown structure)  уделяется  особое  внимание.  По  мере  получения  дополнительной информации разработчик может добавлять новые уровни к дереву работ проекта,  при  этом  нижний  уровень  будет  называться  пакетом  работ.

Вычленение  пакетов  работ  представляет  большое  удобство  при разработке  сетевого  графика  работ.  Дерево  работ  помогает реализовывать две основные функции  УП: планирование и оперативное управление.  

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

-  Матрица  ответственности  – связывает  пакеты  работ   с исполнителями на основе  СРР и ОСИ. 

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

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