Лекція1А (тема 1).

ВВЕДЕННЯ В УПРАВЛІННЯ ПРОЕКТАМИ

План
1. Поняття проекту
2. Причини виникнення і сутність управління проектами
3. Передумови для вибору методології управління проектами
4. Відмінності між управлінням проектами і виробничим управлінням
5. Класифікація проектів

Література
Основна:

1. Арчибальд Р. Управление высокотехнологическими программами и проектами. - М.: ДМК

Пресс, 2002.- 464 с.
2. Батенко Л.П., Загородніх О.А., Ліщинська В.В. Управління проектами: Навч. посібник. – К.:
КНЕУ, 2003. – 231 с.
3. Кантор М. Управление программными проектами. Практическое руководство по разработке
успешного программного обеспечения.: Пер. с. англ. – М.: Издательский дом "Вильямс", 2002. –
176 с.
4. Кочетков А.Г. и др. Управление проектами (зарубежный опыт). –СПб.:"ДваТри", 1992. – 515
с.
5. Ройс У. Управление проектами по созданию программного обеспечения. Унифицированный
подход. - М. : "ЛОРИ", 2002. – 424 с.
6. Управление программами и проектами: (Модульная программа для менеджеров) / М.Л. Разу
и др. – М.: ИНФРА – М., 2000. – 392 с.
7. Фергус О’Коннел. Как успешно руководить проектами. Серебряная пуля: Пер. с англ. – М.:
КУДИЦ-ОБРАЗ, 2003. – 288 с.
8. Шапиро В.Д. и др. Управление проектами. – СПб.: "ДваТри", 1993. – 443 с.

Додаткова:

1. Ахъюджа Х. Сетевые методы в проектировании и производстве. –М.: Мир, 1979. – 638с.

2. Богданов В. "Управление проектами в Microsoft Project 2003". Учебный курс. – СПб.:
Издательский дом "Питер", 2004. – 608 с.
3. Мерсер Д. ИБМ: Управление в самой преуспевающей корпорации мира. –М.: Прогресс, 1991.
– 453 с.
4. Мир управления проектами / Под ред. Х.Решке, Х.Шелле; Пер. с англ. – М.:"Альянс", 1993,
304 с.
5. Роджерс Ф., Фостер Д. ИБМ: Взгляд изнутри : человек  фирма  маркетинг. М.: Прогресс,
1990. – 287 с.

1. Поняття проекту
 Традиційне радянське розуміння проекту - сукупність документації по
створенню будь-яких об'єктів. На Заході це називається дизайном або
інжинірингом.
У сучасній західній практиці та літературі ПРОЕКТ - процес
цілеспрямованої зміни технічної або соціально-економічної системи, що
переводить її з одного стану в інший. Основа західної. концепції проекту - погляд
на проект як на щось суцільне протягом усього його життєвого циклу.
ПРОЕКТ - деяка задача з певними. початковими даними і бажаними
результатами/ цілями, що обумовлюють способи її рішення.
ПРОЕКТ: одноразова сукупність взаємопов’язаних дій, які
здійснюються з певною метою, протягом певного часу, при встановлених
ресурсних обмеженнях. Це найбільш повне визначення.
Проект, як і будь-яка діяльність, має низку властивих йому рис, знання яких
допоможе здійснити ефективну реалізацію проекту.
До таких рис можна віднести наступні:
− Виникнення, існування та закінчення проекту у певному оточенні;
− Зміна структури проекту протягом життєвого циклу;
− Наявність певних зв’язків між елементами проекту як системи;
− Можливість відміни вхідних ресурсів проекту.
Виходячи з визначення проекту можна виділити наступні характеристики
(ознаки) проекту:
1) спрямованість на досягнення конкретної цілі/цілей, які можуть бути
досягнуті з одночасним виконанням низки технічних, економічних та інших
вимог;
2) координоване виконання взаємопов’язаних дій (внутрішні та зовнішні
взаємозв'язки операцій, задач і ресурсів включно);
3) обмежена протяжність у часі (будь-який проект має чітко визначений
термін початку і термін завершення);
 4) обмеженість ресурсів (будь-який проект має свій обсяг матеріальних,
людських та фінансових ресурсів, які використовуються за встановленим і
лімітованим бюджетом);
5) певна міра неповторності та унікальності (як мети, так і умов його
здійснення );
6) неминучість різних конфліктів (ризик).

2. Причини виникнення і сутність управління проектами

Будь-який проект проходить ряд етапів/фаз/стадій. Для проведення проекту

через всі фази ним треба управляти.
Необхідність методології управління проектами, усвідомлена в середині 50-
х років в розвинених країнах світу, викликана масовим зростанням складності і
кількості проектів, а також посиленням впливу наступних чинників:
1) вимоги замовників і збільшення їх компетентності
2) складність кінцевих продуктів проектів
3) взаємозв'язок і взаємовплив зовнішнього оточення проекту
4) міра невизначеності і ризику
5) організаційні перебудови
6) частота зміни технологій
7) помилки планування і ціноутворення
Вплив цих чинників призводив до порушення термінів здійснення проекту,
перевитрат коштів, невиконання вимог до характеристик кінцевої продукції, що
вело до зменшення прибутку, а нерідко -- і до збитків.
Методи управління проектами дозволяють:
1) визначити цілі проекту і провести його обгрунтування
2) виявити структуру проекту: підцілі, основні етапи, роботи
 3) визначити необхідні об'єми і джерела фінансування
4) підібрати виконавців, зокрема через торги, тендери, конкурси
5) підготувати і укласти контракти
6) визначити терміни виконання проекту
7) скласти графік реалізації проекту
8) розрахувати необхідні ресурси
9) розрахувати кошторис і бюджет
10) спланувати і врахувати ризики
11) забезпечити контроль за ходом виконання проекту
Для методології управління проектами характерно зосередження прав і
відповідальності за досягнення цілей на одній людині або невеликій групі.
Інститут управління проектами США дає визначення:
"Управління проектами - мистецтво керування, і координації людських і
матеріальних ресурсів протягом життєвого циклу проекту шляхом застосування
системи сучасних методів і техніки управління для досягнення визначених в
проекті результатів за складом і об'ємом робіт, вартістю, якістю і задоволенням
потреб учасників проекту."
Рис. 2 Піраміда “арсеналу” управління проектами

3. Передумови для вибору методології управління проектами

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

управління, і не скрізь їх доцільно застосовувати. Приймаючи рішення стосовно
використання методології управління проектами, необхідно відповісти на ряд
питань, і якщо більшість або найбільш критичні питання мають позитивні
відповіді, то необхідно прийняти цю методологію:
1) чи великий проект
 2) чи складений проект технічно
3) чи є проект системою підпроектів, які повинні бути об'єднані в один
4) чи є проект частиною іншої системи, і чи потрібна інтеграція з нею; чи є у
більшої системи проектна організація
5) чи є потреба в єдиному джерелі інформації і відповідальність за проект
загалом
6) чи потрібен суворий кошторисний і фінансовий контроль
7) чи передбачаються великі обмеження по кошторису і / або графіку
8) чи необхідне швидке реагування на зміну умов проекту
9) чи пов'язаний проект із залученням великого числа функціональних
підрозділів і виконанням великого числа видів робіт
10) чи може проект серйозно вплинути на організаційну структуру, що
склалася
11) чи треба залучати більше двох підрозділів для взаємодії із
замовниками/споживачем
12) чи є інші складні проекти, які будуть здійснюватися і конкурувати з
даним проектом
13) чи можливий конфлікт між лінійними менеджерами, що залучаються до
проекту
14) чи є організація, що відповідає за своєчасне закінчення проекту
15) чи можуть якісь зміни нанести збитки проекту до його завершення
16)чи потрібні велика зовнішня закупівля і постачання матеріалів,
обладнання, послуг
17) чи треба залучати субпідрядників для виконання більшої частини
проекту
18) чи потрібна експертиза / затвердження проекту державними органами, і
чи можуть вони викликати проблеми і протиріччя
 4. Відмінності між управлінням проектами і виробничим управлінням

В управлінні проектами можна виділити такі відмінності у порівнянні з

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

5. Класифікація проектів
 Для зручності аналізу і синтезу об'єктів безліч різноманітних проектів
можуть бути класифіковані за різними ознаками:
1. За складом і структурою проекту і його предметною областю (клас
проекту): монопроект (окремий проект); мультипроект (комплексний проект,
складається з монопроектів); мегапроект.
2. За основною сферою діяльності в якій здійснюється проект: технічний,
організаційний, економічний, соціальний і змішаний. Таке угрупування визначає
тип проекту.
Організаційні проекти характеризуються:
- проекти зазделегідь визначені, але результати проекту кількісно і якісно
важко визначити, оскільки вони пов'язані з організаційним поліпшенням системи;
- строки і тривалість задаються заздалегідь, ресурси надаються по
можливості;
- витрати на проект фіксуються і зазнають контролю на економічність,
однак потребують коригувань по мірі прогресу проекту.
Економічні (приватизація, наприклад):
- цілі - поліпшення економічних показників функціонування системи;
головні цілі проекту є попередніми. Вони намічаються, але потребують
коригування по мірі реалізації проекту . Це стосується тривалості і термінів
виконання проекту також
- ресурси надаються по мірі необхідності і в розмірах можливого;
- витрати встановлюються заздалегідь, контролюються на економічність і
контролюються по мірі реалізації проекту.
Соціальні (реформування системи соціального забезпечення, наприклад):
- цілі тільки намічаються і далі коригуються по мірі досягнення проміжних
результатів; кількісна. і якісна їх оцінка суттєво утруднена;
 - терміни і тривалість проекту залежать від вірогіднісних чинників або
тільки намічаються і надалі підлягають уточненню;
- витрати залежать від бюджетних асигнувань;
- ресурси виділяються по мірі потреби;
- мають велику невизначеність.
3. За характером предметної області проекти бувають (вид проекту):
інвестиційними; інноваційними; науково-дослідними; учбово-освітніми;
змішаними.
Інвестиційний - відносять проекти, в яких головною метою є створення або
реновація основних фондів, що вимагає вкладення інвестицій.
Для інвестиційних проектів характерно:
- чітко визначені і фіксовані мета, термін завершення і тривалість, витрати
на проект.
- необхідні ресурси і фактична вартість залежать від ходу виконання робіт
по проекту і необхідні потужності повинні надаватись відповідно до графіка і
терміну готовності етапів і завершення проекту.
Інноваційний - головною метою є розробка і застосування нових
технологій ноу-хау та інших нововведень, забезпечення розвитку системи.
Проекти дослідження і розвитку:
- головна мета проекту чітко визначена, але окремі цілі (підцілі) можуть
уточнюватися по мірі досягнення проміжних результатів,
- термін завершення і тривалість проекту визначається зазделегідь, бажане
їх точне дотримання, але вони можуть коригуватися в залежності від отриманих
результатів і загального прогресу проекту.
Планування витрат на проект часто залежить від виділених асигнувань і як
прави ло менше від бюджету, що виділяється для проекту.
4. За тривалістю періоду здійснення проекту: короткострокові (менше 3);
середньострокові (3-5 років); довгострокові (більше за 5).
 5. За ступенем складності: прості, складні, дуже складні.
6. За масштабами самого проекту, кількістю учасників і ступенем впливу
на навколишній світ: малі, середні, великі, дуже великі.

Лекція1Б (тема 1). ОСОБЛИВОСТІ УПРАВЛІННЯ ОКРЕМИМИ

ПРОЕКТАМИ

План

1. Поняття “нормального проекту"

2. Особливості управління малими проектами
3. Особливості управління мегапроектами
4. Особливості управління короткостроковими проектами
5. Особливості управління бездефектними проектами
6. Особливості управління мультипроектами
7. Особливості управління проектами модульного будівництва
8. Особливості управління міжнародними проектами
Література
Основна:

9. Арчибальд Р. Управление высокотехнологическими программами и проектами. - М.: ДМК Пресс, 2002.- 464 с.
10. Батенко Л.П., Загородніх О.А., Ліщинська В.В. Управління проектами: Навч. посібник. – К.: КНЕУ, 2003. – 231 с.
11. Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения.: Пер. с.
англ. – М.: Издательский дом "Вильямс", 2002. – 176 с.
12. Кочетков А.Г. и др. Управление проектами (зарубежный опыт). –СПб.:"ДваТри", 1992. – 515 с.
13. Ройс У. Управление проектами по созданию программного обеспечения. Унифицированный подход. - М. : "ЛОРИ", 2002. – 424 с.
14. Управление программами и проектами: (Модульная программа для менеджеров) / М.Л. Разу и др. – М.: ИНФРА – М., 2000. – 392 с.
15. Фергус О’Коннел. Как успешно руководить проектами. Серебряная пуля: Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 288 с.
16. Шапиро В.Д. и др. Управление проектами. – СПб.: "ДваТри", 1993. – 443 с.
Додаткова:

6. Ахъюджа Х. Сетевые методы в проектировании и производстве. –М.: Мир, 1979. – 638с.

7. Богданов В. "Управление проектами в Microsoft Project 2003". Учебный курс. – СПб.: Издательский дом "Питер", 2004. – 608 с.
8. Мерсер Д. ИБМ: Управление в самой преуспевающей корпорации мира. –М.: Прогресс, 1991. – 453 с.
9. Мир управления проектами / Под ред. Х.Решке, Х.Шелле; Пер. с англ. – М.:"Альянс", 1993, 304 с.
10. Роджерс Ф., Фостер Д. ИБМ: Взгляд изнутри : человек  фирма  маркетинг. М.: Прогресс, 1990. – 287 с.

1. Поняття “нормального проекту"

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

2. Особливості управління малими проектами

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

3. Особливості управління мегапроектами

 Мегапроекти:
- висока вартість;
- потреба в фінансових коштах вимагає нетрадиційної форми фінансування;
- великий об'єм робіт;
- необхідність участі інших країн;
- віддаленість районів, де реалізуюся мегапроекти, додаткові витрати на
інфраструктуру;
- вплив на навколишнє середовище регіону.
При організації управління необхідно враховувати чинники:
- розподіл елементів проекту по різних виконавцях і необхідність координації
їх діяльності;
- необхідність аналізу соціального середовища регіону, країни загалом, ряду
країн - учасниць проекту;
- необхідність виділення в якості самостійної фази розробку концепції
проекту;
- розробка і постійне оновлення планів проекта;
- необхідність моніторингу проекта з постійним оновленням всіх його
елементів;
- урахування унікальності мегапроекта.

4. Особливості управління короткостроковими проектами

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

5. Особливості управління бездефектними проектами

Бездефектні проекти - домінує підвищена якість. Для них характерна висока вартість.
Вимоги:
− об'єднаний план проектних і будівельних. робіт
− поєднання графіка будівництва з графіком пускових робіт;
− ранній пуск окремими технологічними лініями, що дозволяє зазделегідь
перевірити і забезпечити якість усіх систем проекту;
− використання програми, що спеціально розробляється,
− аналіз проблем, пов'язаних з проектом, що дозволяє їх виявити і усунути;
− застосування max гнучкої системи У П

6. Особливості управління мультипроектами

Мультипроекти: в методології УП існують такі мультисередовища:
1) Один підрядчик виконує комплекс схожих робіт для різних замовників
 2) декілька підрядчиків виконують роботи для одного об'єкта і одного
замовника
3) декілька підрядчиків виконують роботи за окремими контрактами для
різних замовників в загальному географічному просторі.
У названих варіантах мова йде про змагання в умовах обмежених ресурсів.
Основна задача менеджера проекта - забезпечити розподіл обмежених ресурсів
між партнерами, що беруть участь в організації мультипроекту, кооперуючись з
ними і координуючи свої дії.

7. Особливості управління проектами модульного будівництва

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

8. Особливості управління міжнародними проектами

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

Лекція 2А (тема 2). ЖИТТЄВИЙ ЦИКЛ (ЖЦ) І ФАЗИ ПРОЕКТУ

План

1. Поняття ЖЦ проекту
2. Фази проекту

1. Поняття ЖЦ проекту

ЖЦ проекту - проміжок часу між появою проекту і його завершенням.

ЖЦ проекту є початковими даними для прийняття рішень з капітальних
вкладеннях на його реалізацію та інвестиції. Стани через які проходить проект
називаються фазами. Кількість етапів і їх послідовність залежить від конкретних
умов здійснення і досвіду основних учасників. Однак логіка і основний зміст
етапів є загальними. Відповідно до пропозиції інституту створення і управління
проектами прийнято виділяти 4 основні фази:
1 - концепція
 2 - розробка
3 - реалізація
4 - завершення
Момент оформлення офіційних документів може вважатися моментом
початку і закінчення проекту. Головне в процесі виділення фаз ЖЦ проекту - це
виявлення конкретних контрольних точок. Під час проходження яких
переглядається додаткова інформація та оцінюються можливі напрямки розвитку
проекту.

2. Фази проекту

1 - Початкова фаза або концепція.

Головний зміст робіт - розробка концепції проекту, яка включає збір
початкових даних і аналіз існуючого стану, попередні дослідження. Виявлення
потреб у змінах проекту, визначення проекту, яке включає в свою чергу: Цілі,
Задачі, Результати, Основні вимоги, Обмежувальні умови, Критерії, Рівень ризику,
Оточення проекту, Потенційні учасники, Необхідний час, Ресурси, Кошти та інш.
Визначення і порівняльна характеристика альтернатив. Представлення
пропозицій, їх випробування і експертиза, затвердження концепції і отримання
схвалення для наступної фази розробки
2 - Фаза розробки - розробка основних компонент проекту і підготовка до
його реалізації.
Загальний зміст робіт:
- Призначення керівника проекту і формування команди проекту.
- Встановлення ділових контактів, встановлення вимог замовника і власника
проекту, ключових учасників.
- Розвиток концепції та основний зміст проекту: Кінцеві результати,
Стандарти якості, Структура проекту, Основні роботи, Необхідні ресурси.
Структурне планування в т.ч. декомпозиція проекту, календарні плани, укрупнені
графіки, кошторис і бюджет проекту, потреба в ресурсах, розподіл позовів (исков).
Організація проведення торгів, укладання субконтрактів. Організація виконання
базових проектів і дослідно-конструкторських робіт по проекту, представлення
проекту, отримання ухвали на продовження робіт.
3 - Фаза реалізації проекту - виконання основних робіт по досягненню
основних цілей проекту.
Основні роботи цієї фази:
1 - Організація проведення торгів і укладання контрактів;
2 - Введення в дію системи управління проектом;
3 - Організація виконання робіт;
4 - Введення в дію засобів і способів комунікації учасників проекту;
5 - Введення в дію системи мотивації і стимулювання команди проекту;
6 - Детальне проектування і технічна специфікація;
7 - Оперативне планування робіт;
8 - Встановлення системи інформаційного контролю за ходом робіт;
9 - Організація і управління матеріально-технічним забезпеченням робіт;
10 - Виконання робіт, передбачених проектом у т.ч. виконання будівельно-
монтажних і пусково-налагоджувальних робіт;
11 - Керівництво, координація робіт, узгодження темпів, моніторинг
прогресу, прогноз стану, оперативний контроль, регулювання основних
показників проекту;
12 - Розв'язання проблем, що виникли і задач.
4 - Фаза завершення проекту - на цій фазі досягаються кінцеві цілі проекту,
підведення підсумків вирішення конфліктів і закриття проекту.
Основний зміст робіт на цій фазі:
1 - Планування процесу завершення;
2 - Експлуатаційне випробування продукту;
3 - Підготовка кадрів для експлуатації відповідного об'єкта;
4 - Підготовка документації;
5 – Здавання об'єкта замовнику;
6 - Введення в експлуатацію;
7 - Оцінка результатів проекту і підведення підсумків;
8 - Підготовка підсумкових документів;
9 - Закриття робіт і проектів;
 10 - Вирішення конфліктних ситуацій;
11 - Реалізація ресурсів, що залишилися;
12 - Накопичення фактичних і дослідних даних для подальших проектів;
13 - Розформування команди проекту.
Розподіл ЖЦ проекту на фази може бути різноманітним, наприклад, за
пропозицією ЮНІДО:
1. Передінвестиційна фаза: аналіз інвестиційних можливостей, попереднє
техніко-економічне обгрунтування.
2. Інвестиційна фаза включає переговори і укладання контрактів,
проектування, будівництво, маркетинг, навчання.
3. Експлуатаційна фаза включає приймання і запуск, заміну обладнання,
розширення і інновації.
Слайд!!!
Слайд!!! (дать нарисовать)

Лекція 2Б (тема 2) МОДЕЛЮВАННЯ ЖЦ ПРОЕКТУ ІС

План
1. Узагальнена модель ЖЦ проекту ІС
2. Каскадна модель ЖЦ проекту ІС
3. Спіральна модель ЖЦ проекту ІС
4. Інші моделі
5. Вибір моделі ЖЦ проекту ІС

1. Узагальнена модель ЖЦ проекту може бути представлена 3-ма

фазами:

1. Розробка стратегії;
2. Створення і впровадження системи;
3. Супровід проекту;
(1) - звичайно виконує замовник спільно з майбутнім її користувачем. У
залежності від кваліфікації замовника і складності системы, ця стратегія може
бути зафіксована в документах. Коли замовником є державна організація, то при
розробці стратегії звичайно визначають мету автоматизації, користувачів,
очікувані переваги, необхідні ресурси для створення ІС, джерела і чинники
ризику, передбачуваного розробника і порядок взаємодії з ним, організацію
проекту і розподіл відповідальності за його реалізацію. Всі ці відомості
відображаються в документах, що ініціюють розробку ІС. У вітчизняній практиці
ці документи це ТЗ.
(2) - створення ІС і її впровадження. Вона може бути побудована в залежності
від прийнятої моделі ЖЦ проекту. Головну роль протягом цієї фази відіграє
організація-розробник.
(3) - супровід здійснюється розробником після впровадження системи, коли
вона надходить в розпорядження замовника або організації користувача. У
процесі супроводу розробник усуває всі помилки, виявлені після впровадження,
здійснює адаптацію ІС з урахуванням умов експлуатації, на вимогу замовника
доопрацьовує її з метою підвищення якості функціонування.
Слайд!!!
Існуючі моделі ЖЦ розрізнюються структурою і конкретним змістом фаз
створення і впровадження ІС. Всі такі моделі утворять спектр моделей на
протилежних кінцях якого знаходяться Каскадна та Спіральна моделі.

2. Каскадна модель ЖЦ проекту ІС

Каскадна модель - характеризується структурою впорядкованих стадій з

яких складаються стадії створення і впровадження. Така впорядкованість
передбачає, що всі передбачені роботи повинні виконуватись настільки ретельно,
щоб не переглядати прийняті рішення. Модель містить тільки цикл на стадії
супроводу. Склад і назва технологічних стадій у різних авторів різна. Відмінності
зводяться до ступеню деталізування. Американський стандарт стадій створення
автоматизованої системи військового призначення DOD-STD-2167A. Передбачає
стадії, наведені на слайді 2.
Слайд!!!
 У інших джерелах, ГОСТ 34.601-90 "Інформаційна технологія. Стадії
створення" відсутні окремі стадії, наприклад, планування, оскільки ця діяльність
за своїм характером є управлінською та не належить до основної діяльності по
проекту.
Переваги каскадної моделі:
1) Детермінованість моделі;
2) Чітка регламентованість (що спрощує управління проектом, особливо
контроль за виконанням ).
Недоліки каскадної моделі:
1) Від затвердження ТЗ до впровадження готового продукту минає багато
часу. Існує ризик, що вимоги користувачів зміняться і не будуть задоволені.
2) Можливі випадки, коли реальні потреби залишилися незмінними, але були
неправильно або недостатньо використані користувачем під час розробки ТЗ.
Слайд!!!
3. Спіральна модель ЖЦ

Спіральна модель передбачає багаторазове проходження тих же самих стадій

проекту доти, доки він не буде задовольняти замовника.
Слайд!!!
Ця модель відображає ітеративний характер, властивий процесу створення
таких складних проектів, якими є програмне забезпечення ІС. На кожній ітерації
створюють діючий прототип, піддають критичної оцінки. На заключній ітерації
прототип приймають за остаточний варіант системи.
Переваги - відсутність нестач каскадної моделі, так як можна врахувати
вимоги, що змінилися.
Недоліки - складність планування та організації робіт, значні витрати
ресурсів при розробці великих проектів. Використовується для невеликих
проектів, існує велика невизначеність відносно вимог користувача.
Якщо проект великий, то зазвичай виділяють в ньому обмежену подсистему,
яку доцільно розробляти використовуючи спіральну модель. Ця модель
використовується у випадках, коли замовник, розробник і користувач -- одна
особа, продукт для масового споживача.
 4. Інші моделі

Проміжний стан між моделями, що розглядаються, є наступні моделі:

1) Метод швидкого прототипу;
2) Метод послідовного нарощування функцій;
3) Еволюційна модель;
4) Модель заснована на повторному використанні компонент;
5) Модель заснована на автоматизованому синтезі програм;
(1) - передбачає розробку в стислі терміни діючого макета частини ІС
найбільш критичної до змін вимоги користувача, проведення досвідченої
експлуатації пакету до переходу до розробки основного зразка. Зазвичай
насамперед підлягає прототипуванню інтерфейс користувача до майбутніх змін.
Це дозволяє залучити користувача до участі в розробці на ранніх стадіях і
уникнути дорогих доробок кінцевих змін.
Основне призначення - полегшити виявлення вимог користувача. Прототип
після ТЗ не використовується і в іншому модель ЖЦ, бо співпадає з каскадною.
Приклад такого підходу Британський стандарт SSADM. Він реалізовує
модель схожу на каскадну, однак передбачає багатократне коректування
документів.
(2) - полягає в поетапній розробці і реалізації системи, на кожному етапі
збільшується кількість функцій. Ця модель дозволяє зменшити час впровадження.
Таким чином користувач раніше починає відчувати перевагу від автоматизації.
Таким чином перевага - скорочення термінів окупності.
Слабка сторона - складність планування і управління в поєднанні з
необхідністю дотримання відкритої архітектури. Цей метод доцільно
використати в управлінських ІС. В першу чергу може бути реализована ІС, в
який реалізуються порівняно прості інформаційні задачі, впровадження яких
може дати відразу помітний ефект.
(3) - передбачає доробку ІС до рівня якості, який задовольнить кінцевого
користувача, безпосередньо в процесі дослідної експлуатації. Реалізацію ІС
починають з тих функцій, про які розробники мають чітке уявлення. Знання
відносно інших функцій системи уточнюють вже після її часткової впровадження
в експлуатацію. У цьому даний підхід є протилежним до метода швидкого
прототипу, при застосуванні якого розробники починають реалізацію функцій
відносно яких у них існує найбільше сумнівів. При створенні складної ІС
еволюційний підхід дозволяє з самого початку зосередиться на досягненні
високих експлуатаційних характеристик, до яких відносять надійність,
мобільність, модифікованість та ін.
Еволюційний підхід доцільно використовувати при розробці ІС, в якій роботи
по створенню ПО не належать критичному шляху загального графіка робіт.
(4) - основа "складального" програмування дозволяє істотно скоротити
вартість і тривалість розробки ІС, а також підвищити її надійність під час
супроводу. Найбільший ефект відзначається в тих випадках, коли значну частку
задач вдається формулювати в термінах порівняно невеликої кількості підзадач,
яким ставить у відповідність стандартні підпрограми. Тоді розробка чергової
задачі зводиться до написання порівняно не складної програми, що викликає
підпрограми у визначеній послідовності і організує обмін даними між ними.
Такий підхід передбачає дослідження понять і відносин відповідної предметної
області та розробку реалізуючого їх пакету при формалізації задач.
Дана модель є ідеалізацією і в чистому вигляді не використовується.
(5) - заснований на трансляції спеціально розроблених програм на мові
високого рівня в машинні програми. У сучасному розумінні ця концепція
заснована на знаннях як про предметну область так і про процес створення
програмних засобів. На відміну від інших підходів він вимагає досить високих
первинних витрат на побудову моделі знань та особливо на створення
інструментальних засобів їх підтримки, що збільшує вартість розробки.
В цей же час автоматизований синтез програм дозволяє різко скоротити всі
види витрат на кожний подальший зразок ІС і реалізувати високу якість
програмного продукту.

5. Вибір ЖЦ ІС
 Для вибору необхідно порівняти сильні і слабкі сторони. Вибір залежить від
того, хто є замовником ІС. Якщо це - ринок або замовник- не держ.організація, то
вибір диктується тільки логікою здорового глузду. Якщо проект розробляється за
державним замовленням, то необхідно дотримуватись ДСТУ, тобто треба
застосовувати каскадну модель.

Лекція 2В (тема 2). ВИКОРИСТАННЯ СТАНДАРТІВ ОРГАНІЗАЦІЇ

ЖИТТЄВИХ ЦИКЛІВ СИСТЕМ

План
1. Види стандартів
2. Oracle Method
2.1. Методика Oracle CDM (Custom Development Method)
2.2. Методика Oracle PJM (Project Development Method)
3. Міжнародний стандарт ISO/IEC 12207

1. Види стандартів

Стандарти класифікують за наступними класифікаційними ознаками:

За предметом стандартизації:
− функціональні стандарти (стандарти на мови програмування, інтерфейси,
протоколи);
− стандарти на організацію життєвого циклу (ЖЦ) створення та використання
автоматизованих систем (АС), інформаційних систем та програмного
забезпечення (ПЗ).
За організацією, що затвердила:
- офіційні міжнародні стандарти;
- офіційні національні або національні відомчі (наприклад ДСТУ, ANSI,
IDEFO/1);
- стандарти міжнародних консорціумів та комітетів з стандартизації (OSF,
OMG (раніш COD ASYL));
- стандарти "де-факто" (SQL, або мова діаграм SADT Д. Росса);
 - фірмові стандарти (Microsoft ODBS, IBM SNA).
За методичним джерелом:
- методичні матеріали фірм розробників ПЗ;
- методичні матеріали фірм консультантів;
- методичні матеріали наукових центрів;
- методичні матеріали консорціумів з стандартизації (наприклад, Oracle
Method, Price Waterhouse SMM, SEI CMM).
Вони можуть мати різну назву: метод, методологія, підхід, модель.
Основною особливістю усіх цих груп та підгруп є те, що до них входять
матеріали, які суттєво відрізняються за:
- ступенем обов'язковості для організацій різних типів;
- конкретністю та деталізацією вимог, які вони містять;
- відкритістю та гнучкістю, можливістю адаптування до конкретних умов.
Розглянемо найбільш поширені стандарти.

2. Oracle Method
2.1. Методика Oracle CDM (Custom Development Method)

Ця методика виникла в наслідок розвитку Oracle CASE - Method і

орієнтована на застосування продуктів Oracle і набору стандартів та керівництв по
використанню відповідних продуктів Designer/2000, Developer/2000 та інших
засобів. Методика підтримує три моделі ЖЦ:
1. "класичну" - передбачені всі роботи/задачі та етапи;
2. "прискорена розробка" (Fast Track) - ще більше зорієнтована на
використання інструментів моделювання та програмування Oracle (Designer/2000,
зокрема), призначена для порівняно невеликих та середніх проектів.
3. "полегшений підхід" - рекомендується у випадку малих проектів,
можливості швидкого прототипування додатків.
Усі моделі ЖЦ є по суті каскадними, навіть при використанні "полегшеного підходу",
який має зрозумілу ітеративність виконання дій, пов'язаних з прототипуванням, зберігає
загальну послідовність та встановлений порядок виконання задач. Включення додаткової
задачі/роботи та їх прив'язка до інших не передбачена, так само, як і зміна послідовності.
 Загальна класична структура ЖЦ формується з певних етапів (фаз) проекту
та процесів, які виконуються на протязі декількох етапів:
- "визначення вимог" (іноді називають етап стратегії);
- аналіз вимог (формулювання детальних вимог до системи);
- проектування (перетворення вимог в детальні специфікації системи);
- реалізація (написання та тестування додатків);
- впровадження (установка системи, підготовка до початку експлуатації);
- експлуатація (підтримка та спостереження за додатком, планування
майбутніх функціональних розширень).
Модель ЖЦ Fast Track передбачає поділ проекту у часі на три фази:
- аналіз вимог;
- проектування та створення системи;
- передача в експлуатацію/впровадження
Полегшена модель передбачає такий самий поділ проекту на три фази.
Основні процеси, що розглядаються в CDM:
1. аналіз вимог (RD);
2. аналіз існуючої системи (ES);
3. технічна архітектура системи (TA);
4. проектування і створення бази даних (БД) (DB);
5. проектування і створення модулів програмного забезпечення (ПЗ) (MD);
6. перетворення даних (CY);
7. документування (DO);
8. тестування (TE);
9. навчання (TR);
10. передача замовнику (інсталяція) (TS);
11. підтримка (PS).
Основні процеси CDM:
1. аналіз вимог (процес визначає бізнес- та системні вимоги до додатку);
2. аналіз існуючої системи (процес визначає і формулює існуюче технічне
середовище для визначення необхідних змін);
3. технічна архітектура системи (процес визначає елементи технічної бази
системи, що розроблюється);
 4. проектування і створення БД (процес забезпечує проектування і створення
реляційної бази даних, включаючи, наприклад, питання ефективної індексації і
безпеки (секретність) на рівні об'єктів БД);
5. проектування і створення модулів ПЗ (основний процес, включає
проектування додатків і створення програмного коду);
6. перетворення даних (цілі процесу - міграція, перетворення і тестування
всіх існуючих даних, які необхідні для роботи нової системи);
7. документування (процес забезпечує створення якісної текстової та on-line
документації для користувачів і адміністраторів, а так само технічних описів
проекту);
8. тестування (процес забезпечує спільне тестування якості всіх елементів
системи, як окремих модулів, так і результатів їх об'єднання);
9. навчання (процес забезпечує навчання і тестування користувачів і
адміністраторів);
10. передача замовнику (процес включає такі задачі, як розробка плану
інсталяції системи, підготовка технічного середовища, організацію процесу
"згортання" існуючої системи);
11. підтримка системи (цілі процесу - моніторинг і розв'язання проблем,
заміна версій з виправленими помилками, оцінка роботи системи і планування
поліпшень);
Графічно взаємозв'язок фаз та процесів можна представити наступним
малюнком:
Аналіз Проектува Передача в
вимог ння та експлуата
створення цію
системи
Аналіз вимог (RD) ---------------
-------
Аналіз існуючої системи (ES) ---------------
-------
Технічна архітектура системи (TA) --------------- ------
-------
Проектування і створення бази ---- -----------
даних (БД) (DB) -------
Проектування і створення модулів ---- -----------
ПЗ (MD) -------
Перетворення даних (CY) --------- --------------- ------
------- -------
Документування (DO) --------- ---------------
------- -------
Тестування (TE) --------- ------
------- -------
Навчання (TR) ---- --------------- ------
------- -------
Передача замовнику (інсталяція) - ---------------
---------------
(TS) ------- ------- -
Підтримка (PS) -----
------
Методика вважається фірмовим стандартом, тобто вона не є обов'язковою.
Прикладна система розглядається в основному як програмно-технічна
система. Тому організаційні задачі/роботи, пов'язані з переходом до нової системи
в ній відсутні.
Власне методика має чітку направленість на створення інформаційної системи з базами
даних в традиційному розумінні.

2.2. Методика Oracle PJM (Project Development Method)

Метод призначений для управління проектами в області інформаційних

технологій. Його мета - забезпечити структурну основу для планування, оцінки,
управління і контролювання проектів будь-яких типів. Цей метод тісно
інтегрований з методом Oracle CDM. Крім того, він в різній мірі враховує вимоги
інших відомих моделей: ISO 9000 Series - Quality Systems, PMI - Project
Management Body of Knowledge, ISO/IEC Standart 12207 - Software Life cycle
Processes, SEI - Capability Maturity Model.
Метод PJM, так само як і CDM, орієнтований на процеси.
Основні процеси, що розглядаються в PJM:
1. Контроль і Звіти (процес містить задачі, що допомагають визначити об'єм
робіт і методи проведення, управляти можливими змінами і контролювати ризик.
Цей же процес визначає управління планом проекту і звіти про хід проведення
проекту);
2. Управління Роботами (задачі цього проекту визначають і контролюють
стан всіх робіт, що виконуються по проекту. Крім цього, забезпечують
"фінансовий погляд" на проект);
3. Управління Ресурсами (процес забезпечує оптимальний підбір персоналу,
що бере участь в проекті, а також організує інфраструктуру для проведення
проекту);
4. Управління Якістю (процес повинен забезпечити "вимірювання якості" і
гарантувати задоволення не тільки вимог, але і очікувань замовника на протязі
всього проекту);
5. Управління конфігурацією (задачі процесу допомагають організувати
зберігання і управління всіма елементами, що створюють хід проекту).
Розділення проекту на фази забезпечує підвищення керованості і зниження
можливого ризику. Кінець кожної фази завершується оглядом і підписанням
основних результатів робіт і дає можливість підтвердити виконання вимог
замовника. Усі разом фази проекту складають цикл життя проекту (project life-
circle), і визначають КОЛИ процеси і задачі повинні бути виконані.
Етапи життєвого циклу:
1. планування проекту (задачі цієї категорії відносяться до предметної
області якості, часу і вартості проекту загалом. Тут так само визначається
організаційна структура і зони відповідальності учасників проекту);
2. планування фази (задачі цієї категорії доповнюють і деталізують плани
проекту для конкретної фази);
3. управління фазою (ці задачі виконуються паралельно з виконанням
робіт по проекту, здійснюють функції моніторинга і звітності на протязі фази);
4. завершення фази (ці задачі завершують проект і забезпечують
підписання всіх необхідних документів по цій фазі);
5. завершення проекту (врегулювання всіх спірних питань і забезпечення
успішного завершення проекту).
Планува Управління фазами Заверше
 ння Планува Управлі Заверше ння
проекту ння фази ння ння фази проекту
фазою
Контроль і звіти ------------ ------------ ------------ ----
------ ------ ------ ----
Правління ------------ ------- ------------
роботами - -- ------
Управління ------------ ------- ------------ ----
ресурсами ------ -- ------
Управління якістю ---- ---- ------------ ----
------
Управління ---- ---- ------------ ---- ----
конфігурацією ------

3. Міжнародний стандарт ISO/IEC 12207

Перша редакція ISO 12207 розроблена в 1995 р. об'єднаним технічним

комітетом ISO/IES ITC1 "Інформаційні технології, підкомітет SC7, програмування
програмного забезпечення".
Це базовий стандарт процесів ЖЦ ПЗ, орієнтований на будь-які види ПЗ та
типи проектів автоматизованих систем, куди входить ПЗ як частина стандарту і
визначає стратегію і загальний порядок створення та експлуатації ПЗ.
Він охоплює ЖЦ від концептуалазації ідеї до завершення ЖЦ. Згідно зі
стандартом:
Система - це об'єднання одного або більше процесів, апаратних засобів,
програмного забезпечення, обладнання і моделей з метою забезпечення
можливості задоволення певних потреб або цілей.
На відміну від Oracle CDM стандарт ISO 12207 в однаковій мірі
призначений для регулювання двосторонніх відносин між замовником (покупцем)
і розробником (постачальником). Він може застосовуватись і у випадку, коли
обидві сторони належать одній організації.
Стандарт визначає набір і послідовність процесів, дій і задач, що виникають
при замовленні, постачанні, розробці, функціонуванні та супроводі систем.
 У порівнянні з CDM процеси є більш крупними, узагальненими. Власне
один процес з ISO рівнозначний усім процесам CDM: придбання, поставка,
розробка і т.інш.
Описано 5 основних (базових) процесів:
1. Процес придбання (замовлення). Визначає дії підприємства-покупця,
яке купує систему, програмний продукт або сервіс програмного забезпечення.
2. Процес постачання. Визначає дії підприємства-постачальника, яке
поставляє покупцеві систему, програмний продукт або сервіс ПЗ.
3. Процес розробки. Визначає дії підприємства-розробника, яке формулює
принципи побудови програмного виробу і розробляє програмний продукт.
Процес функціонування. Визначає дії підприємства-оператора, яке
обслуговує систему (а не тільки ПЗ) в процесі функціонування в інтересах
користувачів.
4. На відміну від дій, які визначаються розробником в інструкціях по
експлуатації, процес визначає дії оператора по консультуванню користувачів,
формуванню зворотнього зв'язку та інші дії, які він планує сам і приймає на себе
відповідні зобов'язання.
- Процес супроводу. Визначає дії персоналу супроводу. Який забезпечує
супровід програмного продукту, що включає:
- управління модифікаціями;
- підтримку його поточного стану та функціональної придатності;
- інсталяцію та вилучення програмного виробу з обчислювальної системи.
Стандарт описує 8 допоміжних процесів, які підтримують інші процеси ЖЦ, є його частиною і
забезпечують відповідну якість проекту.

Допоміжні процеси:
1. вирішення проблем;
2. документування;
3. управління конфігурацією;
4. забезпечення якості;
Цей процес використовує результати наступних процесів групи
забезпечення якості:
5. процес верифікації;
 6. процес атестації;
7. перевірка відповідності спільної оцінки (об'єднаних оглядів);
8. процес аудиту (ревізії).
Описані 4 організаційні процеси:
- процес управління;
- процес створення інфраструктури (визначає дії по створенню
інфраструктури, яка підтримує процеси ЖЦ);
- процес удосконалення процесів ЖЦ;
- процес навчання.
Примітка: Мається на увазі не удосконалення ІС або ПЗ, а поліпшення
самих процесів придбання , розробки, гарантування якості і т.д., які реально
здійснюються в організації.

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

для адаптації стандартів до умов конкретного проекту. Будь-яких етапів, фаз,
стадій не передбачено. Це якраз і підвищує ступінь адаптивності.
В таблиці 1 наведена схема взаємозв'язку процесів.

Таблиця 1.Схема взаємозв'язку процесів

Рівень Процес
Учасники декомпозиції
Замовник контрактний процес замовлення
постачальник рівень процес поставки підтримують і інші
процеси, що
процеси

Оператор операційний процес функціонування

користувач рівень
Розробники інженерний Процес процес розробки
підтримки підтримки
Співробітники рівень підтримки
підтримки
Менеджер корпоративний організаційні процеси
рівень Менеджмент інфраструктура
Удоск навчання
оналення
 Слід зазначити, що кожний процес, дія чи задача ініціюється і виконується
іншим процесом за необхідністю, причому немає наперед визначеної
послідовності (безумовно, при збереженні логіки зв'язків між задачами) (тобто
один процес визиває інші або його частину).
Приклади:
1). Виконання процесу Придбання в частині, що стосується аналізу та
формулювання вимог до системи чи ПЗ може ініціювати виконання відповідних
задач процесу Розробки.
2). В процесі поставки постачальник повинен керувати субпідрядниками
згідно процесу Придбання і виконувати верифікацію та атестацію відповідних
процесів.
3). Процес Супроводження може вимагати розвитку системи і ПЗ, яке
виконується у процесі Розробки.
Такий підхід дозволяє реалізувати будь-яку модель ЖЦ.
Стандарт тільки визначає, що сторони-учасники несуть відповідальність за
вибір моделі ЖЦ для проекту ПЗ, за адаптацію процесів і задач стандарту до цієї
моделі, за вибір і застосування методів розробки ПЗ, за виконання дій і задач,
прийнятних для проекту.
Таким чином, ступінь адаптивності стандарту є максимальною. Сукупність
процесів і задач сконструйовано так, що є можливою їх адаптація у відповідності з
конкретним проектом. Власне, процес адаптації є процесом вилучення процесів,
видів діяльності і задач, що не використовуються в конкретному проекті.
Доповнення унікальних чи специфічних процесів, дій та задач повинно бути
зазначено в контракті між сторонами. Під контрактом розуміють не тільки
юридично оформлені угоди. Угода може бути визначена і єдиною стороною як
задача, поставлена самій собі.
Стандарт не містить конкретні методи дій, тим більше він не містить
заготовки рішень або документації. Він описує архітектуру процесів ЖЦ ПЗ, але
не конкретизує в деталях, як реалізувати чи виконати послуги і задачі, що входять
у процес, не призначений для регламентування імені, формату або точного змісту
документації, що отримують. Такі рішення приймають ті, що використовують
стандарт.
 Конкретна користь стандарту полягає в тому, що він містить набори задач,
характеристик якості, критеріїв оцінювання тощо, які дозволяють всебічно
охопити проектні ситуації.
Наприклад, при проведенні аналізу вимог до систем, передбачається, що:
1). розглядається область застосування систем для визначення вимог до неї;
2). специфікація вимог систем повинна описувати: функції та можливості
систем; бізнес; організаційні вимоги; вимоги користувача; безпеку; захищеність;
людські фактори; проектні обмеження; кваліфікаційні вимоги.
3). вимоги до кваліфікації повинні бути задокументованими. Вимоги
кваліфікації - набір критеріїв та умов (кваліфікаційні умови), яких слід
дотримуватись для того, щоб кваліфікувати програмний продукт як такий, що
відповідає його специфікаціям (задовольняє умовам) і готовий до використання у
визначеному (цільовому) оточуючому середовищі.
Далі передбачено 11 класів характеристик якості, які пізніше
використовуються при гарантуванні якості:
1. функціональні і інші можливі специфікації, включно, виконання, фізичні
характеристики та умови середовища експлуатації;
2. зовнішні зв'язки (інтерфейси);
3. вимоги кваліфікації;
4. специфікації надійності, включно специфікації, пов'язані з методами
функціонування і супроводу, взаємодії з зовнішнім середовищем та
вірогідністю травм персоналу;
5. специфікації захищеності, включно специфікації, пов'язані з
дотриманням точності інформації;
6. людські фактори специфікації з інженерної психології (ергономіки),
включно пов'язані з ручним управлінням, взаємодією людини та
обладнання, обмеженнями на персонал та дії, що потребують
концентрації людської уваги, які є чутливими до помилок людини та
навчання;
7. визначення даних та вимог бази даних;
8. вимоги до установки та прийомки ПП, що поставляється в місцях
функціонування та супроводу;
 9. документація користувача;
10. робота користувача і вимоги виконання;
11. вимоги сервісу користувача.
Гарантування якості на різних процесах виконується з різною передбаченою
ступінню організаційної незалежності діяльності з контролю але до обов'язкової
вимоги повного збільшення персоналу, що перевіряє від будь-якої прямої
відповідальності за об'єкти, які перевіряються.
Такий контроль передбачений з самих ранніх кроків розробки, починаючи з
аналізу системних вимог через перевірку їх на відповідність потребам споживача.
Стандарт містить мало описів про проектування БД, що можна вважати
виправданням, оскільки різні системи і різні прикладні комплекси ПЗ можуть не
тільки використовувати специфічні БД, а і не використовувати БД зовсім. В
таблиці 2 зображена порівняльна характеристика CDM та ISO 12207.
Таблиця 2 Порівняльна характеристика CDM та ISO 12207
ISO 12207 CDM Примітки
Основні процеси
Процес придбання немає
розробником (замовником)
Процес поставки немає В CDM є процес СV -
перетворення даних
Процес розробки. Визначає RD, ES, TA, DB, MD, В дужках показано процеси
дії підприємства- (DO), (TR), TS DO - документування та TR
розробника, яке розробляє - навчання, які відображені в
принципи побудови ПВ і інших процесах ISO 12207
ПП (в контексті створення
системи)
Процес експлуатації немає В організація-оператор
розробляє план і гарантує
відповідність плану
Процес супроводу PS ISO передбачає розвиток, як
елемент супроводу, що
викликає новий процес, в
CDM в такому трактуванні
повномасштабний розвиток
не передбачено
Допоміжні процеси
Процес документування DO - документування
Процес управління Немає
конфігурацією ПЗ
Процес забезпечення якості. TE - тестування, ISO використовує
А також процеси: Oracle PJM можливість застосувати інші
-верифікація міжнародні стандарти,
-атестація наприклад ISO 9000
-сумісна оцінка
аудит
Процес вирішення проблем Є в
Організаційні процеси
Процес управління Oracle PJM
Процес створення Oracle PJM
інфраструктури
Удосконалення процесів немає В ISO 12207 передбачено
ЖЦ зв'язок з ISO 9000
Процес навчання TR - навчання
Висновки:
1. Жоден з розглянутих стандартів не є повним, не описує усі види дій і
задач, що реально існують в конкретних проектах автоматизованих систем і ПЗ.
Так, CDM передбачає суттєво менше дій з гарантування якості, розвитку систем і
ПЗ, функціонуванню системи, визначенню вимог користувача та інш. Разом з тим,
CDM вводить принципово важливий в реальних проектах, пов'язаних зі зміною
поколінь автоматизованих систем, процес CV - "конвертування даних", якого
немає в ISO.
2. ISO має набір процесів, дій і задач, що охоплюють найбільш широкий
спектр можливих ситуацій за умови максимальної можливості до адаптації. В ISO
реалізовано принцип "немає однакових проектів". Він є прикладом добре
організованого (складеного) стандарту, що містить мінімальну кількість
обмежень. При цьому передбачається, що детальне визначення процесів, форм
документів тощо, доцільно винести в різні функціональні стандарти, відомчі
нормативні документи або фірмові методики, які можуть бути використані або ні
в конкретному проекті.
З цієї причини, основним стандартом для побудови профілю ЖЦ
конкретного проекту, доцільно розглядати ISO 12207. Це дозволить побудувати
модель ЖЦ ПЗ і АС, принципову схему гарантування якості, модель управління
проектом.
Інші стандарти і матеріали доцільно включати в профіль ЖЦ тільки в
частині, яка визначає конкретні способи аналізу або програмування, форми
проектних документів та інструменти проектування, що застосовуються в
кожному конкретному процесі чи задачі, узгоджує модель життєвого циклу з
вимогами відповідних стандартів на АС і її компоненти, крім ПЗ.
3. Використання ISO 12207:
а). фіксує необхідність організаційного відокремлення дій, пов'язаних з
"виготовленням" ПЗ і АС від деяких видів робіт, пов'язаних з гарантуванням
якості (незалежні верифікація та атестація. Аудит та експертиза ходу проекту та
його результатів);
 б). фактично визначає конкретну відповідальність керівників організації і
проектів за встановлення відповідної професійної культури, технології і вимог до
якості розробок, або ж за відмову від цілеспрямованої діяльності з вирішення цих
проблем. Наприклад, відмова від регулярної поточної верифікації чи атестації,
тобто від гарантування якості;
в). слід зазначити, що побудова профілів ЖЦ проекту на основі ISO 12207
зазначеним чином може зробити проектні роботи більш дорогими. Вартість
виросте також через проведення дій з гарантування якості. На перший погляд - це
непотрібні ускладнення і ризики в проектуванні АС, яке і без того відносить до
діяльності з підвищеним ризиком. Однак, і замовником і розробником доцільно
врахувати наступне:
- Розробник отримує методику і нормативну базу для повного і зрозумілого
замовнику опису всіх своїх робіт з тестування ПЗ і АС, організації паралельної
роботи нової і старої систем, інших робіт, пов'язаних з "впровадженням".
Розробник може з більшим успіхом уникнути загрозливих для бюджету проекту
ситуацій. Коли він вимушений безкоштовно виконувати ці "об'ємні" роботи,
оскільки замовник не приймає роботи і не платить гроші. Розробник може
створити більш якісний продукт і укріпити свій авторитет на ринку.
- Замовник отримує методику і нормативну базу для гарантування якості
того продукту, який він замовив за свої чи кошти державного бюджету. Замовник
зможе обгрунтувати свої витрати перед фінансовими чи перевіряючими органами
(наприклад, радою директорів/зборами акціонерів), уникнути ситуації, коли через
деякий час (рік чи два) доводиться знову замовляти гроші на заміну невдалої
системи чи програмного комплексу, або залишитись з непридатним продуктом.
Лекція 3А (тема 3) УЧАСНИКИ ПРОЕКТУ

План
1. Склад учасників проекту
2. Функції основних учасників проекту

1. Склад учасників проекту,

їх роль, розподіл їх функцій і відповідальності залежать від типу, виду,

масштабу і складності проекту, а також від фаз ЖЦ проекту. Жорстких
регламентів по складу учасників проекту не існує. Незмінними можна вважати
наступні функції по здійсненню проекту, а отже і такий склад основних учасників:
- проект повинен бути осмислений, “придуманий" і ініційований, значить у
нього повинен бути ініціатор;
- проект повинен мати головну зацікавлену особу (організацію), тобто
сторону, яка є майбутнім власником і користувачем результатами проекту і несе
за нього відповідальність. У нашій термінології замовник = власник + користувач;
- здійснення проекту вимагає залучення інвестицій, значить у нього повинні
бути інвестори;
- проект треба готувати і здійснювати, значить у нього повинні бути
виконавці;
- внаслідок реалізації більшості проектів повинне щось вироблятися або
надаватися послуги, значить у проекту повинні бути свої продавці, виробники і
споживачі;
- проектом треба управляти, значить у проекту повинні бути менеджери.
Проект може торкатися інтересів різних сторін: місцевої влади, населення,
окремих громадян і інших учасників.
З проектом пов'язані: ініціатор проекту, інвестори, керівник проекту,
команда проекту і функціональні групи, генеральний контрактор, субконтрактори,
проектувальники, генеральний підрядник і субпідрядники, постачальники,
ліцензори, консалтингові і інжинірингові послуги, органи влади, власник
земельної ділянки, виробник готової продукції, продавці продукції, покупці
кінцевої продукції, суспільні групи населення, конкуренти і інші зацікавлені
сторони.
Слайд!!!

2. Функції основних учасників проекту

Ініціатор: сторона, що є автором головної ідеї проекту, його попереднього

обгрунтування і пропозицій по здійсненню проекту. Ініціатором може бути
практично будь-хто з майбутніх учасників проекту, але зрештою ділова ініціатива
по здійсненню проекту повинна виходити від замовника.
Замовник: головна сторона, зацікавлена у здійсненні проекту і досягненні
його результату. Як правило, це майбутній власник і користувач результатів
проекту. Він визначає основні вимоги і масштаби проекту, забезпечує
фінансування проекту за рахунок своїх коштів або коштів інвесторів, що
залучаються до проекту. Він укладає контракти з основними виконавцями
проекту, несе відповідальність за цими контрактами, управляє персоналом
взаємодії між учасниками проекту, несе відповідальність за проект перед
суспільством і законом.
Інвестор: сторона, що вкладає інвестиції в проект. Мета інвестора -
максималізація прибутку на свої інвестиції. Якщо інвестор і замовник не одна
особа, то звичайно як інвестор виступають банки, інвестиційні фонди. Інвестори
вступають у контрактні відносини із замовником, здійснюють розрахунки з
іншими сторонами по мірі виконання проекту. Інвестори є повноправними
партнерами проекту і власниками проекту, поки їм не будуть виплачені всі кошти
за контрактом із замовником або кредитною угодою.
Керівник проекту (менеджер): юридична особа, якій замовник і інвестор
делегує повноваження з керівництва роботами по здійсненню проекту, а саме:
плануванню, контролю і координації робіт всіх учасників проекту. Склад функцій
і повноважень керівника проекту визначається контрактом із замовником. Однак,
перед керівником проекту і його командою звичайно ставиться задача
всеосяжного керівництва і координації робіт протягом ЖЦ проекту до досягнення
певної мети проекту і результатів при дотриманні встановлених термінів,
бюджету і якості.
Команда проекту: специфічна організаційна структура очолювана
керівником проекту і яка створюється на період здійснення проекту. Задача
команди проекту: здійснення функцій управління проектом до ефективного
досягнення цілей проекту. Склад і функції команди проекту залежать від
масштабів, складності і інших характеристик проекту. Як правило, основними
учасниками команди проекту є: менеджер проекту, інженер, адміністративний
керівник контракту, контролер, бухгалтер, керівник служби матеріально-
технічного забезпечення, керівник робіт з проектування, керівник будівництва,
координатор робіт з експлуатації, адміністративний помічник, керівник
інформаційної служби.
Контрактор (генеральний контрактор): сторона або учасник проекту, що
вступає у відносини з замовником і який бере на себе відповідальність за
виконання робіт за контрактом. Це може бути весь проект або його частина. Мета
контрактора - отримання максимально можливого прибутку. Функції
контрактора: укладання контракту із замовником (інвестором), відбір і укладання
договорів з субконтракторами, забезпечення координації їх робіт, прийняття і
оплата робіт співвиконавців. Контрактором може бути керівник проекту або інші
активні учасники проекту.
Субконтрактор: вступає у договірні відносини з контрактором або
субконтрактором більш високого рівня, несе відповідальність за виконання робіт і
послуг відповідно до контракту.
Проектувальник: юридична особа, що виконує за контрактом проектно-
дослідницькі роботи в рамках проекту. Вступає у договірні відносини з
генеральним контрактором або безпосередньо із замовником.
Генеральний підрядник: юридична особа, чия пропозиція прийнята
замовником (як правило, для будівельних проектів). Тому звичайно генеральним
підрядником є будівельна і проектно-будівельна організації. Генеральний
підрядник несе відповідальність за виконання робіт відповідно до контракту,
підбирає і укладає договори з субпідрядниками на виконання окремих робіт і
послуг.
Постачальники: субконтрактори, що здійснюють різні види постачання на
контрактній основі.
Ліцензори: організації, що видають ліцензії на право володіння земельними
ділянками, ведення торгів, виконання певних робіт і послуг, використання “ноу-
хау".
Органи влади: сторона, що висуває і підтримує екологічні, соціальні і інші
висуваються суспільством і державою сторони проекту і що задовольняє свої
інтереси шляхом отримання податку від учасників проекту.
Власник земельної ділянки: юридична або фізична особа, що є власником
землі, що бере участь у проекті.
Виробник кінцевої продукції: здійснює експлуатацію створених основних
фондів і виробляє кінцеву продукцію. Бере участь у всіх фазах проекту. У
багатьох випадках є замовником і інвестором. Головна мета – прибуток.
Споживачі кінцевої продукції: юридичні і фізичні особи, що є покупцями і
користувачами кінцевої продукції, що визначають вимоги до кінцевої продукції і
послуг, що формують попит на них. За рахунок коштів споживачів
відшкодовуються витрати на проект і формується прибуток всіх учасників
проекту.
Інші учасники проекту: конкуренти основних учасників проекту; суспільні
групи і населення, чиї економічні і неекономічні інтереси зачіпає здійснення
проекту; спонсори проекту; різні консалтингові, інжинірингові організації,
залучені до здійснення проекту і інші.
Для визначення повного складу учасників проекту, побудови його
функціональної і організаційної структур на стадії розробки концепції проекту
необхідно визначити:
- предметну область: цілі, задачі, роботи і основні результати, масштаби,
терміни, складність;
- відносини власності, залученої до здійснення проекту (що скільки коштує і
кому належить);
- основні ідеї реалізації проекту (як зробити);
- основні активні учасники проекту;
- основні пасивні учасники проекту (кого торкається проект);
- які мотивації учасників проекту (можливий прибуток, збитки, ризик і т.д.).
Приклад: Основні функції учасників інвестиційного проекту – на Слайді!!!
Лекція 3Б (тема 3). ЦІЛІ ПРОЕКТУ

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

Мета (ціль) проекту - доказовий результат і задані умови реалізації загальної

задачі проекту.
Необхідно розрізнювати цілі -"результати" (доказовий результат) і цілі -
"образ дій" (умови реалізації). Разом ці компоненти складають цілі проекту, які
виникають на основі потреб, необхідності, бажання, ідей тощо.
Знаходження мети проекту рівнозначно його визначенню і складає важливий
етап в його розробці.
Після знаходження цілі приступають до пошуку і оцінки альтернативних
способів її досягнення. При знаходженні мети не можна обмежуватися
формулюванням тільки абстрактно, а треба знайти точні цільові
характеристики/результати проекту і умови, що враховуються при реалізації
проекту (вимоги і обмежень).
Для кожного проекту може бути велика кількість взаємопов'язаних цілей, що
відображають його структуру і учасників. Цілі проекту, структура і організація
учасників може описуватися взаємопов'язаними ієрархічними структурами, в яких
можуть бути встановлені відносини між компонентами (цілі, частини, учасники
проекту etc.)
Таким чином, цілі проекту повинні мати чітке значення; результати, що
отримуються при досягненні цілей, повинні бути вимірні; задані обмеження і
вимоги - здійснимі, тобто цілі повинні знаходитися в області допустимих рішень
проекту. Звичайно вони обмежуються термінами, бюджетом, ресурсами, що
виділяються і необхідною якістю результатів.
Одного разу сформульовані цілі не повинні розглядатися як щось незмінне,
так як під впливом змін в оточенні / з прогресом проекту і отриманням проміжних
результатів цілі можуть змінюватися. Цілепокладання - безперервний динамічний
процес, де аналізується ситуація, що склалася і тенденції, а при необхідності
здійснюється коректування цілей.
 2. Процес визначення цілей проекту

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

1) ВИЗНАЧЕННЯ ПОКАЖЧИКІВ ЦІЛЕЙ можна розглядати як попереднє
дослідження, після якого по знайдених покажчиках може бути початий активний
пошук мети і її формулювання. Цей етап вимагає вивчення різних джерел, які
можуть містити шукану інформацію (вимоги до проекту, замовлення на проект,
оточення підприємства etc)
2) ВИЗНАЧЕННЯ МОЖЛИВИХ ЦІЛЕЙ ПРОЕКТУ - використовуються
індивідуальні/групові методи; суворих підходів до цього немає. При
індивідуальній роботі використовуються логічні/дискурсивні методи
(односторонній розгляд проекту), при груповій роботі - інтуїтивні (мозкового
штурму, запису ідей, загального блокнота etc)
3) ОПИС ЦІЛЕЙ ПРОЕКТУ - задокументована угода про цілі проекту. При їх
описі цілі проекту повинні знайти відображення в чіткій однозначній формі:
- результат проекту - описується як бажаний стан системи і залежить від типу
і виду проекту; доповнюється описом ефекту;
- терміни закінчення - описуються як часовий інтервал, в якому бажане
завершення проекту; звичайно це заява про намір, але може бути і що
зобов'язуючий часовий інтервал;
- витрати - в першому описі - це бюджетні рамки, іноді - чітка верхня межа;
- порядок зміни цілей - повинен бути визначений у зв'язку з можливістю
зміни цілей;
- ієрархія залежних цілей - може бути як доповнення; може вказуватися, до
якої мети перейти, якщо дана недосяжна
Ієрархія цілей:
1. Результати проекту
1.1. Опис предмета проекту
1.2. Опис економічного ефекту
2. Протікання проекту
2.1. Терміни
2.2. Кошти і витрати
 Опис цілей визначає суть проекту. Якщо були ризикові міркування, то в опис
проекту входить угода про результати, заява про наміри, терміни і бюджет, угода
про вирішення можливого конфлікту між результатами, термінами і витратами.
Готовий опис цілей проекту - основа для подальшої роботи над проектом.

Лекція 3B (тема 3) СТРУКТУРА ПРОЕКТУ

План

1. Поняття структури проекту

2. Методичні основи структуризації
3. Основні етапи структуризації проекту

1. Поняття структури проекту

Структура проекту (СП) - сукупність взаємопов'язаних елементів і процесів,

представлених з різною мірою деталізування. На основі СП будуються різні
структурні моделі, що використовуються в СП.
СП - це центральний елемент методології управління, являє собою струнку
ієрархічну декомпозицію.
До основних задач відносяться:
1) розбиття задач на блоки
2) розподіл відповідальності за різні елементи проекту, ув'язка робіт зі
структурою організації та роботами
3) точна оцінка необхідних витрат
4) створення єдиної бази для планування
5) ув'язка робіт по проектуванню систем, ведення бухгалтерських рахунків у
фірмі
6) перехід від загальних цілей до задач
 7) визначення комплексів робіт підрядів
Правила структуризації:
1) кожний рівень декомпозиції проекту повинен мати закінчений вигляд або
охоплювати всі компоненти даного рівня деталізування
2) сума характеристик елементів проекту на кожному рівні ієрархії повинні
бути рівні
3) нижній рівень декомпозиції проекту повинен містити елементи або модулі
на основі яких може бути ясно визначені всі дані, необхідні і достатні для
управління проектом
Прийнята структура проекту з виділеною ієрархією постійних елементів
утворить основу інформаційної мови проекту, на якій будуть спілкуватись всі
учасники проекту і буде вестись документація.

2. Методичні основи структуризації

Існують 2 основних методи:

1) "зверху-вниз" - низхідний підхід - визначаються загальне задачі, далі вони
деталізуються
2) "знизу-вгору" - висхідний - визначає приватні задачі та їх узагальнення по
рівнях
Для структуризації проекту використовується ряд спеціальних моделей:
1. дерево цілей - схеми цілей, підцілей по рівнях. Основне правило
розбиття - повнота: кожна мета верхнього рівня повинна бути представлена
повним набором підцілей. Слайд!!!
2. дерево рішень - схеми задач оптимізації багатокрокового процесу
реалізації проекту. Гілки дерева відображають події, які можуть мати місце, а
вузли (вершини)- точки, в яких виникає необхідність вибору.
3. дерево робіт (структура поділу робіт - СПР/WBS – Work Brekdown
Strukture) - включає дві ієрархічні схеми, які між собою пов'язані певним чином:
ієрархія виробів та ієрархія робіт. Нижній рівень ієрархії робіт відповідає
пакетам робіт, що необхідно при розробці мережевого графіка. Пакет робіт може
бути самостійною фінансовою одиницею і повинен мати окремий кошторис та
звіт про витрати. СПР - основа для розробки структурної схеми адміністративного
управління проекту. Слайд!!!
4. організаційна структура виконавців (ОСВ/OBS – Organisation
Brekdown Strukture) - в цій схемі керівник - нульовий рівень. На більш низьких
рівнях - відділи, необхідні для функціонального управління роботами. Ці рівні
іноді відповідають рівням СПР. Мета ОСВ - визначити виконавців,
відповідальних за виконання робіт.
5. матриця відповідальності - зв'язує пакети робіт з організаціями-
виконавцями. Складається на основі СПР і ОСВ.
6. сітьова модель - на основі СПР і ОСВ, дерева цілей і робіт складають
сітьовий графік вузлових подій. Доцільно складати, крім загального (повного),
сітьові графіки окремих пакетів робіт, які називаються сітьовими блоками або
підсітями. Це забезпечує можливість проведення ефективного контролю,
дозволяє більше уваги приділяти управлінню найбільш важливими (критичними)
підсітями, замість того, щоб постійно контролювати увесь сітьовий графік,
зекономить час.
7. структура споживання ресурсів - ієрархічно побудований граф, який
фіксує необхідні на кожному рівні ресурси. Використовується для аналізу засобів,
необхідних для досягнення цілей та підцілей проекту.
1-й рівень – фінансові ресурси

2-й рівень - матер-техн, трудові, фінансові

3-й рівень – буд.матер, машини, обладн.

4-й рівень - складовані, нескладовані

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

на кожному рівні.
 3. Основні етапи процесу структуризації проекту

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

* компоненти продукції проекту
* етапи життєвого циклу
* елементи організаційної структури
Таким чином, мистецтво розбиття проекту ( структуризації ) полягає в
умілому поєднанні трьох різних структур:
1) процесу;
2) продукту
3) організації в єдину структуру проекту.
Здійснити на практиці структуризацію не так легко, як здається на перший
погляд. Здійснення цього процесу є порівняно легшим стосовно “відчуваних”
(речовинних) проектів, що пов’язані з будівництвом, наприклад, а не з розробкою
програмного забезпечення (“інтелектуальних” проектів).
Послідовність дій по структуризації проекту може бути представлена у
вигляді схеми, на якій виділені 6 рівнів ( або етапів ) розбиття.

Етап
Номер роботи
0 1
1 2
2 3,4,5,6
3 7
4 8,9,10
5 11,12,13
Головна задача знайти матеріальні компоненти проекту. Це нагадує
розбиття книги на розділи, землі - на ділянки, комп’ютерних програм - на модулі.
1. Визначення цілей проекту .
Повинні бути повністю та чітко визначені:
- характер проекту;
- цілі та зміст проекту;
 - кінцеві продукти та їх характеристика.
Доцільно використовувати ієрархію цілей.
2. Рівень деталізації.
Необхідно обдумати (задати) різні рівні деталізації планів та кількість рівнів
та елементів в структурі розбиття проекту.
3. Структура процесу .
Повинна бути підготовлена схема життєвого циклу проекту.
4. Організаційна структура.
Схема організаційної структури має охоплювати усі групи та окремі особи,
які будуть працювати на проект, включаючи осіб з зовнішнього оточення,
зацікавлених в проекті.
5. Структура продукту
Це схема розбиття на підсистеми або ієрархія робіт.
6. План бухгалтерських рахунків в організації.
Система кодів, які використовуються при структуризації, має базуватися на
плані бухгалтерських рахунків в організації або на можливості його коректування.
7. Структура розбиття проекту
Вищезазначені пункти 3-6 об’єднуються в єдину структуру проекту.
8. Генеральний зведений план проекту
Може бути у подальшому деталізований в процесі пошуку критичного шляху.
В ході реалізації проекту зведений план може використовуватися для доповідей
вищому керівництву.
9. Матриця розподілу відповідальності
В результаті аналізу взаємовідносин між елементами структури проекту та
організацією (підприємством) будується матриця, де елементи структури проекту
стають рядками, а елементи схеми організації компанії - стовпчиками ( або
навпаки ). В елементах матриці рівень відповідальності тих чи інших дійових осіб
позначають за допомогою різних умовних позначень або кодів.
Таким чином, матриця “призначає” кожному пакету робіт конкретних
виконавців.
10. Робочий план бухгалтерських рахунків
 У разі необхідності потрібно опрацювати систему субрахунків, які
“стикуються” з планом рахунків. (управлінський облік)
11. Робочий сітьовий графік .
Реалізація перших 10 кроків дозволяє розробити деталізований графік, який
включає по кожній з робіт часові та ресурсні оцінки.
12. Система наряд-завдань.
Випливає з попередньої структури (п.7) та матриці (п.9). На цьому етапі
завдання мають бути абсолютно конкретними у часових ресурсах.
13. Система звітності та контролю. Розроблюються форми звітів та
повідомлень, продумується спосіб їх надання тощо.
Лекція 4A (тема 4) ЕЛЕМЕНТИ І ХАРАКТЕРИСТИКИ
ПРОЕКТІВ

План
1. Поняття додаткових елементів проектів
2. Основні характеристики проектів

1. Поняття додаткових елементів проектів

До числа додаткових елементів і характеристик, які відіграють важливу роль

при управлінні проектами, відносяться:
- початкові умови: ці елементи необхідна складова початкових даних для
розробки і вибору концепції проекту. Вони характеризують:
1.1. передісторію та існуючий стан системи;
1.2. існуючий стан навколишньої системи (передбачуваного проекту);
1.3. вимоги до результатів проекту і способам їх досягнення (наприклад,
до надійності);
1.4. обмеження на цілі і результати проекту, що визначають кількісні
характеристики і допустимі межі обсягів робіт, якості, витрат і прибутків,
термінів, тривалості, споживаних ресурсів, ризиків і т.д.
 - область допустимих рішень проекту: це велика кількість рішень по
реалізації проекту, що задовольняють заданим обмеженням проекту.
- вибір і оцінка альтернатив проекту: передбачає знаходження кращого
варіанта проекту з усієї множини допустимих рішень.
- документація проекту: це сукупність взаємопов'язаних документів, що
стосуються проекту і управління проектом. Система документації функціонує
протягом усього життєвого циклу проекту, і відображає всю інформацію,
пов'язану з підготовкою, розробкою, реалізацією і завершенням проекту і
забезпечує нормальну комунікацію всіх членів команди і інших учасників
проекту. Система документації проекту створюється з метою ефективного
керівництва проектом, уніфікації і фіксацій необхідної інформації, своєчасного і
оперативного забезпечення учасників проекту необхідною і достатньою для їх
потреб документованою для їх потреб інформацією, стандартизація складу і
формату показників, створення інформаційної бази для аналітичної роботи,
фіксація і накопичення дослідних даних для майбутніх проектів, фіксація
контролю виконання рішень і зобов'язань, мінімізація можливих конфліктів і
непорозумінь, швидке включення в курс справи нових членів команди і
керівництва. У цей час загальноприйнятих стандартів для системи проектної
документації немає.
- види забезпечення проектів: до основних видів забезпечення відносяться:
інформаційне, програмне, технічне, організаційне, методичне, правове,
математичне і інш.
- методи і техніка управління проектами: сукупність формальних, логічних,
організаційних методів і технічних прийомів управління проектами, які зачіпають
обширні області знань і дисципліни з вироблення і прийняття рішень.
Основні методи і технічні прийоми що використовуються в управлінні
проектами в порядку розвитку основних фаз життєвого циклу:
- розробка концепції проекту: використовуються методи визначення цілей
проекту, методи опису і аналізу цілей, методи маркетингу, соціологічні методи,
експертні системи, методи концептуального проектування (формалізований опис
предметної області, початкових умов і обмежень, вибір критеріїв, пошук рішень,
вибір альтернатив), методи передпроектного аналізу.
 - розробка проекту: використовуються методи структурної декомпозиції,
методи побудови композиційних структурних моделей, методи моделювання
процесів здійснення проектів, імітаційне моделювання, методи календарного
планування (часовий, вартісний, ресурсний аналіз, планування ресурсів і витрат),
методи функціонально-вартісного аналізу, урахування ризику, надійності, методи
управління якістю, методи проектного аналізу на стадіях розробки.
- реалізація проекту: методи оперативного планування робіт, ресурсів і
вартості, методи маркетингу, а саме облік, контроль, аналіз ходу робіт і динаміки
показників, актуалізація планів, прогноз розвитку проекту і регулювання методів
контролю витрат, методи управління запасами, методи управління змінами,
методи проектного аналізу на стадії реалізації проекту.
- завершення проекту: методи аналізу ефективності проекту, методи розробки
виконавчих графіків і аналізу даних про запланований і фактичний хід проекту.

2. Основні характеристики проектів.

До важливих техніко-економічних показників результатів проекту

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

Лекція 4Б (тема 4) УПРАВЛІННЯ ПРОЦЕССОМ ВИКОНАННЯ

ПРОЕКТУ

План
1. Чим управляє проект?
2. Процесний підхід до виділення функцій в управлінні проектами

1. Декомпозиція функцій в управлінні проектами

Концепція управління проектом може розглядатися в різних аспектах.
Найбільш поширеними є:
•функціональний;
•динамічний;
 •предметний;
•процесний.
Функціональний - найбільш універсальний, передбачає розгляд основних
функцій управлінської діяльності: аналіз, планування, організація, контроль.
Динамічний - дозволяє визначити конкретний зміст функцій на кожному
етапі здійснення проекту; передбачає розгляд у часі всіх процесів, пов'язаних з
основною діяльністю по виконанню проекту. Цей процес пов'язаний з логікою
розвитку робіт і визначає так зване спеціальне управління реалізації проекту, яке
включає аналіз проблеми, розробку концепції проекту, базове і детальне
проектування, будівельно-монтажні і пусково-налагоджувальні роботи,
експлуатацію і демонтаж.
Предметний підхід визначає об'єкти проекту, на які направлене управління.
Крім названих аспектів в управлінні проектами з метою декомпозиції
функцій використовується такий аспект, як рівень діяльності. Виділяються два
види такого розділення: організаційний рівень і масштаби діяльності по
управлінню.
Організаційний рівень: проект загалом; міжфірмові утворення; організації-
учасники; окремі колективи розробників.
Масштабність діяльності: політика; стратегія; тактика; функції; процедури;
операції.
Процесний підхід до виділення функцій в управлінні проектами наведено на
рис.
 Методологія управління проектами (УП)

Процеси 1 УП Процеси орієнтовані на продукт

(залежать від життєвого циклу продукту)

1. 2. 3. 4. 5. 6.
Ініціація Планування Виконання і Аналіз Регулювання Завершення
контроль (визначення і
застосування корегуючих
Авторизація впливів)
(рішення про Регулювання є коли є
перехід до відхилення. Якщо відхилень
наступної фази) немає, то регулювання
полягає у доведенні планів і
колнтролі їх реалізації. Ці
процеси включаються у
виконання

4.
Аналіз виконання
6.
Аналіз плану (чи Основні процеси:
відповідає він 1 – аналіз термінів Закриття
вимогам учасників). 2 – аналіз вартості контрактів
Зазвичай аналіз 3 – аналіз якості
плану не виділяють 4 – підтвердження цілей
як окремий процес, Адміністративне
а включають в завершення
процес планування, Допоміжні процеси:
що робить його 1 – аналіз виконання
ітеративним (аналіз результатів і
розподіл інформації між 5. Основні процеси:
учасниками про хід 1 – загальне управління змінами
проекта) 2 – управління ресурсами
2 – аналіз ресурсів 3 – управління цілями
4 – управління якістю

3. Допоміжні процеси: Допоміжні процеси:

(сам процес виконання плану)

1 – облік виконання 1 – управління ризиками

2 – підтвердження якості (регулярна 2 – управління контрактами
Основні процеси:

оцінка виконання проекту на (координація)

відповідність стандартам)
3 – підготовка пропозицій
4 – вибір постачальників і укладання
контрактів
5 – контроль контрактів
6 – розвиток команди проекту
(підвищення кваліфікації)

2. Основні процеси: Допоміжні процеси:

1. планування цілей; 1) планування якості;
2. декомпозиція цілей; 2) планування організації (документування, звітність,
3. визначення складу операцій; призначеня ролей, відповідальність,
4. визначення взаємозв’язку операцій; взаємовідповідальність);
5. оцінка тривалості або обсягів робіт; 3) призначення персоналу;
6. визначення ресурсів; 4) плануваня взаємодіїї;
7. призначення ресурсів; 5) ідентифікація ризику;
8. оцінка вартості; 6) оцінка ризику;
9. складання розкладу виконання робіт; 7) розробка реагування (розробка дій для попередження
ризиків і реакції на загрозливі події);
10. оцінка бюджету (Σ вартості окремих етапів, фаз);
8) планування постачання;
11. розробка плану;
9) підготовка умов для постачаня.
12. визначення критеріїв успіху.

1
Процеси – дії та процедури, пов’язані з реалізацією функцій управління
 2. Чим управляє проект?

Досягнення цілей здійснюється через функції управління. Реалізація кожної

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

Базові функції
• управління предметною областю проекта (змістовна суть) - цілі, задачі,
обсяги робіт і необхідні ресурси;
• управління якістю (вимоги до результатів, стандарти) - якість
організаційних і технічних рішень, матеріалів і обладнання, виконаних робіт,
проміжних і кінцевого результату;
• управлінням часом (бюджет часу) - розробка і контроль графіка,
тривалості етапів і робіт;
• управління вартістю (фінансовий і матеріальний бюджет) - розробка
детального кошторису витрат і фінансового бюджету проекта.
Інтегруючі функції
•управління персоналом проекта (підбір, підготовка, організація роботи) -
визначення потреби в персоналі по стадіях проекта; пошук, прийом і звільнення
працівників; підготовка і підвищення кваліфікації; організація роботи персоналу;
•управління комунікаціями (моніторинг і прогнозування ходу робіт і
результату) - пошук, збір, обробка, передача інформації, проектування
інформаційних зв’язків, своєчасність і достатність інформації;
•управління контрактами (контрактація виконавців, матеріалів тощо) -
маркетинг, реклама, контрольні пропозиції, організація тендерів, укладання
контрактів і контроль за їх реалізацією;
•управління ризиком (зниження рівня невизначеності в проекті) -
прогнозування негативних явищ, їх оцінка, можливість вживання своєчасних
заходів, що попереджають і не допускаючих настання негативних явищ.
 Виділення вказаних функцій обумовлюється такими критеріями оцінки:
•технічна здійсненність, що визначається предметною областю і якістю;
•конкурентоздатність, що визначається якістю, часом і вартістю;
•трудомісткість, що визначається часом і вартістю;
•життєздатність;
•ефективність здійснення проекту, що визначається персоналом, що бере
участь, засобами комунікації, системою матеріально-технічного забезпечення.
Управління проектом передбачає комплексність в реалізації функцій
управління.
Для цього необхідно розглянути:

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

комплексність реалізації кожної функції по видах діяльності, стиковку
часток функції при їх реалізації різними виконавцями і трудомісткість
виконання функцій з урахуванням рівнонапруженості праці;

процедури реалізації кожної функції з метою спрощення і
вдосконалення технології їх виконання.
Зміст функцій управління проектом
Будь-яка функція управління складається з п'яти видів управлінської
діяльності, що мають відносну самостійність: планування, організація,
координація, активізація, контроль. Кожний попередній вид діяльності є
необхідною передумовою подальшого. Ці п'ять видів слідують один за іншим,
поки дана функція не буде повністю реалізована. Отже, міра повноти реалізації
функції управління залежить від комплексності управлінської діяльності.
Розглянемо види управлінських дій, що складають кожну функцію.
Перший вид планування, тобто визначення оптимального результату при
заданих обмеженнях за часом і ресурсами. У будь-якому управлінському рішенні,
розпорядженні завжди є відповіді на питання: хто повинен зробити? що? скільки і
коли?
 На питання, як зробити, дає відповідь другий вид управлінської діяльності
організація, тобто визначення шляхів, методів і засобів досягнення поставленої
мети.
Третій вид координація, або гармонізація, тобто встановлення гармонії в
спільній праці учасників процеса, що планується.
Четвертий вид активізація, або мотивація, тобто створення таких
стимулюючих умов праці, за яких кожний працівник трудився б з найвищою
віддачею.
П'ятий вид управлінської діяльності контроль, тобто прогнозування
відхилень для їх своєчасного попередження.
В управлінні проектом найголовнішим є прогнозування ходу виконання
проекту і не допущення відхилень. Головне це профілактика! Треба бути
розумним «до того», а не після. Це і є справжній контроль.

Лекція 4B (тема 4) ОРГАНІЗАЦІЯ РОБІТ ПО ПРОЕКТУ

План

1. Організаційні форми реалізації проекту

2. Типи організаційних структур груп для УП.
3. Поняття організаційно-динамічної структури управління проектом
4. Функції провідних спеціалістів робочої групи УП
5. Формування і розвиток команди проекту

ОРГАНІЗАЦІЙНІ ФОРМИ РЕАЛІЗАЦІЇ ПРОЕКТУ

Організація робіт по проекту передбачає по-перше, вибір організаційної

форми реалізації проекту, по-друге, - створення організаційної структури УП.
Організаційна форма - це організація взаємодії та взаємовідносин між всіма учасниками
проекту. Організаційна структура УП - сукупність взаємопов"язаних органів управління, що
знаходяться на різних ступенях (рівнях) системи.
Організаційна форма реалізації проекту залежить: від того хто є менеджером
проекту та від прийнятого розподілу етапів і конкретних робочих процедур між
учасниками проекту.
 Існуючі організаційні форми досить різноманітні оскільки вони залежать від
конкретних параметрів проекту: термінів, обсягу, цілей та ін. параметрів,
наприклад, розробка робочої документації з залученням субпідрядників з окремих
частин проекту чи ні. В літературі існує, хоча досить умовна , класифікація
організаційних форм УП: Основна система, Система розширеного управління,
Система прискореного будівництва.
У відповідності з “основною системою” менеджер проекту є представником
(агентом)замовника і не несе фінансової відповідальності за рішення, що
приймаються. Повноваження менеджера проекту обмежуються умовами,
передбаченими контрактом з замовником.
Менеджером проекту (агентом замовника) може бути співробітник практично
будь-якої фірми - учасниці проекту (замовника, включно)або консультативної
фірми. Обов"язки між учасниками проекту в цьому випадку розподіляються
наступним чином:
Замовник: визначає масштаби проекту, укладає контракти з менеджером
проекту та іншими учасниками та несе відповідальність по цим контрактам, керує
процесом взаємодії між усіма учасниками проекту.
Менеджер проекту:
•відповідає за координацію та управління всім ходом розробки та реалізації
проекту (аналіз концептуальних та проектних рішень, будівельно-технічної
документації, власне управління будівництвом, включно),
•працює за контрактом з замовником. З іншими учасниками відносини на
умовах інших контрактів недопустимі.
Інші учасники проекту (архітектор, інженер, постачальники, підрядчики та
ін.) виконують традиційні для них функції.
Переваги цієї організаційної форми: зняття фінансової відповідальності з
менеджера проекту, що забезпечує об"єктивність рішень, що приймаються.
Недоліки: ризик за долю проекту повністю лягає на замовника. Крім того
немає впевненості в стабільності “граничних” витрат по проекту , тому він
вимушений повністю покладатись на компетентність менеджера проекту.
Організаційні форми УП, які передбачають встановлення фіксованої ціни
отримали назву “системи розширеного управління проектами”.
 Загальна схема розподілу відповідальності між учасниками проекту є
приблизно такою. Замовник - відповідає за визначення масштабів та параметрів
проекту, укладає контракт з менеджером проекту, який повинен забезпечити
спорудження об"єкта, у більшості випадків, “під ключ”.
Багато хто з фахівців розглядають такі організаційні форми як своєрідні
“спільні підприємства” до складу яких входять всі учасники проекту за
виключенням замовника.
Менеджер проекту забезпечує управління та координацію процесів
проектування та будівництва у відповідності з угодою між учасниками проекту у
межах фіксованої (кошторисної) ціни. Ним може бути представник підрядної
організації або консалтингової фірми (іноді інжинірингові), який управляє
проектом, координує поставки та роботи по інжинірингу. Ризик покладається на
підрядчика..
Система прискореного будівництва передбачає, що проектування та
будівництво здійснюється однією проектно-будівельною фірмою, з якою замовник
укладає контракт “під ключ” з заздалегідь визначеною ціною проекту. Ця
модифікація найбільш ефективна у тих випадках, коли замовник чітко уявляє
основні характеристики проекту, його параметри, масштаби, вимоги до окремих
його частин тощо.
В таблиці наведено декілька варіантів розподілу функцій між учасниками при
різних організаційних формах реалізації проекту:
Виконавці Види Діяльності
Поставки Проектування Управління
Варіант 1
Замовник (З) +
Підрядчик (ПД) +
Постачальник (ПС)
Проектувальник (ПР) +
Консультант (К)
Варіант 2
З + +
ПД +
ПС
ПР
К
Варіант 3
З
ПД + +
ПС
ПР +
К
Варіант 4
З
ПД +
ПС
ПР +
К +
Варіант 5
З + +
ПД
ПС
ПР
К +
Варіант 6
З
ПД
ПС +
ПР +
К +
Варіант 7
З
ПД + + +
ПС
ПР
К
Варіант 8
З
ПД + +
ПС +
ПР
К
1. Основна система - варіант 1.
2. Система розширеного управління - варіанти 2-6.
3. Система прискореного будівництва - варіанти 7,8.
 ТИПИ ОРГАНІЗАЦІЙНИХ СТРУКТУР ГРУП ДЛЯ УП

Концепція “управління проектами ” передбачає створення для УП спеціальної

групи, яка стає самостійним учасником проекту або входить до складу одного з
учасників та здійснює управління процесом реалізації проекту. Ця група
створюється на період реалізації проекту і після його завершення розпускається.
На практиці застосовуються два основних принципи формування груп для
управління проектами:
1. Провідні учасники проекту - замовник і підрядчик (крім них можуть бути і
інші учасники), створюють свої власні групи, які очолюють менеджери проекту,
власне від замовника та підрядчика. Ці менеджери підпорядковуються єдиному
менеджеру проекту, яким може бути один з них, в залежності від організаційної
форми реалізації проекту.
Для управління проектом створюється єдина група на чолі з менеджером
проекту. В групу входять повноважні представники всіх учасників проекту.
Всередині кожної фірми-учасниці може створюватись своя група контролю за
ходом проекту.
Логіку взаємодії учасників проекту всередині такої групи відображає її
організаційна структура. Основні типи оргструктур для груп по УП:
•проектна структура,
•матрична структура,
•використовується також комбінація цих двох типів,
•проект здійснюється у межах функціональної структури фірм учасниць.
У випадку проектної структури персонал робочої групи виділяється для
участі в проекті на повний робочий день. Всі працівники підпорядковані
безпосередньо менеджеру проекту.
Принцип робочої групи найбільш прийнятний, коли масштаби проекту і
тривалість його виконання такі, що персонал може бути зайнятим у проекті на
протязі усього робочого дня і коли, в ідеальному варіанті він може
розташовуватись в одному місці.
В цілому робоча група проекту - це підрозділ, створений для того, щоб
розподіляти робочі завдання у відповідності з вказівками менеджера проекту, а
також технічними умовами та процедурами проекту.
Принцип робочої групи не обов"язково гарантує найбільш ефективну
діяльність по УП. Однак, зазвичай він робить проект більш економічним, оскільки
забезпечується найкраще співвідношення між строками, витратами та обсягами
робіт, а також якість їх виконання.
При матричній організації менеджер проекту, деякі провідні керівники і
частина персоналу групи призначаються для роботи протягом всього робочого
дня, а інший персонал направляється в міру необхідності. Зазвичай цей персонал
працює одночасно більш ніж над одним проектом.
Матрична структура - це система з відкритими зв"язками і подвійною
відповідальністю виконавців будь-якого рівня. Кожний фахівець має дві лінії
відповідальності:
1. - за якісне виконання своїх функцій в цілому в масштабі всієї фірми,
зазвичай, на протязі року;
2. - за поточне виконання певної функції у межах проекту.
На практиці на протязі багатьох років матрична організація
використовувалась як найкращий спосіб роботи над проектом, особливо в
будівельних фірмах. Зараз проектна структура вважається найефективнішою і
тому популярною.
Переваги і недоліки проектної і матричної структур управління
Основні фактори Матрична структура Проектна структура
Вимоги до системи Необхідна наявність Так як команда працює в
планування і звітності стратегічного матричного одному місці, система
плану планування і звітності
може бути достатньо
простою
Контроль за виконанням Контроль здійснюється Під контролем
проекту через керівників знаходяться всі члени
функціональних групи.
підрозділів Керівнику проекта і
замовнику лечше
 контролювати всі
питання, пов”язані з
проектом.
Ефективність Використання часу з Неминуча наявність
використання робочого точки зору розподілу резервного часу
часу роботи, дуже ефективно
Внесення змін в проект Неминуче виникнення Процес внесення змін
труднощів при внесенні нескладний, так як всі
змін, так як залучено працюють в одному місці,
багато структурних активно взаємодіючи
підрозділів, що беруть один з одним
участь у проекті
Вимоги до керівника Повинен бути гарним Керівник проекту
координатором, повинен бути не тільки
агітатором і вміти технічно грамотним
впливати на учасників спеціалістом, але і гарним
проекту керівником
Роль неформальних Велика Має місце, але не в такій
зв”язків мірі, як при матричній
організації
Вплив на існуючу Вплив мінімальний Вимагає реорганізації
структуру існуючої структури
Якість виконуваних робіт Максимально жорсткий Менш жорсткий контроль
контроль якості
Службове просування обмежені можливості забезпечує можливість
персоналу службового просування дисциплінованим
працівникам стати
керівниками
Слайд: “Переваги та недоліки”
На практиці можна зустріти підхід, коли група для УП не створюється, а
управління проектом здійснюється у межах функціональної структури управління
фірм-учасників.
Однак у цьому випадку виникає проблема міжфункціональної координації,
вирішення якої можливо лише на самому високому рівні управління. Але
керівники цього рівня через велике навантаження не завжди можуть здійснити
таку координацію. Тому при використанні цього типу оргструктури, зазвичай,
призначається один або декілька координаторів, для забезпечення зв"язків між
функціональними підрозділами. Ці координатори можуть бути підпорядкованими
керівникам різних рівнів і координують роботи по одному або кільком проектам,
співпрацюючи з лінійними керівниками.
Недолік : Зусилля координатора не завжди досягають мети через
недостатність його прямої участі у вирішенні поточних задач, що виникають при
виконанні проекту. Цей тип структури використовується, зазвичай, в тих
організаціях, де:
1.- стабільний режим роботи,
2.- відносно малий вплив зовнішнього середовища,
3.- незмінна спеціалізація виробництва,
4.- рівномірний темп розвитку організації.
З порушенням будь-якої з цих умов, наприклад, зі зміною спеціалізації (п.3),
різким збільшенням обсягів робіт (п.4), при переході на нову технологію
виробництва, така структура є малоефективною.
Для того, щоб вибрати тип оргструктури для заданих умов конкретного
проекту можна скористатись критеріями, що наведені в табл.
Критерії для прийняття рішень по організаційній структурі
Критерії оцінки Функціональна Матрична Проектна
Непевність умов низька висока висока
реалізації проекту
Технологія стандартна складна нова
проекту
Складність низька середня висока
проекту
Тривалість коротка середня велика
проектного циклу
Розмір проекту малий середній крупний
Важливість не дуже важливий середньої дуже важивий
проекту важливості
Взаємозалежність і низька середня висока
взаємозв”язок між
окремими
частинами проекту
Критичність часу низька середня висока
(зобов”язання
організації по
строкам
завершення робіт)
Взаємозв”язок і висока середня низька
взаємозалежність
проекту від систем
більш високого
рівня

(Дати слайд).

Організаційна структура проекту допомагає керівникові розподілити між

виконавцями права та обов"язки по окремих роботах або їх частинах.
Оргструктура розробляється для кожної фази ЖЦП на основі узагальненої
(базової) оргструктури і за допомогою практичних рекомендацій. (Дати слайд з
базовою оргструктурою рис.8 та інші варіанти базової структури).
Приклад оргструктури для проекту ПО ІС (слайд).
Приклади оргструктури для проекту ПО ІС на різних фазах ЖЦП (слайди рис
7.2 - проектування, 7.3.а - планування та аналізу, 7.3.б - програмування, 7.3.в -
комплексування та випробування, 7.3.д - супровід).
Узагальнена (базова) оргструктура може бути адаптована для конкретної
розробки через об‘єднання суміжних робіт.
Рекомендації по адаптації оргструктури:
1.Об‘єднати суміжні види діяльності в оргструктурі (див. Рис 7.1).
2.Об‘єднати сусідні роботи з кількістю виконавців менше двох, якщо
•вони не пов"язані з керівництвом декількох підпорядкованих робіт;
•для виконання робіт необхідно менше ніж 0,5 виконавця і є відсутньою
перспектива зростання зайнятості на наступній фазі.
3.Якщо для будь-якого виду діяльності необхідно більше семи виконавців, то
слід розподілити її на роботу, пов"язану з керівництвом і декілька
підпорядкованих робіт.
4.Коло обов"язків будь-якого керівника слід обмежувати керівництвом не
більше ніж сімома роботами.
Слід керуватись логікою “здорового глузду” при побудові оргструктури,
якщо будь-яка з рекомендацій їй не відповідає у конкретних умовах.
Управління та організація відносяться до сфери практичної діяльності людей,
а не до вправ з абстрактної логіки. Тому слід враховувати причини суто
 суб"єктивні. Наприклад, те, чому віддає перевагу замовник або виконавець,
недоліки розробників, конфліктні ситуації та інше, що може спричинити
відхилення від рекомендацій.

ПОНЯТТЯ ОРГАНІЗАЦІЙНО-ДИНАМІЧНОЇ СТРУКТУРИ

УПРАВЛІННЯ ПРОЕКТОМ

Аналіз ефективності реалізації кожної функції дозволяє також більш чітко визначати
обов'язки і права працівників апарату управління і на цій основі проектувати більш раціональну
систему менеджменту.
Функції є основою змісту управління проектом і структури системи
управління. Склад і чисельність апарату управління загалом, так само як склад і
чисельність підрозділів, що до нього входять, визначаються функціями управління
і операціями, що їх складають.
Діяльність команди управління проектом направлена на те, щоб об'єднати в
єдиному потоку управлінського праці всі відносно відособлені, хоч і нерозривно
пов'язані управлінські функції і досягнути результату проекту, що планується.
Динамізм - це постійні зміни. Не зважаючи на все різномаїття типів і видів
проектів, їх структура управління за своїм змістом в основному однорідна, бо в
ній представлена та або інша комбінація одних і тих самих видів робіт по
управлінню. Ця обставина забезпечує єдиний підхід до проектування структур
управління. При цьому забезпечуються одноманітність у проектуванні різних
служб, раціональний розподіл прав і обов'язків, рівна напруженість праці
учасників управлінського процесу.
Але оскільки проект у своєму розвитку має різні фази, стадії та етапи
життєвого циклу, то абсолютно очевидно, що і обсяг управлінських робіт
безперервно змінюється. Звідси відбувається постійна зміна кількості елементів в
організаційній структурі управління проектом, їх взаємозв'язків, ієрархії і
чисельність персонала. Тому дуже важливо на передпроектній стадії визначити
динамізм організаційної структури, це дозволить своєчасно підготувати «вхід» і
«вихід» необхідного персоналу проекту. Особливо важливою властивістю
динамічних організаційних структур є їх гомеостатичність, тобто здатність
виробляти автоматичні реакції по підтримці внутрішньої рівноваги. Така здатність
структури у часовому аспекті є похідною від стабільності і довговічності.
Структури, що змінюють свою конструкцію на різних етапах здійснення
проекту, називаються організаційно-динамічними.
Ці поняття застосовно до структури управління означають передусім
забезпечення можливості її безперервного вдосконалення в умовах динамічного
розвитку проекту. Звідси необхідність постійного вдосконалення структури
управління є чинником її стабільності і довговічності. У свою чергу, стабільність
є похідною від таких понять, як стійкість і надійність. Чим менше в системі
виникає відхилень через різноманітні впливи, тим вона стійкіша. Чим менша
ймовірність відмов керуючої системи, тим вона надійніша.
Проектування організаційно-динамічних структур спирається на наступні
принципи:

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

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

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

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

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

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

соціально-психологічні (соціальна структура і відносини в команді
проекту, характеристика психологічного клімату і інш.);

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

Всі організаційні структури управління проектом можна розділити на три види:

централізовані, координаційні, матричні.
У централізованих структурах як об'єкт управління виступають проекти, повністю
орієнтовані на досягнення однієї мети. Вони передбачають повну відповідальність
за виконання програм лінійного керівника, створюються на часовій основі і
застосовуються, як правило, при виконанні складних, і довготривалих проектів,
що дорого коштують (наприклад, будівництво особливо важливих об'єктів).
Програмно-цільові структури координаційного типу
характеризуються введенням в структуру управління
додаткових координаційних органів, які погоджують
міжфункціональні взаємодії по горизонталі на основі
інформаційно-регулюючої діяльності, спільного
прийняття рішень по проекту і контролю за його
виконанням. Такі органи діють від імені одного з
керівників організації, але безпосередніми правами
розпорядження не наділяються.
Матричні структури засновані на використанні особливого механізму
взаємодії лінійно-функціональних і програмно-цільових підсистем апарату
управління. Головна особливість структур матричного типу складається в
обов'язковому виділенні особи (або органу), наділеної всією повнотою
відповідальності за досягнення мети проекту, якій вищим керівником організації
делегуються відповідні права. Крім того, окремі керівники нижчого рівня в
системі програмно-цільового управління призначаються відповідальними
виконавцями.
Матрична структура упорядковує і різко скорочує
довжину горизонтальних зв'язків в процесі управління,
зводить до мінімуму негативні наслідки багаторівневого
лінійного підкорення, прискорює прийняття рішень і
сприяє підвищенню відповідальності за їх зміст і
результати.
Оскільки формування програмно-цільових структур не
пов'язане зі створенням нових підрозділів, вони є
високодинамічними, легко перебудовуються без
негативних наслідків, не ускладнюють, а навіть
полегшують роботу з кадрами.
Для здійснення безперервного процесу формування динамічної структури управління
проектом в команді проекту повинна бути виділена група проектувальників, яка завчасно буде
здійснювати весь комплекс робіт по зміні діючої організаційної структури і персоналу в
залежності від стадій проекту і інших чинників.

4. ФУНКЦІЇ ПРОВІДНИХ СПЕЦІАЛІСТІВ РОБОЧОЇ ГРУПИ УП

Організаційна структура робочої групи (команди проекту) відповідає

конкретним етапам проекту і складає ядро для розширення організації робіт з
основних видів діяльності над реалізацією проекту.
Оргструктура робочої групи допомагає керівникові розподіляти між
виконавцями права та обов"язки з окремих робіт або їх частин.
Робоча група складається з таких підгруп:
1. підрозділи, що створюються за відповідними напрямками основної
діяльності (проектування, закупівля (постачання), будівництво, тощо) (їх
називають виробничими підрозділами);
2. персонал контролю та координації проекту;
 3. обслуговуючий персонал фірми у межах якої виконується проект (персонал
бухгалтерії, фінансового відділу тощо).
У процесі вибору та призначення персоналу проекту необхідно враховувати
такі чинники як наявність необхідних фахівців, їх кваліфікацію, досвід та особисті
якості, здатність працювати у складі групи і забезпечувати досягнення поставленої
мети.
Якщо організації-учасники проекту створюють свої групи по УП, всі вони,
зазвичай мають подібну оргструктуру. Кожна робоча група формується у
відповідності з потребами проекту, з урахуванням кваліфікації та досвіду
персоналу, що працює над проектом.
Величина робочої групи залежить від масштабів і типу проекту
В робочу групу проекту можуть входити:
1. - менеджер проекту;
2. - інженер-координатор проекту;
3. - менеджер служби матеріально-технічного забезпечення проекту
4. - менеджер будівництва;
5. - менеджер служби контролю ;
6. - координатор робіт з проектування;
7. - координатор проекту з використання засобів автоматизації
управління проектом (менеджер ІС);
8. - адміністративний керівник контрактів;
9. - адміністративний менеджер.
Обов"язки провідних фахівців:
Менеджер проекту - провідний член групи, він:
•делегує повноваження членам групи,
•слідкує за виконанням плана, оцінює стан робіт,координує та коригує їх
виконання,
•використовує персонал контролю проекту для планування обсягів і термінів
робіт, отримання оцінок і контролю затрат,
•відповідає за всю роботу над проектом.
У випадку малих проектів він є також координатором проекту або керує
декількома проектами одночасно.
 У випадку більших проектів йому допомагає координатор робіт по проекту.
Інженер-координатор проекту - відповідає за координацію робіт по проекту
на усіх його стадіях, включаючи проектування, закупівлю обладнання та
матеріалів, будівництво та введення об"єктів в експлуатацію.
•Його основні обов"язки:
•визначає обсяги робіт і терміни їх виконання, встановлює взаємозв"язки між
елементами проекту, забезпечує планування,
•контролює виконання бюджету проекту (особливо витрати на робочу силу
та матеріали),
•забезпечує необхідну якість робіт, у тому числі слідкує за тим, щоб різні
напрямки проектування та інженерного забезпечення відповідали б нормативам та
обмеженням проекту, контролює виконання робіт у відповідності з вимогами
самого проекту та замовника щодо економічних показників, ТУ та
держ.стандартів,
відповідає за комунікації (зв"язок) між усіма учасниками проекту.
Інженер-координатор проекту не відповідає за технічні рішення, що закладені
в проектній документації. Це є обов"язком головного і провідних інженерів за
напрямками робіт, які направлені в робочу групу проекту.
Менеджер служби МТЗ проекту відповідає за своєчасну доставку
обладнання і матеріалів.
Менеджер будівництва (іноді його називають менеджером на місці ведення
будівельно-монтажних робіт) відповідає за всі види робіт, які виконуються на
будівельному майданчику. Іноді вважається, що це основна управлінська посада
при роботі над проектом.
Менеджер будівництва має власний персонал, який вирішує питання
трудових відносин між адміністрацією та профсоюзом, техніки безпеки,
встановлення зв"язків з організаціями та окремими особами, а також свою власну
виробничу підгрупу, яка займається інженерним забезпеченням робіт, веденням
господарських справ та ін.
Менеджер служби контролю працює у тісному контакті з менеджером
проекту. Основними сферами його діяльності є:
•планування та встановлення термінів,
 •оцінка витрат і планування вартості,
•контроль витрат і тенденцій їх зміни,
•інформування менеджера проекту та зацікавлені служби про хід робіт,
•управління матеріально-технічними запасами,
•контроль документації та ін.
Менеджеру служби контролю підпорядковуються кошторисники, плановики,
фахівець з матеріально-технічного забезпечення, фахівець з ведення документації
проекту та представники служби засобів автоматизації УП. В залежності від
обсягу (масштабу) проекту цей допоміжний персонал може працювати цілий день
або ні, або мати також допоміжний персонал.
Координатор робіт з проектування відповідає за виконання робіт з
інженерного проектування у межах проекту. Ця посада є тільки в крупних
проектах, де йому підпорядковуються головні (провідні) інженери з окремих
напрямків. У невеликих проектах координація інженерного проектування
здійснюється інженерами-координаторами проекту (див.2).
Основні види діяльності, які здійснює координатор робіт з проектування:
•визначення обсягів робіт,
•встановлення зв"язків з проектування,
•календарне планування та поточний контроль за ходом проектних робіт,
•збирання даних та аналіз результатів проектування.
Координатор проекту з використання засобів автоматизації
управління проектом (менеджер ІС).
В його обов"язки входить підбір, адаптація та використання програмних
засобів (спеціальних пакетів) управління проектами (Project management). Він несе
відповідальність за машинну обробку інформації в процесі УП. У разі
необхідності розробляє нові ПЗ.
Адміністративний керівник контрактів
Адміністративний керівник контрактів контролює виконання контрактів
включаючи питання, пов"язані з поставками матеріалів та обладнання, наданням
послуг, прийомом виконаних робіт, оплатою контрактів та їх закриттям. На
протязі всього ЖЦП він контактує з контракторами. Слідкує за зміною умов
контрактів, виникненням суперечок та скарг, контролює відповідність матеріалів
та обладнання специфікаціям та стандартам. Контролює виконання гарантій,
передбачених контрактом та визначає чи перекривають вони витрати по усуненню
виявлених дефектів. Складає план закриття контрактів. Узгоджує з замовником
перелік недоліків та відхилень які слід усунути, слідкує за їх ліквідацією.
Адміністративний менеджер (помічник менеджера проекту) координує
допоміжну діяльність:
•конторські послуги (надання оргтехніки, меблів, приміщень, копіювальної
техніки, надання загальних конторських послуг, бібліотечне обслуговування,
тощо);
•фінансові послуги - бухгалтерський облік, укладання контрактів,
страхування, внутрішні ревізії, тощо;
•забезпечення зайнятості персоналу, призначення ставок зарплати,
організація виробничого навчання і т.ін.

4. ФОРМУВАННЯ І РОЗВИТОК КОМАНДИ ПРОЕКТУ

Як зазначалось раніше, для управління будь-яким проектом на період його

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

Ціль проекту

Система управління

Команда проекту

Культура проекту

Реалізація проекту тривале підприємство, що має підвищену частку ризику і

схильне до постійних змін. Тому особливою характеристикою команди проекту є
підприємницький характер її діяльності, направлений на рішення
слабоструктурованих задач і швидке реагування на вимоги зовнішнього
середовища і умови реалізації проекту, що змінюються.
 Принципи і стадії розвитку команди проекту
Командна кооперація персоналу дозволяє збільшити продуктивність
управлінської праці на 70-80%
Процес формування команди проекту (командоутворення) звичайно
розглядають як утворення єдиного, цілісного колективу управлінців, здатного
ефективно досягати мети проекту.
Значення командної роботи по реалізації проекту укладається в можливості
синергічного ефекту від об'єднання групових зусиль, знань і вироблення групових
управлінських рішень, тобто в досягненні «стану, при якому ціле більше, ніж сума
його складових частин». Така кооперація в роботі персоналу значно ефективніша,
ніж конкуренція. Процес управління командою проекту представлений на мал. 1.
Склад команди проекту. Команда проекту створюється керівником проекту
юридичною особою, якій замовник делегує права по управлінню проектом в
обсязі, визначеному контрактом.
Задачею керівника проекту при формуванні команди є підбір членів
команди, які забезпечували б:
• відповідність кількісного і якісного складу команди цілям і вимогам
проекту;
• ефективну групову роботу по управлінню проектом;
• психологічну сумісність членів команди і створення активної
стимулюючої «внутрішньопроектної» культури;
• розгорнене внутрішньогруповое спілкування і вироблення
оптимальних групових розв'язань проблем, що виникають під час реалізації
проекту.
 МАЛ. 1. Алгоритм управління командою проекту
Керівник проекту призначає проект-менеджера, що здійснює загальне керівництво
проектом, контролює його основні параметри і координує діяльність членів команди.
Менеджер проекту визначає необхідну кількість фахівців членів команди, їх кваліфікацію,
проводить відбір і найм працівників.
Для здійснення допоміжних функцій, забезпечення процесів управління і
роботи команди створюється секретаріат, очолюваний адміністративним
помічником.
У команді проекту виділяються члени, що залучаються, і що беруть участь в розробці і
реалізації проекту на різних стадіях його життєвого циклу.
«Кістяк» команди складають постійні члени: головний інженер, головний
бухгалтер, керівник по проектуванню, керівник контрактів, керівник будівництва
тощо, що очолюють функціональні відділи команди і відповідають за прийняття
рішень по управлінню проектом в межах своєї компетенції.
У основі групової консолідації лежать три природні потреби людини: в
приєднанні до групи йому подібних; у визнанні його особистості, його талантів і
заслуг, в причетності до якоїсь спільної справи, до загальних результатів.
 Команда проекту має усі якості і характеристики, властиві соціальній групі.
Як формальна група вона займає певне місце в структурі організації, має
закріплені функції і обов'язки, користується формальними каналами інформації.
Як неформальна група вона досить стійка до криз і конфліктів, користується
різними неформальними зв'язками та інформаційними каналами.
Стадії життєвого циклу команди. Аналогічно життєвому циклу проекту
команда проекту має свій життєвий цикл, в якому можна виділити п'ять основних
стадій: формування, спрацьовуваність, функціонування, реорганізація,
розформування. Характеристика різних стадій життя команди проекту наведена в
табл.

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

№ Найменування
п/ стадії Особливості управління командою
п
1. Формування Особливості роботи в проекті полягають в тому, що
фахівці команди не знають один одного, ніколи не
працювали разом, не є єдиним колективом з
встановленими механізмами взаємодії, груповими
установками. Для їх ефективної спільної діяльності
необхідний певний період, коли вони визначають
відносини, пристосовуються до умов роботи в команді,
усвідомлюють себе єдиним цілим.
На цій стадії відбувається знайомство членів команди
один з одним і з проектом загалом, формуються загальні
цілі і цінності, визначаються норми і правила взаємодії,
ставляться задачі команди і визначаються шляхи і
принципи їх досягнення.
2. Спрацьовуваннн Це період початку спільної роботи, розвитку
я згуртованості групи, що вирішує колективну задачу. Він
(психологічної характеризується підвищеним рівнем конфліктності,
напруженості) викликаним відмінністю в характерах фахівців, підходах,
стилях і методах розв'язання проблем. Всередині команди
йде процес виявлення лідерів, формування неформальних
груп, визначаються ролі окремих працівників і їх місце в
команді, встановлюється психологічний клімат в
колективі, його внутрішня культура, що визначає стиль
роботи і управління, образ взаємодії членів команди.
№ Найменування
п/ стадії Особливості управління командою
п
3. Робоча Найбільш тривала стадія. На основі сформованого
(нормального командного почуття йде нормальний продуктивний
функціонування) процес роботи. Деталі взаємодії уточнюються по ходу
виконання задач, спілкування в різних ділових ситуаціях.
Стадія характеризується максимальним розкриттям
індивідуальних творчих здібностей, члени команди
вчаться розуміти і враховувати потреби і інтереси один
одного. Конфлікти і спори в основному виникають по
причинах, пов'язаних з проектною діяльністю, і носять
конструктивний характер.
Задачею менеджера проекту на цій стадії є раціональний
розподіл функцій між фахівцями і відділами;
забезпечення відповідності особистих можливостей і
здібностей структурі і змісту робіт, що виконуються;
з'єднання в робочих групах і функціональних підрозділах
працівників з різними доповнюючими один одну
індивідуальними здібностями, знаннями і навичками;
підтримка в команді атмосфери довір'я і взаємовиручки,
єдності в розумінні цілей і задач проекту і способів їх
досягнення; визначення і дозвіл конфліктних ситуацій;
створення дійової системи мотивації; контроль за
досягненням проміжних результатів проекту і
координування діяльності всіх функціональних відділів;
розвиток персоналу і створення зовнішнього і
внутрішнього сприятливого іміджу команди проекту.
4. Реорганізація Стадія виникає при змінах в кількісному і якісному
складах команди у випадках, викликаних: змінами в
проекті (задачах, планах, результатах проекту); змінами
структури управління проектом; завершенням окремих
стадій проекту; зміною об'ємів і видів робіт, учасників
проекту; заміною працівників через професійну
невідповідність; додатковим залученням нових фахівців;
запрошенням тимчасових експертів.
На стадії реорганізації задача менеджера проекту полягає
в організації адаптації нових членів команди до стилі і
методів взаємовідносин в команді, в становленні їх
професійної ролі, визначенні функцій, обов'язків, прав і
відповідальності при управлінні проектом. Якщо
№ Найменування
п/ стадії Особливості управління командою
п
відбувається істотне оновлення команди, не виключене
«експрес-проходження» всіх попередніх стадій розвитку
команди наново.
5. Розформування При завершенні окремих стадій і всього проекту
розформовуються окремі підрозділи і вся команда
проекту.
При цьому в залежності від прийнятої оргструктуры
виникають два варіанти подальших дій фахівців команди.
При матричній структурі управління працівники по
закінченні проекту повертаються в свої функціональні
підрозділи організації, тому не переживають почуття
неспокою і невпевненості, необхідності в пошуку роботи.
У разі ефективної діяльності команди по реалізації
проекту при виникненні нових проектів ці працівники
складають «ядро» нової команди.
При проектній структурі управління менеджер проекту
стикається з проблемою подальшого працевлаштування
працівників, які не мають можливості повернутися на
колишнє місце роботи. У цьому випадку, якщо очікується
замовлення на новий проект, при успіху діяльності
команди менеджер має можливість запросити частину
фахівців в команду нового проекту. При цьому члени
команди підвищують продуктивність, доводячи свою
компетентність і професіоналізм.
У випадку, якщо нового замовлення не передбачається,
може спостерігатися зниження інтересу до роботи,
падіння продуктивності, байдужість, заклопотаність
пошуками нових місць роботи. Керівнику команди
рекомендується виявляти увагу до подальшого
працевлаштування фахівців в професійній сфері, надавати
об'єктивні рекомендації членам команди проекту з
вказівкою їх кваліфікації, знань, навичок і досвіду роботи.
Визначення функціональних обов'язків учасників команди проекту

Формування, організація і управління командою проекту, а також функції її членів

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

5.Управління розвитком і діяльністю команди. Формування команди

проекту.

Команда проекту як соціальна група володіє певними характеристиками.

При формуванні і організації роботи команди менеджер повинен
враховувати ці характеристики.
Команда проекту характеризується передусім достатньою мірою
згуртованості високою мірою тяжіння один до одного
Небезпечним наслідком згуртованості є групова однодумність - тенденція придушення
думок, що не узгоджуються з груповими. Задачею менеджера в цьому випадку є підтримка
здорової конкуренції, творчої активності, стимулювання обміну думками і виявлення нових
ідей. Альтернативою однодумності виступає підвищена конфліктність в команді, яка веде до
неконструктивних дій і задоволення особистих амбіцій за рахунок інтересів проекту.
 У процесі реалізації проекту визначаються ролі членів команди, встановлюється їх
статус, виявляються неформальні лідери, що забезпечують досягнення цілей команди.
При підборі команди, визначенні груп, які працюють над окремими
задачами, потрібно враховувати чинник психологічної сумісності, що
забезпечується єдністю ціннісних орієнтації персоналу.
Величезну роль грає робочий клімат всередині команди, який визначається
сукупністю поведінкових установок членів команди і передусім лідерів.
Виділяють чотири основні полярні орієнтації в залежності від мотиваційних
установок персоналу владу, свободу (незалежність), гроші і мета (робота).
При відборі команди проекту крім професійних вимог необхідно
враховувати наступні якості:
• уміння працювати в групі;
• самостійність, заповзятливість;
• бажання брати відповідальність за рішення, що приймаються;
• уміння ухвалювати ризиковані рішення, працювати в умовах
невизначеності;
• комунікабельність, стрессоустойчивость;
• низький рівень конфліктності;
• відповідність ціннісних установок цілям і цінностям проекту.
Хто займається відбором? У залежності від прийнятої системи управління
функціональних менеджерів керівників підрозділів команди відбирає менеджер
проекту. У разі матричної структури управління рішення по відбору і найму
функціональних менеджерів приймається спільно з безпосереднім керівником
Відповідного відділу. Фахівців в підрозділи команди відбирає менеджер функціонального
підрозділу. Участь менеджера проекту і менеджера підрозділу при відборі персоналу
відображена в табл.
Таблиця Участь менеджерів в процесі відбору

Захід щодо відбору Проект-менеджер Менеджер підрозділу

 Захід щодо відбору Проект-менеджер Менеджер підрозділу
Вибір критеріїв Здійснює вибір критеріїв Здійснює вибір критеріїв для
відбору для відбору менеджерів відбору фахівців
Затвердження Затверджує їх
критеріїв
Відбірна бесіда Проводить бесіду з Проводить бесіду з фахівцями
менеджерами
Аналіз заяв і анкет Аналізує заяви і анкети Аналізує заяви і анкети
менеджерів фахівців
Бесіда про прийняття Розмовляє з менеджерами, Розмовляє з фахівцями
з фахівцями спільно
Тестування Тестує менеджерів Тестує фахівців
Перевірка Перевіряє рекомендації Перевіряє рекомендації
рекомендацій менеджерів фахівців

Прийняття рішення Ухвалює рішення Дає рекомендації про прийом

про найм фахівців
Критеріями відбору звичайно виступають освіта, досвід роботи, медичні
характеристики і особисті якості. Треба зазначити, що фахівців з утворенням в
області управління проектами в цей час дуже трохи і мова може йти або про
досвід участі в проектух, або про додаткове утворення в сфері проекту-
менеджменту.
Для виконання багатьох видів робіт по проекту потрібні певні фізичні якості, які
повинні бути підтверджені відповідними медичними документами. Важливе
значення для спрацьованості команди, для ефективної роботи в проекті мають
особисті характеристики працівника вік, сімейний стан, індивідуальні
психологічні характеристики (характер, темперамент, здібності, схильності,
потреби і інтереси) і пр. Для роботи в проекті переважний переважно молодий вік
персоналу від 25 до 45 років, який характеризується високою мірою активності,
високою здатністю до навчання і здібністю до інноваційного типу мислення,
шануй компенсує відсутність спеціального утворення і досвіду роботи.
Одним з способів відбору є тестування претендентів. Для достовірності
отриманих даних бажано провести порівняння результатів різних методів відбору,
наприклад тестів і бесід.
Планування роботи команди. Планування діяльності команди повинно
починатися ще на стадії предінвестиційних досліджень, на етапі визначення
можливого керівника проекту. Після визначення структури команди і обрання
менеджера проекту його задачею є ретельне планування роботи всіх
функціональних підрозділів команди для ефективного використання і розподілу
ресурсів, виділеного на проект.
Першим етапом цієї роботи є кадрове планування визначення необхідного
кількісного і якісного складу команди і персоналу проекту. Подальший процес
вимагає активної участі всіх членів команди в складанні планів роботи. Основою
складання плана роботи команди є план розробки і реалізації проекту.
Організація роботи команди. Організація роботи команди проекту відрізняється
від організаційних норм формалізованої організації.
Одним з принципів командної роботи виступає розподіл обов'язків і
відповідальності за досягнення поставлених цілей, а не жорстке закріплення
функцій, що виконуються. Принцип передбачає відхід від детального розподілу
праці в управлінні проектом і діяльність окремих підрозділів команди шляхом
введення командної відповідальності за рішення конкретних задач. Фахівці з
реорганізації бізнесу М. Хаммер і Дж. Чампи підкреслюють гнучкість такої
системи управління, її здатність швидко перебудовуватися у відповідь на зміни в
проекті.
Цей принцип дозволяє досить суворо планувати діяльність команди проекту і її
окремих підрозділів, контролювати і оцінювати діяльність її членів, використати
дійову систему стимулювання по критерію мети/результату.
Функціональні підрозділи команди спочатку являють собою групи рівних по
статусу працівників з одним офіційним лідером у розділі, націлені на рішення
конкретних задач по управлінню проектом.
У умовах максимізації поставлених задач дуже скоро виявляється нерівномірність
професійного і особистістого зростання членів команди, з'являються потенційні лідери.
Командний успіх і досягнення цілей проекту починають залежати від особистих досягнень,
ініціативи і відповідальності. Таким чином, основним організаційним ресурсом стає особисте
лідирування.
Сильними мотиваторами стають командна відповідальність за результати
проекту і прагнення до особистого лідерства і успіху. Кожний член команди
розуміє, що його високий особистий рейтинг в команді стає заставою його
подальшої успішної професійної кар'єри в проекті-менеджменті, підвищує
імовірність його участі в інших проектах.
Для ефективної організації роботи команди необхідні:
• чіткий розподіл ролей і обов'язків;
• усвідомлення всіма членами команди цілей і поточних задач проекту;
• облік і особистісних, і професійних якостей фахівців при об'єднанні їх
в команду;
• увага менеджерів і до досягнення цілей проекту, і до встановлення
дружньої робочої атмосфери.
Відповідальність за роботу завжди лежить на менеджерові команди проекту. Іншу
частину роботи можна і треба уміти делегувати. Уміння делегувати повноваження, тим
самим розвиваючи здібності персоналу, стає основною якістю ефективного менеджера
проекту.
Поширені помилки, що перешкоджають делегуванню повноважень

1. Швидше зробити самому!

2. Ні у кого немає відповідних навичок і здібностей!
3. Інші можуть зробити не так, як треба.
4. Інші можуть зробити краще.
5. Немає часу на інструктаж.
 6. У інших людей і так повно справ.
7. Люди можуть подумати, що ви їх перевантажуєте.
8. Це можна самому в неробочий час.
9. Це знижує контроль.
Перевагами делегування повноважень є:
 делегування дозволить вам зосередитися на тих аспектах роботи, які
вимагають вашого особистого досвіду, знань і кваліфікації;
 основна частина роботи будь-якого менеджера повинна бути направлена на
рішення стратегічних, а не поточних проблем;
 головною задачею менеджера проекту виступає керівництво персоналом;
 делегування кращий спосіб мотивації творчого персоналу;
 делегування спосіб навчання працівників;
 це перспективний шлях кар'єри персоналу проекту!
Спираючись на всесвітньо відомі ознаки ефективних компаній, описані в 1983 г. Т.
Пітерсом і Р. Уотерменом, застосовно до проекту можна дати вісім рекомендацій по
організації діяльності персоналу проекту.
 Орієнтація на дії. Головним принципом існування команди стає
дієвість.
 Особою до споживачів. Команда віддана ідеї проекту, інтересам
споживачів кінцевого продукта проекту.
 Стимулювання самостійності і заповзятливості. Заохочення творчого
підходу і виправданого ризику в досягненні цілей проекту.
 Продуктивність від людини. Команда зрілий колектив, самостійні і
відповідальні люди.
 Зв'язок з життям, ціннісне керівництво. У проекті створюється
стимулююча культура, ціннісні установки персоналу підтримуються вищим
менеджментом.
  Вірність своїй справі. Персонал високо професійний і орієнтується на
кар'єру в області проекту-менеджменту.
 Простота форми, скромний штат управління. Вищий рівень
управління проектом небагаточисельний, структура гнучка і адаптивна.
 Свобода і жорсткість. Принципи реалізації проекту поєднання
централізації і децентралізації: делегування повноважень і відповідальності;
ефективне лідерство і взаємодія.
Контроль і координація діяльності команди. Зміни, неминучі в будь-
якому проекті, ведуть до зміни задач команди проекту, коректування її діяльності.
Контроль за виконанням поставлених цілей і координація діяльності окремих
функціональних підрозділів виступають найважливішими функціями менеджера
проекту. Функція контролю в команді проекту делегується вниз на рівень
окремого члена команди і приймає межі самоконтроля в зв'язку з високим рівнем
свідомості, дисципліни і професійної відповідальності. Відповідальність за
виявлені відхилення в роботі команди і здійсненні проекту, своєчасне їх усунення
залишається на рівні функціонального керівника і менеджера проекту.
Оцінка діяльності команди проекту. Діагностична оцінка необхідна для
визначення рівня командного почуття і ефективності команди загалом.
Оцінка діяльності команди проекту повинна проводиться передусім за
досягнутими результатами проекту. Періодично оцінюючи рівень досягнення
поставлених цілей, менеджер проекту повинен коректувати діяльність команди,
вносити необхідні зміни в її роботу, визначаючи коло поточних і перспективних
проблем, самооцінку команди проекту можна здійснювати за допомогою тесту.
Тест 1. Діагностична оцінка ефективності команди
Члени команди проставляють бал від 1 до 7, відповідний їх оцінці кожного з наступних
чинників по нижченаведений шкалі.
1. Прояснення задач і розуміння цілей: чи є мети проекту і наміру проекту-
менеджера зрозумілими команді і прийнятими нею?
 2. Ясність ролей: чи знають члени команди, що чекають від них інші? Чи
Згодний кожний з очікуваннями інших?
3. Чи є відповідність між вашими обов'язками і тим, що чекають від вас інші
члени команди?
4. Чи є відповідність між поставленими перед вами задачами і вашими
повноваженнями?
5. Вирішення конфліктів в команді.
6. Яка якість прийняття рішень у вашій команді?
7. Оцінка участі і впливи учасників на вироблення рішень.
8. Лідерство.
9. Взаємна підтримка в групі.
10. Групові стандарти: яка якість роботи групи вважається достатньою (якість
прийнятих стандартів)?
11. Яким, на думку команди, повинна бути взаємодія з клієнтами?
12. Аналогія: порівняйте функціонування вашої команди з роботою єдиного
механізму.
Шкала:

1 2 3 4 5 6 7
Гірші оцінки Кращі оцінки
У залежності від суті чинників гірші оцінки мають значення: слабе, немає,
неефективне, незадовільне, незначне і т.п.; кращі оцінки відповідно: сильне, так, ефективне,
задовільне функціонування тощо.
Підсумовуйте на одному листі пофакторні оцінки, проставлені кожним
учасником. Сума покаже, наскільки згуртовано працює команда.
Лекція 5A (тема 5) ПЛАНУВАННЯ В УП

План
1. Необхідність та особливості планування в УП
2. Принципи планування в проекті
 3. Процеси планування
4. Цілі, призначення та види планів
5. План реалізації проекту
6. Календарні плани

1. Необхідність та особливості планування в УП

Планування - це безперервний процес визначення найкращого способу дій
для досягнення поставлених цілей з урахуванням обстановки, що складається. В
управлінні проектом планування займає основне місце, втілюючи в собі
організаційні засади всього процесу реалізації проекту.
Планування є найбільш важливим процесом управління проектом, що
визначає у часі всю діяльність по його здійсненню.
Логічно планування пов'язане з іншими важливими процесами, такими,
як організація, координація, контроль, аналіз і регулювання.Сутність
планування полягає в обгрунтуванні цілей та способів їх задоволення на основі
виявлення детального комплексу робіт, визначення ефективних методів та
способів, ресурсів усіх видів, необхідних для їх виконання, встановлення взаємодії
між організаціями-учасниками проекту. Діяльність з розробки планів охоплює всі
етапи проектного циклу. Вона починається з участі проект-менеджера у розробці
концепції проекту, продовжується при виборі стратегічних рішень виконання
проекту та розробці його деталей, включаючи складання контрактних пропозицій,
укладання контрактів, виконання робіт, і закінчується при завершенні проекту. На
етапі планування визначаються всі необхідні параметри реалізації проекту -
тривалість (в цілому, окремих етапів та робіт), потреби у трудових, матеріально-
технічних та фінансових ресурсах, терміни поставки сировини, матеріалів,
комплектуючих і технологічного обладнання, терміни та обсяги залучення
проектних, будівельних та інших організацій. Прийняті рішення повинні
забезпечити можливість реалізації проекту у заданий термін з мінімальною
вартістю, витратами ресурсів та при високій якості виконання робіт.
План відіграє роль моделі дій і прогнозу стану проекту і його оточення. У
процесі життя проекту відбуваються зміни як всередині, так і поза ним. Тому
жоден спочатку складений план не може бути виконаний в точності.
Так навіщо ж треба планування проекту, якщо все змінюється? Справа в
тому, що в управлінні проектом головним є не виконання плану, а ефективне
досягнення мети проекту. Тому основне призначення планування полягає в
безперервній підтримці "курсу" розвитку проекту на шляху до його успішного
завершення.
 Що планується в проекті. У проекті необхідно планувати все те, що підлягає
обліку, контролю, аналізу і регулюванню. Це насамперед планування функцій
управління проектами:
1. управління предметною областю проекту;
2. управління вартістю;
3. управління часом;
4. управління якістю;
5. управління людськими ресурсами;
6. управління комунікаціями;
7. управління ризиками;
8. управління постачанням і контрактами.

2. Принципи планування в проекті

При всьому різномаїтті проектів існують загальні підходи і принципи
планування в проектах, що зумовлені типовою діяльністю по управлінню
проектами, яка направлена на безперервне розв'язання таких загальних питань:
1. Що необхідно робити?
2. Хто і що повинен робити?
3. Хто з ким взаємодіє?
4. Коли і що повинне бути зроблено?
5. Скільки і яких ресурсів треба і для чого?
6. Коли і звідки ресурси повинні поступати?
7. Що скільки стоїть?
8. Що і коли повинно бути сплачено? Які це кошти і звідки вони надходять?
9. Які ліміти ресурсів і бюджету?
10. Яка потрібна якість?
11. Які ризики проекту?
12. Що виконано на момент, що розглядається, що немає?
13. Ким і які порушені терміни?
14. Що необхідно зробити, щоб проект був виконаний вчасно?
Таким чином, до загальних принципів планування можна віднести наступні.
Цілеспрямованість. Планування розглядається як процес розгортання
головної мети проекту в ієрархічну послідовність цілей і задач проекту до рівня
окремих заходів, дій, робіт з визначенням порядку їх виконання.
Комплексність. Комплексність планування означає повний охват наукових,
проектних, організаційних, виробничих та інших заходів і робіт, направлених на
досягнення цілей і результатів проекту.
Збалансованість по ресурсах. Збалансованість по ресурсах означає, що
плани не містять задач і робіт, не забезпечених необхідними ресурсами.
 Системність. Системність планування передбачає застосування системного
підходу і врахування впливу на проект чинників його оточення; розгляд проекту
як цілісної системи з визначенням і врахуванням взаємозв'язків як всередині, так і
поза ним.
Гнучкість. Гнучкість планування передбачає здатність системи
прогнозувати і враховувати можливі зміни впливу зовнішніх чинників і їх
наслідків. Для цього користувачеві повинна бути надана можливість легко
варіювати набором технологічних, організаційних і економічних умов, що
враховуються в розрахунку, варіювати критеріями, обмеженнями, пріоритетами і
отримувати в зручному вигляді для аналізу і зіставлення варіанти планів, що
формуються при різних постановках задач.
Багатофункціональність. Багатофункціональність планування означає
обов'язкове планування всіх встановлених функцій управління проектом.
Оптимальність. Оптимальність планування передбачає здатність системи
формувати не просто прийнятні (допустимі з точки зору прийнятих обмежень і
вимог) плани, а раціональні або кращі плани по вибраних критеріях. Це
досягається використанням економіко-математичних або, коли це неможливо,
евристичних методів.
Адаптивність. Адаптивність планування включає всі переваги оптимального
планування, крім того, враховує організаційні проблеми. До процесу розробки
плану залучається керівництво, що дає можливість враховувати вимоги, які не
формалізуються. Все це робить планування більш адекватним реальним умовам,
персоніфікованим, обгрунтованим і відповідальним.
Несуперечність. Несуперечність планування забезпечується спадкоємністю і
взаємоув’язаністю всіх планових рішень.
Безперервність. Безперервність планування полягає в моніторингу, контролі
і, за необхідності, актуалізації планових рішень.
Стабільність. Стабільність планування забезпечується незмінністю основних
цілей і обмежень проекту, його життєздатністю, а також гнучкістю і адаптивністю
системи.

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

4. Цілі, призначення та види планів

Основна ціль планування - інтеграція всіх учасників проекту для виконання
комплексу робіт, що забезпечують досягнення кінцевих результатів проекту.
Планування являє собою сукупність дій, що передбачають визначення цілей
та параметрів взаємодії між роботами та організаціями-учасниками, розподіл
ресурсів і вибір інших організаційних, технологічних та економічних рішень, що
забезпечують досягнення поставлених в проекті цілей. Традиційно у методології
управління проектами сформована, у відповідності з фундаментальними рівнями
управління, наступна система планів:
1. концептуальний;
2. стратегічний;
3. тактичний, який в свою чергу включає:
• поточний;
• оперативний.
На концептуальному рівні визначаються цілі, задачі проекту, розглядаються
альтернативні варіанти дій по досягненню намічених результатів з оцінкою
негативних і позитивних аспектів кожного варіанту, встановлюються
концептуальні напрямки реалізації проекту, включаючи опис предметної області,
укрупненої структури робіт, логіки їх розвитку, основні віхи, попередню оцінку
тривалості, вартості та потреби у ресурсах.
Стратегічний план визначає:
* цільові етапи та основні віхи, які характеризуються строками введення
об'єктів, виробничих потужностей, об'ємами випуску продукції;
* етапи проекту, які характеризуються термінами завершення комплексів
робіт (нульовий цикл, монтаж каркасу та ін.), термінами поставки продукції
(обладнання), термінами підготовки фронту робіт;
* кооперацію організацій виконавців;
* потреби у матеріальних, технічних і фінансових ресурсах з розподілом по
рокам, кварталам.
Основне призначення плану на цьому рівні показати як проміжні етапи
реалізації логічно вишиковуються у напрямку до кінцевих цілей проекту.
Стратегічний план встановлює стабільне зовнішнє та внутрішнє оточення,
фіксовані цілі для проектної команди та забезпечує загальне бачення проекту.
Проект-менеджер ув'язує окремі віхи у єдиній стратегії з інвестором і
знайомить з цим планом проектну команду. Також на цьому рівні фокусується
увага на проміжних етапах, які допомагають розподілити роботу по підрозділам
команди. Підрозділи команди отримують завдання по виконанню проміжного
етапу і планують свою власну роботу незалежно від інших членів проектної
команди. Вони знають, що повинні виконати свій етап до певної дати для того,
щоб забезпечити подальше виконання проекту.
На тактичному рівні розрізняють:
* поточний план - уточнює строки виконання комплексів робіт, потреби у
ресурсах, встановлює чіткі межі між ділянками робіт, за виконання яких
відповідають різні організації-виконавці, у розрізі року і кварталу;
* оперативний план - деталізує завдання учасникам на місяць, тиждень, добу
по комплексах робіт.
Плани можуть деталізуватися по функціях управління. Функціональний план
розроблюється на кожний комплекс робіт (підготовчі роботи, проектно-
дослідницькі роботи, поставка матеріалів та обладнання, будівництво, пусковий
період і освоєння виробничих потужностей) або на комплекс робіт, які
виконуються однією організацією.
На передінвестиційній стадії у складі так званого обгрунтування інвестицій та
ТЕО може складатись укрупнений (попередній) план реалізації проекту,
включаючи потреби в основних видах ресурсів.
Також розрізняють плани за ступенем охоплення робіт проекту:
* зведений, комплексний, головний (на всі роботи проекту);
* детальний (частковий) по організаціях учасниках;
* детальний (частковий) по видах робіт.
Типи календарних планів вибираються в залежності від цілей планування,
особливостей проекту і організації управління.

4. План реалізації проекту

Глибина деталізування планування визначається розмірами і складністю
проекту, характером проекту, типом об’єктів, що створюються. Типова структура
плану проекту по створенню виробничого об’єкта включає:
1. Основні цілі проекту.
2. Фінансовий план проекту.
3. План виконання субконтрактів.
4. Функціональний план.
5. Аналіз чинників виконання проекту.
6. Додатки до плану проекту.
(1) Основні цілі проекту. При формулюванні цілей потрібно уникати
спрощених і практично нездійсненних цілей. Цілі потрібно викладати якомога
більш чітко і конкретно, враховуючи відносне значення кожної мети і її вплив на
прийняття альтернативних управлінських рішень.
 (2) Фінансовий план проекту. Визначається мінімальні рівні інвестицій
кожного інвестора, методи і умови фінансування. План фінансування, як правило,
впливає на графік капітальних витрат, погашення заборгованості і при угоді між
учасниками проекту і інвесторами. Фінансовому плануванню передує кошторисна
робота. Кошториси складаються на кожний вид, етап робіт. Крім того фінансове
планування передбачає оцінку фінансово-економічних показників проекту
(дисконтований прибуток, термін окупності).
(3) План виконання субконтрактів. Представляє спільну стратегію
замовника, генерального підрядника, субпідрядників і постачальників. Є
зв’язуючим для всіх учасників проекту. Основою для його складання служить
чітке визначення і розподіл задач і обов’язків всіх учасників проекту. При
складанні цього плану:
а) оцінюються альтернативи укладання субконтрактів; критеріями такої
оцінки є можливість виконання технічних завдань субпідрядниками в необхідні
терміни;
б) вибір найбільш відповідного типу контрактів для кожного субпідрядника і
визначаються терміни, відповідальні за підготовку і укладання цих контрактів;
в) розробляється концептуальний календарний план проекту як складова
частина контрактної документації.
(4) Функціональний план. Визначає структуру функціональних комплексів
робіт, терміни і особливості їх виконання. До функціональних комплексів можуть
бути віднесені: проектні роботи, матеріально-технічне постачання (МТП),
будівництво, контроль якості, здавання в експлуатацію. Складається з наступних
планових документів:
• головного календарного плану проекту;
• календарних планів робіт (короткострокових);
• функціональних планів робіт.
Головний календарний план (ГКП) формується шляхом уточнення і
деталізування концептуального плану проекту. Він визначає етапи проекту, які
поділяються на цільові етапи і етапи проекту, пов’язані з початком і завершенням
функціональних комплекс робіт. Головний календарний план, як правило,
представляється в формі гістограми, оскільки на цій фазі проекту декомпозиція на
окремі роботи відсутня, а конкретні обмеження не визначені.
Короткострокові календарні плани формуються на основі ГКП і містять
переліки робіт, терміни, прізвища осіб, відповідальних за їх здійснення.
Функціональні плани робіт (ФПР) - системи планових документів, що
містять заходи, а також конкретні технічні і проектні рішення з окремих
особливостей виконання проекту. До таких аспектів відносяться:
1) За планом практичних робіт:
  початкові дані для проектування;
 пріоритети виконання робіт;
 потреба в персоналі;
 процедури затвердження проектних розробок;
2) За планом матеріально-технічного постачання:
 терміни постачання обладнання;
 терміни і контроль за установкою обладнання;
3) За планом будівництва:
 вимоги до приміщень для розміщення обладнання і персоналу;
 організація робіт з підготовки і будівництва приміщень;
4) За планом контролю якості:
 загальні критерії якості;
 контроль обладнання, що поставляється;
5) За планом введення в експлуатацію:
 підготовчі роботи;
 доексплуатаційний контроль;
 введення в експлуатацію.
(5) Аналіз чинників виконання проекту. Чинник виконання проекту - ключові
параметри або процеси проекту, які можуть вплинути на досягнення його цілей.
Мета цього розділу - розробка системи заходів, що компенсують недоліки
планових рішень попередніх етапів планування і спрямованих на запобігання
впливу протидіючих чинників, на отримання вигоди від впливаючих чинників, на
збільшення суми економічного ефекту від взаємодії всіх чинників.
Документальною формою цього розділу плану є угода про заходи, яка
затверджується зацікавленими учасниками і узгоджується з відповідальними
виконавцями.
(6) Додатки до плану проекту. Виносяться дані, що використовуються при
складанні плану:
- дані з концепції проекту;
- матеріали обстеження;
- вимоги і обмеження до проекту та інше.

7. Календарні плани
Центральне місце у плануванні проекту займають задачі календарного
планування - складання і коригування розкладу, в якому роботи, виконані різними
організаціями, ув'язуються в часі між собою і з можливостями їх забезпечення
різними видами матеріально-технічних ресурсів. При ув'язці повинно бути
забезпечено дотримання заданих обмежень (строки пакетів робіт, макети ресурсів,
фіксування та ін.), оптимальне (по прийнятому критерію) розподілення ресурсів.
У ході реалізації проекта застосовуються різні типи календарних планів, які
можна класифікувати по різних ознаках:
а) По рівню планування
1. Календарні плани проекту (розробляються до укладання контрактів);
2. Функціональні календарні плани робіт (ФКПР).
У свою чергу функціональні календарні плани робіт поділяються:
а) По типах робіт:
- ФКПР проектування;
- ФКПР МТЗ;
- ФКПР будівництва;
- ФКПР введення в експлуатацію і освоєння.
- ФКПР також можуть бути складені: на окремі черги, підсистеми, комплекси
великого проекту, які в цьому випадку розглядаються як мініпроекти.
б) По глибині планування:
1. перспективні графіки;
2. графіки початку і завершення робіт по проекту;
3. щомісячні, щотижневі, щоденні.
в) За формою подання:
1. логічні мережі;
2. графіки;
3. діаграми і т.д.
Призначення календарного плану варіюється в залежності від рівня
управління, на якому він використовується:
- керівники вищої ланки - для контролю термінів досягнення основних
корпоративних цілей;
- функціональні керівники - для контролю виконання функціональних
календарних планів робіт;
- менеджер проекту - для контролю виконання основних етапів
функціонування календарних планів і рівня готовності проектних вузлів.
Підготовка календарних планів робіт здійснюється через уточнення і
декомпозицію головного календарного плану проекту (ГКП).
Кожна робота в календарному плані характеризується:
1. часом виконання (тривалістю);
2. рядками початку і закінчення;
3. ресурсами, що вимагаються;
4. відповідальним виконавцем.
У найпростішому випадку параметри календарного плану складають дати
початку і закінчення кожної роботи, їх тривалості та необхідні ресурси. При
аналізі календарних планів визначають також резерв часу (величина можливого
відхилення тривалості для кожної роботи, яка не вплине на завершення проекту
вчасно). У більшості складних календарних планів існує до 6 варіантів моментів
початку, закінчення, тривалості робіт і резервів часу. Це - ранні, пізні, базові,
планові і фактичні дати, реальний і вільний резерв часу.
У повній системі календарного планування існує до 15 дат і моментів часу,
що визначають роботу:
Ранній початок Тривалість Раннє закінчення
Пізній початок Резерв часу Пізнє закінчення
Базовий початок Базовий резерв часу Базове закінчення
Поточний початок Резерв часу, що Залишився Поточне закінчення
Фактичний початок Тривалість, що Залишилася Фактичне закінчення
Процес складання календарного плану полягає у визначенні значень цих дат і
моментів часу.
Планові дати вибираються між ранніми і пізніми датами виконання робіт.
Однак, дата, яка планується для роботи перед початком виконання проекта, може
відрізнятися від дати поточного плану Дуже важливо зареєструвати первинний
план, тому що він є базою, відносно якої надалі здійснюється контроль за часом.
Ця дата називається базовою датою, а дата поточного плану - поточною плановою
датою. Якщо базова (початкова дата) більше дати раннього початку роботи, то
плановий (або базовий) резерв часу буде меншим ніж є. Аналогічно, якщо початок
або закінчення роботи затримується, то резерв часу, що залишився буде меншим
первинного.
При призначенні базових або поточних планових дат необхідно також
враховувати ресурсні обмеження.
Методи розрахунку сітьових моделей дозволяють обчислювати тільки ранні і
пізні дати. Базові і поточні планові дати необхідно вибирати із врахуванням інших
факторів.
Існують три варіанти вибору:
* календарний план по ранніх початках (жорстко зліва): використовується для
стимулювання виконавці проекту;
* календарний план по пізніх закінченнях (жорстко справа): використовується
для подання виконання проекту у кращому вигляді для споживача;
* календарний план між ними: робиться або для згладжування
використовуваних ресурсів або для показу замовнику найбільш вірогідного
закінчення.
Тривалість роботи - це головний параметр планування на основі якого
розраховуються початок і закінчення роботи.
Тривалість роботи залежить від:
- сумарної трудомісткості кожного елементу роботи, і числа працюючих, які
можуть її виконати.
 Трудомісткість роботи (чол.)
Тривалість(днів ) =
Кількість працюючих(чол.)
- часу очікування постачання деяких ресурсів (матеріалів, обладнання тощо,
яке не залежить від числа робітників, що виконують роботу.
При оцінці реальної тривалості необхідно також враховувати і такі чинники:
1. Час, втрачений на непроектні роботи
2. Робота неповний день
3. Перешкоди, що виникають між людьми, що виконують цю роботу і інш.
Як правило, втрати часу (свята, хвороби, навчання і т.п. складають до 30% від
загального робочого часу. Отже min тривалість роботи треба збільшити на 40 %.
1  1 1 
j= = 1,4 .  = = 1,4 
0,7  (1 − 0,3) 0,7 
4. Слід враховувати також, що деякі співробітники можуть працювати над
проектом неповний день. Тому загальна їх кількість повинна розраховуватися
виходячи з числа працюючих повний день. (При коригуванні тривалості необхідно
точно знати, враховані вони чи ні вони при обліку втраченого часу, тобто до того,
як збільшити тривалість на 40%)
5. Перешкоди. Збільшення числа працюючих не завжди зменшує тривалість,
тому що люди, що виконують роботу можуть обмежити доступ один одного до
місця роботи і таким чином зменшити ефективність. Тут можлива їх почергова
робота (для програмування проектів це неможливо).
Таким чином загальна формула розрахунку тривалості наступна
Трудомісткість роботи( людино − дні.)
Тривалість(днів) = × Кперешкод
Еквівалент працюючих увесь день
Тривалість деяких робіт залежить від часу очікування проекту робіт або
постачання матеріалів, або додаткової інформації або від очікування здійснення
якихось змін.
У цих випадках вірогідна тривалість роботи може бути отримана на основі
попереднього досвіду або на базі оперативних і статистичних даних реалізації
аналогічних проектів.
При оцінці тривалості необхідно враховувати також логічний взаємозв'язок
робіт.
Метод критичного шляху
Цей метод є основним математичним засобом для обчислення ранніх і пізніх
початків і закінчень робіт і резервів часу.
Календарний план більш наочно можна представити у вигляді лінійних
діаграм (які іноді називають діаграмами Гантта).
Тривалість роботи - це головний параметр планування не лише у відношенні
початку і закінчення даної роботи, але і в обчисленні для нього раннього початку із
врахуванням узагальненої тривалості передуючих робіт і пізнього закінчення, яке
враховує узагальнену тривалість наступних робіт.
Тривалість залежить від:
* сумарної трудомісткості, яка витрачається на виконання елементів роботи, і
числа робітників, які можуть її виконати;
* часу чекання поставки деяких виробів, який не залежить від кількості
робітників, які виконують роботу.
Тривалість деяких робіт залежить від часу очікування фронту робіт або
поставки матеріалів, або додаткової інформації, або від очікування здійснення
яких-небудь змін.
Вони можуть включати: поставку матеріалів та обладнання; підготовку
фронту робіт; підготовку звітів; переговори з клієнтами або підрядчиками;
отримання планових дозволів і фінансових затверджень.
Ресурсні гістограми і згладжування ресурсів
При призначенні базових або поточних планових дат необхідно враховувати
ресурсні обмеження. Якщо потреби в ресурсах для всіх робіт проекту відомі і
встановлені дати початку і закінчення, то можна обчислити функцію зміни потреб
для кожного ресурсу проекту, яка представляє таблицю рівнів ресурсів або
ресурсну гістограму.
Існує три основних види залежності потреби у ресурсах від ходу роботи
(тривалості):
* постійний - протягом всієї роботи завантаження (фронт робіт) ресурсу не
змінюється;
* східчастий - протягом роботи завантаження ресурсу змінюється
стрибкоподібно (сходинками);
* трикутний - завантаження ресурсу лінійно наростає від початку роботи до
максимального значення, а потім спадає до закінчення роботи.
Аналіз можливості реалізації проекту
Календарний план, отриманий у результаті розрахунку сіткової моделі, перевіряється,
уточнюється, при необхідності деталізується, і коли є повна впевненість, що у план включені
всі роботи, є повна інформація щодо наявних і потрібних ресурсів, переходять до аналізу
можливості реалізації.
Лекція 5Б (тема 5). МЕТОДИ ПЛАНУВАННЯ ПРОЕКТУ

План
1. Розвиток методів планування
2. Сітьові моделі

Розвиток методів планування

 Спочатку використовувалися досить прості засоби і методи, зокрема лінійні
діаграми. Іншими додатковими до лінійної діаграми засобами, що
використовувалися для УП є: таблиці трудових витрат, таблиці витрат ресурсів, в
яких вказані терміни підготовки робочої документації, початок експлуатації,
терміни по інших етапах і ресурси, необхідні для їх здійснення; таблиці
обладнання, що містять дані про типи обладнання, терміни постачання; фінансові
таблиці, що відображають прибутки і витрати.
Потім почали використовувати методи дослідження операцій, сітьові методи
(метод критичного шляху).
Проект «Поляріс» - використовувався метод аналізу і оцінки програм - PERT. Він
має перевагу тоді, коли досягнення цілей проекту пов'язане з фактором
невизначеності. Для кожної операції визначається три оцінки (оптимальна,
песимістична, найбільш вірогідна). Цей метод дозволяє керівництву проекту точно
знати, що необхідно в даний момент зробити, і хто це повинен робити, а також
імовірність виконання деяких операцій.
Сіть передування - дає найпростіше уявлення про операції, що паралельно
виконуються.
Метод критичного шляху і сіті передування краще використовувати тоді, коли
операції проекту мають певну тривалість, а якщо оцінки тривалості носять
ймовірносний характер, то більш ефективний метод PERT.
Загальна умова - для реалізації події повинні бути завершені усі попередні
операції.
Метод аналізу і графічної оцінки – GERT - доцільно застосовувати у випадку,
коли для завершення планування не обов'язкове виконання всіх операцій. Він дає
оцінки імовірності реалізації подій, на основі даних, визначених за допомогою
моделювання ситуацій.
Сітьові моделі

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

використовується для опису залежностей між роботами і етапами проекту. Сіткові
моделі доцільно використовувати тільки для складних проектів.
Існує три типи сіток:
 * сітки типу "вершини-роботи";
* сітки "вершини-події";
* змішані сітки.
Сітки типу "вершини-роботи". У сітках типу "вершини-роботи" елементи роботи
подані у вигляді прямокутників, зв'язаних логічними залежностями, які йдуть один
за одним. Існують чотири типи логічних взаємозалежностей між роботами:
* закінчення-початок: В не може початися, поки не закінчиться А;
* закінчення-закінчення: D не може закінчитися поки не закінчиться С;
* початок-початок: D не може початися поки не почнеться С;
* початок-закінчення: F не може закінчитися поки не почнеться Е.
Сітки типу "вершини-події". Сітки такого виду часто називаються IJ сітками,
оскільки кожна робота визначається номером IJ (початок/кінець). У сітках цього
типу робота зображується стрілкою між двома вузлами і визначається номерами
вузлів, які вона зв'язує. Так як роботи повинні бути унікальними, то дві роботи В і
С не можуть зв'язувати той самий вузол. Таким чином, В і С закінчуються у вузлах
3 і 4 відповідно і ці вузли пов'язуються фіктивною роботою. Так як роботи
пов'язані через вузли, використовується логічна залежність виду закінчення-
початок. Можливе введення фіктивних робіт для зображення трьох інших логічних
зв'язків.
Змішані сітки. Робота зображується у вигляді прямокутника (вузла) або лінії
(стрілки). Крім того, існують прямокутники і лінії, які можуть не зображувати
роботу: одночасні події та логічні залежності. Лінії використовуються не для
об'єднання прямокутників по початках і закінченнях, а для відображення моменту
часу до, під час або після виконання роботи. У останніх модифікаціях змішаних
сіток зникає різниця між вузлами та лініями. Математичний апарат змішаних сіток
- це принципово нова область.
Зображення сіток. У сітях типу "вершини-роботи" кожна робота
зображується прямокутником, поділеним на 7 частин. У верхніх сегментах цього
прямокутника подані дані про ранній початок, тривалість роботи і її раннє
закінчення. У нижніх - пізній початок, резерв часу і пізнє закінчення. Середня
частина містить опис роботи.
 Р а н н ій п о ч а т о к Т р и в а л іс т ь Р а н н є з а к ін ч е н н я

ES D EF

Н айм енуван ня роботи

LS F LF

П із н ій п о ч а т о к
Р езерв П із н є з а к ін ч е н н я

Р и с . 1 4 .1 . О п и с р о б о т и в с іт я х т и п у

У сітях типу "вершини-події" вузол має 4 сегменти: ідентифікатор, значення

ранніх і пізніх моментів часу та резерв часу. Час - це початок наступної роботи і
закінчення попередньої.
 I,J - ідентифікаторb
Найменування ЕS - ранній початок
I ES роботи J EF LS - пізній початок
F - резерв
LS F D LF F ЕF - раннє закінчення
(тривалість) LF - пізнє закінчення

Рис. 14.2. Робота в IJ сіті

2
В

Затримка +2

3 1
A D

Затримка −2

2
C

Рис. 14.3. Сіть типу "вершини-роботи": тривалості задані

Методи побудови сіткових моделей
Всі види сіткових моделей забезпечують розрахунок раннього та пізнього
початку і закінчення, резервів часу для кожної роботи проекту, у припущенні, що
задані тривалості робіт і логічні залежності між ними. Основа цього є настільки
потужною, що дозволяє відслідковувати різні варіанти і за формулою "ЩО-
ЯКЩО", яка передбачає варіювання тривалостями і логічними залежностями між
роботами.
Розрахунок сітьової моделі.
Тривалість - це час виконання роботи.
 Ранні і пізні дати Ці дати можуть бути визначені на основі оціночних
тривалостей всіх робіт. Початок і закінчення однієї роботи можуть залежати від
закінчення іншої. Таким чином існує сама рання дата, коли робота може бути
розпочата - дата раннього початку. Дата раннього початку плюс оціночна
тривалість роботи складають дату раннього закінчення. Якщо дата пізнього
початку відрізняється від дати раннього початку, то проміжок, під час якого робота
може бути розпочата, називається резервом часу.
Ранні початок і закінчення розраховуються на етапі прямого проходу по сітці.
Ранній початок першої роботи дорівнює 0, раннє закінчення розраховується
додаванням значення тривалості роботи. Раннє закінчення перетворюється у
наступній роботі у ранній початок відніманням випередження або додаванням
запізнення, які передбачають залежність закінчення-початок. Для залежності
"початок-закінчення" час початку перетворюється у закінчення. Якщо робота має
дві чи більше попередніх робіт, то перетворюється робота із максимальним
значенням раннього закінчення. Процес повторюється по всій сіті.
Дати пізнього початку, пізнього закінчення, резерв часу розраховуються при
виконанні зворотного проходу. Пізнє закінчення останньої роботи приймається
рівним її ранньому закінченню. Шляхом віднімання тривалості роботи
підраховується пізній початок. Пізній початок перетворюється у пізнє закінчення
попередньої роботи. Перетворена дата початку або закінчення приймається у
якості нового часу початку або закінчення у відповідності з типом залежності.
Коли робота має дві чи більше попередніх роботи, вибирається робота із
найменшим значенням часу початку (після віднімання запізнення і додавання
випередження). Процес повторюється по всій сітці. Резерв часу у першої і
останньої роботи повинен дорівнювати 0. На рис. (Слайд) показана сітка після
зворотного проходу.
Визначення критичного шляху.
Роботи з нульовим резервом часу називаються критичними; їх тривалість
визначає тривалість проекту в цілому.
Критична тривалість - мінімальна тривалість, протягом якої може бути
виконаний весь комплекс робіт проекту.
 Критичний шлях - шлях у сітьовій моделі, тривалість якого дорівнює
критичній. Критичний шлях - це послідовність робіт з нульовими резервами часу.
Роботи, які лежать на критичному шляху, називаються критичними
роботами.

Лекція 5B (тема 5). ОРГАНІЗАЦІЯ ТА УПРАВЛІННЯ ПРОЦЕСОМ

ПЛАНУВАННЯ
План
1. Управління процесом планування
2. Процес планування

Управління процесом планування

Для організації та управління процесом планування застосовуються методи:
1. Директивний передбачає інформування виконавців робіт тільки про
короткострокові плани. Персональна відповідальність за розробку планів, але
коректування і уточнення несе розробник планів, тобто учасники проекту
практично не задіяні в процесі планування.
2. Формування планів тільки на випадок кризового становища. Такі плани -
комплекси заходів щодо ліквідації такого становища.
3. Короткострокове планування методом «Плани комітетів» - плани
складаються виконавцями робіт в ході періодичних нарад по аналізу ходу
проекту.
4. Метод семінарів - менеджер проекту призначає представників
організації - учасників проекту відповідальними за успішне виконання проекту.
Діяльність групи по плануванню організується у вигляді семінарів, які
дозволяють швидко встановити взаємодію між учасниками проекту і створити
реалістичні плани, що враховують вимоги і зацікавленість всіх учасників.
Семінари звичайно проводяться в три етапи:
1. Взаємодія генерального підрядчика і робочої групи планування.
2. Взаємодія членів робочої групи по плануванню.
3. Взаємодію замовників і членів робочої групи.
 Обов'язковою умовою цього методу є надання всім членам робочої групи
необхідної інформації по проекту.
Перший етап семінару має на меті домовлятися про умови передачі управління
проектом від генерального підрядника (замовника) до менеджера проекту і
робочої групи по плануванню. Генеральний підрядник повинен поінформувати
групу про цілі проекту, умови контракту, корпоративні цілі і задачі.
Другий етап є основним. Члени робочої групи безпосередньо займаються
процесом планування; менеджер проекту здійснює загальну організацію процесу
планування і контроль розроблених планів на їх відповідність концепції проекту.
Третій етап. Представник замовника повинен поінформувати членів робочої
групи відносно цілей проекту, корпоративних цілей і задач замовника.
Важливість термінів і якості проекту. Всі ці аспекти повинні бути враховані в
проектах, що розробляються. Замовник аналізує ці документи, а у разі схвалення
погодить їх. Остаточний варіант всіх планів необхідно направляти замовнику
офіційно, а після твердження всім учасникам проекту.

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

Лекція 5C (тема 5). КОНТРОЛЬ В УПРАВЛІННІ ПРОЕКТАМИ

План
1. Сутність контролю в управлінні проектами
2. Види контролю
3. Загальні принципи контролю
4. Побудова системи контролю

1. Сутність контролю в управлінні проектами

1. Контроль представляє процес в якому керівник проекту встановлює - чи
досягаються поставлені цілі, виявляє причини, які дестабілізують хід роботи і
обгрунтовує прийняття управлінських рішень, що коригують виконання робіт по
проекту, перш ніж будуть завдані збитки проекту. Основні задачі контролю:
отримати фактичні дані, зіставити з плановими і виявити відхилення. Для рішення
цієї задачі контроль повинен забезпечити:
2. Моніторинг - систематичне і планове спостереження за всіма операціями.
3. Виявити відхилення від цілей реалізації проекту за допомогою ряду
критеріїв і обмежень, які фіксуються в календарних планах, бюджетах і інш.
документації.
4. Прогнозування наслідків ситуації.
Обгрунтування необхідності прийняття коригуючих впливів.
Предмет контролю - факти і події, перевірка виконання конкретних рішень,
з'ясування причин відхилення, оцінка ситуації, прогнозування наслідків. Контроль
передбачає постійне стеження за просуванням проекту, він cфокусований на
деталях проекту. За контрольні дії несе відповідальність керівник проекту. Оцінка
також, як і контроль, є важливою функцією зворотного зв'язку однак вона
базується на попередньому підведенні проміжних підсумків і оцінці загальної
картини і звичайно проводиться особою або групою осіб, які не працюють
безпосередньо над проектом.
2. Види контролю
Три види контролю:
1 - попередній,
2 - поточний,
3 - заключний
(1) - здійснюється до фактичного початку виконання робіт і направлений на
дотримання певних правил і процедур, як правило він торкається ресурсне
забезпечення робіт.
(2) - поточний контроль здійснюється при реалізації проекту, він включає
контроль часу, досягнення проміжних цілей проекту, виконання заданих обсягів
робіт, контроль бюджету, контроль ресурсів, контроль якості. Основна мета -
оперативне регулювання ходу реалізації проекту. Такий підхід базується на
порівнянні досягнутих результатів з встановленими в проекті вартісними,
часовими, ресурсними характеристиками. У залежності від необхідної точності
розрізнюють технології поточного контролю:
1- контроль на момент закінчення робіт
2- контроль в момент 50 % готовності робіт
3- контроль в момент зазделегідь встановлених певних точках проекту
4- регулярний оперативний контроль
5- експертна оцінка ступеню виконання робіт і готовності проекту
(3) - проводиться на стадії завершення проекту з метою інтегральної оцінки
реалізації проекту. Основне призначення - узагальнення отриманого досвіду для
подальшої розробки і реалізації проектів-аналогів і з метою вдосконалення
процедур управління.
Елементи що є об'єктами контролю: час, вартість, якість, зміни виникаючі в
ході реалізації проекту; підготовка, отримання, розподіл і схвалення документа
проекту, стан справ з фінансуванням, експлуатаційні характеристики проекту,
відповідність положенням контракту.
3. Загальні принципи контролю
Основними принципами менеджера проекту в процесі контролю є:
 1 - наявність плана контролю
2 - визначення базової траєкторії, нормативів, стандартів для порівняння з
ними поточних значень, що контролюються елементів.
3 - регулярне спостереження за ходом робіт і зіставлення поточного стану
проекту з базовою траєкторією і стандартами.
4 - оцінка збігу або розходження планових показників з їх поточними
значеннями.
5 - раннє виявлення проблем, що виникають.
6 - вживання чітких дійових заходів для розв'язання проблем, що виникають.
4. Побудова системи контролю
Необхідно:
1 - визначити склад і рівень деталізування робіт, що підлягають контролю.
2 - складання показників і форми представлення первинної інформації.
3 - встановлення термінів представлення первинної інформації і зведено-
аналітичних звітів.
4 - призначення відповідальних за повноту, достовірність і своєчасність
надання даних, що подаються.
5 - визначення складу, методів і технології подання аналітичних і графічних
звітів.
6 - визначення комплексу програмно-інформаційних засобів, що будуть
використовуватись (якщо будуть використовуватися).
Центральна (необхідність) - визначення складу показників, що
контролюються. У західній науці управління проектами в системах контролю
ходу реалізації проекту для позначення критеріїв оцінки стану проекту
використовувався термін - прогрес в реалізації проекту. Прогрес може бути
виражений різними способами, наприклад, повне завершення окремих етапів
робіт, часткова реалізація робіт, там де для оцінки стану справ використовувався -
% виконання; незавершеність проекту, якщо вона планується.
1- Виконання або невиконання яких-небудь контрольних етапів називаються
якісним прогресом. Кількісним прогресом називають прогрес, який можна оцінити
показниками, вираженими в одиницях вимірювання робіт. Конкретні фізичні
показники прогресу можуть інтегруватись в єдиний показник грошових витрат, це
дозволяє порівняти фактичні витрати з плановими. Одним з варіантів оцінки
прогресу - реєстрація його по таких критеріях:
2- досягнення контрольних точок (етапів) у виконанні календарного полону
робіт
3- витрати фінансових коштів
4- витрати ресурсів і ефективність їх використання (блок показників на
кожний вид ресурсів)
5- величина отриманих прибутків або обсягів виконаних робіт.
Система контролює показники: кошторисна вартість по календарному
графіку, фактичні витрати на виконання робіт, кошторисна вартість виконаних
робіт. На основі цих показників визначаються і інші показники: відхилення від
графіка виконання робіт, відхилення від кошторису витрат, індекс інтенсивності
витрат і інші показники.
Інформація що відображає стан і хід робіт по проекту поступає від членів
проектної команди, організації-виконавців, незалежних контролерів або з
планових і звітних документів.
Три міри деталізування інформації для досягнення мети контролю:
1- керівники підрозділів і відповідальні виконавці отримують найбільш
деталізовану інформацію, що дозволяє оцінити стан кожної із закріплених за ним
робіт і її положення в комплексній сітьовій моделі.
керівник організації і виконавці при під комплектованих роботах повинні
мати інформацію, що дозволяє дати загальною оцінку стану ходу робіт,
закріплених за даною організацією і що містять найбільш докладні відомості по
граничних подіях, якими визначаються зв'язки з іншими організаціями або
підкомплексами а також зведення про роботи даної організації або підкомлексу,
що попали в критичну зону.
3 - керівник проекту отримує деталізовану інформацію по роботах критичної
зони, які дозволяють йому укрупнено оцінити загальний стан робіт по проекту
загалом, його окремих найбільш важливих елементів і етапів а також
проконтролювати планові терміни настання граничних подій, що визначають
зв'язки між організаціями-виконавцями і структурними підрозділами всередині
головної організації.
 Обов'язкові вимоги до системи контролю:
• точність
• своєчасність
• повнота інформації
• забезпечення єдності інформації для всіх учасників проекту
Формальні джерела інформації необхідні для контролю включаючи форми
урахування часу експлуатації машин і обладнання, звіти про виконання заданих
обсягів робіт, табелі використання робочої сили, різні види повідомлень про хід
робіт і інші документи.
Можна скласти спеціальні звіти за різними формами:
а) безпосередньо при особистих контактах
б) у табличній формі надання вартісних показників
у) в графічній формі надання
Незалежно від форми надання, звітна інформація повинна включати 5
основних елементів:
1) кошторисну вартість
2) фактичні результати
3) результати, що прогнозуються
4) відхилення та причини, які пояснюють ці відхилення
Інформація про фактичний хід робіт і прогнозована, представляється в
проектну команду відповідальним виконавцем. Ця інформація використовується
для розрахунку, перерахунку і аналізу сітьової моделі, а також коригуванню
нормативно-довідкової бази. Перерахунок моделі включає в себе фіксацію на
сітьовому графіку стану поточних і закінчених робіт, подій, що здійснилися,
внесення нових робіт і подій, виключення анульованих, уточнення формулювань,
опис робіт. Всякі зміни що стосуються граничних робіт і подій погоджують з
суміжними відповідальними виконавцями.
Лекція 5Е (тема 5) Управління якістю

План
1. Сутність управління якістю та його основні функції
2. Інтеграція функцій забезпечення якості
 3. Способи і техніка управління якістю проектів ІС
4. Розробка системи управління і забезпечення якості програмних
продуктів у відповідності з ISO-9000

1. Сутність управління якістю та його основні функції

Складові якості проекту:
•матеріали, що використовуються, обладнання, сировина;
•якість робіт, що виконуються;
•якість отриманих результатів.
Управління якістю реалізовується через встановлення вимог і стандартів до
якості результатів проекту; забезпечення виконання вимог до якості через систему
контролю і підтримки.
Управління якістю (слайд)
2. Інтеграція функцій забезпечення якості
Опрацювати самостійно з літературних джерел!
3. Способи і техніка управління якістю проектів ІС
Опрацювати самостійно з літературних джерел!
4. Розробка системи управління і забезпечення якості програмних продуктів
у відповідності з ISO-9000
4. 1 Загальна характеристика стандартів ISO-9000 із забезпечення
якості продукції чи послуг
4. 2 Необхідність розробки системи управління по забезпеченню якості
ПП
4. 3 Відповідальність керівництва
4. 4 Система якості
4. 5 Аналіз контракту
4. 6 Управління проектуванням
4. 7 Управління документацією і даними
4. 8 Закупки
4. 9 Ідентифікація та відслідковування продукції
4. 10 Управління процесами
4. 11 Контроль та випробування
 4. 12 Управління продукцією, що не відповідає вимогам
4. 13 Коригуючі та запобіжні дії
4. 14 Погрузочно-розгрузочні роботи, зберігання, упаковка, консервація та
поставка
4. 15 Управління реєстрацією даних про якість
4. 16 Внутрішній аудит якості
4. 17 Підготовка кадрів
4. 18 Обслуговування
4.1. Загальна характеристика стандартів ISO-9000 із забезпечення якості
продукції чи послуг
ISO-9000 - стандарт на якість проектування, розробку, виготовлення та
післяпродажного обслуговування. ISO-9000 визначає базовий набір заходів з
контролю якості та містить схему функціонування бізнес-процесів підприємства,
яке забезпечує якість його роботи.
ISO-9000, не є стандартом якості власне для товарів та послуг, що виробляє
підприємство. Схема “покриває” всі етапи виробничого циклу випуску
товарів/послуг:
 закупку сировини і матеріалів
 проектування
 створення і доставка товарів
 обслуговування клієнтів
 навчання персоналу
Власне ISO-9000 регламентує два ключових момента:
1. наявність і документування відповідного бізнес-процесу
2. вимірювання його якості
Насправді ISO -9000 це серія стандартів з управління якістю і забезпечення
якості.
Є чотири частини ISO -9000:

9000-1 - настанови щодо вибору і застосування

9000-2 - настанови щодо застосування ISO -9001, ISO -9002 та ISO -9003

9000-3 - настанови щодо застосування ISO -9001 до розроблення,
поставляння та супроводження ПЗ.

9000-4 - настанови щодо управління програмною надійністю.
 ISO -9001- системи якості - модель забезпечення якості в процесі
проектування розроблення, виробництва, монтажу та обслуговування. Цей
стандарт є найбільш повним. Він специфікує модель забезпечення якості на всіх
етапах життєвого циклу товару/послуги.
ISO -9002 - системи якості - модель забезпечення якості в процесі
виробництва, монтажу та обслуговування.
ISO-9003 - системи якості - модель забезпечення якості в процесі контролю
готової продукції та її випробування.
ISO-9004-1 - управління якістю та елементи системи якості: Частина 1:
настанови
ISO-9004-2 - управління якістю та елементи системи якості: Частина 2:
настанови щодо послуг.
ISO-9004-3 - управління якістю та елементи системи якості: Частина 3:
настанови щодо перероблюваних матеріалів.
ISO-9004-4 - управління якістю та елементи системи якості: Частина 4:
настанови щодо поліпшення якості.
Сертифікація підприємства за стандартом ISO-9000 включає наступні три
етапи:
1.Застосування стандартів на підприємстві, яке полягає в розробці і введення
в дію низки засобів пропонованих стандартами;
2.Проведення власної сертифікації акредитованими ISO–органами;
3.Періодичні (два рази на рік) перевірки підприємства на наслідування
(відповідність) стандартів;
Сертифікація за ISO-9000 є добровільною справою кожного підприємства.
Основною причиною сертифікації є те що закордонні компанії вимагають
наявності сертифіката від своїх постачальників. Більш того, наявність сертифіката
може бути обов’язковою умовою участі підприємства в міжнародних тендерах,
держзамовленнях, а також отримання пільгових кредитів та страховок.
4. 2. Необхідність розробки системи управління по забезпеченню якості
ПП
В середині 80-х років за постановою ДКНТ СРСР, програми стали
продукцією технічного призначення. Але і до тепер, більшість програмістських
фірм не спромоглися довести організацію процесу розробки програмних систем
до рівня “індустріального”. Для налагодження такого процесу недостатньо мати
висококваліфікованих, талановитих фахівців, необхідними є:
• Чітка організація спільної роботи команди розробників;
• Загальне управління проектом, яке включає не тільки розподіл обов”язків, а
і розподіл відповідальності.
Система якості є організаційним стрижнем створення оптимальних умов для
продуктивної праці фахівців. Вона дозволяє перейти від кустарного рівня
створення програм до наукового, організованого масового виробництва
програмного продукту, завдяки застосуванню особливих методів управління
якістю. Ці методи варіюються від компанії до компанії, але основні їх положення
єдині для всіх і визначаються стандартом ISO-9003.
Цей стандарт включає усі положення загального стандарту ISO-9001, а а
також необхідні доповнення до них, що стосуються розробки, поставки та
обслуговування ПЗ.
ISO-9001 встановлює вимоги до системи якості постачальника і дозволяє
оцінити його можливості з проектування та постачання продукції , що відповідає
цим вимогам.
Вимоги стандарту мають на меті задоволення запитів користувача через
попередження появи будь-яких невідповідностей продукції на усіх стадіях її
життєвого циклу від проектування до обслуговування ПЗ.
Основні поняття, якими оперує стандарт:
• Продукт – результат дії або процесів;
• Програмний продукт- набір комп”ютерних програм, процедур і , можливо,
пов”язаних з ними документів та даних;
• Елемент програмного забезпечення- (software item)-будь-яка частина
програмного продукту, що ідентифікована;
• Основа (baseline)- формально узгоджена версія елемента конфігурації ,
зафіксована у певний момент часу на протязі життєвого циклу елемента
конфігурації;
• Розробка(development)- процес життєвого циклу ПП, що охоплює аналіз
вимог, проектування , кодування, інтеграцію, тестування,установку та підтримку;
 • Модель життєвого циклу- (life cycle model)- , базова модель, яка включає
процеси, дії та задачі, що мають місце у розробці, функціонуванні та супроводі
ПП і охоплюють увесь життєвий цикл системи від визначення вимог до
завершення
• Етап- певний сегмент роботи ;
• Регресійне тестування- ( regression testing)- тестування , що дозволяє
упевнитися в тому, що зміни, внесені з метою виправлення виявлених помилок ,
не породили нових;
• Реплікація- (replication)- копіювання програмного продукту з одного носія
на інший.
Стандарт впроваджується на добровільній основі і зобов”язує підприємства
суворо регламентувати певні аспекти виробничої діяльності. Їх перелік наведено в
плані лекції п. 4.1-4.18.
4.3. Відповідальність керівництва
На керівництво компанії–постачальника накладається задача визначення
політики та своїх зобов”язань з якості.
Ця політика повинна бути узгодженою як з цілями самої компанії , так і з
очікуваннями і запитами самого користувача.
Постачальник повинен забезпечити розуміння цієї політики службовцями
компанії ,її проведення та підтримку на усіх рівнях.
Керівництво визначає і документально оформляє відповідальність,
повноваження та механізми взаємодії персоналу, який виконує та перевіряє
роботу, що впливає на якість.
Керівництво призначає менеджера з якості з відповідними повноваженнями
для забезпечення розробки, впровадження та підтримки в робочому стані системи
якості та надання звітів про її функціонування , які дозволяють проаналізувати та
удосконалити систему якості.
4.4.Система якості
Компанія- постачальник повинен розробити, документально оформити та
підтримати в робочому стані систему якості як засіб, що забезпечує
відповідність продукції вимогам стандарту ISO-9001.
 Система якості передбачає наявність:
• Інструкції з якості, яка включає методики системи якості компанії;
• Опис структури документації , що використовується в системі якості.
Масштаб та ступінь деталізації методик системи якості залежать від
складності роботи, методів, що використовуються, необхідних навичок та
роботи персоналу.
Постачальник також визначає та документально оформляє дії, пов”язані з
реалізацією вимог до якості, тобто планує якість – формулює вимоги до якості,
описує модель ЖЦ, задає критерії початку і кінця кожного етапу проекту,
визначає типи аналізу , тестування та інших дій з перевірки та затвердження
ПП, визначає процедури управління конфігурацією. Планування якості
“настроює” систему якості на певний проект.
4.5. Аналіз контракту
Система якості передбачає певні дії з аналізу контракту.
ПП може розроблятись:
1. За контрактом із замовником;
2. Як комерційний продукт для певного сектора ринку;
3. Як система, вмонтована в апаратне забезпечення;
4. Як система підтримки бізнес-процесів постачальника.
Загальні положення аналізу контрактів, визначені в ISO 9000-3, прийнятні
для будь-якої з цих ситуацій.
Постачальник повинен попередньо проаналізувати заявку на тендер,
контракт чи замовлення ( до надання заявки або укладання контракту). Це
дозволить гарантувати адекватне визначення вимог до проекту і можливість
виконати контракт.
У процесі аналізу контрактів на ПЗ можуть враховуватись різноманітні
аспекти взаємодії з замовником, технічні міркування,аспекти управління та
фактори забезпечення захисту і конфіденційності.
Наприклад, можуть аналізуватися:
- узгоджені із замовником критерії прийняття або відмови від готової
системи;
- термінологія;
 - ступінь участі замовника у спільній роботі;
- відповідальність замовника за надання певних даних або обладнання;
- зобов”язання замовника перед постачальником із заміни на нові версії
системи або зобов”язання постачальника підтримувати старі версії , тощо.
Тут можуть розглядатись стандарти та процедури , які будуть
використовуватись при розробці програмної системи , операційна та апаратна
платформи, вимоги до реплікації( тиражування) і розподілення системи, вимоги
до установки, супроводу та підтримки і низка інших.
4.6.Управління проектуванням
Це найбільший розділ стандарту, оскільки торкається базової складової
загального процесу створення ПП , яка найбільше впливає на його якість.
Постачальник розробляє та документує методики управління та верифікації
проекту з метою забезпечення виконання встановлених вимог.
Цей розділ стандарту IS0 9000-3 містить вказівки з таких основних дій в
процесі розробки:
- аналіз вимог до проекту;
- проектування архітектури систем;
- детальне проектування та кодування;
- планування розробки.
Проект розробки ПП організується за певною моделлю ЖЦ. ISO 9000-3 не
визначає, якою повинна бути модель ЖЦ, це залежить від специфіки задачі.
Стандарт наводить лише визначення моделі ЖЦ як сукупності процесів. Модель
показує, коли ці процеси і як підключаються до реалізації проекту.
Відомо,що розробка системи – це процес початкових вимог до кінцевого
продукту. Стандарт оговорює , що цей процес повинен проводитись у чітко
визначеному порядку, що дозволить попередити появу помилок та знищить
залежність від процесів перебірки та затвердження як єдиних методів виявлення
проблемних ситуацій. Вимога строго дотримуватись дисципліни процесу
розробки означає наявність та підтримку в робочому стані документованих
процедур, які і стануть гарантією того ,що ПП створюється у відповідності з
заданими вимогами та планами розробки і забезпечення якості.
Управління проектом повинно враховувати такі аспекти як:
 - метод проектування та його відповідність конкретній задачі;
- досвід попередніх проектів;
- вимоги наступних процесів;
- тестування, установки, супроводу та використання;
- вимоги до захисту та безпеки;
- спеціальні вимоги до стійкості систем або до її зворотніх дій на
потенційні аварійні ситуації.
Для процесів кодування необхідно задавати правила використання мов
програмування, принципи кодування та правила розробки відповідних коментарів.
Інструментальні засоби і методи, що використовуються при розробці ПП
(системи аналізу та проектування, компілятори) повинні попередньо
затверджуватись і контролюватися системою конфігураційного управління.
Область застосування інструментарію повинна бути задокументована,а
його використання періодично аналізуватися, з метою встановлення необхідності
удосконалення інструментальних систем або заміни на нові продукти.
Проектування та розробка повинні ретельно плануватись. План розробки
ПП повинен формулювати задокументовані дії з:
- аналізу вимог до систем;
- проектування;
- кодування;
- інтеграції;
- тестування ;
- встановленню
- підтримки.
План повинен включати також плани, пов”язані з основним процесом:
- забезпечення якості;
- управління ризиками;
- управління конфігурацією;
- плани інтеграції;
- плани установки;
- плани навчання співробітників та ін.
 Повинні бути визначені і задокументовані принципи організаційно технічної
взаємодії між різними групами, які приймають участь у розробці.
Необхідно чітко встановити межі відповідальності кожного учасника і те
яким чином технічна інформація буде передаватися між учасниками. Тут же
обмовляється відповідальність замовника проекту, якщо він бере участь в
розробці: необхідність брати участь в проекті, зобов'язання по своєчасному
наданню потрібної інформації. У разі обопільної домовленості між
постачальником і замовником може бути запланований спільний аналіз ведення
проекту, регулярно або на певних його етапах. Цей аналіз торкається такі
чинники, як хід розробки з боку постачальника, участь в розробці з боку
замовника, відповідність системи вимогам замовника, результати перевірок,
результати тестування.
Вхідні проектні вимоги до продукції. Вимоги формулює замовник, а
постачальник аналізує, наскільки вони адекватні. Неповні, двозначні або
суперечливі вимоги є предметом урегулювання з особами, відповідальними за їх
пред'явлення. У певних ситуаціях, за обопільній згодою, специфікацію вимог
може провести постачальник.
Вихідні проектні дані також оформляються документально, причому таким
чином, щоб їх можна було перевірити і підтвердити відносно вхідних проектних
вимог. Вихідні дані проекту програмної системи можуть включати: специфікацію
архітектури проекту, детальну специфікацію проекту, початкові коди, керівництво
користувача.
Постачальник програмного продукту повинен планувати і провести
офіційний, документально оформлений аналіз результатів проектування. Міра
формальності і суворість процесів аналізу відповідають складності системи, що
розробляється і мірам ризику, пов'язаного з її використанням. Аналіз
проектування торкається таких аспектів, як можливість виконати проект,
задоволення вимогам захисту і безпеки системи, виконання правил програмування
і можливість тестування.
На певних стадіях проектування проводиться перевірка відповідності
вихідних даних вхідним вимогам. Така верифікація проекту може включати аналіз
вихідних даних, демонстрації, в тому числі за допомогою прототипів і
моделювання, або тестування. Тільки перевірені вихідні проектні дані
затверджуються для остаточного прийому і подальшого використання. Всі
виявлені в процесі перевірки проблемні ситуації повинні адекватно дозволятися.
Перш ніж система буде передана замовнику, постачальник повинен
затвердити систему на відповідність заданому призначенню. Замовнику може
бути переданий тільки затверджений програмний продукт.
Всі зміни і модифікації проекту повинні бути ідентифіковані, документально
оформлені, проаналізовані і затверджені до їх реалізації. Постачальник
встановлює і підтримує в робочому стані процедури управління змінами в проекті,
які можуть виникнути на будь-якій стадії життєвого циклу системи.

4.7. Управління документацією і даними

Постачальник повинен розробити і підтримувати в робочому стані
документовані процедури управління всіма специфікаціями і даними, що
відносяться до вимог стандарту ISO 9001, включаючи і документи зовнішнього
походження (стандарти і креслення споживача). Документи і дані можуть
розміщуватися на будь-якому паперовому або електронному носії.
Для реалізації контролю за документами і даними можуть використовуватися
процедури управління конфігурацією. У область дії цього розділу стандарту
попадають контракти, що специфікують вимоги до продукту; документи, що
описують систему якості, що містять різні плани постачальника і взаємодію
постачальника з споживачем; документи і дані, що описують конкретний
програмний продукт.
4.8. Закупівля
Постачальнику ставиться в обов'язок розробити і підтримувати в робочому
стані документовані процедури, що гарантують відповідність закупленої
продукції встановленим вимогам. При розробці, постачанні, інсталяції і супроводі
програмних продуктів як закупівля може фігурувати: комерційне ПО; розробка по
субконтракту; комп'ютерне і комунікаційне апаратне забезпечення; кошти
розробки; персонал, що наймається за контрактом; сервіс підтримки і супроводу;
повчальні курси і матеріали.
4.9. Ідентифікація та відслідковування продукції
Постачальник повинен встановити і підтримувати в робочому стані
процедури ідентифікація елементів програмного забезпечення на всіх етапах, від
специфікації вимог до розробки, реплікації і доставок. Протягом життєвого циклу
системи повинні працювати процедури відстеження компонентів складових
частин програмного забезпечення.
Процедури ідентифікації і відстеження реалізовуються в системі
конфігураційний управління, що визначається як дисципліна управління,
відповідно до якої здійснюється технічне і адміністративне керівництво
розробкою і підтримкою життєвого циклу елементів конфігурації, включаючи
елементи програмного забезпечення. Ця дисципліна застосовна також до
документації і апаратного забезпечення, що стосується програмного продукту, що
розробляється. Міра використання конфігураційний управління залежить від
розміру і складності проекту, а також від рівня пов'язаного з ним ризику.
Одна з цілей конфігураційний управління задокументувати і забезпечити
повну видимість поточної конфігурації продукту і міри відповідності початковим
вимогам. Інша мета надати кожному, хто працює над проектом, точну інформацію
на будь-якому етапі життєвого циклу. Система конфігураційний управління дає,
зокрема, можливість ідентифікувати версію кожного елемента програмного
забезпечення, управляти одночасною модифікацією даного елемента двома або
більш незалежними розробниками, координувати модифікацію безлічі продуктів і
т . д.
У визначенні конфігурації беруть участь: структура продукту і вибір
елементів конфігурації, друкарська документація і комп'ютерні файли, угоди по
привласненню імен, завдання конфігураційний основ.
4.10. Управління процесами
Постачальник повинен визначити і спланувати процеси розробки, установки і
обслуговування продукту. Процес розробки програмної системи організований як
безліч процесів, що перетворюють початкові вимоги в програмний продукт (див.
розділ "Управління проектуванням"). Розділ стандарту оговорює вимоги до
реплікації, доставки і інсталяції програмних продуктів.
4.11. Контроль і випробування
Постачальник повинен розробити і підтримувати в робочому стані
документовані процедури контролю і випробувань для перевірки виконання
встановлених вимог до продукції.
Контроль і випробування, простіше кажучи, тестування програмного
продукту може зажадатися на декількох рівнях, від окремих елементів ПО до
закінченої системи. Існує декілька підходів до тестування, які даним стандартом
не обговорюються. Вибір підходу залежить від постачальника. Об'єм тестування,
міра контролю за середою випробувань, вхідний і вихідні дані тестів можуть
варіюватися в залежності від вибраного підходу, складності системи і пов'язаних з
нею ризиків.
Постачальник повинен визначити, задокументувати і періодично аналізувати
план тестування модулів, інтеграційних процесів, системи загалом і тестування
для остаточного приймання.
У процесі розробки постачальник повинен контролювати і випробовувати
продукцію відповідно до програми якості. Всі види остаточного контролю і
тестування також потрібно провести відповідно до цієї програми, щоб
пересвідчитися, що готовий продукт відповідає встановленим вимогам. Для
виробника програмних систем це означає, що перш ніж продукт буде переданий
замовнику, постачальник повинен офіційно підтвердити, що продукт працює
відповідно до заданого призначення, в умовах, схожих з тими, в яких буде
застосовуватися система. Будь-які відмінності між середою затвердження системи
і фактичною середою її використання, а також ризик, пов'язаний з цими
відмінностями, повинні бути виявлені і зареєстровані на можливо більш ранніх
етапах життєвого циклу.
Крім тестування для остаточного затвердження, тестування може провести
замовник при прийманні вже затвердженого продукту. При цьому він буде
визначати, відповідає чи ні продукт раніше узгодженим критеріям. Замовник може
передати повноваження на проведення таких тестів постачальнику або третій
особі. Постачальник і замовник повинні погодити між собою методи розв'язання
проблем, виявлених в ході процедури приймання.
4.12. Управління невідповідною продукцією
Постачальник повинен розробити і підтримувати в робочому стані
документовані процедури, що гарантують, що продукт, не відповідний
встановленим вимогам, не буде ненавмисно використовуватися або
встановлюватися. При розробці програмного забезпечення для ізоляції його
невідповідних елементів може зажадатися вивести їх з середи розробки або
тестування в окрему середу. У разі розробки вбудованого ПО можлива ізоляція
апаратного компонента, що містить невідповідний прикладний елемент.
4.13. Коригуючі та попереджаючі дії
Постачальник повинен розробити і підтримувати в робочому стані
документовані процедури по виконанню коректуючих і попереджаючих дій. Будь-
яка така дія, зроблена для усунення причин фактичних або потенційних
невідповідностей, повинна бути адекватно проблемам і враховувати міру ризику.
Якщо коректуючі дії безпосередньо впливають на програмний продукт, може
бути підключений процес конфігураційний управління для контролю за змінами.
Початкові дані для попереджаючих дій може дати аналіз базових причин
невідповідностей, що виникли.
 4.14. Вантажно-розвантажувальні роботи, зберігання, упаковка,
консервація і постачання
Цей розділ стандарту ISO 9000-3 конкретизує специфіку можливих
пошкоджень програмного продукту, засобу зберігання, методи упаковки,
консервації і постачання ПО.
Пошкодження програмного забезпечення означає зміну його інформаційного
вмісту. Стандарт оговорює, що зараження програмного продукту комп'ютерним
вірусом вважається пошкодженням ПО. Заходи захисту від вірусів описуються в
керівництві по реплікації.
Термін "знесення" не застосуємо до тієї інформації, яку містить програмна
система. Однак зноситися може носій, на якому зберігається система, і
постачальник повинен вжити відповідні заходів обережності.
Постачальник повинен визначити систему зберігання елементів програмного
забезпечення, управління доступом до цих елементів і підтримка версій продукту.
Для того щоб підтримати цілісність системи і забезпечити базис для управління
змінами елементи програмного забезпечення потрібно зберігати в середовищі, яке
здатне захистити їх від несанкціонованих змін і забезпечує доступ, що
контролюється і вибірку основної і будь-яких інших списів. Крім того, повинні
бути враховані умови зберігання носіїв, особливо можливий електромагнітний і
електростатичний вплив.
Можливості консервації елементів програмного продукту також зажадають
від постачальника створення певної системи, яка буде підтримувати, наприклад,
регулярне резервування, гарантоване копіювання ПО на змінний носій через певні
проміжки часу, зберігання носіїв в захищеному та стійкому до відмов середовищі,
що дозволяє гарантувати відновлення у разі катастроф.
4.15. Управління реєстрацією даних про якість
Постачальник розробляє і підтримує в робочому стані документовані
процедури ідентифікації, збору, індексування, доступу, складання картотеки,
зберігання, ведення і вилучення зареєстрованих даних про якість. Приклади таких
даних документовані результати тестування, повідомлення про проблеми, запити
про зміни, анотовані документи, результати аналізу, протоколи різних засідань,
аудиторські повідомлення.
 У тому випадку, якщо дані про якість зберігаються в електронному вигляді,
при визначенні часу збереження і доступу до даних необхідно враховувати міру
можливої деградації електронних списів і доступність пристроїв і програмних
компонентів для доступу до даних.
4.16. Внутрішній аудит якості
Постачальник розробляє і підтримує в робочому стані документовані
процедури планування і проведення внутрішніх перевірок якості, які дозволять
пересвідчитися, що діяльність в області якості і її результати відповідають
запланованим заходам, а також підтвердити ефективність системи якості.
Внутрішні перевірки якості плануються на основі статусу і важливості
діяльності, що перевіряється. Внутрішній аудит повинен провестися персоналом,
не залежним від осіб, які несуть відповідальність за діяльність, що перевіряється.
Внутрішній аудитор аналізує узгодженість програми якості для конкретного
проекту із загальною системою якості, прийнятою в організації.
4.17. Підготовка кадрів
Постачальник повинен розробити і підтримувати в робочому стані
документовані процедури визначення потреб в підготовці кадрів, а також
забезпечувати підготовку всього персоналу, що виконує роботи, які впливають на
якість. Персонал повинен бути кваліфікований на основі відповідного утворення,
підготовки і досвіду. Визначення задач навчання повинно ув'язуватися з тими
інструментальними засобами, методами і комп'ютерними ресурсами, які будуть
використовуватися в розробці програмного продукту і управлінні ім. Можливо,
буде також потрібне спеціальне навчання в тій області, з якою пов'язаний
програмний продукт, що розробляється.
4.18. Обслуговування
Що стосується програмного забезпечення, то обслуговування тут розуміється
як супровід системи (maintenance) і підтримка замовників (customer support).
Підтримка замовників обговорюється в стандарті ISO 9000-2.
Супровід системи, як правило, включає в себе виявлення і аналіз
невідповідностей в програмній системі, що викликають збої в її роботі; корекцію
програмних помилок; модифікацію інтерфейсів, що необхідно у разі внесення
додатків або змін в апаратуру; функціональне розширення або поліпшення
продуктивності
Всі дії по супроводу повинні провестися і контролюватися відповідно до
плану супроводу, який зазделегідь визначається і узгоджується постачальником і
замовником.
На закінчення нам залишається лише додати, що технологія розробки
програмного забезпечення це ціла наука, якої в Росії, леле, майже не вчать. Звідси
явний дефіцит хороших менеджерів і фахівців з комплексних проектів. Загальні
положення стандарту по забезпеченню якості лише верхівка айсберга. За межами
нашої статті залишилися деталі тих процесів, які реально забезпечують якість
кінцевого продукту. Але це, як правило, "ноу-хау" компанії.

Література
1. Міжнародний стандарт ISO 9001:1994. Системи якості. Модель
забезпечення якості при проектуванні, розробці, виробництві, монтажі і
обслуговуванні (Друге видання). Москва 1996.
2. International Standard ISO 9000-3. Quality management and quality assurance
standards Part 3: Guidelines for the application of ISO 9001:1994 to the development,
supply, installation and maintenance of computer software.

Лекція 5Ж (тема 5) Управління часом

План
1. Сутність управління часом та її зв’язок з іншими функціями УП
2. Зміст функції управління часом
3. Контроль за розвитком проекту за його часовими характеристиками

1. Сутність управління часом та її зв’язок з іншими функціями УП

 У кожному проекті час – це один з найважливіших визначальних чинників
при оцінці досягнень (успіхів) проекту. Час є основним ресурсом проекту, але , на
жаль “негнучким” ресурсом. Згаяний час не може бути поновленим. Звідси
потреба особливої уваги до функції управління часом.
2. Зміст функції управління часом
Ця функція тісно пов'язана з функцією управління предметною областю і
включає в себе:
•визначення тривалості термінів початку та завершення проекту, його частин,
найважливіших подій і кожної роботи, що виконується;
•мінімізацію (оптимізацію) часових характеристик;
•розумне (раціональне) використання резервів часу;
•контроль за розвитком проекту за його часовими характеристиками;
• прогнозування термінів завершення робіт, етапів та проекту в цілому;
•прийняття рішень з ліквідації небажаних часових відхилень.
Функція управління часом здійснюється за допомогою
 аналізу часових характеристик проекту та його частин (тривалість, дати
початку та закінчення проекту та його окремих етапів, робіт);
 календарного планування робіт;
 контролю графіків виконання робіт, їх актуалізації і коригування.
(слайд)
 Управління часом (УЧ)

Планування часу в Оцінка тривалостей Календарне Контроль часу в

проекті планування проекті

Зміст 1. Реальний час

Стратегія - Визначення робіт - Призначення строків 1. Організація системи
- Предметна область УЧ 1. - Структурна декомпозиція контрольних подій контролю проекту
1. - Обмеження - Рівень деталізації - Введення часових обмежень - Задача контролю
- Загальна послідовність робіт - Обсяги робіт - Призначення пріоритетів - Забезпечення
- Методи і процедури Ресурси 2. Реальні ресурси - Допускання відхилень
- Повноваження і - Визначення потреб - Введенння обмежень - Потоки інформації
відповідальність 2. - Варіанти - Призначення пріоритетів - Оргструктура
- Точність - Код ресурсу - Ресурси - Розподіл обов”язків
Обмеження на ресурси - Графік споживання розподіл - Система відображення
- Логіка розвитку проекту - Продуктивність зглажування/калібровка 2. М оніторинг і аналіз
2. - Логіка руху ресурсів Обмежувальні умови графік споживання - Склад показників
- Оцінка доступних ресурсів - Логіка руху ресурсів 3. Взаємозв”язки робіт - Розрахунок ТЕП
- Розподіл ресурсів 3. - Обмеження часу, ресурсів, - Типові мережі - Визначення відхилень
- Взаємозв”язки ресурсів інше - Коригування даних - Оцінка результатів
Ключові роботи і події - Перешкоди - Фіктивні роботи 3. Звіти
- Календарі і інтервали ? внутрішні - Резерви часу - Мета і призначення
3. - Строки контрактів ? зовнішні 4. Методи аналізу - Рівень деталізації
- Контрольні дати - Вплив зовнішнього - Перевірка і інтерпретація - Періодичність
- Ключові події середовища - Аналіз і відбір альтернатив - Представлення
Укрупнений план Аналіз - Розрахунки: МКП, ПЕРТ - Ведення архіву
- Розгляд, ухвалення - Альтернативи - Регресивний аналіз 4. Регулювання
4. - Контрольні події і дати 4. - Реальність виконання - Оптимізація планів - Аналіз і оцінка ситуації
- Структура і логіка робіт - Тривалість - Розгляд і приняття - Виявлення альтернатив
- Описання робіт - Прогнозування - Зворотній зв”язок - Аналіз і вибір
- Рівень деталізації плану - Загрузка потужностей 5. Информація про плани альтернатив
- Одиниці виміру часу - Резерв на непередбачені - Відображення - Підготовка рішень і
- Критерії витрати Таблиці, графіки Ганта тощо доведення до виконавців
- Одиниці виміру робіт Сітьові графіки - Оцінка виконання
- Доведення до учасників рішень
проекту

128
 Лекція 6А (тема 6) Управління вартістю

План
1. Сутність управління вартістю та його функції
2. Методи оцінки та прогнозування вартості проекту інформатизації
3. Методи і техніка управління вартістю проекту в умовах ринку

1. Сутність управління вартістю та його функції

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

Блоки управління:
1.оцінка і прогнозування вартості;
2.кошториси і бюджет;
(1.) контроль вартості;
(1.) використання вартісних показників.
1.проводиться економічний аналіз, розраховується рентабельність і прибуток, організовується фінансування
проекту, проводиться оцінка зведеної економічної ефективності проекту, виявлення резервів на непередбачені витрати,
прогнозування вартісних характеристик проекту на усіх фазах життєвого циклу.
2.складаються кошториси на кожний вид робіт, оцінюються резерви на непередбачені витрати, встановлюються
основні техніко-економічні і вартісні показники, формується система бухобліку, встановлюється порядок фінансування і
оплати виконаних робіт і послуг.
3.визначення вартості, розробка системи інформації та її відображення, управління резервами і непередбаченими
витратами, моніторинг фактичних витрат, аналіз відхилень від кошторису і бюджету, складання зведеної звітності про
стан вартості проекту.
створення БД про досвід реалізації проекту, розробка схеми функціональних обов'язків, аналіз результатів і досвіду
після завершення проекту і вироблення рекомендацій на майбутнє; вартісна оцінка життєвого циклу проекту;
функціонально-вартісний аналіз (ФСА).
(слайд)

4. Методи оцінки та прогнозування вартості проекту інформатизації

130
 Як і будь-яка цілеспрямована діяльність, розробка проекту ІС повинна здійснюватися за планом, а для правильного
планування ходу робіт необхідно уміти досить точно оцінювати тривалість і витрати на розробку проекту. В останні
входять: заробітна плата розробників, керівників проекту і допоміжного персоналу; вартість купованих і орендованих
програмних і апаратних засобів, що використовуються при розробці ІС; накладні витрати (оренда приміщень,
перепідготовка персоналу, утримання апарату управління тощо).
Для організації-розробника дуже важливо не занизити оцінку собівартості проекту, щоб гарантувати свою
прибутковість. У той же час, надмірне завищення вартості або термінів може налякати замовника, який в цьому випадку
може віддати перевагу іншому розробнику або взагалі відмовитися від створення ІС через її високу вартість.
Здійснити таке оцінювання істотно утрудняє велика кількість факторів і складний характер їх впливу на процес
створення ІС. До таких факторів, зокрема, можна віднести наступні:
- складність (розміри) ІС, що розробляється;
- особливості області застосування і архітектури системи (управління об'єктом, що функціонує в реальному

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

- чисельність і кваліфікація розробників;

- стабільність вимог замовника;

- наявність специфічних вимог до апаратних засобів.

У зв'язку з тим, що багато з перерахованих факторів досить невизначені і важко піддаються оцінюванню, дуже
часто керівники-практики заперечують можливість науково обгрунтованого прогнозування витрат на створення ІС або
вважають існуючі методи некорисними.

131
 Сказане особливо характерне для організацій-розробників, що знаходяться на низькому рівні технологічної
зрілості, оскільки в таких організаціях, зазвичай, або взагалі відсутня система накопичення статистичних даних,
необхідних для застосування того або іншого методу прогнозування, або дані, що є недостовірні. Звичайно, за таких
умов не може йти мови про отримання надійних оцінок навіть при використанні найдовершеніших методів.
Тому відомі методи оцінювання і прогнозування витрат на створення ІС розраховані на застосування в досить
зрілих в технологічному відношенні організаціях.
Яке ж місце в життєвому циклі проекту займає прогнозування витрат на створення ІС?
Як відомо, планування є діяльністю, що виконується на всіх стадіях життєвого циклу проекту. Первинні оцінки
ресурсів, необхідних для створення ІС, роблять ще при розробці стратегії автоматизації і оцінювання реалізованості
задуму. Оскільки на цих передпроектних стадіях звичайно бракує багатьох початкових даних, для оцінювання звичайно
використовують метод аналогії, спираючись при цьому на досвід створення інших ІС та інтуїцію. Очевидно, що
отримані оцінки, при цьому недостатньо точні, і тому при розробці великих проектів остаточне розв'язання питання про
виділення ресурсів на створення ІС звичайно відкладають на більш пізній час, коли вже є досить даних для
прогнозування витрат з достатньою для практики точністю. При правильно організованому технологічному процесі і
високій технологічній зрілості розробника дані, достатні для оцінювання з прийнятною точністю, вдається отримати до
завершення складання технічного завдання. Цим, зокрема, і пояснюється те, що в американській стандартній моделі
життєвого циклу (каскадній див тему 5) стадія планування безпосередньо слідує за розробкою технічного завдання.
Саме на цій стадії найширше застосовуються методи прогнозування часу і витрат, необхідного для створення ІС.
У ході планування на подальших стадіях раніше отримані оцінки уточнюють на основі додаткових даних, що
отримуються в ході проектування і реалізації ІС. В ідеалі, до моменту введення ІС в дію, при правильно організованому
накопиченні статистичних даних існуючі методи дозволяють досить точно прогнозувати витрати для найтривалішої
стадії - супроводу, яка також дорого коштує.

132
 До цього часу існує декілька підходів до оцінювання тривалості і витрат на розробку ІС, які знайшли застосування
на практиці. Як показали дослідження, основним чинником, що впливає на час і витрати, є складність ІС. У залежності
від способу обліку цього чинника в розрахункових моделях, їх можна умовно розділити на дві групи:
• найпростіші методи, засновані на оцінюванні загального числа операторів (рядків, команд) в початкових текстах
програм,
• методи, засновані на інших характеристики складності ІС.
Як приклад першої групи методів розглянемо так звану модель СОСОМО - Constructive Cost Model, а другої - метод
функціональних балів Function Point Analysis (FPA).
Модель СОСОМО
Починаючи з середини 1970-х років, в США постійно здійснюється збір статистичних даних про зовнішні техніко-
економічних показники розробок ІС, насамперед, що виконуються по держзамовленнях. Вони стали основою для ряду
досліджень з метою виявлення основних закономірностей, що дозволяють прогнозувати тривалість і витрати. Судячи з
публікацій, роботу по збиранню цих даних спочатку здійснювали в різний час різні групи дослідників, що отримували
фінансову підтримку від військового відомства через його різні управління. У цей час ця діяльність зосереджена в
рамках Інституту програмної інженерії (SEI), що є, як відомо, головним науковим центром.
Спочатку була запропонована наступна загальна модель для оцінювання трудомісткості проектів ІC [1985]:
Е = (а + bSc)m(Х), (20.1)
де Е - трудомісткість,
а, b, с - константи,
S - оцінка складності розроблюваної ІС, виражена в тисячах рядків початкового програмного коду,
m(Х) - нелінійна функція вектора інших параметрів проекту X.

133
 Однак незабаром з'ясувалося, що навіть у такому загальному вигляді неможливо побудувати єдину модель,
придатну для будь-якої ІС. Це пояснюється тим, що техніко-економічні показники для різних класів ІС
характеризуються дуже великим розкидом.
Тому Б. Боэмом [див. Боэм Б.У. Инженерное проектирование программного обеспечения. – М.: Наука, 1991. – 190 с.]
був запропонований удосконалений варіант моделі (20.1), що отримала назву СОСОМО (Constructive Cost Model). У
залежності від характеру проекту, в ній використовують різні значення параметрів. Для цього були виділені наступні
три класи ІС: прості, складні і середньої складності (проміжні). Прості системи порівняно невеликі за розміром,
характеризуються відсутністю жорстких обмежень, не містять принципово нових технічних рішень і розробляються в
умовах стабільних і чітко сформульованих вимог замовника. Складні ІС, як правило, є вбудованими у великі об'єкти,
функціонують в реальному масштабі часі, в них широко застосовуються нові методи і алгоритми, вони повинні
задовольняти жорстким обмеженням, а вимоги до них схильні до змін і уточнень в ході розробки. Проекти третього
класу займають проміжне положення.
Основне розрахункове співвідношення моделі, запропонованої Боемом, для трудовитрат (в людино- місяцях)
наступне:
Е=aі Sbi m(X). (20.2)
Значення параметрів аi, оцінені за відомими статистичними даними, в залежності від класу ІС, встановлюють
рівними 2.4, 3.0 і 3.6 відповідно для простих, середніх (проміжних) і складних систем. Параметру bi, надають значення:
1.05, 1.12 і 1.20.
Вектор Х містить 15 параметрів, а функція m(Х) є добутком 15 відповідних кожному з параметрів коефіцієнтів
трудомісткості. Передбачається, що в деяких усереднених умовах кожний коефіцієнт рівний одиниці. Вплив
відповідних факторів на трудовитрати враховують шляхом підбору значень цих коефіцієнтів. Фактори вибрані таким
чином, що їх взаємним впливом можна знехтувати. Їх можна звести в наступні чотири групи, що характеризують:
1. властивості ІС (вимоги до надійності, складність бази даних, загальна складність системи,
134
 2. властивості обчислювальної установки (наявність обмежень на час рішення задач і на пам’ять, а також
необхідність забезпечення переносимості програм на різні типи ЕОМ),
3. колектив розробників (наявність кваліфікованих проектувальників, досвід роботи в заданій предметній сфері,
наявність програмістів, досвід роботи з системою програмування і апаратурою),
4. технологія (використання передових методів розробки програм, застосування CASE-засобів, якість планування
робіт).
На основі накопичених статистичних даних для кожної з цих груп були розраховані діапазони значень відповідних
коефіцієнтів і розроблена методика їх визначення в умовах конкретних проектів.
Крім прогнозування трудовитрат, метод СОСОМО дозволяє оцінювати тривалість розробки ІС. Її розраховують за
наступною формулою:
Т=2.5EСi, (20.3)
де Т - тривалість в місяцях.
Значення параметра С, для простих, середніх і складних проектів встановлюють відповідно рівними 0.38, 0.35 і 0.32.
Ця модель була розроблена Б. Боемом на основі статистичних даних, накопичених в 1960-70 р.р. головним чином
фірмою TRW (розробником систем ракетно-космічної оборони). Виконана пізніше перевірка її на шести інших
сукупностях статистичних даних [1985] показала, що для різних вибірок від 17% до 67% оцінок, отриманих з її
допомогою, мають відносну погрішність не більше за 25%, тобто модель має точність, яку не завжди можна визнати
задовільною.
Ми не будемо докладно розглядати усі конкретні значення параметрів моделі СОСОМО, що використовуються для
прогнозування витрат на створення ІС. Їх можна знайти в літературі [Боэм Б.У. Инженерное проектирование
программного обеспечения. – М.: Наука, 1991]. Причин цьому кілька. Головна з них полягає в тому, що з часу перших
публікацій, присвячених цій моделі, пройшло досить багато часу, за який технологія проектування ІС значно змінилася
на краще. Тому ці дані напевно вже застаріли. У той же час в літературі відсутні відомості про уточнені значення
135
параметрів і структури методу СОСОМО, але є дані про те, що він як і раніше є основним при плануванні розробок на
замовлення Міністерства оборони США.
Наведені вище результати, що характеризують точність прогнозування, відносяться до раннього етапу
застосування цієї моделі в умовах, коли не враховувалися специфічні особливості фірми-розробника. За останні 10
років, в зв'язку з введенням в дію системи атестування технологічної зрілості організації-розробників, вже з'явилися
фірми, що характеризуються 4-5 рівнями зрілості. В таких фірмах повинна бути налагоджена своя власна система
накопичення і аналізу статистичних даних, що дозволяє діставати набагато достовірніші оцінки, ніж це робилося 10-15
років тому. Моделі прогнозування, засновані на методі, подібному СОСОМО, в цей час розповсюджуються на
комерційній основі і прив'язуються до специфіки організації-розробника. При цьому фірми не розкривають конкретні
значення параметрів моделі, оскільки це може виявитися на руку конкурентам.
Таким чином, модель СОСОМО, приблизно в дещо вдосконаленому вигляді, досить широко використовується в
США в організаціях, що характеризуються досить високим рівнем технологічної зрілості. Однак відомостей про
точність прогнозів, що отримуються і конкретних удосконаленнях методу в доступних джерелах немає. Можна
припустити, що вони є комерційною таємницею.
На теренах СРСР в 1978-86 р.р. під керівництвом В.В. Ліпаєва також проводились дослідження методів
прогнозування витрат на створення ІС і була розроблена модель, заснована приблизно на тих самих ідеях, що і
СОСОМО [Липаев В.В., ПотаповА.И. Оценка затрат на разработку програмных средств.- М.: Финансы и статистика,
1988], але яка базувалася на вітчизняному матеріалі. Основні удосконалення стосувалися складу факторів, що враховані
в моделі. Вона більш детальна, причому вплив деяких факторів враховується інакше, ніж в моделі Боема. Інших
дослідженнь аналогічного масштабу на теренах СРСР в цьому напрямі не велося. Залишки колективу, керованого В.В.
Ліпаєвим і що має знання і досвід у цій сфері, зосереджені в Російському НДІ інформаційних технологій і систем
автоматизованого проектування (РІТАП).

136
 Методу СОСОМО й аналогічним йому методам є властивими ціла низка недоліків, і ряд авторів піддають його
критиці. Основний недолік є наслідком того, що для оцінювання витрат і тривалості розробки необхідно мати оцінку
складності ІС, виражену через число команд або операторів програми. Основними аргументами проти використання цієї
характеристики складності наступні:
• точне число операторів програми стає відомим лише у кінці розробки, а розрахунки треба виконувати значно
раніше, після складання технічного завдання;
• написання програм є лише невеликою частиною всіх трудовитрат, і тому число операторів не характеризує їх
повністю;
• у разі використання декількох різних мов програмування складно підрахувати число операторів, особливо для
непроцедурних мов;
• далеко не завжди зрозуміло, як здійснювати підрахунок (наприклад, чи треба враховувати коментарі і оголошення
змінних тощо);
• не всі програми, що розробляються входять в комплект постачання (наприклад, програми, що забезпечують
відладку і випробування).
Тому були зроблені спроби відійти від числа операторів програми як міри складності ІС і використати інші
метрики. Одним з підходів, що набув досить широкого поширення є метод функціональних балів (Function Point Analysis
-FPA).
Метод функціональних балів (FPA)
Відомо, що до моменту завершення розробки технічного завдання на створення ІС в проектній документації є ряд
параметрів, значення яких характеризують складність системи.
До цих параметрів можна віднести, наприклад, число:
• класів інформаційних об'єктів,
• атрибутів інформаційних об'єктів,
137
 • функціональних задач (інформаційних і обробки),
• число вхідних і вихідних змінних кожної задачі.
Цей список може бути продовжений. Очевидно, що кожний з перерахованих параметрів якось характеризує
складність, тобто зі зростанням його значення, за інших рівних умов, складність, а з нею трудомісткість і тривалість
розробки ІС зростають. Питання тільки полягає в тому, яким чином агрегувати ці параметри в одному такому
показникові як трудомісткість.
У виборі одного з можливих способів їх агрегування і полягає сутність так званого методу функціональних балів
(Function Point Analysis - FPA). Уперше метод був запропонований в роботі [Albrecht A. J, Measuring Application
Development Prodactivity, on Proc. IBM Applications Development Symposium, GUIDE Int. and SHARE Inc., IBM Corp.,
Moneterey, CA. Oct. 14-17, 1979]. За своїм призначенням метод FPA призначений для більш вузького класу систем, ніж
метод СОСОМО. А саме, FPA орієнтований на системи, що містять у своєму складі досить складні бази даних.
У порівнянні з СОСОМО метод FPA має більш вузьку спрямованість і тому значенні, що він призначений тільки
для оцінювання складності ІС, а не трудомісткості або тривалості, тобто в ньому не враховуються фактори,
безпосередньо пов'язані з процесом розробки і реалізації, які враховує модель СОСОМО. По суті, метод FPA дозволяє
оцінити тільки значення параметра, яке можна було б підставити в формули (20.1) або (20.2) замість довжини програми
S.
Розглянемо найпростіший варіант цього методу.
В якості вхідних даних для оцінювання складності ІС, що розробляється, використовують наступні п'ять
параметрів:
• число форм вхідних повідомлень - Inp,
• число форм вихідних повідомлень - Out,
• число інформаційних задач - Inq,
• число головних файлів - Maf,
138
 • число інтерфейсів - Inf.
Порівнюючи цей перелік з попереднім, можна помітити схожість і деякі відмінності. Так, число головних файлів є
не що інше як число класів інформаційних об'єктів, що мають зв'язки з іншими класами типу 1:М. Тобто, в цьому
параметрі агреговано не тільки число класів, але і складність зв'язків між ними. Задачі обробки явно не представлені,
але легко пересвідчитися, що їх число непрямо відображене в кожному з параметрів, тобто додання цього параметра
тільки призведе до надмірності.
Складність системи оцінюють у так званих функціональних балах за наступною формулою:
FP =UFP  TСF, (20.4)
де перший співмножник характеризує логічну складність, виражену в балах, а другий є поправочним коефіцієнтом,
що враховує інші фактори, від яких залежить складність системи.
Логічну складність розраховують за наступною формулою:
UFP = а  Inp + b  Out + с  Inq + d  Mat + е  Inf, (20.5)
де значення кожного з коефіцієнтів, a, b, с, d, е, встановлюють у залежності від складності відповідного елемента ІС
(табл. 20.1).
Другий співмножник в (20.4) розраховують по формулі:
TCF =0.65 +0.01 • DI, (20.6)
де коефіцієнт DI (Degree of Influence) - це сума наступних 14 показників:
1. наявність і складність телекомунікації,
2. розподілена обробка,
3. особливі вимоги до якості,
4. ступінь використання ресурсів обладнання,
5. частота транзакції,
6. діалоговий режим введення даних,
139
 7. особливі вимоги до ефективності роботи кінцевих користувачів,
8. діалоговий режим оновлення даних,
9. наявність складних алгоритмів обробки,
10. можливість повторного використання компонентів системи,
11. простота розгортання системи,
12. зручність експлуатації,
13. переносимість на інші платформи,
14. простота супроводу.
Оскільки кожному з перерахованих показників проектувальник повинен присвоїти оцінку з діапазону від 0 до 5,
параметр D1 може приймати значення від 0 до 70, а коефіцієнт TCF - відповідно від 0.65 до 1.35.

Таблиця 20.1. Вагові коефіцієнти логічної складності

Елемент системи Міра складності елемента системи
Мала Середня Висока
Вхідне повідомлення 3 4 6
Вихідне повідомлення 4 5 7
Інформаційна задача 3 4 6
Головний файл 7 10 15
Інтерфейс 5 7 10
Як видно, склад чинників, що враховуються і спосіб їх обрахування досить суб'єктивний. Незважаючи на це,
численні дослідження показали, що оцінка складності, виражена функціональними балами, значно краще відображає
справжній стан речей, ніж кількість операторів програми. Проте, і тут ще є місце для вдосконалення моделі FPA. Хоча в
спеціально підібраних прикладах оцінка трудомісткості із застосуванням числа операторів в найгіршому випадку дала
відносну помилку 800%, а за методом FPA - " лише" 200%, це також є абсолютно незадовільним.

140
 Недосконалість моделі FPA досить добре видно навіть з приведеного вище переліку чинників, що враховуються
при розрахунку значення параметрів DI. Двократне врахування діалогового режиму як чинника, що впливає на
складність, явно відноситься до часів, коли процедури діалогової взаємодії було важко проектувати і реалізувати
програмно. Це свідчить про те, що розглянута вище модель FPA потребує вдосконалення. Поліпшений варіант цього
методу детально викладений у монографії [Symons, 1991].
Судячи з публікацій, метод FPA досить широко використовується по обидві сторони Атлантики. Існує Асоціація
користувачів методу (FPA Users Group), яка регулярно проводить робочі зустрічі й конференції, які сприяють обміну
інформацією між фахівцями і вдосконаленню методу. У Великобританії під егідою ССТА видана методична допомога
по застосуванню FPA для прогнозування витрат і тривалості розробки ІС. Все це свідчить про те, що цей метод постійно
удосконалюється і має важливе практичне значення.
Таким чином, судячи з розглянутих вище моделей, до теперішнього часу вже виявлено склад основних факторів,
що визначають тривалість, трудомісткість і вартість розробки ІС, а також вивчено характер їх впливу. Як правило,
залежності економічних показників від цих факторів порівняно прості, і для їх повного опису досить вказати значення
невеликого числа параметрів (найчастіше - одного, рідше - до трьох-чотирьох). Головна складність полягає в тому, щоб
оцінити ці параметри, тобто зробити калібрування моделі. Як показує практика останніх років, найточніші результати
прогнозування дає калібрування, що виконується всередині організації-розробника з урахуванням її особливостей і,
зокрема, характеру проектів ІС, на розробці яких вона спеціалізується. Однак для проведення такого калібрування
необхідно, щоб організація мала досить високу технологічну культуру і мала достатній обсяг накопичених статистичних
даних. Якщо ці умови не додержані, то доводиться задовольнятися результатами калібрування моделі, виконаними для
інших організацій, що може різко знизити точність прогнозування.
Іншими словами, головною умовою передбачуваності процесу створення ІС є висока технологічна культура
організації-розробника.
5. Методи і техніка управління вартістю проекту в умовах ринку

141
Самостійно!!

142
 У п р а в л ін н я в а р т іс т ю

О ц ін к а і п р о г н о з у в а н н я К ош торис і бю дж ет К онтроль вартості В икористання

вартості в а р т іс н и х п о к а з н и к ів

1. Е к о н о м іч н и й а н а л із
1. С т р у к т у р н а д е к о м п о з и ц ія р о б іт
2. С истем а кодуван ня 1. В изначен ня 1. Б а з и д а н и х п р о д о с в ід
- Р е а л ь н іс т ь в и к о н а н н я 2. П о л іт и к а р е а л із а ц ії п р о е к т у
2. Р е н т а б е л ь н іс т ь і п р и б у т о к 3. С кладанн я кош торису
- П лан уван ня витрат 3. П роцедури 2. С х е м и ф у н к ц іо н а л ь н и х
- П л а н к а п іт а л о в к л а д е н ь 4. С и с т е м а ін ф о р м а ц ії і її о б о в ” я з к ів
- П о в е р н е н н я і н в е с т и ц ій - О ц і н к а з м ін
4. Р у х г р о ш о в и х з а с о б ів в ід о б р а ж е н н я 3. А н а л із р е з у л ь т а т ів і д о с в ід у
- П рям і витрати 5. У п р а в л ін н я р е зе р в а м и н а п іс л я з а в е р ш е н н я п р о е к т у і
- Р у х г р о ш о в и х з а с о б ів з 5. Р езерви на неперед бачені витрати
6. О с н о в н і т е х н і к о - е к о н о м іч н і і непередбачені витрати в и р о б к а р е к о м е н д а ц ій д л я
врахуванням дисконтування - З м ін и п р о е к т у і п л а н ів м айб утнього
- А н а л із р и з и к ів в а р т іс н і п о к а з н и к и
7. С истем а б ухгалтерського - Р е к л а м а ц ії 4. В а р т іс н а о ц ін к а п о в н о г о
3. Ф ін а н с у в а н н я - М ож ливі ризики ж и т т є в о г о ц и к л у в ід к о н ц е п ц ії
4. З в е д е н а е к о н о м іч н а о ц і н к п р о е к т у 8. П о р я д о к ф ін а н с у в а н н я і о п л а т и
в и к о н а н н я р о б іт і п о с л у г - Р езерви д о л ік в ід а ц ії
5. О б с я г і н в е с т и ц ій в п р о е к т 6. М о н іт о р и н г ф а к т и ч н и х в и т р а т 5. Ф у н к ц іо н а л ь н о - в а р т іс н и й
- П о п е р е д н я о ц ін к а проти кош торису і бю дж ету а н а л із ( о п т и м із а ц ії з а г а л ь н о ї
- О ц і н к а н а ф а з і к о н ц е п ц ії 7. А н а л із в ід х и л е н ь в а р т о с т і)
- О ц ін к а п р и б а зо в о м у - Ін т е гр а л ь н і в ід х и л е н н я 6. К ом п”ю тер ні додатки
проектуванні - А н а л із к о ж н о г о в и п а д к у - П редставлен нн я дани х для
- Т е ж при детальном у - В ід х и л е н н я з а п р о ш л и й р іш е н н я п р и к л а д н и х з а д а ч
- О ц і н к а п іс л я в в о д у в п е р іо д
е к с п л у а т а ц ію - П лан / ф акт
6. Р езерв на непередбачені витрати 8. З в е д е н і зв іт и п р о с т а н в а р т о с т і
7. О б л і к ін ф л я ц ії проекту
8. П рогнозування 9. А н а л із в а р т іс н и х п о к а з н и к ів
- П о д о с л ід н и м д а н и м проекту
- Р озрахункові м етод и 10. К оригую ий вплив для
- В п р о ц е с і р е а л із а ц ії регулю ван ня вар тості
9. Е к о н о м ік о - с т а т и с т и ч н і м е т о д и

143
Лекція 6Б (тема 6) Управління ризиком

План
1. Сутність управління ризиком та його функції
2. Класифікація ризиків за різними ознаками

1. Сутність управління ризиком та його функції

144
 Формальні методи визначення, аналізу, оцінки, попередження виникнення, прийняття заходів щодо зниження ступеню
ризику
Ризик - вплив на проект і його елементи непередбачених подій, які можуть нанести певні збитки і перешкоджати досягненню
цілей проекту. Ризик характеризується трьома чинниками:
1. подіями, що негативно впливають на проект;
2. імовірністю появи таких подій;
3. оцінка збитків, нанесених такими подіями.
Підфункції управління ризиком:
- виявлення ризику;
- зниження міри ризику.
Виявлення ризику:
1.виявлення зовнішніх непередбачуваних подій;
2.виявлення зовнішніх передбачуваних, але невизначених подій;
3. виявлення внутрішніх нетехнічних подій;
4.виявлення внутрішніх технічних чинників;
5. юридичні і правові чинники.
Зниження міри ризику:
- страхування ризику;
- аналіз впливу;
- планування реагування на ризикові події;
- система реагування на ризикові події;
- використання інформації по ризиках.

145
 Ризику схильні передусім фінансовий, технічний, організаційний і соціально-політичний аспекти проекту. Управління
ризиком застосовується, якщо міра ризику є досить високою.
Слайд !!!

146
147
 Управління ризиком
Продовж ення рис.→

Виявлення ризиків

Зовнішні непередбачені Зовнішні передбачені (але Внутрішні (не Внутрішні технічні

події не визначені) події технічні) фактори фактори

1. Несподіване втручання
органів державного 1. Ринкові ризики з-за змін
- Джерел вартості 1. Зрив графіків робіт 1. Зміна технологій
регулювання - Затвердження ріш ень
- Стандарти і норми сировини
- Попиту - Нестача робочої сили 2. Виробництво робіт
- Експорт - Страйки - Якість
- Конкуренції
- Ціноутворення - Нестача матеріалів - Продуктивність
- Екологія - Ринкових цін
- Бажань покупців - Затримка поставок - Надійність
- Розміщення - Непередбачені умови на
2. Експлуатація площадці 3. Проектування
2. Стихійні лиха - Помилки в проекті - Відповідність
- Необхідність супроводу
- Зміни вимог замовників технічним умовам
Несподіваний зовнішній - Відповідність проекту
3.
- Безпека - Нереальність планів - Імовірність змін
вплив - Недоробки
- Екологічні - Зміна керівництва та ін. 4. Технологічні ризики
- Соціальні 3. Валютний курс
4. Інфляція
- Економічні 2. Переривання фінансування
Система податків
- Технічні
Соціальні і екологічні
3. Перевищення витрат через
Нездоланні обставини і фактори
4. - Виконавців
невдачі - Постачальників Ю ридичні і правові фактори
- Політична - Замовника
нестабільність
1. Ліцензії
- Банкротство
2. Патентні права
- Порушення контрактів Схема управління ризиком (частина 1) 3. Помилки контрактів
і ін 4. Зовнішні позоки
5. Внутріш ні позови
6. Форс-мажор

148
 Управління ризиком
Продовження рис.→

Зниження ступеню ризику

Страхування ризику Аналіз впливу Планування реагування на Система реагування на

ризикові події ризикові події

1. Приямий збиток власності

- Автомобільно-дорожні 1. Основи (базис)
- Стан зовнішнього 1. Розподіл ризиків 1. Визначення
випадки Перегляд з метою зниження політики/процедури
- Обладнання оточення
- Внутрішні основні ступеню ризику
- Матеріали - робіт 2. Відповідальність
цінності
- Власність контрактора - бюджета 3. Модель ризику
2. Перевірка: внутрі чи поза - графіків - Базисна
2. Непрямі збитки - специфікації - Детальна
- Затрати на проектом
- якості
переміщення Моніторинг і огляд
3. Ступінь невизначеності і
- Перестановка 2. Перенесення ризиків на 4.
обладнання надійності
- Діаграми впливу других учасників Система регулювання
- Втрата арендної плати - контракті
- Перериви в роботі - Оцінка імовірності
ризиків - страховка
- Ліквідаційні втрати - зобов”язання
- Можливість розподілу
- Збільшення
фінансування ризиків
- Моделювання ризиків 3. Планування резервів
- засобів
Юридична - Оцінка чутливості
3.
4. Оцінка можливих збитків - часу
відповідальність - реакції на крайній Використання даних по
5. Варіанти життєвого циклу ризикам
випадок
4. Персональне страхування - відповідальність на
випадок припинення 1. Бази даних по минулому досвіду
проекту 2. Поточна база даних проекту
3. Постпроектна оцінка
4. Непередбачені події 4. Архів
Схема управління ризиком (частина 2) 149
Лекція 6В (тема 6) Управління персоналом

План
1. Сутність управління персоналом та його функції
2. Адміністративні аспекти управління персоналом
3. Регулювання відносин і взаємодії учасників та членів команди проекту

1. Сутність управління персоналом та його функції

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

150
1.Адміністративні;
2.Регулюючі взаємовідносини і взаємодії.
Кожна з цих груп включає розв'язання питань, пов'язаних з:
- службовими відносинами;
- оплатою праці;
- трудовим законодавством і регулюванням;
- учасниками проекту;
- членами команди проекту;
- самої команди проекту.

151
 Управління персоналом

Адміністративні аспекти Регулювання відносин і взаємодія

Службові Оцінка і оплата Трудове Зовнішні Члени Команда

законодавство і учасники команди
відносини праці проекту
регулювання проекту проекту

1. -Пошук і відбір 1. Посадові

1. Внутріформові 1 Вище 1 Лідерство
кандидатів,прийо інструкції і 1 Взаємозв”язки
м на роботу обов”язки правила і керівництво 2 Створення
вимоги 2 Лінійні/ внутрі команди команди
2. Навчання (обмін
персоналу 2. Оцінка функціональні 3 Стимулювання
2. Рівні права і керівники інформацією) команди
3 Робочі контакти виконання 2 Мотивування
можливості 3 Обслуговуючий 4 Прийняття
4 Планування 3 Взаємні поради і
просунення по 3. Регулювання персонал і рішень з участю
Арбітраж допоміжний консультації команди
службі оплати праці 3.
(вирішення персонал 4 Взаємодопомога і 5 Система
5 Планування взаємовиручка
трудових ресурсів Регулювання трудових спорів 4 Штатні заохочень
4. 5 Делегування
і конфліктів) працівники команди
6 Удосконалення льгот і повноважень
організації 5 Супільність, 6 Регулювання
заохочень 6 Спільне вирішення
причетна до конфліктів
спільної роботи проблем
7 Діловодство і проекту 7 Організаційна
6 Персонал 7 Персональні політика і
ведення заохочення
замовника психологічний
документації 8 Публічне визнання
7 Співробітники клімат
надзору і власного вкладу і 8 Обмін
інспекції заслуг інформацією з
8 Захисники 9 Влада, вплив групами
оточуючого 9 Виконання
середовища
9 Перевіряючі
відповідність
проекту
вимогам закону
152
Лекція 7 (тема 7) Управління контрактами і забезпеченням проекту

План
1. Сутність управління контрактами і забезпеченням проекту та його функції
2. Методи і моделі управління контрактами

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

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

154
 Управління контрактами і
забезпеченням ресурсами

Цілі і задачі Системи Визначення Процес Контроль за Оцінки по

інформації вимог в придбання і виконанням заверш енню
забезпеченні забезпечення контрактів контрактів
1. Описання робіт і
ресурсів, щ о 1. Джерела інформації
- внутріш нє 1. Трудові ресурси 1. 1. Виділення засобів
вимагаю ться (фірми) М етоди придбання - Визначення 1. Оцінка
- Специф ікації - зовніш нє - Реклама ефективності
2. Поставки порядку оплати
- Зв”язки - Запрош ення - Обмеження забезпечення
декомпозиції робіт і 2. Невистачаюча - Переговори проекту
інформація 3. Послуги фінансування
контрактів по їх 2 - Придбання
забезпеченню Відбір джерел 2. Оповіщ ення 2. Оцінка виконання
2. Стратегія 3. Додаткова забезпечення контрактів
інформація постачальників
- Ф ірми замовника 3. ресурсами про початок робіт
- Проекту Визначення типу
3. Оточення проекту 4. контрактів 3. Контроль
- внутріш нє Оформлення виконання
- зовніш нє документації для зобов”язань
4. Альтернативи 5. тендерів і покупок
- можливі 6. Запрош ення на торги 4 Ф інансовий
варіанти і відбирання Відповіді на контроль
кращ их 7. пропозиції
5. Аналіз ризиків 8. Оцінка пропозицій 5. Зміни контрактів
- визначення Аналіз контрактних
ризиків і збитків 9. ризиків 6. Спори і
- оцінки Проведення розбіжності по
прийнятного 10. переговорів контракту
ступеню ризику 11. Заключення контрактів
Протести по 7. Заверш ення
відхиленим контракту
пропозиціям

155
 Лекція 8 (тема 8) Автоматизація управління проектами

План
1. Мета автоматизації та призначення інформаційної системи управління проектами
2. Вимоги до інформаційної системи управління проектами
3. Базові функціональні можливості системи для управління проектами

4. Короткий аналітичний огляд пакетів управління проектами

5. Впровадження АІСУП

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

Управління проектами (УП) – одна з найбільш складних та трудомістких областей управлінської діяльності. Поясненням цьому є
наступне:
 складність логіки розвитку (особливо це стосується складних проектів) і, як наслідок,
 постійні зміни у взаємозалежності різних елементів проекту;
 складність утримати все це в пам’яті, наочно уявити, відслідковувати, аналізувати та коригувати на папері.
Як і будь-який процес управління, діяльність по УП супроводжується обробкою даних про ті елементи проекту, які
виділені для управління. Зважаючи на складність УП об’єми інформації, яку необхідно збирати, обробляти та
аналізувати учасникам проекту, можуть бути надзвичайно великими.
Тому основну мету автоматизації УП можна сформулювати як підвищення продуктивності праці, пов’язаної зі
збором, обробкою, аналізом даних про хід виконання проекту, проведенням необхідних аналітичних і прогнозних
розрахунків, необхідних для прийняття ефективних рішень.
Таким чином, автоматизована інформаційна система УП (АІСУП) – це єдиний комплекс, що поєднує програмні і
технічні засоби обробки і передачі інформації, методи УП і інші елементи які забезпечують його функціонування та
підвищення ефективності усіх процесів.
156
 Кожна інформаційна технологія підтримує певні методи управління. Метод управління визначає те, на що і як
потрібно діяти керівникові, щоб досягти очікуваних результатів.
Найбільш поширеними є три великі групи методів управління:
а) ресурсами
б) процесами
в) корпоративними знаннями (комунікаціями)
Перша група
Модель цих методів представляє організацію як систему ресурсів (фінансів, матеріальних запасів і кадрів), що належать власникам –
юридичним особам, структурам, підрозділам, фізичним особам.
Усі процеси описуються як проводки, які відображають рух ресурсів між власниками. Основна мета управління для
цього методу є забезпечення ресурсами та контроль за ними. Приклад, система бухгалтерського обліку.
Друга група розглядає організацію як систему бізнес-процесів. Тут центральними поняттями є процес, функція, дані,
подія.
Основна мета управління для цих методів – забезпечення координації подій і функцій.
До другої групи відносяться такі методи як управління якістю (TQM –стандарт ISO9000).
До цієї групи відносяться і управління проектами (сімейство стандартів PMI), але лише в тій частині, в якій ці
проекти можна вважати типовими доведеними до рівня технології .
Методи управління підтримуються ПЗ, яке відоме як система управління проектами, документооборотом,
технологічними процесами.
Третя група – уявляє організацію як систему невеликих колективів співробітників, які вирішують загальну задачу, а в
ролі організаційних факторів виступають корпоративні знання та ефективні комунікації.
Основна мета управління – забезпечення координації, комунікації та швидкого пошуку інформації для самостійного
прийняття рішення.
Ця група методів управління зараз бурхливо розвивається і має назву «управління знаннями».
До цієї групи методів відносяться і методи управління складними нестандартними проектами (вони базуються на
сімействі стандартів PMI). В таких проектах критичним чинником управління є проектні комунікації та кваліфікаційний
рівень проектної групи.
У кожного методу є своя область ефективного застосування, але існують випадки, коли використання одного просто є
неможливим без використання іншого.
157
 Так в інформаційному менеджменті є присутніми кожні з цих методів.
Таким чином, основним призначенням АІСУП є переведення на машинну обробку процесів управління проектами.
Основним призначенням АІСУП є переведення на машинну обробку процесів управління проектами.
Базові риси ІСУП зумовлені специфікою характеристик проекту:
1. Оскільки проект - це одноразова сукупність дій, направлених на досягнення унікальної мети (або досягнення
комплексу цілей), то ІС УП створюється для кожного проекту і є тимчасовою системою.
2. Реалізація проектів пов"язана з виконанням унікального комплексу дій. Таким чином, календарні і фінансові плани
базуються, здебільшого, на прогнозних і експертних оцінках, ніж на попередньому досвіді.
3. Проект здебільшого здійснюється при обмеженнях у часі, обмеженому бюджеті, дефіциті ресурсів. Звідси ІСУП
повинна підтримувати алгоритми вирішення конфліктних вимог.
4. Координоване виконання взаємопов"язаних дій. Весь об"єм робіт проекту розділяється на пакети робіт і задачі, які
легко піддаються управлінню і часові та ресурсні параметри яких можуть бути оцінені з високою ступінню точності.
Таким чином функція контролю над проектом базується на оцінці результатів виконання задач, а не на порівнянні
об"ємів робіт, за певний календарний період (міс., кв., рік)
5. Реалізація проекту поєднує зусилля і використання ресурсів різних відділів і організацій. ІСУП повинна
забезпечити підтримку ділових стосунків між виконавцями, тимчасово об‘єднаними в команду.
6. Проект має життєвий цикл, який включає стадії : концепція, розробка, реалізація, завершення. Різні стадії
життєвого циклу потребують виконання різних управлінських функцій. Таким чином ІСУП є динамічною системою, яка
змінюється в залежності від стадії проекту.
7. Проекти не є повністю незалежними від бізнес-оточення, яке включає як інші проекти, які здійснюються
організацією, так і поточну виробничу діяльність. Таким чином ІСУП є відкритою системою, яка має інтерфейси з
іншими системами.
Управління проектами – інтегрований процес. Дії (або їх відсутність ) в одному напрямку зазвичай впливають і на
інші напрямки. Такий взаємозв’язок примушує балансувати між задачами проекту – часто поліпшення в одній області
може бути досягнуте лише за рахунок погіршення в іншій. Для кращого розуміння інтегрованої природи Управління
Проектами розглянемо її місце серед інформаційних систем, що підтримують поточну управлінську діяльність сучасної
організації.
В сучасній організації, зазвичай функціонує ціла низка інформаційних систем, які забезпечують підтримку поточної
управлінської діяльності. Керівник проекту може використати ту чи іншу інформацію з корпоративних ІС. Але в них, в

158
основному, дані структуровані для підтримки діяльності функціональних керівників,, тому є надмірними і, зрештою,
непотрібними для менеджера проекту.
Таким чином основними принциповими відмінностями ІСУП від корпоративних систем є наступні:
1. Якщо корпоративні ІС в основному підтримують окремі функціональні підрозділи, то ІСУП об"єднує дані з різних
підрозділів і організацій, що відносяться до конкретного проекту.
2. В корпоративних системах цикл збору і аналізу інформації та видачі звітності прив"язаний до календарного
періоду (місяць, квартал, рік). В ІСУП управлінська інформація збирається, зберігається і аналізується відносно ступеню
досягнення цілей проекту (задач, етапів, віх).
Тому створення ІСУП на основі лише існуючих функціональних ІС має низку недоліків :
•низька оперативність отримання і якість інформації внаслідок надлишкових даних;
•низька ступінь інтеграції інформації внаслідок різнорідності ІС, які використовуються різними відділами (тим паче
різними організаціями), що приймають участь у проекті.
Переводу на машинну обробку підлягають такі процеси:
- планування робіт;
- контроль за ходом виконання проекту;
- аналіз ходу виконання плану;
- коригування плану робіт.
Тобто автоматизації підлягають основні напрямки (функції) управлінської діяльності.
Можливості застосування методів УП є досить широкими та різноманітними.
Кожний проект є унікальним і кожна організація, що створюється для його виконання, розробляє власну політику та
процедуру виконання проекту.
2. Вимоги до інформаційної системи управління проектами
До чинників, що впливають на підходи і, відповідно, вимоги до АІСУП відносяться:
- стиль управління проектом;
- потреби робочої групи проекту;
- вимоги вищих керівників.
1. Ці аспекти необхідно детально розглянути, перш ніж визначитись, яка необхідна АІСУП. Існують чотири категорії стилей управління:
2. Детальне знання проекту та високий рівень контролю;
3. Детальне знання проекту та невисокий рівень контролю.
4. Невисокі знання деталей проекту та невисокий рівень контролю;
159
 5. Невисоке знання деталей проекту та значний рівень контролю.
Перший стиль вимагає, щоб план проекту був розроблений дуже детально, щоб всі ці деталі вводились в базу даних системи та були доступні у будь-який час.
Вимогою є, щоб робоча група проекту здійснювала поточний контроль за роботою через короткі проміжки часу. Ступінь деталізації залежить від масштабів та
складності проекту.
Другий стиль вимагає, щоб план проекту був розроблений досить детально, і щоб всі ці деталі були введені в базу даних, але не передбачає, щоб подробиці
плану були легко доступними.
Менеджер проекту може не аналізувати всю цю інформацію, а вивчає її тільки вибірково. При необхідності він повинен отримати детальну інформацію. Такий
стиль надає більше свободи робочій групі при розробці своїх планів.
АІСУП не повинна бути надто чутливою.
Третій стиль не потребує розробки дуже деталізованого плану проекту для введення в БД або забезпечення доступності інформації. Цей стиль також надає
робочій групі більше свободи в розробці власних планів такий підхід називається управління «по відхиленням» АІСУП також не повинен бути надто чутливою.
Четвертий стиль є не зовсім звичайним. Він навпаки вимагає, щоб план проекту не розроблявся дуже детально.
Менеджеру проекту необхідно забезпечити рівень контролю за БД та легку доступність інформації. Така система буде зручною для менеджера проекту, якому
необхідно керувати деталями і якому необхідно надавати багато звітів про стан справ вищим керівникам різного рівня. Ці звіти повинні бути довільними за своїм
характером.
В цьому випадку АІСУП повинна бути виключно чутливою.
Ефективність роботи менеджера залежить від його здатності здійснювати контроль через заздалегідь внесені відповідні зміни.
При визначенні вимог до ІС УП (конкретної) необхідно чітко визначитись на який стиль слід орієнтуватись і для вирішення яких задач буде потрібна АІСУП.
А для цього керівникові необхідно проаналізувати характер діяльності власної організації з точки зору можливості і доцільності застосування проектної форми
планування і управління. Яка діяльність може плануватися у вигляді проектів? Наскільки детально необхідно планувати і контролювати проекти? Тільки після цього
можна з упевненістю сказати наскільки прийняте рішення про використання системи для управління проектами є обгрунтованим.
Потім необхідно визначитися з класами функцій планування і управління, які повинна реалізувати ІСУП:
• тільки планування або планування і контроль ходу проекту;
• планування і контроль лише термінів виконання робіт;
• планування і контроль фінансових вкладень без детального планування використання ресурсів;
• детальне планування використання ресурсів;
• багатопроектне управління.
Корисно заздалегідь визначити:
1. Приблизні вимоги до розмірності проектів і детальності планування, організаційної структури управління і звітності.
2. Скільки проектів буде вестися одночасно і чи будуть вони взаємозалежними?
3. Яка приблизна кількість задач в одному проекті?
4. Скільки видів ресурсів буде задіяно в одному проекті і як будуть розділятися ресурси між проектами?
Важливим є також міркування, пов’язані з кваліфікацією персоналу, який буде використовувати ІСУП.
160
 Тільки з урахуванням усього вищесказаного можна чітко сформулювати вимоги до інформаційної системи автоматизації управління проектами.
Після аналізу всіх вимог необхідно прийняти рішення про вибір ІСУП з тих, що пропонує ринок, або при відсутності на ринку системи, яка відповідає вимогам–
про розробку власної :
Декілька зауважень!
1. Розробка власної обійдеться значно дорожче (на 1-2 порядки)
2. Сам процес розробки досить тривалий і відповідно результат від використання такої системи відстає у часі від моменту вкладення коштів, оскільки, будь-
який проект обмежений у часі, це є суттєвим.
3. Процес розробки досить складний і трудомісткий процес. Він вимагає залучення різноманітних фахівців.
4. Розробка нової ІС сама по собі є проектом і відповідно вимагає управління.
Тому, розробка ІС із застосуванням готових ПЗ (як власними силами, так із залученням сторонньої фірми) є більш доцільним, крім випадків, коли фірма сама є
розробником ПЗ.
Основною проблемою є вибір програмного засобу, який відповідає вимогам. Крім вимог, що розглянуті раніше, доцільно враховувати наступне.
У організації можна виділити принаймні три рівні, на яких відбувається управління проектами:
1. Рівень вищого керівництва, на якому відбувається визначення цілей і задач підприємства, приймається рішення про фінансування, оцінюється
пріоритетність проектів.
2. Стратегічний рівень, що складається з професіоналів по управлінню проектами, що займаються плануванням і контролем корпоративних проектів. Як
правило, цей рівень представляється вельми малою кількістю людей, основний обов’язок яких – саме управління проектами, і які в своїй роботі спираються
на програмне забезпечення по управлінню проектами. Місія подібних професіоналів є ключовою в організації. Вони працюють як група підтримки
управління проектами, навіть якщо офіційно їм не дають таку назву.
3. Рівень операцій, для якого робота з програмним забезпеченням по управлінню проектами є другорядною. Це відповідальні за проекти на місцях, менеджери
проектів, керівники груп. На рівні операцій, звичайно ж, потрібно мати інструмент з управління і контролю за проектом, але на непостійній основі.
Наприклад, менеджер проекту може приділити цьому увагу лише декілька годин в місяць.
Безсумнівно, потрібна інтеграція програмного забезпечення трьох рівнів для підтримки інформаційних потоків в організації..
Вимоги до інтегрованої системи по управлінню проектами універсальні і не залежать від специфіки організації. Модель обміну даними можна спрощено
представити таким чином:
Потік даних по проекту йде у напрямі знизу вгору, від рівня операцій до стратегічного рівня, на якому відбувається узагальнення відомостей, що
поступили, і вже на рівні вищого керівництва дані поступають у вигляді звіту, який представляє дані по проекту в досить загальному вигляді.
Кожний рівень управління характеризується своїми специфічними вимогами до програмного забезпечення УП.
Таблиця. 1 Вимоги до програмного забезпечення по управлінню проектами.

Рівень вищого керівництва Стратегічний рівень Рівень операцій

• Простота в застосуванні • Можливість інтеграції з іншими • Простота
• Можливість отримувати засобами (додатками) використання
демонстраційні звіти • Засоби для згортання даних по • Простота вивчення
161
 • Потужні можливості проекту (представлення звітів • «Прозорість»
узагальнення відомостей керівництву) і поглибленню для процедур введення
• Засоби для інтеграції даних планування на більш детальному даних
з інших програмних рівні • Наочність
додатків • Засоби для контролю за
• Процедури для планування реалізацією проекту
зверху вниз • Гнучкість при настроюванні
вихідних форм звітності
Рівень вищого керівництва
Для даного рівня (насправді у вищого керівництва не завжди є бажання працювати з системами управління проектами) самою головною вимогою є простота
використання. Керівництво, якщо у нього з’явиться потреба працювати з ПЗ УП, буде робити це не дуже часто, і навряд чи захоче витрачати на вивчення системи більше
2-3 днів.
Наступною важливою особливістю є презентаційний характер форм надання інформації по проектах, оскільки керівник може використати програмне
забезпечення для підготовки презентацій для клієнтів. Засіб для надання інформації в самому загальному вигляді на одному листі в формі діаграми Гантта або кривій
витрат найбільш стандартна вимога. Керівництво не буде витрачати час на введення даних, так що повинна бути можливість для отримання даних з інших джерел, в
тому числі з інших рівнів управління проектами. У той же час може знадобитися засіб для планування зверху вниз, якщо треба буде деталізувати побудований
керівництвом план на іншому рівні управління.
Стратегічний рівень
Зазвичай вимога легкості вивчення і «доброзичливий інтерфейс» не згадується в запитах на програмне забезпечення фахівців-професіоналів. Базовими є
потужність засобів часового аналізу термінів, ресурсного планування, вартісного аналізу і аналізу ризиків. Адже вважається, що користувач не тільки знає, як викликати
будь-яку процедуру системи, але і розуміє закладений в неї алгоритм. Крім того, дуже часто потрібно інтегрувати дані про проекти з даними з інших додатків,
наприклад, з бухгалтерських програм і т.д. Обов’язково повинен бути передбачений засіб об’єднання декількох проектів для узагальненого аналізу, управління,
контролю.
Важливою є можливість введення реальних даних і порівняння попередніх планів з фактичним виконанням для внесення коригуючих операцій. Гнучка звітність
потрібна також, оскільки менеджерам-професіоналам доводиться настроювати звіти не тільки для себе, але і для співробітників, які працюють з проектом на інших
рівнях управління.
Рівень операцій
Вимога «простоти використання» при роботі з системою завжди виставляється під номером один у списку вимог. Співробітники не можуть витрачати дуже
багато часу для підтримки даних по проекту в актуальному стані. Найчастіше менеджери проектів скаржаться на те, що багато часу у них йде на введення даних по
проекту. Однак можливість надання звітів в графічному вигляді є важливою для координації дій виконавців проекту, що входить у безпосередні обов’язки менеджера
проекту.

Важливо не робити узагальнень при складанні списку вимог і не намагатися знайти такий засіб, який задовольняє
усім запитам. Не можна коректно визначати пріоритети, розглядаючи вимоги різних рівнів. Звичайно, можна виходити
з найбільш високих запитів стратегічного рівня, припустивши, що користувачі інших рівнів вивчать і будуть
використовувати лише частину функцій системи, але таке рішення буде дорогим і обтяженим.
162
 3. Базові функціональні можливості системи для управління проектами
До рішення про придбання програмного забезпечення для УП в різних організаціях приходять по різному:

 На основі рекламної інформації продавця систем,

На основі порівняльних оглядів ПЗ, що публікують в комп"ютерних виданнях .
Корисно знати базові функціональні можливості систем. Основні з них представлені в таблиці.
Таблиця. Базові функціональні можливості системи УП
Функціональна Вимоги до реалізації
характеристика
1.Засоби опису комплексу • Опис глобальних параметрів планування проекту
робіт проекту, зв’язків між • Опис логічної структури комплексу робіт
роботами і їх часових • Багаторівневе представлення проекту
характеристик • Призначення часових параметрів планування задач
• Підтримка календарів окремих задач і проекту загалом
2.Засоби підтримки інформації • Організаційна структура виконавців
про ресурси і витрати по • Ведення списку наявних ресурсів, номенклатури матеріалів
проекту та призначення і статей витрат
ресурсів і витрат окремим • Підтримка календарів ресурсів
роботам проекту • Призначення ресурсів роботам
• Календарне планування при обмежених ресурсах
3.Засоби контролю за ходом • Порівняння планових і фактичних показників і
виконання проекту. прогнозування ходу майбутніх робіт
4.Графічні засоби • Діаграма Гантта (часто суміщена з електронною таблицею і
представлення структури що дозволяє відображати різну додаткову інформацію)
проекту, засоби створення • PERT діаграма (сіткова діаграма)
різних звітів по проекту • Створення звітів, необхідних для планування і контролю

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

163
 • можливість призначення часових характеристик (максимальна тривалість окремої задачі, максимальна тривалість проекту, одиниці часу, доступні в системі
(рік, місяць, тиждень, день), виділення задач-віх, встановлення резервів часу (повний, вільний), можливість системи автоматично встановлювати тривалість окремих
задач, можливість прив’язати тривалість задач до об’єму призначених ресурсів);
• зв’язки між задачами (максимальна кількість попередніх і подальших задач, допустимі типи зв’язків, допустимі типи затримок/перекриття);
• максимально допустима кількість задач в проекті, довжина імені задачі, можливості кодування, можливість автоматичного перерахунку, багаторівневе
представлення проекту.
2. Засоби підтримки інформації про ресурси і витрати по проекту та призначення ресурсів і витрат окремим роботам проекту.
інформація про ресурси (максимальна кількість ресурсів на проект, можливість опису різних типів ресурсів (матеріально-технічних, персоналу, статті витрат,
номенклатура матеріалів), підтримка ресурсів з фіксованою вартістю і ресурсів, вартість яких залежить від тривалості їх використання, підтримка інформації про
необхідні і доступні об’єми ресурсу, можливість задання нормального і максимального об’єму ресурсу, можливість задання змінного об’єму ресурсу, можливість
задання індивідуальних календарів ресурсів);
призначення ресурсів задачам (максимальна кількість ресурсів на задачу, можливість задання часткового використання ресурсів, можливість задання затримок
при використанні ресурсу);
календарне планування при обмежених ресурсах (виділення переобтяжених ресурсів і задач що їх використовують, розв’язання ресурсних конфліктів,
автоматичне/командне вирівнювання ресурсів, вибір ресурсів для вирівнювання, вирівнювання з урахуванням пріоритетів задач, вирівнювання з урахуванням обмежень
за часом або з урахуванням обмеження на ресурс, оптимальність отриманих планів).
3. Засоби контролю за ходом виконання проекту:
засоби відстеження стану задач проекту (фіксація плану розкладу проекту, засоби підтримки фактичних показників стану задач (процент завершення));
засоби контролю за фактичним використанням ресурсів (бюджетна кількість і вартість ресурсу, фактична кількість і вартість ресурсу, кількість і вартість
ресурсів, необхідних для завершення роботи);
засоби вартісного аналізу проекту і аналізу на основі виконаних об’ємів робіт.
4. Зручні графічні засоби представлення структури проекту (діаграма Гантта, сіткова діаграма, ієрархічна діаграма проекту), а також засоби створення різних
звітів по проекту.
Діаграма Гантта (відображення критичного шляху, розрахункових і фактичних дат початку і закінчення робіт, резервів робіт, можливість зміни часової шкали,
відображення поточної дати, відображення складових задач, відображення додаткової інформації);
PERT діаграма (відображення критичного шляху, розрахункових і фактичних дат початку і закінчення робіт, тривалості, резервів робіт, відображення багатьох
рівнів деталізування задач, можливість задання різних типів сіткової діаграми, ручне і автоматичне розміщення робіт і зв’язків, визначення додаткової інформації);
засоби створення звітів (звіти за станом виконання розкладу, звіти по ресурсах і за призначенням ресурсів, профілі завантаження ресурсів, звіти по витратах
(можуть включати вартість окремих задач, деталізація вартості задач по ресурсах, вартість ресурсу по задачах, заплановану і фактичну вартість), звіти по грошових
потоках, звіти для аналізу фактичного стану виконання задач проекту і порівняння із запланованим).
Крім того, повинні бути враховані наступні додаткові можливості при виборі системи автоматизації управління проектами:
 сортування даних (максимальна кількість критеріїв, сортування по кодах задач і датах);
 критерії відбору даних (виключаючий і виділяючий відбір);
 можливості друку (типи принтерів, плоттер, багатосторінковий звіт);

164
  засоби обміну даними (підтримка технології клієнт/сервер, стандартів SQL(Snruktured Query Langueage - стандартна, структурована мова побудови запитів
до баз даних) і ODBC (Open Data Connectivitdy - стандарт доступу до баз даних різних форматів), інтеграція з ресурсами Web (всесвітня мережа, побудована
за технологією Internet), імпорт/експорт (ASCII- формат структурованого текстового файлу, dBase, Lotus, інші системи для управління проектами );
 робота в мережі з декількома проектами (багатопроектне планування, об’єднання проектів, зв’язок проектів, максимальна кількість пов’язаних проектів,
спільне ресурсне планування);
 мови програмування і розробки макровизначень.
Важливим для майбутнього користувача є простота вивчення і використання системи, а також якість супутньої документації, додаткової консультаційної
підтримки цієї системи на ринку.
Як будується інтегрована система по управлінню проектами?
Вибір програмного забезпечення по управлінню проектами зазвичай залежить від того, з якого рівня виходила ініціатива. Тому типовою є ситуація, коли самий
активний рівень нав’язує іншим програмне забезпечення, що відповідає безпосередньо його вимогам.
Переваги та недоліки різних варіантів вибору ПЗ УП
1. Вибір виконується керівництвом
За Проти
 Впровадження швидко просувається • Керівництву можуть бути не відомими запити
 Методи впровадження підтримуються нижчих рівнів
керівництвом • Система може буде неефективною для роботи
 Завдяки підтримці легко знаходять фінансові і менеджерів-професіоналів
людські засоби для впровадження
2. Вибір виконується на стратегічному рівні
За Проти
 Найбільш вірогідно, що продукт, буде достатньо • Може виникнути потреба в інтенсивному
функціональним тренінгу з ПЗ
 Експерти з управління проектами в компанії зможуть • Для реального використання продукту
надавати рекомендації користувачам інших рівнів доведеться вводити багато даних на інших
 Система буде достатньо вдало інтегрованою з рівнях
іншими програмними продуктами

3. Вибір виконується на рівні операцій (демократичний підхід)

За
 Обрана система є легкою у застосовуванні
 Велика кількість користувачів вже
використовує систему, зазвичай приймається
рішення про поставку інтегрованої системи
управління проектами
 Оскільки система не є
багатофункціональною, вона скоріше всього
Проти
• Програмне забезпечення низького рівня, яке не
задовольняє вимог стратегічного рівня і рівня
вищого керівництва
• Оскільки програмне забезпечення нав’язане
стратегічному рівню, з його боку буде
створюватись опір
165
 дешева • Малофункціональне програмне забезпечення
буде інтегруватися з іншими програмами, що
призведе до додаткових зусиль і витрат фінансів

Який з підходів найбільш вдалий? Ніякий оскільки у кожному з них доводиться жертвувати потребами членів рівнів управління, які
не беруть участі у виборі. Схема вибору програмного забезпечення по управлінню проектами в організації складається з наступних кроків:
• Аналіз вимог,
• Аналіз ринку,
• Вибір програмного забезпечення.
4. Короткий аналітичний огляд пакетів управління проектами
Розглянемо існуючі на сьогоднішній день на ринку системи управління проектами через призму розглянутих
вимог.
Microsoft Project
Microsoft Project є на сьогоднішній день самою поширеною у світі системою УП. У багатьох західних компаніях MS Project став звичною добавкою до Microsoft
Office навіть для рядових співробітників, які використовують його для планування графіків нескладних комплексів робіт.

Відмінною особливістю пакету є його простота. Розробники MS Project не прагнуть вкласти в пакет більш складні
алгоритми календарного або ресурсного планування. У той же час значна увага приділяється використанню сучасних
стандартів, які дозволяють ефективно інтегрувати пакет з іншими додатками. Наприклад, підтримка стандартів ODBC
(Open Data Connectivitdy - стандарт доступу до баз даних різних форматів) і OLE 2.0 (Object Linking Embeding -
стандартний механізм зв"язку об"єктів у Windows) спрощує задачі інтеграції бізнесу-додатків.
Підтримка Microsoft Mail і Microsoft Exchange дозволяє полегшити і систематизувати групову роботу з проектами.
Настройка повідомлень для команди проекту включає можливість визначення складу проектних даних що
пересилаються учасникам проекту по електронній пошті і установку обмежень на корекцію інформації, що
пересилається одержувачами. зберігання проектів в папках Exchange забезпечує додаткові засоби розмежування доступу
до файлів проектів.
Для швидкого включення в роботу початківця користувача MS Project надає, крім звичайних засобів допомоги,
також можливість покрокової розробки проекту (Create Your First Project i Cue Cards) i інтелектуальної підказки (Answer
Wizard).
Серед переваг пакету також потрібно відмітити досить зручні i гнучкі засоби створення звітів. Основні типи звітів
166
можуть бути вибрані із заготовлених (Report Gallery). Можливість одночасно мати до шести планів для кожного проекту
дозволяє підвищити ефективність аналізу «що якщо...» У той же час MS Project надає мінімальний набір засобів для
планування i управління ресурсами. Додаткові можливості Project також включають імпорт/експорт даних в форматах
ASCII, CSV, Excel, Lotus 1-2-3, dBASE i FoxPro, засоби запису макрокоманд, Visual Basic.
MS Project може бути рекомендований для планування нескладних проектів користувачами непрофесіоналами i
початківцями.
Time Line (Time Line Solutions)
Інший популярний недорогий пакет, який пропонує компанія Time Line Solutions Corp. Значне поширення на
ринку отримала русифікована версія Time Line 1.0 для Windows. Крім неї, набуває поширення Time Line 6.5 для
Windows - більш потужна і складна версія системи.
Time Line 1.0, подібно MS Project, містить лише мінімально необхідні функції управління проектами, надаючи
користувачеві-непрофесіоналові максимально прості i ясні засоби швидкого створення i розрахунку нескладних
проектів.
Користувачеві початківцеві система пропонує набір базових розкладів, які дають загальне уявлення про проекти в
різних областях (бізнес-план, виробництво виробу, маркетинг виробу, новобудова i т.д.). Спеціальна функція інструктор
активізує модуль контролю за логікою роботи користувача. Періодично від виводить на екран запити, уточнюючи
призначення пророблених операцій, i пропозиції відносно подальших дій.
Пакет містить повний набір функцій управління проектами, однак, об'єм проектів, що плануються, як i в MS
Project, обмежений 10000 задач i 1000 видів pecypсів. Система надає спрощені алгоритми ресурсного планування.
Засоби створення звітів крім табличних i графічних (Гантт, PERT) дозволяють отримати календарний графік, який
представляє дані в добре знайомому керівнику форматі настінного календаря.
Використання правил відбору дозволяє надрукувати індивідуальний робочий календар для груп співробітників або кожного з
співробітників нарізно. Даний засіб може бути зручним для невеликих проектів.
Для організації колективної роботи з даними проекту Time Line 1.0 може бути встановлений як на робочих
станціях, так i на cepвеpi мережі.
Багатопроектне управління реалізовується тільки через об'єднання проектів або зв'язок проектів. Пакет підтримує
імпорт/експорт даних в форматах ASII, CSV, Lotus 1-2-3, dBASE.
У комплект постачання російської вepciї Time Line 1.0 входять додаткові продукти Guide Line і Guide Maker,
призначені для створення і використання інструкцій з розробки проектів в конкретних предметних областях.
167
 Time Line 1.0 може бути рекомендований користувачам-непрофесіоналам, які планують переважно часові i
вартісні параметри проектів.
Time Line 6.5 є більш могутньою версією системи управління проектами, принципово відмінною від вepciї 1.0 по
ряду параметрів.
Основними відмінними особливостями Time Line 6.5 є реалізація концепції багатопроектного планування в рамках
організації, гнучкі засоби підтримки формування звітів і засоби настройки на інформаційне середовище користувача. У
Time Line 6.5 зняті обмеження на розмірність проектів.
Time Line 6.5 дозволяє зберігати всі дані, що стосуються проектів організації в єдиній SQL базі даних, яка, крім
опису проектів i єдиного для організації списку pecypсiв, містить вci елементи настройок управлінського середовища
прийнятої в компанії для роботи з проектами. Всі основні об'єкти бази даних об'єднані у вікні OverView у відповідних
розділах. За допомогою даного вікна можна переглянути структуру бази даних проекту i здійснити доступ до будь-якого
елемента, а також створити свої елементи користувача в списках.
Time Line 6.5 пропонує досить могутні алгоритми роботи з ресурсами, включаючи засоби міжпроектного
призначення i вирівнювання перевантажень pecypсiв, гнучкі можливості по опису специфічних календарних графіків
роботи ресурсів. Недоліком даних засобів є відсутність можливостей опису і відображення ієрархії pecypсiв організації.
Стандартні можливості генерації табличних звітів по проекту доповнені можливостями системи створення, що
включається в постачання Time Line 6.5 i генерації звітів Cristal Reports 4, яка дозволяє створювати практично будь-які
види звітів, що містять дані як з БД Time Line, так і з інших баз даних компанії. Більше за 30 заготовок стандартних
звітів управління проектами в форматі Cristal Reports включені в систему.
Корисною додатковою можливістю системи є засоби створення власних формул в електронній таблиці Time Line.
Окремий модуль імпорту/експорту дозволяє обмінюватися даними з іншими пакетами УП (MS Project, CA-
SuperProject, Time Line 1.0 for Windows i 5.0 для DOS), базами даних (dBASE) i електронними таблицями (Lotus). Time
Line 6.5 підтримує стандарти ODBC, OLE 2.0, DDE,підтримує макромова Symantec Basic.
Time Line 6.5 може бути рекомендований для планування середніх або комплексів малих проектів.
Open Plan Professional (Welcom Software)
Open Plan Professional –представник класу професійних систем. Однією з основних відмінностей системи є могутні
засоби ресурсного i вартісного планування, які дозволяють значно полегшити задачу знаходження найбільш
ефективного розподілу ресурсів і складання їх робочого розкладу. Крім того, користувачами інтегрованої системи
управління проектами організації є як професійні менеджери, що здійснюють узгодження i оптимізацію планів проектів,
аналіз ризиків, прогнозування і т.д., так і учасники проектів, що виконують збір, уточнення i актуалізацію даних,
168
готуючі звіти. Якщо для професіоналів важлива потужність i гнучкість функцій планування, що надаються системою і
аналізу проектів, то для інших користувачів важливіше простота i прозорість системи. Тільки Open Plan забезпечує
сьогодні як повну інтеграцію між професійною i "настільною" версіями системи, так і відкритість для обміну даними із
зовнішніми додатками.
Open Plan постачається в двох варіантах - Professional i Desktop –кожний з яких відповідає різним потребам
виконавців, менеджерів і інших учасників проекту. обидві вepciї працюють з однією базою даних – немає необхідності в
обміні даними. Спільне використання професійної i «полегшеної» версій системи управління проектами дозволяє не
тільки врахувати потреби вcix груп користувачів, але i значно знизити вартість рішення.
До основних переваг Open Plan відноситься те, що він може працювати з даними будь-якого профілю, що
стосуються життєдіяльності підприємства. Програмне забезпечення Welcom можна настроїти на роботу з
різноманітними базами даних завдяки об'єктно-орієнтованій i клієнту-серверний архітектурі. Open Plan має прямий
доступ до SQL баз даних. Користувач може вибрати в якому форматі зберігати дані по проектах (у власному форматі
Open Plan, в форматах Oracle, SQL Server, Sybase, xBase).
Open Plan забезпечує обмеження доступу до даних проекту, дозволяючи надавати різні права на доступ до певних
даних, роблячи їx доступним обмеженому колу ociб і регулюючи їx спільне використання. 3aci6 "Директор управління
проектами», вбудоване в Open Plan, дозволяє упорядити застосування стандартних елементів проектів i процедур. У
Open Plan пропонується 65 моделей, побудованих на базі керівництва РМI (інституту Проектного Менеджменту, США),
які можна настроїти для створення документів, що відповідають вимогам 3/SCSC i ISO стандартів.
Primavera (Primavera Systems, Inc.)
Центральний програмний продукт сімейства Primavera, Primavera Project Planner (РЗ), добре відомий в середовищі професійних менеджерів проектів у всьому
світі. Сьогодні РЗ застосовується для управління середніми i великими проектами в самих різних областях, хоч найбільше поширення даний продукт отримав в сфері
управління будівельними і інженерними проектами.

Primavera Project Planner надає досить стандартний для всіх подібних систем графічний інтерфейс, але у РЗ є
декілька додаткових можливостей. По-перше, це можливість угрупування i впорядкування робіт по різних ознаках на
різних рівнях деталізування проекту, що дозволяє уявити інформацію в більш зручному вигляді для конкретної
управлінської ситуації. Наприклад, використовуючи дані засоби, всю інформацію по проекту можна згрупувати по фазі
проекту на першому рівні ієрархії, по відповідальному ресурсу - на другому i відсортувати по даті початку робіт - на
третьому. Для кожної групи можуть бути задані власні шрифт i колір (тексту i фону), посторінкове розбиття.
Інша корисна особливість - це можливість розбиття екрану по горизонталі на дві частини, кожна з яких може бути
переглянута незалежно. Це дає можливість одночасно переглядати різні частини проекту.

169
 Окpiм того, РЗ має певні відмінності від інших пакетів в засобах ресурсного планування.
При описі ресурсу можуть бути вказані нормальна i максимальна кількість даного ресурсу, а також його ціна по
шести часових інтервалах. Ресурс може бути помічений як керівник (об'єм призначення керуючого ресурсу на задачу
буде впливати на тривалість її виконання). Наприклад, визначивши, що робітники – це керуючий ресурс, а бригадир - ні,
можна добитися скорочення термінів виконання задачі прокладка траншеї за рахунок призначення більшої кількості
робітників. збільшення ж кількості бригадирів не вплине на тривалість роботи.
При плануванні завантаження pecypсiв може виникнути необхідність в описі нелінійного профілю споживання
ресурсу окремою задачею. РЗ дає можливість описати різні криві розподілу ресурсу, пропонуючи дев'ять стандартних
кривих i можливість визначити власний профіль споживання, розбивши часову фазу на 10 періодів.
Засоби автоматичного перепланування задач з урахуванням обмежень на ресурси набувають особливої ваги для
великих проектів, коли менеджер не в змозі самостійно проаналізувати причини недостачі pecypсiв i знайти рішення для
кожної конкретної роботи. РЗ дозволяє вибрати режим перерахунку розкладу і підібрати критерії перепланування робіт,
що забезпечує отримання більш короткого розкладу. Серед режимів перерахунку можна виділити вирівнювання уперед
(визначення можливої дати закінчення проекту при заданій початковій даті), вирівнювання назад (визначення самої
пізньої допустимої дати початку проекту), згладжений перевантажень pecypсів в рамках в часових резервів робіт або в
рамках заданого інтервалу.
Окpiм того, є можливість перерозподіляти призначення робіт між згрупованими ресурсами.
До недоліків засобів ресурсного планування можна віднести обмеження на кількість календарів. Окрім головного
календаря проекту, РЗ дозволяє описати лише 30 додаткових календарів, в той час як можливість завдання
індивідуальних графіків роботи для кожного ресурсу вже стало нормою в сучасних пакетах УП. Інше обмеження
пов'язане з кількістю pecypсiв (не більш за 120), що контролюються при вирівнюванні профілю завантаження обмежених
pecypсів.
Засоби підтримки у багатопроектному середовищі управління в РЗ включають можливість визначення iєpapxiї i
права доступу до майстра- проекту i підпроектів. Менеджер-координатор проекту має право редагувати майстер-проект і
всі підпроекти. Менеджер підпроекту має право додавати ресурси в словник pecypсiв, але не видаляти їx i не змінювати
їx ціни. Якщо вирішення ресурсних конфліктів в рамках підпроекту вимагає даних іншого підпроекту, менеджер може
це зробити тільки при наділенні його додатковими повноваженнями з боку менеджера-координатора проекту. Однак,
ресурсне планування по всьому проекту загалом може здійснюватися тільки менеджером-координатором. Тільки він
може визначити зв’язки між підпроектами. У порівнянні з багатьма іншими програмними продуктами, які також дають
можливість багатопроектного управління, відмітною особливістю РЗ є детальний опис принципів багатопроектного
170
управління в документації, де вони розглядаються з двох точок зору: менеджера-координатора проекту i менеджера
підпроекту.
Крім РЗ, компанією Primavera Systems постачається полегшена система для УП – SureTrack. Цей програмний
продукт орієнтований на невеликі проекти, підпроекти, роботу конкретних виконавців з фрагментами проектів.
SureTrack має ті ж засоби, що i РЗ в плані організації проекту по кодах i фільтрації інформації, установки обмежень і
розрахунку розкладу, але в той же час існує ряд обмежень i додаткових можливостей.
З обмежень потрібно відмітити відсутність засобів багатопроектного управління i фрагментації проектів, меншу
розмірність проектів, більш скромні засоби створення звітів. Однак, в SureTraсk з'явилися календарі ресурсів і, як
наслідок можливість розрахунку тривалості робіт з урахуванням узгодження календарів виконавців (очікується, що
календарі pecypсiв з'являться i в наступній версії РЗ). Крім того, у pecypсiв з'явилася додаткова категорія – прибуток.
SureTraсk відрізняється від всіх інших продуктів Primavera тим, що він повністю русифікований i постачається разом з
посібником для користувача на російській мові.
SureTraсk здійснює імпорт/експорт файлів у форматах РЗ i MS Project.
Таким чином, працюючи спільно, РЗ i SureTraсk пропонується підхід, прийнятний для управління проектами
різного розміру і складності. Крім вищеназваних продуктів з сімейства Primavera інтерес може представляти система
аналізу ризиків проекту Monte Carlo for Primavera,яка дозволяє визначити терміни і вартість проекту з заданою
вірогідністю.
Artemis Views (Artemis International)
Інша відома в світі управління проектами торгова марка – Artemis. Традиційно ПО сімейства Artemis (Artemis
2000, Artemis 9000, потім Prestige) використовувалося для управління великими інженерними проектами. На
сьогоднішній день корпорація Artemis International розповсюджує під цією торговою маркою серію програм під
загальною назвою Artemis Views.
Сімейство Artemis Views складається з набору модулів що автоматизують piзнi аспекти управління
проектами: ProjectView, ResourceView, TrackView, CostView. Bci модулі сумісні за даними, працюють в архітектурі
клієнт/сервер, підтримують ODBC стандарт і легко інтегруються з популярною СУБД Oracle, SQLBase, SQLServer,
Sybase.
Кожний модуль може працювати як незалежно, так і в комбінації з іншим ПО. Ціна на це, традиційно недешеве ПО, розраховується
виходячи з конфігурації, що замовляється.

171
 ProjectView дозволяє реалізувати мультипроектну, багатокористувацьку систему планування i контролю проектів
в організації. ProjectView дозволяє розділяти проектні дані (календарі, кодифікатори, списки ресурсів) між
користувачами або призначеними для користувача групами, забезпечує засоби безпеки при одночасній роботі
користувачів з проектом. Система дозволяє отримувати значну кількість різних звітів за допомогою власних засобів або
з використанням спеціалізованого ПО (наприклад, Quest). У комбінації з засобами управління ресурсами Resource View
дозволяє побудувати інтегрований підхід до управління роботами і поточними операціями.
Resource View – спеціалізована система для планування і контролю використання pecypciв як в проектному або
матричному середовищі управління, так i для поточних робіт. У системі реалізовані засоби підтримки узгодження
керівниками розподілу ресурсів між роботами. Графічна панель управління ресурсами дозволяє менеджерам планувати,
контролювати i оптимізувати їx завантаження за рахунок перерозподілу черги робіт відповідно до наявності ресурсів.
Track View надає засоби ведення фактичної інформації по виконаних об’ємах робіт, контролю за станом
виконання і вартістю поточних робіт (проектних i поза-проектних). Система дозволяє інтегрувати дані для різних рівнів
управління в організації від рядових виконавців, ведучих інформацію по своїх задачах, до вищого керівництва, яке може
отримати укрупнені дані по фактичних витратах i об'ємах робіт.
Cost View забезпечує підтримку центрального репозиторію для інформації по вcix витратах i прибутках проектів.
Пакет дозволяє аналізувати економічну ефективність контрактів, будувати таблиці грошових потоків, передбачати
витрати і розраховувати показники внутрішньої норми рентабельності проектів. Безумовно Artemis Views дозволяє
створити могутнє інтегроване рішення, однак витрати, пов'язані з придбанням i впровадженням даного ПО, істотно
обмежують коло потенційних користувачів.
Spider Project
Огляд систем УП був би неповний без згадки російської розробки -Spider Project. По інформації, отриманій від
фахівців, які розробляють i підтримуючих пакет, система була інстальована для управління декількома десятками
великих проектів.
Даний пакет має декілька характерних особливостей, які дозволяють йому конкурувати iз західними системами на
великих, промислових проектах.
По-перше, це могутні алгоритми планування використання обмежених pecypciв. Тестування відомих пакетів УП
(Artemis Views не тестувався) показало перевагу алгоритмів Spider Project за якістю планів виконання робіт, що
складаються при обмеженості ресурсів, що є. Для 32 і 100 проектів, що брали участь в тестуванні, Spider Project склав
більш короткі розклади робіт, а для інших 68 проектів його розклади не поступалися кращим з розкладів, складених
західними пакетами.
172
 У пакеті реалізована можливість використання при складанні розкладу робіт взаємозамінних ресурсів (пули
ресурсів), яка також дозволяє отримати більш коpоткі розклади. Використання ресурсних пулів позбавляє менеджера від
необхідності жорстко призначати виконавців на роботи проекту. Йому досить зазначити загальну кількість ресурсів,
необхідних для виконання робіт і з яких pecypciв цю кількість вибирати. Це дозволяє скоротити непродуктивні простої
pecypcів i полегшити роботу проектного менеджера, позбавляючи його необхідності робити стомливі на великих
проектах оцінки «що коли...».
Ще однією особливістю пакету є можливість використання нормативно-довідкової інформації - про
продуктивність pecypсів на тих або інших видах робіт, витрати матеріалів, вартість робіт i pecypсiв. Spider Project
дозволяє необмежено нарощувати число показників, що враховуються в проектах створювати i використовувати в
розрахунках будь-які додаткові табличні документи i бази даних, вводити будь-які формули розрахунку. Можливість
настройки системи дозволяє користувачам отримувати від пакету не тільки розклад робіт, графіки завантаження
pecypсiв i вартісні характеристики проекту, але i технологічні характеристики складених розкладів. Так наприклад, в
гірничо-добувній промисловості користувачі Spider Project отримали можливість планувати не тільки порядок виїмки
об'ємів руди, але i враховувати об'єми окремих компонентів, що містяться в руді.
Перевершуючи багато які з західних пакетів по потужності i гнучкості окремих функцій, Spider Project, загалом,
поступається в області програмної реалізації (використання стандартів обміну даними, інтерфейс користувача і т.д.).

5. Впровадження ІС УП
Купуючи систему для планування і управління проектами, часто забувають, що впровадження системи, тягне за
собою зміну процесів управління в організації (іноді значну). Доцільним при цьому є системний підхід, який включає
планування комплексу робіт і контроль за їх здійсненням. Іншими словами, почати освоєння системи управління
проектами в організації найкраще з розробки плану робіт по впровадженню системи.
Розроблений план впровадження не повинен обмежуватися лише установкою програмного забезпечення в
організації і навчанням користувачів функціям системи. Проекти по установці нових систем автоматизації управлінської
діяльності традиційно охоплюють набагато більш широкий спектр задач від додаткової формалізації процедур збору і
зберігання управлінської інформації до здійснення змін в організаційній структурі управління і перерозподілу обов"язків
. Загалом, проекти по впровадженню подібних систем можна віднести до класу організаційних проектів – проектів, які в
тій або іншій мірі призводять розвитку структури організації. Особливістю даного типу проектів є те, що від успіху або
невдачі проекту може залежати ефективність функціонування організації загалом або її окремих підрозділів. З цієї
причини ретельне планування і контроль не тільки технічних, але і людських аспектів впровадження системи набуває
173
особливої. Склад і зміст задач, що вирішуються в рамках подібного проекту, можуть скласти тему окремої розмови. Тут
же хотілось б зупинитись лише на деяких загальних моментах планування подібних проектів.
Можна сформулювати декілька помилок, що зустрічаються найчастіше в плануванні впровадження системи для
управління проектами, які є причинами невдач освоєння подібних систем:
- цілі проекту і очікувані результати не визначені заздалегідь або визначені не в повному об‘мі . Жорсткі
часові обмеження, нетерплячість або непослідовність керівництва можуть не дозволити реалізувати цілі
проекту в повному обсязі;
- планування введення в експлуатацію всіх функцій пакету управління проектом одночасно. Впровадження
системи управління проектами в повному об"ємі може потребувати використання цілої низки нових технологій
(наприклад, установку глобальної інформаційної мережі і баз даних клієнт-сервер), а реалізація різних функцій
може впливати на роботу різних підрозділів і фахівців (наприклад, різні відділи повинні бути залучені в
підтримку інформаційних потоків при реалізації тимчасового, ресурсного і вартісного видів планування робіт).
Все це може привести до значного ускладнення проекту і робить проблематичним стабілізацію роботи системи
загалом.
планування переводу відразу всієї організації на використання системи для управління проектами. Це подібно
спробі зв"язати відразу всіх співробітників великої організації в локальну обчислювальну мережу, замість того щоб
здійснювати підключення користувачів послідовно відділ за відділом.

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

174
 сплануйте впровадження системи по відділах. Почати краще з невеличкого відділу, з досить кваліфікованими співробітниками.
Необхідно пам"ятати , що в кожній організації є співробітники більш зацікавлені у використанні нових систем автоматизації і більш здатні в
їх освоєнні. Почати краще саме з них. Отримавши першу групу користувачів, що освоїли систему, можна перейти до поширення даної
технології на інші відділи в організації. Коли система почне реально працювати в організації, противникам її використання доведеться також
стати її користувачами. Важливо пересвідчитися, що керівники відділів обізнані про плани впровадження нової системи і діють відповідно
до плану.
Звичайно, це лише деякі поради відносно впровадження програмного забезпечення для управління проектами. Масштаби
використання подібних систем в різних організаціях можуть істотно варіюватися.
Складність задач по впровадженню залежить від масштабів організації, структури управління і ступеню
автоматизації, масштабів і типу проектів, що реалізовуються, ступеню залучення до управління проектами зовнішніх
організацій.
Однак, навіть у відносно простих ситуаціях план впровадження системи може зіграти вирішальну роль для її
введення в реальну експлуатацію. Найбільш важлива роль проектного підходу до освоєння системи в тому, що він
дозволяє залучити потенційних користувачів системи в єдину команду проекту і таким чином заручитися їх підтримкою.
Саме це дає шанс на успіх впровадження системи в організації.

175
 Управління комунікаціями (взаємодія
і інформаційні зв"язки)

Додатки
Учасники Уміння і Оточення і засоби
інформаційного Процеси навички
обміну
1 Функціональні
• Керівництво
проектом
1 Замовник 1 Передача 1 Техніка 1 Способи спілкування • Зустрічі, форуми
• Усна • Лідерство • Персонально • Інформаційна
Вище керівництво • Коммунікабельність система управління
2 • Письмова • Через організацію
• Мотивація проектом
• Візуальна • Таємні • Маркетинг і
3 Команда проекту • Контактна та ін. • Взаємодія повідомлення торговля
• Переконання (неправдиві слухи) • Зв"язки з
4 Виконавці 2 Фільтрація інформації • Мова 2 Технічне громадськістю
• Композиція/ забезпечення
по змісту і • Управлінська
5 Інші учасники красномовство
призначенню • Засоби документація
проекту • Активне слухання
• Місце - протоколи
3 • Швидке читання - переписка
Прийом і сприйняття розташування
• Вирішення проблем 3 - звіти
інформації в • Виділення Персональні контакти
залежності від способу 4 Групові зустрічі - специфікації
пріоритетів - договорні
передачі 5 Телефон
• Вирішення документи
6 Кореспонденція 2
конфліктів Методи і засоби
4 Інтерпретація і 2 7 Електронна пошта
Стиль спілкування • Визначення
засвоєння інформації • Владний • Політика
• Допоміжний • Розподіл
• Радницький відповідальності
• Покладистий • Процедури/
• Засуджуючий стандарти
• Етичний • Інформаційні
• Скритний потоки
• Руйнуючий 176
• Засоби відображення
• Залякуючий • Огляд і аналіз
177