Класическите грешки: Демотивация на екипа
Когато говоря на моите семинари за управление на проекти за факторите, които предричат успеха или провала на един проект, неминуемо стигаме до класическите грешки, дефинирани от Steve McConnell и публикувани в неговата книга “Rapid Development” (1996). Тя и до днес е “библия” в областта на проектното управление в софтуерния бизнес и постулира, че ако искаме един проект да бъде успешен, преди всичко трябва да престанем да правим класически грешки – онези действия, които са доказали в практиката на много проекти, че със сигурност водят до провал. Един от тези важни фактори е демотивацията на екипа.
Започвам с демотивацията, защото наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. Това, което искам да ви разкажа, е една история от моя опит (нали затова този блог се казва PM Stories 
), в която демотивацията изигра съществена роля за провала на проекта.
Това беше първият ми проект в една от най-авторитетните софтуерни фирми в България. Бях толкова щастлив, че са ме одобрили да работя за тях, че бях готов да работя денонощно, за да докажа своите професионални качества. Аз нямах особени постижения преди това – бях просто редови програмист в малка фирма и нямаше с какво да се похваля. Но сега бях попаднал на място, където хем имаше много неща, които да науча, хем можех да покажа пред шефовете и клиентите на какво съм способен.
Възложителят беше сериозна финансова институция с разрастващ се бизнес и имаха остра нужда да заменят екселските файлове, които ползваха за отчитане на финансовото състояние на своите клиенти, със специализирана информационна система, която можеше да им даде точна и навременна информация за това. За съжаление, човекът, който отговаряше от тяхна страна за изпълнението на проекта, беше недостатъчно компетентен и още в самото начало разбрахме, че само изясняването на изискванията ще ни отнеме ужасно много време.
Категории: Класически грешки | 6 коментара
Как да ангажираме висшия мениджмънт в проекта?
През 1994 г. излиза първият Chaos Report – изследване на успеваемостта на ИТ проектите, което показва, че успешните проекти за ужасно малко (16%), а прекратените – цели 31%. Въпреки, че методиката и базата на интервюираните се оспорват от мнозина, самият отчет показва доста трагична ситуация в проектното управление в онези години.
Оттогава до сега има и други изследвания на успеваемостта на проектите, а самите Standish Group, които са изготвили първия Chaos, продължават периодично да правят подобни изследвания, опитвайки се не само да разберат какъв процент от проектите са успешни, но и причините за успеха и провала на проектите в ИТ сферата.
Много от тези изследвания установяват, че една от най-важните причини за проблемите на проектите е слабата ангажираност на топ мениджмънта в проекта. В моя опит също има много случаи, когато се е налагала намесата на големия шеф – било да договори важни решения с възложителя, или да повдигне морала на екипа и да им покаже доверие, – но това не се е случвало. И започвам да се питам: защо, как е възможно един интелигентен човек да пренебрегне това свое задължение, което на всичкото отгоре се оказва, че има фатално значение за проекта?
След известно размишление, стигнах до два вероятни извода – оптимистичен и песимистичен.
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
