Не правете нищо без ясна цел

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

Ако нямате ясна цел и само правите нещо, защото всички останали го правят или всички казват, че е важно да го направите, то:

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

Пример: Портфолио и програми

Ако участвате в подбора и инициирането на проекти, трябва да се уверите, че се фокусирате върху ползите и проблемите, които трябва да бъдат решени, а не върху продукта, който ще реализира тези неща. Класическият пример е производителят на асансьори, който тъй като получавал оплаквания за скоростта на своите асансьори инициирал и ръководил множество проекти за увеличаване на скоростта, без пълен успех. Това продължило докато не решили да се съсредоточи върху проблема (скуката или дискомфорта на хората) вместо с „естественото“ решение (по-бързи асансьори). Резултатът е, че те добавят огледала в асансьорите и решават проблема просто и евтино.

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

Пример: Проектът като цяло

Гъвкавостта на продукта варира между проектите. В някои ИТ проекти продуктът е напълно гъвкав и неговата окончателна версия зависи от обратната връзка, която ще бъде генерирана на всеки етап от разработката му по време на проекта, което изисква адаптивен (Agile) подход. На практика това е комбинация от наслояване на портфолио, програма и проект и се нуждае от максимално внимание към крайната цел. Добра идея е да се документира целта и тя да бъде достъпна. Това е една от целите на „продуктовата визия“, използвана в някои Scrum проекти. Вниманието към стойността на бизнеса в Agile проектите е техният начин да осигурят съответствие с целта.

В други видове проекти, където продуктът е относително фиксиран и съществуват други механизми, които да гарантират, че идентифицираният продукт ще задоволи целта, членовете на екипа на проекта могат да прехвърлят голяма част от фокуса си от целта към продукта (следователно, принципът „фокус върху продуктите“ на PRINCE2^®). Минималното внимание към целта, обаче, все още е необхоидмо, за да се гарантира, че това, което се разработва, ще задоволи целта, което може да бъде направено чрез сравняване на прогнозираните ползи с очакваните ползи (оттук и принципът на „продължаващата бизнес обосновка“ и темата „бизнес казус“ в PRINCE2^®).

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

Пример: Мониторинг на проекта

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

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

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

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

Пример: Документи

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

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

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

Търсенето на „шаблон“ е обратното на правенето на нещо, което се основава на цел.

Пример: Отчитане на състоянието

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

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

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

Пример: Бизнес казус и харта на проекта

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

Докато мислите за начина, по който можете да подготвите документите, за да задоволите техните цели, може да не мислите за всеки сценарий и да пропуснете нещо. За да избегнете това, можете да проверите какви ресурси предлагат PRINCE2^® , PMBOK^® ръководстворо, P3.express и DSDM^® и след това да оцените тези предложения въз основа на целите.

Пример: Пост-проект

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

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

Мониторингът след приключване на проекта е необходима стъпка за постигане на целта. Това е основна отговорност на системите за управление на програми и портфолио и, тъй като повечето компании нямат такива нива на управление, тази стъпка обикновено се пренебрегва. Ето защо методи като P3.express и DSDM^® добавят тази стъпка към техните методологии за управление на проекти.

Пример: Простота

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

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

Пример: Приспособяване

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

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

▼ PDF