PM Stories

Целите на проекта – видео

Майк Рам — Mon, 07 Nov 2011 07:50:27 +0000

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

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

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

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

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

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

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

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Класическите грешки: Демотивация на екипа

Майк Рам — Tue, 25 Oct 2011 02:12:43 +0000

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

Започвам с демотивацията, защото наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. Това, което искам да ви разкажа, е една история от моя опит (нали затова този блог се казва PM Stories ), в която демотивацията изигра съществена роля за провала на проекта.

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

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

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

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

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

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

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Как да ангажираме висшия мениджмънт в проекта?

Майк Рам — Sun, 16 Oct 2011 16:11:06 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

За плановете и планирането

Майк Рам — Mon, 04 Jul 2011 16:41:45 +0000

Имам един любим цитат, който някои приписват на ген. Патън, а други на Айзенхауер. В крайна сметка не е толкова важно кой е оригиналният автор, а какво е посланието. Ето го и него:

Планът е нищо! Планирането е всичко!

Съвсем наскоро пък попаднах на друг цитат, чийто автор не е упоменат, но пък звучи малко по-ясно:

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

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

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

На 12.07.2011 г. ще водя семинар по управление на проекти, посветен на планирането. По този повод, освен че ви каня да участвате в него, искам да ви попитам за вашето мнение относно плановете и планирането. Какво мислите за горните цитати? Вярвате ли, че е важно да имаме план – не само в проектите, които изпълняваме, а и в живота? И доколко трябва да следваме плана, който веднъж сме създали – трябва ли да се стремим да го изпълняваме на всяка цена или можем всеки ден да го променяме?

И за да ви стимулирам към активност (след доста продължително затишие в този блог), обявявам награда: онзи коментар, който най-пълно и аргументирано отговори на поставените въпроси по мое субективно мнение, ще получи ваучър за участие в семинара “Планиране на проекти” на 12.07.2011 с 50% отстъпка от редовната такса за регистрация.

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

Ако всичко това ви изглежда интересно и полезно, заповядайте – регистрирайте се за участие до 08.07, за да се възползвате от по-ниската цена за ранно записване. Няма да съжалявате!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Среща на Agile и Lean общостта – 18.04.2011

Майк Рам — Mon, 11 Apr 2011 11:43:52 +0000

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

Здравейте, приятели!

Наскоро да имаше семинар на тема “Методологии за управление на проекти”, където стана дума за Lean & Agile. Затова няма да изпадам в подробности – ще отбележа само, че Lean & Agile са философии/принципи/методи/практики, които през последните години набират широка популярност по света (до някаква степен и в България) и които имат сериозно отражение върху начина на управление на проекти (софтуерни и не само).

Конкретният повод да пиша тук е една инициатива, подета от Jurgen Appelo, целяща подобряване на комуникацията и сътрудничеството между хората в Европа, интересуващи се от Agile и Lean. Подробности за инициативата има тук: http://www.noop.nl/2011/02/agile-lean-europe-energize-the-network.html

На конференцията XP 2011 в Мадрид през месец май 2011 ще се дискутират идеи и планове за Agile Lean Europe (ALE) общността (http://www.noop.nl/2011/03/ale-gathering-at-xp2011.html). Идеята е всяка страна да представи своите идеи пред останалите.

Във връзка с това Scrum Bulgaria групата организира среща на 18 Април 2011, понеделник от 19:00 часа. Сборен пункт – фоайето на Факултета по Математика и Информатика (ул. Джеймс Баучър 5; град София). Основна тема за обсъждане: визия и идеи за Agile Lean Europe (ALE) общността:

Какво е важно за нас от България по отношение на цялата ALE общност (Европа). В частност отговор на тези въпроси.
Как ще представим нашите идеи пред останалите? (В най-добрия случай се търси някой да се появи на XP2011 в Мадрид през май 2011).

Междувременно темата се дискутира тук: http://bit.ly/ale-xp2011-bulgaria-sb
Подробности за събитието – на сайта на scrumbulgaria групата.

Срещата е отворена за всички желаещи! Заповядайте!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Документи на бизнес анализа

Майк Рам — Wed, 09 Mar 2011 15:02:14 +0000

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

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

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

Документите, които са представени в публикацията са:

Current state analysis document (Анализ на текущото състояние)
Project vision document (Визия за проекта)
Solution vision document (Визия за решението / продукта)
Business requirements document (Бизнес изисквания)
Business process design document (Дизайн на бизнес процесите)
Use case model document (Use case модели)
Use case specification document (Use case спецификации)
System-wide requirements document (Системни изисквания)
Solution glossary (Речник на решението)

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

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

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Безплатна електронна книга за PRINCE2

Майк Рам — Tue, 01 Mar 2011 09:08:45 +0000

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

Книгата “Inside PRINCE2“ е сборник със статии, написани от Елизабет, разказващи за основните концепции на методологията, принципите на толерансите, особеностите при иницииране и приключване на проекта, както и въпроси относно сертифицирането в тази област.

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

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

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

Книгата “Inside PRINCE2″ на Елизабет Харин е чудесно начало за онези, които тепърва се запознават с тази методология. Надявам се да ви бъде полезна!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Да си се похваля или “който рискува – пичели”

Майк Рам — Sun, 20 Feb 2011 11:09:47 +0000

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

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

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

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

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

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

Мариана Евлогиева, в типичния си хумористичен и закачлив стил също посвети един пост в блога си на семинара, в който ме поставя редом с такива титани на интелектуалната мисъл като Къци Вапцаров (“Риск печели, риск губи”) и Христо Стоичков (“Който ни рискува – ни пичели”), но ако махнем шегата настрана, ще видим, че тя е открила за себе си ползите от анализа на рисковете, който може да разкрие десетки, ако не и стотици рискове, които не само могат да се превърнат в препъни-камъни за проекта, ами и в “истински канари”, които да не можем да заобиколим. И най-важното, което Мариана споделя, е че това не бива да ни плаши и паникьосва, а да ни помогне да си изградим успешна стратегия за предотвратяване на негативния ефект на такива събития.

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

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

Най-ефективният семинар изобщо в който съм участвал досега!

Нищо повече не мога да добавя, освен:

Благодаря ви, приятели! Продължаваме напред заедно!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Вероятност за риск

Майк Рам — Tue, 01 Feb 2011 06:45:29 +0000

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

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

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

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

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

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

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Как се справяте с рисковете?

Майк Рам — Fri, 28 Jan 2011 09:50:40 +0000

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

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

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

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

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

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

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

Участвайте и споделете вашето мнение – така ще си бъдем взаимно полезни в работата!

Гласувайте за тази статия в Svejo.net: