managementul contractelor

23
Managementul contractelor

description

Managementul proiectelor software (cursuri si lab)

Transcript of managementul contractelor

Page 1: managementul contractelor

Managementul contractelor

Page 2: managementul contractelor

1. Tipuri de contractResursele externe cerute pot fi sub formă de servicii. Un exemplu simplu ar fi folosirea unei echipe temporare la contracte de durată mică, în vederea îndeplinirii anumitor sarcini.

Pe de altă parte, contractul poate fi încheiat pentru livrarea unei aplicaţii software complete.

Acesta poate fi:

• bespoke system (sistem comandat), i.e. un sistem care e creat de la zero, special pentru un client;

• off-the-shelf (gata pentru cumpărare), pe care îl cumperi ca atare (“as is”) –uneori se mai numeşte shrink-wrapped software;

• customized off-the-shelf (COTS) software – acesta este basic core system, care e modificat pentru a îndeplini cerinţele unui anumit client.

Obs. Livrarea unui echipament, conform legii din Anglia, poate fi privită ca un contract pentru livrarea de bunuri. Livrarea de software poate fi privită ca oferirea unui serviciu (pentru scrierea software-ului) sau ca acordarea unei licenţe pentru folosirea software-ului. Aceste disticţii au implicaţii legale.

Page 3: managementul contractelor

O altă clasificare a contractelor este d.p.d.v. al modalităţii de plată către

furnizori:

• contracte cu preţ fixat;

• contracte de timp şi materiale;

• contracte cu preţ fixat per unitatea livrată.

Page 4: managementul contractelor

Contracte cu preţ fixat

Preţul e fixat atunci când se semnează contractul. Clientul ştie că dacă nu

există schimbări în termenii contractului, preţul pe care-l va plăti este cel

consemnat în contract.

În acest caz trebuie ca analiza cerinţelor să fi avut deja loc. Odată începutî

dezvoltarea, clientul nu-şi poate schimba cerinţele fără să negocieze preţul

contractului.

Page 5: managementul contractelor

Avantajele acestei metode sunt:

• Cheltuielile clientului cunoscute;

• Motivarea furnizorului;

Dezavantajele acestei metode sunt:

• Preţuri mai mari pentru a permite eventualele lucruri neprevăzute. Furnizorul adaugă o marjă la calcularea preţului tocmai pentru a reduce riscul apariţiei unor situaţii neprevăzute;

• Dificultăţi în modificarea cerinţelor;

• O presiune upward asupra costului schimărilor. În competiţi cu alţi furnizori, furnizorul va încerca să ofere un preţ cât mai scăzut. Dacă, odată contractul semnat, e nevoie de schimbări ale cerinţelor, furnizorul e în poziţia forte de a cere un preţ mai mare pentru aceste schimbări;

• Ameninţare la calitatea sistemului. Nevoia de a menţine un preţ fixat poate duce la deteriorarea calităţii sistemului.

Page 6: managementul contractelor

Contracte de timp şi materiale

Clientul e taxat la o valoare fixă pentru unitatea de efort (de exemplu, oră echipă). La începutul contractului, furnizorul oferă o estimare a costului, bazată pe înţelegerea cerinţelor utilizatorului, dar aceasta nu e baza pentru plata finală.

Avantajele acestei metode sunt:

• Uşurinţa în a schimba cerinţele;

• Lipsa presiunii preţului;

Dezavantajele acestei metode sunt:

• Handicapul clientului. Clientul e cel care se va înfrunta cu toate riscurile asociate cu cerinţe vag definite sau care se schimbă;

• Lipsa motivaţiei pentru furnizor. Furnizorul nu are motivaţie să lucreze într-o manieră care să încurajeze economia costurilor.

Page 7: managementul contractelor

Contracte cu preţ fixat per unitatea livrată (preţ unitar fixat)

Acesta e asociat cu function point (FP) counting. Mărimea sistemului care urmează să fie livrat e calculată sau estimată la începutul proiectului. Mărimea sistemului trebuie să fie estimată în linii de cod, dar FPs pot fi derivate cu uşurinţă de la documentaţia cerinţelor. E stabilit preţul per unitate. Preţul final va fi preţul unitar înmulţit cu numărul de unităţi.

Exemplu. Tabelul de mai jos arată o astfel de estimare a preţurilor (tabel preluat din Garmus, Herron, Measuring The Software Process, 1996)

Dacă sistemul conţine 2600 FPs, costul total va fi:2000x967+500x1019+100x1058

Page 8: managementul contractelor

Avantajele acestei metode sunt:• Înţelegerea din partea clientului. Clientul poate vedea cum e calculat preţul;• Uşurinţa de a face comparaţii. Preţurile stabilite pot fi comparate;• Emerging functionality. Furnizorul nu-şi asumă riscul funcţionalităţii în creştere.• Eficienţa furnizorului. Furnizorul are încă motivaţia să livreze sistemul la funcţionalitatea cerută.• Lyfe cycle range. Cerinţele nu trebuie specificate în forma finală la început. Contractul poate acoperi atât etapa de analiza, cât şi etapa de design.Dezavantajele acestei metode sunt:• Dificultăţi cu măsurarea dimensiunii software-ului. Numărul de linii de cod poate fi mărit folosind un stil de codare “bombastic”. Folosirea regulilor de numărare a FPs poate favoriza furnizorul sau clientul. Soluţia ar fi să fie angajat un independent FP counter (numărător independent al FPs);• Schimbarea cerinţelor. Anumite cerinţe pot afecta drastic tranzacţiile, dar nu se adaugă la numărrea globală a FPs. O schimbare a cerinţelor făcută târziu în ciclul de dezvoltare va necesita aproape sigur mai mult efort pentru implementare decât dacă s-ar produce mai devreme.

Page 9: managementul contractelor

O altă clasificare a contractelor (conform regulilor din Uniunea Europeană) se face în legătură cu abordarea care e folosită pentru selectarea contractorului:

• deschisă (open);

• restricţionată (restricted);

• negociată (negociated).

Open tendering process

În acest caz, orice furnizor poate face o ofertă pentru furnizarea de bunuri şi servicii. Mai mult, toate ofertele care sunt în conformitate cu condiţiile originale din invitation to tender trebuie să fie considerate şi evaluate în acelaşi mod ca celelalte. La un proiect major, unde există o mulţime de oferte şi procesul de evaluare e consumator de timp, acest mod poate fi scump.

Page 10: managementul contractelor

Restricted tendering process

În acest caz, sunt oferte doar de la furnizorii care au fost invitaţi de client. Spre deosebire de open tendering process, clientul poate în orice moment să reducă numărul furnizorilor potenţiali. Este în mod uzual cea mai bună abordare. Există totuşi riscuri: acolo unde contractul rezultant e la un preţfixat, clientul îşi asumă responsabilitatea pentru corectitudinea şi completarea cerinţelor specificate furnizorilor.

Negociated procedure

Sunt situaţii când procesul de ofertare restricţionată nu e cel mai potrivit.

În aceste cazuri, se poate justifica abordarea unui singur furnizor, caz în care clientul poate fi acuzat de favoritisme.

Page 11: managementul contractelor

2. Etape în definitivarea contractelor

Analiza cerinţelor

Înaninte de abordarea furnizorului, trebuie să fie specificate clar cerinţele. Documentarea cerinţelor trebuie sp aibă, în mod tipic, secţiuni de forma celor arătate în tabelul de mai jos (un asemenea document se numeşte uneori operational requirement sau OR):

Page 12: managementul contractelor

Cerinţele definesc cu grijă funcţiile care necesită să fie duse la bun sfârşit de noua aplicaţie şi toate intrările(inputs) şi ieşirile(outputs) necesare pentru aceste funcţii.

Cerinţele trebuie de asemenea să declare orice standard cu care trebuie să fie conforme şi sistemele cu care noul sistem să fie compatibil.

Sunt necesare de asemenea cerinţe operaţionale şi de calitate (vezi capitolul despre Calitatea produselor software).

Cerinţele obligatorii (mandatory) trebuie să fie îndeplinite. Dacă o propunere nu îndeplineşte obligatorie, atunci propunerea va fi respinsă.

Dacă cerinţa e dezirabilă (desirable), dar nu obligatorie, atunci propunerea poate fi acceptată din acest punct de vedere, dar trebuie ca alte aspecte ale propunerii să compenseze acest neajuns.

Page 13: managementul contractelor

Planul de evaluare (evaluation plan)

Odată specificată lista de cerinţe, trebuie schiţat planul despre cum va fi evaluată propunerea. Pentru o aplicaţie off-the-shelf, sistemul însuşi va fi evaluat.

Invitaţia la ofertă (invitation to tender)

După analiza cerinţelor şi producerea planului de evaluare, e posibilă etapa de a invita posibilii furnizoti să facă o ofertă. În esenţă, această invitaţie trebuie însoţită de o scrisoare, în care să se ofere diverse informaţii: cum va fi tratată legal oferta, care este termenul limită pentru prezentarea ofertei etc.

Abordările privind această etapă nu sunt unitare în diverse ţări, de aceea recomandăm consultarea normelor legale pentru fiecare ţară.

Page 14: managementul contractelor

Evaluarea propunerilor

Procesul de evaluare trebuie făcut metodic şi planificat şi ar putea include:

• examinarea atentă a documentelor propunerii;

• intervievarea reprezentanţilor furnizorilor;

• demonstraţii;

• examinări ale site-urilor;

• teste practice.

Documentele propunerii oferite de furnizori pot fi examinate pentru a vedea dacă conţin toate elementele ce satisfac cerinţele originale. Se pot cere anumite clarificări asupra unor puncte ale propunerii.

Orice declarare factuală făcută de furnizor presupune o angajare legală din partea lui dacă influenţează cumpărătorul să ofere contractul acelui furnizor.

Cumpărătorul poate lua iniţiativa de a păstra note ale întâlnirilor şi de scrie apoi furnizorului pentru a obţine confirmarea asupra acurateţii lor.

Furnizorul poate, în finalul documentului contractului, să încerce să excludă orice angajare la orice reprezentaţii făcute în negocierile precontract.

Page 15: managementul contractelor

Când produsul livrat se bazează pe un produs existent, e posibil să vadă o demonstraţie. Un pericol cu demonstraţiile este acela că sunt controlate de furnizor. De aceea, clientul ar trebui să facă o planificare a lucrurilor pe care doreşte să le vadă în demonstraţie, asigurându-se astfel că toate elementele importante sunt văzute.

Cu un software off-the-shelf, e posibil să avem acces concret la aplicaţie. De exemplu, o versiune demonstrativă poate fi valabilă (de genul celor care după 39 zile nu mai sunt valabile). E nevoie de un plan de test, care să ne asigure ca sunt evaluate caracteristicile importante.

O problemă frecventă este aceea că în timp ce o aplicaţie existentă lucrează bine pe o anumită platformă, nu lucrează mulţumitor pe platforma clientului. În acest caz sunt mai utile examinările unor site-uri operaţionale care folosesc sistemul.

Page 16: managementul contractelor

3. Termenii tipici ai unui contract

E nevoie să schiţăm anumite arii majore asupra cărora trebuie să ne concentrăm:

Definiţii

S-ar putea ca terminologia folosită în documentul contractului să fie definită, de exemplu ce se înţelege prin “client” şi “furnizor”.

Forma înţelegerii

De exemplu, e contract de vânzare, de leasing sau licenţă? De asemenea, poate subiectul unui contract, cum ar fi licenţa pentru utilizare unei aplicaţii software, poate fi transferată unei terţe părţi?

Bunuri şi servicii furnizate

Echipament şi software. Include o listă concretă a pieselor individuale de echipament care vor fi livrate.

Page 17: managementul contractelor

Servicii. Acestea acoperă lucruri ca:

• instruire;

• documentare;

• instalare;

• conversia fişierelor existente;

• mentenanţă;

• măsuri de asigurare temporare.

Proprietarul software-ului

Două chestiuni apar: mai întâi, poate clientul să vândă software-ul la alţii şi a doua dacă furnizorul poate vinde software-ul la alţii.

Când un software e scris special pentru un client, clientul va dori probabil să-şi asigure exclusivitatea, de exemplu prin cumpărarea copyright-ului sau prin specificarea în constract că foloseşte exclusiv software-ul.

Page 18: managementul contractelor

Mediul (environment)Când trebuie instalat echipamentul fizic, trebuie specificată linia de demarcaţie dintre responsabilităţile furnizorului şi clientului cu privire la lucruri cum ar fi furnizarea de energie. Când software-ul e furnizat, trebuie confirmată compatibilitatea cu hardware-ul existent şi sistemul de operare existent.

Angajamentele clientuluiClientul trebuie să asigure accomodation pentru furnizori şi probabil alte facilităţi (internet, linie telefonică etc).

Proceduri de acceptareUn sistem va fi acceptat numai după a trecut de testele de acceptare. O parte a contractului va specifica detalii ca timpul pe care-l are clientul să facă testele, deliverables de care depind testele de acceptare şi procedura pentru semnare atunci când testarea e completată.

Standarde

Clientul poate cere furnizorului dovada că diverse standarde sunt respectate.

Page 19: managementul contractelor

Managementul proiectului şi al calităţii

Contractul trebuie să ceară ca standardele din seria ISO-9000 să fie îndeplinite, ca şi ISO 12207 (de exemplu).

Planificarea

Oferă o planificare a timpului în care trebuie completate părţile cheie ale proiectului. Această planificare va obliga atât clientul, cât şi furnizorul. De exemplu, furnizorul poate si în stare să instaleze software-ul la o dată convenită numai dacă clientul face platforma hardware disponibilă.

Preţul şi metoda de plată

În contract trebuie stabilit preţul şi modalitatea de plată.

Cerinţe legale diferite

În contract pot fi specificate ce condiţii se aplică la subcontractarea muncii, obligaţia pentru daune către o terţă parte şi liquidated damages.

Liquidated damages sunt estimatori ai pierderilor financiare pe care clientul le suferă dacă furnizorul a eşuat în obligaţiile pe care şi le-a asumat.

Page 20: managementul contractelor

4. Managementul contractului

La anumite puncte de decizie, clientul are nevoie să examineze munca deja

făcută şi să ia decizii despre direcţia viitoare a proiectului.

Proiectul va necesita ca reprezentanţi ai clientului şi furnizorului să

interacţioneze în multe puncte ale ciclului de dezvoltare.

Această interacţiune, sau alţi factori externi, conduc(e) de obicei la

necesitatea unor schimbări.

Pentru fiecare punct de decizie, trebuie să fie definite deliverables ce

urmează să fie prezentate de furnizori şi toate output-urile.

Page 21: managementul contractelor

Odată contractul încheiat, trebuie avută în vedere calitatea muncii. Standardul ISO 12207 oferă printre altele posibilitatea existenţei unor agenţi, angajaţi independent de client sau furnizor, care se vor duce la bun sfârşit verificarea, validarea şi asigurarea calităţii.

Pe măsură ce sistemul se dezvoltă, apare uneori nevoia unor schimbări în

cerinţe, care pot duce la modificarea termenilor contractului. Va fi nevoie

deci de o procedură de control al schimbărilor, care să înregistreze cerinţele

pentru schimbări, împreună cu acordul furnizorului şi eventualele costuri

suplimentare necesare pentru munca în plus.

Clientul, pe de altă parte, trebuie să se asigure că în contract se specifică şi

felul cum sunt tratate situaţiile în care furnizorul nu respectă una sau mai

multe obligaţii legale.

Page 22: managementul contractelor

5. Acceptarea

Când munca e terminată, clientul trebuie să înceapă activitatea legală pentru realizarea testării de acceptare (acceptance testing). Contractul poate stabili o dată limită pentru cât poate dura testarea, astfel încât clientul să poată face testarea înainte de expirarea timpului, în vederea corectării problemelor ridicate.

O parte a plăţii sau chiar toată plata va depinde de testul de acceptare. Uneori o parte a plăţii finale va fi reţinută pentru perioada rulare operaţională şi va fi plătită dacă nivelul de fiabilitate este conform specificaţiilor contractate. Există de obicei o perioadă de garanţie, în timpul căreia furnizorul poate pune la punct orice eroare apărută. Probabil că furnizorul poate cere o perioadă de garanţie mai mică (30 zile, de exemplu), în timp ce clientul ar încerca să ducă perioada de garanţie până spre 120 zile, de exemplu (aceste valori sunt orientative, dar pot fi întâlnite adesea în realitate).

Page 23: managementul contractelor

Concluzii

Câteva dintre punctele cheie din acest capitol pot fi astfel rezumate:

• contractarea cu succes necesită timp important;

• e mai uşor să se obţină concesii din partea furnizorului înainte de semnarea contractului decât după;

• un contract va stabili obligaţii şi pentru client, şi pentru furnizor;

• negocierea contractului va include înţelegerea asupra managementului relaţiei dintre furnizor şi client în timpul executării proiectului.