HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

Mindenki azt akarja, hogy a projektje sikeres legyen. Abban viszont nincs egyetértés, mit értünk sikeres projekt alatt.

Mindenki azt akarja, hogy a projektje sikeres legyen. Abban viszont nincs egyetértés, mit értünk sikeres projekt alatt.

E blog hasábjain már osztottam az észt arról, hogy mi a sikeres projekt receptje, anélkül, hogy tisztáztam volna, mit értünk sikeres projekt alatt.

Ez azért nagyon kérdés, mert ugye a sikeres projekt az, ahol előléptetést és bónuszt kapunk, ahol az ügyfél fizet, miközben a bukott projektért kötbér és kirúgás jár.


A legelső definíció ami eszembe jut: a projekt akkor sikeres, ha az ügyfél elégedett. Az ügyfél elégedettsége nyilván cél. De ezt így elég nehéz megfogni. Mi van, ha elkezdjük a projektet, és menet közben kiderül, hogy az ügyfélnek egész más kell, mint amit a charter-ben leírtunk? Mi van, ha pont azt szállítjuk le, amit a charter-ben ígértünk, de az ügyfélnek nem az kell? Mi van, ha az ügyfél nem is tudja, mi kell neki? Mi van, ha bikinis lányokat delegálunk a projektbe, akik meggyőzik az ügyfelet, hogy neki ez úgy jó ahogy van?

Elég sok itt a kérdés.

 

Nézhetjük „pénzügyes” szemüvegen át a kérdést: sikeres projekt az, amiért az ügyfél fizet, és bukott az, amiért nem fizet. Ezzel csak az a baj, hogy sok olyan projektet láttam, ahol sikerült „jól” megkötni a szerződést, és a szállító a nemteljesítésért is pénzt kapott. Sőt, ebből élt.

Nem is beszélve azokról a projektekről, amiket több fázisra bontanak, a beszállító az első fázis után elteszi az érte járó pénzt és soha nem akar második vagy harmadik fázist szállítani.

 

Ezek után nézhetjük „jogász” szemüvegen át a kérdést: legyen a projekt indulásakor egy szerződés és egy specifikáció, a projekt akkor van kész és akkor sikeres, ha ennek a specifikációnak 100%-ban megfelel. Itt rögtön adódik az az élethelyzet, hogy az ügyfél igényei menet közben változnak, de a projekt nem követi azokat. Vagy ha a beszállító a szerződésnek megfelelően szállít, csak abban nincs köszönet.

 

A Standish csoport közismert Chaos report-jában megpróbálja definiálni a sikeres projektet, és azt vizsgálja, hogy a projektek mekkora része sikeres. A Standish group szerint az a projekt sikeres, ami határidőre és az előírt költségeken belül szállítja az összes funkciót és szolgáltatást az eredeti specifikáció szerint. (A 2009-es Chaos report szerint csupán a projektek 32%-a sikeres)

Ez a definíció már nagyon jó, de nem elég jó. Ugyanis mi van, ha az ügyfél menet közben meggondolja magát és mást akar? Mi van, ha változik az üzleti környezet? Mi van, ha új megállapodást kötünk az ügyféllel?

 

A válasz ott van minden projektmenedzsment módszertanban. A projekt sikere papírforma szerint az, hogy határidőre, költségen belül leszállítja a tervezett funkciókat. A projekt nem más, mint a projekt terv végrehajtása. Azonban a projekt maga nem statikus, hanem egy élő dolog, emiatt nincs értelme az eredeti specifikációról beszélni. Ha változnak a körülmények, akkor meg lehet változtatni a specifikációt, a határidőt és a költségeket. Minden projektnek szükségszerű része a változás menedzsment. Ha a beszállító és az ügyfél megállapodik, hogy a határidőt kitolják, több erőforrást rakjanak a projektbe, de ezért cserébe a scope is megváltozzon, akkor ez az új cél, és e szerint kell a projektnek teljesítenie.

A sikeres projekt tehát az, ahol az aktuális megállapodásnak megfelelően határidőre és költségeken belül szállítja a funkciókat.

Ez egyrészt egy pontosan meghatározott, objektív és mérhető cél. És teljesíthető is – feltételezve azt, hogy a projekt megkapja az igényelt erőforrásokat.

Másrészt viszont rugalmasságot ad: lehet reagálni a piaci változásokra és az ügyfél igényeire. Amikor változtatni kell, akkor az ügyfél és a beszállító összeülnek és megváltoztatják a projektet.

Hol van itt az ügyfél elégedettség? Az ügyfél nyílván csak olyan változást fog elfogadni, ami neki kedvező. Ugye az ügyfél megoldásokat akar, amiért fizet. Ha többet akar az eredetileg megállapodottnál, akkor azért hajlandó többet fizetni. Ha a beszállító késik és ezért akarja a határidőt kitolni, azt nem kell elfogadnia.

Ugyanakkor a beszállítót sem éri hátrány, hiszen az ő hozzájárulása is kell a változtatáshoz. Közös megegyezésre és kompromisszumra van szükség, egy olyan helyzetben, ahol a megrendelőnek pénze van, a vállalkozó több munkát tud felajánlani.

Címkék: siker projekt sikertényező

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr605211852

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Ismeretlen_734488 2012.07.02. 16:43:31

Az okfejtés és a definíció tetszik, de egy fontos dolgot hiányolok, mégpedig az elvárt minőséget. Hiába kerül leszállításra a projekt határidőben és költségkereten belül, ha a használati értéke - és ebbe az esztétikai kérdéseket is beleértem - sérül. Az én fő szakmám az építőipar, ahol a minőség nagyon sok gondot jelent, de IT területén sem elhanyagolható, hogy egy rutin mennyire eszi a memóriát, stb, miközben a projekt célja időben és költségben megvalósul.
süti beállítások módosítása