ALL(PDF)
.pdfДля кожного результату дається опис його якісних цілей у термінах вихідної якості й погоджених вимог. Наприклад, "доповіді про поточний стан будуть надаватися щотижня спонсорові проекту й лідерам
проектної команди й повинні затверджуватися кожною з персон до передачі в архів проекту". Ступінь підтримки, що повинна бути надана продукту, повинна бути також представлена як якісна ціль.
Шаблон статуту проекту: Організація й відповідальність
Цей розділ визначає вимоги до проектної команди й, беручи до уваги ресурсний план організації й вимоги до навичок проектування, призначає ролі й відповідальність пойменованим індивідам.
Примітка: Із РМВОК 4 виключено всі функціональні й організаційні вимоги зі Статуту Проекту.
Шаблон статуту проекту: Організація й відповідальність (продовження)
Можлива структура організації:
•Виконавчий комітет
•Лідер проекту
•Менеджер проекту ( IT-Менеджер проекту й/або менеджер проекту в бізнес-сфері)
•Лідери проекту в IT-Галузі (Лідери команд розробки або лідери проектних команд в ITГалузі, які допомагають менеджерові проекту в адмініструванні й/або управлінні специфічними аспектами проекту)
•Члени проектних команд (включаючи членів IT-Команд і бізнес-клієнтів)
•Координатор випробувань
•Контролер якості
•Контролер конфігурації
•Контролер змін
Організація й відповідальність (продовження)
Індивіди можуть сполучати виконання ролей у проекті. Наприклад, у невеликих проектах менеджер проекту може бути одночасно членом проектної команди, контролером конфігурації й змін і координатором випробувань. У невеликих проектах Виконавчий комітет може не створюватися, і лідер проекту виконує узгоджувальну й наглядову функцію.
Увеликих проектах лідери проектних IT-команд можуть призначатися помічниками менеджера проекту
вдіях по координації всіх операцій проекту й управлінню специфічними виходами за планом робіт.
Організація й відповідальність (закінчення)
У більшості проектів краще розділяти ролі менеджера проекту й лідера команди. Суміщення веде до відхилення від виконання основних функцій по управлінню проектом.
Ці ролі звичайно описуються в "Керівництві менеджера IT-Проекту", "Основні ролі й обов'язки". У рамках цього розділу описуються відносини по наданню повідомлень і проектні інтерфейси.
Необхідні узгодження, інтерфейси із зовнішніми організаціями (для надання посередницьких послуг) і з комітетами нагляду, контролю й вищого управління повинні бути задокументовані.
Шаблон статуту проекту: Залежності
Всі залежності за межами прямого контролю керуючих проектом або зовнішні рамки проекту (які можуть вплинути на успіх проекту) повинні бути визначені.
Наприклад, дії, які повинні бути виконані клієнтом або субконтрактором, або дії або виходи зовнішніх
проектів, які необхідні усередині контексту проекту, що розглядається. Внутрішні залежності також повинні бути розглянуті.
Залежності проекту й/або виходів проекту від інших проектів/продуктів (існуючі або, що перебувають у розвитку) повинні бути зрозумілі.
Наприклад, якщо необхідний ресурс стає недоступним до завершення іншого проекту, ця залежність повинна бути визначена й відповідний ризик повинен бути задокументований у відповідному для цього розділі Положення.
Повинні бути також визначені необхідні зв'язки з іншими існуючими або планованими системами
Шаблон статуту проекту: Плани підтримки дій
Тут описуються плани підтримки операцій.
Прикладами такої підтримки можуть бути навчання, забезпечення якості, управління конфігурацією й документальна підтримка.
Якщо ці плани існують як документи зовнішні по відношенню до Плану проекту (План управління конфігурацією, План якості, План навчання), то тут необхідно навести посилання на них.
Шаблон статуту проекту: Забезпечення й ресурси проекту
Потреби проекту в такому забезпеченні й ресурсах, як офісний простір, спеціальні засоби обслуговування, обчислювальна техніка, офісне обладнання повинні бути визначені.
Відповідальність за поставку або забезпечення виконання цих умов повинна бути чітко позначена й описана.
Планування необхідних обчислювальних потужностей (пам'ять, процесор, дисковий простір) повинне брати до уваги розміри купованого або розроблювального програмного забезпечення, рівень персоналу проекту й історію подібних проектів у минулому.
Шаблон статуту проекту: Управління ризиком
Всі ризики, пов'язані із проектом і діями, які можуть бути початі з метою мінімізації ризиків, повинні бути описані.
Запобіжні заходи й плановані реакції також повинні бути описані.
Наприклад, ризик може залежати від одного з навичок (одного ресурсу) у рамках організації. Менеджмент повинен у цьому випадку щонайменше визначити альтеративні джерела цієї навички або забезпечити навчання резервного ресурсу. Використання апаратного забезпечення енного типу теж народжує ризик. Управління ризиком повинне передбачити попереднє ознайомлення із прототипами обладнання й додаткове тестування.
Повинні бути описані як процеси ідентифікації, документування, спостереження й моніторингу ризиків, так і процеси зниження й виключення ризиків і стратегії реакцій.
Шаблон статуту проекту: Управління ризиком (закінчення)
Увеликих проектах План управління ризиками може розроблятися поза Статутом.
Уневеликих проектах він починається як частина Статуту, але доопрацьовується протягом реалізації проекту у вигляді зовнішнього документа або системи.
Відомий підхід, що має назву Безперервне управлінням ризиками (Continuous Risk Management - CRM). Існують відповідні Керівництва (відкриті ресурси й Інтернет), до змісту яких входять систематичний (таксономічний) опитувальник і всі алгоритми, які можуть бути використані у пов'язаних інструментах і технологіях.
Шаблон статуту проекту: Процесні умови й відхилення
Якщо в компанії уже визначилися з Методологією управління проектами або Методологією системного проектування життєвого циклу, це повинно бути відбите в даному розділі.
Якщо з якихось причин відхилення від цих стандартів бачаться необхідними й/або бажаними для проекту, ці відхилення повинні бути визначені, і їхнє раціональне обґрунтування повинне бути тут поміщено.
Шаблон статуту проекту: Етапи
Включає опис життєвого циклу проекту і життєвого циклу поставки рішення (розробки проекту). Повинні бути визначені етапи проекту, цілі кожного етапу й ознаки їхніх входів/виходів.
Роблять посилання на прийняті в компанії для етапу проекту підходів до визначення вхідних ресурсів/результату й ознак входу/виходу.
Для кожного етапу життєвого циклу, прикладних процедур, методів і стандартів повинні бути наведені посилання або визначення.
Шаблон статуту проекту: Управління проектом
У розділі пояснюються методи й процедури, які застосовуються для надання допомоги менеджеру проекту в оцінці виконання проекту й інформуванні про виконання проектної команди, спонсора проекту й зацікавлених сторін проекту.
Він також включає визначення підходу до усунення відхилень від плану проекту й проведенню коригувальних операцій.
Шаблон статуту проекту: Управління проектом (продовження)
Управління проектом характеризується:
•Типом і частотою розробки проектних звітів
•Частотою проведення нарад проектної команди
•Частотою обговорень контрольних точок етапів проекту (проведених, по-можливості, Виконавчим комітетом).
•Частотою зборів Виконавчого комітету
•Ім'ям і розміщенням проектного файлу
•Методами, які повинні бути використані, щоб одержати допуск і контролювати проектні операції
•Критерієм випуску змінених версій проектного плану
•Метриками, які повинні бути зібрані при реалізації проекту, і аналізом, що повинен бути виконаний з ними
Шаблон статуту проекту: Управління проектом (закінчення)
Цей розділ також визначає методи й політики, використовувані для контролю границь проекту, управління емісіями й управління змінами й конфігуруванням.
Також у рамках розділу повинен бути представлений план проектних комунікацій - методи, синхронізація, спостерігачі й т.д. у проектних комунікаціях (інструменти які повинні використовуватися, методи одержання результату, адресати, колекція проектної інформації й реакцій на неї й архівація робочих паперів проекту).
Шаблон статуту проекту: Дії по управлінню якістю
Дії по управлінню якістю пов'язані як із процесами управління проектом, так і з результатами
проекту.
Потрібен список усіх оглядів по якості й тестах якості, використовуваним у проекті, включаючи права власності, наближені план-графіки й зусилля.
Наприклад, має бути присутнім огляд проектного плану, конструкційні огляди, випробування пристроїв, випробування систем, прийомні випробування. Для цього повинен бути складений і спланований
список всіх об'єднаних споживчо-клієнтських оглядів.
Шаблон статуту проекту: Дії по управлінню якістю
Включіть наради для підготовки оглядів по результатах тестів приймання й перевірку відповідності вимогам.
На цьому етапі проекту специфічні огляди, пов'язані із продуктами, і процеси (конструкційні огляди, системні тести й т.п.) можуть бути ще не відомі. Проте, опис очікуваних типів оглядів і рівнів залучення різних зацікавлених сторін і членів команди повинен бути тут представлений.
Шаблон статуту проекту: Графік проекту
Діаграма Гантта для робіт, ресурсів і пов'язаних з ними відповідальних виконавців.
Методологія управління проектами, прийнята в компанії, й/або Методологія управління життєвим циклом систем може вплинути на побудову діаграми Гантта (включаючи відповідну декомпозицію робіт).
Графік проекту повинен враховувати критичні залежності між проектними групами. Рекомендується використовувати спеціальні програмні інструменти проектного менеджменту для
розробки графіка проекту й моніторингу його реалізації відповідно до графіка.
Шаблон статуту проекту: Оцінка трудомісткості проекту
Цей розділ описує проектні зусилля в людино-днях або людино-місяцях, оцінювані відповідно до процедури оцінки, прийнятої в компанії. Зусилля повинні бути декомпоновані на етапи й фази проекту.
Включається інформація, використовувана для оцінювання зусиль (припущення, історичні дані, використовувані для одержання оцінок і т.п.).
Шаблон статуту проекту: Оцінка вартості проекту
Цей розділ визначає вартість проекту, оцінювану відповідно до процедури, прийнятої в компанії. Вартість повинна бути класифікована (праця, обладнання, офісний простір тощо) і декомпонована на етапи й фази проекту.
Додатково, політика й методи постачання/поставок, використовувані в проекті, повинні бути деталізовані (хто відповідає за рішення про закупівлі й розробку й управління рахунками замовлень, платіжними дорученнями й т.п. і як все це управляється).
Включається інформація, використовувана для одержання оцінок вартості (допущення, джерела вартісної інформації, історія вартостей, використовувані для оцінки).
Статут необхідний будь-якому проекту Він формує зміст зобов'язань менеджера проекту, зміст володіння проектом його спонсором, зміст
колективної роботи команди проекту.
Статут проекту охоронить від конфліктів у майбутньому із приводу того, хто бере участь у проекті й, чи повинен залучатися певний співробітник у команду розробки проекту.
У цілому статут дозволить швидше досягти мети проекту.
Приклад статуту проекту Проект: Відновлення операційних систем до ХР і до серверів 2000 Спонсор проекту: Піскун Максим, провідний інженер з ІТ (к. 233)
Менеджер проекту: Михайло Шварговський, мережний адміністратор (к. 234)
Команда проекту: Едуард Басов, Анна Берінгер, Марина Бабич, Ксенія Фролова, Шарлота Харченко, Дмитро Батіг, Катерина Манько, Михайло Сивкович, Марко Терновий, Степан Удовенко
Приклад статуту проекту (продовження)
Мета проекту: Всі настільні системи оновлюються до Windows XP до 3 грудня 2010 р.
Всі сервери обновляються й переносяться на п'ять серверів Windows 2000 Servers до 20 грудня наступного року.
Приклад статуту проекту (продовження)
Бізнес-Умови: Windows 95 використовувалася компанією п'ять останніх років. Персонал полюбив і
вивчив цю систему, але настав час іти далі. Ми збираємося впровадити нові технології Microsoft, подібні Windows 95, але переважаючі по своїх можливостях - тобто системи Windows XP. Ця операційна система дозволить підвищити продуктивність праці, забезпечить більшу мобільність, підсилить захист і спростить обслуговування. Крім того, у ХР реалізовані нові технології, такі як інфрачервоний мережний доступ, які допоможуть впровадити складську систему для готової продукції й нове фінансове ПЗ, розгортання його намічене на кінець року. Зрозуміло, компанія продовжить присутність в Інтернеті й проведення інтерактивної торгівлі. У цій області системи ХР мають прекрасні можливості для всіх нас.
Приклад статуту проекту (продовження)
Як відзначалося в останній рік, сервери компанії застаріли, стали повільними за сучасними мірками. Ми замінимо сервери шістьома новими багатопроцесорними серверами з достатньою кількістю пам'яті, дисків RAID, а також швидкими й надійними стрічковими масивами, що означає швидку, безперебійну й продуктивну роботу всіх співробітників компанії.
Для розгортання на всіх наших серверах обрана операційна система Windows 2000 Advanced Server, що надасть користувачам швидкий пошук ресурсів, підвищить час безперебійної роботи мережі та її безпеку.
Приклад статуту проекту (продовження)
Результати проекту:
• Windows XP на кожному настільному й переносному комп'ютері
•Windows 2000 на шести нових серверах
•Усі роботи завершуються 20 грудня наступного року
Приклад статуту проекту (продовження)
Базовий графік робіт:
•Вересень Тестування методів розгортання, дослідження стану користувальницьких систем і додатків, завершення створення образа й формування сценаріїв,
•Жовтень Початкове розгортання в пілотній групі з 100 користувачів. Перевірка, документування й вирішення проблем, що виникли. Повторне розгортання в тій самій пілотній групі доробленої версії й сценаріїв. Початок тестування й настроювання Windows
2000 Server.
Приклад статуту проекту (продовження)
Базовий графік робіт:
•Листопад Початок чотиригодинних підготовчих курсів, розрахованих на один місяць. Слухачі курсів будуть учитися розгортати ХР на своїх настільних ПКДіагностику й допомогу на місцях координує Дмитро Батіг, менеджер служби підтримки. Продовження тестування Windows 2000 Servers. Три системи Windows 2000 Servers будуть запущені до 15 листопада 2006 р.
•Грудень Завершення розгортання систем ХР. Установка нових серверів 2000 і створення інфраструктури. Перетворення існуючих серверів в Windows 2000. Проект завершується 20 грудня наступного року.
Приклад статуту проекту (продовження)
Ресурси проекту:
•Бюджет: $175 тис. (включаючи ХР, сервер 2000, ліцензії клієнтського доступу CAL, консалтинг, навчання)
•Тестова лабораторія резервується на чотири місяці
•Запрошення консультанта з Donaldson Education
Приклад статуту проекту (закінчення)
Статут проекту може містити стільки інформації, скільки необхідно.
Звичайно він доступний у всій компанії (за винятком фінансових даних), тому потрібно кілька разів перевірити його до випуску.
Доступність статуту проекту в усій компанії, що особливо зачіпає всіх її співробітників, дозволить включити в роботу всіх зацікавлених осіб, погодити проект і повідомляти про наступні зміни.
У статуті проекту чітко прописана відповідальність співробітників, що беруть участь у проекті.
Дякую за увагу!
•
•
Тема: Управління процесом виконання проекту
Декомпозиція функцій в управлінні проектами
Управлінська діяльність відповідно до PMBOK Guide – Project Management Body Of
Knowledge
•Розширення PMBOK у застосуванні до ІТ-проектів
1.Декомпозиція функцій в управлінні проектами
1. Декомпозиція функцій в управлінні проектами Концепція управління проектом може розглядатися в різних аспектах.
Найбільш поширеними є:
•
•
•
•
функціональний;
динамічний;
предметний;
процесний.
Функціональний підхід Досягнення цілей проекту здійснюється через функції управління.
Функція управління у застосуванні до управління проектом означає діяльність команди проекту по управлінню проектом.
Реалізація кожної функції забезпечується відповідним управлінським підрозділом, який є структурним елементом системи управління проектом.
Цей підхід найбільш універсальний, передбачає розгляд таких основних функцій управлінської діяльності:
•планування,
•організація,
•координація,
•активізація,
•контроль.
Динамічний підхід
передбачає розгляд у часі всіх процесів, пов'язаних з основною діяльністю по виконанню проекту; дозволяє визначити конкретний зміст функцій на кожному етапі здійснення проекту.
Цей підхід пов'язаний з логікою розвитку робіт і визначає так зване спеціальне управління реалізації проекту, яке включає
•
•
аналіз проблеми,
розробку концепції проекту,
•
•
•
базове і детальне проектування,
будівельно-монтажні і пусконалагоджувальні роботи,
експлуатацію і демонтаж.
Предметний підхід визначає об'єкти проекту, на які направлене управління.
Наприклад, підготовка приміщення для розміщення ІТ-служби, серверної, розробка ПЗ, впровадження системи тощо.
1.Декомпозиція функцій в управлінні проектами
Зметою декомпозиції функцій використовується і такий аспект, як рівень діяльності.
Виділяються два види такого розділення: організаційний рівень і масштаби діяльності по управлінню.
•Організаційний рівень: проект загалом; міжфірмові утворення; організації-учасники; окремі колективи розробників.
•Масштабність діяльності: політика; стратегія; тактика; функції; процедури; операції.
Процесний підхід
Процеси – дії та процедури, пов’язані з реалізацією функцій управління.
Процесний підхід до виділення функцій в управлінні проектами наведено на наступному слайді
Процесний підхід Зазвичай процеси управління проектами представлені як дискретні елементи із чітко визначеними
взаємодіями.
На практиці вони накладаються один на одного й взаємодіють такими способами, які повністю розкрити нереально.
Фахівці з управління проектами, визнають, що існує багато різних способів управління проектами.
Необхідні групи процесів і їхні складові, що пропонуються різними стандартами і методологіями, є
орієнтирами для застосування відповідних знань і навичок управління проектами при реалізації конкретного проекту.
Процесний підхід Застосування процесів управління проектами є ітеративним, і багато процесів повторюються кілька
разів протягом проекту.
Групи процесів управління проектами пов'язані за допомогою виходів (результатів), які вони виробляють.
Вихід одного процесу, як правило, стає входом для іншого процесу або є результатом проекту.
2. Управлінська діяльність відповідно до PMBOK Guide – Project Management Body Of Knowledge
PMBOK
•концентрація кращої практики (best practice);
•основа взаємодії між командами проекту;
•база для сертифікації фахівців;
•систематизація знань у специфічній галузі - управління проектами. Відповідає на питання «ЩО РОБИТИ?» «ЯК РОБИТИ?» - визначається корпоративними регламентними документами
Організації
1. PMI - Project Management Institute
(Інститут управління проектами, США)
PMBOK – Project Management Body Of Knowledge – звід знань по управлінню проектами - стандарт ANCI (American Standards Institute)
2. APM - Association of Project Management
(Асоціація управління проектами, Великобританія)
APM Body Of Knowledge
Зміст стандарту PMBOK 2008
Розділ 1. “Структура управління проектами” - формує основу для розуміння суті управління проектами (Вступ, Життєвий цикл проекту і організація)
Розділ 2. “Стандарт для управління проектами” визначає процеси управління проектами для окремого проекту, а також входи і виходи для кожного процесу.
Зокрема, виділено п'ять груп процесів управління проектами: ініціація, планування, виконання, моніторинг і контроль, і завершення; співвіднесено галузі знань з управління проектами із зазначеними групами процесів.
Розділ 3. “Галузі знань управління проектами” описує галузі знань управління проектами; в ньому перераховані процеси управління проектами и визначені входи, інструменти, методи і виходи для кожної галузі.
Усього виділено:
9 галузей знань; 5 груп и 42 процеси
Основні зміни в PMBOK4
Добавлено (основне)
•
•
•
Сбір вимог, аналітика и протипування
Ідентифікація зацікавлених осіб
Ітеративність фаз
Змінено (основне)
• Статут проекту позбавлений функцій ініціалізації
Вилучено (основне)
•
•
•
Попередній зміст проекту
Планування змісту
Вагова модель по закупках
PMBOK 4 став ітеративним?
•
•
•
•
•
PMBOK 3 передбачав тільки «Водопад» (каскадну модель)
PMBOK4 запропонував ітеративне ведення проектів
Порівняння PMBOK й ітеративної методики Agile
PMBOK – священна корова це сам план
Agile – священна корова це результат (Value)
Мишель Слигер, PMP, Master of Scrum
Нове у фіксуванні сфери охоплення
•Опис вимог стейкхолдерів
(Stakeholder Requirements Documentation)
•План управління вимогами
(Requirements Management Plan)
•Матриця трансформації вимог
(Requirements Traceability Matrix)
Методи збору вимог по PMBOK4
•Інтерв'ю
•Фокус-групи по компетенції
•Тематичні сесії (Facilitated Workshop)
•Креативні техніки прийняття рішень і вирішення конфліктів інтересів стейкхолдерів
•Опитувальники
•Спостереження за виконанням процесу в реальності, а не тільки по паперах
•Прототипи
Опис вимог за PMBOK4
•які бізнес-проблеми вдасться розв'язати продуктом проекту;
•відповідність цілей проекту і бізнесу;
•функціональні вимоги, включаючи опис бізнес-процесів и взаємодію з кінцевим продуктом проекту;
•вимоги до якості;
•опис коригувань організаційної структури;
•опис змін у поточних бізнес-процесах;
•вимоги до технічної підтримки і навчання
Ідентифікація зацікавлених осіб
Основні діючі особи (керівники)
• Менеджер (керівник) проекту (Project Manager) - особа, відповідальна за управління проектом