Krizove rizeni nekolika projektu

Problém máte s prvním projektem, ten vyřešte. Nezatahujte do problému i ostatní projekty. Pokud první projekt potřebuje více zdrojů, mění se zásadně jeho Business Case a musíte kvalifikovaně navrhnout jeho sponzorovi, co s tím. Přeplánovat (a kde vzít zdroje...přece nemůžete jen tak omezovat další projekty, představte si že mají různé sponzory, to byste zásadně překračoval mandát vedoucího projektu), zastavit..a hlavně kde se stala chyba, proč k tomu došlo a co udělat pro to, aby se neopakovala.

Keep it simple stupid, jinak se z toho picnete a v pytli budou všechny projekty.

A mimochodem, doplňte si vzdělání v oboru.

Jsem elektronik, ale jinak mám vojenskou vysokou školu, tedy ofícír, za mlada. Existoval předmět, v době mého studia: Operační výzkum, původně to bylo určeno na řešení problematiky, zásobování vojska munucí a materiálme. K tomu patřila i t.z.v. Metoda kritické cesty. Frajeři ekonomové, politici i odborníci na tyto metody zapoměli......... Trh vyřeší všechno ... Tak ne ...

pro InCoTech
mne se myslenka predani krizoveho projektu naopak libi. Jde o to, ze casto muze jit o subjektivni uviznuti a pomuze cerstvy pohled na vec. Btw., proto taky nabizite sve sluzby.
V praxi se mi soustredeni na nejkomplikovanejsi veci velmi nevyplaci. Taky k tomu zklouzavam a pak to konci tim, ze mam na stole nekolik velmi komplikovanych ukolu a omezeny cas. Z meho pohledu je lepsi prave delegovat (outsourcovat) ty technicky komplikovane ukoly odbornikum a soustredit se spise na ty nejzasadnejsi.

pro Tomas Smutny
dekuji za radu. Podivam se na metodu kriticke cesty. Na prvni pohled si to zatim nedokazu v praxi predstavit, ale za pokus to stoji.

dekuji i ostatnim za komentare

V řadě příspevků se bere za samozřejmé, že vedoucí projektu je operativní hasič, kterého problémy překvapují jako na běžícím pásu. To se samozřejmě děje, pokud problému dostatečně nerozumí, špatně jej naplánoval, za dílčí výstupy špatně přidělil odpovědnosti a nedefinoval akceptační kritéria a postupy. Potom souhlasím se vším, co tu zaznívá. S řešením se ale neshodneme, já tvrdím že se musí dostat k řešení příčin, ne jen následků. A musí se vzdělat, pane smutný generále (probuďte se, totáč je pryč a zelená nefrčí).

Organizace a řízení schůzek patří samozřejmě k základním schopnostem, přidal bych k poslední poznámce něco nutné byrokracie - předem dohodnout, o čem schůzka bude, jaké má cíle a program, připravit a distribuovat podklady, na schůzce dosáhnout jasných závěrů s termíny a odpovědnostmi a ty ZAPSAT!!!!!!!

Kritická cesta ani jiný způsob plánování vám obávám se nepomůže. Vedení projektů není jen o plánování, vy máte problémy s řízením kapacit, s dodržováním plánů, se základním pochopením role vedoucího projektu, sponzora projektu, členů týmu a jejich liniových manažerů. Doporučoval-li jsem vám doplnit si vzdělání, myslel jsem na PMI, PRINCE2 a pod.

PMI je tak pro amíky a PRINCE2 je typický moderní balast navršený kolem základních problémů aby se líbil, zaujal a vidělal.. Asi jako koučing ...

praxe: přijmu brigádníka na rutinní úkony projektů 2,3,4, ušetřené zdroje věnuju 1 při 20% záloze pro případné průsery, ztrátu zisku kompenzuje nezhroucení systému a důležitost projektu, který si musí zasloužit označení 1.

Já to dělal tak, že jsem krizový projekt delegoval a věnoval se v klidu ostatním, abych si nenarušil i ty ostatní. Plánovaný čas jsem věnoval jen dohledu nad krizovým... Jen musíš mít za zády někoho, koho na to můžeš pustit. A nebo připustit, že to půjde celé jinou cestou, než kdybys to dělal sám (těžké že?)

Zakladna chyba je v ocakavani, ze 100% vykonu je "akurat" :).
Spravna odpoved je bod c.1 :)
Na vyuzitie volneho casu ked ide vsetko neocakavane dobre sa uz nieco drobne a kratkodobe najde.

no správné jsou všechny odpovědi ale zásadní je nechávat si rezervy. A velmi důležité je kalkulovat projekty nikoliv jako samostatné aktivity, ale uvědomit si jejich dopad na vytížení různých lidí. A zcela klíčové je pak kvalitní projektové řízení, čím kvalitnější projektové řízení, tím menší potřeba nějakých rezerv.
Dalším způsobem je mít těch projektů 100 a ne 4. To že ti onemocní třeba jeden programátor ze 4 je podstatně pravděpodobnější, než že ti onemocní 25 programátorů ze 100. Ale to se samozřejmě snadno napíše a hůř realizuje.
Klíčová je také krizová komunikace - nejhorší možný způsob je počkat až se to posere a pak to říkat klientovi - když to s nimi proberete v průběhu tak zjistíte, jak moc je pálí termíny a často se zjistí, že se člověk honí kvůli nějakému termínu ve smlouvě, ve kterém je klient stejně zrovna měsíc na dovolené.

Osobně si nemyslím, že je možné mít 40% neutilizovaných rezerv - dnes je to spíše opačně. Pokud si ale můžete dovolit tento stav - firma mých snů :-)
Jinak bych se možná podíval na to kdo dělá které práce - ať nemáte senior lidi na administrativních pracech a podobně.
Jinak podívat se na "reálné" termíny dodávky také určitě pomůže - nejspíše zjistíte, že v krizi je více projektů :-(

Přeju hodně štěstí

Moc dekuji za nazory a zkusenosti!
Stale vice se presvedcuji v uzitecnosti rezerv i kdyz maji tendenci se vzdy na neco vycerpat. :/ Stejne tak jako kazdy projekt ma tendence vycerpat vsechny pridelene zdroje (Murphyho zakon)
Ten popis problemu je samozrejme prilis teoreticky. Realne projekt vyzaduje zdroje v rozsahu od-do, a neni snadne udelat dobry odhad i po letech zkusenosti. (Tyka se projektu IT)
Do 100 projektu opravdu nejdu, to bych pak mel uplne jine starosti a problemy. Prijde mi to jako cesta do pekla. Uz i 4 se mi zda byt hodne. Ohledne komunikace 100% souhlasim.
Delegovat krizovy projekt je zajimavy napad :) a fakticky jsem to taky vyzkousel. Je to ovsem zase o tom, jak rikate, mit komu delegovat = dalsi rezervni zdroje.

Byl jsem zvedavy na variantu 3. Zatim se zda, ze ji nikdo nepouziva. Asi by bylo obtizne vest zaroven 3 zdrave a 1 nemocny projekt. Nakaza se spravidla siri.

zdravim,

budu trochu vestit. Napisi moznosti:

0) Pokud je chyba v lidech = jejich neschopnost, tak vyhodit lidi u prvniho projektu a prijmout nove.

1) udelat znovu analyzu u prvniho projektu. Mozna bude jenom stacit sepsat chyby. Vyjde Vam pak uplne neco jineho, nez jste puvodne od prvniho projektu zamyslely.
Pak uz se bude vse resit lepe.

2) Zastavit prvni projekt, pokud to jde na nejakou dobu. V dane fazi bych se soustredil na jiste penize, ktere prijdou brzo a to jsou zbyvajici projekty.

3) Prvni projekt zahodit a napsat/udelat znovu, pokud to presahlo nejakou rozumnou mez a uz se s tim neda pracovat. Nevymyslet ani nic noveho, ale vzit dobre osvedcene pokusy.

Osobne se domnivam, ze nejvice techto problemu je spatna analyza. Muze to byt, ze delate neco, co neznate. Neco co nedovedete presne popsat. Neco u ceho jste precenili sily. Nebo nedovedete pouzit lepsi postup = nastudovani a implementace zabere mene casu nez se snazit dotahnout neco, co se jiz "tahne".

gf

Zarazila mě Pavlova (2) metoda, protože v praxi si to neumím představit: nejrizikovější projekt předám - tj. mám v záloze někoho schopnějšího, kdo to úspěšně dotáhne. Osobně bych to spíš udělal naopak - sám se soutředil na nejkomplikovanější a ty "lehčí" delegoval. Ale to je jen teoretizování, pokud je diskuze takto obecná.

Ale celkově bych volil pátou možnost: dnes není problém najít si nějakou slušnou firmu (třeba tu naši), která mi velmi rychle dodá zkušeného analytika, který najde chybu v projektu a případně dodá potřebné kvalifikace na dokončení projektu. Ziskovost projektu se sice o něco sníží, ale je to lepší, než negativní reference.
Pokud hrozí zpoždění termínů, tak je od začátku třeba jednat se zákazníkem. Někdy se ukáže, že pracuje s nějakou rezervou a je tak prostor pro 6. variantu. V každém případě se tak předejde možným konfliktům.

Sedněte si, stanovte si prioritu jednotlivých projektů, jejich časové nároky, termíny dodávek apod. No a pak mezi ně podle priorit přidělujte dostupné zdroje (pracovníky, hw). Pokud se nedostává zdrojů, musíte buď ořezat (odsunout) projekty s nejnižší prioritou, nebo přidat zdroje (najmout člověka, koupit hw, ...).

Cokoliv jiného je jenom lakování na růžovo a ve finále skončíte se čtyřmi projekty v krizi namísto např. tří projektů dodaných OK a jednoho zpožděného projektu s nejnižší prioritou (typicky je to např. vývoj interního IS).

Hlavně se nesnažte vymýšlet rafinovaně komplikované plány .., to nefunguje.

Variace na stejné téma .. metoda PERT

Projekty maji ruzne faze, za prve by tedy pridelovani projketu PM melo toto akceptovat. Tj aby se mi nesesli vice komplikovanych fazi v jeden cas. Pak samozrejme uz jde jen o planovani sebe sama a prelivani svych casu mezi projekty. (samozrejme ne prehnane) Proste at minikdo netvrdi, ze kazdy den na projektu je zahul. A propo doporucuji omezit schuzovani a zavest predschuzky (definice problemu overeni, ze zucastneni pochopili) rozejit se a pak udelat schuzku, kde se vybere nejlepsi a nejvhodnejsi reseni. Timto pak mame dostatek casu a pres nevznika. Jsou to metody jeste s pre 89, kdy toliko nebyli pocitace a cestak nebyl o tom, ze sednu do auta a vyrazim, ale o otm, ze mi to nekdo musel schvalit a nebylo to jen tak.

Omezte porady na 30 max 45 minut. K osobnimu rizeni casu, moje zkusenost je , ze mezi 6 a 9 rano udelam praci za cely den pokud bych prisel az na 9

Zdravim,

urcite ne variantu c.2. tedy ukrajovat si z volneho casu a pocitat s tim jako s rezervou. Tohle je opravdu cesta do pekel, protoze pri takovem vytizeni pak znacne klesa produktivita. Jednoduse receno "to za to nestoji". Pro nektere lidi to muze byt i navykove, ve smyslu ze "jednou se prece nic nestane, budu vyjimecne pracovat i cely vikend". A pak je to porad.

Sledovat prubzne jak ty projekty bezi a necekat az nekde vznikne opravdovy prusvih a teprve ten pak resit, to uz je pak pozde. Nekdo to tu uz drive pojmenoval jako "komunikace". Ta komunikace by mela byt predevsim ucelna, ale ne byrokraticka (nevim jak to lepe popsat, ale snad je tomu rozumet). Typicky ve vetsich firmach sice stale organizuji ruzne meetingy a vyplnuji sheety, nicmene o skutecnem stavu veci casto moc nevedi. Tohle se vam v mensi firme jeste stat nemusi ;-)

Posledni vec co me napada je mit na ty nejdulezitejsi casti projektu spolehlive lidi, od kterych vite co muzete ocekavat a oni naopak jeste vidi vysledky sve prace. Obecne by mel projekty ridit nekdo, kdo se v danem oboru vyzna a drive v nem pracoval (napriklad programatory ridit clovek co nejaky cas uspesne programoval atd.), aby dokazal realne odhadnout co ti lide jeste mohou v danem case zvladnout a co uz ne. Tito u nas myslim obecne chybi a jsou suplovani tzv. univerzalnimi managery. Podle toho to pak vypada.

Mozna to neni prilis odborna odpoved, je z pohledu cloveka co sice projekty neridi, ale vidi jake ma to rizeni potom dopady ;-)