Управління проєктом «Queue control

Кутовий, Дмитро Олегович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7299

Title:	Управління проєктом «Queue control
Authors:	Лавданська , Ольга В’ячеславівна Кутовий, Дмитро Олегович
Keywords:	управління проєктом;PMBok;інформаційна технологія;SEO;WBS
Issue Date:	4-Dec-2021
Abstract:	Управління стартапом є надзвичайно складним завданням, оскільки потрібно спростити практично кожну операцію бізнесу. Будь-то команда, робочі процедури, внутрішня та зовнішня комунікація тощо, потрібно докласти зусиль, щоб все було добре. Успіх стартапу залежить від ряду факторів. Одна з найважливіших речей, яка визначає успіх новоствореного бізнесу – це те, як здійснюється керування та реалізація проекту. Для будь -якого стартапу об’єднання всіх співробітників для співпраці та управління проектами – це важка справа. Але існує певний тип управлінської дисципліни, яка стосується того, як ви керуєте своїми проектами. Багато стартапів часто неправильно оцінюють управління проектами яке корисне лише у великих організаціях або компаніях, які стали стабільними. Але управління проектами є надзвичайно важливим і вирішальним навіть для нових малих підприємств. Про важливість управління проектами свідчать наступні факти. Згідно з глобальним опитуванням PMI Pulse of the Professional 2017 року [53], компанії, які впроваджували відомі практики управління проектами, витратили у 28 разів менше грошей, все тому, що їхні стратегічні ініціативи дали хороші результати. У виданні PMI «Пульс професії» за 2015 рік [54] було запропоновано, що управління проектами може покращити показники успішності проектів за рахунок зменшення ризиків та скорочення загальних витрат. Інше глобальне опитування PMI, проведене у 2018 році [55], показало, що лише 58% організацій усвідомлюють важливість управління проектами. Опитування з питань управління проектами 2017, проведене компанією KPMG [56] показало, що 60 % організацій керували своїми проектами, використовуючи структуру портфелю, а 80 % організацій використовували більше декількох методологій управління проектами. Ця статистика дає чітке уявлення про те, що управління проектами може допомогти організаціям краще управляти своїми проектами з кращими шансами на успіх. Однак не кожна організація використовує управління проектами в повній мірі. Власник стартапу повинен мати на увазі, що project management – це чудовий спосіб привести проекти до успіху. Керуючи проектами професійно, можна покращити загальний результат свого бізнесу.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7299
Appears in Collections:	126 Інформаційні системи та технології (IT Project Management)

Files in This Item:

File	Description	Size	Format
РЕП_МАГ_Кутовий_МІТ-2010.pdf Restricted Access		1.36 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

2

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ

Кафедра інформаційних технологій проектування

Пояснювальна записка
до кваліфікаційної роботи

магістра
(освітньо-кваліфікаційний рівень)

на тему: «Управління проєктом «Queue control»»

Виконав: студент 2 курсу, групи МІТ-2011
Спеціальності
122 «Комп’ютерні науки»
(шифр і назва спеціальності)
Освітньої програми
Управління ІТ-проектами я

Кутовий Д.О.
(прізвище та ініціали)
Керівник Лавданська О.В.
(прізвище та ініціали)
Рецензент к.т.н., доцент, полковник служби
цивільного захисту, начальник кафедри
техніки та засобів цивільного захисту,
Черкаський інститут пожежної безпеки
імені Героїв Чорнобиля Національного
університету цивільного захисту України
Биченко А.О.
(прізвище та ініціали)

3

Черкаси 2021 року

4

5

ЗМІСТ
СПИСОК УМОВНИХ СКОРОЧЕНЬ ........................................................................ 8
РОЗДІЛ 1 РОЗРОБКА КОНЦЕПЦІЇ ПРОЕКТУ .................................................... 12
1.1 Формування інвестиційного задуму .............................................................. 12
1.2 Аналіз конкурентного середовища................................................................ 14
1.3 SWOT, PEST аналіз проекту .......................................................................... 15
1.4 Резюме проекту ............................................................................................... 16
1.5 Висновки до розділу ....................................................................................... 18
РОЗДІЛ 2 УПРАВЛІННЯ ПРОЕКТОМ .................................................................. 19
2.1 Управління інтеграцією та інформаційними зв’язками проекту ............... 19
2.2 Управління змістом проекту .......................................................................... 24
2.3 Управління часом проекту ............................................................................. 29
2.4 Управління трудовими ресурсами проекту .................................................. 31
2.5 Оцінка вартості стартапу ................................................................................ 32
2.6 Особливості реалізації ІТ-стартапів .............................................................. 37
2.7 Управління якістю проекту ............................................................................ 40
2.8 Управління ризиками проекту ....................................................................... 44
2.9 Управління змінами проекту.......................................................................... 58
2.10 Контроль проекту .......................................................................................... 63
2.11 Висновки до розділу ..................................................................................... 72
РОЗДІЛ 3 ОЦІНКА ЕФЕКТИВНОСТІ ПРОЕКТУ ................................................ 73
3.1. Планування фінансових ресурсів інвестиційної фази проекту ................. 73
3.2. Ефективність поточної основної операційної діяльності .......................... 77
3.3. Планування амортизаційних витрат операційної діяльності .................... 79
3.4 Планування кредитних процесів операційної діяльності ........................... 81
3.5 Прогноз доходів операційної діяльності .................................................... 82
3.6 Прогноз витрат операційної діяльності ........................................................ 83
3.7 Прогноз грошових потоків операційної діяльності ..................................... 85
3.8 Прогноз грошових потоків проекту .............................................................. 87
6

3.9 Оцінка показників ефективності проекту ..................................................... 90
3.10 Висновки до розділу ..................................................................................... 90
ВИСНОВКИ ............................................................................................................... 91
СПИСОК ІНФОРМАЦІЙНИХ ДЖЕРЕЛ ............................................................... 92

7

СПИСОК УМОВНИХ СКОРОЧЕНЬ
ІТ – Інформаційні технології;
ПК – Персональний комп’ютер;
OC – Операційна система;
SEO – Search engine optimization;
WBS - Work breakdown structure;
ТЕО – Техніко-економічне обгрунтування;
ТЗ – Технічне завдання;
TQM – Total Quality Management;
PDCA – Plan do check act;
QA – quality assurance;
ПМ – Проектний менеджер;
ІБ – Інформаційна безпека;
ІД – Інвестиційна діяльність;
ОД – Операційна діяльність.
8

ВСТУП
Управління стартапом є надзвичайно складним завданням, оскільки
потрібно спростити практично кожну операцію бізнесу. Будь-то команда, робочі
процедури, внутрішня та зовнішня комунікація тощо, потрібно докласти зусиль,
щоб все було добре.
Успіх стартапу залежить від ряду факторів. Одна з найважливіших речей,
яка визначає успіх новоствореного бізнесу – це те, як здійснюється керування та
реалізація проекту.
Для будь -якого стартапу об’єднання всіх співробітників для співпраці та
управління проектами – це важка справа. Але існує певний тип управлінської
дисципліни, яка стосується того, як ви керуєте своїми проектами.
Багато стартапів часто неправильно оцінюють управління проектами яке
корисне лише у великих організаціях або компаніях, які стали стабільними. Але
управління проектами є надзвичайно важливим і вирішальним навіть для нових
малих підприємств.
Про важливість управління проектами свідчать наступні факти. Згідно з
глобальним опитуванням PMI Pulse of the Professional 2017 року [53], компанії,
які впроваджували відомі практики управління проектами, витратили у 28 разів
менше грошей, все тому, що їхні стратегічні ініціативи дали хороші результати.
У виданні PMI «Пульс професії» за 2015 рік [54] було запропоновано, що
управління проектами може покращити показники успішності проектів за
рахунок зменшення ризиків та скорочення загальних витрат.
Інше глобальне опитування PMI, проведене у 2018 році [55], показало, що
лише 58% організацій усвідомлюють важливість управління проектами.
Опитування з питань управління проектами 2017, проведене компанією
KPMG [56] показало, що 60 % організацій керували своїми проектами,
використовуючи структуру портфелю, а 80 % організацій використовували
більше декількох методологій управління проектами.
9

Ця статистика дає чітке уявлення про те, що управління проектами може
допомогти організаціям краще управляти своїми проектами з кращими шансами
на успіх. Однак не кожна організація використовує управління проектами в
повній мірі.
Власник стартапу повинен мати на увазі, що project management – це
чудовий спосіб привести проекти до успіху. Керуючи проектами професійно,
можна покращити загальний результат свого бізнесу.
Актуальність теми. Застосування проектного підходу в процесі розробки
Queue Control. Система, яка надає можливість контролювати чергу всередині і
ззовні відділення, що сприятиме підвищенню продуктивності працівників та
забезпечить автоматизоване дотримання карантинних умов.
Мета дослідження. Метою даної роботи є розкрити методологію
управління проектом Queue Control за допомогою теоретичних знань та
практичних навичок, що були здобуті за час навчання.
Для досягнення поставленої мети були сформульовані та вирішені такі
завдання дослідження.:
‒ визначити цілі проекту;
‒ підготовити обґрунтування та концепцію проекту;
‒ структурувати проект (підцілі, підпроекти, фази і т.д.);
‒ визначити фінансові потреби і джерела фінансування;
‒ розрахувати кошторис і бюджет проекту;
‒ визначити терміни виконання проекту і розробити графік реалізації;
‒ забезпечити контроль за ходом виконання проекту і внесення коректив у
план реалізації;
‒ управління ризиками в проекті;
‒ визначення критеріїв якості та контроль їх дотримання;
‒ налагодження комунікації між виконавцями;
‒ інтеграція проекту;
‒ контроль та мотивація.
Об’єктом дослідження є проект Queue Control.
10

Предмет дослідження – методи та засоби управління проектом Queue
Control.
Галузь дослідження – галузь інформаційних технологій.
Методи дослідження. В роботі застосовані методи проектного
менеджменту згідно PMBok.

11

РОЗДІЛ 1 РОЗРОБКА КОНЦЕПЦІЇ ПРОЕКТУ
1.1 Формування інвестиційного задуму
Пандемія COVID-19 спричинена поширенням коронавірусу SARS-CoV-2.
Спалах захворюваності на вірус вперше був зафіксований в м. Ухань (Китай) у
грудні 2019 року. 30 січня 2020 року Всесвітня організація охорони здоров'я
оголосила цей спалах надзвичайною ситуацією в галузі суспільної охорони
здоров'я, що має міжнародне значення, а 11 березня – пандемією. Станом на 14
листопада 2021 року зареєстровано понад 253 млн. випадків захворювання по
всьому світу; підтверджено понад 5,0 млн летальних наслідків захворювання, що
робить пандемію COVID-19 однією з найбільш смертоносних в історії.
В основному вірус SARS-CoV-2 передається при тісному контакті,
найчастіше через невеликі краплі, що утворюються при кашлі, чханні та розмові.
Краплі зазвичай падають на землю або на поверхні, а не переміщуються повітрям
на великі відстані. Передача може також відбуватися через дрібніші краплі, які
здатні залишатися зваженими в повітрі протягом більш тривалих періодів часу.
Рідше можливе зараження після дотику до забрудненої поверхні, а потім до
обличчя. Інфікований найбільш заразний протягом перших трьох днів після
появи симптомів, хоча поширення можливе і до появи симптомів, а також через
людей, які не виявляють симптомів.
До поширених симптомів відносяться лихоманка, кашель, втома, задишка,
втрата смаку та аносмія (втрата нюху), можлива закладеність вух. При
ускладненнях можуть виникати гострий респіраторний дистресс-синдром
(ОРДС) і пневмонія (запалення легких). Інкубаційний період, тобто відрізок часу
від моменту зараження до прояву симптомів, зазвичай становить близько 5 днів,
але може змінюватись від 2 до 14 днів. Оскільки немає жодних противірусних
препаратів для лікування захворювання, первинне лікування проводиться за
допомогою симптоматичної терапії (усунення окремих симптомів). З кінця 2020
12

року існує кілька вакцин проти COVID-19, низка країн розпочала масову
вакцинацію проти COVID-19.
Як профілактичні заходи рекомендуються миття рук, прикривати рот і ніс
ліктьовим згином при кашлі або чханні, підтримка дистанції від інших людей
(соціальне дистанціювання), носіння захисної маски в громадських місцях,
дезінфекція поверхонь, збільшення вентиляції та фільтрації повітря в
приміщенні, а також моніторинг та самоізоляція для людей, які підозрюють, що
вони інфіковані. Органи влади в усьому світі вжили заходів, запровадивши
обмеження на подорожі, контроль ризику на робочому місці та закриття об'єктів.
Крім того, багато установ працюють над підвищенням потенціалу тестування та
відстеження контактів інфікованих осіб.
Пандемія COVID-19 стала причиною серйозних соціально-економічних
наслідків, включаючи найбільшу світову рецесію після Великої депресії та
масовий голод, що торкнувся близько 265 млн осіб. Це призвело до перенесення
або скасування безлічі спортивних, релігійних, політичних і культурних заходів,
а широко поширений дефіцит поставок посилився панічними покупками.
Зменшилися викиди забруднюючих речовин та парникових газів. Школи,
університети та коледжі були закриті або на загальнонаціональній, або на
місцевій основі в 172 країнах, що торкнулося приблизно 98,5% світового
населення шкільного та студентського віку. Дезінформація про вірус
поширилася через соціальні мережі та засоби масової інформації. Відомі випадки
ксенофобії та дискримінації щодо китайського народу та тих, хто сприймається
як китайці або вихідці з регіонів з високим рівнем інфікування.
Відношення вище описаної ситуації до нашої системи Queue Control.
Одним із пунктів дотримання санітарних та протиепідемічних заходів є
обмеження кількості відвідувачів у торговельній залі. Допустима кількість
людей може бути, як з розрахунку 1 особа на 1 кв/м, так і не більше 1 особи на
10 кв/м – органами місцевого самоврядування можуть встановлюватися різні
норми. Таким чином, під час карантину магазинам, поштовим чи банківським
відділенням доводиться слідкувати за живою чергою для дотримання норм.
13

Queue Control – це сукупність електронного обладнання та програмного
забезпечення, яка дозволить упорядкувати прийом відвідувачів, позбавитися
«живих» черг, отримати неупереджений інструмент контролю навантаження та
якості роботи персоналу, а головне забезпечить автоматизоване та безпечне
дотримання карантинних норм. СКЧ (Система контролю черги) створена не
лише для відвідувачів, а й має перспективу потужного інструмента для
ухвалення обґрунтованих управлінських рішень щодо управління ресурсами та
маркетингу.

1.2 Аналіз конкурентного середовища
На ринку існують аналогічні продукти, що частково відповідають
потребам (табл. 1.1).
Таблиця 1.1
Порівняння продуктів-аналогів
Взаємодія Контроль за
Конкуренти Функціонал системи з Спрямованість дотриманням
відвідувачами компанії карантинних
норм
Підрахунок збір даних та
відвідувачів на заготовлених аналітика для
WATCOM
GROUP основі датчиків рішень немає торгових мереж Не має

на вході та торговельних
центрів
Збір та обробка антикрадіжні
ТК Системс аналітики заготовлених системи та Немає
зібраної на рішень немає лічильники готових
основі датчиків відвідувачів рішень

Аналіз черги,
Axis аналітика на звукове Smart системи
на основі IP Під
Communications основі сповіщення технологій замовлення
відеокамер

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

Наше рішення датчиків звукове та оптимізація Є готове
, взаємодії з рішення
аналітика за сповіщення відвідувачами
потребою

14

1.3 SWOT, PEST аналіз проекту
Результати SWOT-аналізу проекту:
Strengths:
 високий рівень контролю якості;
 зростання оборотних коштів;
 концентрація на певних послугах;
 передові інформаційні технології та висока якість обслуговування;
 досконала система управління.
Opportunities:
 відсутність конкурентів з реалізованим продуктом;
 низький поріг входу в міжнародний ринок;
 удосконалення менеджменту;
 захист здоров'я громадян в умовах карантину;
 поява нових партнерів;
 можливість впровадження додаткового функціоналу та послуг.
Weaknesses:
 нестабільність політичного середовища;
 економічна депресія;
 перший досвід розробки реального проекту.
Threats:
 нестабільність політичного середовища;
 можливі великі коливання курсу обміну валюти;
 вихід на ринок нових конкурентів;
 збільшення податків.
PEST аналіз проекту подамо у вигляді табл. 1.2.

15

Таблиця 1.2
PEST аналіз проекту
Група Опис
факторів Фактор

11 серпня 2021 року Володимир Зеленський
підписав закон, який встановлює загальний
порядок, за яким розглядатимуть заяви про
Законодавство набуття статусу резидента Дія City та вимоги до
резидентів. Закон почав діяти з 14 серпня.
До законопроекту продовжують подавати
Політичне правки і він несе достатню кількість ризиків для

середовище ІТ-фахівців.
Зовнішня політика Загострення політичних і економічних відносин
країни між окремими країнами
Зовнішня політика Зловживання Росією домінуючою позицією на
країни ринку газу і відповідно істотний вплив на рівень
цін
Загальносвітова Поширення нової хвилі в світі мутованого
ситуація штаму коронавіруса
Зростання ВВП в січні - серпні 2021 роки (2,9%)
був у два рази менше, ніж падіння ВВП за
Економічні Зменшення аналогічний період минулого року - 5,7%. Такі
фактори держбюджету дані навело Мінекономіки в огляді економічної
активності за підсумками серпня поточного
року.
Соціальні Безробіття Безробіття збільшується.
фактори Карантин Потужний розвиток коронавірусу.
Пандемія мотивує учасники ринків капіталу
продовжувати інвестувати в автоматизацію
протягом 2021 року. Процеси ручного введення
Технологічні Автоматизація даних і незв'язані інфраструктури додатків
відходять у минуле, водночас триває перехід на
відкриті платформи та стандартизовані API. У
2021 році продовжаться масштабні інвестиції в
RPA.

1.4 Резюме проекту
Назва проекту – "Queue Control".
Метою проекту є розробка комерційного продукту у вигляді
автоматизованої системи контролю черги, яка визначає кількість клієнтів в
приміщенні та інформує відвідувачів про наявність вільних операторів.
Очікуваний термін реалізації проекту 1 – 1,5 року. Впровадження системи
16

дозволить збільшити прибутки шляхом підвищення якості обслуговування
клієнтів.
Класифікація проекту:
 за класом – монопроект;
 за типом – економічний;
 за видом – інвестиційний;
 за тривалістю – короткостроковим;
 за масштабом – малий;
 за ступенем складності – простий.
Учасники проекту:
 команда Noosphere;
 ініціатор ідеї, розробник;
 співавтори, розробники;
 керівник проекту;
 інвестор та експерти;
 проектувальник;
 розробники;
 аутсорс-розробники;
 тестувальники;
 посередники;
 інші зацікавлені сторони.
 споживачі кінцевої продукції
Цілі учасників проекту – реалізація продукту на основі технічного
завдання із дотриманням обмежень проекту.
Обмеження проекту:
 терміни (1 – 1,5 року);
 бюджет;
 технічне завдання.
17

Вимоги до результату проекту. Успішно розроблений та вчасно
реалізований продукт, який буде влаштовувати кінцевого споживача і приносити
прибуток. Таким продуктом є автоматизована система контролю черги, що
контролюючи потік відвідувачів в приміщенні, допомагає дотримуватись
карантинних норм та оптимізувати процес їх обслуговування.
Особливості проекту. Відсутність успішних аналогів впроваджених в
нашому регіоні. Більшість аналогів направленні на збір статистичних даних про
трафік відвідувачів закладу. Є декілька аналогів задачею яких є оптимізація
потоку черги, та декілька рішень для дотримання карантинних норм. Перші
група систем не орієнтовані на пряму, автоматизовану, взаємодію із клієнтами, а
інша група – віршує задачу лише частково.
Альтернативи реалізації проекту. На сьогоднішній день є багато
мікрокотнролерів та датчиків. Але обрані саме Raspberry pi 4 (одноплатний
комп’ютер), та Wemos LoLin32 lite (мікроконтролер) – це рішення було прийнято
опираючись на наявність великої кількості відгуків, та згуртованих
співтовариств з більшими базами знань, ніж в інших аналогів, що полегшить
входження нашим розробникам-новачкам в цю сферу. Також ці компоненти
повністю влаштовують як функціонально, так і за ціною відносно конкурентних
аналогів.

1.5 Висновки до розділу
Автоматизація процесу обслуговування клієнтів закладами з об’ємними
потоками відвідувачів, навіть без додаткових функцій вже буде корисною і це не
потребує багато ресурсів. Але, це ще не впроваджено на ринку і цим можна
скористатися. Основна ідея роботи полягає у тому, що можна почати розробляти
продукт для вирішення однієї проблеми, за допомоги якої найпростіше ввійти до
ринку, а потім додавати сумісні рішення інших задач, і таким чином підвищувати
цінність продукту. Загалом у першому розділі було описано предметну область
та ідею проекту, проведено порівняльний аналіз конкурентів, виконано SWOT та
PEST аналізи, складено резюме проекту.
18

РОЗДІЛ 2 УПРАВЛІННЯ ПРОЕКТОМ
2.1 Управління інтеграцією та інформаційними зв’язками проекту
Область знань управління проектом поєднує процеси, між якими є багато
спільного. Наприклад, управління інтеграцією проекту пов'язане з процесами
складання плану проекту, виконання плану проекту та процесом інтегрованого
контролю за змінами.
Управління інтеграцією проекту складається із трьох процесів: розробка
плану проекту, виконання плану проекту та цілісний контроль за змінами.
Наукова основа розробки проекту пов'язана з координуванням усіх аспектів
проекту. Планування проекту, його виконання та контроль за змінами проходять
через весь проект та постійно повторюються під час роботи над проектом.
Планування та виконання проекту включають визначення цілей проекту та
можливостей його успішного завершення. Контроль за змінами перевіряє план
проекту протягом його виконання, у такий спосіб можна бачити, що ці три
процеси тісно взаємопов'язані.
Управління інтеграцією проекту – це одна з дев'яти сфер управління
проектом:
‒ управління інтеграцією проекту;
‒ управління сферою дії проекту;
‒ управління часом проекту;
‒ управління витратами проекту;
‒ управління якістю проекту;
‒ управління персоналом проекту;
‒ управління зв'язками проекту;
‒ управління ризиком проекту;
‒ управління забезпеченням проекту.
19

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

Рисунок 2.1 – Схема інформаційного обміну в ІТ проекті

20

Cуміщення Scrum і Kanban технік. Як їх використовувати, адаптувати,
оптимізували для досягнення конкретних цілей, чому це треба і до чого може
призвести.
Scrum завжди справляється з усіма складнощами, до появи нового
специфічного проекту, наприклад:
Провели попередні роботи, налаштували оточення, підняли сервера і
організували робочий процес за звичною методологією Scrum. Провели
актуалізацію backlog і приступили до формування двох тижневого спринту.
Умова:
1. Планування
У процесі планування (Planning Poker, з картами і відносними одиницями
виміру трудомісткості S, M, L, XL, XXL), незважаючи на те, що завдання були
детально опрацьовані, і сформовані вимоги не викликали ніяких додаткових
питань, практична оцінка виявилася далеко не прозорою, нижченаведені умови
сформували першу проблему:
Проблема №1 - Планування, яке швидко втрачає свою актуальність:
 відсутність інформації про засоби і методи розробки раніше реалізованого
функціоналу;
 наявність незавершених завдань;
 неможливість оцінити стадію і відсоткове виконання завдань без
детального тривалого занурення в вихідні матеріали;
 проведення багатогодинного планування нераціонально.
 планування не раціонально, з тієї причини, що «підводні камені» заховані
в успадкованому коді і сотнях залежностях, неможливо передбачити на
початкових етапах роботи з кодом.
2. Розробка
На практиці все виявляється ще гірше. CMS (Система керування вмістом),
на якій створюється проект, може виявитись ґрунтовно переробленою,
документація часто не актуальною або повністю відсутньою. Активна
21

комунікація в команді, дозволяє пом'якшити поріг входження нових
розробників. Але все одно можна сильно недооцінити деякі завдання.
Проблема №2 – Багато термінових позапланових завдань.
Коли проект досить навантажений. На 3-й день розробки виявляються
критичні помилки, що вимагають моментального виправлення. Протягом усієї
ітерації доводиться перебудовувати плани, перемикатися між завданнями, і
прийматися за термінові завдання. Що тягне за собою додаткові витрати на
документування та відчуття повного безладу і хаосу.
Бажано ретельно підходити до розбору завдань перед покером. Це дає
деякі поліпшення, але проявляються інші складності.
Проблема №3 – Зміни пріоритетів завдань в ході ітерації.
Після оцінки можуть змінюватись пріоритети завдань, так як деякі з них
виявляються більш трудомісткими у порівнянні з уявленнями і перекривають
більш дрібні і термінові. План знову починає змінюватися, з'являються термінові
завдання, відбувається зміна пріоритетів.
Велика кількість позаштатних ситуацій вибиває з колії, працювати стає
складніше, падає продуктивність, більш того практично неможливо дати будь-
які адекватні оцінки успішності ітерацій.
Рішення:
Є дві Agile методології (Scrum і Kanban). Їх можна розібрати на
інструменти, взяти тільки необхідне.
Аналітик здійснює документування і розбір завдань з надходження,
складає їх в backlog.
Product Owner коригує пріоритети завдань.
Попереднє планування не здійснюється.
Розробник бере в розробку завдання з вищим пріоритетом з backlog.
Завершена задача надходить в тестування.
Проводяться необхідні перевірки.
При відсутності зауважень завдання повторно перевірятися на регресії або
очікує інші завдання, без яких її винесення до продукту неможливо.
22

Весь життєвий цикл проекту розділений на 2-х тижневі ітерації. Вони
носять лише формальний характер для можливості оцінити динаміку
продуктивності, а також хронологічно полегшують процес виконаних завдань.
Проведення демонстрації за підсумками кожної ітерації за спрощеною
схемою, демонструються тільки ті завдання, які вимагають додаткових
коментарів, інше замовник в змозі переглянути сам.
Кожна ітерація закінчується ретроспективою.
Основні інструменти методологій наведемо у табл. 2.1
Таблиця 2.1
Основні інструменти методологій
Scrum Kanban
 Ролі (Product Owner / Scrum  Як основна метрика для
Master / Команда) планування і поліпшення
 Пріоритезувати Product Backlog процесів використовується час
 Обмежені за часом ітерації. виконання завдання.
 Демонстрації по закінченню  Оцінки завдань опційні
ітерації  Можна додавати нові завдання,
 Daily Stand-up в будь-який момент часу.
 Безперервний потік завдань не
прив'язаний до ітерації

Відповідно треба визначити правила для ведення завдань в системі
контролю версій.
Результати:
 методика показує свої результати вже при першій ітерації:
 зростання продуктивності;
 позапланові завдання більше не змінюють загальних планів;
 поліпшення загального настрою і працездатності команди;
 збереження прозорості організованих процесів, все просто як для команди,
так і для замовника.
Звичайно, не всі проблеми вирішуються відразу, але відповіді починають
приходити самі собою, більше не потрібно ламати голову над кожною з них.
23

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

Рисунок 2.2 – Дошка Trello для проекту Queue Control

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

2.2 Управління змістом проекту
Структурною декомпозицією робіт (Work Breakdown Structure) називають
представлення проекту, виконане у вигляді ієрархічної структури робіт, що
досягається за допомогою послідовної декомпозиції. Інструмент спрямований на
детальне планування, оцінку вартості, визначення та розподіл персональної
відповідальності виконавців тощо – тобто, на основні роботи та результати, що
визначають зміст проекту
Переваги ієрархічної структури робіт (WBS) для менеджерів ІТ проектів:
 управління розробкою;
24

 управління проектами;
 agile;
 управління продуктом.
Поділ завдань на більш дрібні та керовані частини робить робочий процес
набагато простіше. Ієрархічна структура робіт WBS, або структура декомпозиції,
є схемою, де завдання проекту відображають їхнє ставлення один до одного і до
проекту в цілому.
Використання WBS: допомагає правильно організувати проекти; надає
допомогу в описі змісту проекту для зацікавлених сторін; допомагає розподілити
обов'язки; показує основні етапи проекту та всі ракурси контролю; дозволяє
правильно оцінити витрати, ризики та час робіт.
Декомпозиція завдань проекту Queue Control із використанням WBS
наведена на рис. 2.3.

Рисунок 2.3 – Ієрархічна структура робіт проекту Queue Control

WBS заснована на графічній природі, яка допомагає менеджерам проектів
25

передбачити результати, що базуються на різних сценаріях. Процес часто
описується як структура відгалуження, що охоплює всі етапи проекту в
організованому порядку. WBS також може бути представлена у вигляді
табличного списку задач та елементів у плані розбивки робіт діаграм Ганта.
Менеджери використовують структуру декомпозиції, щоб структурувати
та ділити проекти на легко керовані компоненти. Вони, у свою чергу,
поділяються доти, доки вони не призначаються конкретному фахівцю в команді.
Структура WBS стала популярною та широко використовується у розробці
програмного забезпечення завдяки її очевидним перевагам. Керівники проектів
сміливо її застосовують. І ось чому:
1. Посилення комунікації у команді проекту. Неважливо, чи має ІТ проект
внутрішню чи зовнішню спрямованість. Ієрархічна структура робіт включає
комунікаційні акти на кожному кроці.
2. Фокусування на кінцевих цілях. WBS допомагає тримати всю команду у
фокусі та зосередженій на кінцевій меті. Це зводить до мінімуму можливість
виконання непотрібної роботи.
3. Деталізація. Кожна деталь ретельно розглядається, тому в проекті нічого
не губиться.
4. Передбачення виникнення проблем. Коли проект буде готовий, можуть
виникнути проблеми. Ієрархічна структура робіт допомагає скоротити їх
кількість, оскільки всі деталі враховуються перед виконанням.
5. Колективний мозковий штурм. Менеджери використовують структуру
для мозкового штурму, щоб знайти корисні ідеї та рішення. З її допомогою їх
легко зібрати, а потім із них викреслювати непотрібні.
6. Питання планування. За допомогою WBS легко визначити, які із
запланованих завдань відстають від графіка.
7. Управління ризиками. Якщо використовуєтся WBS, зменшуються
ризики та здійснюється керування ними із самого початку. Це допомагає
розподілити всі ресурси: кошти, час та трудовитрати.
8. Розподіл завдань. Якщо структурувати проект, легше призначати
26

завдання конкретним людям.
9. Гнучкість для різних команд. Ієрархічна структура робіт
використовується у різних сферах. Не має значення скільки людей у команді:
WBS завжди буде підтримувати процес виконання проекту. Вона також може
стати чудовим інструментом для залучення клієнтів, оскільки показує процеси
зсередини і допомагає їх краще зрозуміти.
Якщо поєднати WBS та діаграму Ганта вийде покращений процес
планування. Для відображення ієрархічної структури робіт поширена практика
застосування діаграм Ганта. Саме вони чітко відображають всю структуру,
причому у дуже зручному вигляді. Діаграми Ганта використовуються у багатьох
програмах та сервісах для управління проектами, таких як GanttPRO, MS Project,
Wrike тощо.

Рисунок 2.4 – Діаграма Ганта GanttPRO для проекту Queue Control

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

критичний шлях.
Онлайн діаграма Ганта підходить і для керування командою проекту. Під
кожним завданням можна залишати коментарі, прикріплювати файли, ділитися
самим графіком, експортувати його до популярних форматів, переглядати
історію змін — командна робота справді зручна. Втім, як і відстеження інших
процесів, пов'язаних із управлінням проектами.

Рисунок 2.5 – Дошка GanttPRO

Ієрархічна структура робіт – поширений та зручний спосіб планування ІТ
та будь-яких інших проектів. А якщо відобразити її діаграмою Ганта, то у такому
вигляді вона значно спрощує процес не лише планування, а й управління. За
допомоги неї можна:
 ставити завдання та розподіляти їх між учасниками;
 задавати терміни виконання завдань, їх тривалість, прогрес;
28

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

Рисунок 2.6 – Mind map прототипу Queue Control

2.3 Управління часом проекту
Управління часом — одна з найважливіших підсистем проекту через те,
що поряд із витратами та якістю входить до «магічного трикутника» проекту та
визначає обмеження проекту по часу. Управління часом здійснюється на всіх
етапах життєвого циклу проекту, реалізуючись у різних функціях проект-
менеджменту. На етапі розробки проекту – це планування часу проекту, на етапі
реалізації – контроль виконання мережевого графіка та внесення змін по ходу
здійснення проекту.
29

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

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

Рисунок 2.7 – Тривалість розробки mvp для проекту Queue Control

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

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

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

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

виробничих потужностей — витрати, що повторюються. закупівля
комплекту обладнання — одноразові витрати;
 постійні та змінні за ознакою залежності від обсягу робіт;
 плату за понаднормовий робочий час.
Техніка оцінки витрат проекту включає 13 кроків, які можуть відрізнятися
залежно від проекту:
1) Визначення потреб роботи у ресурсах.
2) Розробка мережевої моделі.
3) Розробка WBS.
4) Оцінка витрат у розрізі WBS.
5) Обговорення WBS із кожним із функціональних управляючих.
6) Вироблення основного напряму процесів.
7) Оцінка витрат кожного елемента WBS.
8) Узгодження базових витрат із вищим рівнем управління.
9) Обговорення з функціональними керуючими потреби у персоналі.
10) Розробка OBS.
11) Розробка детальних графіків.
12) Формування сумарного звіту щодо витрат.
Включення результатів оцінки витрат у документи проекту. Оцінка
вартості проекту по суті є оцінкою всіх витрат, необхідних для його успішної та
повної реалізації:
 зобов'язання;
 бюджетні витрати (кошторисна вартість робіт, розподілена у часі);
 фактичні витрати (відтік готівки).
Зобов'язання виникають, наприклад, під час замовлення будь-яких товарів
чи послуг заздалегідь, досі їх використання у проекті. В результаті
виставляються рахунки, оплата за якими може здійснюватися або в момент
готовності товарів до постачання, або в момент їх отримання, або згідно з
прийнятою в організації політикою оплат. У будь-якому випадку, при замовленні
бюджет зменшується на суму цього замовлення. Нерідко вона враховується до
33

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

транспортування, управління інформацією, контроль якості та ін.;
 зняття продукції з виробництва.
Розрахунок вартості проекту Queue Control наведено на рис. 2.8-2.12.

Рисунок 2.8 – Розрахунок витрат capex та opex

Рисунок 2.9 – Заробітні ставка команди

Рисунок 2.10 – Сукупні витрати в місяць
35

Рисунок 2.11 – Розрахунок брутто

Рисунок 2.12 – Підсумок з урахуванням витрат

Фінансовий розрахунок прибутків та збитків (P&L), містить зведену
інформацію про доходи, витрати та прибутки/збитки компанії за певний період
часу. Звіт показує здатність компанії генерувати продажі, управляти витратами
та створювати прибуток. Оцінка складена за трьома точками оптимістична (A),
найбільш ймовірна (B) і песимістична (C) (рис. 2.13).

30000
25000
20000
15000
A
B
10000
C
5000
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
-5000

Рисунок 2.13 – Free Profit and Loss
36

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

2.6 Особливості реалізації ІТ-стартапів
Сьогодні стартап – це процес реалізації за короткі терміни і, як правило,
при невизначених початкових ресурсах завдання або проекту, що відрізняються
принциповою новизною для виконання яких компанія не має розроблених
стандартів. Це абсолютно нове завдання, яким раніше ніхто не займався.
Стартап або стартап-компанія (від англ. start-up - запускати) є нещодавно
запущеним проектом, мета якого - у найшвидший час окупити вкладені в нього
інвестиції та отримати прибуток. Як правило, такі компанії створені нещодавно,
перебувають у стадії розвитку чи дослідженні перспективних ринків.
Основними складовими стартапу є ідея, здатна принести великий
прибуток, кваліфікований і переконаний у можливості реалізації ідеї персонал та
наявність фінансів, які необхідно інвестувати в ідею на етапі її реалізації, поки
вона ще не окупатиметься.
Якщо більшість нових бізнесів йдуть по перевіреному аналогічними
проектами шляху, використовуючи готові канали та інструменти звернення до
цільової аудиторії, то стартап – це завжди крок у деяку невідомість, хоч і з
оціненими ризиками. Ідея стратапу в унікальності та відсутності в більшості
випадків бази аналогів.
Однак не всяка ідея може стати успішним стартапом. Особливістю
розвитку стартапу у порівнянні з плановим проектом є відсутність послідовного
плану дій та наявність ризиків. Унікальність ідеї не є запорукою успішного
стартапу, тому що вона може виявитися нереалізованою і вже на початкових
етапах можна зазнати величезних збитків. Тому важливо на початковому етапі
визначити, яка з ідей може стати успішною, яка є перспектива в розробці.
37

Автору проекту необхідно ухвалити рішення: запускати стартап або
доцільніше від нього відмовитися. Для цього необхідно оцінити позитивні та
негативні сторони ідеї, ризики реалізації та подальшого розвитку проекту.
При аналізі діяльності ІТ-стартапів, які були припинені, виявлено такі
фактори:
1) Відсутність доходу;
2) Клієнти не зацікавлені в дослідженнях або розроблюваному
продукті/послуги;
3) Не правильна оцінка ринку. Переоцінка розміру, запізній вихід на ринок;
4) Не затребуваний чи важкий у використанні продукт;
5) Не ефективні рішення у сфері продажу та маркетингу. Канали збуту
замість прямих продажів, відстрочка виходу на світовий ринок або надто
швидкий вихід;
6) Не правильна оцінка моменту. Продукт (послуга) впроваджений надто
рано чи надто пізно;
7) Не проінформованість про конкурентів і мінливі умови ринку.
Оцінка перерахованих вище факторів є непростим завданням. Як правило,
цим займаються експерти в галузі побудови стартапу. Але незважаючи на це,
оцінити всі фактори зі стовідсотковою точністю навряд чи вдасться. Це пов'язано
з самою сутністю ІТ-стартапа. Можна лише наблизитись до конкретних даних,
мінімізувати невизначеність.
Більшість проектів закривається з наступних причин:
 незнання свого споживача;
 відсутність потреби в товарі/послугі на ринку;
 неправильний підбір команди;
 слабкий маркетинг;
 вихід за межі встановленого бюджету.
Визначення «свого» споживача полягає в аналізі існуючого ринку та
визначенні цільової аудиторії. Правильність визначення цільової аудиторії, її
сегментація, аналіз, виявлення потреб, страхів, критеріїв вибору – це основа
38

побудови успішного ІТ-стартапу. Помилки на цьому етапі призводять до того,
що бюджети витрачаються марно і втрачається дорогоцінний час.
Щоб зібрати інформацію про цільову аудиторію, використовуються різні
методики: від анкет, особистих інтерв'ю, опитувань поштою, до використання
технічних засобів у вигляді найпростіших датчиків та застосування
комп'ютерних технологій.
При виході на ринок з новим продуктом/послугою важливо враховувати
ситуацію, що склалася на ринку. Необхідно проаналізувати наявні товари та
розрахувати потребу у запропонованому продукті. Відсутність потреби у новому
продукті призведе до провалу.
Команда грає велике значення у майбутній роботі стартапу. Експерти
вважають, що близько 70% успіху нового бізнесу на ранній стадії залежить від
команди компанії. Обгрунтування просте: все може піти не так, і тільки відмінна
команда зможе ефективно реагувати на ситуацію, що змінюється на ринку,
«підступи» конкурентів, проблеми фінансування та інші несподіванки.
Команда ІТ-стартапу повинна ґрунтуватися на технічних кадрах, але також
мати сильні управлінські кадри. Менеджери є життєво важливою частиною
технологічного стартапу. Якщо без технічної частини команди неможливо
створити новий продукт, то без сильного управління неможливо вивести його на
ринок і успішно просувати до споживачів.
Немає сенсу наймати занадто багато співробітників однієї спеціалізації.
Команда ІТ-стартапу повинна володіти набором різноманітних навичок та
досвідом, необхідним для реалізації ідеї.
На ранньому етапі не варто брати до команди висококваліфікованих,
дорогих співробітників. По-перше, це може вимагати надто багато засобів та
зусиль. По-друге, надто рання поява в команді професіоналів може призвести до
катастрофи - їхній авторитет може стати гальмом у роботі всієї команди. Краще
спиратися на фахівців середнього класу, які прагнуть досягти успіху. Це буде
запорукою їхньої активності та ініціативності.
39

Під час створення управлінського апарату головним завданням стає
розподіл функціональних ролей між членами команди, забезпечення управління
кожный ділянці.
Маркетинг у період запуску нового проекту передбачає гнучкість,
адекватну та оперативну реакцію на умови ринку. Дуже важливо ставити
виміріні цілі та фокусувати всі свої зусилля на їхньому досягненні.
Ключову роль маркетингу грає розуміння інтересів аудиторії. У сучасному
житті є багато каналів досягнення аудиторії – пошукові системи, журнали та
блоги, соціальні мережі, форуми – мільйони людей. Залишається лише
запропонувати те, що споживачеві цікаво.
Інтереси аудиторії лежать в основі просування у пошукових системах,
оптимізації конверсій сайту, реклами та роботи із спільнотами. Це називається
inbound-marketing (вхідний маркетинг) – користувачі самі знаходять необхідний
продукт/послугу, заходять та залишають свої контактні дані, тому що бачать
щось цікаве та хочуть це отримати.
Визначення бюджету є важливим кроком. Якщо кошти на розвиток
закінчаться раніше, ніж буде досягнуто мети, це, швидше за все, стане кінцем
проекту.
При визначенні бюджету важливо врахувати всі напрямки витрат
реалізації ІТ-стартапу. Практика показує, що близько 80% бюджету йде на
заробітну плату розробників. Бюджет просування має становити трохи більше
20% від загальної суми.
Витрати на офісне приміщення не є обов'язковими, але вважається, що
краще всій команді працювати під одним дахом. Слід також пам'ятати про оплату
зв'язку та послуг Інтернету, витрати на інфраструктуру (хостинг, домени тощо),
бухгалтерію та звітність.

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

що проект відповідає вимогам, заради яких він був прийнятий. Під якістю
розуміється цілісна сукупність характеристик об'єкта, що належать до його
здатності задовольняти встановлені чи передбачувані потреби.
У проекті можна виділити два аспекти, які необхідно розглядати у
нерозривному взаємозв'язку та взаємозалежності. Якісне управління - запорука
якісного продукту. Тільки якісний проект може створити якісний продукт. Під
якісним керуванням проектом можна розуміти планування проекту, виконання
робіт проекту, ресурсне планування проекту, контроль усіх аспектів роботи з
проекту. Еволюцію Quality Management зображено на рис. 2.14.

Рисунок 2.14 – Еволюція формулювання “якості”

Критичним аспектом якості в контексті управління проектами є
необхідність відображення вимог у змісті проекту. Важливо задовольнити
вимоги всіх груп замовників та зацікавлених сторін (за можливості).
Якість – результат якісних процесів, а не постійного контролю.
Основні принципи управління якістю PMI:
1) Задоволення замовника. Забезпечення як формальних вимог замовника
(зафіксованих у контракті), так і неформальних очікувань кінцевих
користувачів від використання ними продукту;
41

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

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

43

Ком анд Умови
а
Замало досвіду праці Відсутність зарплатні на стадії mvp
Втома Робота на Робота в вільний час
після основного виду
Заваіднсттаажнеінні зайнятості
Мотивація
сть Якість
продукту не
відповідає
Відповідність ТЗ Актуальність вимогам

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

Уп равлінн Обладнання
я
Рисунок 2.15 – Діаграми Ішикави проекту Queue Control

2.8 Управління ризиками проекту
Будь-який проект нерозривно пов'язаний з невизначеністю та ризиками.
Невизначеність у проекті – це брак або відсутність інформації, знань чи
розуміння можливих наслідків дій, рішень чи подій, що вживаються.
Результатом невизначеності є ризики. Один із процесів в управлінні проектом –
управління ризиками. Як і інші процеси, він є «наскрізним» для проекту і є
присутнім на всіх стадіях його життєвого циклу.
Відповідно до визначення американського довідника в галузі управління
проектами PMBOK, ризик проекту – це невизначена подія або умова, яка у разі
виникнення має позитивний чи негативний вплив, щонайменше, на одну з цілей
проекту, наприклад, терміни, вартість, зміст чи якість. Наголошується на
значущості того, що ризик у проекті може мати не лише негативний, а й
позитивний вплив на проект, тобто призводити до покращення якісних та
кількісних характеристик кінцевих цілей проекту. Відповідно, можна виділити
негативні ризики, позитивні ризики та непередбачені обставини:
44

1. Негативні ризики – загрози, іншими словами, події, що ведуть до
погіршення якості виконання проекту, що вимагають залучення додаткових
витрат ресурсів та часу або, ймовірно, знижують якісні характеристики
кінцевого результату.
2. Позитивні ризики – можливості, або події, що дають шанс покращити
якість реалізації проекту та досягти цілей, можливо, з меншими витратами
ресурсів та часу або вищою якістю.
3. Непередбачені обставини – те, що неможливо було або не змогли
передбачити на стадії визначення ризиків.
Ризик може бути викликаний однією або декількома причинами і у разі
виникнення будь-якої з цих точно не відомих заздалегідь подій може вплинути
на вартість проекту, його розклад чи виконання. Ризики визначаються як
зовнішніми стосовно проекту чи організації аспектами – умовами середовища, -
і внутрішніми – умовами реалізації проекту.
Для підвищення якості виконання проекту та досягнення кінцевих цілей
менеджер проекту реалізує процес управління ризиками.
Управління ризиками – це систематичний процес зниження
невизначеності та управління ймовірністю подій у проекті. Мета управління
ризиками проекту – підвищення ймовірності виникнення та впливу сприятливих
подій і зниження ймовірності виникнення та впливу несприятливих для проекту
подій.
Весь процес управління ризиками проекту поділяється на окремі
підпроцеси, які виникають щонайменше один раз у кожному проекті, а деякі
реалізуються на кількох стадіях проекту, носячи ітеративний характер:
1. Планування управління ризиками – інтегруючий процес вибору підходу,
планування та виконання операцій з управління ризиками проекту. Реалізується
на стадії планування проекту.
2. Ідентифікація ризиків – визначення того, які ризики можуть вплинути на
проект та документальне оформлення їх характеристик. Виникає на стадії
45

планування проекту, але носить характер, що повторюється, виникаючи
періодично для поповнення реєстру ризиків проекту в міру його реалізації.
3. Якісний аналіз ризиків – розташування ризиків за рівнем їх пріоритету
для подальшого аналізу або обробки шляхом оцінки та підсумовування
ймовірності їх виникнення та впливу на проект.
4. Кількісний аналіз ризиків – кількісний аналіз потенційного впливу
ідентифікованих ризиків на загальні цілі проекту.
5. Планування реагування на ризики – розробка можливих варіантів та дій,
що сприяють підвищенню сприятливих можливостей та зниженню загроз для
досягнення цілей проекту.
6. Моніторинг та управління ризиками – відстеження ідентифікованих
ризиків, моніторинг залишкових ризиків, ідентифікація нових ризиків (і
пов'язаний процес якісного та кількісного аналізу, а також вироблення планів
реагування), виконання планів реагування на ризики та оцінка їх ефективності
протягом життєвого циклу проекту.
Таблиця 2.2
Процес управління ризиками на всіх стадіях проекту
Моніторинг
Ініціація Планування Виконання та Завершення
управління
Управління Планування Моніторинг
ризиками управління та управління
проекту ризиками ризиками
Ідентифікація
ризиків

Якісний
аналіз ризиків

Кількісний
аналіз ризиків

Планування
реагування на
ризики

Незважаючи на те, що в групі процесів ініціації, виконання та завершення
не показані підпроцеси управління ризиками проекту, управління ризиками
46

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

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

– інше.
Умови передачі відповідальності за певні ризики третій стороні можуть
визначатися у контракті.
У багатьох випадках у контракті з оплатою фактичних витрат витрати на
ризики можуть перекладатися на покупця, а в контракті з фіксованою ціною
ризик може перекладатися на продавця, якщо розробка проекту вже перебуває у
стабільному стані.
Контракт із фіксованою ціною означає, що робота буде зроблена за
вартістю, визначеною на початок проведення робіт. До контракту можуть бути
додані умови щодо фіксації строків зі штрафними санкціями за затримки. За
умови використання договору з фіксованою ціною менеджер проекту знає точну
вартість складової частини проекту. Договір ефективно передає ризики витрат та
часу на підрядника, перевищення витрат повністю лягає на субпідрядника. Мінус
цього способу: підрядник частково закладе ці ризики у вартість контракту.
Передача ризику страхуванням можлива, якщо є можливість оцінки ризику
і страхова компанія готова прийняти його за певну премію. Або контрагент може
і готовий керувати ризиком, знову ж таки, отримавши за це певну премію за
ухвалення ризиків проекту. Проблема варіанта страхування полягає в тому, що в
ряді випадків для ризикового брокера важко визначити події та умови ризику,
особливо якщо він не знайомий зі специфікою проекту, або процес оцінки
ресурсомісткий.
Більш м'яким варіантом передачі є поділ ризиків, якому приділяється
дедалі більше уваги останніми роками. За цієї стратегії відповідальність за ризик
несуть обидві сторони договору при реалізації проекту. Розподіл ризиків між
постачальником та командою проекту ініціює взаємовигідний процес
покращення, спонукаючи постачальників до інновацій. Однак подібний метод
несе в собі додатковий ризик того, що пропоновані інновації не запрацюють, при
цьому інноваційний процес відволікає ресурси як у постачальника, так і команди
проекту.
49

У разі реалізації стратегії поділу або передачі ризику команда проекту несе
витрати до реалізації ризикової події.
Стратегія зниження (пом'якшення) ризиків передбачає:
 зниження ймовірності реалізації ризику;
 зниження наслідків негативної ризикованої події до прийнятних меж –
ризик або не здійсниться, або здійсниться, але з меншими наслідками.
Вживання запобіжних заходів щодо зниження ймовірності настання
ризику або його наслідків часто виявляється більш ефективним, ніж зусилля
щодо усунення негативних наслідків, які вживаються після настання події
ризику.
Як приклади заходів щодо зниження ризиків можна навести:
1. Впровадження менш складних процесів, структурне спрощення,
деталізацію процесів до такого рівня, що дозволить достатньо знизити
ймовірність реалізації ризику. Крім спрощення процесів, ймовірність ризиків
може знизити детальніший опис процесів або застосування додаткових програм
навчання персоналу проектів.
2. Проведення більшої кількості випробувань чи реалізацій прототипів, у
яких виробляється відпрацювання основних рішень проекту.
3. Вибір постачальника, постачання якого мають більш стабільний
характер. Вибір може проводитись на підставі даних архівів попередніх проектів.
Для зниження ризиків може знадобитися розробка прототипу, на основі
якого здійснюється пропорційне збільшення ймовірності ризику від стендової
моделі до процесу або продукту. Якщо неможливо знизити ймовірність,
ослаблення ризику має бути спрямоване на наслідки ризику, а саме – на ті зв'язки,
які визначають їхню серйозність. Наприклад, розробка дублюючої підсистеми
може скоротити наслідки відмови основної системи.
У разі вибору стратегії зниження, команда проекту несе витрати до
реалізації ризикової події.
Стратегії реагування на позитивні ризики.
50

Використання. Ця стратегія може бути обрана для реагування на ризики
з позитивним впливом, якщо необхідно, щоб ця сприятлива можливість була
гарантовано реалізована. Ця стратегія призначена для усунення всіх
невизначеностей, пов'язаних з ризиком верхнього рівня, за допомогою заходів,
що забезпечують появу цієї сприятливої можливості у різних формах.
До заходів прямого реагування на цю можливість відносяться залучення до
участі в проекті більш талановитого персоналу, щоб скоротити час, необхідний
для його завершення, або забезпечення вищої якості, ніж було передбачено
початковим планом.
Команда проекту може нести витрати до реалізації ризикової події з метою
збільшення його ймовірності та отримання позитивних результатів після його
реалізації. Або витрати здійснюються після реалізації події, при цьому команда
проекту не впливає на ймовірність події, але використовує ризик, що
реалізувався, з метою проекту, з тим щоб поліпшити його якісні характеристики.
Спільне використання позитивних ризиків передбачає передачу
відповідальності третій стороні, здатній найкращим чином скористатися
сприятливою можливістю в інтересах проекту.
До заходів із спільним використанням сприятливих можливостей належить
утворення партнерств із спільною відповідальністю за ризики, команд,
спеціалізованих компаній чи спільних підприємств, створених спеціально для
управління сприятливими можливостями.
Посилення. При застосуванні цієї стратегії змінюється «розмір»
сприятливої можливості шляхом підвищення ймовірності виникнення та/або
позитивної дії, а також шляхом виявлення та максимізації основних джерел цих
позитивних ризиків. Для підвищення цієї ймовірності можна спробувати
полегшити чи зміцнити причину, що викликає сприятливу можливість, та
цілеспрямовано посилити умови її появи. Можна також вплинути на джерела
впливу, намагаючись підвищити чутливість проекту до цієї сприятливої
можливості.
Загальні стратегії реагування на ризики.
51

Прийняття. Ця стратегія означає, що команда проекту прийняла рішення
не змінювати план проекту у зв'язку з ризиком або не знайшла іншої відповідної
стратегії реагування на ризики, оскільки або ймовірність ризику занадто мала,
або ефект від ризику занадто великий і його вплив на цілі проекту у разі
реалізації ставить під питання ключові цілі проекту. Ця стратегія може бути
застосована або до загроз, або до сприятливих можливостей. Вона може бути або
активною, або пасивною.
Ця стратегія використовується у випадках, коли:
– виключити всі ризики із проекту малоймовірно;
– наслідки ризику настільки великі, що недоцільно розробляти варіанти
передачі з метою зменшення впливу на проект;
– ймовірність ризику та його наслідки малі, його можна прийняти, оскільки
вартість розробки заходів з управління ризиком перевищує вартість
наслідків.
Пасивне прийняття цієї стратегії передбачає проведення будь-яких
запобіжних заходів, залишаючи команді проекту право діяти на власний розсуд
у разі настання події ризику.
Найбільш поширена форма активного прийняття даної стратегії -
створення резерву на непередбачені обставини, що включає час, гроші або
ресурси для управління відомими - або, в деяких випадках, потенційними і навіть
невідомими - загрозами і сприятливими можливостями.
Вибір стратегії реагування на ризики.
Вибір стратегії реагування на ризики визначається ймовірністю реалізації
ризику, що оцінюється величиною наслідків ризику у разі реалізації. Можливе
застосування одночасно кількох стратегій, якщо ймовірність ризику велика і
величина його наслідків також велика.
Якщо негативний ризик мінімальний, то, ймовірно, менеджеру доцільніше
прийняти ризик, оскільки розробка плану реагування вимагатиме більше коштів,
ніж наслідки від ризику. У зоні помірного ризику менеджер проекту, швидше,
вибиратиме між стратегією передачі та/або зниження ризику. Зі збільшенням
52

ймовірності ризику та величини наслідків – наближенням до верхнього правого
кута квадрата малюнка - менеджер проекту схилятиметься до застосування
стратегії ухилення або застосовуватиме комплексне рішення зі стратегії передачі
та зниження, якщо з будь-яких причин ухилення неможливо. Таким чином, у разі
негативних ризиків, менеджер буде прагнути зміститися до нижнього лівого кута
квадрата – зони мінімального ризику, - обираючи ту чи іншу стратегію чи
комплексний підхід із кількома стратегіями.
У разі позитивних ризиків, його дії будуть зворотними, стимулюючи
зміщення у верхній правий кут (табл. 2.3).
Таблиця 2.3
Порівняння стратегій реагування на ризики
Заходи до Заходи

ризикової після Коли Формат реалізації

події ризикової застосовується (приклад)
події
Негативні ризики
Наслідки ризику Альтернативний
+ великі; сценарій реалізації
проекту
Імовірність ризику Уточнення умов на
велика, і вона має стадії ініціації та
Ухилення значні наслідки; планування з метою
знищення ймовірності
ризикової події
Умови реалізації
ризику поза зоною
контролю менеджера
проекту
Є можливість
оцінити величину
наслідків, і є
компанії
(страховики), які
+
готові розділити Страховий договір
Передача
ризик або умови
передачі ризиків
(партнери згодні на
умови контракту)

Умови в договорі /
контракті
Зниження + Можливе виділення Багаторазові попередні

ресурсів на випробування або
53

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

Можливість ризику Створення резервів
+ дуже низька ресурсів
Наслідки ризику
дуже низькі,
дешевше вжити
Прийняття ризику, ніж
розробляти заходи
Наслідки ризику
дуже низькі,
дешевше вжити
ризику, ніж
розробляти заходи

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

події, які приводять у дію механізм реагування на непередбачувані обставини,
наприклад, відсутність проміжних контрольних подій чи присвоєння певному
постачальнику високого рівня пріоритетності. Моніторинг ризиків та реалізація
планів дій у разі їх реалізації вимагає закладання до бюджету та планів проекту
резервів на ризики – резервів на відоме невідоме.
Однак у будь-якому проекті є те, що не можна передбачити. Для впливу на
подібні події у проекті створюється управлінський резерв (бюджетний фонд),
який використовується командою управління проектом у разі виникнення
подібних обставин.
Яку б стратегію реагування на ризик не вибрав менеджер проекту, план
реагування на ризик та формування резервів на його забезпечення проводиться
до можливої реалізації ризику.
Таблиця 2.4
Оцінка ризиків по категоріям для проекту Queue Control
Категорія
ризику Ризик Малий Середній Високий Оцінка

ризику

Клієнт  Зацікавленність + 4
 Актуальність 5
 Згідність з ціною

Команда  Організація + 3
роботи + 5
 Завантаженість 6
 Мотивація +
3
 Кваліфікація
 Хвороба
Розробка  Баги + 10
 Дизайн 4
 Вимоги + 4
 Тривалість

Конкуренти  Вища якість + 4
продукту
+ 4
55

 Розвинутіщі
маркетингові
канали

Впровадження  Відсутність + 8
репутпції
 Відсутність + 7
досвіду

Таблиця 2.5
Оцінка ризиків і методи боротьби з ними
Ризик Оцінка
ризику Методи боротьби

 Баги 10 Багів боятись не потрібно, головне вчасно
 їх виявляти та виправляти
 Хвороба члену Дотримання норм карантину під час
команди 9
пандемії
 Відсутність Репутація – це нематеріальний актив, який
репутпції складається самостійно незалежно від того,
 докладають зусилля для її побудови чи ні.
Розуміючи важливість і залежність від неї
різних аспектів бізнесу, у тому числі
8 фінансового результату, треба брати
репутацію під контроль і починати активні
дії щодо поліпшення становища, що вже
склалося, або створення і підтримання
свого нового статусу.
 Відсутність Потрібно не тільки виконувати локальні
досвіду задачі, а й пам'ятати про саморозвиток в
7 відповідних сферах.
Можливо варто залучити додаткових
людей, або звернутися до аутсорс фахівців.
 Згідність з ціною 6 Треба розмовляти з клієнтом.
 Мотивація Потрібно розмовляти з командою. Та
6 наявність реального профіту, окрім
цікавого процессу розробки.
56

Потрібно щоб люди знали для чого
працюють і хотіли це отримати, а також
справедливі вихідні та гарні відносини в
середені команди
 Тривалість 6 Повна команада, якісне управління.
 Актуальність Треба слідкувати за ринком, та
актуальністью проблематики.
5 Мати альтернативні варіанти
переорієнтування.
 Завантаженість Організація роботи, наявність необхідних
5 фахівців.
 Зацікавленність Треба не затягувати терміни та не втрачати
клієнтом зв'язок з клієнтом. Мати додаткові
4 можливості масштабування продукту з
цікавими перспективами.
 Дизайн 4 Треба звертатись до професіоналів
 Вища якість Завчасно вивчати аналоги, і продовжувати
продукту у 4 слідкувати за ними під час розробки.
конкурентів
 Організація роботи Вивчення методологій управління
3 допоможе
 Кваліфікація Якісні співбесіди та курси по підвищенню
2 кваліфікації

Наведений аналіз свідчить:
1. Кожен проект пов'язаний із невизначеністю. Невизначеність породжує
ризики проекту.
2. Ризики бувають як негативними –які несуть загрози проекту, так і
позитивними – які можуть надати можливості проекту.
3. Для підвищення якості реалізації проекту та збільшення ймовірності
досягнення поставлених цілей керівник проекту разом із командою проекту
керує ризиками, підвищує ймовірність позитивних ризиків та знижує
ймовірність негативних ризиків.
57

4. Стратегії реагування на негативні ризики: ухилення, зменшення,
поділ/передача.
5. Стратегії реагування на позитивні ризики: використання, спільне
використання, посилення.
6. Загальна стратегія реагування ризики – прийняття.

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

 підтримання та оновлення базового (цільового, директивного, опорного
тощо) плану (графіка) проекту, що використовується для порівняння з
планами, що створюються в процесі виконання проекту;
 виправлення базисного плану пов'язане головним чином із змінами змісту
проекту, але з іншими змінами, які мають враховуватися під час
розрахунку у плані проекту під час виконання;
 необхідна зміна змісту проекту під час виправлення змісту його результату
(продукту, товару, послуги тощо);
 координацію та узгодження змін у взаємопов'язаних видах інформації,
функціях, процесах та процедурах управління проектом.
Вхідні дані єдиного контролю змін містять базовий (цільовий,
директивний, опорний тощо) план (графік) проекту, звітність про хід реалізації
проекту та вимоги до змін у проекті.
Для єдиного контролю змін застосовується набір формальних процедур,
встановлених внутрішньофірмовими нормами реалізує проект організації, які
визначають зведення правил змін прийнятих до цього часу офіційних документів
проекту та порядок їх прийняття. Таким прикладом можливо, що утворилася у
створенні система документообігу. Якщо такої системи немає, то особового
складу проекту слід створити подібну систему чи пристосувати спеціальні
програмні оболонки (наприклад, програмний продукт " Expedition " компанії "
Primavera Systems " ), у яких здійснено найпоширеніші й проявили себе
практично методи і засоби управління змінами. Створення системи у разі стає
частиною проекту, причому дуже важливою. Для контролю змін застосовуються
і процедури обробки змін, які можуть бути затверджені без попереднього
розгляду (наприклад, у ході регламентних робіт з обмеженим часом прийняття
рішення або у разі надзвичайних ситуацій). Для таких заздалегідь обумовлених
випадків підсистема контролю змін має дозволяти "автоматично" затверджувати
певні категорії змін. Як і будь-які інші зміни, ці зміни мають бути в
обов'язковому порядку запротоколовані та прийняті до уваги, щоб не виникло
проблем надалі через відсутність інформації про цей стан справ щодо проекту.
59

затверджувати певні категорії змін. Як і будь-які інші зміни, ці зміни мають бути
в обов'язковому порядку запротоколовані та прийняті до уваги, щоб не виникло
проблем надалі через відсутність інформації про цей стан справ щодо проекту.
затверджувати певні категорії змін. Як і будь-які інші зміни, ці зміни мають бути
в обов'язковому порядку запротокольовані та прийняті до уваги, щоб не виникло
проблем надалі через відсутність інформації про цей стан справ щодо проекту.
Результати загального контролю змін включають модифікований базовий
план проекту з урахуванням встановлених змін, які доводяться до учасників
проекту.
Функції загального контролю змін закріплюються за комісією (групою)
контролю змін (Change Control Board), яка займається затвердженням чи
відхиленням запитів на зміни. Права та обов'язки комісії чітко визначені та
узгоджені з основними учасниками проекту. У великих та складних проектах
може працювати одночасно кілька комісій із різними правами та обов'язками.
Контроль змін змісту проекту відтворюється: для оцінки впливу факторів,
що призводять до позитивних чи негативних змін змісту проекту; визначення
змін змісту проекту; для управління змінами змісту проекту за її появи. Контроль
змін змісту був із іншими процесами контролю.
Наступні елементи проекту та фактори, що впливають на його реалізацію,
можуть змінюватися:
 цілі та плани проекту;
 механізми реалізації проекту;
 використання ресурсів;
 контракти та зобов'язання щодо них;
 використовувані стандарти та нормативи;
Причинами змін у змісті робіт можуть бути:
o зміни кон'юнктури над ринком;
o дії та наміри конкурентів;
o технологічні зміни, зміни в єнах та доступності ресурсів;
o економічна нестабільність;
60

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

процес контролю за реалізацією змін. За відсутності такого контролю менеджеру
проекту буде важко контролювати виконання робіт частини проекту, що
залишилася.
У досить загальному вигляді цей процес має регламентувати проходження
змін через п'ять основних стадій.
1. Опис. На початковій стадії необхідно зрозуміти та описати пропоновану
зміну. Пропозиція документується та обговорюється.
2. Оцінка. Друга стадія передбачає повномасштабний аналіз впливу
запропонованої зміни. Для цього проводиться збирання та узгодження всієї
інформації, необхідної для оцінки наслідків цієї зміни. Результати дослідження
документуються та обговорюються.
3. Схвалення. У третій стадії розглядаються результати досліджень та
приймається рішення: схвалити зміну, відмовити, відкласти. Якщо прийнято
рішення відкласти реалізацію зміни, необхідно провести додаткові дослідження
та розрахунки. Якщо приймається позитивне рішення, то затверджуються
виконавці та виділяються кошти на проведення зміни. Ухвалені рішення
документуються.
4. Реалізація. Зміна вноситься у план проекту та реалізується.
5. Підтвердження виконання. Контроль коректного та повного виконання
робіт у рамках цієї зміни. У разі позитивного результату зміна знімається з
контролю.
Кожна стадія виконується відповідно до затвердженого регламенту та
передбачає певний розподіл ролей серед учасників проекту.
Документом спеціального призначення регламентується проведення
переговорів та ухвалення рішення про реалізацію зміни, в яких бере участь
менеджер, реалізує цю частину проекту, представник замовника, а за потреби —
і представники зацікавлених організацій.
Таким чином, в ідеальному випадку контроль реалізації змін є
комплексною технологією управління проведенням зміни проекту з відповідним
набором документації та розподілом обов'язків.
62

2.10 Контроль проекту
На хід реалізації проекту впливають безліч як зовнішніх, так і внутрішніх
факторів, що дестабілізують. Це призводить до зміни розрахункових параметрів
(тимчасових та вартісних). Важливо своєчасно вживати заходів щодо
коригування ходу виконання робіт у зв'язку з умовами навколишнього
середовища проекту, що змінюються, і мотивувати підлеглих на досягнення
поставлених цілей.
У цих умовах одним із важливих засобів реалізації поставленої мети є
моніторинг за ходом реалізації проекту.
Моніторинг — це процес, за допомогою якого проект-менеджер визначає,
чи правильні його рішення, як здійснюється проект (за часом, вартістю,
ресурсами), чи не потрібні коригування.
Завдання моніторингу полягають у тому, щоб отримати фактичні дані про
хід виконання проекту, зіставити їх із плановими характеристиками і виявити
відхилення, виходячи з яких будуть прийняті наступні управлінські рішення.
Моніторинг має забезпечити:
 облік (систематичне та планомірне спостереження за всіма процесами
реалізації проекту);
 виявлення відхилень від цілей реалізації проекту за допомогою низки
критеріїв та обмежень, які фіксуються в календарних планах, бюджетах,
розрахункових потребах у трудових та матеріальних витратах, фінансових,
нормативних та ін.;
 прогнозування наслідків ситуації, що склалася;
 обгрунтування необхідності прийняття коригувального впливу .
Прийнятні рівні відхилень мають бути визначені від початку проекту.
Наприклад, у дослідному проекті прийнятні відхилення можуть бути досить
великими – до 20%. Оскільки дослідження завжди несуть значну частку
невизначеності, план досліджень неминуче буває приблизним.
Як функцію управління моніторинг не слід змішувати з урахуванням та
статистичним контролем. Облік обмежується спостереженням, виміром,
63

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

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

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

Тимчасові витрати порівнюють з розрахунковою тривалістю та
порівнюють з обсягами виконаних робіт.
Дані про фактичне споживання матеріально-технічних ресурсів
зіставляють з передбачуваними потребами у робочій силі, матеріалах та
устаткуванні, виконують аналогічні операції.
Грошові витрати порівнюють із показниками бюджету чи кошторисної
вартості.
До блоку показників, що характеризують виконання бюджету, належать:
 початкова калькуляція;
 поточні рахунки, що включають фактичні прямі витрати;
 накладні витрати та інші витрати;
 інтегральні показники вартості проекту.
До блоку показників, що характеризують витрати матеріально-технічних
ресурсів, належать:
 витрата матеріалів та обладнання;
 витрата трудових ресурсів.
Зрештою досвідчений професійний менеджер проекту може сам визначити
ступінь чи відсоток готовності об'єкта загалом чи виконання окремої операції.
Розрізняють такі методи вимірювання фактично виконаних обсягів робіт:
 обсяги або витрати у фізичних одиницях або в рублях;
 відсоток виконання планових завдань;
 відсоток готовності та ін.
Вимірювання та оцінки описують різні сторони процесу здійснення даного
проекту. Усі вони однаково необхідні і мають значення для повноти розуміння
ступеня виконання заданих обсягів робіт.
Залежно від необхідної точності розрізняють такі технології оцінки
виконання проекту:
 контроль у моменти закінчення робіт (метод "0-100");
 контроль у моменти 50% готовності робіт (метод "50-50");
67

 контроль у заздалегідь визначених точках проекту (метод контролю за
віхами);
 регулярний оперативний контроль (через рівні проміжки часу);
 експертна оцінка ступеня виконання робіт та готовності проекту.
Інформація, що відображає стан та хід виконання заданих обсягів робіт,
надходить із численних джерел (члени проектної команди, організації-
виконавці, незалежні контролери, планові та звітні документи). У формальній
інформаційній системі джерела інформації включають картки табельного обліку
трудовитрат та експлуатації обладнання, замовлення на поставки, рахунки-
фактури, повідомлення з місця виконання робіт про фактично виконані обсяги,
звіти з контролю якості тощо. У всіх випадках до найважливіших аспектів
контролю відносяться точність, своєчасність та повнота.
Крім формальних джерел інформації існує велика кількість інших вхідних
даних, призначених для забезпечення служб управлінської діяльності; деякі з них
скорочують звичайний шлях проходження інформації.
Для кожного ієрархічного рівня керівництва потрібна своя, специфічна,
планова та звітна інформація про хід виконання робіт комплексу. Ця специфіка
проявляється у двох аспектах – у широті охоплення інформацією загального
комплексу робіт та ступеня деталізації інформації. Раціональне поєднання цих
ознак інформації, що надається керівникам різного рівня, є одним із центральних
завдань при проектуванні інформаційних систем контролю проекту.
Неправильне поєднання цих ознак призводить або до недостатності, або
надмірності інформації і, отже, негативно позначається на ефективності
управління.
Керівники кожного рівня повинні отримувати тільки ту інформацію і в тій
мірі деталізації, яка необхідна та достатня для вироблення регулюючих впливів
та прийняття рішень щодо закріплених за ними частин проекту. Водночас ця
інформація має забезпечувати концентрацію їхньої уваги на найбільш
напружених та відповідальних ділянках роботи.
68

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

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

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

71

2.11 Висновки до розділу
В другому розділі було описано особливості інвестиційної фазу проекту
Queue Control. Також розглянуто такі аспекти управління проектом за PMBoK як
розробка ієрархічної структури роботі; управління часом проекту,
використовуючи розроблений календарний план, діаграму Ганта; управління
вартістю проекту; управління якістю шляхом розробки діаграми Ісікаві;
управління ризиками проекту шляхом визначення ризиків та стратегій керування
ризиками.

72

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

Встановлення інтервалу залежить від низки факторів:
– загальна тривалість інвестиційного періоду (чим більше період, тим
більший інтервал);
– прогнозована періодичність грошових надходжень та виплат;
– бажана точність отримання прогнозних оцінок.
Прогноз витрат на реалізацію окремих процесів проекту (табл. 3.1) :
Таблиця 3.1
Прогноз витрат на реалізацію окремих процесів проекту
Напрямки
витрат Місяці, тис. грн.

(процеси) 1 2 3 4 5 6 7 8 Всього
1. Технологічне
проектування 8 8

2. Оренда і
утримання
офісних 8 8 8 8 8 40
приміщень
(щомісячно)
3.
адміністративні
витрати 12 12 12 12 12 12 12 84
(щомісячно)
4. Придбання
обладнання 10 10 10 30

5. Придбання
комплектуючих 180 180 180 180 720

6. Утримання
групи
спеціалістів 60 60 60 60 60 300
(щомісячно)
7. Створення
матеріальних 200 200
запасів
8. Тестування 30 30
9. Утримання
виробничих
площ 13 13 26
(щомісячно)
10. Створення
реалізаційної 25 25 50
мережі
11. Набір і
навчання 20 20
персоналу
12.
Впровадження 35 35

Всього 8 20 30 270 270 260 520 165 1543

74

Таблиця поточних потреб у капіталовкладеннях та розрахунок відсотків за
кредит (табл. 3.2).
Таблиця 3.2
Поточні потреби у капіталовкладеннях та розрахунок відсотків за
кредитом
0,16 0,98039 7,843137 7,84313
1 8 8

28 0,4 0,96116 19,22338 26,9127
2 20

58 0,6 0,94232 28,26967 54,6546
3 30

328 5,4 0,92384 249,4383 303,021
4 270

598 5,4 0,90573 244,5473 541,627
5 270

858 5,2 0,88797 230,8726 761,879
6 260

1378 10,4 0,87056 452,6913 1199,63
7 520

1543 3,3 0,85349 140,8259 1316,93
8 165

Графічне зображення поточних потреб у капіталовкладеннях та
розрахунок відсотків за кредит наведено на рис. 3.1-3.3.
75
Місяці
Потреба в
капіталовкладеннях
Потреба в
капіталовкладеннях
з наростяючим
підсумоком
Відсоток за кредит
Коефіцієнт
дисконтування
Дисконтова нні
капіталовкладення
Дисконтованні
капіталовкладення
з наростючим
підсумком

Розбиті витрати
1800
1600
1400
1200
1000
800
600
400
200
0
1 2 3 4 5 6 7 8 9

Рисунок 3.1 – Розбиті витрати
Цільні витрати
1800
1600
1400
1200
1000
800
600
400
200
0
1 2 3 4 5 6 7 8 9

Рисунок 3.2 – Цільні витрати

76

1400
1200
1000
800
600
400
200
0
1
2 Ряд 2
3
4
5 Ряд1
6
7
8

Рисунок 3.3 – Поточні витрати

3.2. Ефективність поточної основної операційної діяльності
Один із показників ефективності інвестиційних проектів – потреба у
додатковому фінансуванні. Вона дорівнює максимальному абсолютному
значенню негативного накопиченого сальдо від інвестиційної та операційної
діяльності або накопиченого наростаючим підсумком сальдо сумарного
грошового потоку (максимальне сальдо накопиченого потоку).
Розрахунок додаткового фінансування показує мінімальний обсяг
зовнішнього фінансування проекту, необхідний для забезпечення його
фінансової реалізації. Тому додаткове фінансування називають ще капіталом
ризику.
Значення показника додаткового фінансування не нормується. Чим менша
абсолютна величина ДФ, тим менша кількість коштів має залучатись для
здійснення проекту з зовнішніх джерел фінансування, щодо проекту.
Слід пам'ятати, що реальний обсяг потрібного фінансування не
зобов'язаний збігатися з ДФ та, як правило, перевищує його за рахунок
77

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

розрахунковий рахунок. Цей показник значною мірою залежить від характеру
виробничої діяльності. Його зниження – одне з основних завдань підприємства.
Таблиця 3.3
Прогноз динаміки вартісних показників операційної діяльності
Прогноз динаміки вартісних показників операційної діяльності
Роки операційної діяльності
Показники 1 2 3 4 5 6 7 8 9 10
1. Ціна
реалізації
одиниці 1200 1164 1129 1095 10623, 1030 9995, 9695, 9404,
9122,77
продукції (Ц), 0 0 1 2 5 5 7 8 9
грн./одиницю
2. Прямі
витрати на
матеріали на
одиницю 1000 9411, 9223,6 9039, 8858, 8681, 8507, 8337,4776
9800 9604
продукції 0 9 8 2 4 3 6 21
(М),
грн./одиницю
3. Прямі
витрати на
оплату праці
(ОП), 2080, 2122, 2164,8 2208, 2252, 2297, 2343, 2390,1851
грн./одиницю, 2000 2040
8 4 6 2 3 4 3 37
(з
нарахуванням
и)
4. Постійні
витрати
операційної 147, 150,8 153,8 156,95 160,0 163,2 166,5 169,8 173,28842
діяльності 145
9 6 8 3 9 9 6 9 25
(ПВ),
тис.грн./рік

3.3. Планування амортизаційних витрат операційної діяльності
Амортизація – це систематичний розподіл вартості основних засобів за
різними періодами протягом сроку його використання (експлуатації). Іншими
словами, це поступове списання вартості основних засобів на витрати протягом
терміну експлуатації. Причина у цьому, що економічно амортизація є відбитком
фізичного/морального зносу об'єкта. Крім відображення фізичного/морального
зносу в амортизації є інша важлива функція-правильне зіставлення доходу та
79

витрат за періодами. Основні засоби використовуються кілька років, отже,
беруть участь у отриманні доходу теж кілька років. Списати відразу всю вартість
основних засобів на витрати – це буде порушенням відповідності доходів та
витрат за періодами, тобто бухгалтерського принципу нарахування. Після повної
амортизації основних засобів залишкова (балансова) вартість основних засобів
стає рівною нулю чи ліквідаційної вартості, якщо така визначалася. Надалі об'єкт
може використовуватися з такою вартістю або бути дооцінений. Можливо і
взагалі списаний з балансу, якщо його використання неможливе.
Амортизаційні групи – це групи, на які підрозділяється майно, що
амортизується відповідно до термінів корисного використання на підставі
нормативних актів.
Поняття "амортизаційна група" використовується насамперед для податку
на прибуток, а також використовується для цілей бухгалтерського обліку.
Основний сенс віднесення конкретного об'єкта до тієї чи іншої
амортизаційної групи полягає в тому, щоб визначити термін корисного
використання з метою встановлення норми амортизації та розрахувати суму
амортизації.
У податковому обліку для нарахування амортизації залежно від терміну
корисного використання основні засоби розподіляються по 16 амортизаційним
групам у порядку зростання.
Таблиця 3.4
Розрахунок амортизаційних витрат за роками операційної діяльності
Роки операційної діяльності
1 2 3 4 5 6 7 8 9 10
4 група 748 448,8 299,2 119,68 47,872 19,149 7,6595 3,0638 1,2255 0,4902 0,1961 0,0784
6
група 10 3 7 4,9 3,43 2,401 1,681 1,176 0,824 0,576 0,404 0,282

80
Групи основних
фондів
Первісна вартість,
тис.грн.
Річна норма
амортизації, %

Разом 306,2 124,58 51,302 21,55 9,3402 4,2403 2,0491 1,0667 0,5996 0,3609

3.4 Планування кредитних процесів операційної діяльності
У ході операційної діяльності необхідно забезпечити погашення кредитів,
використаних на інвестиційній фазі проекту, та забезпечити виплату відсотків за
сумами кредиту. Перші виплати передбачені з допомогою прибутку, другі - у
складі операційних витрат.
Розглядаються два можливі варіанти побудови кредитного процесу.
Перший варіант жорсткіший, з меншим терміном погашення кредиту, другий -
м'якший, з більш тривалим терміном погашення кредиту та можливими
відстрочками.
Таблиця 3.5
Схема використання та повернення кредиту за роками операційної
діяльності
Роки операційної діяльності
Показники
1 2 3 4 5 6 7 8 9 10
1 варіант
1.
Повернення
суми 524,6 524,6 524,6
кредиту, тис.
грн. (%)
2.
Використана
за рік сума 1573,9 1049,2 524,6
кредиту, тис.
грн. (%)
3. Оплата
процентів, 377,7 251,8 125,9
тис. грн.
2 варіант

1.
Повернення 393,5 393,5 393,5 393,5
суми

81

кредиту, тис.
грн. (%)
2.
Використана
за рік сума 1573,9 1573,9 1180,4 786,9 393,5
кредиту, тис.
грн. (%)
3. Оплата
процентів, 377,7 377,7 283,3 188,9 94,4
тис. грн.

3.5 Прогноз доходів операційної діяльності
Детальний прогноз виручки має найбільшу трудомісткість, але дає
достовірніші результати. Такий прогноз повинен включати аналіз можливостей
компанії з реалізації своєї продукції (послуг) по основним групам продукції. При
цьому, важливо забезпечити прозорість та достовірність прогнозу, для чого
необхідно спрогнозувати обсяг реалізації у натуральних кількісних показниках
(коли це можливо) або спрогнозувати зміни трудомісткості (складності)
виконання майбутніх проектів компанії.
Складність кількісного прогнозу реалізації в натуральних показниках є
характерною рисою багатьох видів бізнесу, наприклад, для тих компаній,
діяльність яких пов'язана із здійсненням наукової діяльності та дослідно-
конструкторських робіт, консультаційних послуг, виробництвом несерійної
продукції за індивідуальними замовленнями.
Незважаючи на це практично в будь-якому випадку можна виділити
основну ціноутворюючу характеристику виробленої продукції або послуги
(трудомісткість, масу і т. д.).
Важливою умовою є підтвердження використовуваних прогнозних
показників об'єктивними очікуваннями учасників та аналітиків ринку.
Таблиця 3.6
Прогноз доходів операційної діяльності
82

Показни Роки операційної діяльності
ки 1 2 3 4 5 6 7 8 9 10
1. Річні
обсяги
реалізаці
ї 1 1 1 1 1 1 1 1 1 1
продукці
ї, тис.
одиниць
2. Ціна
одиниці, 1500 14550 14113 13690 13279 12881 12494 12119 11756 11403
грн./од. 0 ,0 ,5 ,1 ,4 ,0 ,6 ,7 ,2 ,5

3.
Річний 1500 14550 14113 13690 13279 12881 12494 12119 11756 11403
дохід, 0 ,0 ,5 ,1 ,4 ,0 ,6 ,7 ,2 ,5
тис. грн.

3.6 Прогноз витрат операційної діяльності
При розрахунку потоків реальних грошей слід пам'ятати принципову
відмінність понять приток і відтоків реальних від понять доходів і витрат.
Існують певні номінально грошові витрати, такі як знецінення активів та
амортизація основних засобів, що зменшують чистий дохід, але не впливають на
потоки реальних грошей, т.к. номінально грошові витрати не передбачають
операцій із перерахування грошових сум.
Всі витрати віднімаються від доходів і впливають на суму чистого
прибутку, але не за всіх витрат потрібен реальний переказ грошей.
Такі витрати не впливають на потік реальних грошей.
З іншого боку, в повному обсязі грошові виплати (що впливають потік
реальних грошей) фіксуються як витрати. Наприклад, купівля товарно-
матеріальних запасів чи майна пов'язані з відпливом реальних грошей, але з
витратою.
Таблиця 3.7
Прогноз витрат операційної діяльності, тис. грн. (1 – варіант)
Прогноз витрат операційної діяльності
Роки операційної діяльності
83

Показни
ки 1 2 3 4 5 6 7 8 9 10

1.
Витрати 11,6 11,5 11,38 11,2 11,1 10,9 10,8 10,72766
12 11,84
змінні 85 34 85 47 11 79 51 276

2.
Витрати 150, 153, 156,9 160, 163, 166, 169, 173,2884
145 147,9
постійні 86 88 53 09 29 56 89 225

3.
Амортиза 124,5 51,3 21,5 9,340 4,24 2,04 1,06 0,59 0,360908
306,2
ція 8 02 5 22 03 91 67 96 734

4.
Процент 378 252 126
за кредит
Разом
операцій 840,92 536,1 339, 186, 177,6 175, 176, 178, 181, 184,3769
ні 64 38 75 96 81 58 45 6 34 939
витрати

Таблиця 3.8
Прогноз витрат операційної діяльності, тис. грн. (2 – варіант)
Показни Роки операційної діяльності
ки 1 2 3 4 5 6 7 8 9 10
1.
Витрати 11,6 11,5 11,38 11,2 11,1 10,9 10,8 10,72766
12 11,84
змінні 85 34 85 47 11 79 51 276

2.
Витрати 150, 153, 156,9 160, 163, 166, 169, 173,2884
145 147,9
постійні 86 88 53 09 29 56 89 225

3.
Амортиза
ція 124,5 51,3 21,5 9,340 4,24 2,04 1,06 0,59 0,360908

306,2 8 02 5 22 03 91 67 96 734
4.
Процент
за кредит 377,72 377,7 283, 188, 94,43

64 26 29 86 16
Разом 840,92 662,0 497, 375, 272,1 175, 176, 178, 181, 184,3769
операцій 64 46 14 82 13 58 45 6 34 939
84

ні
витрати

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

85

Таблиця 3.9
Прогноз грошових потоків операційної діяльності (1-варіант)
Показники, Роки операційної діяльності
тис. грн. 1 2 3 4 5 6 7 8 9 10
1. Доход від 1500 1455 1411 1369 1327 1288 1249 1211 1175 1140
реалізації 0,00 0,00 3,50 0,10 9,39 1,01 4,58 9,74 6,15 3,47
2. Операційні 840,9 536,1 339,7 186,9 177,6 175,5 176,4 178,6 181,3 184,3
витрати 3 4 5 6 8 8 5 0 4 8
3. Балансовий 1415 1401 1377 1350 1310 1270 1231 1194 1157 1121
прибуток 9,07 3,86 3,75 3,14 1,71 5,43 8,13 1,14 4,81 9,09
4. 306,2 124,5
Амортизація 0 8 51,30 21,55 9,34 4,24 2,05 1,07 0,60 0,36
5.
Оподатковани 1385 1388 1372 1348 1309 1270 1231 1194 1157 1121
й прибуток 2,87 9,28 2,44 1,59 2,37 1,19 6,08 0,07 4,21 8,73
6. Податок на 2493, 2500, 2470, 2426, 2356, 2286, 2216, 2149, 2083, 2019,
прибуток 52 07 04 69 63 21 89 21 36 37
7. Чистий 1135 1138 1125 1105 1073 1041 1009 9790, 9490, 9199,
прибуток 9,36 9,21 2,40 4,90 5,74 4,98 9,18 86 85 36
Таблиця 3.10
Прогноз грошових потоків операційної діяльності (2-варіант)
Показники, Роки операційної діяльності
тис. грн. 1 2 3 4 5 6 7 8 9 10
1. Доход від 1500 1455 1411 1369 1327 1288 1249 1211 1175 1140
реалізації 0,00 0,00 3,50 0,10 9,39 1,01 4,58 9,74 6,15 3,47
2. Операційні 840,9 662,0 497,1 375,8 272,1 175,5 176,4 178,6 181,3 184,3
витрати 3 5 4 2 1 8 5 0 4 8
3. Балансовий 1415 1388 1361 1331 1300 1270 1231 1194 1157 1121
прибуток 9,07 7,95 6,36 4,27 7,28 5,43 8,13 1,14 4,81 9,09
4. 306,2 124,5
Амортизація 0 8 51,30 21,55 9,34 4,24 2,05 1,07 0,60 0,36
5.
Оподатковани 1385 1376 1356 1329 1299 1270 1231 1194 1157 1121
й прибуток 2,87 3,37 5,06 2,72 7,94 1,19 6,08 0,07 4,21 8,73
6. Податок на 2493, 2477, 2441, 2392, 2339, 2286, 2216, 2149, 2083, 2019,
прибуток 52 41 71 69 63 21 89 21 36 37
7. Чистий 1135 1128 1112 1090 1065 1041 1009 9790, 9490, 9199,
прибуток 9,36 5,97 3,35 0,03 8,31 4,98 9,18 86 85 36

86

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

87

Фази, роки, квартали проекту
Показники Роки інвестиційної фази Роки операційної фази

1 2
м м м м м м м м 1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8
1. Грошові 8 20 20 80 80 200 106 165
потоки 0
інвестиційної
діяльності
2. Чистий 11359,3 11389,2 11252,4 11054,9 10735, 10414,9 10099,1 9790,85 9490,8 9199,35
прибуток 564 116 0441 0044 744 764 8367 842 519 6941
операційної
діяльності
3. 8 20 20 80 80 200 106 165 306,2 124,58 51,302 21,5498 9,3402 4,24029 2,04906 1,06668 0,5996 0,36090
Амортизація 0 2 8 62 938 198 8734
4. Грошові 8 20 20 80 80 200 106 165 524,62 524,62 524,62
потоки 0
фінансової
діяльності
(отримання та
повернення
кредиту)
5. Сальдо -8 -20 -20 -80 -80 -200 - -165 10528,5 10740,0 10676,4 11033,3 10726, 10410,7 10097,1 9789,79 9490,2 9198,99
реальних 106 364 116 8241 5064 404 361 346 1731 522 6033
грошей 0
6. Коефіцієнт 0,98 0,96 0,94 0,92 0,90 0,88 0,87 0,85 0,81 0,65 0,52 0,42 0,34 0,28 0,22 0,18 0,14 0,12
дисконтуванн 04 12 23 38 57 8 06 35
я
7. 7,84 19,2 28,2 249, 244, 230, 452, 140, 8490,75 6984,91 5599,67 4666,81 3658,8 2863,85 2239,99 1751,45 1369,2 1070,34
Дисконтовани 31 23 7 44 55 87 69 83 512 907 9018 6016 593 698 1393 8984 495 4495
й потік
грошей за
періодами
8. 7,84 26,9 54,6 303, 541, 761, 119 131 8490,75 15475,6 21075,3 25742,1 29401, 32264,8 34504,8 36256,3 37625, 38695,9
Дисконтовани 31 13 55 02 63 88 9,6 6,9 512 742 5321 6923 029 855 7689 3588 585 2987
й потік
грошей
наростаючим
підсумком
88

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

3.9 Оцінка показників ефективності проекту
Розрахунок показників ефективності проекту здійснюється на основі
прогнозу та реалізації на 10 років. Відповідно до формалізованого підходу
абсолютний ефект проекту визначається як різниця між накопиченими
грошовими надходженнями та відтоками.
Але оскільки передбачається, що інвестиційна фаза повністю фінансується
за рахунок позичкового капіталу, то сума інвестицій власних коштів дорівнює
нулю.
Показники ефективності проекту Queue Control наведено у табл. 3.12.
Таблиця 3.12
Показники ефективності проекту Queue Control
Чистий дисконтований прибуток 38695,93
Індекс прибутковості 29,383311
Величина середньорічних грошових притоків 3869,593
Очікуваний строк окупності капіталу 0,7020531
Внутрішня норма доходності 32%

3.10 Висновки до розділу
В третьому розділі було розраховано та досліджено показники економічної
ефективності проекту Queue Control. Результат розрахунків свідчить про те, що
проект є прибутковим. Він має індекс дохідності, що рівний 29,38, величина
середньорічних грошових притоків дорівнює 3869,59 тис. грн.
90

ВИСНОВКИ
В даній роботі розглянуто управління проектом Queue Control. Питання
пов’язані з успішним управлінням проектів на сьогодні є досить актуальні,
оскільки в галузі інформаційних технологій, часто виникає визначений набір
невирішених проблем, таких як збільшення обсягу операцій і зменшення
швидкості роботи системи, використання могутньої системи не на повну
потужність, перетворення впровадження в нескінченний процес, постійну зміну
вимог.
При цьому були вирішені наступні задачі: сформовано інвестиційну ідею
проекта Queue Control; проаналізовано конкурентів; визначено структуру
продукту проекту; проведено PEST та SWOT аналіз; розраховано вартість
Queue Control; визначено ризики, які можуть виникнути при реалізації проекту,
та запропоновано методи боротьби з ними; запропоновано систему моніторингу
стану задач проекту та комунікацій між його учасниками.
Для управління часом та вартістю проекту застосовано програму
сітьового планування проектного менеджменту Ganttpro та Excel що дало змогу
розрахувати планові терміни виконання робіт, визначити необхідні витрати на
реалізацію проекту і його окремих фаз, а також оперативно коректувати
складені плани виконання робіт відповідно до ходу виконання проекту.
При аналізі проекту були ідентифіковані ризики. Також були розроблені
та вжиті дії для зменшення негативної дії ризиків на проект, та для запобігання
виникнення самих ризиків. При управлінні ризиками в роботі, зроблено
висновок, ризиковані ситуації можуть виникнути на кожному етапі розробки,
тому необхідно створити чек-лист та звірятися з ним, поки проект не буде здано.
Проект поділений на такі етапи: підготовчі роботи, аналіз вимог,
проектування, реалізація, тестування, впровадження та супроводження.

91

СПИСОК ІНФОРМАЦІЙНИХ ДЖЕРЕЛ
1. Соціальна відповідальність українського бізнесу: результати опитування. –
К., 2005. – 53 с.
2. Чепурнов В.О. Правовий статус благодійних установ та товариств за
законодавством України : автореф. дис. на здобуття наук. ступеня канд.
юрид. наук : спец. 12.00.03 «Цивільне право і цивільний процес; сімейне
право; міжнародне приватне право» / В.О. Чепурнов. – К., 2004. – 16 с.
3. European venture philanthropy directory 2007/2008. – 2007. – 105 p.
4. Практика благодійної діяльності бізнес-компаній в Україні: сучасний
досвід. За результатами дослідження / [Гулевська-Черниш А., Непочатова
Д., Паливода Л., Шендеровський С.]. – К. : Салютіс, 2010. – 60 с.
5. Омецінська М.В. Сучасний стан благодійництва та меценатства в Україні:
проблеми та перспективи розвитку [Електронний ресурс] / М.В.
Омецінська. – Доступно з : www.nbuv.gov.ua/portal/
Soc_Gum/Vdakk/2010_3/37. pdf.
6. Малик И.П. Развитие социальной ответственности бизнеса в Украине /
И.П. Малик // Економічний простір. – 2008. – №13. – С. 112–123.
7. Корпоративная филантропия: мифы и реальность. Результаты
социологического исследования. – М., 2002. – 65 с.
8. Закон України «Про благодійництво та благодійні організації» від 16.09
1997 р.
9. Всеукраїнський благодійний фонд «Соціальне партнерство» [Електронний
ресурс]. – режим доступу : http://socpartnerstvo.org/.
10. Благотворительность в зеркале общественного мнения. Обзор
Исследований / [обзор сост. Н. Шувалова]. – М. : Форум Доноров, 2009. –
54 с.
11. Азарова Т.В. Технологія оцінки соціальних програм і проектів. /
Т. В. Матяш, Л.К. Абрамов . – Кіровоград, 2007. – 100 с.
92

12. Прокопенко Т.О. Інформаційні технології управління організаційно-
технологічними системами: [текст] монографія / Т.О. Прокопенко, А.П.
Ладанюк. – Черкаси: Вертикаль, видавець Кандич С.Г., 2015. – 224 с.
13. Тесля Ю.М., Білощицький А.О., Тесля Н.Ю. Інформаційна технологія
управління проектами на базі ERPP (Enterprise Resources Planning In
Project) та APE (Administrated Projects Of The Enterprise) систем. – Київ:
Київський національний університет будівництва і архітектури, 2010. – 17 с.
14. Классификация социальных проектов [Электронный ресурс]. – Режим
доступа: http://bibliofond.ru/view.aspx?id=474867.
15. Видяпина В.И. Бакалавр экономики [Электронный ресурс]. – Режим
доступа: http://lib.vvsu.ru/books/Bakalavr01/page0121.asp.
16. Одаренко С. Полцарства за идею. В Украине социальные проекты всё чаще
получают финансирование [Электронный ресурс]. – Режим доступа:
http://focus.ua/society/228076/.
17. Khazan O. Bill Gates's Quest to Determine Why Children Are Dying
[Electronical resource]. – Access mode: http://www.theatlantic.
com/health/archive/2015/05/bill-gates-child-health-mortality-prevention-
surveillance-network/392549/.
18. A Global Movement To End Human Trafficking [Electronical resource]. –
Access mode: http://endhumantrafficking.com/campaigns/.
19. Дитхелм Г. Управление проектами / Герд Дитхелм. – Санкт-Петербург:
Бизнес-пресса, 2004. – 400 с. – (2).
20. Управление проектами – Самара: Самарский Государственный
Технический Университет, 2015. – 95 с.
21. Лучшие приложения для учета финансов [Електронний ресурс]. – 2017. –
Режим доступу до ресурсу: http://softcatalog.info/ru/android/obzor/uchet-
finansov.
22. ТОП-8 бесплатных приложений для учёта личных финансов [Електронний
ресурс]. – 2015. – Режим доступу до ресурсу:
https://platiza.ru/about/BlogArticle/116.
93

23. Amadeo K. What Is Competitive Advantage? Three Strategies That Work
[Електронний ресурс] / Kimberly Amadeo. – 2018. – Режим доступу до
ресурсу: https://www.thebalance.com/what-is-competitive-advantage-3-
strategies-that-work-3305828.
24. Patel N. Online Marketing Made Simple: A Step-by-Step Guide [Електронний
ресурс] / Neil Patel. – 2015. – Режим доступу до ресурсу:
https://neilpatel.com/what-is-online-marketing/.
25. Таргетированная реклама [Електронний ресурс] – Режим доступу до
ресурсу: https://apollo-8.ru/targetirovannaya-reklama.
26. СММ (SMM) Маркетинг социальных медиа [Електронний ресурс] – Режим
доступу до ресурсу:
27. Стратегічний менеджмент / [М. П. Бутко, М. Ю. Дітковська,
С. М. Задорожна та ін.]. – К.: Центр учбової літератури, 2016. – 376 с.
28. Управління змістом проекту, цілі та задачі [Електронний ресурс] – Режим
доступу до ресурсу: http://www.managerhelp.org/hoks-1134-1.html.
29. Чорна М. В. Проектний аналіз. – Харків: Консум, 2003. – 228 с.
30. Управління проектами – Хмельницький: Хмельницький національний
університет, 2015. – 276 с.
31. Андрущакевич Т. О. SWOT-аналіз як основний інструмент стратегічного
управління, його переваги і недоліки [Електронний ресурс] /
Т. О. Андрущакевич, О. В. Коновалова – Режим доступу до ресурсу:
http://www.rusnauka.com/3_SND_2010/Economics/58123.doc.htm.
32. Павленко А. Ф. Маркетинг / А. Ф. Павленко, А. В. Войчак. – К.: КНЕУ,
2003. – 246 с.
33. Elevating Expectations: 5 Ways Product Quality Impacts Your Brand
[Електронний ресурс]. – 2018. – Режим доступу до ресурсу:
https://www.business.com/articles/5-reasons-why-product-quality-matters/.
34. SWOT Analysis and PEST Analysis – When to Use Them [Електронний
ресурс]. – 2018. – Режим доступу до ресурсу:
https://creately.com/blog/diagrams/swot-analysis-vs-pest-analysis/.
94

35. Project Scope Triangle [Електронний ресурс]. – 2006. – Режим доступу до
ресурсу: http://www.projectscopetemplate.com/project-scope-triangle-
213.html.
36. Гудзь О. Є. Менеджмент ідей та управління проектами / О. Є. Гудзь,
А. А. Глушенкова., 2016. – 156 с.
37. Статистика жителів України [Електронний ресурс] – Режим доступу до
ресурсу: http://database.ukrcensus.gov.ua/Mult/Dialog/Saveshow.asp.
38. Мороз Л. А. Маркетинг / Л. А. Мороз, Н. І. Чухрай. – К.: „Інтелект-Захід”,
2002. – 244 с.
39. Запорожець А. О. Розробка проекту інтернет-магазину техніки на основі
ситуаційного аналізу / А. О. Запорожець. – Черкаси, 2018. – 35c.
40. Ноздріна Л. В. Управління проектами / Л. В. Ноздріна, В. І. Ящук,
О. І. Полотай. – К.: Центр учбової літератури, 2010. – 432 с.
41. Нечаюк Л. І. Менеджмент / Л. І. Нечаюк, Н. О. Телеш. – К.: Центр учбової
літератури, 2003. – 348 с.
42. Петренко Н. О. Управління проектами / Н. О. Петренко, Л. О. Кустріч,
М. О. Гоменюк. – К.: Центр учбової літератури, 2015. – 244 с.
43. Управління проектами інформатизації – Тернопіль: Тернопільский
національний технічний університет Ім. И. Пулюя, 2016. – 235 с.
44. Попов В. Л. Управління інноваційними проектами / В. Л. Попов. – Москва:
Инфра-М, 2009. – 336 с.
45. Запорожець А. О., Запорожець М. В. Застосування методів тайм-
менеджменту в управлінні проектами.. Вісник ЧДТУ. – 2018. - №2. – 139
С.
46. Погановська А. Р. Інформаційний менеджмент і управління проектами / А.
Р. Погановська, В. С. Селуков, Д. А. Даниленко. – Миколаїв: ЧДУ ім. П.
Могили, 2017.
47. Машошина Т. В. Зміст та характеристика проектного менеджменту /
Т. В. Машошина. – Харків, 2013. – 93 с.
48. Управління вартістю проекту на етапі виконання проекту [Електронний
95

ресурс] – Режим доступу до ресурсу: http://www.managerhelp.org/hoks-
1141-1.html.
49. Должанський І. З. Бізнес-план: технологія розробки : навч. посіб. /
І. З. Должанський, Т. О. Загорна. – К. : ЦНЛ, 2006. – 384 с
50. Прокопенко Т. О. Методологія управління ІТ проектами /
Т. О. Прокопенко. – Черкаси: ЧДТУ, 2017. – 109 с.
51. Мазур И. И. Управление проектами / И. И. Мазур, В. Д. Шапиро,
Н. Г. Ольдерогге. – Москва: Омега-Л, 2004. – 664 с.
52. Аньшин В. В. Управление проектами: Фундаментальный курс /
В. В. Аньшин, О. А. Ильина. – Санкт-Петербург: Высшая школа
экономики, 2013. – 900 с.
53. Глобальне опитуванням PMI Pulse of the Professional 2017 року
[Електронний ресурс]. – Режим доступу до ресурсу: https://www.pmi.org/-
/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-
the-profession-2017.pdf.
54. Видання PMI «Пульс професії» за 2015 рік [Електронний ресурс]. – Режим
доступу до ресурсу: https://www.pmi.org/-
/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-
the-profession-2015.pdf?v=32696185-33f5-4fc0-93bb-
1f339ad75d2e&sc_lang_temp=en
55. Глобальне опитування PMI, проведене у 2018 році [Електронний ресурс].
– Режим доступу до ресурсу: https://www.pmi.org/-
/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-
the-profession-2018.pdf.
56. Опитування з питань управління проектами 2017, проведене компанією
KPMG [Електронний ресурс]. – Режим доступу до ресурсу:
https://assets.kpmg/content/dam/kpmg/nz/pdf/July/projectmanagementsurvey-
kpmg-nz.pdf.
96

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets