Проблемите, с които се сблъсквах

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

С течение на времето видях колко грешни са тези подходи и до колко разочарования водят. Както за клиента, който не получава нищо свястно като резултат, така и за проектния екип, който излиза обезверен и демотивиран. Още тогава започнах да се питам:

Защо го правим всичко това?

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

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

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

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

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

Съзряването

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

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

Ето защо в обученията, които водя, не се представям за по-умен от моите курсисти и не се опитвам да давам съвети. Само споделям наблюденията си от личния си опит и поставям въпроси, на които всеки сам трябва да намери отговора за себе си. Отдавна съм разбрал, че няма начин “един размер да пасне на всички” – колкото хора, толкова и изисквания. Затова и всеки проект е уникален и затова всеки проект изисква уникален подход. Това е проклятието и красотата на нашата работа. Важното е да знаем основните принципи, да изповядваме ясни ценности и да преследваме верните цели. Тогава неминуемо ще постигнем успех.

Пътят към истината е чрез диалог.

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

Ако вие сте такива хора – заповядайте! Заедно ще успеем!

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

The post Защо водя обучения по управление на проекти? appeared first on PM Stories.

Статистиката от доклада Chaos

Graig Brown от блога Better Projects представи една статистика от доклада Chaos на Standish Group от 2002 г., в която се вижда, че цели 45% от изискванията, които клиентът е включил в проекта и са били реализирани, в крайна сметка въобще не се ползват. (Цъкнете върху картинката за по-голямо изображение.)

Като добавим и 19-те процента на много рядко използвани изисквания, положението придобива трагични размери. На практика, едва 20% от изискванията на клиента влизат в активна употреба. Това означава, че огромно количество труд и енергия на проектиния екип са отишли на вятъра.

Какъв е изводът?

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

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

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

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

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

The post Внимавайте с изискванията на клиента! appeared first on PM Stories.

Войната на браузърите

Scott Berkun е популярен консултант и лектор в областта на проектното управление, автор на книгите The Myths of Innovation и Confessions of a Public Speaker. В новия си блог Speaker Confessions, посветен на говоренето пред публика, той представя запис от една своя презентация, изнесена пред екипа на Google, наречена Поуки от войната на браузърите. В нея той разказва за ранните години на интернет и развитието на първите версии на най-популярните браузъри по онова време – Netscape Navigator и Internet Explorer.

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

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

Защо хората мразят процесите?

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

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

Възможно ли е изобщо да се управлява един проект с какъвто и да е процес?

Но после стигам до извода, който и самият Скот предлага:

За всеки проект е нужен подходящ екип и подходящ процес.

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

Ще попитате “А какво значи “подходящ” процес?“. Отговорът е много прост: подходящ е онзи процес, който помага на хората да си свършат работата по-добре. Процес, който повече пречи, отколкото помага, е по-добре да бъде сменен.

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

(Снимка: Pınar Özger)

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

The post Защо хората мразят процесите appeared first on PM Stories.

Докладът Chaos (The Chaos Report)

През 1994 г. излиза първият Chaos Report – изследване на успеваемостта на ИТ проектите, проведено от The Standish Group. Tо показва, че успешните проекти за ужасно малко (16%), а прекратените – цели 31%. Въпреки, че методиката и базата на интервюираните се оспорват от мнозина, самият отчет показва доста трагична ситуация в проектното управление в онези години.

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

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

Защо се случва това?

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

След известно размишление, стигнах до два вероятни извода – оптимистичен и песимистичен.

Оптимистичният извод

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

Как можем да постигнем по-голяма ангажираност на шефа?

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

Песимистичният извод

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

Можем ли изобщо да го накараме да се ангажира по-сериозно с нашия проект?

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

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

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

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

И тук идва моят въпрос към вас: имали ли сте подобни случаи, когато големият шеф се измъква от отговорност към проекта и какви са вашите идеи за това как да го накараме да се ангажира по-активно в работата?

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

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

The post Как да ангажираме висшия мениджмънт в проекта? appeared first on PM Stories.

Що е то вероятност за риск?

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

Сет Годин за риска

Бях приятно изненадан, че моят личен бизнес гуру и любим блогър – Сет Годин – е имал подобни преживявания, за които разказва в книгата си “Племена”:

Наскоро слушах някакъв човек по радиото, който през цялото време предъвкваше “вероятността за риск”, свързана с някакво действие в бъдеще. Хората са толкова уплашени от риска, че не искат да използват самата дума. В крайна сметка, рискът е вероятност за провал, нали? Значи ни предупреждава, че има вероятност за вероятност. Дори не може да каже точната дума.

Всичко е рисковано. Винаги.

Всъщност, това не е съвсем вярно. Има едно изключение: единственото сигурно нещо е, че винаги има риск. Колкото повече се опитвате да играете на сигурно, толкова по-рисковано става. Така е, защото светът със сигурност, съвсем определено и напълно вероятно се променя.

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

Епилог

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

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

The post Вероятност за риск appeared first on PM Stories.

Класическите грешки

Когато говоря на моите семинари за управление на проекти за факторите, които предричат успеха или провала на един проект, неминуемо стигаме до класическите грешки. Това е термин, дефиниран от Steve McConnell и публикуван в неговата книга “Rapid Development” (1996). Тя и до днес е “библия” в областта на проектното управление в софтуерния бизнес. В нея авторът постулира, че ако искаме един проект да бъде успешен, преди всичко трябва да престанем да правим класически грешки. Това са онези действия, които са доказали в практиката на много проекти, че със сигурност водят до провал. Един от тези важни фактори е демотивацията на екипа. Стив МакКонъл я постава сред най-важните причини за неуспеха на един проект.

Наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. В този пост ще ви разкажа една история от моя опит, в която демотивацията изигра съществена роля за провала на проекта.

Моята история с демотивацията на екипа

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

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

Моята оценка на предстоящата работа

Аз имах опит в работа с банкови системи и прецених, че ще ни трябват 10-12 месеца за изпълнението на целия проект. Това включваше:

• 3-4 месеца за цялостен анализ на изискванията и формулиране на функционална спецификация
• поне 6 месеца разработка от един малък екип от четирима човека примерно.

Каква беше моята изненада, когато разбрах, че аз ще съм единствения програмист в екипа (а бях титулован Team Leader!) и вместо очакваните 10-ина месеца за цялостно изпълнение на проекта, имах само 4! Заедно с колегата, който изпълняваше функциите на проектен мениджър и бизнес анализатор, се опитахме да обясним на големия шеф, че при тези условия нямаме никакви шансове да изпълним този проект, но отговорът му беше, че ако не се справим, значи не сме достойни за тази фирма и че той е направил грешен избор като ни е назначил.

Грешният екип

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

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

Единият колега беше назначен с връзки и въпреки напомпаните препоръки, се оказа, че на практика няма никакъв опит в програмирането и почти с нищо не може да бъде полезен. Другият пък беше доста колоритна личност, за който понятията трудова дисциплина и отговорност не съществуваха. Той идваше на работа след 13:00 часа, защото до обяд си отспивал след нощни игри на Counterstrike, а в 17:00 вече си тръгваше, защото имал среща с гадже. Кодът, който пишеше и публикуваше в общата source code база, не се компилираше и в крайна сметка колегата носеше повече вреда, отколкото полза на работата. Да, беше веселяк, но това никак не помагаше на нашите проблеми.

Закономерният провал

Не след дълго на нашия екип започнаха да му викат “наказателния отряд”. Всички разбрахме, че бяхме хора, които не само не се ползваха с доверието на висшето ръководство, но бяхме напълно изоставени от него. Мотивацията на целия екип се срина до нула и когато след близо 9 месеца работа клиентът поиска да прекратим договорните си отношения, никой от нас не беше изненадан. Имах познати във фирмата на клиента и разбрах, че по-късно същият проект е бил възложен на друга фирма, която го изпълнила успешно точно по плана, който аз и моят колега бяхме разработили. Единственото ми удовлетворение от цялата история беше, че все пак моите оценки се оказаха верни.

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

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

The post Класическите грешки: Демотивацията на екипа appeared first on PM Stories.

Какво представлява управлението на рисковете в проекта?

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

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

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

Два казуса за обсъждане

Искам да ви подканя да се включите в обсъждането на два конкретни казуса. Единият е формулиран в страницата на моята фирма – RammSoft – във Фейсбук. Там питам как бихте постъпили, ако ключов член на вашия екип реши да напусне фирмата.

За онези, които нямат акаунт в социалната мрежа или просто тук се чувстват по-уютно, предлагам друг казус – по-сложен, според мен:

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

Споделете мнението си с коментар под този пост. Така ще си бъдем взаимно полезни в работата!

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

The post Как се справяте с рисковете? appeared first on PM Stories.

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

Бизнес целите на проекта

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

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

Стъпки за постигане на целите – SMART

Как обаче оценяваме дали целта е постигната? Това става с по-малките цели, които си поставяме. На английски това се нарича objectives, а аз го нарекох стъпки към постигане на главната цел. Те трябва да отговорят на определени характеристики, описани с акронима SMART:

• Конкретни (Specific)
• Измерими (Measurable)
• Приемливи (Acceptable)
• Реалистични (Realistic)
• Ограничени във времето (Time-bounded)

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

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

Майк Рам за целите на проекта

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

The post Целите на проекта – видео appeared first on PM Stories.