Как мога да класифицирам професионалните стандарти за управление на проекти. Приложения към регламентите. Организационен матуритет на управлението на проекти

Ако психологическите аспекти на ръководството и изкуството на изграждането на междуличностни отношения в проекта са приоритет за западните мениджъри, техните вътрешни колеги предпочитат процедурен подход. Това наистина е така (поне по отношение на руските мениджъри) и означава, че работата в определени ограничения и стандарти не е само позната на нашите мениджъри (нека си припомним поне съветските герои), но също така доста удобно. И какво тогава говори за управлението на компанията, за което присъствието и изпълнението на тези стандарти означава гарантирано ниво на качество на проектите?

И накрая, споменаваме, че практиката на създаване на собствени методи и ръководства за управление на проекти е широко разпространена в най-големите западни компании, като Oracle, IBM, Pricewaterhousecoopers, Andersen Consulting, SAP AG, Siemens и др.

Всички тези съображения и ни позволяват да приемем, че темата на стандарта за управление на проекти в предприятието трябва да причини лихва. Предлагайки този доклад, ние се основаваме на нашия собствен опит и опит на нашите колеги за създаване на такива стандарти, а не само за клиенти на трети страни, но и за техните компании.

Какво е специфичното съдържание на такъв стандарт? Как да направите стандартния инструмент за управление на работното място на предприятието? Какви информационни технологии могат да се използват за подпомагане на стандарта?

Това и други свързани въпроси са посветени на доклада.

1. Общи съображения за създаване на стандарт. Специализация и детайлизиране.

Стандартите за управление на проекти на предприятието по отношение на методологията обикновено имат основа, определена от документи с доста общ характер (понякога тези документи се наричат \u200b\u200b"рамка"). Такива документи се отнасят до управителния орган на проекта (PMBOK) на Американския институт за управление на проекти (PMI), признат от много международен стандарт за деколта и стандарта ISO 10006: 1997, който даде редица най-важни разпоредби на PMBOK Standard de Юра. Значението и съдържанието на прехода от рамковите стандарти (какви са pmbok и в повече повече от ISO 10006) Стандартът на компанията се състои в тяхната специализация и подробности.

Специализация означава включване в стандарта на предприятията от тези и само тези разпоредби, свързани с дейностите по проекта в това предприятие и в задължителни за реалностите на това предприятие. На първо място, от това следва, че такива реалности трябва да бъдат ясно определени. Е, необходимо е да се определят реалностите в добре дефинирани концепции, измерими показатели и др. Във връзка с това стандартът на дружеството неизбежно трябва да съдържа описание и класификация на фирмени проекти.

Фирмените проекти могат да се отнасят до различни професионални области на дейност (правни, финансови, информационни, строителни, маркетинг и др.), Имат различна сложност от гледна точка на решени задачи, различна скала от гледна точка на привлечените ресурси и предвидения резултат. Могат да бъдат разпределени някои категории проекти, специфични от гледна точка на специфични отрасли. Например, в стандарта на Enron, специализирана в областта на електрическата индустрия, международните (чуждестранни) проекти се разглеждат отделно, тъй като представят специални изисквания за законодателна база, персонал, оборудване, икономическа инфраструктура, логистика и др.

Организационните структури и персонал на проекта също са обект на специализация. Стандартът на предприятията може не само да бъде записан от стандартни дизайнерски роли (ръководител на проекта, администратор, мениджър на качеството и др.), Но също така и за определяне на структурата и принципите на формиране на органите за управление на проекти. Пример за такава специализация може да обслужва управленска структура на две нива в проекти за прилагане на ERP системи.

За всички постоянни (дефинирани редовни структура) на единици, по един или друг начин, свързани с изпълнението на проектите, следва да се определят принципите на тяхното участие в проекти - видовете работа, процедурата за разпределяне и изземване на персонал, формулярите и размера на полученото възнаграждение.

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

Предмет на специализация определено е процеси на управление на проекти. Общият набор от възможни процеси ще бъде подаден под формата на триизмерно пространство, показано на фиг. 1. относно координатните оси, тези размери, посочени в рамкови стандарти, се депозират, други, като например контролните нива, могат да бъдат предложени календарни периоди. Всяка точка на това пространство е основен процес на управление. Например: "Планиране на риска на етапа на изпълнение на системата.

Избраните елементарни процеси образуват процедури за управление на проекти, които могат да бъдат изградени върху принципа "аксиален" (тук се дължи на абсцисата, ордината и приложението, посочена на фиг. 1).

Всъщност описанието на тези процедури е основният обем на стандарта. И ако станете по-точни, под стандарта на предприятието, ние разбираме набор от документи, обясняващи или предписват как, в каква последователност, в кои времеви рамки, използвайки кои шаблони трябва да изпълняват определени действия в процеса на управление на проекти. Броят на тези документи зависи от степента детайли Стандартен и може да бъде доста голям (от десетки до стотици документи). На фиг. 2 Те са представени под формата на стъпало (цилиндрична зигформи), която обикновено се изгражда върху нея като пробуждане на апетит страхотно при тези, които организират и регулират работата в предприятието, и стандарта на разработване на стандарта .

Предмет на описанието в стандарта може да бъде и типични ситуации, характерни за проектите на предприятията и препоръки за отговор на тези ситуации. Това е един вид решения, нещо като списък възможни грешки и препоръки за тяхното премахване (контролен списък). Разбира се, решението все още ще получи мениджър, но има генерализиран опит ("син на труден") от предишни поколения.

Фиг. 1. Процеси на космически контрол

Фиг. 2. структурна структура на управлението на проекти

2. Класификация на проектите като първи етап от създаването на стандарт

Ключовият момент в създаването на стандарта за управление на проекти е да разберем какви проекти се извършват в предприятието, какви са техните различия, което е между тях. Тези въпроси са свързани с практиката на управление на проекти и са отразени в предприятието стандарт.

Сред западните колеги становището е често срещано, че професионалният ръководител на проекта може успешно да приложи всеки проект, независимо от това коя област се отнася - от изграждането на ядрена електроцентрала преди проектиране софтуер. По принцип тази теза е валидна, но дяволът, както знаете, лъжи в детайлите! Колко време се нуждае и има такъв запас? Какъв е размерът на консултантите и какви квалификации? Колко ще струва такъв ръководител на проекта само по себе си и колко голяма ще има допълнителни разходи?

Това е особено важно за предприятията, които прилагат всеобхватни проекти, вълнуващи различни тематични области. Характермен пример, в който е еднакво очевиден и необходимостта от привличане на "универсален" ръководител на проекта и начини за намаляване на цената на нейното "съдържание", е проектът за създаване на клон на банката. Такъв проект включва редица взаимосвързани и в същото време спрямо независимите подпроекти: правно, строителство, технологично, то, набиране, маркетинг и др. В големи банки клоните се създават от десетки. След един или два такива проекти опитът им може да бъде достатъчен за формиране на типични цели и резултати, стандартни календарни и ресурсни планове и бюджет за всеки вид проекти (подпроекти), идентифициране на добре познати рискове и ефективни работни стратегии с тях и др. .

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

Какво трябва да бъде отразено в плана за управление на проекта

Организационна структура - отговорност и процедура за взаимодействие на участниците, имената и отговорностите на ключовите фигури на проекта

Контрол документация за проекта - Структура, околна среда и процедура за съхранение за създаване и поддържане на хранилището на документите по проекта, списък на шаблоните за документи.

Управление на заминаването - процедури за работа с рискове, с възникващи проблеми и промени, форми на съответните документи на проекта

Осигуряване на качеството - списък и разпоредби за събития, насочени към предоставяне на качество, както резултати от проекта (продукт) и процеси за управление на проекти и управление на работата.

Контрол и отчитане - Правилник за извършване на мерки за анализ на състоянието на проекта, съответстващ на формулярите за докладване.

Предимствата на типичните шаблони са очевидни - спестявания на консултанти, унифициране на подходите, намаляване на времето за изготвяне на проектна документация. Има и недостатъци, отбелязваме тук само две. Създаването на такива шаблони е случай доста труден и те ще ги използват или не, предварително не е известно. Това зависи от волята и постоянството на управлението на предприятието. Вторият - съществува страх, че присъствието на такива шаблони ще бъде да се съсредоточи инициативата и независимостта на ръководителя на проекта и той няма да може да реагира адекватно на необичайни ситуации. Струва ни се, че тези трудности няма да бъдат толкова критични, ако шаблоните са удобни, а тяхната специализация и подробности ще бъдат оптимални за това предприятие и неговите проекти. И това е въпросът за качеството на работата на консултантите и анализаторите, създаващи стандарт.

Колко различни шаблони за управление на проекти са подходящи в стандарта? За да отговорим на този въпрос, е необходимо да се изгради класификация на проектите, извършвани в предприятието. Освен това е очевидно, че за всяко предприятие ще бъде уникална класификация. Всъщност с изграждането на такава класификация и създаването на стандарта трябва да започне.

Първо, отбелязваме, че е малко вероятно да се изгради едно дърво класификация на проекти за предприятия. Най-вероятно те ще бъдат няколко класификации по различни причини, свързани с определени раздели на плана. Помислете за някои от тях.

Класификация за тема и продукти в тези области Позволява специализирани секции Съдържание и граница, Ключови етапи, Изисквания и стандарти. Тази класификация може да бъде изградена на йерархичен принцип. Например "информационни технологии" - "Проекти за системна интеграция" - "Създаване на интегрирани системи за управление на проекти".

Класификация на скалагирането на проекта Позволява специализирани секции Организационна структура , Управление на отклонение, осигуряване на качеството . Различни бази могат да бъдат използвани за изграждане на тази класификация - териториална дисперсия, както е обичайно в Enron Corp., или цената на проекта (IBM) може да бъде някои други основи и комбинации от тях.

Класификация под формата на плащане и следователно, отчитане на работата Позволява специализиране Контрол и отчитане, Управление на проектната документация Въз основа на такива форми на договори като "време и материали" и "фиксирана цена".

По този начин можете да говорите например за плана за управление на проекта "за създаване на концепция ( продукт) информационна система ( тема област) на стойност повече от $ 100 хиляди ( мащаб) с договор във формата на формата и материалите ( форма на плащане и счетоводство) ", като макроскреин, получен чрез просто сглобяване на няколко по-малки (микро) шаблона на отделни дялове на плана. В допълнение, някои допълнителни секции, които не могат да бъдат определени на микроразпределението (като" времето, трябва да бъдат включени в Macroshlock работи на етапи "). Micoshobs могат да бъдат дълбоко специализирани - колко позволява съответната класификация и опит, придобит в предприятието.

Примерите за класификации на проекта, разглеждани по-горе, са специално избрани от нас, за да илюстрираме способността за изграждане на шаблон от относително независими стандартни фрагменти. Въпреки това, в реалния живот има и други ситуации. Например, прие IBM класификация на сложни проекти (сложност). В съответствие с тази класификация, проектите се разделят на обикновен бизнес (бизнес като обичай - BAU), стандартни проекти на системна интеграция и комплексни проекти системна интеграция. Освен това, тази класификация определя за структурата и съдържанието на плана за управление на проекти. В този случай, други класификации запазват стойността си, за да образуват отделни дялове на плана.

3. План за управление на проекти

Планът за управление на проекти, съдържащ документирана представа за проекта, съгласуван от всички участници, е фундаментален документ - "точка на подкрепа" за цялото последващо развитие на проекта.

Нека покажем как могат да изглеждат някои раздели от специализиран план за управление на проекти. Ние използваме за този пример за проект за създаване на клон на банката, даден в предишния раздел. Помислете за подпроцеса на създаването на ИТ инфраструктурата на клона на банката.

При изграждане на специализирано микро-заключване "съдържание и граница на проекта" използвахме препоръките на PMBOK PMI (Таблица 1).

В този шаблон само имената на софтуера и времето на изпълнението на стъпките на работа остават.

Описание на количествените критерии, които трябва да бъдат изпълнени за проекта, за да се счита за успешен

Времето за доставка на оборудване и софтуер в Москва не трябва да надвишава двадесети дни.

Степентът на оборудването и софтуерът в Москва не трябва да надвишава дните си.

Крайният срок за транспортиране на оборудване и софтуер в клон на банката не трябва да надвишава zz дни.

Крайният срок за инсталиране и създаване на оборудване и софтуер в клона не трябва да надвишава WW дни.

Сравняване на съдържанието, дадено в примера Проект проект и Резултати от проекта Може да се отбележи, че резултатите от проекта са елементи на декомпозицията на продукта на проекта. Ето защо при формирането на план (и следователно при формирането на образец на план) често се използва структурата на декомпозицията на работното място (WBS - структура за разбивка на работата) и много водещи компании включват в своите методологии и стандарти типични WBS като изрично (Andersen Consulting), така че имплицитно (IBM).

Структура на разлагане на работата

За да се извърши разлагане и да се направи структура на разлагане (WBS - структура на разбивка), според някои автори, тя е много лесна: "На първо място, проектът трябва да бъде разделен на няколко подпроекта. Всеки от подпроектите, на свой ред, може да бъдат разделени на определен брой предпроекти. Така следва последователно разделянето на проекта на компонентите, докато ще бъде достигнат желаното ниво на детайлност "(ние ще цитираме в статията М. Нюгава" Структура на разлагането на произведения "в Март на списанието " информационна услуга"За 2001 г.).

Всъщност всичко не е определено и ще бъде не само за трудностите при създаването на WBS, но и за отварянето на възможностите. Помислете за проблема за примера на проекта за създаване на информационна система (IP).

На етапа на инициализиране на проекта ръководителят на проекта трябва да отговори на редица въпроси (всъщност, те, разбира се, много повече, но ние сме ограничени до тях):

какво да правите (дефинирайте продуктите на проекта),
как да го направите (дефинирайте технологични етапи проект)
който ще направи това (идентифициране на изпълнители, конети, подизпълнители),
кой и в каква форма ще плащат за работа (определят какви договори ще бъдат сключени).

Какви са подпроектите за прекъсване на оригиналния проект? Какво ще бъде по-удобно да се види на първото ниво на разлагане - IC компоненти (софтуер, техническа, информация) или технологични етапи (концепция, техническа задача, дизайн и др.)? Или може би тя може да бъде по-удобна за групова работа в изпълнители или клиенти?

Например, ако проектните работи се извършват в интерес на различни клиенти и в същото време се финансират от различни инвеститори (виж фиг. 3) разлагането може да се извърши или чрез значителен знак за възлагане на работа на проекти, \\ t или според официалния знак за приписване на труд за финансиране на споразумения. Друг случай е фиксиращ в структурата на работата на подизпълнителите. След това, за етапа на плана на календара на проекта, има официално разпределени групи от строителни работи, извършвани от главния изпълнител (изпълнител) и други изпълнители (подизпълнители). Това разлагане е препоръчително да се прилага, ако са фиксирани големи логически взаимосвързани блокове на работа зад подизпълнителите, относително независими проекти от други произведения.

Така че тук рецептите за всички случаи не съществуват тук. Освен това, всеки от споменатите алтернативни мнения е интересен и има право да съществува, ползата от инструментите за планиране на календара ви позволява да поддържате много различни групи работа.

И следователно първото нещо, което трябва да бъде отразено в специализиран шаблон за WBS е какви алтернативни мнения за структурата на декомпозицията на работата следва да бъдат подкрепени в проекта (гледна точка на ръководителя на проекта, гледна точка на куратора, гледна точка на инвеститора, \\ t и т.н.).

Ако се изисква разлагане за няколко различни бази, трябва да се посочи основното нещо (обикновено е изглед на ръководителя на проекта). За да се подкрепят други възгледи, трябва да бъдат определени подходящи функции за класификация, описани като характеристики. подробна работа. Такива знаци могат да се използват, например, код на проекта, код на договор, код на подизпълнители и др.

План за управление на проекти и рамкови стандарти

Някой може да изглежда създал шаблон за план за управление на проекти просто просто, необходимо е само да има "рамкови" стандарти, като PMBOK и ISO 10006 и да разберат тематичната област. Всъщност това изобщо не. В повечето случаи рамковият стандарт предоставя само концептуалния апарат и общите методологически принципи. Освен това случаят също така се усложнява от факта, че необходимата информация в самите рамкови стандарти "разпръснати" на различни секции и не е толкова лесно да се "събира, изгражда и води до общ знаменател".

Ще илюстрираме това при примера на не най-трудния раздел на плана "Организационна структура на проекта". В PMBOK необходимата информация е разпръсната в няколко секции (2.2.; 2.3; 2; 4; 4.1.3.; 9) и в ISO 10006: 1997 (e) - раздел 5.8. Но в това и в друг случай не е достатъчно да се създаде специализиран шаблон на тази информация!

Така, въз основа на методологията "рамка", следва да се създаде корпоративна методология, в която са определени основните разпоредби, изисквания, принципи и практики на управление на проекти и систематизирани във връзка с управлението на проекти в това предприятие въз основа на анализа на специфичните особености на проектите, извършени от предприятието.

Тази корпоративна методология и специализирани шаблони за документи са създание на стандарта за управление на ниво предприятие. И процесът на създаване на стандарта прилича на спирала, на всеки нов обрат, от които техниките стават все по-специализирани, а шаблоните все повече подробни са.

На първо място, ще обясним термина "отклонения", това е необходимо, защото в литературата за управление на проекти се тълкува двусмислено.

В предишния раздел говорехме за плана за управление на проекти - фундаментален документ, съдържащ документирана представа за координирания проект от всички участници. С други думи, планът за управление на проекти е "точка на подкрепа" или базовата линия за цялото последващо развитие на проекта.

Въпреки това, вече планирайки проект, ние приемаме, че не всичко ще се окаже точно както е планирано. И истинското изпълнение на проекта, като правило, потвърждава тези опасения. Неограничаването на първоначалното съгласувано и фиксирано представяне на проекта (изходно ниво на проекта) и това, което се получава в действителност и обикновено се наричат \u200b\u200bотклонения. Терминът "отклонения" е еквивалентен на термина "отклонения", използван в англоговорящата литература, разбира се в този смисъл.

В същото време, другият термин се приема в англоговоряща литература, която в руските публикации също се превежда като отклонения. Този термин обозначава не само неразпределеното и планираните резултати, но и причините за тези несъответствия, както и методи и технологии (управление на изключения), което позволява да се справят с такива ситуации в проекта с минимални загуби. Това е по-широко тълкуване, че ще имаме предвид в бъдеще, като говорим за отклонения.

Традиционните области на управление на проекти, по един или друг начин, свързани с отклоненията, включват рискове, проблеми и промени. И въпреки че не във всички стандарти, тези понятия се съчетават с цялостната концепция за отклонение, наличието на взаимоотношения между тях е очевидно. Разбирането на тези връзки и адекватно отразените в стандарта за управление на проекта, не само правилно ще изгради процедурна и документална част от стандарта, но и дори по-важното, тя ще осигури възможност за систематично контролиране и анализиране на отклоненията, както в отделен проект, така и в отделен проект, така и на мащаб на предприятието като цяло.

Обърнете внимание, че представените в този раздел съображения не са разсеяни аргументи и се основават на материалите на настоящия стандарт за управление на проекти на IBS. Благодарим на компанията за възможността за използване на тези материали и екипа на разработчиците (Иля Виноградов, Мария Чуков) за възможността за използване на тези материали.

Сценарии за управление на отклонение

Управлението на отклонението се свежда главно до борбата срещу неприятностите, които като цяло могат да включват три етапа:

Управление на рисковете. Проблемите не са дошли, но е възможно да се появят с нежелани и непланирани събития, които могат да доведат до факта, че целите на проекта (една или няколко) няма да бъдат постигнати. Целта на този етап е да се предотвратят неприятности преди тяхното възникване или поне да ги посрещнем в изпълнение.

Управление на проблеми . Дошли са проблемите и е необходимо да се открие техният произход, степента на влияние върху проекта, методите за преодоляване. Целта на този етап е да предоставим на проекта възможност да отидат както е планирано.

Управление на промените. Проблемите се оказаха доста сериозни и не беше възможно да се справят с тях, без да се засяга проекта. Целта на този етап е, че финансистите се наричат \u200b\u200b"да записват вреди" - изменение на предварително договорените продукти и услуги, времето на изпълнение и разходите за работа, управление и технологични процеси и др.

Строго казано, отклоненията не могат да бъдат непременно свързани с проблеми. Така рисковите събития включват желани, но непланирани събития (възможности). Съответно, промените ще бъдат положителни. Например, намаление на данъчната ставка позволява да се намали частта от бюджета на проекта. Въпреки това, в рамките на този доклад, ние ще говорим само за отклонения с минус знак.

Събитията в проект, свързани с отклонения, могат да се развият на различни сценарии, някои от които са представени на Фиг. четири.

Фиг. 4. Обща схема Управление на заминаването

Цикълът за контрол на пълното отклонение съответства на първия сценарий, в който

По време на планирането на проекта беше идентифициран риск, но работата с нея не доведе до желания резултат,

Проблемът, който се случи в резултат на появата на рисковото събитие, също не беше решен успешно,

И всичко това доведе до необходимостта от промени в плана на проекта.

За сравнение, помислете за втория сценарий, в който се изпълняват промени в проекта, без да се чакат проблеми. Това е справедливо отговорно решение. Ситуации, при които такива решения са оправдани, могат да бъдат описани в стандарт със специфични категории рискове и количествени оценки на риска, при които този сценарий трябва да бъде приложен.

От особен интерес от гледна точка на анализа на отклоненията представляват четвърти и пети сценарии, съответстващи на случаите на възникване на проблеми, които не са посочени като рискове. Причината за това може да бъде, например, атипичната ситуация или просто "загубата" на риска в резултат на липса на квалификация. Резултатът от анализа на причините и тежестта на последиците може да бъде решението, че за определени категории проекти на предприятието не е препоръчително да се ангажира дълбоко в управлението на риска и е достатъчно просто да се решават проблеми, тъй като те се случват. Докато за други категории на проекта, напротив, е необходимо да се укрепи рязко работата с рискове.

Още веднъж акцентираме, че рисковете, проблемите, промените са тясно свързани помежду си, а според нас следва да се разглеждат в стандарта съгласно раздела за унифицирано отклонение. Но планираните облигации за нас на равнище сценарии трябва да бъдат подробно подробно в процесите на управление на частния риск, проблеми и промени, чието съображение отиваме.

Управление на рисковете

Най-простите и в същото време, които трябва да бъдат отразени в стандарта - формалната страна на управлението на риска, а именно:

Процедури, регулиращи основните етапи на работа с рискове - идентифициране на риска, мониторинг и анализ на риска, планиране на развитието и реализиране на рисково противодействие.
Шаблони на документи, отразяващи процеса на работа с рискове - рискова карта, дневник за риск за проекта и др.

От разнообразието от методи за управление на риска за стандарта трябва да бъдат избрани тези от тях, които са адекватни на проекти, в които те ще бъдат приложени. Тук имаме предвид преди всичко, разходите за изпълнение на процедурите за управление.

Така, когато анализира рисковете, може да бъде разрешено съзнателно намаляване на оценките за някои специфични категории проекти, например за проектите с ниска цена или сложност. Пример за този подход е даден Маса. 2 когато, като обща оценка на риска, степента на заплаха за риск, "изчислена" чрез вероятността от настъпването на рисково събитие и неговото въздействие върху напредъка на проекта.

Маса. 2. Заплаха от риск от матрица

Вероятност на събитие Въздействие върху проекта	Нисък по-малко от 20%	Средно аритметично от 20 до 60%	Високо повече от 60%
Слаб Може би появата на въпроси или проблеми в проекта, но едва ли води до нарушение на графика на календара, бюджета или влошаването на качеството на продукта		Средно аритметично	Средно аритметично
Средно аритметично Може би нарушение на графика, увеличаване на разходите или влошаването на качеството на продукта	Нисък	Високо	Високо
Сила Може би значително нарушение на графика, увеличаване на разходите или влошаването на качеството на продукта	Средно аритметично	Високо	Критичен

"Цената на разделянето" е както на помощната (вероятност и влияние), така и в основния мащаб (степента на заплаха) трябва да се определи от чисто практическите съображения - възможно ли е да се постигне или друга точност и може да се използва.

Какви сценарии ще развият увреждания в проекта, до голяма степен се определя от приетите работни стратегии с рискове. Можем да направим всичко, за да избегнем риск, а след това най-вероятно е вторият сценарий (виж Фиг. четири). Ние, напротив, можем да поемаме рискове и да не го противодействаме, позволявайки развитието на събитията в първия или в третия сценарий. Можете също така да намалите риска и след това с благоприятно развитие на събитията, най-желаният сценарий се прилага, когато рисковото събитие не се случи.

Управление на проблеми

На първо място, ние ще обясним какво наричаме проблеми и защо проблемите могат да бъдат контролирани (и необходими).

В курса реална работа При създаването и прилагането на стандарта за управление на проекти в предприятието авторите трябваше да се изправят пред факта, че фразата "управление на проблемите" причинява недоумение сред колегите, които не са се запознали с английските стандарти за управление на проекти. Много хора изглеждат по-запознати с "решението" или "решаване на проблеми", които съответстват на "решаването на проблема" или "резолюция на проблеми", приети в така наречените "рамкови" стандарти, споменати по-горе.

Авторите в този брой предпочитат да следват духа и писмото на такива стандарти за управление на проекти като MITP / PMM / WISDD IBM Corporation, в което този процес се нарича "проблеми / проблеми с управлението на проблемите", който в руския превод е най-добър, според нас , изглежда като "проблеми".

Проектът се разбира като всеки функционален, технически или свързан с бизнеса въпрос, който се появява в процеса на проекта и изисква отговор - проучване и решения, за да се гарантира, че проектът може да бъде планиран. С други думи, проблемът е изключителните обстоятелства, които трябва да бъдат контролирани (т.е. мениджърите) от момента на тяхното възникване.

Обикновено проблемите се разделят на две категории - за проблеми, които могат да бъдат решени на мястото на възникването, т.е. на равнището на управление на проекта - проблеми и ескаливите проблеми - въпроси, които за тяхното разрешение е необходимо да се повиши Високо управление на управлението, включително външни софтуерни връзки с проекта.

Стандартът трябва да отразява официалната страна на управлението на проблемите:

Процедури, регулиращи основните етапи на работа с проблеми - идентифициране на проблема, наблюдение и анализ на проблема, вземане на решение и неговото изпълнение, затваряне на проблема.
Шаблони на документи, отразяващи процеса на работа с проблеми - проблеми с карти, дневник за проблеми с проекта и др.

Могат да се разработят специални решения за анализ на проблеми. Например, за да се определи такова най-важната характеристика Проблеми като приоритет на неговото решение могат да бъдат използвани от приоритетната матрица, дадена в Маса. 3 .

Маса. 2. РЕШЕНИЕ НА ПРИОРИТЕТИТЕ НА MATRIX

Спешност Въздействие върху проекта	Не-ужас	Приоритет	Спешен случай
Слаб Малко вероятно е да доведе до нарушение на календарния план, бюджет или влошаване на качеството на продукта	Незначителен	Незначителен	Важно
Средно аритметично Може би нарушаване на плана на календара, увеличаване на стойността или влошаването на качеството на продукта	Незначителен	Важно	Особено важно
Сила Може би значително нарушение на календарния план, увеличаване на разходите или влошаването на качеството на продукта	Важно	Особено важно	Особено важно
Особено важни проблеми - изискват незабавно решение с участието на всички необходими ресурси. Важни проблеми - изискват спешно решение с участието на всички налични ресурси. Малки проблеми - изискват решения в рамките на наличните ресурси, без да се засяга останалата част от проекта. Значителни проблеми - не се правят действия за решаване на проблема, преди да се промени приоритет.

Включването на процеса на управление на управлението в стандарта за управление на проекта на предприятието трябва да се има предвид, че въпреки че е необходимо управление на проблемите за всички проекти, но степента на използване на формалните процедури трябва да съответства на спецификата на проекта и, \\ t Преди всичко, неговото мащаб и сложност. За малките проекти разходите от пълното използване на този процес могат да бъдат прекомерни.

Управление на промените

Провеждане на примери, илюстриращи работата с рискове и проблеми, разчитахме на традиционни ценни проекти - ресурси, срокове, качествени характеристики на продукта. Ясно е, че контролните влияния, свързани с противодействащите рискове или с решаване на проблеми, са ограничени от същите рамки.

Промяната в проекта е модификация на предварително договорените продукти и услуги, условията за изпълнение и разходите за работа, управление и технологични процеси и др.

Като традиционни мерки за промяна на използваните в проекта ресурси, той се използва например увеличение на интензивността на работата, материални стимули, заместване или привличане на допълнителни изпълнители и подизпълнители. Ако има възможност за маневриране, тогава можем да говорим за промяна на времето за завършване на индивидуалните произведения, изместване на крайъгълния камък в рамките на проекта или дори увеличаване обща сума завършване на проекта. И накрая, в някои случаи е необходимо да се прибягват до най-малко желаните мерки, свързани с намаляване на изискванията за качествени характеристики., замяна и дори изключение на продукта.

От гледна точка на тежестта на последствията промените могат да бъдат класифицирани, например, както следва:

Планирани загуби (взети предвид в плана за управление на проекти).
Допустими загуби (незначителни непланирани разходи).
Нежелани загуби (значителни непланирани разходи).
Невалидни загуби (непланирани разходи, които са неприемливи за един или повече участници в проекта).

За всеки проект, първоначално (макар и приблизително) степента на влияние на някои промени в големината на вероятните загуби, произтичащи от прилагането на тези промени. На фиг. 5 Тази информация е представена под формата на диаграма, в която промените са свързани със загуби. Разбира се, видовете възможни промени и техните местоположения по региони са собственост на конкретни проекти или по-скоро видове проекти. Следователно тези диаграми могат да бъдат включени в стандарта на предприятието като характеристика на видовете на проекта, определени в класификациите на проекта.

Ограниченията за промени в ресурса, времето, продуктите могат да бъдат твърди до различни степени и в зависимост от това в проекти има доста типични ситуации, които могат да бъдат предварително описани. Разгледайте някои такива ситуации.

Често стратегията на промените се определя от факта, че поне една от осите на промяната не трябва да води до излизане от площта на планираните загуби. И това означава необходимостта да се измести в едно или веднага в две други измерения. Така че, ако е известно, че клиентът е ориентиран, преди всичко, при спазване на планираното ниво на качество на продукта, трябва да се осигурят опции за промени, свързани с манипулирането на ресурсите и / или термини (стратегия "Stubborn клиент").

В други случаи могат да се изискват други стратегии, например "сурово време" или "ограничен бюджет, когато промените в крайните срокове и ресурсите следва да бъдат записани в областта на насрочените загуби.

Желаната и възможна алтернативна стратегия за измерване (виж фиг. 6) може да бъде показана в диаграмата. Сега, за да може да се сравни алтернативните варианти не само качествено, но и количествено, тя остава само за разработване на показатели за всяка от осите. И тогава стратегията може да бъде оценена, например, с площ от подходящия триъгълник.

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

Фиг. 5. Зони за загуба

Фиг. 6. Стратегии за промени в проекта

5. Организационни структури в проекти

Днес случаите, когато организационната структура на проекта съвпада с организационната структура на предприятието или част от неговата част. Много често служителите, в съответствие с графика на персонала, се разпространяват чрез функционалните разделения на предприятието и се формират специални временни организационни структури за изпълнение на проекта, наречени проектни екипи, включително представители на различни единици.

За да създадете и управлявате команда по проекта, се използват определени рецепти, които гарантират ефективността на тези процеси. Тези рецепти не са универсални и трябва да вземат предвид спецификата на предприятието - от организационната структура до произведения продукт.

Сред първите проблеми, които възникват при формирането на организационните структури на проекта и които трябва да бъдат решени на нивото на стандарта за управление на проекти, отбелязваме проблемите, свързани с кръстовищата на функциите административно управление и управление на проекти.

Началник на отдел и ръководител на проекта

Административното управление на предприятието се осъществява чрез системата за управление, чийто ключова връзка е средно мениджъри - ръководители на разделения, в пряко подчинение на предприятията. В проектирането и ориентираните предприятия значението на дейността на отдела е да се "разпространи" и по-точно да се "продават" всичките си служители в проекти.

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

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

В същото време редица задължения възникват както от ръководителя на отделите по отношение на проектите, така и от страна на ръководителите на проекти към разделенията на ресурсите. Тези задължения следва да бъдат определени в съответните разпоредби и длъжностни характеристики, а специалните случаи могат да бъдат описани в допълнение към плановете за управление на проекти.

Често възниква объркване, какви функции са компетентността на ръководителя на устройството и коя е компетентността на ръководителя на проекта. Това е особено характерно за случаите, когато ръководителят на проекта не е позиция в персонала на предприятието, но само роля на проекта, която може да бъде изпълнена, включително главата на устройството. В раздела. 3 показва няколко примера, илюстриращи тези различия в някои области, където административното и управлението на проекти имат точки за контакт.

Маса. 3. Събиране на отговорност в административното управление и управлението на проекти

Област на отговорност Контролна област	Отговорност на началника на дивизията (административно управление)	Отговорност на ръководителя на проекта (управление на проекти)
Планиране и контрол	Формиране на бизнес плана Планиращ бюджетен отдел Контрол "на къртици" Докладване преди управлението на предприятието	Подробен график на проекта Планиране на бюджета на проекта Оперативен контрол на проекта Докладване преди ръководството
Човешки ресурси	Приемане и уволнение Централизирано разпределение на ресурсите Контрол на дисциплината Организация на обучението	Формиране на екипа по проекта Анализ и оценка на служителите Прилагане на санкции и промоции Регламент за конфликт
Продукти за рамки (при примера на IP информационни системи)	Методологията за създаване е.	Дизайнът е. Е. Е.

Изпълнител

Но управлението на управлението и за проекти са необходими изпълнители и тези изпълнители се получават от персонала на функционалните единици. По този начин работното време на всеки служител на проекта и ориентираното предприятие е разделено на дизайн и непроективно. Заетостта на служителя разполага с ръководителя на отдела, ръководителите на проекти, в които е участвал служителят. Следователно, служителят в същото време няма нито един, но два, или дори повече, директни началници, заповедите, които той трябва да изпълни и преди който трябва да докладва за работата на работата.

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

За да може тази ситуация да не се превърне в източник на конфликт и стрес, трябва да се създадат ясни и лесни за изпълнителни правила, залегнали в стандарта на проектните процедури. Тези правила следва да регулират процедурата за издаване и хармонизиране на задачите, отчитане на разходите за работното време, разрешаване на конфликтни ситуации и др.

Един от основните критерии за качество на проекта трябва да служи на времето на служителя за тяхното изпълнение. Ако този път надвишава един час седмично, процедурите трябва да бъдат подобрени. Начини за подобряване на повече от достатъчно. Това е промяна в счетоводните политики и създаването на специални административни звена (както в екипи за персонала, така и в екипи по проекта) и накрая използването на съответните информационни технологии (управление на документи и управление на работата).

Екип по проекта

При формирането на организационни структури на проекти трябва да се спазват два основни принципа - разделяне на отговорностите и разделяне на областите на отговорност. В този смисъл решението е пряко свързано със сложността и сложността на проектите.

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

Изглежда, че ситуацията изглежда по отношение на области на отговорност. В прости проекти ситуацията е позната, когато самият мениджър на проекта извършва всички функции за управление на проекти (включително управление на риска, конфигурация, качество и др.). В сложни проекти ръководителят на проекта е принуден да създаде частен персонал, разпространявайки индивидуални управленски функции между техните служители.

Разпределението на отговорността по отношение на материални решения за продуктите на проекта обикновено се определя на нивото на работните групи. В същото време, ако в прости проекти мениджърът на проекта може да играе на непълно работно време и ролята на системния архитект (ако говорим за ИТ проекти), тогава за сложни проекти едва ли е препоръчително.

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

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

Например, често, по силата на практиката на практика, не всички функции за управление на проекти могат да бъдат отчуждавани от специализираните отдели за предприятията и прехвърлят екипа на проекта, като делегират съответните специалисти към неговия състав. За такива случаи следва да се предоставят и регулират и регулирани процедури за взаимодействие на екипа по проекта (например с финансовия отдел, планирането и икономическия отдел, логистична услуга и др.). На фиг. 7 показва диаграма на формирането на проекта и неговото взаимодействие със сродни услуги, което е характерно за компанията - системен интегратор.

Фиг. 7. Схема за формиране на екипа на проекта

6. Услуга за осигуряване на качеството и управление на проекти

Известно е, че расте добра морава много просто. Необходимо е просто да посетите и рязане - и толкова сто години. Приблизително ситуацията е и стандартът на управление на проекти в предприятието. Някой трябва да създаде стандарт и някой трябва непрекъснато да го възпроизвежда в обновяване на условията. Някой трябва да използва стандарта и някой трябва да следва начина, по който се използва.

Според нас най-правилният подход за трансформиране на стандарта за управление на проекти към работния инструмент е включването му в една система за управление на качеството в предприятието. Обмислете някои точки, свързани с този подход.

Планиране и контрол на качеството в проекта

Планирането на качеството на проектите се извършва, за да се изберат тези разпоредби на стандартите и стандартите, които са препоръчителни и евентуално прилагани към този конкретен проект, както и събития и работа, необходими за гарантиране на изискванията на тези стандарти по отношение на качеството на. \\ T резултати и процеси на проекта.

Планирането на качеството се извършва като част от процеса на планиране на проекта като цяло. Резултатите от планирането на качеството на проекта (план за качеството на проекта) следва да бъдат отразени в плана за управление на проекта.

План за качеството на проекта определя как ще бъде предоставен проектът с необходимото качество на работата от гледна точка на организационната структура, ресурсите, методологическата и инструменталната подкрепа. На етапа на планиране на качеството могат да бъдат създадени и документи, регламентиращи мерките за контрол на качеството на управлението на проекта, като плана за одит на проекта, формата на въпросника за наблюдение и управление на ръководството и др.

Изпълнението на проекта трябва да бъде планирано и систематично да се прилага под формата на различни дейности като одит, мониторинг и изследване .

Одит на проекта - Проверка на съответствието на формализираните организационни дейности за изпълнение на проекти, приети за стандарти за управление на проекти. Одитът се прави в определени часове на проекта за наблюдение на изпълнението на процедурите за управление на проекти, определени в стандарта, и коректността на проекта на проектните документи.

Важно е да се отбележи, че предметът на одита на проекта не е технически решения и съдържанието на техническата документация на проекта (одитът на техническите решения и техническата документация е предмет на процеси, изпълнявани в други подсистеми на системата за управление на качеството на дружеството ).

Мониторинг на проекта - Редовно изпълнена оценка на състоянието на проекта, като се вземат предвид различни дейности в рамките на проекта. Целта на мониторинга е да предостави ръководството на предприятието за оперативна съвкупна информация за изпълнението на проекта, достатъчна за приемане на ключови решения по проекта.

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

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

Фиг. 8. Диаграма на текущото състояние на управление на проекти

Проект за изследване - подробен анализ на някои области на дейност в рамките на проекта и подготовката на цялостната картина на проекта, за да се подобри качеството на изпълнението, както този проект, така и проектните проекти като цяло.

Експертизата се извършва най-квалифицираните и опитни специалисти В областта на управлението на проекта. За разглеждане и двете формализирани данни, получени в резултат на процедурите за одит на проекта и мониторинг и информацията, получена чрез консултации и интервюта и свързани с неформализирани (или слабо формализирани) региони за управление на проекти (компетентност на персонала, \\ t междуличностни отношения и т.н.).

Според резултатите от разглеждането се подготвя заключение, съдържащ анализ на причините, както и препоръки относно организационните решения и мерки за преодоляване на неблагоприятното развитие на този проект или, в случай на успешно развитие на проекта - за систематизиране и възпроизвеждане на положителен опит.

Услуга за управление на качеството и управление на проекти

Разбира се, за да се развие стандартен май (и да вземе смелостта да каже - най-често, трябва) да бъде включена в трети консултант. Въпреки това, цялата по-нататъшна съдба на стандарта напълно зависи от техните собствени усилия на специалисти и управление на предприятието. Следователно най-ранните етапи трябва да бъдат организирани специални услуги, отговорни за развитието и спазването на стандарта за създаване на стандарт в предприятието.

Такива услуги могат да включват услугата за управление на качеството и услугата за управление на проекти. Мястото на тези услуги в организационната структура на предприятието и техните функции са показани на фиг. девет.

Фиг. 9. Структура и функции на услугите, отговорни за качеството на изпълнението на проекта

Служба за управление на качеството По отношение на управлението на проекти предвижда:

Интегриране на стандарта за управление на проекти в обща система Фирмени стандарти.
Контрол на качеството на управлението на проекта под формата на одити на изпълняващите проекти за проверка на спазването на стандартите за управление на корпоративните проекти.

Ние не разглеждаме други области на услуги за управление на качеството, които не са свързани със създаването и използването на стандарт за управление на проекти. Трябва да се отбележи обаче, че ако такава услуга в предприятието съществува до началото на създаването на стандарта за управление на проекта, неговото развитие следва да се основава на системата за качество на системата за качество, създадена от тази услуга (политика на качеството, управление на качеството, управление на качеството, управление на качеството качество и т.н.).

Важно място в работата Услуги за управление на проекти Трябва да има методология за развитие за управление на проекти, включително:

Развитие, подобряване, координация на стандарта за управление на корпоративния проект, включително целия комплекс от организационни документи - процедури, инструкции, шаблони за управление на документи.
Разработване на изисквания за разширяване или изясняване на функционалните отговорности на свързаните единици, за да се осигурят функции за управление на проекти.
Подбор и организация на адаптирането и прилагането на инструменти за управление на проекти.
Корпоративно публикуване на одобрени материали, провеждане на семинари за тяхното използване.
Формиране на планове за подобряване на уменията на ръководителите на предприятия, организиране на обучение и сертифициране.

Друга важна характеристика на услугата за управление на проекти може да бъде прякото участие на своите служители в проектите на дружеството като управленски персонал. Това ви позволява да преминете към силна матрична организационна структура на предприятието, когато персоналът за управление на проекти е осигурен от службата за управление на проекти и техническите - различни функционални разделения на предприятието. Възможна схема за формиране на екипа на проекта и нейното взаимодействие със сродни услуги е показано на фиг.7.

И накрая, функциите на услугата за управление на проекти могат да включват и технически и информационни проекти, използващи инструментите за автоматизация. Въпреки това, ако софтуерът за управление на проекти е интегриран в цялостната софтуерна и техническа инфраструктура на предприятието, тези функции са препоръчителни за предаване на обединеното ИТ услуга на предприятието.

Може би някой, представен за прилагането на стандарта за управление на проекти, ще изглежда прекалено скъп, но според нас създаването на нова управленска култура в предприятието е иначе невъзможно - само за посещение и намаляване.

7. Тактика и стратегия Изпълнение на стандарт за управление на проекти

Разходите са свързани не само с развитието на съдържанието на стандарта, но и до много по-голяма степен с тези трансформации в системата за управление на предприятията, които трябва да придружават изпълнението на стандарта.

Разгледайте някои важни обстоятелства, които до известна степен ще позволят да се оптимизира тактиката и стратегията за разработване и прилагане на стандарта.

Основните етапи на създаване на стандарт за управление на проекти

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

Работейки в областта на консултациите, авторите перфектно представляват това дразнене, което може да доведе до определена категория на уважаваните колеги думите "концепция" и "техника". И въпреки това ще се осмелим да кажем, че предпочитаното от създаването на стандарт е пътят на последователния детайл, включително, включително етапите на развитие на концепцията и методологията за управление на проектите за предприемачество (вж. Грешка! Източникът на връзката не е намерен.).

Фиг. 10 . Етапи на създаване на стандарт за управление на проекти

Концепция за управление на проекти Това е фундаментален документ на системата за управление на проекти (супа), оправдаващ необходимостта от бизнеса за създаване на супа (включително икономическа ефективност на изпълнението), която определя основните си параметри и резултати, стратегия за прилагане и развитие, използвана автоматизация и информационна технология.

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

В корпоративна техника процесите на управление на проекти са описани в процедурите формат, който определя процедурата за извършване на основните етапи на проекта, използваните технологии и методологии, както и препоръчаните документи за управление.

И накрая работен стандарт Разработва и детайли процедури за управление на проекти, допълва техните подробни инструкции за изпълнение на процедури и шаблони на ръководни документи.

Стандарт за управление на проекти в общия контекст на управлението на предприятието

Стандартът за управление на проекти засяга най-различните аспекти на предприятието. Ето защо неговото развитие и прилагане следва да се извършват, като се вземе предвид общият контекст на управлението на предприятията, което е компоненти като система за качество, организационна структура, финансова система и други (виж фиг. 11).

Фиг. 11. Стандарт за управление на проекти в системата за управление на предприятията

Стандартът за управление на проекти е неразривно свързан с системата за качество и трябва да бъде хармонизирана с стандарти за качество, използвани в предприятието. В оптималната версия стандартът за управление на проекта трябва да бъде създаден като неразделна част от системата за качество на предприятието и може да бъде основата за подготовката на предприятието, нейните подразделения и служители към сертифициране съгласно ISO 9000 и управлението на проекти.

Въвеждането на методи за проектиране на управлението значително засяга организацията на бизнеса на компанията и обикновено води до определени промени в организационната структура на предприятието, в документа, в някои бизнес процеси. Стандартът за управление на проекти е най-подходящият начин за поправяне на тези промени в де Юре, които, разбира се, не е възможно без заинтересованото участие на висшето ръководство на предприятието.

Отделен и много важен въпрос е финансовото управление на предприятието, което изпълнява дейността си в проектната форма. Тук връзката между трите вида бюджетни бюджети - бюджетът на проекта, бюджета на разделението и бюджета на предприятието като цяло.

Тези и други подобни въпроси са в рамките на компетентността, а не толкова много специалисти по управление на проекти, колко консултанти в съответните области (качество, финанси, организационни структури, бизнес процеси и др.), Които трябва да бъдат включени за извършване на тези произведения.

Информационни технологии в управлението на проекти

Тук ще подчертаем две основни направления - автоматизация на стандарта за управление на проекти и автоматизация на функциите за управление на проекти.

Автоматизация на управлението на проекти Тя може да бъде снабдена със средства за информационни технологии, като например системата за управление на документи в документалната част на стандарта или системата за управление на бизнес процесите в процедурната част на стандарта.

Стандартът за управление на проекти е на първо място, набор от документи, които обясняват или предписват, както в коя последователност, за кои времеви рамки, използващи кои шаблони трябва да изпълняват определени действия в процеса на управление на проекти. Тези документи не са свързани с един проект и формират регулаторната и методологическата подкрепа на системата за управление на проекти като цяло, а техният брой може да бъде доста голям.

По силата на това един от обещаващите подходи е организацията на стандарта като база на знанието, която предоставя всички необходими услуги за актуализиране и търсене на документи, за организиране на междусистемни връзки между документи, кръстосани препратки и др. Въпреки че примерите и другият подход са известни, когато се създава специализирана информационна среда за поддържане на стандарта (Andersen Consulting).

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

В стандарта може да бъде изрично или имплицитно положен автоматизация на функциите за управление на проекти . Ето защо разработването на стандарта е необходимо да се има предвид перспективата за създаване на супа, включително стандарт и различни средства за автоматизиране на управлението на проекти.

Към основните области на дейностите по управление на проекти да бъдат в една или друга степен, ние се отнасяме:

Всъщност управлението на проекти, което в тесен смисъл обикновено се разбира като планиране на ресурсите на календара.
Формиране и поддръжка на бюджета на проекта.
Управление на документи, както управленски, така и в резултат на това.
Управление на бизнес процесите в проекти, включително процеси на координация на документи.

Отбележете, че последните две позиции в този случай не са свързани с документи и процедури на стандарта, а до управленски и смислени документи на конкретни проекти и организиране на колективна работа с тези документи.

Автоматизацията на управлението на проекти не е тема на този доклад. Ето защо, тук ще се ограничим до изявлението, че средствата за автоматизиране на управлението на проекти трябва да бъдат свързани с други информационни системи за предприятията (например с системата за управление на персонала, с ERP системата и т.н.). И това от своя страна ще доведе до необходимостта от установяване на интерфейси между основните пакети от приложни програми, използвани за създаване на свързани елементи на интегрираната система на предприятията. . Наскоро модулите за управление на проекти все повече са част от такива приложни системи като ERP., например, модул Проект. Система. в SAP. R./3 и CRM., например, модула EVENTIX. Ангажимент. в Продажба на продажби..

Тези съображения показват, че създаването на стандарт за управление на проекти може да се разглежда като неразделна част (проект) на голяма програма за подобряване на системата за управление на предприятията. И, разбира се, изпълнението на тази програма ще изисква прилагането на методите за управление на проекти, а натрупаният опит на свой ред ще бъде отразен в стандарта.

8. Речник на управлението на проекта

Да започнем този раздел с история за забавен епизод. Веднъж, в нашата компания, бяха практикувани студенти-дипломан, които се специализират в управлението на проекти. След като им даде задача, ръководителят на практиката (един от авторите на този доклад) поиска да опише обхват Проект (каза той - обхват). "И какво е обхват? " -внимателно изяснено едно момиче. "ОТНОСНО, обхват - Това ... "- отговори на мениджъра и рисуваше с ръце във въздуха, което наподобява средния размер на земното кълбо. - Ясно е - каза тъжно момичето. - Бяхме обяснени и в Института. "

Ситуацията е много характерна и доста опасна. Има определен термин, използван в англоговорящите източници и няма очевиден и недвусмислен превод на руски в контекста на управлението на проекти. На професионален жаргон, използвахме този термин на оригиналния език. Наистина, много по-удобно е да се каже обхватот всяко достатъчно обемист "съдържание и граница". Ако някой е непонятен, винаги можете да обясните, поне с помощта на жестове. И води всичко това на факта, че известно време след точното значение на термина никой не си спомня, всеки го третира по свой собствен начин и в същото време всеки мисли, че се разбират!

Добавете към това, колкото на езика на оригинала, много термини изобщо не се интерпретират. В сравнителния речник на Макс Ваййман, базиран на по-петдесет източника, за много термини се дават с 5-6 различни определения. Руско-говорящи речници, които също се получават достатъчно голям бройВ много случаи още повече обърква ситуацията.

Сега погледнете този проблем от гледна точка на стандарта за управление на проекта. Стандартите са документи, които не трябва да позволяват различни тълкувания и които трябва да бъдат разбрани от всеки служител на предприятието. От това най-малко два заключения са от съществено значение за темата на нашия доклад. Първо, стандартът трябва да съдържа определенията на основните използвани термини и второ, нито тези термини на английски език не трябва да се прилагат (въпреки че споменаването на английския аналог определено е полезно) или тяхната транслитерация на руски език.

Авторите на стандарта на Volns да решат как ще отидат при формирането на речник - независимо дали завършените дефиниции на руски ще могат да направят свой собствен превод от английски или, ще бъдат предложени техните дефиниции, адаптирани към професионалната квалификация за околната среда и персонала на предприятието. Очевидно е едно нещо, във всеки случай, тази задача няма да бъде проста.

Като малък речник, водещ в този доклад, ние по никакъв начин не претендираме да бъдем напълно, нито за анализ или критика, включена в нея. Единствената задача е да се даде обяснение на условията, които използвахме в нашия доклад, и ги свързваме с често използваните колеги.

Кратък речник

Проект (Проект) - уникален комплекс от взаимосвързани събития предварително за постигане на целите при определени изисквания за времето, бюджета и характеристиките на очакваните резултати.

Проект - уникален процес, състоящ се от набор от взаимосвързана и наблюдавана работа с начални и крайни дати и предприети за постигане на целта за съответствие със специфични изисквания, включително срокове, разходи и ресурси [ISO].

Проект - целенасочена временна дейност, предназначена да създаде уникален продукт или услуга [NTK].

Управление на проекти (Проект.Управление) - професионални творчески дейности за ръководството на човешки и материални ресурси чрез прилагане на съвременни методи, средства и художествено управление успешно постигнат целите при определени изисквания за времето, бюджета и характеристиките на очакваните резултати от проектите, извършвани в пазарни условия в Социални системи.

Управление на проекти включва планиране, организация, наблюдение и контрол на всички аспекти на проекта по време на непрекъснатия процес на постигане на целите си [ISO].

Управление на проекти - процеса на прилагане на знания, умения, методи и средства и технологии за дейностите по проекта, за да се постигнат или надвишават очакванията на участниците в проекта [Pmbok].

План за управление на проекти (Проект. Управление План) - Фундаментален документ (базов документ), от който трябва да започне всеки проект. Съдържа документираната идея за проекта, съгласуван от всички участници. В инвестиционни проекти - Главен план на проекта (Проект. Майстор План (UE).

Харта на проекта ( Проект. Хартата) - документът, разработен от по-високата администрация, който предоставя на ръководителя на проекта, правото да използва ресурсите на организацията, за да изпълни работата на проекта [Pmbok].

Определение на проекта ( Проект. Определение. Докладвайте) - документ, определящ проект, включително: какви са целите и резултатите от проекта; Каква е нейната нужда; Какво трябва да се направи; Как кога и къде трябва да се направи; Това, което е необходимо за това; колко струва; Какво трябва да привлечете външни ресурси и организации; Какви стандарти и процедури подлежат на съответствие с проекта [NTK].

Основа (изходно ниво на проекта) - Основните параметри и тяхното определено разбиране на проекта - "точка на подкрепа" за цялото последващо развитие на проекта.

Основен план (базовата линия) - Първоначален план на проекта с одобрени промени. Основният план се случва и на компонента на проекта - разходите, графика и др. [OEU].

Област ( Обхват) – Комбинацията от продукти и услуги, чието производство трябва да бъде предоставено в рамките на проекта [Pmbok].

Цели ( Обхват) - комбинация от продукти и услуги, насрочени за производство в проекта [orp].

Ключови елементи на проекта (Проект.Етапи) - Ключови събития по проекта, което е необходимо и достатъчно състояние, определящо постигането на резултатите от проекта. Обикновено се представя под формата на схема или таблица с взаимовръзки и условия на постижение, формиране План за етапи (Крайъгълен камък.Плана, Крайъгълен камък.График, МайсторГрафик).

Контролно събитие - важно събитие на проекта, обикновено свързано с постигането на най-важните резултати от [orp].

Други възможности - ключово събитие [Ue], проверете точката [Ue].

Структура на разлагане на работата (РаботаРазбивка.Структура), sdr (WBS) - Представянето на проекта под формата на йерархична структура на произведенията, получени чрез последователно разлагане. СПТ е предназначен за подробно планиране, оценка на разходите и подкрепата на личната отговорност на изпълнителите.

Структурно разлагане на работата - йерархично структуриране на проектни работи, фокусирано върху основните резултати на проекта, определяйки нейната тематична област. Всяко подчинено ниво на структурата е детайлът на елемента на най-високото ниво на проекта. Елементът на проекта може да бъде както продукт, услуга и работен пакет или работа [NTK].

Йерархична структура на работата - структуриране на работата по проекта, отразявайки основните му резултати. Всяко от следващото ниво на йерархията отразява по-подробна дефиниция на компонентите на проекта [op].

Работна детайлна структура - йерархична структура на последователното разлагане на проекта към подпроекти, опаковки на работа на различни нива на подробни пакети [ue],

Отклонения на проекта (Проект.Изключения) - Липсва действителните и планираните резултати на проекта, причините за такива погрешни методи, методи и технологии, които позволяват да се справят с такива ситуации в проекта. Включват рискове, проблеми и промени.

Отклонение ( Отклонение) - извън границите на установените изисквания. Отклоненията включват случаи, когато резултатът от работата не отговаря на изискванията или неоснователно повече от [QMPP].

Рискове на проекта (Проект.Рискове) - Възможността за неочаквани ситуации или рискови събития в проекта, които могат да повлияят негативно или положително върху постигането на целите на проекта. Рискът от проекта се характеризира със следните фактори: източници и характеристики на събитията, които могат да имат вероятности от такива събития; Възможни щети на проекта и оценка на неговото влияние върху проекта.

Риск - потенциал, числено измерим възможността за нежелани ситуации, свързани с тях под формата на загуби, повреда, загуби [ue].

Риск по проекта в общото разбиране това е опасността от нежелани отклонения от очакваните държави в бъдеще, въз основа на които се вземат решения в това [ППО].

Проблеми с проблемите - Всеки функционален, технически или свързан с бизнеса въпрос, възникнал в процеса на изпълнение на проекта и изисква учене и решаване, за да се гарантира, че проектът може да бъде планиран.

Проблемни ситуации ( Проблем. ситуации) - произтичащи от изпълнението на ситуацията по проекта за излизане, от която е необходимо да се намери оптимални решения [NTK].

Решаване на проблеми ( Проблем. Решаване) - определението за последователни систематични процедури, с които се анализират и решават проблемни ситуации [NTK].

Промени промени (Проект.Промени) - Модификация на предварително договорените продукти и услуги, условията за изпълнение и разходите за работа, използвани ресурси, управление и технологични процеси и др.

Промяната - увеличаване или намаляване на характеристиките на елементите на проекта. Преразглеждане на основния проектен план. Това предполага документирани и одобрени промени [ue].

План за календар на проекта (Проект.График) - Списъкът на планираните проекти работи с условията за изпълнение и отговорните лица, изготвени в съответната форма, определена от плана за управление на проекта.

График на проекта - планирани дати за работа и планирани дати за начало на контролните (ключови) събития ("VEX") на проекта [NTK].

Куратор на проект (Спонсор) - лице, което е отговорно за ръководството на предприятието за успеха на проекта като цяло и има правомощия за решаване на ресурсите и други проблеми, избягал от ръководителя на проекта.

Спонсор на проекта - отделен човек или организация, за която се предприема проектът и които са по-голямата част от риска от проекти [BS2].

Ръководител проект (Проект.мениджър) - Управителят, отговарящ за успешното изпълнение на проекта, взаимодействие с клиента, подизпълнителите и разделенията на Дружеството, организиране на подготовката и предоставянето на докладване по проекта.

Ръководител проект - лице, отговорно за управлението на проекти [Pmbok].

Бюджет на проекта (Проект.бюджет) - Одобрено планирано разпространение финансови средства Проект по различни причини: при разходни статии; във времеви периоди, според участниците в проекта; решени задачи, според компонентите на очакваните резултати; Според елементите на организационната структура на проекта и др.

Бюджет на проекта - очакваната цена, разпределена от периода на изпълнение на проекта [NTK].

Заинтересовани хора (Заинтересовани страни) - Физически и юридически лица, както пряко участващи в проекта, а тези, чиито интереси могат да бъдат засегнати от процесите на изпълнение на проекта и неговите резултати.

Участници в проекта - физически и организации, които са пряко включени в проекта или чиито интереси могат да бъдат засегнати при изпълнението на проекта [Pmbok].

9. Допълнителни ползи от прилагането на стандарта.

Стандарт за управление на проекти и човешки ресурси

Понякога в него не е подробно да се инвестира. Не е възможно да се инвестира в целия обем знания, необходими за ръководителя на проекта. Да, стандартът не е предназначен за това. Стандартно определя какво и кога трябва да направите в каква форма и ком. Дайте резултат. Но като - Това не е стандартен въпрос, но професионалната компетентност на мениджъра. Отговора на въпроса като Трябва да търсите в учебници и справочници (те не са толкова много на руски, но те са).

Стандартът няма да замени тази литература, но ролята му в целевия персонал за обучение на компанията може да бъде много значим. Тук, според нас, следващият паралел ще бъде от значение. По отношение на процесите на управление на проектите, стандарт на компанията е специализиран и описват изискванията на рамковите стандарти (като ISO 10006 или PMBOK PMI). По същия начин, по отношение на квалификацията на управленския персонал, стандартът на компанията е специализиран и описва изискванията на регулаторните рамки в тази област (като ICB или NTC).

Стандартът на компанията включва раздели, свързани, на първо място, областите на зоните за управление на проекти са най-критични за това предприятие. Именно тези теми трябва да бъдат предмет на програмата за обучение на персонала. Освен това разширената програма за обучение под формата на списък на квалификационните изисквания може да бъде разрешена директно в текста на съответните дялове на стандарта. Същите тези изисквания могат да бъдат включени и в служителите за управление на длъжностите.

И, разбира се, развитието на стандарта за управление на предприятията е най-важната стъпка за специалист, който се изчислява за получаване на международно признат сертификат в управлението на проекти.

Стандарт за управление на проекти и нивото на управление на процесите на управление

Фактът, че използването на стандарта за управление на проекти показва, че компанията е достигнала определено ниво на зрялост на процесите на управление. За да измерите това ниво и да определите указанията по-нататъчно развитие Могат да се прилагат различни методи. Един от най-популярните подходи е да се използват модели на зрялост, моделът на матуритетния модел (CMM) е широко известен, използван за оценка на зрелостта на софтуера, който развива софтуер.

Такива модели съществуват в управлението на проекти. Всъщност такъв модел, макар и доста опростен, се предлага от нас в една от предишните бележки при обсъждането на стратегията и тактиката на създаването на стандарта. Този модел включва използването на три нива на зрялост, които съответстват на концепцията, методологията и стандарта за управление на оперативния проект.

Като друг пример, ние даваме модел от пет нива (PM) 2 - модел за управление на процеса на управление на проекти.

Първо (първоначално) ниво на зрялост съответства на ситуацията, когато няма официално приети процедури за управление на проекти в организацията, изпълнението на проекта не е планирано, работата на проекта е слабо определена по съдържание, обем и цена. Процесите на управление на процесите са напълно непредсказуеми и слабо контролирани. Висшето ръководство често не разбира ключовите въпроси на управлението на проекти, поради което успехът на проектите зависи повече от индивидуалните усилия, отколкото от организацията на процесите на управление на проекти. Компаниите на това ниво могат да бъдат описани като опит за спонтанно овладяване на основните процеси на управление на проекти.

Второ ниво на зрялост (ниво на индивидуално планиране на проекти) Съответства на заявлението в организирането на индивидуални неограничени и несъответстващи процедури за управление на проекти. Ръководителите на проекти, процесите на управление на проекти са частично признати и контролирани. Във всеки конкретен проект обаче планирането и управлението зависи от индивидуалния подход на нейния лидер.

Трето ниво на зрялост (контрол) Тя включва частична формализация на процесите на управление на проекти и използването на основната система за планиране и управление на проекти в организацията. Компаниите, които са достигнали това ниво, извършват систематичен и структуриран подход към планирането и контрола на проектите. Персоналът на проекта е готов да разбере и прилага инструменти и инструменти за управление на проекти.

Четвъртото ниво на зрелостта (ниво на интеграция) Тя се характеризира с пълна формализация с официалното одобрение на всички процеси на управление на проекти и документацията за цялата съответна информация. Компаниите, които са достигнали това ниво, са в състояние да планират ефективно, да управляват и наблюдават всички многобройни проекти. Процесите на управление на проекти са добре дефинирани, количествено оценени, разбрани от персонала и прилагани на практика. Данните, свързани с процесите на управление на проекти, са стандартизирани, събрани и съхранявани в базата данни, за да се осигури ефективен и обективен анализ и количествена оценка на процесите. Събраните данни се използват и за прогнозиране на нежеланите тенденции и предотвратителните нежелани ситуации, които застрашават производителността и качеството. Това позволява на компанията да създаде основа за обективно вземане на решения.

И накрая, на най-високата, пето ниво на зрялост (ниво на подобрение) Процесите на управление на процесите в компанията непрекъснато се подобряват. Предоставя се автоматично събиране на данни за управление на проекти, за да се идентифицират слаби точки в процесите. Тези данни са внимателно анализирани и количествено определени, за да се определят възможностите за по-нататъшно подобряване на процесите на управление на проекти. Това ниво приема наличността и използването на инструменти за непрекъснато подобряване на процесите на управление на проекти. Такива инструменти могат да бъдат например организационни структури, процедури и информационни технологии, които гарантират способността за одит, мониторинг и изследване на проекти.

Според нас каквато и да е модел на падежа на процесите на управление на проекти, стандартът за управление на проекти трябва да играе ключова роля в нея. По този начин постигането на третото и по-високите нива на зрялост съгласно модела (PM) 2 е просто немислим без стандарта на управление на проекти. И стандартът е официално отражение на постигнатото ниво на падежа на процесите на управление на проекти.

Стандарт и маркетинг на проекта

Стандартът за управление на проекти е вътрешна компания за документи. Въпреки това, както и всяко постижение в областта на качеството, наличността на този стандарт има значителен маркетингов ефект и засилва позицията на компанията на пазара. Нека обясним тази теза.

Много често, за да получите печеливш договор, компанията трябва да покаже какво знае как да управлява проекти и може да го направи. Всъщност, в почти всяка голяма търг за разработване на информационни системи, изискванията се съдържат непременно по отношение на управлението на проекти. Понякога тези изисквания са конкретни, например "Как ще бъдат организирани група на проекта Като се вземат предвид участието в проекта на много страни? Как ще се подкрепят отношенията с различни партньори? По-често те са формулирани в самото общ: "Предоставете информация за процесите на управление на фирмата, които позволяват да проследява и наблюдава всички аспекти, свързани с проекта, включително ...".

От първо място отбелязваме, че отговорите на огромното мнозинство от тези въпроси завършен видео Съдържащи се (трябва да се съдържат) в стандарта за управление на проекта, който само по себе си значително опростява и намалява процеса на подготовка на тръжни предложения. И освен това отговорите по отношение на собствения си стандартен поглед в очите на клиента много по-привлекателни от вариациите на темата на PMBOK, както се показва, че във вашата компания опитът за управление на проекти (а) е (б) систематизиран и в) е систематизирано, което се използва масово.

Ако считаме, че приносът, даден на общата оценка на тръжните предложения за изискванията за управление на проекти, понякога достига петдесет процента, ефективността на стандарта за управление на проекта като маркетингов инструмент става доста очевиден.

10. Литература:

1 Микхеев V.N., TOVB А.С. Международни и национални стандарти за управление на проекти, управление на проекти и ръководители на професионални компетенции. В събота Труд на втората руска практическа конференция "Стандарти в проектите на съвременни информационни системи", М., 2002. - стр.33-37.

2 TOVB А.С. CIPES G.L. Метод и опит в създаването на ИТ програма за управление на проекти. В събота Работи на втората руска практическа конференция "Стандарти в проектите на съвременни информационни системи", М., 2002. - стр.42-47.

3 TOVB А.С. CIPES G.L. Бележки за управление на проекти. Стандартно управление на проекти за ниво на предприятията. "Директор на информационната служба" № 1-6, 2001 и Nos. 1-6, 2002.

4 "Директор на информационно обслужване" № 5, 2001.

5 C. William IBBS, млад хюн Kwak. Ползите от управлението на проекти: финансови и организационни награди на корпорации. - Фондация за обучение по управление на проекти, 1997

11. Източници, за които са цитирани дефинициите: \\ t

Британски стандарти 6079-2: 2000 Управление на проекти Част 2 Речник. (auth.).

ISO / TR 10006: 1997 (e). Управление на качеството - насоки за качество в управлението на проекти (използван от G G. Gerasimova).

Wideman сравнителен речник на Условията за управление на проекти. Pmforum, 2000 (www.maxwideman.com).

Ръководство за органа за управление на проектите на знанието. PMI Стандарти Комитет.1996 издание (използван от М. Грачина).

Управление на качеството за проекти и програми, Lew Ireland, Институт за управление на проекти, Площад Нютаун, ПА, 1991. (цитиран от, превод на автор.)

[NTK] Основи на професионалните знания и националните изисквания за компетентността на специалистите по управление на проекти. Ед. В и. Voropheyeva, 2001.

[Orp] Основи за управление на проекти. В и. Либесън.

[Ue] управление на проекти. Директория за професионалисти. Ед. I.i. Mazura и V.D. Shapiro, 2001.

[UPP] Управление и проекти на програмата. 17-Модулна програма за мениджърите "Управление на организацията развитие". Модул 8. M.L. Веднъж, v.i. Воропаев и др., 1999. Връзки

За разлика от PM BOK PMI в методологията на МИТР (PMM), терминът цели за проекта означава задачите на проекта, решението на което, т.е. Постигането на съответните вноски може да бъде оценено чрез количествени критерии.

Например, в различни материали, базирани на методологии на IBM MITP, рисковете за проектиране не винаги са включени в отклоненията.

Управлението на стандартите на компаниите по отношение на методологията обикновено има основа, определена от общите документи, които се наричат \u200b\u200bрамка. Тези документи включват органа за управление на проекта на знанието на Американския институт за управление на проекти, признат от много международни де факто стандарти и стандарта 1B 10006: 1997, смисълът и съдържанието, което се състои в тяхното значение специализация и подробности.

Специализация - включване в стандарта на дружеството за тези разпоредби, свързани с дейностите по проекта. В същото време стандартът на дружеството трябва да съдържа описание и класификация на фирмени проекти. Организационни структури и персонал на проекта Също така са предмет на специализация. В стандарта на компанията стандартните дизайнерски роли не могат да бъдат записани, но също така и да се определи структурата и принципите на формиране на органите за управление на проекти. За всички постоянни единици, по един или друг начин, свързани с изпълнението на проектите, следва да бъдат идентифицирани принципите на тяхното участие в проекти - видовете работа, процедурата за разпределяне и изземване на персонал, форми и размери на полученото възнаграждение. Предмет на специализация е и процеси на управление на проекти. Общият набор от възможни процеси ще бъде подаден под формата на триизмерно пространство, показано на фиг. 4.23. Според координатните оси, тези измерения, посочени в рамковите стандарти, са отложени; Други, като контролни нива, могат да се предлагат календарни периоди. Всяка точка от това пространство е елементарен процес на управление, например, "планиране на риска в етапа на изпълнение на системата".

Избраните елементарни процеси образуват процедури за управление на проекти, които могат да бъдат изградени върху аксиален принцип (тук се дължи на абсцисата, ордината и приложението, посочено на фиг. 4.23). Описанието на тези процедури е основният обем на стандарта, т.е. Според стандарта на компанията той се разбира като набор от документи, предписани както в коя последователност, по коя време, използващи кои шаблони трябва да се извършват в процеса на управление на проекти.

Броят на тези документи зависи от степента на стандартни детайли и може да бъде доста голяма. Предмет на описанието в стандарта може също да бъде типични ситуации, характерни за проектите на компанията и препоръки за отговор на тези ситуации, т.е. Вкръбни решения таблици, нещо като списък с възможни грешки и препоръки за тяхното премахване.

Класификация на проектите като първи етап от създаването на стандарт

Ключовият момент в създаването на стандарта за управление на проекти е да се разбере какви проекти се извършват в компанията, какви са техните различия, което е между тях. Тези въпроси са свързани с практиките за управление на проекти и са отразени в стандарта на компанията.

Документ, от който трябва да започне всеки проект, е план за управление на проекти, който определя методите за управление на проекти, препоръчани в компанията за този вид проекти.

Етапи на жизнения цикъл на проекта

Време, повишено внимание | Рискове Fedsonal комуникационни договори промени промени

Й. Функции за контрол

Аз si іа §

Инициализация) Планиране на контрол на ефективността

Фази на контрола

Фиг. 4.23.Процеси на космически контрол

Източник: TOVB А.С. CIPES G.L. Стандартно управление на проекти на предприятието // Директор на информационната служба. 2002. № 1-6.

Планът за управление на проекти отразява:

Съдържанието и границите на проекта са целите и целите на проекта, основните резултати, критериите за оценка на факта, че работата или частта е завършена;
Ключовите етапи на проекта са основните събития на проекта и плана за тяхното постигане, евентуално използване на структурата на разграждането на работата;
Планиран бюджетен проект;
Предположения и ограничения - предпоставки, въз основа на които оценяват времето за изпълнение, сложност и цена на работата по проекта, включително описанието на първоначалните рискове;
Изисквания и стандарти - списък на регулаторните и регулаторни документи или техните индивидуални разпоредби, които следва да се спазват по време на работата на проекта;
Подходи за изпълнението на проекта - понятието за предполагаемото решение (няколко алтернативни възможности), методи за развитие и основни информационни технологии;
Организационната структура е отговорност и процедура за взаимодействие на участниците, имената и задълженията на ключовите фигури на проекта;
Управление на документацията на проекта - структура, среда за съхранение и процедура за създаване и поддържане на хранилището на документите по проекта, списък на шаблоните за документи;
Управление на отклонение - рискови процедури, с възникващи проблеми и промени във формите на съответните документи на проекта;
Осигуряване на качеството - списък и наредби за провеждане на дейности, насочени към предоставяне на качество като резултати от проекта (продукт) и процесите на управление на проекти и управлението на работата;
Контролът и докладването е регламентите за провеждане на мерки за анализ на състоянието на проекта, съответстващ на формулярите за докладване. Предимствата на типичните шаблони са очевидни - спестявания на консултанти, унифициране на подходите, намаляване на времето за изготвяне на проектна документация. Въпреки това, създаването на шаблони е доста трудоемко, тяхното присъствие ще се бори с инициативата и независимостта на ръководителя на проекта. За определяне нужда от количество Шаблони за план за управление на проекти е необходимо да се изгради класификация на проектите, извършвани в компанията.

Класификация за тема и продукти в тези области Позволява специализираните раздели: "Съдържание и граница", "ключови етапи", "изисквания и стандарти". Тази класификация може да бъде изградена на йерархичен принцип, например информационни технологии - проекти за системна интеграция - създаването на интегрирани системи за управление на проекти.

Класификация на скалагирането на проекта Позволява специализираните участъци: "организационна структура", "управление на отклонение", "система за качество". За да се изгради тази класификация, могат да се използват различни бази - териториална дисперсия или разходи за проекти.

Класификация под формата на плащане и отчитане на работата Позволява ви да се специализирате: "Контрол и отчитане", "Управление на документацията на проекта" въз основа на такива форми на договори като "време и материали" и "фиксирана цена". Така тя може да бъде обсъдена например за плана за управление на проекта за създаване на концепция (продукт) на информационната система (област) на стойност над 100 хиляди долара, (скала) с договор във формата и формата на материалите (Платежна форма и счетоводни работи) ", като макроскреин, получен чрез просто сглобяване на няколко по-малки (микро) шаблона на отделни дялове на плана.

Класификация на сложни проекти (сложност). В съответствие с тази класификация, проектите се разделят на обикновени бизнес проекти, стандартни проекти за интеграция и сложни проекти на системна интеграция. Освен това, тази класификация определя за структурата и съдържанието на плана за управление на проекти. В този случай, други класификации запазват стойността си, за да образуват отделни дялове на плана.

План за управление на проекти, съдържащ документирана представа за проекта, съответстващ на всички участници, е основен документ, точка за подкрепа за цялото последващо развитие на проекта (Таблица 4.18).

Таблица 4.18.

Специализирано съдържание на микросалон "и граници на проекта за създаване на ИТ инфраструктура на клон на банката"

Параграф микро	клон на банката
Обосновка на проекта (обосновка на проекта)	Описва основните характеристики на продукта и тяхната връзка на S. бизнес необходимост или други стимул	Всички клонове трябва да имат единна, надеждна, гъвкава и лесно повишаване на ИТ инфраструктурата, базирана на платформа, което позволява да се използва софтуер за приложения като основно средство за обработка на бизнес транзакции.
Продукт на проекта (продукт на проекта)	Основни характеристики на продукта и връзката им с необходимостта на бизнеса	Доставка, инсталиране и конфигуриране на софтуер за оборудване и системен софтуер в новосъздадения клон на банката, който формира основата за последващото прилагане на банковата информационна система
Резултати от проекта (резултати на проекта)	Списък с резултати (субпор), постигайки (пълно и успешно създаване) на което означава завършване на проекта	Спецификации на системния софтуер и нейната конфигурация. Изисквания за помещението за инсталиране на оборудване. Списък на оборудването и софтуера. План за техническо решение. Референтни копия на инсталацията и конфигурацията на системния софтуер. Оборудване и системен софтуер, доставени в банков клон, създаден и подготвен за инсталиране на банкова информационна система
Критерии за оценка на резултатите (цели на проекта) 1	Описание на количествените критерии, които трябва да бъдат изпълнени за проекта, за да се счита за успешен	Времето за доставка на оборудване и софтуер в Москва не трябва да надвишава XX дни. Отклоните на оборудването и софтуерът в Москва не трябва да надвишават дните на UU. Крайният срок за транспортиране на оборудване и софтуер в клон на Банката не трябва да надвишава Комерсант дни. Инсталацията и настройката на оборудването и софтуера в клона не трябва да надвишава дните на UU

Сравняване на съдържанието на проекта "Продукт на проекта" и "Резултати от резултатите", може да се отбележи, че резултатите от проекта са елементи на декомпозицията на продукта на проекта. Ето защо при формирането на план често се използва структура на разлагане на работата (WBS - структура за разбивка на работата) и много водещи компании включват в собствените си методологии и стандартни стандарти за WBS и двете изрично (Andersen Consulting) и имплицитно (IWM).

Структура на разлагане на работата

В етапа на инициализиране на проекта ръководителят на проекта трябва да отговори на редица въпроси: какво да прави (идентифициране на продуктите на проекта); Как да направите това (определете технологичните етапи на проекта); Кой ще направи това (идентифициране на изпълнители, конети, подизпълнители); Кой и в каква форма ще плащат за работа (определят какви договори ще бъдат сключени).

Например, ако проектните работи се извършват в интерес на различни клиенти и се финансират от различни инвеститори (фиг. 4.24), разлагането може да се извърши или със значителен знак за работа по проекти, или според официалния знак на класифициране на споразумения за финансиране.

Функционален

клиент

	Проект Р1.	Проект P2.	Проект PZ.

Инвеститор

Договор D1.

Изпълнители

---- декомпозиция на значителен знак
-Expoose официален знак (финансови потоци)

Фиг. 4.24.Разлагане на произведения по различни причини Източник:

Друг случай е фиксиращ в структурата на работата на подизпълнителите. След това, за етапа на плана на календара на проекта, има официално разпределени групи от строителни работи, извършвани от главния изпълнител (изпълнител) и други изпълнители (подизпълнители). Това разлагане е препоръчително да се прилага, ако са фиксирани големи логически взаимосвързани блокове на работа зад подизпълнителите, относително независими проекти от други произведения.

Ето защо, първото нещо, което трябва да бъде отразено в специализирания шаблон на WBS, е какви алтернативни мнения за структурата на разграждането на работата следва да бъдат подкрепени в проекта. Ако се изисква разлагане за няколко различни бази, трябва да се посочи основното нещо. За да се подкрепят други възгледи, следва да се определят подходящи класификационни функции, описани като характеристики на подробна работа. Като такива знаци, кода на проекта, кода на договора, кода на подизпълнителя.

План за управление на проекти и рамкови стандарти

В повечето случаи рамковият стандарт предоставя само концептуалния апарат и общите методологически принципи. Въз основа на рамковата методология следва да се създаде корпоративната методология, в която основните разпоредби, изисквания, принципи и практики на управление на проекти са определени и систематизирани във връзка с управлението на проекти в това дружество, основано на анализа на специфичните особености на извършените проекти.

Тази корпоративна методология и специализирани шаблони за документи са в основата на стандарта за управление на проекта на компанията. И процесът на създаване на стандарта прилича на спирала, на всеки нов обрат, от които техниките стават все по-специализирани, а шаблоните все повече подробни са.

Отклонения на проекта. Рискове, проблеми, промени

Планиране на проекта, ние приемаме, че не всичко ще се окаже точно както е планирано. Възникващите несъзрения на първоначалното съгласувано и записано представяне на проекта и това, което се получава в действителност и се наричат \u200b\u200bотклонения. В същото време, другият термин - "изключения" се приема в английската литература, което означава не само неразбираемостта на действителните и планираните резултати, но и причините за тези несъответствия, както и методи и технологии, които го правят възможно да се справят с такива ситуации с минимални загуби. Това е по-широкото тълкуване, което ще има предвид в бъдеще, като говорим за отклонения. Традиционните области на управленските проекти, свързани с отклоненията, включват рискове, проблеми и промени.

Сценарии за управление на отклонение. Управлението на отклонението се свежда главно до борбата срещу неприятностите, които като цяло могат да включват три етапа:

1) управление на рисковете. Проблемите все още не са дошли, но е възможно да се появят с нежелани и непланирани събития, които могат да доведат до факта, че целите на проекта няма да бъдат постигнати. Целта на този етап - предотвратяване на проблеми преди тяхното възникване;
2) управление на проблемите. Дошли са проблемите и е необходимо да се открие техният произход, степента на влияние върху проекта, методите за преодоляване. Целта на този етап е предоставят възможност на проекта да отиде както е планирано;
3) управление на промените. Проблемите бяха сериозни и не беше възможно да се справят с тях, без да се засяга проекта. Целта на този етап(Фактът, че финансистите се наричат \u200b\u200b"загуби за запис") - модификация на предварително договорените продукти и услуги, условията за изпълнение и разходите за работа, управление и технологични процеси.

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

Фиг. 4.25.

Източник: TOVB А.С. CIPES G.L. Постановление. ОП.

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

От особен интерес от гледна точка на анализа на отклоненията представляват четвърти и пети сценарии, съответстващи на случаите на възникване на проблеми, които не са посочени като рискове. Причината за това може да бъде, например, атипичната ситуация или просто "загуба" на риска в резултат на липса на квалификация. Резултатът от анализа на причините и тежестта на последствията може да бъде решението, че за някои категории проекти проекти изобщо не е препоръчително да се ангажират дълбоко в управлението на риска и е достатъчно просто да се решат проблеми, както се случват. Докато за други категории на проекта, напротив, е необходимо да се укрепи рязко работата с рискове.

Управление на рисковете. Най-простите и в същото време, които трябва да бъдат отразени в стандарта - формалната страна на управлението на риска, а именно:

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

От различни методи за управление на риска за стандарта трябва да бъдат избрани тези от тях, които са адекватни на проекти, в които те ще бъдат приложени (разходите за процедурите за управление на изпълнението). Така, когато анализира рисковете, може да бъде разрешено съзнателно намаляване на оценките за някои специфични категории проекти, например за проектите с ниска цена или сложност. По този начин, в таблица 4.19, степента на заплаха за риска, изчислена чрез вероятността от настъпването на рисковото събитие и неговото влияние върху хода на проекта се използва като обща оценка на риска.

Таблица 4.19.

Заплаха за риска от матрица

^ "" - "---- ^ вероятността на събитие Въздействие върху проекта	Ниско (по-малко от 20%)	Средно (от 20 до 60%)	Високо (повече от 60%)
Нисък.Възможно е да се появяват въпроси или проблеми в проекта, но е малко вероятно да доведе до нарушение на графика на календара, бюджета или влошаването на качеството на продукта
Средно аритметично.Може би нарушение на графика, увеличаване на разходите или влошаването на качеството на продукта
Силен.Може би значително нарушение на графика, увеличаване на разходите или влошаването на качеството на продукта

Източник". TOVB А.С. CIPES G.L. Постановление. ОП.

"Цената на разделението" както на помощната (вероятност и влияние) и по главния мащаб (степента на заплаха) трябва да се определят от практически съображения - е точност и дали може да се използва. Какви сценарии ще развият увреждания в проекта, до голяма степен се определя от приетите работни стратегии с рискове. Можете да направите всичко, за да избегнете риск, а след това най-вероятно е вторият сценарий. Възможно е, напротив, да поеме риск и да не го противопоставят, позволявайки развитието на събития в първия или в третия сценарий. Можете също така да намалите риска, а след това с благоприятно развитие на събитията, най-желаният сценарий се изпълнява, когато рисковото събитие не се случи.

Управление на проблемите. Проектът се разбира като всеки функционален, технически или свързан с бизнеса въпрос, който се появява в процеса на проекти и изисква обучение и решения за реакция и решения, за да се гарантира, че проектът може да бъде планиран. С други думи, проблемът е изключителните обстоятелства, които трябва да бъдат контролирани от момента на тяхното възникване. Обикновено проблемите се разделят на две категории: 1) Проблеми, които могат да бъдат решени на мястото на възникване, т.е. на ниво управление на проекта (проблеми); 2) Саматни проблеми (въпроси), които за тяхното разрешение, необходими за повишаване на високите контролни нива, включително външни за проекта.

Стандартът трябва да отразява формалната страна на управлението на проблемите (процедури, регулиращи основните етапи на работа с проблеми: идентифициране на проблем, наблюдение и анализ на проблема, вземане на решения и нейното изпълнение, затваряне на проблема. Шаблони на документи, отразяващи процеса на работа С проблеми - проблеми с проекта, проблеми с проекта "Списание". Да се \u200b\u200bанализират проблемите, могат да се разработят специални решения, например, за да се определи такъв характерен проблем, като приоритет на неговото решение, приоритетната матрица може да се използва в таблица. 4.20.

Включването на процеса на управление на управлението в стандарта за управление на проекта трябва да се има предвид, че въпреки че управлението на проблемите се изисква за всички проекти, степента на използване на официалните процедури трябва да отговаря на спецификата на проекта, нейната мащаба и. \\ T сложност. За малките проекти разходите от пълното използване на този процес могат да бъдат прекомерни.

Управление на промените. Промяната в проекта е модификация на предварително договорените продукти и услуги, условията за изпълнение и разходите за работа, управление и технологични процеси. Като традиционни мерки за промяна на използваните ресурси

Matrix приоритети решаване на проблеми

Таблица 4.20.

Спешност Въздействие върху проекта	Не-ужас	Преди всичко редки	Спешен случай
Нисък.Малко вероятно е да доведе до нарушение на календарния план, бюджет или влошаване на качеството на продукта	Несейн
Средно аритметично.Може би нарушаване на плана на календара, увеличаване на стойността или влошаването на качеството на продукта
Силен.Може би значително нарушение на календарния план, увеличаване на разходите или влошаването на качеството на продукта		Особено важно
Особено важни проблеми изисква незабавно решение с участието на всички необходими ресурси. Важни проблеми изискват спешно решение с участието на всички налични ресурси. Малки проблеми Изисква решения в рамките на наличните ресурси, без да се засяга останалата част от проекта. Значителни проблеми - Не се предприемат действия, преди да се промени приоритет.

Източник

проектът се прилага, например, увеличаване на интензивността на работата, материални стимули, подмяна или привличане на допълнителни изпълнители и подизпълнители. Ако е възможно да се маневрират термини, тогава можем да говорим за промяна на времето за завършване на индивидуалните произведения, изместването на крайъгълния камък в рамките на проекта или дори увеличаване на цялостното приключване на проекта. И накрая, в някои случаи трябва да прибягвате до най-малко желаните мерки, свързани с намаляване на изискванията за качествени характеристики, замяна и дори изключение на продукта. От гледна точка на тежестта на последствията промените могат да бъдат класифицирани, например, както и планираните загуби.

За всеки проект, първоначално ще се определи степента на влияние на някои промени в големината на вероятните загуби, произтичащи от прилагането на тези промени. На фиг. 4.26 Тази информация е представена под формата на диаграма, в която промените са свързани със загубите. Разбира се, видовете възможни промени и тяхното местоположение по региони са собственост на конкретни проекти или по-скоро видове проекти. Ето защо, такива диаграми могат да бъдат включени в стандарта на компанията като характеристика на проектите на проекта, определени в класификациите на проекта.

Ограниченията за промени в ресурса, времето, продуктите могат да бъдат твърди до различни степени и в зависимост от това съществуват доста характерни ситуации в проекти, които също могат да бъдат описани предварително. Разгледайте някои такива ситуации. Често стратегията за промяна се определя от факта, че според една от осите промяната не трябва да води до излизане от площта на планираните загуби. И това означава необходимостта да се измести в едно или веднага в две други измерения.

Площ неприемлива загуба

Ресурси

Продукти

Фиг. 4.26. Области на загуба Източник: TOVB А., Ципси, Указ. ОП.

Така че, ако е известно, че клиентът е фокусиран върху спазването на планираното ниво на качество на продукта, трябва да се осигурят опции за промени, свързани с манипулацията и времето на ресурсите (стратегия "упорита клиент"). В други случаи могат да се изискват други стратегии, например "сурово време" или "ограничен бюджет", когато промените в времето и ресурсите и ресурсите следва да бъдат записани в областта на насрочените загуби. Желаните и възможни алтернативни промени стратегии (фиг. 4.27) могат да бъдат показани в диаграмата.

Фиг. 4.27.

Източник: TOVB A., Tsips. Указ. ОП.

Сега, за да може да се сравни алтернативните варианти не само качествено, но и количествено, тя остава само за разработване на показатели за всяка от осите. И тогава стратегията може да бъде оценена, например, с площ от подходящия триъгълник. Също така отбелязваме, че работата с промени в стратегическото ниво трябва задължително да бъде подкрепена от официални процедури, описващи основните промени в процесите на управление на промените: проектиране и регистрация на заявления за промени, разглеждане и одобряване на заявленията, прилагането на промените. Освен това трябва да се наблюдават промени, което осигурява контрол върху тяхното прилагане.

Организационни структури в проекти

За изпълнение на проекта се формират специални временни организационни структури, наречени проектни екипи, включително представители на различни звена. За да създадете и управлявате екипа на проекта, се използват определени методи, които гарантират ефективността на тези процеси. Методите не са универсални и трябва да вземат предвид спецификата на компанията - от организационната структура до произведения продукт. Сред първите проблеми, които възникват при формирането на организационните структури на проекта и които трябва да бъдат решени на нивото на стандарта за управление на проекти, отбелязваме проблема, свързани с кръстовищата на административното управление и функциите за управление на проекти.

Началник отдел и ръководител на проекта. Административното управление в компанията се осъществява чрез системата за управление, чийто ключова връзка е средно мениджъри. Управлението на проектите включва изпълнението на всички търговски дейности под формата на проекти и получаване на печалби чрез изпълнение на тези проекти. Съответно, значението на ръководителя на проекта е да "купи" необходимите ресурси от ръководителите на единици и с тяхната помощ за изпълнение на проекта.

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

В същото време, редица задължения възникват както от ръководителя на отделите по отношение на проектите и от страна на ръководителите на проекти към ресурсните звена, които трябва да бъдат определени в съответните разпоредби и длъжностни характеристики, а специалните случаи могат да бъдат описани в допълнение към плановете за управление на проекти. Таблица 4.21 показва примери, илюстриращи разликите в зони, където административното и управление на проекти имат точки за контакт.

Екип на проекта.При формирането на организационни структури на проекти трябва да се спазват два основни принципа: 1) разделение на нивата на отговорността; 2) Разделяне на областите на отговорност. В този смисъл решението е пряко свързано със сложността и сложността на проектите. За прости проекти обикновено са достатъчно две нива на управление. Ръководителят на проекта извършва оперативно управление на проекта, осигурява изпълнението на планираната работа, подготвя предложения за промени в плановете, координира техническите и човешките ресурси. Правомощия за промяна на времето, бюджета, съдържанието и границите на проекта се отнасят до горното ниво на управление и принадлежат към най-високия лидер. Тази схема може да се развие както надолу (мениджъри по подпроекти) и нагоре (управление на пътувания с многопроекти или програми).

Таблица 4.21. \\ t

Решение за отговорност в административното управление

и управление на проекти

Обхват на отговора Регион офис	Отговорност на началника на дивизията (административно управление)	Отговорност на ръководителя на проекта (управление на проекти)
Планиране и контрол	Формиране на бизнес план. Планиращ бюджетен отдел. Контрол "на етапите". Докладване преди управлението на предприятието	Подробен график на проекта. Планиране на бюджета на проекта. Оперативен контрол на проекта. Докладване преди ръководството
Човек	Приемане и уволнение. Централизирано разпределение на ресурсите. Контрол на дисциплината. Организация на обучението	Формиране на екипа на проекта. Анализ и оценка на служителите. Прилагане на санкции и промоции. Регламент за конфликт
Продукти за рамки (при примера на IP информационни системи)	Методология за създаване на IP.	Дизайн IP. IP развитие Е.

Източник: TOVB A., Tsips. Указ. ОП.

По този начин важен елемент от стандарта е описание на типичните организационни структури за различни видове проекти, например в съответствие с класификацията и шаблоните на инструкциите на персонала на проекта на ниво роля на проекта. Освен това, предмет на описанието в стандарта може да бъде най-различните аспекти на екипа по проекта - от процесите на нейното формиране и прекратяване на споменатите по-горе счетоводни и отчетни процедури. Очевидно е, че тези процеси и процедури не могат да бъдат затворени в рамките на проекта и трябва да засегнат по-общия контекст на корпоративните отношения. На фиг. 4.28 показва схема за формиране на екип по проекта и неговото взаимодействие със свързани услуги, характерни за компанията - системен интегратор.

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

Фиг. 4.28.Схема за формиране на екипа на проекта Източник: TOVB A., Tsips. Указ. ОП.

Услуга за осигуряване на качеството и управление на проекти.Най-правилният подход за трансформиране на стандарта за управление на проекти към работния инструмент е включването му в една система за управление на качеството на системата. Обмислете някои точки, свързани с този подход.

Планиране и контрол на качеството в проекта Тя се осъществява, за да се изберат тези разпоредби на стандартите и стандартите, които са препоръчителни и евентуално прилагани към този конкретен проект, както и събития и работа, необходими за гарантиране на изискванията на тези стандарти по отношение на качеството на резултатите и процесите на проекта .

Планирането на качеството се извършва като част от процеса на планиране на проекта като цяло. Резултатите от планирането на качеството на проекта трябва да бъдат отразени в плана за управление на проекти. План за качеството на проекта определя как ще бъде предоставен проектът с необходимото качество на работата от гледна точка на организационната структура, ресурсите, методологическата и инструменталната подкрепа. На етапа на планиране на качеството могат да бъдат създадени и документи, регламентиращи мерките за контрол на качеството, за да се контролира управлението на проекта, като например плана за одит на проекта, формата на мониторинга и управленското докладване на въпросника. Изпълнението на проекта трябва да бъде систематично да се прилага под формата на различни събития, като одит, мониторинг и изследване.

Primint Project - Това е проверката на съответствието на формализираните организационни дейности за изпълнение на приетите проекти за управление на проекти. Важно е да се отбележи, че предметът на одита на проекта не е технически решения и съдържанието на техническата документация на проекта.

Мониторинг на проекта - Редовно изпълнява оценката на състоянието на проекта, като се вземат предвид различните видове дейности в рамките на проекта. Целта на мониторинга е да предостави управлението на оперативната обобщавана информация за изпълнението на проекта, достатъчна за приемане на ключови решения по проекта.

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

Комуникации Управление на риска Съдържание и управление на границите Планиране на качеството Управление на качеството Финансов и договор Управление на ресурсите Управление на ресурсите Изменения в интегралната оценка на проекта 7

Фиг. 4.29.Диаграма на текущия статус на управление на проекти Източник: TOVB A., Tsips. Указ. ОП.

Проект за изследване - подробен анализ на някои области на дейност в рамките на проекта и изготвяне на обща картина на проекта с цел подобряване на качеството на прилагането на този проект и проекти на компанията като цяло.

Съгласно резултатите от разглеждането се подготвя заключение, съдържащо анализ на причините, както и препоръки за организационни решения и мерки или за преодоляване на неблагоприятното развитие на този проект, или - в случай на успешно развитие на. \\ T Проект - за систематизиране и възпроизвеждане на положителен опит.

Качеството на услугите за управление на качеството и услугите за управление на проекти в организационната структура и техните функции са показани на фиг. 4.30.

Служба за управление на качеството По отношение на управлението на проекти предвижда:

Интегриране на стандарта за управление на проекти в общата система на фирмените стандарти;
Контрол на качеството на управлението на проекта под формата на одити, за да се провери спазването на стандартите за управление на корпоративните проекти.

Ако такава услуга в компанията съществува в началото на създаването на стандарта за управление на проекти, неговото развитие следва да се основава на основните основни документи на системата за качество. Важно място в работата на службата за управление на проекти следва да заема разработването на методологията за управление на проекти, включително прякото участие на своите служители в проектите на дружеството като управленски персонал; Техническа и информационна подкрепа на проекти, използващи инструменти за автоматизация.

Фиг. 4.30.

изпълнение на проекта

В армията има поговорка: "Макар и грозно, но монотонен".

Защо се нуждаете от монотонност или стандарт?

Опростяване на разбирането в взаимодействието.

Хората мислят стандарт по-лесен за намиране на общо разбиране помежду си. Стандартите съчетават нации и народи. Например, европейците в езиковия и културния план ще бъдат трудни за разбиране на индусите, но някои математически термини и формули ще разберат перфектно. По същия начин английският език, който сега е стандартът на взаимодействие, помага на хората различни страни общуват помежду си.

По същия начин стандартите в управлението на проекти, помагат на ръководителите на проекти от цял \u200b\u200bсвят да се разбират

Най-добрите практики.

Има хора, които са добре запознати с някаква тема, например, продават добре. Такива хора обикновено са малцинство. Ако тези хора научат уменията си на хора, които продават по-лошо, тогава добрите мениджъри по продажбите в света ще станат повече.

С помощта на стандарти, можем да прехвърлим най-добрите практики за управление на проекти между хората. Например, компанията Dupont е създала метод за критична пътека. Този метод стана стандарти в управлението на проекти и започнаха да се радват наоколо.

Систематизиране на знанията.

Когато стандартът е създаден, тогава всички знания, налични по това време, са систематизирани. В резултат на това това позволява на хората да използват стандарта за бързо намиране на желаните знания за управление на знанията.

Сега ще се запознаем с основните стандарти, съществуващи стандарти в управлението на проекти.

ISO 21500 - ръководство за управление на проекти, разработено от международната общност на проекта през 2012 г.

Gost R 54869-2011 - Руски стандарт за управление на проекти. 1 септември 2012 г. е поръчан. Стандартът отразява основните етапи на работа с проекти.

Pmbok - разработен от PMI (най-голямата сдружение с нестопанска цел в света на професионалните ръководители на проекта) Кодекс на правилата и законопроекти. Използва се в повечето страни по света.

C-pmbok - китайска версия на pmbok.

P2M - Японски стандарт, който първо се фокусира върху управлението на програмата (за това, което е програма, можете да прочетете в статията "Условия за управление на проекти." Целта на този стандарт е прилагането на сложни иновативни идеи и интеграция , Тези идеи с предприятието.

M-Modell - Разработено от Германия и САЩ през 1979 г., стандартът, който се използва предимно за създаване на софтуер.

ICB (Международна изходна линия) IPMA е стандарт, съчетаващ няколко европейски стандарти. Този стандарт включва 28 основни области на знанието в управлението на проекти и 14 допълнителни. Добре описва компетентността на мениджърите на проекти. Използва се в Европейския съюз, Индия, Украйна, Казахстан, Азербайджан.

Хермес е швейцарски стандарт за управление на проекти, използван главно в него.

Prince2 - първоначално разработен като метод за провеждане на ИТ проекти, но скоро стана универсален.

APMBOK е националният стандарт на Великобритания, обхващащ 52 необходими проекта.

Тъй като статията е била повече информация от обучението, тогава няма да дам никакви задачи, след като го прочета.

Изпратете добрата си работа в базата знания е проста. Използвайте формата по-долу

Студентите, завършилите студенти, млади учени, които използват базата на знанието в обучението и работата ви, ще ви бъдат много благодарни.

Публикувано на http://www.allbest.ru/

Министерство на образованието и науката на Руската федерация

Държавен бюджет образователна институция Висше професионално образование

"Челябинск държавен университет"

ДА СЕурсова Работа

" Стандарти за управление на проекти"

Въведение
1. Общи съображения за създаване на стандарт. Специализация и детайл
2. Класификация на проектите като първи етап от създаването на стандарт
2.1 Какво трябва да бъде отразено в плана за управление на проекта
2.2 План за управление на проекти и рамкови стандарти
3. отклонения на проекта. Рискове, проблеми, промени
3.1 Управление на риска
3.2 Управление на проблемите
3.3 Управление на промените
4. Организационни структури в проекти
5. Тактика и стратегия за прилагане на стандарт за управление на проекти
6. Допълнителни ползи от прилагането на стандарта
Заключение
Библиография

Въведение

На пръв поглед концепцията за проекта и стандарта може да изглежда трудно за съвместима. В края на краищата, често е дори в дефиницията на проекта да включва думи за уникалност, не-реформируемост на целите, условията за изпълнение, резултатите от проекта. Тъй като наистина е така, в този случай можете да стандартизирате в управлението на проекти? И ако можете, дали имате нужда? Няма ли да се намесва само с инициативата, да наложи не оптимални, а след това просто неправилни решения? Ако психологическите аспекти на ръководството и изкуството на изграждането на междуличностни отношения в проекта са приоритет за западните мениджъри, техните вътрешни колеги предпочитат процедурен подход. Това наистина е така (поне по отношение на руските мениджъри) и означава, че работата в определени ограничения и стандарти не е само позната на нашите мениджъри (нека си припомним поне съветските герои), но също така доста удобно. И какво тогава говори за управлението на компанията, за което присъствието и изпълнението на тези стандарти означава гарантирано ниво на качество на проектите?

Също така сравнявам резултатите от всички руски конференции "Стандарти в проектите на съвременните информационни системи", където темата за стандартите за управление на проекти бе представена доста широко и предизвика оживен интерес и дискусия, както в заседателната зала, така и в местността. В решенията на конференцията това е "признаване на ролята на стандартите в организирането на изпълнението на отделни проекти и при проектирането на проекта като цяло в предприятията". И накрая, споменаването, че практиката за създаване на собствени методи и ръководства за управление на проекти е широко разпространена в най-големите западни компании, като Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и др. Позволете ни, че се приема, че темата за стандарта за управление на проекти трябва да причини лихва.

1. Общи съображения за създаване на стандарт. Специализация и детайл

Стандартите за управление на проекти на предприятието по отношение на методологията обикновено имат основа, определена от документи с доста общ характер (понякога тези документи се наричат \u200b\u200b"рамка"). Такива документи се отнасят до управителния орган на проекта (PMBOK) на Американския институт за управление на проекти (PMI), признат от много международен стандарт за деколта и стандарта ISO 10006: 1997, който даде редица най-важни разпоредби на PMBOK Standard de Юра. Значението и съдържанието на прехода от рамковите стандарти (какво е PMBOK, и още повече ISO 10006) към стандарта на компанията се състои от тяхната специализация и детайлност.

Специализацията означава включване в стандарта на предприятията от тези и само тези разпоредби, свързани с дейностите по проекта в това предприятие и в задължителни за реалностите на това предприятие. На първо място, от това следва, че такива реалности трябва да бъдат ясно определени. Е, необходимо е да се определят реалностите в добре дефинирани концепции, измерими показатели и др. Във връзка с това стандартът на дружеството неизбежно трябва да съдържа описание и класификация на фирмени проекти.

Фирмените проекти могат да се отнасят до различни професионални области на дейност (правни, финансови, информационни, строителни, маркетинг и др.), Имат различна сложност от гледна точка на решени задачи, различна скала от гледна точка на привлечените ресурси и предвидения резултат. Могат да бъдат разпределени някои категории проекти, специфични от гледна точка на специфични отрасли. Например, в стандарта на Enron, специализиращ в областта на електрическата индустрия, международните (чуждестранни) проекти се разглеждат отделно, като предоставят специални изисквания за законодателната рамка, на персонала, оборудването, икономическата инфраструктура, логистиката и др.

За всички постоянни (дефинирани редовни структура) на единици, по един или друг начин, свързани с изпълнението на проектите, следва да се определят принципите на тяхното участие в проекти - видовете работа, процедурата за разпределяне и изземване на персонал, формулярите и размера на полученото възнаграждение.

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

Предмет на специализация определено е процеси на управление на проекти. Общият набор от възможни процеси ще бъде представен под формата на триизмерно пространство, показано на фиг. Тези измерения, посочени в рамковите стандарти, се отлагат по координатните оси, други, като контролни нива, могат да бъдат предложени календарни периоди. Всяка точка на това пространство е основен процес на управление. Например: "Планиране на риска на етапа на изпълнение на системата.

Избраните елементарни процеси образуват процедури за управление на проекти, които могат да бъдат изградени върху принципа "аксиален" (тук се дължи на абсцисата, ордината и приложението, посочена на фиг. 1).

Всъщност описанието на тези процедури е основният обем на стандарта. И ако станете по-точни, под стандарта на предприятието, ние разбираме набор от документи, обясняващи или предписват как, в каква последователност, в кои времеви рамки, използвайки кои шаблони трябва да изпълняват определени действия в процеса на управление на проекти. Броят на тези документи зависи от степента на стандартна детайлност и може да бъде достатъчно голяма (от десетки до стотици документи). На фиг. 2 Те са представени под формата на стъпало (цилиндрична зигформи), която обикновено се изгражда върху нея като пробуждане на апетит страхотно при тези, които организират и регулират работата в предприятието, и стандарта на разработване на стандарта .

Предмет на описанието в стандарта може да бъде и типични ситуации, характерни за проектите на предприятията и препоръки за отговор на тези ситуации. Това е, особените решения, нещо като списък с възможни грешки и препоръки за тяхното премахване (контролен списък). Разбира се, решението все още ще получи мениджър, но има генерализиран опит ("син на труден") от предишни поколения.

Фиг. 1. Процеси на космически контрол

Фиг. 2. структурна структура на управлението на проекти

2. Класификация на проектите като първи етап от създаването на стандарт

Ключовият момент в създаването на стандарта за управление на проекти е да разберем какви проекти се извършват в предприятието, какви са техните различия, което е между тях. Тези въпроси са свързани с практиката на управление на проекти и са отразени в предприятието стандарт.

Сред западните колеги становището е често срещано, че професионалният ръководител на проекта може успешно да изпълни всеки проект, независимо от коя област се отнася - от изграждането на атомна електроцентрала преди разработването на софтуер. По принцип тази теза е валидна, но дяволът, както знаете, лъжи в детайлите! Колко време се нуждае и има такъв запас? Какъв е размерът на консултантите и какви квалификации? Колко ще струва такъв ръководител на проекта само по себе си и колко голяма ще има допълнителни разходи?

Но тази информация е същността на основния документ, от който трябва да започне всеки проект - план за управление на проекти (в различни източници можете да намерите други имена на такъв документ - Хартата на проекта, определение на проекта). По този начин могат да бъдат подготвени специализирани шаблони за управление на проекти, които определят определени специфични методи за управление на проекти, препоръчани в това предприятие за този вид проекти. И след тях и други типични модели.

2.1 Какво трябва да бъде отразено в плана за управление на проекта

Съдържанието и границите на проекта са целите и целите на проекта, основните резултати, критериите за оценка на факта, че работата или частта е завършена.

Основните проекти на проекта са основните събития на проекта (етапи) и плана за тяхното постигане, вероятно използване на структурата на декомпозицията на работата (WBS).

Планиран бюджетен проект

Предпоставенията и ограниченията са предпоставките, основаващи се на това кои оценки на времето на прилагане, сложността на работата на проекта и цената, включително описанието на първоначалните рискове.

Изисквания и стандарти - списък на регулаторните и регулаторни документи или техните индивидуални разпоредби, които следва да се спазват по време на работата на проекта.

Подходи за изпълнението на проекта - понятието за предполагаемото решение (няколко алтернативни възможности), методи за развитие и основни информационни технологии.

Организационна структура - отговорност и процедура за взаимодействие на участниците, имената и отговорностите на ключовите фигури на проекта

Управление на документацията на проекта - структура, среда за съхранение и процедура за създаване и поддържане на хранилище за проект, списък на шаблоните за документи.

Управление на заминаването - Процедури за работа на риска с възникващи проблеми и промени, форми на съответните документи на проекта.

Осигуряването на качеството е списък и разпоредби за провеждане на дейности, насочени към предоставяне на качество, както резултати от проекта (продукт) и процеси за управление на проекти и управление на работата.

Контролът и докладването е регламентите за провеждане на мерки за анализ на състоянието на проекта, съответстващ на формулярите за докладване.

Първо, отбелязваме, че е малко вероятно да се изгради едно дърво класификация на проекти за предприятия. Най-вероятно те ще бъдат няколко класификации по различни причини, свързани с определени раздели на плана. Помислете за някои от тях.

Класификация по тема и продукти в тези зони позволява специализиране на съдържанието и границите на секциите, ключовите етапи, изискванията и стандартите. Тази класификация може да бъде изградена на йерархичен принцип. Например "информационни технологии" - "Проекти за системна интеграция" - "Създаване на интегрирани системи за управление на проекти".

Екологичната класификация на проекта позволява специализиране на организационната структура на участъка, управлението на отклонение, осигуряване на качеството. Различни бази могат да бъдат използвани за изграждане на тази класификация - териториална дисперсия, както е обичайно в Enron Corp., или цената на проекта (IBM) може да бъде някои други основи и комбинации от тях.

Класификация под формата на плащане и следователно отчитането на работата позволява специализиране на контрол и докладване, управление на проектната документация въз основа на такива форми на договори като "време и материали" и "фиксирана цена".

По този начин можем да говорим например за шаблона "План за управление на проекти за създаване на концепция (продукт) на информационната система (тема) струва повече от 100 хил. Долара (скала) с договор във формата и материалите за материали (плащане Форма и отчитане на строителните работи) ", като макроскреин, получен чрез просто сглобяване на няколко по-малки (микро) шаблона на отделни раздели на плана. В допълнение, някои допълнителни раздели трябва да бъдат включени в макрослоката, която не може да бъде определена на микроравно ниво (като "като" етапи "). Micraots могат да бъдат дълбоко специализирани - доколкото позволява съответната класификация и опит, придобит в предприятието.

Примерите за класификации на проекта, разглеждани по-горе, са специално избрани от нас, за да илюстрираме способността за изграждане на шаблон от относително независими стандартни фрагменти. Въпреки това, в реалния живот има и други ситуации. Например, IBM прие класификация на проекти за сложност (сложност). В съответствие с тази класификация, проектите се разделят на обикновен бизнес (бизнес като обичай - BAU), стандартни проекти за системна интеграция и сложни проекти за системна интеграция. Освен това, тази класификация определя за структурата и съдържанието на плана за управление на проекти. В този случай, други класификации запазват стойността си, за да образуват отделни дялове на плана.

2.2 План за управление на проекти и рамкови стандарти

Ще илюстрираме това при примера на не най-трудния раздел на плана "Организационна структура на проекта". В PMBOK необходимата информация е разпръсната в няколко секции (2.2.; 2.3; 2; 4; 4.1.3.; 9) и в ISO 10006: 1997 (e) - раздел 5.8. Но в това и в друг случай не е достатъчно да се създаде специализиран шаблон на тази информация!

Така, въз основа на методологията "рамка", следва да се създаде корпоративна методология, в която са определени основните разпоредби, изисквания, принципи и практики на управление на проекти и систематизирани във връзка с управлението на проекти в това предприятие въз основа на анализа на специфичните особености на проектите, извършени от предприятието.

Тази корпоративна методология и специализирани шаблони за документи са създание на стандарта за управление на ниво предприятие. И процесът на създаване на стандарта прилича на спирала, на всеки нов обрат, от които техниките стават все по-специализирани, а шаблоните все повече подробни са.

3. отклонения на проекта. Рискове, проблеми, промени

На първо място, ще обясним термина "отклонения", това е необходимо, защото в литературата за управление на проекти се тълкува двусмислено. В предишния раздел говорехме за плана за управление на проекти - фундаментален документ, съдържащ документирана представа за координирания проект от всички участници. С други думи, планът за управление на проекти е "точка на подкрепа" или базовата линия за цялото последващо развитие на проекта.

Управлението на отклонението се свежда главно до борбата срещу неприятностите, които като цяло могат да включват три етапа:

Управление на рисковете. Проблемите не са дошли, но е възможно да се появят с нежелани и непланирани събития, които могат да доведат до факта, че целите на проекта (една или няколко) няма да бъдат постигнати. Целта на този етап е да се предотвратят неприятности преди тяхното възникване или поне да ги посрещнем в изпълнение.

Управление на проблемите. Дошли са проблемите и е необходимо да се открие техният произход, степента на влияние върху проекта, методите за преодоляване. Целта на този етап е да предоставим на проекта възможност да отидат както е планирано. Данни за стандартната специалност на проекта

Управление на промените. Проблемите се оказаха доста сериозни и не беше възможно да се справят с тях, без да се засяга проекта. Целта на този етап е, че финансистите се наричат \u200b\u200b"да записват вреди" - изменение на предварително договорените продукти и услуги, времето на изпълнение и разходите за работа, управление и технологични процеси и др.

3.1 Управление на риска

Най-простите и в същото време, които трябва да бъдат отразени в стандарта - формалната страна на управлението на риска, а именно:

Процедури, регулиращи основните етапи на работа с рискове - идентифициране на риска, мониторинг и анализ на риска, планиране на развитието и реализиране на рисково противодействие.

Шаблони на документи, отразяващи процеса на работа с рискове - рискова карта, дневник за риск за проекта и др.

От разнообразието от методи за управление на риска за стандарта трябва да бъдат избрани тези от тях, които са адекватни на проекти, в които те ще бъдат приложени. Тук имаме предвид преди всичко, разходите за изпълнение на процедурите за управление.

Така, когато анализира рисковете, може да бъде разрешено съзнателно намаляване на оценките за някои специфични категории проекти, например за проектите с ниска цена или сложност.

3.2 Управление на проблемите

На първо място, ние ще обясним какво наричаме проблеми и защо проблемите могат да бъдат контролирани (и необходими). В хода на реалната работа по създаването и прилагането на стандарта за управление на проекти в предприятието авторите трябваше да се изправят пред факта, че фразата "управление на проблемите" причинява недоумение сред колегите, които не са имали запознаване с управлението на проекти по английски език стандарти. Много хора изглеждат по-запознати с "решението" или "решаване на проблеми", които съответстват на определенията на "решаването на проблеми" или "резолюция на проблемите", прието в гореспоменатите "рамкови" стандарти, посочени по-горе.

Авторите в този брой предпочитат да следват духа и писмото на такива стандарти за управление на проекти като MITP / PMM / WISDD IBM Corporation, в което този процес се нарича "проблеми / проблеми с управлението на проблемите", който в руския превод е най-добър, според нас , изглежда като "проблеми".

Обикновено проблемите се разделят на две категории - за проблеми, които могат да бъдат решени на мястото на възникването, т.е. на равнището на управление на проекта - проблеми и ескаливите проблеми - въпроси, които за тяхното разрешение е необходимо да се повиши Високо управление на управлението, включително външни софтуерни връзки с проекта.

Стандартът трябва да отразява официалната страна на управлението на проблемите:

Процедури, регулиращи основните етапи на работа с проблеми - идентифициране на проблема, наблюдение и анализ на проблема, вземане на решение и неговото изпълнение, затваряне на проблема.

Шаблони на документи, отразяващи процеса на работа с проблеми - проблеми с карти, дневник за проблеми с проекта и др.

Могат да се разработят специални решения за анализ на проблеми. Например, за да се определи такава важна характеристика на проблема като приоритет на неговото решение, може да се използва приоритетна матрица.

3.3 Управление на промените

Провеждане на примери, илюстриращи работата с рискове и проблеми, разчитахме на традиционни ценни проекти - ресурси, срокове, качествени характеристики на продукта. Ясно е, че контролните влияния, свързани с противодействащите рискове или с решаване на проблеми, са ограничени от същите рамки.

Промяната в проекта е модификация на предварително договорените продукти и услуги, условията за изпълнение и разходите за работа, управление и технологични процеси и др.

Като традиционни мерки за промяна на използваните в проекта ресурси, той се използва например увеличение на интензивността на работата, материални стимули, заместване или привличане на допълнителни изпълнители и подизпълнители. Ако е възможно да се маневрират термини, тогава можем да говорим за промяна на времето за завършване на индивидуалните произведения, изместването на крайъгълния камък в рамките на проекта или дори увеличаване на цялостното приключване на проекта. И накрая, в някои случаи трябва да прибягвате до най-малко желаните мерки, свързани с намаляване на изискванията за качествени характеристики, замяна и дори изключение на продукта.

От гледна точка на тежестта на последствията промените могат да бъдат класифицирани, например, както следва:

Планирани загуби (взети предвид в плана за управление на проекти).

Допустими загуби (незначителни непланирани разходи).

Нежелани загуби (значителни непланирани разходи).

Невалидни загуби (непланирани разходи, които са неприемливи за един или повече участници в проекта).

Ограниченията за промени в ресурса, времето, продуктите могат да бъдат твърди до различни степени и в зависимост от това в проекти има доста типични ситуации, които могат да бъдат предварително описани. Разгледайте някои такива ситуации.

В други случаи могат да се изискват други стратегии, например "сурово време" или "ограничен бюджет, когато промените в крайните срокове и ресурсите следва да бъдат записани в областта на насрочените загуби.

Фиг. 5. Зони за загуба

Фиг. 6. Стратегии за промени в проекта

4. Организационни структури в проекти

За да създадете и управлявате команда по проекта, се използват определени рецепти, които гарантират ефективността на тези процеси. Тези рецепти не са универсални и трябва да вземат предвид спецификата на предприятието - от организационната структура до произведения продукт.

Сред първите проблеми, които възникват при формирането на организационните структури на проекта и които трябва да бъдат решени в стандарта за управление на проекта, отбелязваме проблемите, свързани с кръстовищата на функциите на административното управление и управлението на проекти.

Изпълнението на проекта възниква в рамките на организацията, чиято структура е засегната до голяма степен от успеха на проекта. Разпределят следните принципни организационни форми:

· Функционална структура, включваща използването на съществуващата функционална йерархична структура на организацията. Мениджърът на проекта предоставя само цялостна координация на работата;

· Дивизионна форма на управленска организация (вид функционална структура, образувана от регионален продукт или технологични характеристики;

{!LANG-b3df6ef8c16e6113f1be1e190a406d05!}

{!LANG-f44e405069266e697ecdf152cbd7656b!}

{!LANG-fb6459adf155f2e27f3c683abecc0efc!}

{!LANG-3d6886bbaad67da629ef0c1f34c591dd!}

{!LANG-a76aabe39c70c22090d06f45002c9993!}

{!LANG-7d89314d897beb4b44766e415d93137d!}

{!LANG-6be4e13e8fb45944c579b154cbb72f17!}

{!LANG-5886286bbce3abafc92a41116df5315e!}

{!LANG-4a697a166b1d6ec84fed159751620d2d!}

{!LANG-ee8b83729f5325db92c50e3521be39de!}

{!LANG-19eb9a76582758426f42e8eb961c1a7b!}

{!LANG-b0cf87d6c7d994303c9488606ab80a1a!}

{!LANG-4cfdd9c60a449a6d23d61ee59585abe4!}

{!LANG-88cf17e7c10744146f96a590cdbeef59!}

{!LANG-9f10bb755178c69b7ba37faf7a630063!}

{!LANG-617611b2f7b2420a1709e6a5b1d4b62a!}

{!LANG-6ff0713bba671355a30b2ca41f4dee8c!}

{!LANG-61b6db32e1d5d9806e09dcc47ef56d3b!}

{!LANG-41e14a2ae9bd76aadfc60ce1881845f3!}

{!LANG-278a7357765c820fadb1bc7328fc5a16!}

{!LANG-436c70829e211bac56ff5c2b28911337!}

{!LANG-2c3781629cfe8df4190a7d968448d190!}

{!LANG-6c17ca8684b603ee426a15f51d581f9e!}

{!LANG-86c6bf9727bee4018ae59037a5d74daf!}

{!LANG-58711e521c71705fc817e799aaeb7bd0!}

{!LANG-e8c238c5ecc898938890a7a681afe7ec!}

{!LANG-0fdafc8fcdf4f708abb53a8dbacf29db!}

{!LANG-86978d2d5bb4b9644494559cb69f4422!}

{!LANG-c7bffd9977d1b5ad0dea06d9ae8776dd!}

{!LANG-9bb388128a7d759814940f4e37950ba5!}

{!LANG-c94cc728e3f146d8ea68ad45bee46623!}

{!LANG-25812c48c78ec2aba7e29ae1db187b26!}

{!LANG-45b7079a6bb764d481d2437e1eb72ab6!}

{!LANG-ed9eab7e8f7678ab8deac80debbfac45!}

{!LANG-5a9012eb3aac6bd0f44cec315ff717e7!}

{!LANG-fc99cce2737537ba87d599389ff8202e!}

{!LANG-066484eab6d3c78074cd29085d7eac9e!}

{!LANG-3d7f771342744bc9486220aae40b71a3!}

{!LANG-f22bcef0dcce5340881c976331bbbbc4!}

{!LANG-f1ad8fdd291f268de24aa0ad754c417f!}

{!LANG-b9751d0c8b39851642df48339e030187!}

{!LANG-d025928c50c3e68a2039b00479076266!}

{!LANG-28e113284cb11955e030747dda49a3eb!}

{!LANG-2c3fc00eee01df2b9f6ff9023473f247!}

{!LANG-5217527919c9de2f1c316d60a4eb00bd!}

{!LANG-899d827ba3b86098833fb2a7fbaa0ab3!}

{!LANG-e1833537a32bd5693168a513e01910d8!}

{!LANG-e4589413a8a7be043b56925a5fed83b1!}

...

{!LANG-2315defc5e8fbf7be03badaab0f522f9!}

{!LANG-d0159285db639a66c79265bdeab39a75!}

{!LANG-b990041c48ce8b691069e1a722cb176e!}

{!LANG-0571dd035afbee97902dfb617cd15870!} {!LANG-e467b56038491e801f5acea4b23ff08d!}{!LANG-32539bf53c115d8fa8f6ee43afde0826!}

{!LANG-d1f22bb84184355fae5ce43c9deb1b29!}

{!LANG-676011a27327676ee051f5222f8c5d68!}

{!LANG-834f4658b3e8dca62c770b024d6c086a!}

{!LANG-f34b3a48e8792b5cc21ac86bb4a46201!}

{!LANG-a7c47052c38717f5d467827a33bee8b4!}

{!LANG-548c3c4b1eaf68c9addecfd221f94f4f!}

{!LANG-c4f5cb9da761e0c1896a47549e720448!}

{!LANG-63623c1c69bf9055c69f2865313486c8!}

{!LANG-5b53d90146f8639d15a28349222db221!}

{!LANG-f69196f8523041c1a544053938facf86!}

{!LANG-8fabcd908fba76817da4e8e1074e707d!}

{!LANG-a239171fb1b994547228f3576ee6ec20!}

{!LANG-daaa9cece003b85c27e5735ad454ebb1!}

{!LANG-4ac390e98a99d41d6000a3b5b96f2d93!}

{!LANG-0d08208700d043bb0791e76af9109f23!}

{!LANG-bbe0272dd9d95cb8d3a2aee3152e5a78!} {!LANG-c2984025f6c93a5c0d8e3f834088144d!}{!LANG-a7a5c90735366a726f14a3d501b635e2!}

Категории

Избор на редакторите

Как мога да класифицирам професионалните стандарти за управление на проекти. Приложения към регламентите. Организационен матуритет на управлението на проекти

Структура на разлагане на работата

Класификация на проектите като първи етап от създаването на стандарт

Структура на разлагане на работата

План за управление на проекти и рамкови стандарти

Отклонения на проекта. Рискове, проблеми, промени

Организационни структури в проекти

Изпратете добрата си работа в базата знания е проста. Използвайте формата по-долу

Въведение

1. Общи съображения за създаване на стандарт. Специализация и детайл

Фиг. 1. Процеси на космически контрол

Фиг. 2. структурна структура на управлението на проекти

2. Класификация на проектите като първи етап от създаването на стандарт

2.1 Какво трябва да бъде отразено в плана за управление на проекта

Съдържанието и границите на проекта са целите и целите на проекта, основните резултати, критериите за оценка на факта, че работата или частта е завършена.

Планиран бюджетен проект

Организационна структура - отговорност и процедура за взаимодействие на участниците, имената и отговорностите на ключовите фигури на проекта

Управление на заминаването - Процедури за работа на риска с възникващи проблеми и промени, форми на съответните документи на проекта.

Контролът и докладването е регламентите за провеждане на мерки за анализ на състоянието на проекта, съответстващ на формулярите за докладване.

2.2 План за управление на проекти и рамкови стандарти

3. отклонения на проекта. Рискове, проблеми, промени

Управлението на отклонението се свежда главно до борбата срещу неприятностите, които като цяло могат да включват три етапа:

3.1 Управление на риска

Най-простите и в същото време, които трябва да бъдат отразени в стандарта - формалната страна на управлението на риска, а именно:

Шаблони на документи, отразяващи процеса на работа с рискове - рискова карта, дневник за риск за проекта и др.

3.2 Управление на проблемите

Стандартът трябва да отразява официалната страна на управлението на проблемите:

Шаблони на документи, отразяващи процеса на работа с проблеми - проблеми с карти, дневник за проблеми с проекта и др.

3.3 Управление на промените

От гледна точка на тежестта на последствията промените могат да бъдат класифицирани, например, както следва:

Планирани загуби (взети предвид в плана за управление на проекти).

Допустими загуби (незначителни непланирани разходи).

Нежелани загуби (значителни непланирани разходи).

Невалидни загуби (непланирани разходи, които са неприемливи за един или повече участници в проекта).

Фиг. 5. Зони за загуба

Фиг. 6. Стратегии за промени в проекта

4. Организационни структури в проекти

· Дивизионна форма на управленска организация (вид функционална структура, образувана от регионален продукт или технологични характеристики;

{!LANG-b3df6ef8c16e6113f1be1e190a406d05!}

{!LANG-fb6459adf155f2e27f3c683abecc0efc!}

{!LANG-3d6886bbaad67da629ef0c1f34c591dd!}

{!LANG-a76aabe39c70c22090d06f45002c9993!}

{!LANG-4a697a166b1d6ec84fed159751620d2d!}

{!LANG-ee8b83729f5325db92c50e3521be39de!}

{!LANG-19eb9a76582758426f42e8eb961c1a7b!}

{!LANG-b0cf87d6c7d994303c9488606ab80a1a!}

{!LANG-4cfdd9c60a449a6d23d61ee59585abe4!}

{!LANG-617611b2f7b2420a1709e6a5b1d4b62a!}

{!LANG-6ff0713bba671355a30b2ca41f4dee8c!}

{!LANG-61b6db32e1d5d9806e09dcc47ef56d3b!}

{!LANG-41e14a2ae9bd76aadfc60ce1881845f3!}

{!LANG-6c17ca8684b603ee426a15f51d581f9e!}

{!LANG-86c6bf9727bee4018ae59037a5d74daf!}

{!LANG-0fdafc8fcdf4f708abb53a8dbacf29db!}

{!LANG-ed9eab7e8f7678ab8deac80debbfac45!}

{!LANG-066484eab6d3c78074cd29085d7eac9e!}

{!LANG-f1ad8fdd291f268de24aa0ad754c417f!}

{!LANG-b9751d0c8b39851642df48339e030187!}

{!LANG-d025928c50c3e68a2039b00479076266!}

{!LANG-28e113284cb11955e030747dda49a3eb!}

{!LANG-2c3fc00eee01df2b9f6ff9023473f247!}

{!LANG-5217527919c9de2f1c316d60a4eb00bd!}

{!LANG-899d827ba3b86098833fb2a7fbaa0ab3!}

{!LANG-e1833537a32bd5693168a513e01910d8!}

{!LANG-e4589413a8a7be043b56925a5fed83b1!}

{!LANG-2315defc5e8fbf7be03badaab0f522f9!}

{!LANG-bfc95980634bf529e8a406db2c842b31!}

{!LANG-5bf5c1d5c47fd0d047c1542c32abd343!}

{!LANG-8ffe5e48639e519921c7bc795adadd20!}

{!LANG-0b294e305f274f387a8ca983bd4274a9!}