Тема 1 Характеристика управління проектами

• Название: Тема 1 Характеристика управління проектами
• Анкор: ekzamen_po_Upr_proektami.doc
• Дата: 06.06.2018
• Размер: 1.12 Mb.
• Имя файла: ekzamen_po_Upr_proektami.doc
• Тип: Документы; #20041
• страница: 3 из 7

21.Складові системи планування та контролю проекту: мета, характеристика робіт.

Основна мета планування полягає в побудові моделі реалізації проекту. Вона необхідна для координації діяльності учасників проекту, з її допомогою визначається порядок, в якому повинні виконуватися роботи і т. д.

Характеристики робіт:

1. Визначення цілей і завдань проекту.

Цілі і завдання визначають об’єкт проекту, є причиною його запуску.

Якісні характеристики, якими повинні володіти цілі проекту:

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

2. Узгодження проміжних результатів (цілей) включають вимірні результати, певні продукції, послуги, вимоги, аналогічно цілям.

3. Виявлення вимог допомагає оцінити успішність виконання цілей і результатів. Формують менеджер, зацікавлені особи.

4. Визначення припущень і обмежень - можуть стосуватися людей, об’єктів, варіантів розвитку подій, які повинні виконуватися або бути в наявності.

5. Складання опису змісту проекту - документально формулює цілі і проміжні результати, служить основою для прийняття майбутніх проектних рішень - займається менеджер.

Включає:

• 
  загальну характеристику проекту (опис проектної документації);
  
• 
  цілі (критерії завершення);
  
• 
  повний список проміжних результатів;
  
• 
  список виключень із змісту (проміжні результати 2-ї фази);
  
• 
  оцінка термінів і вартості на рівні 1-го порядку;
  
• 
  функції і обов’язки;
  
• 
  критерії здачі-приймання продукції;
  
• 
  допущення;
  
• 
  обмеження.
  

6. Розробка комунікаційного плану:

- план управління змістом проекту - вказує спосіб визначення змісту, розробки структурної декомпозиції робіт, характеризує і документує метод управління змістом, включає управління змінами змісту.

- план взаємодії - вказує на інформаційні потреби зацікавлених осіб, періодичність і спосіб надання інформації. Визначає хто, коли і яку інфо отримує (зацікавлені особи).

22.Сітьове планування.

Сітьова діаграма (мережа, граф мережі, PERT-діаграма) - графічне відображення робіт проекту і залежностей між ними. У плануванні та управлінні проектами під терміном «мережа» розуміється повний комплекс робіт і віх проекту з встановленими між ними залежностями.

Мережеві діаграми відображають мережеву модель у графічному вигляді як безліч вершин, відповідних робіт, пов'язаних лініями, представляють взаємозв'язки між роботами. Цей граф, званий мережею типу «вершина-робота» або діаграмою передування-слідування, є найбільш поширеним уявленням мережі.

Існує інший тип мережевої діаграми-мережу типу «вершина-подія», який на практиці використовується рідше. При даному підході робота представляється у вигляді лінії між двома подіями (Вузлами графа), які, у свою чергу, відображають початок і кінець даної роботи. PERT-діаграми є прикладами цього типу діаграм.

Методи сітьового планування - методи, основна мета яких полягає в тому, щоб скоротити до мінімуму тривалість проекту. Ґрунтуються на розроблених практично одночасно і незалежно методі критичного шляху (СРМ - Critical Path Method) та методі оцінки та перегляду планів ПЕРТ (PERT-Program Evaluation and Review Technique).

Метод критичного шляху дозволяє розрахувати можливі календарні графіки виконання комплексу робіт на основі описаної логічної структури мережі і оцінок тривалості виконання кожної роботи, визначити критичний шлях для проекту в цілому.

Діаграма Ганта - горизонтальна лінійна діаграма, на якій задачі проекту представляються протяжними в часі відрізками, що характеризуються датами початку і закінчення, затримками і, можливо, іншими часовими параметрами.

23.Складання бюджету.

Складання бюджету. Вартість проекту визначається сукупністю вартостей ресурсів проекту, вартостями і часом виконання робіт проекту. Оцінка всіх витрат по проекту еквівалентна оцінці загальної вартості

проекту. Управління вартістю проекту включає в себе процеси, необхідні для забезпечення і гарантії того, що проект буде виконаний в рамках затвердженого бюджету.

Управління вартістю і управління витратами практично є тотожними поняттями. Цілями системи управління вартістю (витратами) є розробка політики, процедур і методів, що дозволяють здійснювати

планування і своєчасний контроль витрат.

Управління вартістю (витратами) проекту включає в себе такі процеси:

»Оцінку вартості проекту;

»Бюджетування проекту, тобто встановлення цільових показників витрат на реалізацію проекту;

»Контроль вартості (витрат) проекту, постійної оцінки фактичних витрат, порівняння з раніше запланованими в бюджеті і вироблення заходів коригуючого і застережливого характеру.

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

Кошторис проекту - документ, що містить обґрунтування та розрахунок вартості проекту (Контракту), зазвичай на основі обсягів робіт проекту, необхідних ресурсів та цін.

Одним із способів, що дозволяють управляти витратами проекту, є використання структури рахунків витрат (планів рахунків). Для виконання робіт потрібні ресурси, які можуть виражатися як у праці робітників, матеріалах, устаткуванні, так і у вигляді позицій грошових витрат, коли немає необхідності або можливості знати, які конкретно ресурси їх складають. На стадії формування бюджету роботи всі ресурси, залучені для її виконання, списуються на різні статті витрат.

24.Моніторинг виконання у часі та по витратах.

Моніторинг виконання у часі та по витратах.



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

контролю вибрати відповідні вагові коефіцієнти для визначення узагальнених показників.

25.система інформування і прийняття рішень.

Система інформування і прийняття рішень. Визначивши відхилення проекту від плану, менеджер повинен вжити відповідні дії. Чим раніше коригувальні дії вжиті, тим краще. Дії по відновленню контролю над проектом рекомендується також ретельно планувати.

П'ять основних можливих варіантів дій, які найчастіше використовуються в разі відхилення проекту від плану:

»Знайти альтернативне рішення. У першу чергу необхідно розглянути можливості, пов'язані з підвищенням ефективності робіт за рахунок нових технологічних або організаційних рішень.

»Перегляд вартості - збільшення обсягів робіт і призначення додаткових ресурсів. Даний підхід зазвичай застосовується у випадку необхідності усунення тимчасових затримок проекту;

»Перегляд термінів - терміни виконання робіт будуть відсунуті. Керівництво проекту може піти на таке рішення у випадку жорстких обмежень по вартості;

»Перегляд змісту робіт - обсяг робіт з проекту може бути зменшений і відповідно лише частина запланованих результатів проекту буде досягнута.

»Припинення проекту. Це, мабуть, найбільш складне рішення. Однак воно має бути прийнято, якщо прогнозовані витрати за проектом перевищують очікувані вигоди. Рішення, пов'язане з припиненням проекту, крім суто економічних аспектів, пов'язано з подоланням проблем психологічного характеру, пов'язаних з інтересами різних учасників проекту.

26.Компоненти структуризації проекту.

Управління проектом припускає його розбивку на окремі блоки, які є самостійними об'єктами планування, обліку, організації й координування, тобто побудову структури проекту.

Структура проекту – це сукупність взаємопов’язаних елементів і процесів проекту, які представлені з різним ступенем деталізації. В термінах управління проектами структура проекту являє собою “дерево” орієнтованих на продукт компонентів, представлених обладнанням, роботами, послугами й інформацією, отриманими в результаті реалізації проекту.

Структура проекту повинна відповідати наступним вимогам:

Ø кожний рівень ієрархії повинен мати закінчений вигляд або охоплювати всю суму частин проекту, що представлені на даному рівні деталізації;

Ø сума характеристик елементів проекту на кожному рівні ієрархії структури повинна бути рівною;

Ø нижній рівень декомпозиції проекту повинен містити елементи (модулі), на основі яких можуть бути чітко визначені всі дані, що необхідні та достатні для управління проектами (функціональні характеристики, обсяги робіт, вартість, необхідні ресурси, виконавці, зв'язки з іншими елементами і т.д.).

Декомпозиція проекту означає поділ проекту на окремі компоненти, елементи, модулі, тобто виокремлення окремих рівнів ієрархії. Прийнята структура проекту з виділеною ієрархією постійних елементів утворить основу інформаційної мови проекту, на якій будуть спілкуватись всі учасники проекту і буде вестись документація.

Найбільш важливими сферами використання структурних моделей проекту є:

Ø пошук, визначення та аналіз цілей проекту;

Ø побудова та вибір альтернативних рішень щодо реалізації проекту;

Ø попереднє планування проекту за укрупненими моделями (фазовими, сітковими і т.д.);

Ø визначення ресурсів, термінів, вартості робіт;

Ø проектний аналіз (визначення життєздатності проекту);

Ø фінансовий план проекту;

Ø організація проекту;

Ø проектні роботи і система документації проекту;

Ø детальне планування робіт (календарні плани робіт, графіки постачання, бюджетування);

Ø підписання й управління контрактами;

Ø оперативне планування робіт;

Ø моніторинг проекту;

Ø регулювання ходу робіт;

Ø управління забезпеченням проекту;

Ø складання виконавчих (фактичних) моделей і графіків, аналіз результатів та накопичення досвіду.

Такий перелік використання структурних моделей неповний, але яскраво відображає важливість ролі структурних моделей і методології управління проектами.

Структуризація проекту дозволяє більш конкретно сформувати для всіх учасників проекту перелік виконуваних ними робіт, проміжні і кінцеві результати, які повинні бути отримані ними на визначених стадіях створення проекту, а також встановити між роботами раціональні інформаційні зв'язки. Вона передбачає розробку робочої структури (Work Breakdown Structure – WBS), організаційної структури проекту (Organization Breakdown Structure   OBS) та затратної структури (Cost Breakdown Structure – CBS).

Структуризація проекту — досить складний процес, оскільки він повинний враховувати всі елементи і параметри проекту: результати проекту; стадії й етапи життєвого циклу; організаційну структуру управління; ресурси на розробку й реалізацію; умови зовнішнього й внутрішнього середовищ, у яких здійснюється розробка і реалізація проекту й багато інших факторів. Тобто структуризація проекту є одним з інструментів організації проекту, основою створення системи управління проектом в цілому (через запровадження схеми тотальної інтеграції), інструментом управління персоналом проекту.

Існують такі підходи до структуризації проекту :

Ø за життєвим циклом проекту;

Ø за компонентами продукту;

Ø функціональний підхід;

Ø географічний підхід;

Ø за відповідальністю.

На жаль, у практиці управління проектами часто структуризація здійснюється тільки за одним критерієм, який ґрунтується на стадіях і етапах життєвого циклу. Інші фактори враховуються інтуїтивно і не мають чіткого алгоритму формалізації.

27.Методологія структуризації, її характеристика і значення.

У загальному вигляді проект повинен представляти синтез трьох самостійних структур: організації процесу створення проекту, процесу розробки й реалізації, результату.

Зрозуміло, методика структуризації проекту залежить, насамперед, від його специфіки й умов створення. У цьому відношенні вона завжди індивідуальна. Проте, процес структуризації можна розглядати як типовий, що складається з ряду послідовно виконуваних процедур.

Етапи розбивки й планування проектів:

1. Визначення цілей створення проекту.

2. Аналіз проекту.

3. Становлення стадії створення, декомпозиції продукту, розробка ОСУ.

4. Синтез проекту.

5. Розробка плану-графіку, підготовка функціональної матриці.

6. Створення системи завдань.

7. Організація контролю.

Процес структуризації проекту в практиці управління розпочинається на передінвестиційній стадії (етапи аналізу проблеми й розробки концепції) і закінчується на інвестиційній стадії (етапи розробки й реалізації проекту).

Структура розбивки проекту повинна поєднувати розподіл на :

Ø компоненти продукту проекту;

Ø етапи життєвого циклу;

Ø елементи організаційної структури.

Процес структуризації є невід’ємною частиною загального процесу планування проекту і визначення його цілей, а також підготовки зведеного плану проекту та матриці розподілу відповідальності та обов’язків.

В практиці управління проектами основними задачами структуризації проекту є:

1. Розбивка проекту на блоки, якими можна здійснювати управління;

2. Розподіл відповідальності за різними елементами проекту та ув’язка робіт із структурою організації;

3. Створення єдиної бази для планування, складання кошторисів і контроль за витратами;

4. Точна оцінка необхідних витрат – засобів, часу та матеріальних ресурсів;

5. Перехід від загальних, не завжди конкретно виражених, цілей до чітко визначених завдань, що виконуються підрозділами компанії;

6. Визначення комплексів робіт.

Існують 2 основних методи структуризації:

1) “зверху-вниз” (низхідний підхід) — визначаються загальні задачі, далі вони деталізуються;

2) “знизу-вгору” (висхідний) визначає окремі задачі та їх узагальнення по рівнях.

Для структуризації проекту використовується ряд спеціальних моделей:

1. “Дерево цілей” — схеми цілей, підцілей по рівнях. Основне правило розбиття — повнота: кожна мета верхнього рівня повинна бути представлена повним набором підцілей.

2. “Дерево рішень” — схеми задач оптимізації багатокрокового процесу реалізації проекту. “Гілки дерева” відображають події, які можуть мати місце, а вузли (вершини)   точки, в яких виникає необхідність вибору.

3. “Дерево робіт” (структура поділу робіт або СПР) — включає дві ієрархічні схеми, які між собою пов'язані певним чином: ієрархія виробів та ієрархія робіт. Нижній рівень ієрархії робіт відповідає пакетам робіт, які необхідні при розробці сіткового графіка. Пакет робіт може бути самостійною фінансовою одиницею і повинен мати окремий кошторис та звіт про витрати. СПР — основа для розробки структурної схеми адміністративного управління проекту.

4. Організаційна структура виконавців (ОСВ/OBS ) — в цій схемі керівник — нульовий рівень. На більш низьких рівнях — відділи, необхідні для функціонального управління роботами. Ці рівні іноді відповідають рівням СПР. Мета ОСВ — визначити виконавців, відповідальних за виконання робіт.

5. Матриця відповідальності — пов'язує пакети робіт з організаціями-виконавцями. Складається на основі СПР і ОСВ. Використовується для контролю відповідності розподілу ролей цілям проекту. На верхньому рівні розподіляються ролі та відповідальність по елементах ІСР. На нижньому – по операціях проекту.

6. Сіткова модель — на основі дерева цілей і робіт складають сітковий графік вузлових подій. Доцільно складати, крім загального (повного), сіткові графіки окремих пакетів робіт, які називаються сітковими блоками або підсітями. Це забезпечує можливість проведення ефективного контролю, дозволяє більше уваги приділяти управлінню найбільш важливими (критичними) підсітями, замість того, щоб постійно контролювати увесь сітковий графік, зекономити час.

7. Структура споживання ресурсів — ієрархічно побудований графік, який фіксує необхідні на кожному рівні ресурси. Використовується для аналізу засобів, необхідних для досягнення цілей та підцілей проекту.

8. Структура витрат — ієрархічний графік, який фіксує вартість елементів проекту на кожному рівні.

Здійснити на практиці структуризацію не так легко, як здається на перший погляд. Здійснення цього процесу є порівняно легшим стосовно “відчуваних” (речовинних) проектів, що пов’язані з будівництвом, наприклад, а не з розробкою програмного забезпечення (“інтелектуальних” проектів).

Головне завдання полягає в тому, щоб знайти матеріальні компоненти проекту.

Охарактеризуємо ці роботи:

1. Визначення цілей проекту.

Повинні бути повністю та чітко визначені:

Ø характер проекту;

Ø цілі та зміст проекту;

Ø кінцеві продукти та їх характеристика.

Доцільно використовувати ієрархію цілей.

2. Рівень деталізації. Необхідно продумати (задати) різні рівні деталізації планів та кількість рівнів та елементів у структурі розбиття проекту.

3. Структура процесу. Повинна бути підготовлена схема життєвого циклу проекту.

4. Організаційна структура. Схема організаційної структури має охоплювати всі групи та окремих осіб, які будуть працювати на проект, включаючи осіб із зовнішнього оточення, зацікавлених в проекті.

5. Структура продукту. Це схема розбиття на підсистеми або ієрархія робіт.

6. План бухгалтерських рахунків в організації. Система кодів, які використовуються при структуризації, має базуватися на плані бухгалтерських рахунків в організації.

7. Структура розбиття проекту. Вищезазначені пункти 3-6 об’єднуються в єдину структуру проекту.

8. Генеральний зведений план проекту. Може бути у подальшому деталізований у процесі пошуку критичного шляху. В ході реалізації проекту зведений план може використовуватися для доповідей вищому керівництву.

9. Матриця розподілу відповідальності. В результаті аналізу взаємовідносин між елементами структури проекту та організацією (підприємством) будується матриця, де елементи структури проекту стають рядками, а елементи схеми організації компанії — стовпчиками (або навпаки). В елементах матриці рівень відповідальності тих чи інших дійових осіб позначають за допомогою різних умовних позначень або кодів. Таким чином, матриця “призначає” кожному пакету робіт конкретних виконавців.

10. Робочий план бухгалтерських рахунків. У разі необхідності потрібно опрацювати систему субрахунків, які “стикуються” із планом рахунків (управлінський облік).

11. Робочий сітковий графік. Реалізація перших 10 кроків дозволяє розробити деталізований графік, який включає по кожній з робіт часові та ресурсні оцінки.

12. Система наряд-завдань. Випливає з попередньої структури (п.7) та матриці (п.9). На цьому етапі завдання мають бути абсолютно конкретними у часових ресурсах.

13. Система звітності та контролю. Розроблюються форми звітів та повідомлень, встановлюється спосіб їх надання тощо.

28.Підсистеми робочої структури: кінцеві результати, субпроекти, робочі модулі, робочі елементи; їх характеристика.

Робоча структура (WBS) – це ієрархічна структура, побудована з метою логічного розподілу усіх робіт з виконання проекту і подана у графічному вигляді. Це сукупність декількох рівнів, кожний з яких формується в результаті розподілу роботи попереднього рівня на її складові.

Основні етапи розробки виробничої структури:

1. Визначення ступеня деталізації проектних робіт;

2. Визначення кількості рівнів;

3. Розробка структури кожного рівня;

4. Підготовка опису елементів виробничої структури;

5. Формування системи кодування;

6. Проведення зворотних обчислень (затрати знизу доверху за принципом: відділ локалізації - субпідрядник).

На сьогодні використовується два основних підходи при застосуванні цього методу:

1. Створення тільки виробничої структури (структуризація в одному розрізі);

2. Створення виробничої і організаційної структур (у розрізі – проект і організаційні підрозділи).

На основі цих підходів використовують структуру витрат CBS та багаторівневий підхід для мультинаціональних проектів.

Створення виробничої структури може проводитись по таких рівнях:

1. Проект;

2. Стадії або субпроекти (наприклад сформовані за продуктовим принципом: забезпечення кадрами, технічне забезпечення, програмне забезпечення і управління проектом).

3. Системи або блоки;

4. Робочі пакети.

WBS може застосовуватися для поєднання робіт, які необхідно виконати, організаційних структур і відповідальності за роботу з підсистемами планування, оцінки, розподілу витрат і ресурсів, аналізу, контролю і звіту в єдину взаємопов’язану інтегро­вану систему управління проектом.

29.Основні ознаки робочого пакета як найнижчого рівня робочої структури.

На найнижчому рівні робочої структури знаходиться робочий пакет. Це група робіт чи операцій, які піддаються оцінці з погляду визначення затрат і наділення ресурсами, тривалості виконання та призначення відповідального. Структура робочого пакету має такі складові: обсяг і перелік робіт до виконання; відповідальний за робочий пакет; необхідні результати; бюджет; основні умови; терміни.



30.Переваги робочої структури проекту.

Робоча структура (WBS) – це ієрархічна структура, побудована з метою логічного розподілу усіх робіт з виконання проекту і подана у графічному вигляді. Це сукупність декількох рівнів, кожний з яких формується в результаті розподілу роботи попереднього рівня на її складові.

Переваги:

• 
  Система WBS поділяє проект на елементи робіт, що піддаються управлінню, для яких легко визначити витрати та побудувати графіки.
  
• 
  Належним чином підготовлена та побудована структура проекту задовольняє вимоги керівництва компанії, менеджера проекту та замовника.
  
• 
  Інтеграція WBS з організаційною структурою проекту допомагає менеджеру наділити учасників проекту відповідальністю за виконання конкретних технічних завдань.
  
• 
  Вона також дозволяє створити просту систему дослідження ходу реалізації проекту.
  
• 
  Формування структури починається з розподілу цілей проекту на значно менші блоки робіт аж до досягнення самих дрібних позицій, що підлягають контролю. Така деревоподібна структура дозволяє встановити логічний зв’язок між ресурсами компанії та обсягом робіт, які потрібно здійснити.
  

31.Створення двоспрямованої структури проекту на основі поєднання робочої та внутрішньої організаційної структури проекту.

Створення робочої структури проекту дає змогу визначити весь перелік робіт, які необхідно виконати, проте не відповідає на запитання, хто виконуватиме ці роботи і яким коштом. Тому дедалі частіше у проектах використовується двоспрямована структуризація, яка поєднує робочу й організаційну структури і передбачає:

• 
  робочу структуру проекту (WBS);
  
• 
  організаційну структуру проекту (OBS);
  
• 
  облік затрат;
  
• 
  описання робочих пакетів (діяльності);
  
• 
  систему кодування;
  
• 
  словник використання WBS (каталог CTR «Витрати — час — ресурси»).
  

Організаційна структура проекту (ОBS). Ця структура стосується тільки внутрішньої організаційної структури проекту і не зачіпає відносин проектних груп чи учасників з батьківськими організаціями. Будується ОBS аналогічно робочій структурі, а саме:

• 
  на першому рівні відображається організаційна структура як єдиний елемент;
  
• 
  на другому і нижчих рівнях триває поділ структури на основні організаційні елементи.
  

Цей процес повторюється до найнижчого рівня — базових робочих груп (змішаних цільових або функціональних), а при реалізації малих проектів — до окремих виконавців.

Обсяг робіт для цих найнижчих організаційних рівнів являє собою найнижчі елементи WBS, кожний з яких можна планувати і контролювати як окремі одиниці. Таке саме правило чинне для створення OBS. Кількість рівнів залежить від розміру проекту.

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

32.Структуризація затрат.

Структура статей витрат є додатковим засобом планування робіт проекту. Основна відмінність статей витрат від бухгалтерських рахунків полягає в тому, що за статтями класифікується і збирається інформація, взагалі кажучи, не підтверджена до моменту збору документально управлінська інформація (немає документів, що підтверджують факт витрат, але є попередня інформація про виконані роботи, використаних ресурсах і т. д.); ця інформація потрібна і може використовуватися тільки для прийняття управлінських рішень. Необхідні документи з'являться тільки до певних вимог бухгалтерського обліку

календарним датам, а не до поточних датам проекту.

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

У статтях витрат може акумулюватися інформація з різних пакетам робіт, сформованим за різними підставами (відібраним по фільтрам):

»За змістом;

»За термінами виконання;

»За структурою рахунків, субрахунків;

»За відповідальним виконавцям.

Таким чином, статті витрат допомагають формувати і відслідковувати бюджет проекту, здійснювати поточний управлінський облік і оцінювати можливі витрати по завершенні робіт проекту.

При плануванні великих проектів число окремих статей витрат може досягати декількох тисяч. Це може призвести до певних труднощів і з їх описом на стадії планування, і з урахуванням фактичної інформації по ним на стадії виконання проекту. В якості одного з рішень цієї проблеми використовується підхід по формуванню багатофункціональних проектних команд. Його суть полягає в тому, що стаття витрат призначається не окремо взятому організаційного підрозділу, а так званої багатофункціональної команді. Така стаття охоплює велику кількість робіт і відповідає більш високому рівню СДР. Загальна кількість статей витрат при цьому скорочується.

33.Поєднання робочої, організаційної і затратної структур у трьоспрямованій структурі проекту.

Трьохспрямована структура проекту створюється додаванням до двоспрямованої структури третьої — структури затрат (Cost Breakdown Structure — CBS).

CBS утворюється за алгоритмом, аналогічним алгоритму створення WBS і OBS. Перший рівень — це всі витрати на проект. Другий рівень — основні елементи CBS: матеріали, вузли, комплектуючі; витрати на утримання устаткування; трудові витрати; інші витрати.

Третій рівень — подальша розбивка. Наприклад, для трудових витрат це будуть: витрати на добір і навчання; витрати на оплату праці з поставки і монтажу устаткування; витрати на оплату праці з програмного забезпечення.

Четвертий рівень — подальша розбивка, наприклад, для оплати праці з програмного забезпечення: оплата праці програмістів; оплата праці системних аналітиків; оплата праці операторів.

Ця структура дає змогу збирати інформацію про затрати, аналізувати й готувати звіти по затратах будь-якого підрозділу або елементу робіт.

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

34.Розробка матриці відповідальності.

Матриця відповідальності — графік, який співставляє функціональні обов’язки з елементами ієрархічної структури.

Матриця відповідальності забезпечує опис та узгодження структури відповідальності за виконання пакетів робіт. Вона являє собою форму опису розподілу відповідальності за реалізацію робіт по проекту, із зазначенням ролі кожного з підрозділів в їх виконанні. Матриця містить список пакетів робіт СДР по одній осі, список підрозділів і виконавців, які беруть участь у виконанні робіт, - по інший. Елементами матриці є коди видів діяльності (зі заздалегідь визначеного списку) і (або) вартість робіт.

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



У табл. показаний приклад матриці відповідальності. Ролі в прикладі вказують вид участі підрозділів у роботі: О - відповідальний виконавець, И - виконавець, П - приймання робіт, К - Консультації.
Матриця може також відображати види відповідальності конкретних керівників за ті чи інші роботи. Крім того, в матриці можуть бути відображені ролі людей, не задіяних безпосередньо в проекті, але які можуть надавати підтримку в роботі команди.

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

35.Кодування робіт.

Система кодування. Ключем до інтеграції окремих елементів проекту є систематизована система кодування, яка допомагає структурувати проект, визначити елементи обліку витрат, WBS i OBS і встановити їхні взаємовідносини. Вона використовується, щоб відокремити і вод­ночас поєднати все: роботи, їх планування і контроль, ресурси і кошти, облік, оцінку тощо.

Кодування — це життєво необхідний компонент інформаційної системи управління проектами. У кодуванні використовуються багатоцифрові номери або комбінації цифр і літер, кожна з яких має свій зміст, своє значення.

Кожний кодовий номер відповідає певним витратам, WBS або ОBS рівню та елементу, а також вказує на взаємостосунки у структурах WBS і ОBS. Кожний рівень структури представлено частиною коду. Одна частина презентує структуру WBS, друга — ОBS. Пов’язуючи їх, ми отримуємо витрати, притаманні цим структурам та їхнім окремим елементам.

Кодування WBS.

1. Код першого рівня - проект, як правило, кодується одно- чи двозначним числом.
2. Код другого рівня - наступні одна чи дві цифри WBS-коду представляють елементи WBS другого рівня. Якщо використовуємо цифрову нумерацію — можна нумерувати дев’ять елементів, літерову — відповідно до літери абетки.

3. Код третього рівня - для наступного рівня додається ще одна цифра.

Кодування ОBS. Ця система кодується аналогічно WBS.

1. Код першого рівня - даний рівень може мати код, а може і не мати його.

2. Код другого рівня. - друга цифра (або дві для великого проекту) представляє елементи другого рівня. 3. Код третього рівня - наступна цифра ОBS-коду представляє елементи третього рівня.

Таким чином, при кодуванні організаційної структури перша цифра представляє організацію в цілому; друга — відділи; третя — групи.

36.СТR – словник для середніх та великих проектів на підприємстві.

Створення робочої структури проекту дає змогу визначити весь перелік робіт, які необхідно виконати, проте не відповідає на запитання, хто виконуватиме ці роботи і яким коштом. Тому дедалі частіше у проектах використовується двоспрямована структуризація, яка поєднує робочу й організаційну структури і передбачає:

• 
  робочу структуру проекту (WBS);
  
• 
  організаційну структуру проекту (OBS);
  
• 
  облік затрат;
  
• 
  описання робочих пакетів (діяльності);
  
• 
  систему кодування;
  
• 
  словник використання WBS (каталог CTR «Витрати — час — ресурси»).
  

У зв’язку зі створенням WBS/ОBS-структур та кодуванням їх потрібно створити словник, який би визначав елементи й облік затрат. Це гарантує розуміння кожним залученим до проекту значення і змісту кожного з елементів WBS або ОBS. Словник може бути розширений визначенням обсягу робіт, вит­рат, ресурсів та обмежень за часом. Це може бути подано у виг­ляді каталогу «Витрати –– час — ресурси» (Cost — Time –– Resources, або CTR).

CTR-СЛОВНИК

Номер	Код роботи	Зміст роботи	Затрати, грн	Тривалість, дні	Необхідні ресурси
…
3.	813-42	Навчання систем­них аналітиків	4000	5	Тренери — 2 особи Аудиторія — 5 днів

Роботу зі систематизації і поєднання робіт треба обов’язково виконати на певній стадії планування проекту. Для кожного виду діяльності потрібно визначити час, ресурси і затрати, щоб у подальшому формувати систему планів і здійснювати їх контроль, причому сума затрат і ресурсів за видами діяльності має відповідати затратам і ресурсам, виділеним для цього підрозділу, і навпаки.