Основи проектного менеджменту 2 страница

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

• Перший цикл по створенню - формулювання вимог до
системи, завдання вимог по першому циклу, проектування
логічної системи, проектування і створення системи по

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

• Другий цикл по створенню - формулювання вимог до
підсистеми, визначення вимог до другого циклу створення,
здійснення фізичного проектування, створення системи по
другому циклу, розробка планів по тестуванню системи, оцінка
другого циклу і отримання рекомендацій.

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

2.2 Зацікавлені сторони проекту

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

• Менеджер проекту - окрема особа, яка відповідає за управління
проектами.

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

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

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

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

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

■

Малюнок 2 — 5. Приклад життєвого циклу розробки програмного забезпечення (за Мюнком)

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

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

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

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

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

2.3 Вплив виконавчої організації

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

2.3.1 Організаційні системи

Організації під проект - це ті організації, чия діяльність в основному пов'язана з виконанням проектів. Ці організації можна розбити на дві категорії.

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

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

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

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

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

Малюнок 2-6. Вплив організаційної структури на проекти

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

2.3.2 Організаційна культура і стиль

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

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

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

2.3.3 Організаційна структура

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

Класична функціональна організація, показана на малюнку 2-7, — це ієрархія, в якій кожний працівник має одного конкретного начальника. Персонал згруповується по спеціальностях, таких як виробництво, маркетинг, інжиніринг і облік на верхньому рівні, інжиніринг потім розбивається на механічний та електротехнічні підрозділи. Функціональні організації також мають проекти, але зміст цих проектів обмежується організаційними функціями: інженерний підрозділ у функціональній організації виконуватиме свою роботу незалежно від підрозділів виробництва і маркетингу. Наприклад, коли розробка нового продукту здійснюється в чисто функціональній організації, фаза проектування часто називається «проект» і до неї залучається тільки персонал інженерного підрозділу. Якщо тут виникають виробничі питання, вони по ієрархії надходять до керівника виробничого підрозділу. Потім керівник інженерного підрозділу також по ієрархії передає відповідь менеджеру проекту інженерного підрозділу. В іншому кінці спектра знаходиться організація «під проект» (проектно-орієнтована організація), структура якої схематично зображена на малюнку 2-8. У проектно-орієнтованій організації члени команди часто працюють разом. Більша частина організаційних ресурсів залучена до роботи над проектом, і менеджери проектів тут більш незалежні і мають багато повноважень. У проектно-
орієнтованих організаціях часто діють організаційні одиниці (відділи), які

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

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

 

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

2.4 Загальні управлінські навички

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

• Фінансування та облік, продаж і маркетинг, дослідження й
розробку, виробництво та розподіл.

• Стратегічне, тактичне й оперативне планування.

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

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

• Самоврядування, управління особистим часом, управління
стресами тощо.

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

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

 

 

2..4.1 Лідерство

Коттер [4] розрізняє поняття «лідерство» та «управління» з акцентом важливості обох понять: одне без іншого ймовірно призведе до небажаних результатів. Він говорить, що управління в основному зосереджується на «стійкому отриманні ключових результатів, очікуваних зацікавленими сторонами», тоді як лідерство включає:

• вибір напрямку - розвиток як погляду в майбутнє, так і стратегій з
метою вироблення змін, необхідних для отримання такого погляду;

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

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

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

2.4.2 Комунікація

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

• письмова й усна (слухання або розмова);

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

• формальна (звіти, брифінги і т.д.) і неформальна (нотатки на
пам'ять, кулуарні бесіди і т.ін.);

• вертикальна (вверх і вниз в організації) і горизонтальна
(рівноправні співробітники).

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

• Моделі відправник-одержувач - цикл зворотного зв'язку,
комунікаційні бар'єри і т.ін.

• Вибір засобів інформації - коли здійснити комунікацію в
письмовій формі, коли в усній, коли написати неформальну
записку по пам'яті, коли - формальний звіт і т.ін.

• Стиль написання — активний або пасивний, структура
пропозиції, вибір слів і т.ін.

• Технологія уявлення - мова, проектування засобів наочної
інформації і т.ін.

• Технологія управління нарадами - підготовка порядку денного,
управління конфліктами і т.ін.

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

 

2.4.3 Ведення переговорів

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

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

• Задачі, зв'язані зі змістом, вартістю і календарним планом
проекту.

• Внесення змін у зміст, вартість і календарний план проекту.

• Строки та умови контракту.

• Призначення.

• Ресурси.

2.4.4 Вирішення проблем

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

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

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

2.4.5 Вплив організації

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

Як влада, так і політика використовуються тут в позитивному значенні. Пфеффер [5] дає визначення владі, як «потенційній здатності впливати на поведінку, змінювати хід подій, долати опір і примушувати людей робити те, що інакше не буде зроблено». Аналогічно, Екклз [6] говорить, що «політика - це вироблення колективних дій групою людей, які можуть мати абсолютно різні інтереси. Звичайно, тут існує небезпека того, що спроба врахувати всі інтереси призводить до боротьби між різними силами або до «організаційних ігор», і в кінцевому підсумку до абсолютно непродуктивної діяльності цих організацій».

2.5 Соціоекономічний вплив

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

Стандарти й норми

Міжнародна організація із стандартизації (ISO) розрізняє стандарти й норми так [7]:

• Стандарт - це «документ загального та багаторазового
використання, затверджений відповідною організацією, в якому
зведені правила, керівництва чи характеристики для продуктів,
процесів або послуг і який не є обов'язковим для дотримання».
Існує безліч стандартів, які розглядають практично будь-які
питання: від температурної стабільності гідравлічних потоків до
розмірів комп'ютерних дискет.

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

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

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

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

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

2.5.2 Інтернаціоналізація

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

2.5.3 Вплив культурної сфери

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

 

3.Процеси управління

Проектами

Управління проектами - це комплексна робота: якась дія або відмова

від неї в одній галузі звичайно спричиняє наслідки в інших галузях.

Взаємодії можуть бути безпосередніми і зрозумілими, але вони також

можуть бути невловимими і невизначеними. Так, зміна змісту майже

завжди впливає на вартість проекту, але вона не обов'язково

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

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

Для того щоб допомогти зрозуміти інтеграційну природу управління проектами і для підкреслення важливості інтеграції, у даному 3.4 документі описується управління проектами в термінах процесів по Настройка компонентах і їх взаємодій. Цей розділ являє собою вступ до концепції взаємодій між управління проектами як множини взаємопов'язаних процесів і таким процесами чином закладає основи розуміння процесів, описаних у розділах 4 -12. Він включає такі підрозділи:

Процеси в проектах

3.2 Групи процесів

3.3 Взаємодії між процесами

3.4 Настройка взаємодій між процесами

 

Процеси в проектах

Проекти складаються з процесів. Процес - «це серія дій, що ведуть до результату» [1]. Процеси в проектах здійснюють люди. Процеси бувають двох основних категорій:

• Процеси в управлінні проектами, що зосереджуються на описі

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

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

коротко описані в цьому розділі и більш детально в розділах 4-12.

• Процеси, орієнтовані на продукт, зосереджені на визначенні і
створенні продукту проекту. Процеси, орієнтовані на продукти,
звичайно, визначаються відповідно до життєвого циклу
проекту (обговорювалося в підрозділі 2.1) і варіюються
залежно від прикладної сфери (обговорюється у додатку F).

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

3.2 Групи процесів

Процеси управління проектами можуть бути впорядковані по п'яти групах по одному або більше процесу в кожній:

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

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

• Процеси виконання - координування штату та інших ресурсів
для здійснення плану.

• Процеси здійснення контролю - перевірка того, що задачі
проекту розв'язуються на тлі контролю виконання і в разі
необхідності здійснення дій щодо коригування проекту.

• Процеси закриття - формалізація прийняття проекту (або фази)
і доведення його (або її) до логічного завершення.

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

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

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

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

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

3.3 Взаємодії між процесами

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

• Вхідні дані - документи або документовані одиниці, що
впливають на процес.

• Методи та засоби - механізм, що застосовується до вхідних
даних для отримання результатів.

• Результати - документи або документовані одиниці, що є
результатами процесу.

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

3.3.1 Процеси ініціалізації

Малюнок 3- 4 ілюструє процес у групі процесів загалом.