Managementul proiectelor software

Oliviu Matei October 15, 2008

Contents

1 Introducere 1.1 Caracteristici . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Potentiale riscuri . . . . . . . . . . . . . . . . . . 1.2 Triple Constraints . . . . . . . . . . . . . . . . . . . . . . 1.3 Project Lifecycle . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Project Initiation . . . . . . . . . . . . . . . . . . 1.3.2 Project Planning . . . . . . . . . . . . . . . . . . 1.3.3 Project Execution . . . . . . . . . . . . . . . . . . 1.3.4 Project Closure . . . . . . . . . . . . . . . . . . . 1.4 Probleme comune in proiectele software . . . . . . . . . . 1.4.1 Probleme identicate n organizarea proiectelor . . 1.4.2 Probleme identicate n planicarea proiectelor . . 1.4.3 Probleme identicate n controlul proiectelor . . . 1.4.4 Probleme identicate n managementul calitatii . . 1.4.5 Probleme identicate n managementul schimbarilor si al conguratiilor . . . . . . . . . . . . . . . 1.4.6 Probleme identicate n managementul riscului . . 1.4.7 Concluzii . . . . . . . . . . . . . . . . . . . . . . i

1 3 6 7 9 9 12 17 21 26 27 29 30 32 33 34 35

Contents 2 Project Planning 2.1 Introduction . . . . . . . . . . . . . . . . . . 2.2 Gantt . . . . . . . . . . . . . . . . . . . . . 2.3 PERT and CPM . . . . . . . . . . . . . . . 2.3.1 PERT . . . . . . . . . . . . . . . . . 2.3.2 CPM . . . . . . . . . . . . . . . . . . 2.3.3 PERT vs. CPM . . . . . . . . . . . . 2.3.4 Avantajele metodelor PERT si CPM 2.3.5 Utlizarea metodelor PERT si CPM . 2.4 Dependencies . . . . . . . . . . . . . . . . . 2.5 The wrong choice . . . . . . . . . . . . . . . 2.6 Managing Probabilities . . . . . . . . . . . . 2.7 Summary . . . . . . . . . . . . . . . . . . . 37 37 38 40 40 41 42 42 43 51 51 53 54 57 57 58 60 64 65 65 66 68 68 71 71 72 74 74 76 77 77

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

3 Managementul calitatii 3.1 Introducere . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Calitatea produselor software particularitati . . . . . . . 3.3 Principii de proiectare a proceselor de dezvoltare software 3.4 Conceptul de software corespunzator pentru utilizare . . 3.5 Costul calitatii . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Cost of Quality: Appraisal vs. Failure Costs . . . 3.5.2 Leveraging Appraisal to Reduce Failure Costs . . 3.5.3 Being In Control . . . . . . . . . . . . . . . . . . 3.6 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Managementul riscului 4.1 Introduction . . . . . . . . . . . . . . . . . . . 4.2 Project Management Metrics . . . . . . . . . . 4.3 Risk Management Survey . . . . . . . . . . . 4.3.1 Barry Boehm . . . . . . . . . . . . . . 4.3.2 Richard Fairley . . . . . . . . . . . . . 4.3.3 F/A-18E/F Risk Management Process 4.3.4 Rockwell Risk Management Process . . ii

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Contents 4.4 4.5 4.6 Where Risk Management and Metrics Overlap . . . . . . Selecting a Sample Measure . . . . . . . . . . . . . . . . Sample Metric Discussion . . . . . . . . . . . . . . . . . 4.6.1 Identifying Risks with Metrics . . . . . . . . . . . 4.6.2 Tracking Risks with Metrics . . . . . . . . . . . . A Sample Risk Management Standard . . . . . . . . . . 4.7.1 Introduction . . . . . . . . . . . . . . . . . . . . . 4.7.2 Risk Management . . . . . . . . . . . . . . . . . . 4.7.3 Risk Assessment . . . . . . . . . . . . . . . . . . 4.7.4 Risk Analysis . . . . . . . . . . . . . . . . . . . . 4.7.5 Risk Evaluation . . . . . . . . . . . . . . . . . . . 4.7.6 Risk Reporting and Communication . . . . . . . . 4.7.7 Risk Treatment . . . . . . . . . . . . . . . . . . . 4.7.8 Monitoring and Review of the Risk Management Process . . . . . . . . . . . . . . . . . . . . . . . 4.7.9 The Structure and Administration of Risk Management . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 78 78 80 80 82 85 85 86 90 91 96 96 99 100 101 105 107 107 107 108 108 110 111 112 113 114 115 117 119 120

4.7

4.8

5 Managementul echipei de proiect 5.1 Organizing a Team Project . . . . . . . . . . . . . 5.1.1 Organizing a Project Team . . . . . . . . . 5.1.2 Assessing Internal Skills . . . . . . . . . . 5.1.3 Experience Is the Best Barometer . . . . . 5.1.4 Resumes and Skill Assessments . . . . . . 5.1.5 Create a Roles and Responsibilities Matrix 5.2 Learning Is Hard Work . . . . . . . . . . . . . . . 5.2.1 Creating a Team . . . . . . . . . . . . . . 5.2.2 Dening Project Manager Power . . . . . 5.2.3 Hello! My Name Is . . . . . . . . . . . . . 5.3 Where Do You Live? . . . . . . . . . . . . . . . . 5.3.1 Building Relationships . . . . . . . . . . . 5.3.2 Interviewing Potential Team Members . . iii

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

Contents 5.3.3 Why You Need Interviews . . . . . . . . . How to Interview . . . . . . . . . . . . . . . . . . 5.4.1 Managing Team Issues . . . . . . . . . . . 5.4.2 Dealing with Team Disagreements . . . . . Phases of Team Development . . . . . . . . . . . 5.5.1 Project Management Is Not a Democracy 5.5.2 Dealing with Personalities . . . . . . . . . Use Experience . . . . . . . . . . . . . . . . . . . 5.6.1 Disciplining Team Members . . . . . . . . 5.6.2 Following an Internal Process . . . . . . . 5.6.3 Removal from a Project . . . . . . . . . . 5.6.4 Using External Resources . . . . . . . . . 5.6.5 Finding an Excellent IT Vendor . . . . . . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 121 124 124 127 128 130 131 133 133 134 134 135 137

5.4

5.5

5.6

5.7

6 Managementul comunicarii in cadrul proiectului 139 6.1 Comunicarea in lumea virtuala . . . . . . . . . . . . . . 139 6.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . 139 6.1.2 Open and Eective Communication . . . . . . . . 140 6.1.3 Communication Challenges with Virtual Teams . 141 6.1.4 Diminished Informal Communications . . . . . . . 142 6.1.5 Fewer Nonverbal Communication Clues . . . . . . 142 6.1.6 Increased Reliance on Asynchronous Communications . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.1.7 Increased Impact of Cultural Implications . . . . 143 6.1.8 Raising and Resolving Conicts . . . . . . . . . . 144 6.1.9 Guidelines for Consideration to Promote Eective Communications . . . . . . . . . . . . . . . . . . 145 6.1.10 Summary . . . . . . . . . . . . . . . . . . . . . . 149 7 Managementul schimbarii 151 7.1 What is Change Management? . . . . . . . . . . . . . . . 151 7.1.1 The Task of Managing Change . . . . . . . . . . 151 iv

Contents 7.1.2 An Area of Professional Practice . . . . . . . . . 7.1.3 A Body of Knowledge . . . . . . . . . . . . . . . 7.1.4 A Control Mechanism . . . . . . . . . . . . . . . 7.1.5 Content and Process . . . . . . . . . . . . . . . . The Change Process . . . . . . . . . . . . . . . . . . . . 7.2.1 The Change Process as Unfreezing, Changing and Refreezing . . . . . . . . . . . . . . . . . . . . . . 7.2.2 The Change Process as Problem Solving and Problem Finding . . . . . . . . . . . . . . . . . . . . . 7.2.3 The Change Problem . . . . . . . . . . . . . . . . 7.2.4 Change as a How Problem . . . . . . . . . . . . . 7.2.5 Change as a What Problem . . . . . . . . . . . . 7.2.6 Change as a Why Problem . . . . . . . . . . . . . 7.2.7 The Approach taken to Change Management Mirrors Managements Mindset . . . . . . . . . . . . Skills and Strategies . . . . . . . . . . . . . . . . . . . . 7.3.1 Political Skills . . . . . . . . . . . . . . . . . . . . 7.3.2 Analytical Skills . . . . . . . . . . . . . . . . . . . 7.3.3 People Skills . . . . . . . . . . . . . . . . . . . . . 7.3.4 System Skills . . . . . . . . . . . . . . . . . . . . 7.3.5 Business Skills . . . . . . . . . . . . . . . . . . . . 7.3.6 Four Basic Change Management Strategies . . . . 7.3.7 Factors in Selecting A Change Strategy . . . . . . 7.3.8 One More Time: How do you manage change? . . 152 152 153 154 155 155 155 156 157 158 158 160 162 162 162 163 164 165 165 166 167 169 169 169 170 171 172 173 174

7.2

7.3

8 Decision Theory 8.1 What is decision theory? . . . . . . . . . . . . . . . 8.1.1 Relations and numbers . . . . . . . . . . . . 8.1.2 The comparative value terms . . . . . . . . 8.1.3 Using preferences in decision-making . . . . 8.1.4 Numerical representation . . . . . . . . . . . 8.1.5 Using utilities in decision-making . . . . . . 8.2 The standard representation of individual decisions v

. . . . . . .

. . . . . . .

. . . . . . .

Contents 8.2.1 Alternatives . . . . . . . . . . . . . 8.2.2 Outcomes and states of nature . . . 8.2.3 Decision matrices . . . . . . . . . . 8.2.4 Information about states of nature Expected Utility . . . . . . . . . . . . . . 8.3.1 What is expected utility? . . . . . . 8.3.2 Objective and subjective utility . . 8.3.3 Appraisal of EU . . . . . . . . . . . 8.3.4 Probability estimates . . . . . . . . Variations of expected utility . . . . . . . . 8.4.1 Process utilities and regret theory . 8.4.2 Prospect theory . . . . . . . . . . . Social decision theory . . . . . . . . . . . . 8.5.1 The basic insight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 176 177 178 179 179 180 182 185 187 187 189 191 192 195 197 198 198 199

8.3

8.4

8.5

9 Project Closure 9.1 Project evaluation . . . . . . . . . . . . . 9.1.1 Evaluation against success criteria 9.1.2 Preparing the completion report . 9.1.3 Review and approval . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

10 Concluzii 201 10.1 Viitorul apartine organizatiilor centrate pe proiecte . . . 201 10.2 9 lucruri de tinut minte . . . . . . . . . . . . . . . . . . . 203

vi

Chapter 1

Introducere
O denitie simpla a proiectului este urmatoarea: proiectul reprezinta un efort temporar depus pentru a crea, cu resurse limitate, un produs unic sau un serviciu unic1. Alta denitie, apropiata de aceasta, subliniaza ca sub denumirea de proiect sunt reunite o serie de activitati interdependente, care se deruleaza potrivit unui plan pentru a atinge un anumit obiectiv/pentru a obtine anumite rezultate ntr-o perioada de timp bine delimitata; activitatile din cadrul proiectului nceteaza n momentul n care obiectivul respectiv a fost atins(@@@ cite de gasit ceva). Denitiile mai noi ale proiectelor evidentiaza faptul ca acestea sunt esentiale pentru a-tingerea obiectivelor strategice/de dezvoltare ale unei organizatii; proiectele reprezinta, de fapt, modalitatea prin care este implementata strategia de dezvoltare a unei organizatii. O buna planicare a dezvoltarii organizatiei ofera raspuns la cteva ntrebari esentiale: Ce se va schimba? De ce este necesara schimbarea? Cnd va avea loc schimbarea? Cum se va realiza schimbarea? Ct costa si cum este nantata schimbarea? Cine si asuma responsabilitatea pentru schimbare? Cui apartin rezultatele n urma schimbarii? 1

CHAPTER 1. INTRODUCERE Managementul proiectelor reprezinta utilizarea unui set de cunostinte, competente, deprinderi, instrumente si tehnici specice n vederea ndeplinirii obiectivelor generale si specice ale unui proiect anume. Scopul managementului proiectelor l reprezinta obtinerea unui anumit rezultat, respectnd constrngerile nanciare, de timp, de calitate si cele de natura tehnica impuse proiectului. ntrebarile cele mai frecvente la care managementul proiectelor trebuie sa ofere raspuns sunt urmatoarele: Ct va dura proiectul? ntrzierea unei anumite activitati/a unui set de activitati va provoca ntrzierea ntregului proiect? Resursele puse la dispozitie sunt suciente pentru a putea respecta planicarea initiala? In mod frecvent, proiectele sunt mpartite n componente - subproiecte - pentru a putea mai usor administrate. Subproiectele sunt de multe ori subcontractate catre terti -e ca este vorba despre o entitate exterioara organizatiei sau despre un departament al organizatiei respective care initial nu era planicat sa participe n proiect. Va prezentam, n continuare, cteva exemple de proiecte: lansarea pe piata a unui nou produs sau serviciu; ocuparea unei nise noi pe piata; modernizarea unei ntreprinderi; construirea sau modernizarea unui spital; modicarea ortranitrramei sau schimbarea stilului de lucru ntr-o organizatie; implementarea unui nou sistem informational ntr-o organizatie; construirea unui obiectiv (cladire, centrala electrica, autostrada, cale ferata, baraj); derularea unei campanii electorale; schimbarea grilei de programe la un post de televiziune; 2

1.1. CARACTERISTICI realizarea unui lm; activitatea de cercetare cu un obiectiv bine delimitat (n domeniul stiintelor socio-umane sau n domeniul stiintelor exacte); punerea pe picioare a unei ntreprinderi agricole sau zootehnice; schimbarea modului n care se deruleaza uxul comunicatonal si informational ntr-o organizatie; nintarea unui ziar; modernizarea procesului educational ntr-o universitate5

1.1

Caracteristici

Exista cteva cuvinte cheie n modul de denire a proiectelor, e ca este vorba despre proiecte de anvergura sau despre proiecte care se deruleaza la o scara redusa: 1. timp limitat: nceputul si sfrsitul proiectului sunt bine delimitate; 2. echipa de proiect ad hoc; 3. obiective precise, clar formulate; 4. rezultate concrete, masurabile, unice; 5. plan riguros; 6. activitati interdependente, interconditionate; 7. resurse limitate: resurse nanciare (buget stabilit dinainte), resurse umane, echipamente, dotari, sedii, materii prime si materiale, informatie; 8. strategie de dezvoltare. 3

CHAPTER 1. INTRODUCERE Iata n continuare cteva precizari n legatura cu ingredientele care intra n compozitia oricarui proiect. Determinantul temporar din prima denitie nseamna, asa cum am aratat, ca proiectul are un nceput si un sfrsit strict delimitate. Aceasta caracteristica reecta faptul ca proiectele sunt caracterizate de exibilitate si au o capacitate mai mare de a exploata, la timp, nisele de pe piata. In plus, temporar reecta si faptul ca echipa de proiect se desinteaza dupa ce proiectul a fost declarat nchis (vezi n continuare). Temporar nu nseamna, nsa, scurt, deoarece unele proiecte pot dura ani de zile. De asemenea, trebuie subliniat ca determinantul temporar nu se aplica produselor si serviciilor care rezulta n urma proiectului, ci efortului depus pentru a le realiza. Deci, temporar, n cazul unui proiect, nu este totuna cu trecator, efemer. Pentru ca un proiect sa e ntradevar reusit, trebuie ca produsele si serviciile sale sa e caracterizate de durabilitate, sa aiba capacitatea de a rezista dupa ncheierea sa ociala. Proiectul nu beneciaza de un sta permanent, echipa de proiect este creata ad hoc, implicarea n proiect a membrilor echipei este, si ea, temporara. Rolurile pe care le ndeplinesc acestia nu sunt xe, ceea ce da nastere unei mai mare exibilitati, dar poate constitui si o sursa de pericole (vezi mai jos). Din acest motiv, managementul resurselor umane si managementul abilitatilor angajatilor sunt mult mai importante dect n activitatea normala de management a unei organizatii. Prima denitie a proiectului expusa anterior arata ca rezultatele proiectului sunt unice. Acest lucru trebuie nteles n sensul ca produsele si serviciile rezultate au o nota distinctiva fata de toate celelalte produse sau servicii ale organizatiei care deruleaza proiectul; includ un element de inovatie, de noutate, din punctul de vedere al calitatii, al modalitatii de realizare, al abordarii, al publicului caruia i sunt destinate, al regiunii geograce n care sunt lansate etc. Rezultatele proiectului trebuie sa aiba aceste caracteristici de noutate n raport cu orice alt proiect asemanator. Unicitatea se pastreaza chiar si cnd este vorba, spre exemplu, de un proiect care a fost derulat n alta tara si care ar urma sa aiba loc, n forma foarte apropiata, si n Romnia. Faptul ca localizarea, publicul, mediul 4

1.1. CARACTERISTICI social si cultural sunt altele antreneaza modicari n ceea ce priveste activitatile, anticiparea si evaluarea impactului etc. Planul redactat riguros si detaliat este cel mai important lucru ntr-un proiect (vezi si n continuare). Un plan bun poate supravietui unei idei de proiect obisnuite, chiar mediocre. Dar o idee stralucita de proiect este probabil sa esueze daca planul este gresit. Daca planul nu este redactat riguros, pe hrtie, e ca si cum nu ar exista. In ceea ce priveste resursele utilizate ntr-un proiect, acestea includ: oameni; fonduri; echipamente; materii prime si materiale; sedii; informatie. Pentru a avea o vedere mai sistematizata asupra tipurilor de resurse, prezentam urmatoarea clasicare: resurse hard si resurse soft. La rndul lor, resursele hard se mpart n: resurse zice - terenuri, cladiri, echipamente, materii prime si materiale; resurse nanciare - bani, credite, instrumente nanciare. Ct priveste resursele soft, acestea includ: resurse umane - oameni, abilitati, competente, cunostinte; resurse intangibile - informatie, imagine de marca, reputatie, prestigiu. 5

CHAPTER 1. INTRODUCERE Nici una dintre aceste resurse nu trebuie privita ca ind superioara alteia si, n consecinta, nici una nu trebuie neglijata sau uitata. Reusita unui proiect se masoara si n functie de echilibrul, armonia stabilite ntre toate aceste tipuri de resurse. De multe ori, exista tendinta ca atentia sa e concentrata exclusiv pe respectarea termenelor limita si a bugetului. Dar, daca la terminarea proiectului, echipamentele sunt deteriorate (ca urmare a utilizarii excesive), iar oamenii sunt epuizati, succesul este doar partial.

1.1.1

Potentiale riscuri

Natura temporara a proiectului prezinta, asa cum am anticipat, si cteva provocari/ potentiale riscuri: oamenii care au fost desemnati sa faca parte din echipa de proiect au si alte activitati de desfasurat, alte sarcini de ndeplinit, e n cadrul altor proiecte, e n cadrul muncii de rutina specice organizatiei respective; membrii echipei de proiect este posibil sa nu mai lucrat mpreuna, au stiluri de lucru diferite, abordari diferite; n plus, exista situatii cnd rapiditatea cu care trebuie asamblata echipa de proiect nu le mai permite membrilor acestora sa dezvolte spiritul de echipa, sa construiasca ncrederea reciproca, sa si armonizeze stilurile de lucru; autoritatea asupra membrilor echipei de proiect este mai difuza: ea este mpartita ntre managerul functional (directorul executiv al organizatiei sau al unui departament) si managerul de proiect; acesta din urma nu are la dispozitie instrumentele de motivare aate la dispozitia managerului functional, precum cresteri salariale, aprecieri ale muncii depuse, propuneri de avansare; managerul de proiect poate face apel la acestea, dar indirect, tot prin intermediul managerului functional. 6

1.2. TRIPLE CONSTRAINTS

1.2

Triple Constraints

There are three factors in product development that remain in constant tension: cost, quality, and time (gure 1.1). For the sake of this discussion, quality shall mean the number of features a product is to have, and their depth, usability, and polish

Figure 1.1: The three constraints of a project The cost of a given project is usually computed by enumerating its features, and the time it will take to implement them. Likewise, the number of features and their depth of quality and usability are limited by nances and time. The amount of time a project will take is a direct result of the feature set, and the amount of money the company is willing to spend. Since these factors have a direct relationship, when you attempt to adjust any one of them, the other two feel the eect. You cant reduce the cost without sacricing features or deadlines. You cant increase features without incurring extra costs and time spent. You cant reduce time to meet a market window without reducing features or increasing costs. Decision makers have an unsavory habit of trying to own all three factors, leaving product developers to make bricks without straw. When 7

CHAPTER 1. INTRODUCERE decision makers dictate the cost, the feature set, and the market window, developers are left to try to make it all t but without any of the controlling factors under their power. Oftentimes decision makers dont have all the information available to dictate these three factors, but attempt to do it anyway. Developers know this, and it leaves them in a disgruntled state. The assertion that those morons in management dont have a clue is a common complaint. Sometimes it comes from this issue. Everyone likes to control the cost factor because it is the easiest one to see the eect on bottom-line protability. Product features and time windows are less tangible and require work to make the connection. Product features are most important to people closest to customers because solving their needs makes them happy and results in good bonuses. If our product doesnt have a spinning weasel we wont make the sale! Clearly those folks like to control the quality factor. Time is usually the last deciding factor. Given a budget and a list of requirements, time-to-market is usually the last factor to be explored. A fair balance is to let decision makers control two of the factors while development controls the third. This gives development the power to resolve the equation. To be fair, everybody needs to understand and accept the powers they are giving up, and the ones they are retaining. These decisions are largely driven by the vision for the project. For instance, if the vision is to meet a critical market window or xed event, then it may be necessary to give up features, or to hire more people to do the work. Regardless of the scenario, giving the development people power over one factor frees them to adjust their mode of operation to make the project a success. Independent contractors usually work on xed costs plus expenses. If the project takes longer than planned, the contractor works for free until the project is complete. Clearly the company owns the cost factor. The company usually also owns product deliverables, with some measure of exibility. Contractors usually sign a contract that states they will deliver x, y, and z for n number of dollars. Again, the time it takes to deliver them is left to the contractor to manage. Protability is fundamentally an 8

1.3. PROJECT LIFECYCLE issue of making deliverables on time by allocating appropriate resources. Because time is the only factor under direct control of the contractor, it is very important to study use of time in past projects, and rene estimation and resource allocation skills, in an eort to maximize protability. One factor of successfully working together as a team is allowing people to own the parts of the equation that aect them most.

1.3

Project Lifecycle

Figure 1.2 outlines the lifecycle of a project.

Figure 1.2: The lifecyle of a project

1.3.1

Project Initiation

The Initiation Phase is the rst phase in the project. In this phase a business problem (or opportunity) is identied and a business case which provides various solution options is dened. A feasibility study is then 9

CHAPTER 1. INTRODUCERE conducted to investigate the likelihood of each solution option addressing the business problem and a nal recommended solution is put forward. Once the recommended solution is approved, a project is initiated to deliver the approved solution. A Project Charter is completed, which outlines the objectives, scope and structure of the new project, and a Project Manager is appointed. The Project Manager begins recruiting a project team and establishes a Project Oce environment. Approval is then sought to move into the detailed planning phase. Figure 1.3 depicts the undertaken activities.

Figure 1.3: The undertaken activities in the initial stage of a project

Develop Business Case Once a business problem or opportunity has been identied, a Business Case is prepared. This includes: A detailed denition of the problem or opportunity An analysis of the potential solution options available. For each option, the potential benets, costs, risks and issues are documented. A formal feasibility study may be commissioned if the feasibility of any particular solution option is not clear The recommended solution and a generic implementation plan. The Business Case is approved by the Project Sponsor and the required funding is allocated to proceed with the project. 10

1.3. PROJECT LIFECYCLE Perform Feasibility Study At any stage during (or after) the development of a Business Case, a formal Feasibility Study may be commissioned. The purpose is to assess the likelihood of a particular solution options achieving the benets outlined in the Business Case. The Feasibility Study will also investigate whether the forecast costs are reasonable, the solution is achievable, the risks are acceptable and/or any likely issues are avoidable. Establish Project Charter After the solution has been agreed and funding allocated, a project is formed. The Project Charter denes the vision, objectives, scope and deliverables for the project. It also provides the organization structure (roles and responsibilities) and a summarized plan of the activities, resources and funding required to undertake the project. Finally, any risks, issues, planning assumptions and constraints are listed. Appoint Project Team At this point the scope of the project has been dened in detail and the project team are ready to be appointed. Although a Project Manager can be appointed at any stage of the project, s/he will need to be appointed prior to the establishment of the project team. The Project Manager documents a detailed Job Description for each project role and appoints a human resource to each role based on his/her relevant skills and experience. Once the team are fully resourced, the Project Oce is ready to be set-up. Set up Project Oce The Project Oce is the physical environment within which the team will be based. Although it is usual to have one central project oce, it is possible to have a virtual project oce environment, with project team 11

CHAPTER 1. INTRODUCERE members in various locations around the world. Regardless of the location, a successful project oce environment will comprise the following components: Location (either physical or virtual) Communications (telephones, computer network, email, internet access, le storage, database storage and backup facilities) Documentation (methodology, processes, forms and registers) Tools (for accounting, project planning and risk modeling). Perform Phase Review At the end of the Initiation Phase, a Phase review is performed. This is basically a checkpoint to ensure that the project has achieved its stated objectives as planned.

1.3.2

Project Planning

Once the scope of the project has been dened in the Project Charter, the project enters the detailed planning phase. This involves the creation of a: Project Plan (outlining the activities, tasks, dependencies and timeframes) Resource Plan (listing the labor, equipment and materials required) Financial Plan (identifying the labor, equipment and materials costs) Quality Plan (providing quality targets, assurance and control measures) 12

1.3. PROJECT LIFECYCLE Risk Plan (highlighting potential risks and actions taken to mitigate them) Acceptance Plan (listing the criteria to be met to gain customer acceptance) Communications Plan (listing the information needed to inform stakeholders) Procurement Plan (identifying products to be sourced from external suppliers). At this point the project has been planned in detail and is ready to be executed. Figure ?? depicts all the stages of planning a project.

Figure 1.4: Planning a project

Develop Project Plan The rst step is to document the Project Plan. A Work Breakdown Structure (WBS) is identied, which includes a hierarchical set of phases, activities and tasks to be undertaken on the project. After the WBS has been agreed, an assessment of the eort required to undertake the activities and tasks is made. The activities and tasks are sequenced, resources are allocated and a detailed project schedule is formed. This project schedule will become the primary tool for the Project Manager to assess the progress of the project. 13

CHAPTER 1. INTRODUCERE Develop Resource Plan Immediately after the Project Plan is formed, it is necessary to allocate the resources required to undertake each of the activities and tasks within the Project Plan. Although general groups of resources may have already been allocated to the Project Plan, a detailed resource assessment is required to identify the: Types of resources (labor, equipment and materials) Total quantities of each resource type Roles, responsibilities and skill-sets of all human resources Items, purposes and specications of all equipment resource Items and quantities of material resource. A schedule is assembled for each type of resource so that the Project Manager can assess the resource allocation at each stage in the project. Develop Financial Plan Similar to the Resource Plan, a Financial Plan is prepared to identify the quantity of money required for each stage in the project. The total cost of labor, equipment and materials is quantied and an expense schedule is dened which provides the Project Manager with an understanding of the forecast spending vs. the actual spending throughout the project. Preparing a detailed Financial Plan is extremely important as the projects success will depend on whether or not it is delivered within the time, cost and quality estimates for this project. Develop Quality Plan Meeting the quality expectations of the customer is critical to the success of the project. To ensure that the quality expectations are clearly dened 14

1.3. PROJECT LIFECYCLE and can reasonably be achieved, a Quality Plan is documented. The Quality Plan: Denes what quality means in terms of this project Lists clear and unambiguous quality targets for each deliverable. Each quality target provides a set of criteria and standards which must be achieved to meet the expectations of the customer Outlines a plan of activities which will assure the customer that the quality targets will be met (i.e. a Quality Assurance Plan) Identies the techniques used to control the actual level of quality of each deliverable as it is built (i.e. a Quality Control Plan). Finally, it is important to review the quality not only of the deliverables produced by the project but also of the management processes which produce them. A summary of each of the management processes undertaken during the execution phase is identied, including Time, Cost, Quality, Change, Risk, Issue, Procurement, Acceptance and Communications Management. Develop Risk Plan The foreseeable project risks are then documented within a Risk Plan and a set of actions to be taken formulated to both prevent each risk from occurring and reduce the impact of the risk should it eventuate. Developing a clear Risk Plan is an important activity within the planning phase as it is necessary to mitigate all critical project risks prior to entering the Execution phase of the project. Develop Acceptance Plan The key to a successful project is gaining acceptance from the customer that each deliverable produced meets (or exceeds) his/her requirements. 15

CHAPTER 1. INTRODUCERE To clarify the criteria used to judge each deliverable for customer acceptance, an Acceptance Plan is produced. The Acceptance Plan provides the criteria for obtaining customer acceptance, a schedule of acceptance reviews within which customer acceptance will be sought and a summary of the process used to gain acceptance of each deliverable from the customer. Develop Communications Plan Prior to the Execution phase, it is also necessary to identify how each of the stakeholders will be kept informed of the progress of the project. The Communications Plan identies the types of information to be distributed, the methods of distributing information to stakeholders, the frequency of distribution and responsibilities of each person in the project team for distributing information regularly to stakeholders. Develop Procurement Plan The last planning activity within the Planning phase is to identify the elements of the Project which will be acquired from external suppliers to the project. The Procurement Plan provides a detailed description of the Products (i.e. goods and services) to be procured from suppliers, the justication for procuring each product externally, as opposed to from within the business, and the schedule for procurement. It also references the process for the selection of a preferred supplier (Tender Process) and the process for the actual order and delivery of the procured products (Procurement Process). Contract Suppliers Although external suppliers may be appointed at any stage of the project, it is usual to appoint suppliers after the Project Plans have been documented but prior to the Execution phase of the project. Only at this point will the Project Manager have a clear idea of the role of the supplier 16

1.3. PROJECT LIFECYCLE and the expectations for his/her delivery. A formal Tender Process is invoked to identify a short-list of interested suppliers and select a preferred supplier to meet the procurement needs of the project. The Tender Process involves creating a Statement of Work, a Request for Information and Request for Proposal to obtain sucient information from each potential supplier to select a preferred supplier. Once a preferred supplier has been chosen, a Supplier Contract is agreed for the delivery of the requisite product. Perform Phase Review At the end of the Planning phase, a Phase review is performed. This is basically a checkpoint to ensure that the project has achieved its stated objectives as planned.

1.3.3

Project Execution

This phase involves the execution of each activity and task listed in the Project Plan. While the activities and tasks are being executed, a series of management processes are undertaken to monitor and control the deliverables being output by the project. This includes the identication of changes, risks and issues, the review of deliverable quality and the measurement of each deliverable being produced against the acceptance criteria. Once all of the deliverables have been produced and the customer has accepted the nal solution, the project is ready for closure. Build Deliverables This phase requires the physical construction of each deliverable for acceptance by the customer. The actual activities undertaken to construct each deliverable will vary, depending on the type of project (e.g. engineering, building development, computer infrastructure or business process re-engineering projects). Deliverables may be constructed in a waterfall 17

CHAPTER 1. INTRODUCERE

Figure 1.5: Executing a project

18

1.3. PROJECT LIFECYCLE fashion (where each activity is undertaken in sequence until the deliverable is nished) or an iterative fashion (where iterations of each deliverable are constructed until the deliverable meets the requirements of the customer). Regardless of the method used to construct each deliverable, careful monitoring and control processes should be employed to ensure that the quality of the nal deliverable meets the acceptance criteria set by the customer. Monitor and Control Whilst the Project Team are physically producing each deliverable, the Project Manager implements a series of management processes to monitor and control the activities being undertaken. An overview of each management process follows. Time Management Time Management is the process within which time spent by sta undertaking project tasks is recorded against the project. As time is a scarce resource on projects, it is important to record the time spent by each member of the team on a Timesheet to enable the Project Manager to control the level of resource allocated to a particular activity. A Timesheet Register provides a summary of the time currently spent on the project and enables the Project Plan to be kept fully up to date. Cost Management Cost Management is the process by which costs (or expenses) incurred on the project are formally identied, approved and paid. Expense Forms are completed for each set of related project expenses such as labor, equipment and materials costs. Expense Forms are approved by the Project Manager and recorded within an Expense Register for audit purposes. Quality Management Quality is dened as the level of conformance of the nal deliverable to the customers requirements. Quality Management is the process by which the quality of the deliverables is assured and controlled for the 19

CHAPTER 1. INTRODUCERE project, using Quality Assurance and Quality Control techniques. Quality reviews are frequently undertaken and the results recorded within a Quality Register Change Management Change Management is the process by which changes to the projects scope, deliverables, timescales or resources are formally dened, evaluated and approved prior to implementation. A core aspect of the Project Managers role is to manage change within the project successfully. This is achieved by understanding the business and system drivers requiring the change, documenting the benets and costs of adopting the change and formulating a structured plan for implementing the change. To formally request a change it is often necessary to complete a Change Form. The change request details may then be recorded within a Change Register. Risk Management Risk Management is the process by which risks to the project (e.g. to the scope, deliverables, timescales or resources) are formally identied, quantied and managed during the project. A project risk may be identied at any stage of the project by completing a Risk Form and recording the relevant risk details within the Risk Register. Issue Management Issue Management is the method by which issues currently aecting the ability of the project to produce the required deliverable are formally managed. After completion of an Issue Form (and logging the details within the Issue Register), each issue is evaluated by the Project Manager and a set of actions undertaken to resolve the issue at hand. Procurement Management Procurement Management is the process by which product is sourced from an external supplier. To request the delivery of product from a supplier, a Purchase Order must be approved by the Project Manager and sent to the supplier for conrmation. The status of the purchase is then tracked using a Procurement Register until the product has been delivered and accepted by the project team. Acceptance Management 20

1.3. PROJECT LIFECYCLE Acceptance Management is the process by which deliverables produced by the project are reviewed and accepted by the customer as meeting his/her specic requirements. To request the acceptance of a deliverable by the customer, an Acceptance Form is completed. The Acceptance Form describes the criteria from which the deliverable has been produced and the level of satisfaction of each criterion listed. Communications Management Communications Management is the process by which formal communications messages are identied, created, reviewed and communicated within a project. The most common method of communicating the status of the project is via a Project Status Report. Each communication item released to the project stakeholders is captured within a Communications Register. Perform Phase Review At the end of the Execution Phase, a Phase review is performed. This is basically a checkpoint to ensure that the project has achieved its stated objectives as planned.

1.3.4

Project Closure

Project Closure involves releasing the nal deliverables to the customer, handing over project documentation, terminating supplier contracts, releasing project resources and communicating the closure of the project to all stakeholders. The last remaining step is to undertake a Post Implementation Review to quantify the overall success of the project and list any lessons learnt for future projects. The two stages of project closure are depicted in gure 1.6. Perform Project Closure Project Closure involves undertaking a series of activities to wind up the project, including: 21

CHAPTER 1. INTRODUCERE

Figure 1.6: Closing a project Assessing whether the project completion criteria have been met Identifying any outstanding items (activities, risks or issues) Producing a hand-over plan to transfer the deliverables to the customer environment Listing the activities required to hand over documentation, cancel supplier contracts and release project resources to the business Communicating closure to all stakeholders and interested parties. A Project Closure Report is submitted to the Customer and/or Project Sponsor for approval. The Project Manager is then responsible for undertaking each of the activities identied within the Project Closure Report on time and according to budget. The project is closed only when all activities identied in the Project Closure Report have been completed. Review Project Completion(Evaluarea nala) Evaluarea reprezinta emiterea de judecati privind progresul nregistrat pe calea atingerii obiectivelor propuse. Ea se concentreaza, n principal, asupra a patru aspecte: activitatile desfasurate, resursele utilizate, rezultate obtinute si benecii realizate. Aceasta actiune se desfasoara neaparat la sfrsitul proiectului, dar este deosebit de util ca pe parcursul lui sa aiba loc evaluari partiale. Dupa o evaluare corecta a unui proiect, este necesar sa se poata raspunde la cteva ntrebari esentiale: 22

1.3. PROJECT LIFECYCLE n ce masura si-a atins proiectul obiectivele propuse? n ce masura atingerea obiectivelor poate atribuita n mod direct proiectului derulat? n ce masura proiectul s-a desfasurat conform planicarii din cererea de nantare? Spre deosebire de monitorizare care presupune analizarea a ceea ce se ntmpla n timpul derularii proiectului, evaluarea reprezinta o analiza a ceea ce s-a ntmplat. O evaluare este ecient numai dac sunt satisfcute urmtoarele conditii: obiectivele proiectului au caracteristici SMART (asa cum a fost descris anterior la capitolul privind planicarea) monitorizarea se face pe parcursul ntregului proiect, informatiile ind culese si prelucrate cu grija cei care fac evaluarea doresc sa e critici cu activitatea lor si a organizatiei (evaluarea nu are nici un sens sa e facuta daca oamenii nu sunt capabili sa admita ca pot gresi) membri echipei de proiect doresc sa puna n aplicare schimbarile reiesite a necesare ca urmare a evaluarii. Evaluarea nal presupune i o msurare a succesului proiectului. Elementele urmrite n msurarea succesului sunt urmtoarele: ncheierea proiectului n intervalul de timp alocat ncheierea proiectului n limitele costului prevazut de buget ncheierea proiectului la nivelul de performanta stabilit n etapa de planicare ncheierea proiectului cu schimbari minime sau agreate ca necesare de toate partile implicate 23

CHAPTER 1. INTRODUCERE ncheierea proiectului fara a perturba celelalte activitati ale organizatiei ncheierea proiectului cu un sentiment de satisfactie al membrilor echipei acceptarea proiectului de catre beneciar. nainte de evaluarea propriu-zis, coordonatorul de proiect trebuie s cear scurte rapoarte scrise de la ecare din membrii echipei. Pentru a se asigura de faptul c acestia vor furniza informaiile utile pentru evaluarea nal, raportul poate fcut prin completarea unor chestionare elaborate de ctre coordonator. Dup adunarea acestor informaii, trebuie planicat o ntlnire cu persoanele care au jucat un rol cheie n proiect, n cadrul creia acestora s li se solicite s-i exprime prerea despre proiect i s spun ce ar face mai bine ntr-o eventual ocazie viitoare. Prima ntrebare pe care trebuie s ne-o adresam n evaluarea proiectului este dac au fost atinse obiectivele i s-au obinut rezultatele dorite. Apoi, trebuie revzute toate etapele, de la nceput pn la sfrit, pentru a vedea ce a mers i ce nu. Trebuie analizate cu atenie problemele aprute pe parcursul proiectului i modul n care coordonatorul i membrii echipei s-au descurcat n a le rezolva, punctndu-se momentele n care au fost ecieni i momentele n care ar putut lucra mai bine. n continuare este prezentat un chestionar de analizare a proiectului, cu ajutorul cruia coordonatorul proiectului i echipa s pot face o evaluare corect dup terminarea lui. 1. Ct de bine au fost ndeplinite obiectivele planicate? 2. Ct de bine au fost denite activitile i sarcinile n cadrul proiectului? 3. n ce msur au respectat membrii echipei datele de ncepere i de ncheiere a sarcinilor? 24

1.3. PROJECT LIFECYCLE 4. n ce msur nivelul real de performan s-a ridicat la nivelul de performan ateptat? 5. n ce msur proiectul s-a ncadrat n bugetul iniial? 6. Cum ai clasica abilitatea echipei de a rezolva problemele aprute pe parcurs? 7. Cum ai clasica eciena echipei n general? 8. Cum ai clasica eciena coordonatorului de proiect? 9. Ct de bine au primit beneciarii / clienii rezultatele proiectului? 10. n ce msur rezultatele proiectului au depit ateptrile dumneavoastr (dac este cazul)? 11. Ce schimbri s-ar putut face pentru mbuntirea performanei? 12. Ce factori au contribuit la succesul proiectului? 13. Ce factori au periclitat succesul proiectului? 14. Care sunt problemele sau activitile neterminate i ce importan au ele pentru succesul proiectului? Raportul nal Raportul nal trebuie s cuprind att o istorie a proiectului, ct i evaluarea nal a performanei. Dac raportul unui proiect mic se poate ntinde pe 2 3 pagini, raportul unui proiect de anvergur poate cuprinde 10 - 20 de pagini. Dac s-a inut un jurnal al proiectului, elaborarea raportului nal este relativ uoar. Principalele aspecte care trebuie cuprinse n raportul nal sunt urmtoarele: descriere pe scurt a proiectului, n conformitate cu planicarea initiala 25

CHAPTER 1. INTRODUCERE rezumatul principalelor realizari din cadrul proiectului analiza masurii n care au fost ndeplinite obiectivele proiectului raportul nanciar, nsotit de explicatiile referitoare la abaterile fata de bugetul initial evaluarea performantelor membrilor echipei (evaluarea ecarei persoane trebuie sa e condentiala) probleme aparute pe parcursul derularii proiectului, care necesita atentie si dupa terminarea lui recomandari privind proiecte viitoare de acelasi tip recomandari pentru membrii echipei. n ecare din seciunile raportului nal trebuie scoase n eviden aspectele pozitive i cele negative. Lucrurile care n-au mers trebuie explicate, iar explicaiile trebuie nsoite de recomandri pentru viitor. Toate persoanele implicate n proiect trebuie s contribuie la raportul nal, e elabornd seciuni ale lui, e revizuindu-l nainte de a i se da forma nal.

1.4

Probleme comune in proiectele software

n cadrul acestei sectiuni vor prezentate tipul problemelor identicate, cauzele posibile de producere si impactul pe care aceste probleme, odata manifestate, l produc asupra proiectelor sau asupra institutiilor. Studiul a fost coordonat de Ministerul Comunicatiilor si Tehnologiei Informatiei. Urmatoarele probleme se manifesta n cadrul proiectelor TIC: ntrzierea nalizarii proiectelor cresterea costurilor de implementare ale proiectelor nerealizarea unor livrabile ale proiectelor sau ntrzierea lor 26

1.4. PROBLEME COMUNE IN PROIECTELE SOFTWARE nerespectarea standardului de calitate pentru livrabile nerespectarea (partiala sau totala) a cerintelor utilizatorilor diminuarea gradului de ncredere n capacitatea de livrare a furnizorului erodarea relatiilor dintre organizatia furnizorului si a beneciarului sau dintre membrii acestor organizatii abaterea de la obiectivele stabilite ale proiectului Aceste probleme determina n ultima instanta esecul partial sau total al proiectelor prin neatingerea obiectivelor propuse sau nerespectarea constrngerilor stabilite. n gruparea problemelor identicate a fost respectata structura generala a componentelor oricarei metodologii de management de proiect.

1.4.1

Probleme identicate n organizarea proiectelor

Principalele probleme identicate pentru aceasta componenta sunt urmatoarele: nu este foarte clar stabilit fata de cine raporteaza managerul de proiect pe parcursul implementarii proiectului coordonatorul de proiect al beneciarului nu are pregatirea necesara pentru a monitoriza si evalua modul n care managementul de proiect este realizat de catre furnizor organizatia care furnizeaza proiectul sau managerul de proiect nu are capacitatea de a realiza managementul implementarii unor proiecte complexe produsele rezultate n urma implementarii proiectului nu sunt folosite de catre utilizatorii nali 27

CHAPTER 1. INTRODUCERE refuzul de colaborare si de acceptare a produselor din partea persoanelor care utilizeaza produsele realizate n cadrul proiectului indisponibilitatea sau dezinteresul resurselor beneciarului fata de derularea proiectului nerezolvarea la timp a problemelor aparute n proiect specicatia cerintelor nu acopera corect sau complet cerintele utilizatorilor nerecunoasterea sau subminarea autoritatii managerului de proiect Cauzele care produc aceste probleme sunt n general urmatoarele: nu este stabilit un comitet de conducere al proiectului nainte de demararea acestuia coordonatorul de proiect al beneciarului nu este ntotdeauna identicat de catre conducerea institutiei pe baza abilitatilor si experientei de management de proiect; de regula, acesta este ales din cadrul departamentului de TIC nu exista o nominalizare ociala a membrilor echipei de proiect a beneciarului, cu descrierea rolului si a responsabilitatilor specice n proiect departamentele care beneciaza de pe urma proiectului sau utilizeaza produsul acestuia nu sunt ntotdeauna implicate direct n derularea proiectului, sau nu sunt reprezentate n comitetul de conducere al proiectului furnizorii nu nominalizeaza ntotdeauna n mod ocial (n cadrul unui document de proiect) echipa proprie de proiect si/sau managerul de proiect si nu descriu rolurile si reponsabilitatile pentru membrii echipei de proiect 28

1.4. PROBLEME COMUNE IN PROIECTELE SOFTWARE nu ntotdeauna sunt folosite mijloacele (instrumentele) cele mai eciente pentru prezentarea problemelor aparute n derularea proiectului n vederea luarii de decizii n timp util de catre persoanele autorizate n cele mai multe cazuri nu se solicita furnizorului prezentarea n cadrul ofertei tehnice a metodologiei de management de proiect pe care acesta o va utiliza pe parcursul proiectului de foarte multe ori nu este solicitat furnizorului sa faca dovada capacitatii sale de management de proiect, sa prezinte CV-ul pentru managerul de proiect propus si dovezile care sa ateste experienta acestuia n managementul unor proiecte de anvergura similara caietele de sarcini nu prevad n mod explicit responsabilitatea conducerii proiectului (a sarcinilor si a responsabilitatilor organizatiilor furnizor si beneciar) si nu includ cerinte specice pentru managementul proiectului nu este solicitata n caietele de sarcini identicarea n cadrul ofertei nanciare a ofertantului a costurilor asociate managementului de proiect

1.4.2

Probleme identicate n planicarea proiectelor

Principalele probleme identicate pentru aceasta componenta sunt urmatoarele: dependentele pentru proiect nu sunt corect sau complet identicate estimarea nerealista a duratelor pentru activitatile din cadrul etapei alocarea resurselor este defectuoasa (insucienta) ntrzierea activitatilor deoarece resursele nu sunt disponibile atunci cnd este necesar 29

CHAPTER 1. INTRODUCERE Cauzele care produc aceste probleme sunt n general urmatoarele: nu sunt luate n considerare n cadrul proceselor de planicare toate elementele care necesita planicare nu sunt folosite metode sau instrumente specice n cadrul planicarii planicarea detaliata nu este ntotdeauna realizata la nceputul etapelor, atunci cnd informatiile relevante necesare planicarii sunt disponibile

1.4.3

Probleme identicate n controlul proiectelor

Principalele probleme identicate pentru aceasta componenta sunt urmatoarele: problemele care apar pe parcursul derularii proiectelor nu sunt identicate la timp si/sau nu sunt solutionate optim sau n timp util beneciarul nu cunoaste ntotdeauna care este stadiul real al proiectului, sau care sunt problemele cu care furnizorul se confrunta la un moment dat coordonatorul de proiect al beneciarului nu are prghiile institutionale corespunzatoare pentru a controla n mod ecient un proiect serviciile sau documentele care trebuie produse nu sunt ntotdeauna cunoscute sau clar identicate n Contract reponsabilitatile partilor si dependentele reciproce sunt ambiguu exprimate metodele de acceptare pentru livrabile nu sunt identicate n mod explicit 30

1.4. PROBLEME COMUNE IN PROIECTELE SOFTWARE testele care trebuie realizate nainte de acceptarea unui produs sau serviciu nu sunt identicate si rezultatele testelor nu sunt riguros documentate nu sunt cunoscute ntotdeauna responsabilitatile privind controlul si raportarea progresului nu se cunoaste care este ordinea de prioritate a documentelor contractuale n cazul n care exista contradictii ntre prevederile acestora exista deseori nentelegeri cu reprezentantii furnizorului datorita ntelegerii diferite a ceea ce trebuie livrat sau a modului n care trebuie livrat Cauzele care produc aceste probleme sunt n general urmatoarele: contractele ncheiate nu contin suciente detalii care sa permita un control ecient al proiectelor furnizorii nu includ n ofertele lor detalii referitoare la: reponsabilitatile partilor si dependentele reciproce, testele care trebuie realizate, metodele de acceptare pentru livrabile caietele de sarcini nu prevad ntotdeauna responsabilitatile partilor privind controlul si raportarea progresului nu exista n contract o clauza care sa prevada ordinea n care diferitele documente care fac parte din contract vor interpretate modalitatile si instrumentele de control nu sunt folosite ntotdeauna ntr-un mod ecient de catre coordonatorul de proiect al beneciarului: sedinte de identicare a progresului, sedinte de rezolvare a problemelor, sedinte de control cu furnizorii, sedinte de raportare catre conducere, rapoarte scrise si scrisori (puncte de vedere) 31

CHAPTER 1. INTRODUCERE

1.4.4

Probleme identicate n managementul calitatii

Principalele probleme identicate pentru aceasta componenta sunt urmatoarele: livrabilele realizate de proiect nu corespund standardelor de calitate aplicabile si stabilite pentru proiect procesul de testare nu scoate n evidenta toate neconformitatile livrabilelor livrabilele realizate de proiect nu pot folosite de catre utilizatori datorita disfunctionalitatilor majore care apar imediat dupa intrarea n perioada de operare a acestora furnizorul nu este n masura sa asigure si sa controleze calitatea pe perioada desfasurarii proiectului Cauzele care produc aceste probleme sunt n general urmatoarele: organizatia beneciarului sau a furnizorului nu ntelege ntotdeauna ce nseamna calitatea n mediul de proiect caietele de sarcini nu contin ntotdeauna criterii de calitate pentru toate livrabilele proiectului nu sunt clar stabilite sau cunoscute criteriile de calitate care se aplica diferitelor tipuri de livrabile (echipamente, licente software, servicii de analiza, servicii de implementare, servicii de instruire, servicii de suport si asistenta tehnica, documente tehnice, documente de analiza, rapoarte, grace de implementare etc.) nu se solicita n cadrul caietului de sarcini prezentarea de catre ofertant a modului n care acesta va asigura calitatea livrabilelor pe parcursul desfasurarii proiectului 32

1.4. PROBLEME COMUNE IN PROIECTELE SOFTWARE furnizorii nu prezinta n cadrul ofertelor tehnice modalitatea practica n care acestia vor asigura si controla calitatea livrabilelor proiectului, mentionarea existentei certicarii ISO ind de multe ori singura referire la calitate necunoasterea n totalitate sau neaplicarea tuturor tipurilor de criterii n baza carora se realizeaza n cadrul proiectelor testarea si acceptarea livrabilelor

1.4.5

Probleme identicate n managementul schimbarilor si al conguratiilor

Principalele probleme identicate pentru aceasta componenta sunt urmatoarele: modicarea cerintelor beneciarului pe parcursul derularii proiectului si imposibilitatea furnizorului de a raspunde la aceste schimbari n mod ecient neintegrarea unor sub-sisteme sau componente n sistemul nal n urma implementarii unor schimbari la nivelul acestora aparitia unor ntrzieri sau costuri neplanicate sau neaprobate n urma realizarii unor modicari la specicatia livrabilelor livrarea unor produse care sa nu e functionale sau utilizabile Cauzele care produc aceste probleme sunt n general urmatoarele: desi este acceptata de marea majoritate a intervievatilor ca existenta unei proceduri scrise care sa documenteze exact toate elementele unei schimbari este perfect justicata, n foarte multe cazuri procedura de control a schimbarilor nu este cunoscuta sau nu este utilizata n cadrul proiectelor nu sunt cunoscute toate componentele proiectului pentru care se aplica managementul schimbarii 33

CHAPTER 1. INTRODUCERE nu este clar denita autoritatea care ar trebui sa aprobe implementarea unor schimbari n cadrul proiectului nu sunt cunoscute avantajele si riscurile pentru diferitele abordari n implementarea schimbarilor pe parcursul ciclului de viata a proiectului

1.4.6

Probleme identicate n managementul riscului

Principalele probleme identicate pentru aceasta componenta sunt urmatoarele: producerea de ntrzieri n derularea proiectului, pentru anumite activitati sau livrabile, n urma aparitiei unor probleme care nu au fost prevazute depasirea bugetului alocat pentru proiect datorita unor situatii neprevazute crearea unor situatii tensionate n cadrul echipei de proiect comune furnizorbeneciar n urma manifestarii unor riscuri realizarea unor compromisuri relativ la calitatea unor livrabile datorita aparitiei unor probleme care nu au fost prevazute Cauzele care produc aceste probleme sunt n general urmatoarele: nu sunt clar denite sau nu sunt formal asumate de catre parti responsabilitatile referitoare la managementul riscurilor n marea majoritate a cazurilor nu este folosita, nici de catre beneciar si nici de catre furnizor, o procedura formala de realizare a managementului riscurilor care sa prezinte modalitatea practica de realizare a identicarii riscurilor, a probabilitatii de aparitie si a impactului n cazul aparitiei, a planicarii activitatilor de contracarare si a planurilor alternative n cazul materializarii riscului 34

1.4. PROBLEME COMUNE IN PROIECTELE SOFTWARE nu sunt stabilite responsabilitatile n identicarea si controlul riscurilor pentru persoanele cu autoritate de decizie din cadrul organizatiei beneciarului nu sunt identicate si disponibile modalitatile concrete prin care pot controlate riscurile n cadrul organizatiei beneciare nu sunt derulate sedinte de analiza comune (beneciar si furnizor) n vederea identicarii si evaluarii riscurilor din proiect nu sunt stabilite sau derulate planuri de actiune de catre coordonatorul de proiect al beneciarului n vederea contracararii riscurilor nu este solicitata n cadrul caietului de sarcini prezentarea n cadrul ofertei tehnice de catre furnizor a unui plan concret de management al riscului pentru principalele riscuri identicate planul de riscuri nu este revizuit pe parcursul proiectului

1.4.7

Concluzii

Pentru a putea evalua anvergura problemelor identicate s-a avut n vedere determinarea frecventei de manifestare a acestor probleme pe parcursul initierii, contractarii, demararii si derularii proiectelor. Astfel, n urma analizei informatiilor si a consolidarii rezultatelor din chestionarele primite, s-au putut determina pentru ecare problema n parte frecventa de aparitie si componenta de metodologie de management de proiect careia aceasta i apartine. Componentele de metodologie au fost ulterior grupate n trei categorii n functie de numarul problemelor care au fost semnalate. Mai jos sunt prezentate componentele de management de proiect grupate pe cele trei categorii: Clasa 1 probleme foarte frecvente (peste 75% din proiecte): probleme apartinnd componentei de management a riscului 35

CHAPTER 1. INTRODUCERE probleme apartinnd componentei de organizare a proiectului Clasa a 2-a probleme cu frecventa medie (ntre 35% si 75% din proiecte): a probleme apartinnd componentei de control a proiectului probleme apartinnd componentei de management al schimbarii probleme apartinnd componentei de management al calitatii Clasa a 3-a probleme cu frecventa redusa (sub 35% din proiecte): a probleme apartinnd componentei de planicare a proiectului Rezolvarea problemelor identicate n cadrul analizei prin utilizarea unei metodologii de management de proiect de catre organizatiile care furnizeaza proiectul sau care beneciaza de pe urma acestuia si utilizeaza produsul proiectului reprezinta un factor determinant n asigurarea succesului acestuia . Din acest motiv, n cadrul sectiunilor care urmeaza vor prezentate componentele generale ale unei metodologii de management de proiect care sa e aplicate pe parcursul implementarii proiectelor TIC din administratia publica locala.

36

Chapter 2

Project Planning

2.1

Introduction

Projects that involve more than one person and/or more than one step pose the following questions: What tasks need to be done to complete the project? When and in what order will these tasks be done? Who will do each task? What are the intermediate deadlines (e.g., status reports), and what will be done by these deadlines? To answer these questions, additional issues arise, such as: How long will each task take? What dependencies exist between tasks? Who has the knowledge/skill/time to do each task? What external constraints exist (e.g., time to order parts)? The Gantt, PERT, and CPM charts describe the answers to these questions in timeoriented diagrams. In all cases, the task is the basic unit of interest. In this context, a task is some signicant activity the group will need to perform to accomplish 37

CHAPTER 2. PROJECT PLANNING its goals. Note that the group will have goals that include the project itself as well as presentations, reports, proposals, etc. Tasks are given: a name/description (typically, verb-noun, as in design control board or research literature) an estimate of the amount of calendar time required a list of other tasks (if any) that must be completed before this task can begin (or end)i.e., dependencies. Other task attributes can be added if desired, such as time required in person-hours and other resources required (e.g., nancial, special skills, special equipment). Besides tasks, other information is required, such as: the overall project start/end dates other deadlines or milestones (e.g., reports, etc.) factors aecting time available (e.g., holidays, breaks, other classes, presentations, etc.) Now the three methods (Gantt, PERT, CPM) will be described. Following that, a cookbook approach to the creation of a Gantt chart will be presented.

2.2

Gantt

The Gantt chart ( 2.1) was invented in the early 1900s by Henry L. Gantt, an American engineer and social scientist. The horizontal axis is (linear) time; each task is given its own horizontal band where the calendar duration of the task is indicated by a box, line, or other object with a variable horizontal dimension. Tasks are often grouped into categories, and each 38

2.2. GANTT

Figure 2.1: Example of Gantt chart category can be treated as a summary task whose duration spans all the tasks within that category. Tasks are generally listed from top to bottom in the order they will occur; if there are groups of tasks, the tasks are chronological (by starting date) within a group, and the groups ordered by starting date. The horizontal axis has a resolution appropriate to the type of tasks; a resolution of one day is useful for most projects. Note that if signicant work is not expected to be done on weekends, these should be omitted from the chart, otherwise tasks will have their durations distorted if they straddle days when no work is likely. A vertical line is usually placed on the chart to show the current date. Other important milestones can be noted (and labeled) with dotted vertical lines at the appropriate dates. The advantages of the Gantt chart are: time is explicit (and linear) all tasks visible in relationship to others deadlines are shown project status at intermediate times is shown can show progress by lling in task boxes 39

CHAPTER 2. PROJECT PLANNING The unmodied Gantt chart has the following shortcomings: tasks might not be associated with people (solution: tag tasks with the initials of the people responsible) person-hours are not indicated, only calendar time (solution: note person-hours near the task box) dependencies are not explicit (solution: imply dependencies by ordering tasks, or use extra lines and arrows) no summary of the load on a person (solution: create an additional set of horizontal task lines for each person, showing what tasks they are working on when) other resources not shown (e.g., nancial) (solution: note resources in description or near task box) critical paths are not explicit (solution: use highlighting or other graphical means to indicate the sequence of tasks along the critical path) does not record dierence between original plan and actual (solution: enhance the task box to show two dierent durationsan upper (actual) and lower (estimated))

2.3
2.3.1

PERT and CPM

PERT

A few of the shortcomings of the Gantt chart are solved in the PERT chart (Program Evaluation and Review Technique). (See gure 2.2) The PERT chart uses a connected series of nodes to make explicit dependencies between tasks. In addition, the order of tasks is given by the ow of the connections left to right, but the horizontal axis is not necessarily linear in time. 40

2.3. PERT AND CPM

Figure 2.2: CPM (PERT) chart. Nodes are events (here numbered 1-8), which occur on completion of tasks. Lines connecting events are tasks (activities), which have a calendar duration (in days) noted. The bold lines show the critical path. The PERT chart can be more compact than the Gantt, but does so at the cost of a linear time scale. The time resources required by a task are given numerically, rather than appearing graphically (i.e., horizontal dimension) as in the Gantt chart; this may make it harder to quickly see what areas are using the most time resources.

2.3.2

CPM

The CPM (Critical Path Management) chart is similar to the PERT chart but includes an explicit indication of the critical paththat sequence of tasks that denes the minimum amount of time for the project. Put another way, these are the tasks that a delay within will delay the entire project. One or more sequences of such tasks always exists; the CPM chart makes these paths (usually just one) explicit. Otherwise, CPM shares the same strengths and weaknesses as the PERT, and the two are often lumped together as one technique. For complex, time-critical projects, the CPM/PERT charts might be useful in providing a clear indication of the critical sequences of tasks necessary to keep the project on schedule. However, the Gantt chartespecially when augmented by notations to show dependenciesis easier to produce and update, and is a good all-around project planning tool. 41

CHAPTER 2. PROJECT PLANNING

2.3.3

PERT vs. CPM

Modalitatea de estimare a duratei activittilor: PERT este un instrument probabilistic care utilizeaza 3 estimri pentru a aa durata de executie a proiectelor pe baza probabilittii de distributie a timpilor de realizare CPM este un instrument deterministic care se bazeaza pe o singur estimare Modalitatea de estimare a costurilor de realizare a proiectelor: PERT este instrument de planicare i control al timpului s CPM permite o estimare explicit a costului aditional al estimrii timpului

2.3.4

Avantajele metodelor PERT si CPM

Avantajele celor doua metode sunt: Planicare detaliata .. .. Angajamente si comunicatii Monitorizare si control ecient Identicarea ariei problemelor potentiale Asigura utilizarea optima a resurselor Ofera posibilitatea replanicarii Ofera posibilitatea administrarii contractelor Intelegerea metodelor este usoara Metodele se adapteaza la rezolvarea pe computer Se pot folosi ca instrumente de decizie 42

2.3. PERT AND CPM Utilizeaza probabilitatea de realizare (PERT) Utilizare pentru evaluarea cost timp (CPM)

2.3.5

Utlizarea metodelor PERT si CPM

Utilizarea celor doua metode presupune trei etape distincte (gure 2.3): 1. Formularea problemei 2. Gsirea solutiei problemei 3. Analiza i aplicarea solutiei s

Figure 2.3: Etapele utilizarii celor doua metode

Analiza proiectului In aceasta etapa se intocmeste lista activitatilor si se stabileste ordinea acestora. Firma X trebuie sa organizeze oxigenarea apei unui lac. Ca urmare a analizei proiectului rezulta etapele din tabelul 2.1. 43

CHAPTER 2. PROJECT PLANNING Table 2.1: Analiza proiectului Descrierea activittii Durata [sptmni] Organizare administrativ 3 Angajare personal 4 Aprovizionare cu materiale 4 Transport materiale 2 Organizarea echipei de msurare 4 Planicarea msurtorilor 6 Ansamblare echipamente 3 Evaluarea planului de actiune 1 Oxigenarea apei 12 Msurare i evaluare s 2

Activitatea A B C D E F G H I J

Activitti precedente A A C A C B, D E G, J I, H

Ealonarea activittilor s Acest pas cuprinde: denirea continutului activittilor = ealonarea este s determinat Estimarea duratei activittilor i a costurilor aferente s Se determin timpul necesar (durata estimat) pentru ecare activitate te . In cazul CPM, duratele sunt determinate (certe), iar in cazul PERT se fac trei estimari si se aplica media aritmetica. Constructia retelei Reteaua este o reprezentare grac a informatiilor cuprinse tabelul de n denire a problemei ( 2.1). In aceasta retea, activitatile sunt reprezentate prin arcuri, iar evenimentele prin cercuri. Constructia retelei ncepe cu activittile care nu sunt precedate de alte activitti. Iar toate activittile care necesit aceeai activitate precedent s pornesc din acelai nod (vezi gura 2.4). Se continu in acest mod pn cnd s se gureaz toate activittile i evenimentele. s 44

2.3. PERT AND CPM

Figure 2.4: Reteaua asociata proiectului de oxigenare a apei Analiza evenimentelor Aceasta etapa se utilizeaz mai ales metoda PERT. Analiza se poate n face printr-o enumerare completa sau analitic. Proceduri: 1. timp estimat de intrare retea n 2. calcularea timpilor cel mai devreme i cel mai trziu s 3. cutarea tolerantelor evenimentelor i identicarea evenimentelor s critice 4. cutarea tolerantelor activittilor i identicarea activittilor critice s 5. cutarea drumului critic Estimarea timpului de intrare retea n Duratele activittilor (te ) se nscriu diagram ca in gura 2.5. n

Figure 2.5: Duratele inscrise Calcularea timpilor cel mai devreme i cel mai trziu s 45

CHAPTER 2. PROJECT PLANNING Folosim urmatoarele notatii: TE data cea mai devreme posibil (imediat dup ce toate evenimentele precedente s-au ncheiat) TL data cea mai trzie posibil (ultima dat la care se poate produce evenimentul fr a produce pagube). Se nscrie pentru toate evenimentele de la stnga. Data cea mai devreme de realizare a proiectului este data cea mai devreme a ultimului eveniment (gura 2.6). Se nscrie pentru toate evenimentele de la dreapta.

Figure 2.6: Timpii activitatilor in cadrul proiectului de oxigenare a apei Determinarea abaterilor evenimentelor (marjelor de timp) i s identicarea evenimentelor critice Abaterea este diferenta dintre TL si TE . Astfel, daca TL TE = 0 atunci este vorba de o activitate critica, iar daca TL TE > 0 avem o activitate cu marje de timp. Determinarea abaterilor activittilor i identicarea activittilor s critice La acest pas se determin ct poate ntrzia o activitate fr s afecteze proiectul. Abaterea activitatii (durata activitatii, timpul disponibil pentru operatie TF ) este egala cu diferenta dintre TL pentru eveniment la sfritul s activittii, TE pentru eveniment la nceputul activittii si te TF = TL (sf ) TE (inc) te Gsirea drumului critic 46

2.3. PERT AND CPM Table 2.2: Centralizarea timpilor Activitate TL (sfarsit) TE (inceput) te TF A 3 0 3 0 B 10 3 4 3 C 7 3 4 0 D 10 7 2 1 E 24 3 4 17 F 13 7 6 0 G 13 9 3 1 H 25 7 1 17 I 25 13 12 0 J 27 25 2 Drumul critic este drumul cel mai lung din retea. A se remarca faptul ca intr-o retea pot exista mai multe drumuri critice. Drumul critic pentru proiectul nostru este reprezentat prin linia ingrosata din gura 2.7.

Figure 2.7: Determinarea drumului critic retea n Analiza activitatilor Daca ES este data de nceput cea mai devreme, EF este data de sfrit s cea mai devreme, atunci: EF = ES + te . Daca LF este data de sfrit cea mai trzie, LS este data de s nceput cea mai trzie, atunci LS = LF te . Reprezentarea graca a acestor concepte este arata in gura ?? 47

CHAPTER 2. PROJECT PLANNING

Figure 2.8: Reprezentarea graca completa a activitatilor Monitorizare i control s Presupunem c activitatea 1 (organizare administrativ) va dura cu 1 sptmn mai mult dect s-a prevzut (4 spt. loc de 3 spt.) Pentru n evenimentul 2 avem: TE = 4 TL = 3 S = TL TE = 4 3 = 1 In acest caz proiectul va intarziat cu o saptamana. O solutie posibila ar transferul de resurse de la activittile cu marj de timp pentru a elimina ntrzierea. Alte solutii: relaxarea prescriptiilor tehnice si a cerintelor de calitate modicarea scopului proiectului reducnd obiectivele schimbarea succesiunii activitatilor utilizarea de resurse aditionale startarea activitatilor cnd activitatile precedente sunt curs de n nalizare 48

2.3. PERT AND CPM Table 2.3: Calculul marjei de timp Activitatea Start cel mai Start cel mai Marj devreme trziu 1-2 0 0 0 1-3 0 4 4 1-4 0 4 4 2-3 2 2 0 3-5 7 7 0 4-5 1 5 4 Utilizarea resurselor Metodele PERT / CPM se limiteaz la planicarea timpului de executie acest caz nu se cunoate permanent disponibilul al unui proiect. In s n de resurse al proiectului. Modul de abordare al resurselor poate afecta drumul critic i data de nalizare. s

Angajati necesari 2 2 3 2 1 2

Figure 2.9: Exemplu de proiect Analizm activittile tabelul 2.3. n Rezolvarea problemei cu ajutorul diagramei Gantt (vezi gura 2.10). Obs.: Personalul nu este echilibrat utilizat pe parcursul proiectului. Incrcarea variaz ntre 1 i 7 persoane/sptmn s Solutie: prin ncercri succesive se echilibreaz distributia personalului proiect. n 49

CHAPTER 2. PROJECT PLANNING

Figure 2.10: Start la data cea mai devreme

Figure 2.11: Echilibrarea resurselor proiect n

50

2.4. DEPENDENCIES

2.4

Dependencies

Both PERT and CPM represent the project with a diagram that shows the tasks and their dependencies. The simple diagrams above show three tasks that have sequential dependencies. The arrow from Task 1 to Task 2 indicates that the start of Task 2 depends on the end of Task 1. Task 2 cannot start until Task 1 nishes. In larger projects these charts can get fairly complex. @@g The chart above shows a project with many tasks and dependencies. At the start of the project three tasks (t1, t9, and t5) begin concurrently. Other tasks start as these tasks end. Notice that t6 and t7 cannot begin until t5 completes. Notice also that t3 cannot start until t2 and t6 both complete. The longest path through this network is known as the Critical Path, from which CPM gets its name. The critical path is shown in bold. This path through the project tells us that the end event is 26 days from the start event. If we were using PERT, then the date of the end event would be a random variable based upon the and s of each of the tasks on the critical path. We would also be able to calculate the probabilities of other paths going critical.

2.5

The wrong choice

Over the last three decades, software project managers have become enamored with the power of these charts to represent dependencies. Ive often seen projects represented as huge diagrams showing all the various software tasks and their interdependencies. These are often broken down well below the subsystem level to tasks that are measured in man-days. While I agree that the ability to represent dependencies on a chart like this is cool; it is also fairly useless in a software project. First of all, the number of concurrent tasks in a software project 51

CHAPTER 2. PROJECT PLANNING usually cannot exceed the number of people in the development team. If you have ve developers, then typically no more than ve programming tasks can be going in parallel. The sixth task cannot begin until one of those ve completes.This represents a dependency that is usually not shown on a CPM chart. There are some automated tools that attempt to address this problem by automatically allocating tasks to available resources. However, Ive never found that kind of allocation to be very useful o r accurate in a software project.

A more serious problem is that most dependencies in a software project are avoidable. It may make some kind of logical sense that you have to nish writing the login servlet before you start the logout servlet; but in reality you could write and test them in any order. Analysts often assert that you must complete the data model before you can start writing queries, but in fact the queries and data model can evolve together, and the business rules can often precede both. Architects often insist that you must design and implement the infrastructure before you can begin writing the application itself; but again weve found that application and infrastructure can evolve together.

So, as cool as the dependency charts are, they almost always represent a set of arbitrary and irrelevant decisions in a software project. This may explain why these charts so frequently become useless as the project proceeds (one team I consulted for referred to it as the laugh track). The tasks just dont just dont get done the way the dependency chart says they should. PERT was designed and used for huge projects involving thousands of contractors. Tasks were months long, truly parallel, and the dependencies were real. In this kind of environment it makes sense to create a dependency chart. It makes even more sense to use the best/nominal/worst estimation scheme and to calculate the probabilities. But for managing software projects at the man-day level the dependency charts make little sense at all. 52

2.6. MANAGING PROBABILITIES

2.6

Managing Probabilities

What does make sense in a software project is the management of probabilities. Not in the formal sense of PERT, but in the informal sense of Agile Project Management (APM). In APM the project is broken down into tasks that are in the few man-day range. These tasks are estimated, but not in absolute units like man-days. Rather they are estimated in terms of each other. One of the tasks is arbitrarily assigned a number of points (usually three) and then all other tasks are given a point value in terms of how much harder or easier they are than that reference task. The project is divided into iterations that are usually one or two weeks in length. At the beginning of each iteration stakeholders arrange the tasks in the order theyd like to see them implemented. The developers work down this list in the order specied. At the end of the iteration the team counts the number of points they completed. This number becomes their velocity for the iteration.

Figure 2.12: The velocity of the team Two bar charts are kept on the wall. Figure 2.12 shows the velocity of the team for each iteration, and gure 2.13 shows how many points remain in the project. Notice that the rst chart shows a random distribution of velocities around a mean of about 45 points per iteration. The second chart shows the eect of all this work on the project. Note, however that sometimes 53

CHAPTER 2. PROJECT PLANNING

Figure 2.13: The number of remaining points in a project the bars on the second chart dont shrink by enough, and sometimes they even grow. This is because new features are being added to the project, and the developers are re-estimating certain tasks based on better knowledge. The slope of the second graph is also a random distribution that predicts when the project will be done. Though it would be possible to calculate the probabilities, there isnt really much point. Given a nice straight ruler, the probabilities can be eyeballed with sucient accuracy for the kinds of decisions that need to be made. Given the charts above, a good software manager can make decisions about schedule, manpower, and scope and thereby manage the project to a desirable outcome.

2.7

Summary

Motivele pentru care este necesara planicarea unui proiect sunt urmatoarele: se reduc incertitudinile n creste ecienta realizarea proiectului membrii echipei de proiect nteleg mai bine obiectivele urmarite se stabilesc repere raport cu care se poate urmari si controla n derularea proiectului 54

2.7. SUMMARY se economiseste timp se realizeaza o ordine de prioritati a activitatilor cadrul proiecn tului. Project plans are aicted by uncertainties that turn schedules into random variables. Fortunately we can measure that randomness and use it to determine the probabilities that certain tasks will be complete by certain dates. Once we know the probabilities, we can manage the project by adjusting scope, manpower, and schedule so that the probability of a desirable outcome remains high. PERT is a scheme for managing probabilities for very large and complex projects, however it does not scale down to the level at which most software projects are planned. CPM has all these failings for software, and also ignores the randomness inherent in planning software systems. Agile Project Management (APM) is well suited for the kinds of tasks that populate most software project plans. It also captures and characterizes the randomness and uncertainty that are inherently part of those projects. By using APM, managers have constant and accurate data with which to manage the project.

55

Chapter 3

Managementul calitatii

3.1

Introducere

Conceptia moderna despre calitate priveste acest concept n dinamica sa si leaga calitatea produsului sau serviciului de calitatea conceptiei (proiectului) si calitatea fabricatiei. Conform standardelor ISO, calitatea fabricatiei reprezinta gradul de conformitate a produsului cu documentatia tehnica. Iar calitatea proiectului exprima masura n care proiectul produsului asigura satisfacerea cerintelor beneciarilor si posibilitatea de folosire, la fabricatia produsului a unor procedee tehnologice rationale si fezabile din punct de vedere economic (gura 3.1).

Figure 3.1: Calitatea produsului software unde: A = cerintele beneciarului; B = caracteristicile calitatii prevazute n documentatia tehnica; 57

CHAPTER 3. MANAGEMENTUL CALITATII C = caracteristicile produsului; 1 = calitatea conceptiei; 2 = calitatea fabricatiei; 3 = calitatea produsului (sau serviciului). La aceste notiuni se adauga si conceptul de calitate livrata. Aceasta se refera la nivelul real al calitatii produsului sau serviciului, n momentul achizitionarii de catre beneciar.

3.2

Calitatea produselor software particularitati

Daca societatea contemporana este o socie-tate a calitatii, atunci ea este, n aceeasi masura, o societate a informatiei si a tehnologiei informatiei. n industria de software, ntlnim aceeasi concentrare pe produs a conceptiei, execu-tiei, asigurarii si vericarii calitatii, ca n faza preindustriala, dar, pe de alta parte, datorita complexitatii produsului rezultat, exista grupul de executanti, mpartit n colective sau indivizi specializati, care ac-tioneaza pe parcursul unor nlantuiri de faze (ciclu de viata). Modelul de productie n industria software este un model de productie a proiectelor. Particularitatea consta n faptul ca activitatile desfasurate pot specice unei anumite faze a ciclului de viata, sau pot independente de fazele ciclului de viata [1]. Importanta calitatii produselor software re-zida n cel putin trei aspecte: erorile din programele de aplicatie pot fatale n a-numite domenii unde vietile oamenilor depind de acestea; aceste erori pot provoca pierderi nanciare, materiale si tot felul de alte tipuri de insatisfactii sau pierderi; daca n domeniul produselor hardware costurile au o tendinta generala de scadere, n do-meniul dezvoltarii de software, desi pro-ductivitatea a crescut substantial, nu se n-registreaza si o scadere a costurilor care sa duca la aceeasi tendinta. Acest ultim aspect se datoreaza particula-ritatilor prin care calitatea se manifesta n domeniul produselor software, asa cum sunt ele relevate n [44]: 58

3.2. CALITATEA PRODUSELOR SOFTWARE PARTICULARITATI comportamentul instructiunilor nu se deterioreaza n timp; erorile sunt provocate de folosirea sau combinarea incorecta a componentelor elementare, si nu de aceste componente n sine; interactiunile dintre componentele unui program sunt, mai complexe, mai ales daca acestea ruleaza n cadrul unor aplicatii complexe; erorile exista deja n program, ele sunt eliminate cu timpul, prin depanare, deci programul se mbunatateste prin trecerea timpului; eliminarea unei erori nu da siguranta ca s-a diminuat numarul total de erori cu o uni-tate; non-calitatea programelor poate atri-buita n ntregime greselilor umane, de proiectare, conceptie, programare, docu-mentare. Un manager preocupat de calitatea produ-selor software trebuie sa posede, conform [47], anumite abilitati speciale si chiar calitati native, cum ar : sa observe ce se ntmpla si sa nteleaga semnicatia propriilor observatii; sa se poata comporta si sa poata actiona congruent n situatii interpersonale dicile, chiar si cnd este derutat, suparat sau speriat; sa poata nte-lege situatiile complexe. Aceasta ultima abilitate permite sa se poata planica un proiect si apoi sa se observe si sa se actio-neze astfel nct proiectul sa decurga conform planului sau sa poata modicat conform cerintelor si schimbarilor aparute pe parcurs. Calitatea produselor software este denita n [9] ca masura n care acestea satisfac cerintele utilizatorilor prin carac-teristici tehnice, economice si psiho-soci-ale. Aceasta denitie se bazeaza pe doua concepte care, puse n legatura, dau masura calitatii unui produs software, si anume cerintele utilizatorilor si caracteristicile produsului. 59

CHAPTER 3. MANAGEMENTUL CALITATII

3.3

Principii de proiectare a proceselor de dezvoltare software

Masura fundamentala a oricarui proces cu feedback controlat este posibilitatea de a compara ceea ce a fost planicat a se rea-liza, cu ceea ce s-a realizat n fapt. Proiec-tarea proceselor de dezvoltare software are la baza doua activitati: analiza riguroasa a cerintelor si speci-catiilor, fara de care nu se poate face o evaluare asupra dimensiunilor, efortului de realizare si a obiectivelor privind calitatea; planicarea masurabilitatii proceselor si produselor software intermediare si nale, fara de care nu se poate asigura nici gestiunea si nici managementul operational al calitatii. Desi evolutiile lumii reale determina modi-carea continua a cerintelor chiar si n tim-pul procesului de realizare a proiectului, ceea ce conduce, la un dialog permanent ntre producatorul de software si bene-ciar, procesul iterativ de aproximare a ce-rintelor trebuie sa ngusteze aceasta tendin-ta si sa o ndrepte catre ceva ce se poate naliza si pune n opera. Asa cum se arata n [49], clientii cum-para sau accepta produsele software att timp ct: 1. i ajuta n rezolvarea proble-melor; 2. i ajuta n sesizarea oportuni-tatilor de mbunatatire a propriei activitati; 3. le ofera o imagine buna pe piata, n fata clientilor lor cei mai semnicativi; 4. le usureaza munca si contribuie la mbu-natatirea comfortului acesteia. Aceste ele-mente constituie motive puternice pentru focalizarea atentiei echipei de dezvoltare software n directia sesizarii corecte a pro-blemelor si oportunitatilor clientului. n cadrul managementului calitatii totale, n vederea livrarii catre clienti a unor produse de valoare, s-a dezvoltat n Japonia, me-todologia desfasurarii (explicitarii) functiei calitatii - Quality Function Deployment - QFD - ca o structura sosticata, cu mai multe subsisteme. Instrumentele si tehni-cile acestei metodologii sunt aplicate n prezent n proiectele de dezvoltare de hard-ware, servicii si software. 60

3.3. PRINCIPII DE PROIECTARE A PROCESELOR DE DEZVOLTARE SOFTWARE Planicarea masurabilitatii si a ceea ce se va masura pentru managementul calitatii este un element esential al proiectarii gestiunii calitatii, n cadrul oricarui proiect de dezvoltare de software. Aceasta presupune desfasurarea unui set minimal de activitati care sa puna bazele unui mana-gement de calitate si ale producerii de soft-ware de calitate. Premisele realizarii unui proiect masurabil sunt, dupa opinia ex-primata n [46]: compunerea proiectului din procese masurabile; un sistem de creare si ntretinere a unei vederi globale publice (rapoarte, scheme, reprezentari grace) asupra progresului realizat n domeniul calitatii proiectului; un sistem de cerinte bine ntocmite, care documenteaza tot ceea ce furnizorul si beneciarul nteleg - de comun acord - prin calitatea produsului software; un sistem de revizii si inspectii care sa masoare orice evolutie a calitatii proiec-tului. Realizarea oricarui proiect presupune mu-tatia unui sistem dintr-o stare A (initiala), ntr-o stare B (starea nala dorita). O ase-menea transformare nu poate facuta fara perceperea exacta a starii A, cunoasterea cerintelor pentru starea nala B si cunoas-terea realitatilor starilor A si B. Gerald Weinberg recomanda n [46] urmatorii pasi pentru proiectarea generala a unui sis-tem de procese care sa duca la realizarea cu succes a unui proiect masurabil de dezvoltare de software si sa permita tot-odata managementul calitatii: Pregatirea pentru o succesiune de pro-cese iterative. Odata cu denirea completa, fara ambiguitati si corecta a proiectului, orice manager trebuie sa e pregatit (cel putin psihologic) pentru viitoarele ranari si redeniri; 61

CHAPTER 3. MANAGEMENTUL CALITATII Identicarea clientilor si valorizarea optiunilor acestora. ncepnd proiectul cu clientii si valorizndu-le corespunzator optiunile si cerintele, aceasta presupune deja plasarea problemei calitatii pe creasta valului; Selectarea obiectivelor posibile de atins. Formularea obiectivelor trebuie sa e clara si, exprimata n termeni nenegativi. De exemplu, n locul formulei: Proiectul nu va putea sa depaseasca bugetul alocat, se poate opta pentru formula: Proiectul va avea un buget si un set de cerinte stabilite, de comun acord, de managerii organizatiei si de managerii proiectului, nainte de nceperea acestuia. Proiectul se va executa n conditiile ndeplinirii setului de cerinte si n limita bugetului aprobat. Stabilirea obiectivelor ntr-o maniera masurabila. Stabilirea n acest mod a o-biectivelor presupune existenta unui ras-puns clar la orice ntrebare de genul: Cum se poate dovedi ca obiectivul X a fost atins?. De aceea, n formularea obiecti-velor trebuie evitate fraze cu un nteles vag precum: Se va actiona n directia cresterii calitatii si productivitatii. Stabilirea obiectivelor trebuie facuta cu constrngeri minime asupra proiectului. Se recomanda evitarea formularii unor obiective de genul: Testarea produsului software se va face pe 100 statii de lucru IBM, care vor instalate pna la data de 20 martie. O alternativa care duce la mi-nimizarea presiunilor asupra proiectului poate : Produsul software va testat pe 80 pna la 100 statii de lucru. Toate statiile de lucru vor identice, iar conguratia aleasa trebuie sa e cea recomandata de furnizorii urmatoarelor produse software ..... Vericarea posibilelor obstacole. Trebuie sa se alcatuiasca o lista care sa cuprinda ct mai multe posibile obstacole ce pot sta calea n realizarii obiectivelor. Ulterior, ecare posibil obstacol va analizat 62

3.3. PRINCIPII DE PROIECTARE A PROCESELOR DE DEZVOLTARE SOFTWARE si se va stabili daca poate ntr-adevar un obstacol, precum si posibile cai de depasire a acestuia (gura 3.2).

Figure 3.2: Obstacole si cai de rezolvare Vericarea resurselor. Acesta este un pas peste care multi manageri de proiect trec cu usurinta, avnd vedere faptul ca resursele n umane, nanciare si materiale, sunt cuprinse planurile proiectun lui. De exemplu, daca clientul face urmatoarea armatie: Doresc o interfata utilizator foarte prietenoasa, care sa faciliteze ope-rarea, dar la ntrebarea producatorului Ct timp puteti aloca pentru a deni exact cerintele dumneavoastra ceea ce priveste aceasta inn terfata prietenoasa, clientul raspunde: Sunt prea ocupat pentru a face acest lucru. Voi faceti interfata si apoi voi mai explicit cnd voi vedea rezulatul, acest raspuns releva cel putin doua aspecte: pe de o parte interesul clientului rea-lizarea interfetei respective n nu este prea arzator, iar, pe de alta parte, clientul nu poate luat considerare ca o resursa pentru proiect (ceea ce este mai n grav). Planicarea inversa. Pentru a putea planica invers, este necesar ca, mai nti, sa existe o imagine clara a starii B (starea nala dorita). Pornind napoi ctre starea initiala A, se identica o stare intermediara C, din care starea B este cel mai probabil de atins, si asa mai departe: A - E - D - C - B. Desigur ca nici un plan real nu poate liniar. Planicarea inversa poate ecienta conditiile care: n n 63

CHAPTER 3. MANAGEMENTUL CALITATII lungimea grafului este sucient de mica, astfel elermentele nct de incertitudine sa e diminuate; planicarea trebuie sa e incrementala, pasi realisti, astfel n nct, daca sistemul nu a atins starea intermediara dorita, sa poata corectat pasul urmator. n

3.4

Conceptul de software corespunzator pentru utilizare

Fiecare client are preferinte individuale, care pot satisfacute prin caracteristici de calitate diferite. Aceasta relatie se reecta puternic inn dustria de software. Astfel, alaturi de unii factori ai caracteristicii de exibilitate, se arma tot mai mult posibilitatea de personalizare a produselor software, ca o caracteristica de calitate tot mai apreciata. Pentru satisfacerea cerintelor, este impor-tant ca relatia calitate-cumparator sa e puternic reectata nu numai denirea calitatii, dar si mann n agementul si ges-tiunea acesteia, deoarece cumparatorul ho-taraste, n nal, ce este calitatea. Astfel, specicatiile, ca reectari ale cerintelor identicate si denite ale beneciarilor, nu reprezinta criterii de calitate absolute, ci numai mijloace necesare pentru satisfa-cerea asteptarilor. n cazul managementului total al calitatii, relatia client-furnizor este generalizata prin internalizarea ei. Trecerea de la un proces la altul, de la o etapa la alta, este abordata conform principiului urmatorul proces este clientul. Cele trei componente ale managementului calitatii totale sunt mbu-natatirea continua; satisfacerea utilizato-rilor si avansul organizatiei. Tehnicile ma-nageriale pentru realizarea lor sunt contro-lul statistic al proceselor (Statistical Pro-cess Control-SPC), desfasurarea functiilor calitatii (Quality Function Deployment-QFD) si explicitarea politicii (Policy De-ployment- PD). 64

3.5. COSTUL CALITATII

3.5

Costul calitatii

How high is your Cost of Quality? The answer might surprise you. Yes, it includes reviews, the QA infrastructure, and preparing teststhose are your Appraisal Costs. But how high are your Failure Coststhe cost of defects? Your engineers spend time in diagnosis and rework, development schedules slip, support costs climb, and your companys and products reputations sink. These Failure Costs, which are the more signicant Cost of Quality, are beyond your direct control. But you can gain control over them indirectly, by investing in Appraisal Costs that minimize Failure Costs, reducing your total Cost of Quality and making it more predictable.

3.5.1

Cost of Quality: Appraisal vs. Failure Costs

The Cost of Quality is a signicant cost on any project, so prudent managers look for ways to keep those costs in check. The Quality costs we can control are things like performing reviews, preparing tests, and maintaining our QA infrastructure; Appraisal Costs. But there are also the Quality costs we cannot control. Failure Costs are the ones that happen to us. We incur these Costs of Poor Quality every time a defect comes to light, both during testing and after release. Failure costs take many forms: The eort that our developers spend investigating and diagnosing defects, and then reworking designs and code to correct them. Slips in our schedules, as testing uncovers defects that require rework and re-testing. Our customer support costs, most of which are for helping customers to deal with all of the defects we shipped to them, while developers spend even more time in investigation and rework. 65

CHAPTER 3. MANAGEMENTUL CALITATII But, the biggest Failure costs are nearly impossible to quantify; loss of customer good will, tarnished reputation in the market, and loss of product momentum. Since some components of the Cost of Quality are under our direct control and others are not, it seems to make sense to reduce those costs that we can, and hope for the best with those that we cannot control. Unfortunately, a focus on reducing Appraisal costs can increase our total Cost of Quality, because it is likely to result in an even larger increase in Failure costs. As reported consistently in our industry, Failure Costs rise exponentially as the project progresses. Reducing Appraisal activities delays the detection of defects, ensuring that they are much more expensive to address when they are detected.

3.5.2

Leveraging Appraisal to Reduce Failure Costs

Most organizations depend upon the compiler and various types of testing to remove most or all of the defects from their products. But as we can see from Figure 1, these are not the most eective methods of removing defects. They each tend to detect no more than 50 Contrast this with the various kinds of Reviews and Inspections. They are relatively more eective, not only because they can detect 60-80 The Cost of Quality column indicates whether the majority of the time in that activity is spent appraising or dealing with failures. (It is important to realize that only the rst compile is not failure-related. If there were no defects, we would have to run the compiler only once. By the same token, only the rst run of any test is not failure-related. All diagnosis, rework and re-testing is necessitated by failures.) The Eectiveness column indicates both the percentage of defects that are likely to be detected and the total cost in engineer-hours to detect, diagnose, and remove each defect. The placement of Reviews and Inspections in the list is based on best practices. In some cases, their eectiveness is quite low. 66

3.5. COSTUL CALITATII Table 3.1: Appraisal vs. Failure Activities Activity Cost of Quality Structured Personal Reviews Appraisal Formal (Fagan) Software Inspections Appraisal Compiling Failure Unit Testing Failure Integration Failure Beta Testing Failure System Testing Failure (and performance & other testing) Acceptance Testing Failure Walkthroughs Appraisal

Eectiveness *********** ********** ******** ******* ****** ***** **** *** *

The order of Compiling, Unit Testing, Integration, Beta Testing, System Testing and Acceptance Testing in the above list really does indicate their relative eciency in removing defects (not just their lifecycle order). The placement of Unit Testing in the list is based on best practices. Many developers have never been trained in testing, and are ineective at it. Walkthroughs are more eective for training purposes than for defect removal. These economics point us toward the principle of leveraging Appraisal Costs (the ones we directly control) in order to reduce Failure Costs (the ones that are less controllable). And this principle leads us to the counterintuitive proposition that if we wish to achieve dramatic reductions in our total Cost of Quality, we must increase Appraisal Costs dramatically. Does this proposition really work? Consider that all ALL of our Failure costs (every dollar of them) are caused by a nite number of defects in our software. Every defect that we can remove more economically than we currently do represents money on our companies bottom lines. Every defect we can remove in a more timely way represents hours or days (or weeks!) of schedule saved. 67

CHAPTER 3. MANAGEMENTUL CALITATII Every defect that we avoid shipping to our customers reduces support costs, and every useful feature that we do ship is priceless good will that builds our companies reputations and market share. Reviews and Inspections are the most economical way to detect and remove defects. Testing is a relatively less eective way to remove defects, but it is still a necessary part of our development lifecycle. Rather than continuing to make it our main defect removal mechanism, we would do better to use it to verify the eectiveness of our earlier primary defect removal activities: reviews and inspections.

3.5.3

Being In Control

The only way to be in control of our total Cost of Quality is to shift it from the uncontrollable Failure Costs to the controllable Appraisal Costs. With each incremental increase in Appraisal activities like reviews (assuming they are done well), we can expect a corresponding and larger reduction in our Failure activities. If we carry this principle to its logical conclusion, we will nd ourselves in the enviable position of having shifted the majority of our Cost of Quality to the Appraisal side of the equation! This will mean that our Cost of Quality will not only be reduced signicantly, but it will also be more predictable and more manageable. Instead of happening to us, our Quality Costs will be a tool that we can wield to control our projects and assure their success.

3.6

Concluzii

n poda timpului scurt scurs de la nas-terea industriei de software, se apreciaza ca ecare sablon al acestei culturi organi-zationale evolutive, descrise prin nivelele de maturitate ale modelului Maturitate/Ca-pabilitate dezvoltat la Software Engine-ering Institute - S.U.A., a avut propria contributie la dezvoltarea industriei software - de la a face calculatoarele mai 68

3.6. CONCLUZII Table 3.2: ISO/IEC ISO 9126-1 ISO 9126-2 ISO 9126-3 9126 - Caracteristici si metrici ale calitatii software Caracteristici si subcaracteristici de calitate Metrici externe Metrici interne

Table 3.3: ISO/IEC 14598 - Evaluarea produselor software ISO 14598-1 Generalitati ISO 14598-2 Planicare si management ISO 14598-3 Proces pentru dezvoltatori ISO 14598-4 Proces pentru achizitori ISO 14598-5 Proces pentru evaluatori ISO 14598-6 Documentatia pentru modulele de evaluare putin nspaimntatoare pentru publicul larg, pna la a oferi modalitati de dezvoltare si tinere sub control a unor proiecte de dimensiuni mari. Asa cum se prezinta [7], n ncepnd cu anul 1998, evaluarea si certicarea produselor software va benecia de doua noi serii de standarde, ISO 9126 si ISO 14598: Dincolo de modelele oferite de literatura de specialitate, de diferite institute si or-ganizatii (ISO, SEI, IEC), rezulta ca ma-nagementul calitatii este principalul factor care contribuie la statuarea meta-modelului calitatii software, aplicabil nu att la ni-velul organizatiilor producatoare de soft-ware, ct la nivelul ntregii industrii. Acest meta-model al calitatii software nu repre-zinta doar mbunatatirile incrementale ce apar de la luna la luna sau de la an la an domeniul analizat, ci consta acumun n larea solida a micilor pasi ce construiesc drumul mbunatatirii calitatii, de-a lungul istoriei acestei industrii. Indiferent de denirea si operationalizarea managementului calitatii, asa cum se arata [7], productia de software si furni-zarea de servicii n informatice asociate de-pind mare masura de managementul efectiv n al efortului intelectual, si nici o natiune nu-si poate permite sa aiba o in-dustrie de software care sa produca altceva dect software de calitate. 69

Chapter 4

Managementul riscului

4.1

Introduction

Despite much research and progress in the area of Software Project Management, software development projects still fail to deliver acceptable systems on time and within budget. Much of the failure could be avoided by managers pro-actively planning for and dealing with risk factors rather than waiting for problems to occur and then trying to react. Usually this reaction is too little and too late, because by the time the problem is fully recognized, the schedule has already slipped, a considerable investment has been made, and the product quality has suered due to introduction of errors or work-arounds. Risk management has been proposed as a solution to provide insight into potential problem areas and to identify, address, and eliminate them before they derail the project. In order to implement a successful risk management program, project managers need tools to help them. One possible tool is collecting measurements and using them as part of a metrics program. A good measurement program helps managers [3]: communicate unambiguously throughout the organization identify and correct technical and management problems by focusing on early discovery make key tradeos by assessing the impact of decisions track the status of processes and products against program objectives 71

CHAPTER 4. MANAGEMENTUL RISCULUI defend and justify decisions by providing data to explain how issues are prioritized and managed Despite the acceptance of a metrics program as a project management tool, it is rarely discussed as a risk management tool. This seems an oversight. This paper will briey discuss measurements and metrics as a project management tool, and look at several risk management methodologies and their enabling tools. Then it will propose that there are overlapping areas where a good metrics program can be used as a tool for portions of the risk management process. Selecting a potential risk area, this paper will give examples of ways in which metrics can help identify and track risk.

4.2

Project Management Metrics

Much attention has been focused recently on software measurement. By collecting, analyzing and using measurement data, software project managers are more able to have visibility into and control over their projects. Measures and the metrics that can be derived from them allow the managers to determine the status of their programs, track the projects progress against the plan, measure the quality of the product being developed, and become aware of potential problems. Using this data can allow managers to have objective information which helps them make the daily decisions necessary to run their projects. Collecting this data also helps them by providing the basis for possibly improved estimates for future projects. Most discussions on starting metrics programs stress that the measures chosen to be collected should be simple, and if possible be those already being collected for other uses. There are two reasons for this. First, managers and developers can balk at initiating a metrics program because they feel that measurement collection is time consuming, peopleintensive, and expensive and distracts workers from their primary task of developing software. Collecting measures can add anywhere from ve 72

4.2. PROJECT MANAGEMENT METRICS to ten percent to the development cost of a program [39], so if a program can reuse data that is already being collected, e.g., timecard or nancial data, the process is less expensive and more liable to be accepted. Secondly, collecting low level, simple data allows managers to use it in a variety of dierent analyses, allowing for more exibility. It also allows managers to combine dierent measures to obtain a better metric which may tell them more than any measurement alone. Project managers need to select a measurement and metrics set that is appropriate for their project, and not pick a set and then try to apply their project to that set. There are many measures and derived metrics that can be proposed, but it should be the program management and technical issues and objectives that drive the measurement requirements. Whatever set is chosen, it should be easy to collect and analyze, cover all phases of the life cycle, give management the desired insight into the project, and deal with specic, dened issues or attributes of the program. There are two perspectives, feasibility and performance, which should be considered during measurement analysis. Feasibility is more static, and concerns dealing with the accuracy and realism of plans, estimates, or assumptions associated with an issue. Performance is more dynamic, dealing with the adherence to those plans, estimates and assumptions [3]. There are many metric sets proposed throughout DoD and in Software Engineering literature, and following is one very simple set of core attributes which drive the list of measures to collect [19]: size eort schedule software quality rework 73

CHAPTER 4. MANAGEMENTUL RISCULUI Most metric sets deal with a variation of these attributes and are chosen to help project managers gain insight into their product (size, software quality, rework), process (rework, software quality) and project (eort, schedule).

4.3

Risk Management Survey

Software development risk has been dened as the exposure to one or more of four types of risk [2]: performance risk, or the failure to obtain all of the anticipated benets of the systems and software under development cost risk, or signicantly exceeding budgeted or estimated cost schedule risk, or the failure to deliver satisfactory software products by scheduled milestones and user need dates support risk, or the delivery of a product that has excessive life cycle maintenance costs due to deciencies in maintainability, exibility, compatibility or reliability Risk management has been dened as the practice of controlling risks that have the potential for causing unwanted program eects [17]. This control is an entire development life cycle activity, starting with planning for risk at the earliest stages of the project and continuing with monitoring and alleviating risk though the support stage. Several risk management methodologies have recently been oered in the literature. The following is an overview of several approaches, with at brief look at the tools that have been proposed to aid those processes.

4.3.1

Barry Boehm

Barry Boehm is a pioneer in software risk management, developing his risk management methodology in conjunction with his risk driven spiral 74

4.3. RISK MANAGEMENT SURVEY development model [11, 12]. Boehm oers a six step risk management process, composed of two main steps, each divided into three sub-steps: risk assessment, consisting of identication of those risks likely to cause problems analysis to determine the loss probability and loss magnitude for each risk and to develop a compound risk prioritization to rank the identied risk items according to their compound risks risk control, consisting of management planning to bring the risk items under control resolution to eliminate or resolve the risk items monitoring to track the projects risk reduction progress and to apply corrective action where necessary. Boehm discusses sample tools for use at each of his steps, ranging from checklists to cost models to cost-benet analysis. No mention is made of any standard project management metrics as a potential tool for aiding risk managers. The Rand Corporation has developed an excellent Guide for the Management of Expert Systems Development using Boehms risk driven spiral model [29]. In this guide, expert system development is evolutionary, taking place through six phases: initiation, concept, denition/design, development, deployment, and post-deployment. For each phase, the guide discusses the risk containment activities, but no tools are recommended. The Software Engineering Institute (SEI) has also developed a risk management guidebook for software acquisition managers, with steps very similar to Boehms [24]. In Appendix C of the guidebook, there is a list of recommended tools for each step in risk management. Under Planning Methods and Tools, Goal-question-measure, which is used to 75

CHAPTER 4. MANAGEMENTUL RISCULUI dene a set of measures, is listed as a method or tool, and under Tracking Approaches is the use of spreadsheets or graphs to track those metrics selected.

4.3.2

Richard Fairley

Richard Fairley oers a seven step risk management process based on his work identifying and overcoming risk factors on software development projects with various organizations [20]. His process starts much like Boehms, but unlike Boehms Fairleys process seems to assume that some risk items will overtake the project and require remedial action. The steps of his process are: identify the risk factors assess risk probabilities and eects on the project develop strategies to mitigate identied risks monitor risk factors invoke a contingency plan when a quantitative risk factor crosses a predetermined threshold manage the crisis by possibly drastic corrective action if the contingency plan fails recover from a crisis, e.g., by rewarding personnel, reevaluating schedule and resources Outside of assorted plans and his mathematical model for determining risk probabilities and eects, Fairley discusses no tools or tool methodology. 76

4.3. RISK MANAGEMENT SURVEY

4.3.3

F/A-18E/F Risk Management Process

In the latest update of the DoD series 5000 acquisition documents, DoD required risk management in all defense programs [17]. An example of one such risk management process is that of the F/A-18E/F [4], which contains the following four steps performed in a continuous feed-back loop: risk identication risk analysis by quantifying the risks and determining overall risk level risk planning by developing a list of risk mitigation tasks risk tracking via monitoring and updates Under risk identication, this approach asks, What causes a risk to be surfaced? and then suggests a set of tools including negative trends or forecasts along with a set of metrics.

4.3.4

Rockwell Risk Management Process

Another management process, based on the principles of Dr. Robert Charette, is that of Rockwell [5], which is made up of ve steps: identify risks characterize risks prioritize risks avert risks track/control risks This methodology is tool-based and lists many tools for possible use for each of these ve steps, but none is related to common project management metrics. 77

CHAPTER 4. MANAGEMENTUL RISCULUI

4.4

Where Risk Management and Metrics Overlap

The risk management processes surveyed above have several steps in common. All start with the identication of risk items, followed by some method of weighting and prioritizing those risks, moving to developing strategies to mitigate risks when and if they occur, and ending with some way of planning for and tracking or monitoring risks. Looking at the common steps through the processes, and looking at the applications of a metrics program, it seems there are two places where basic project management metrics can be applied: identifying risk, and planning for and tracking some risk items. Furthermore, there are two ways in which metrics can help with risk identication. Using feasibility analysis, measures can be used at the initial risk identication step to help managers create a risk list. Since risk identication should be an ongoing task that happens throughout the life cycle, using performance analysis and looking at negative trends can alert managers to a risk area that might not have been previously identied.

4.5

Selecting a Sample Measure

In order to show this connection between metrics and risk management, we need to select an example from common software development risks while keeping in mind the initial set of core attributes listed above in the metrics discussion. Boehms list of the top ten risk items based on a survey of several experienced project managers are [12]: personnel shortfalls unrealistic schedules and budgets developing the wrong functions and properties 78

4.5. SELECTING A SAMPLE MEASURE developing the wrong user interface gold plating continuing stream of requirements changes shortfalls in externally nished components shortfalls in externally performed tasks real-time performance shortfalls straining computer-science capabilities In the Guide for the Management of Expert Systems Development a sample set of ten prioritized risk items is given for each of the six phases of development. For each phase the top priority risk is personnel shortfall, the same as Boehms number one risk item. In Toward an Assessment of Software Development Risk, the authors attempt to develop a conceptual denition of and an initial measure for the construct of software development risk. As part of their study, they reviewed several other studies that had looked at and identied risk items that threatened project success. As part of this study, they found a strong degree of resemblance between what many authors had labeled risk factors and what others called uncertainty factors in IS. They looked at these risk factors and uncertainty factors, grouped them according to their shared meanings, and identied their underlying concept. They came up with eighteen underlying concepts of which nine, or one-half, are personnel related [8]: technical newness, which deals with experience with the technology team size team diversity team expertise (software development) 79

CHAPTER 4. MANAGEMENTUL RISCULUI team expertise (application) team expertise (task) team expertise (in general) experience of leader conicts, which deals with interpersonal conicts as well as conicting preferences Looking at Boehms list, the Rand work and this study, it seems that if one is to pick a risk item that is prevalent across all, personnel shortfalls is the one. In addition, since software development is such a labor intensive enterprise, personnel shortfalls can have a major impact. Sta hours are the primary means of planning and tracking human resources assigned to various tasks and activities. Tracking sta hours allows for accurate scheduling and resource allocation and allows managers to assess the impact of personnel changes on cost and schedule. Based on these reasons, this paper uses personnel issues as its example.

4.6
4.6.1

Sample Metric Discussion

Identifying Risks with Metrics

One simple measure that can be collected is sta level, sometimes called personnel, which counts the total number of software personnel available for a project. At initial risk identication, this measure can be used in a feasibility analysis and compared against the estimated stang level. The results can give managers an indication of whether they will have enough personnel for a project or whether they will have to start looking for new team members. However, this measure by itself will probably not give sucient insight to help identify all personnel shortfall risks. Two further renements of 80

4.6. SAMPLE METRIC DISCUSSION this measure are software development sta prole and software development personnel qualication, sometimes also called sta experience [21]. Software development sta prole is composed of several components which managers can measure and assess during the risk identication period: sta level, which deals with actual availability for the project and considers whether a team member is full or part time, will be transferring before the project is over, going on family leave, etc. All this data is measurable and can be plotted against estimated sta requirements. sta availability, which deals with whether the team member is actually available, in place and trained at the appropriate time of the development life cycle historic project and company retention rates, which can help project managers predict whether their team will be intact throughout the project, or whether they should plan for turnover and build sucient slack in their estimates sta mix, which measures distribution by activity such as Quality Assurance (QA) and Conguration Management (CM), and helps managers determine whether they have enough people for each task Another measure is sta experience, or software personnel qualication, which deals with individual team members prociencies. Referring back to the list of underlying risk factors developed by the authors in Toward an Assessment of Software Development Risk, team expertise is listed in four dierent categories as potential risk factors. Sta experience or qualication level can refer to several dierent things: educational level 81

CHAPTER 4. MANAGEMENTUL RISCULUI years of experience with the company, indicating a knowledge of company standards as well as loyalty and dedication years of software development experience years of experience in the domain years of experience in the language years of experience on similar projects amount of specialty training years of relevant specialty training All of this measurement data is available to managers who are trying to assess whether their team has sucient experience to complete the planned project. None of this experience necessarily guarantees capability, but these types of measurements give managers a tool to determine whether their proposed team members can perform the tasks required of them. Since risk identication is an ongoing process, measures like the above can periodically be reviewed if other indicators point to stang problems. Managers must be careful to include any experience obtained on the current project is an interim analysis is done.

4.6.2

Tracking Risks with Metrics

Once managers have built their teams and the project has begun, their metrics programs allow them to track the progress of the project, product and process. The metrics programs also oer insight into those areas that were identied as potential risk items in the early planning stage. Once they have begun to collect data, managers can begin to use performance analysis and look for trends to indicate whether or not a risk item is under control, as well as to indicate that a new, previously unidentied item may be becoming a risk. 82

4.6. SAMPLE METRIC DISCUSSION The following is an example that discusses tracking the two personnel issues discussed above, sta level and sta experience [41]. Figure 4.1, to which the discussion refers, is further presented.

Figure 4.1: Software Personnel Indicator Assume that personnel shortfalls were originally identied as a risk item, and that the project manager is closely tracking his personnel. The project manager should have plotted the planned stang proles for the total sta and for the experienced sta at the beginning of the contract. As time passes, some deviation from the curve is expected, but too great a deviation is cause for alarm. A program that does not have enough experienced personnel or that tries to bring too many into the project toward the end of the schedule is a project that is at risk. When looking at the shape of the planned software sta curve, it should grow through the requirements and design phases, peak in code and early test, and begin to fall as acceptance and integration tests are completed. The prole of the experienced sta should be high in the beginning of the project, decrease slightly during coding and increase again during test. The ratio of experienced personnel should be near to 3:1, but never 83

CHAPTER 4. MANAGEMENTUL RISCULUI exceed 6:1. As discussed above, the sta level refers to the ability of the developer to maintain a sucient level of sta to complete the project timely. In addition to tracking total sta, tracking experienced sta is also important as they are crucial to maintaining schedule and product quality. Finally tracking sta losses is important because sta turnover can impact the stability of the work force. Even though a team member leaves and is quickly replaced, there is usually an impact due to the earning curve while that new person is trained and acclimates to the existing team. This sample chart is made up of only three measures, total sta level, experienced sta level, and unexpected sta losses. Nevertheless, it shows several things to a manager. Initially, the total number of personnel on the project was lagging behind the estimate, but the number of experienced personnel working on it was higher than planned. This could mean that there were problems getting enough personnel to work on the project at rst and the shortage was being covered by a higher than planned number of experienced sta. It could also mean that the schedules can be maintained and the project is on track, but it may be at the expense of cost, since experienced personnel are usually more expensive. The manager should continue to monitor this. The number of unplanned losses is nominal and does not seem to indicate any problems or risks. However, the number of experienced personnel is beginning to fall faster than the unplanned turnover rate. This may be a risk if the project is starting into the testing phase. Again, the manager may want to look at other measures or begin to track this item more closely. There are variations of this metric that can also be used to give the manager further insights. These include reporting stang separately for each development task, e.g., QA, CM, or testing; and reporting stang separately for special skills, e.g., Ada, client-server, or database development. Normally, understang as seen in Figure 1 indicates a possible sched84

4.7. A SAMPLE RISK MANAGEMENT STANDARD ule slippage that must be further tracked. The manager would do well to also look at the schedule and other indicators to assess the impact. If the project does continue to slip due to a personnel shortage, adding new personnel is not necessarily the answer, as this may add further delays due to the learning curve [14]. If the turnover rate becomes too high, this could also become a major risk due to lack of continuity, impairing project knowledge and eroding the knowledge-base.

4.7
4.7.1

A Sample Risk Management Standard

Introduction

This Risk Management Standard is the result of work by a team drawn from the major risk management organisations in the UK - The Institute of Risk Management (IRM),The Association of Insurance and Risk Managers (AIRMIC) and ALARM The National Forum for Risk Management in the Public Sector. In addition, the team sought the views and opinions of a wide range of other professional bodies with interests in risk management, during an extensive period of consultation. Risk management is a rapidly developing discipline and there are many and varied views and descriptions of what risk management involves, how it should be conducted and what it is for. Some form of standard is needed to ensure that there is an agreed: terminology related to the words used process by which risk management can be carried out organisation structure for risk management objective for risk management Importantly, the standard recognises that risk has both an upside and a downside. 85

CHAPTER 4. MANAGEMENTUL RISCULUI Risk management is not just something for corporations or public organisations, but for any activity whether short or long term.The benets and opportunities should be viewed not just in the context of the activity itself but in relation to the many and varied stakeholders who can be aected. There are many ways of achieving the objectives of risk management and it would be impossible to try to set them all out in a single document.Therefore it was never intended to produce a prescriptive standard which would have led to a box ticking approach nor to establish a certiable process. By meeting the various component parts of this standard, albeit in dierent ways, organisations will be in a position to report that they are in compliance.The standard represents best practice against which organisations can measure themselves. The standard has wherever possible used the terminology for risk set out by the International Organization for Standardization (ISO) in its recent document ISO/IEC Guide 73 Risk Management - Vocabulary Guidelines for use in standards. In view of the rapid developments in this area the authors would appreciate feedback from organisations as they put the standard into use (addresses to be found on the back cover of this Guide). It is intended that regular modications will be made to the standard in the light of best practice.

4.7.2

Risk Management

Risk management is a central part of any organisations strategic management. It is the process whereby organisations methodically address the risks attaching to their activities with the goal of achieving sustained benet within each activity and across the portfolio of all activities. The focus of good risk management is the identication and treatment of these risks. Its objective is to add maximum sustainable value to all the activities of the organisation. It marshals the understanding of the potential upside and downside of all those factors which can aect the 86

4.7. A SAMPLE RISK MANAGEMENT STANDARD organisation. It increases the probability of success, and reduces both the probability of failure and the uncertainty of achieving the organisations overall objectives. Risk management should be a continuous and developing process which runs throughout the organisations strategy and the implementation of that strategy. It should address methodically all the risks surrounding the organisations activities past, present and in particular, future. It must be integrated into the culture of the organisation with an eective policy and a programme led by the most senior management. It must translate the strategy into tactical and operational objectives, assigning responsibility throughout the organisation with each manager and employee responsible for the management of risk as part of their job description. It supports accountability, performance measurement and reward, thus promoting operational eciency at all levels. External and Internal Factors The risks facing an organisation and its operations can result from factors both external and internal to the organisation. The diagram overleaf summarises examples of key risks in these areas and shows that some specic risks can have both external and internal drivers and therefore overlap the two areas.They can be categorised further into types of risk such as strategic, nancial, operational, hazard, etc. Risk management protects and adds value to the organisation and its stakeholders through supporting the organisations objectives by: providing a framework for an organisation that enables future activity to take place in a consistent and controlled manner improving decision making, planning and prioritisation by comprehensive and structured understanding of business activity, volatility and project opportunity/threat 87

CHAPTER 4. MANAGEMENTUL RISCULUI

Figure 4.2: Examples of the Drivers of Key Risks

88

4.7. A SAMPLE RISK MANAGEMENT STANDARD

Figure 4.3: The Risk Management Process

89

CHAPTER 4. MANAGEMENTUL RISCULUI contributing to more ecient use/allocation of capital and resources within the organisation reducing volatility in the non essential areas of the business protecting and enhancing assets and company image developing and supporting people and the organisations knowledge base optimising operational eciency

4.7.3

Risk Assessment

Risk Assessment is dened by the ISO/ IEC Guide 73 as the overall process of risk analysis and risk evaluation. Risk Identication Techniques - examples Brainstorming Questionnaires Business studies which look at each business process and describe both the internal processes and external factors which can inuence those processes Industry benchmarking Scenario analysis Risk assessment workshops Incident investigation Auditing and inspection HAZOP (Hazard and Operability Studies) 90

4.7. A SAMPLE RISK MANAGEMENT STANDARD Risk Analysis Methods and Techniques - examples Upside risk Market survey

Prospecting Test marketing Research and Development Business impact analysis Both Dependency modelling SWOT analysis (Strengths,Weaknesses, Opportunities,Threats) Event tree analysis Business continuity planning BPEST (Business, Political, Economic, Social,Technological) analysis Real Option Modelling Decision taking under conditions of risk and uncertainty Statistical inference Measures of central tendency and dispersion PESTLE (Political Economic Social Technical Legal Environmental) Downside risk Threat analysis

Fault tree analysis FMEA (Failure Mode and Eect Analysis)

4.7.4

Risk Analysis

Risk Identication Risk identication sets out to identify an organisations exposure to uncertainty.This requires an intimate knowledge of the organisation, the 91

CHAPTER 4. MANAGEMENTUL RISCULUI market in which it operates, the legal, social, political and cultural environment in which it exists, as well as the development of a sound understanding of its strategic and operational objectives, including factors critical to its success and the threats and opportunities related to the achievement of these objectives. Risk identication should be approached in a methodical way to ensure that all signicant activities within the organisation have been identied and all the risks owing from these activities dened. All associated volatility related to these activities should be identied and categorised. Business activities and decisions can be classied in a range of ways, examples of which include: Strategic - These concern the long-term strategic objectives of the organisation.They can be aected by such areas as capital availability, sovereign and political risks, legal and regulatory changes, reputation and changes in the physical environment. Operational - These concern the day-today issues that the organisation is confronted with as it strives to deliver its strategic objectives. Financial - These concern the eective management and control of the nances of the organisation and the eects of external factors such as availability of credit, foreign exchange rates, interest rate movement and other market exposures. Knowledge management - These concern the eective management and control of the knowledge resources, the production, protection and communication thereof. External factors might include the unauthorised use or abuse of intellectual property, area power failures, and competitive technology. Internal factors might be system malfunction or loss of key sta. Compliance - These concern such issues as health and safety, environmental, trade descriptions, consumer protection, data protection, employment practices and regulatory issues. 92

4.7. A SAMPLE RISK MANAGEMENT STANDARD Whilst risk identication can be carried out by outside consultants, an in-house approach with well communicated, consistent and co-ordinated processes and tools (see Appendix, page 14) is likely to be more eective. In-house ownership of the risk management process is essential. Risk Description The objective of risk description is to display the identied risks in a structured format, for example, by using a table.The risk description table overleaf can be used to facilitate the description and assessment of risks.The use of a well designed structure is necessary to ensure a comprehensive risk identication, description and assessment process. By considering the consequence and probability of each of the risks set out in the table, it should be possible to prioritise the key risks that need to be analysed in more detail. Identication of the risks associated with business activities and decision making may be categorised as strategic, project/ tactical, operational. It is important to incorporate risk management at the conceptual stage of projects as well as throughout the life of a specic project. Risk Estimation Risk estimation can be quantitative, semiquantitative or qualitative in terms of the probability of occurrence and the possible consequence. For example, consequences both in terms of threats (downside risks) and opportunities (upside risks) may be high, medium or low (see table 4.2). Probability may be high, medium or low but requires dierent denitions in respect of threats and opportunities (see tables 4.3 and 4.4). Examples are given in the tables overleaf. Dierent organisations will nd that dierent measures of consequence and probability will suit their needs best. For example many organisations nd that assessing consequence and probability as high, medium or low is quite adequate for their needs and can be presented as a 3 x 3 matrix. 93

CHAPTER 4. MANAGEMENTUL RISCULUI Table 4.1: Table - Risk Description 1. Name of risk 2. Scope of Risk 3. Nature of Risk 4. Stakeholders 5. Quantication of Risk 6. Risk Tolerance/ Appetite

7. Risk Treatment and Control Mechanisms 8. Potential Action for Improvement 9. Strategy and Policy Developments

Qualitative description of the events, their size, type, Eg. strategic, operational, nancial, knowledge or com Stakeholders and their expectations Signicance and Probability Loss potential and nancial impact of risk Value at risk Probability and size of potential losses/gains Objective(s) for control of the risk and desired level o Primary means by which the risk is currently manage Levels of condence in existing control Recommendations to reduce risk Identication of function responsible for developing st

Other organisations nd that assessing consequence and probability using a 5 x 5 matrix gives them a better evaluation.

Table 4.2: Consequences - Both Threats and Opportunities Financial impact on the organisation is likely to exceed a certain amount Signicant impact on the organisations strategy or operational activities Signicant stakeholder concern Medium Financial impact on the organisation likely to be between 2 certain amounts Moderate impact on the organisations strategy or operational activities Moderate stakeholder concern Low Financial impact on the organisation likely to be less that a certain amount Low impact on the organisations strategy or operational activities Low stakeholder concern High

94

4.7. A SAMPLE RISK MANAGEMENT STANDARD

Table 4.3: Probability of Occurrence - Threats Estimation Description Indicators High Likely to occur each year Potential of it occurring several times (Probable) or more than 25% chance within the time period (for example - ten years) of occurrence. Has occurred recently. Medium Likely to occur in a ten Could occur more than once within the (Possible) year time period or less time period (for example - ten years). than 25% chance of Could be dicult to control due to occurrence. some external inuences. Is there a history of occurrence? Low Not likely to occur in a Has not occurred. (Remote) ten year period or less than Unlikely to occur. 2% chance of occurrence.

Table Estimation High (Probable)

Medium (Possible)

Low (Remote)

4.4: Probability of Occurrence - Opportunities Description Favourable outcome is likely to be achieved in one year or better than 75% chance of occurrence. Reasonable prospects of favourable results in one year of 25% to 75% chance occurrence. Some chance of favourable outcome in the medium term or less than 25% Opportunity for which the likelihood of chance of occurrence.

Indicators Clear opportu on with reaso achieved in th current mana Opportunities but which req Opportunities above the pla Possible oppo fully investiga

success is low resources curr

95

CHAPTER 4. MANAGEMENTUL RISCULUI Risk Analysis methods and techniques A range of techniques can be used to analyse risks.These can be specic to upside or downside risk or be capable of dealing with both. (See Appendix, page 14, for examples). Risk Prole The result of the risk analysis process can be used to produce a risk prole which gives a signicance rating to each risk and provides a tool for prioritising risk treatment eorts. This ranks each identied risk so as to give a view of the relative importance. This process allows the risk to be mapped to the business area affected, describes the primary control procedures in place and indicates areas where the level of risk control investment might be increased, decreased or reapportioned. Accountability helps to ensure that ownership of the risk is recognised and the appropriate management resource allocated.

4.7.5

Risk Evaluation

When the risk analysis process has been completed, it is necessary to compare the estimated risks against risk criteria which the organisation has established.The risk criteria may include associated costs and benets, legal requirements, socioeconomic and environmental factors, concerns of stakeholders, etc. Risk evaluation therefore, is used to make decisions about the signicance of risks to the organisation and whether each specic risk should be accepted or treated.

4.7.6

Risk Reporting and Communication

Internal Reporting Dierent levels within an organisation need dierent information from the risk management process. 96

4.7. A SAMPLE RISK MANAGEMENT STANDARD The Board of Directors should: know about the most signicant risks facing the organisation know the possible eects on shareholder value of deviations to expected performance ranges ensure appropriate levels of awareness throughout the organisation know how the organisation will manage a crisis know the importance of stakeholder condence in the organisation know how to manage communications with the investment community where applicable be assured that the risk management process is working eectively publish a clear risk management policy covering risk management philosophy and responsibilities Business Units should: be aware of risks which fall into their area of responsibility, the possible impacts these may have on other areas and the consequences other areas may have on them have performance indicators which allow them to monitor the key business and nancial activities, progress towards objectives and identify developments which require intervention (e.g. forecasts and budgets) have systems which communicate variances in budgets and forecasts at appropriate frequency to allow action to be taken report systematically and promptly to senior management any perceived new risks or failures of existing control measures Individuals should: ual risks understand their accountability for individ97

CHAPTER 4. MANAGEMENTUL RISCULUI understand how they can enable continuous improvement of risk management response understand that risk management and risk awareness are a key part of the organisations culture report systematically and promptly to senior management any perceived new risks or failures of existing control measures External Reporting A company needs to report to its stakeholders on a regular basis setting out its risk management policies and the eectiveness in achieving its objectives. Increasingly stakeholders look to organisations to provide evidence of eective management of the organisations non-nancial performance in such areas as community aairs, human rights, employment practices, health and safety and the environment. Good corporate governance requires that companies adopt a methodical approach to risk management which: protects the interests of their stakeholders ensures that the Board of Directors discharges its duties to direct strategy, build value and monitor performance of the organisation ensures that management controls are in place and are performing adequately The arrangements for the formal reporting of risk management should be clearly stated and be available to the stakeholders. The formal reporting should address: the control methods - particularly management responsibilities for risk management the processes used to identify risks and how they are addressed by the risk management systems 98

4.7. A SAMPLE RISK MANAGEMENT STANDARD the primary control systems in place to manage signicant risks the monitoring and review system in place Any signicant deciencies uncovered by the system, or in the system itself, should be reported together with the steps taken to deal with them.

4.7.7

Risk Treatment

Risk treatment is the process of selecting and implementing measures to modify the risk. Risk treatment includes as its major element, risk control/mitigation, but extends further to, for example, risk avoidance, risk transfer, risk nancing, etc. NOTE: In this standard, risk nancing refers to the mechanisms (eg insurance programmes) for funding the nancial consequences of risk. Any system of risk treatment should provide as a minimum: eective and ecient operation of the organisation eective internal controls compliance with laws and regulations. The risk analysis process assists the eective and ecient operation of the organisation by identifying those risks which require attention by management.They will need to prioritise risk control actions in terms of their potential to benet the organisation. Eectiveness of internal control is the degree to which the risk will either be eliminated or reduced by the proposed control measures. Cost eectiveness of internal control relates to the cost of implementing the control compared to the risk reduction benets expected. The proposed controls need to be measured in terms of potential economic eect if no action is taken versus the cost of the proposed action(s) and invariably require more detailed information and assumptions than are immediately available. 99

CHAPTER 4. MANAGEMENTUL RISCULUI Firstly, the cost of implementation has to be established. This has to be calculated with some accuracy since it quickly becomes the baseline against which cost eectiveness is measured. The loss to be expected if no action is taken must also be estimated and by comparing the results, management can decide whether or not to implement the risk control measures. Compliance with laws and regulations is not an option. An organisation must understand the applicable laws and must implement a system of controls to achieve compliance.There is only occasionally some exibility where the cost of reducing a risk may be totally disproportionate to that risk. One method of obtaining nancial protection against the impact of risks is through risk nancing which includes insurance. However, it should be recognised that some losses or elements of a loss will be uninsurable eg the uninsured costs associated with work-related health, safety or environmental incidents, which may include damage to employee morale and the organisations reputation.

4.7.8

Monitoring and Review of the Risk Management Process

Eective risk management requires a reporting and review structure to ensure that risks are eectively identied and assessed and that appropriate controls and responses are in place. Regular audits of policy and standards compliance should be carried out and standards performance reviewed to identify opportunities for improvement. It should be remembered that organisations are dynamic and operate in dynamic environments. Changes in the organisation and the environment in which it operates must be identied and appropriate modications made to systems. The monitoring process should provide assurance that there are appropriate controls in place for the organisations activities and that the procedures are understood and followed. Changes in the organisation and 100

4.7. A SAMPLE RISK MANAGEMENT STANDARD the environment in which it operates must be identied and appropriate changes made to systems. Any monitoring and review process should also determine whether: the measures adopted resulted in what was intended the procedures adopted and information gathered for undertaking the assessment were appropriate improved knowledge would have helped to reach better decisions and identify what lessons could be learned for future assessments and management of risks

4.7.9

The Structure and Administration of Risk Management

Risk Management Policy An organisations risk management policy should set out its approach to and appetite for risk and its approach to risk management.The policy should also set out responsibilities for risk management throughout the organisation. Furthermore, it should refer to any legal requirements for policy statements eg. for Health and Safety. Attaching to the risk management process is an integrated set of tools and techniques for use in the various stages of the business process.To work eectively, the risk management process requires: commitment from the chief executive and executive management of the organisation assignment of responsibilities within the organisation allocation of appropriate resources for training and the development of an enhanced risk awareness by all stakeholders. 101

CHAPTER 4. MANAGEMENTUL RISCULUI Role of the Board The Board has responsibility for determining the strategic direction of the organisation and for creating the environment and the structures for risk management to operate eectively. This may be through an executive group, a non-executive committee, an audit committee or such other function that suits the organisations way of operating and is capable of acting as a sponsor for risk management. The Board should, as a minimum, consider, in evaluating its system of internal control: the nature and extent of downside risks acceptable for the company to bear within its particular business the likelihood of such risks becoming a reality how unacceptable risks should be managed the companys ability to minimise the probability and impact on the business the costs and benets of the risk and control activity undertaken the eectiveness of the risk management process the risk implications of board decisions Role of the Business Units This includes the following: the business units have primary responsibility for managing risk on a day-to-day basis business unit management is responsible for promoting risk awareness within their operations; they should introduce risk management objectives into their business 102

4.7. A SAMPLE RISK MANAGEMENT STANDARD risk management should be a regular management-meeting item to allow consideration of exposures and to reprioritise work in the light of eective risk analysis business unit management should ensure that risk management is incorporated at the conceptual stage of projects as well as throughout a project Role of the Risk Management Function Depending on the size of the organisation the risk management function may range from a single risk champion, a part time risk manager, to a full scale risk management department.The role of the Risk Management function should include the following: setting policy and strategy for risk management primary champion of risk management at strategic and operational level building a risk aware culture within the organisation including appropriate education establishing internal risk policy and structures for business units designing and reviewing processes for risk management co-ordinating the various functional activities which advise on risk management issues within the organisation developing risk response processes, including contingency and business continuity programmes preparing reports on risk for the board and the stakeholders 103

CHAPTER 4. MANAGEMENTUL RISCULUI Role of Internal Audit The role of Internal Audit is likely to dier from one organisation to another. In practice, Internal Audits role may include some or all of the following: focusing the internal audit work on the signicant risks, as identied by management, and auditing the risk management processes across an organisation providing assurance on the management of risk providing active support and involvement in the risk management process facilitating risk identication/assessment and educating line sta in risk management and internal control co-ordinating risk reporting to the board, audit committee, etc. In determining the most appropriate role for a particular organisation, Internal Audit should ensure that the professional requirements for independence and objectivity are not breached. Resources and Implementation The resources required to implement the organisations risk management policy should be clearly established at each level of management and within each business unit. In addition to other operational functions they may have, those involved in risk management should have their roles in coordinating risk management policy/strategy clearly dened.The same clear denition is also required for those involved in the audit and review of internal controls and facilitating the risk management process. Risk management should be embedded within the organisation through the strategy and budget processes. It should be highlighted in induction 104

4.8. CONCLUSION and all other training and development as well as within operational processes e.g. product/service development projects.

4.8

Conclusion

Software project managers need to manage risk and use every tool available to them for this management. If they can use a tool that is already being used on their project for other purposes, they save themselves time and money. Most managers use some form of a metrics program to track their project for cost, schedule, eort, and quality. Many of the measures used to help them with this project management can also serve additional use in identifying and tracking risk. This paper used a common software risk, personnel shortfall, to show how managers can use measures and metrics to help identify and track risk items. This technique can be applied to other common risk items, such as requirements changes and unrealistic schedules and budgets, to help managers have visibility into and control over their overall projects in addition to identifying and monitoring their risk items.

105

Chapter 5

Managementul echipei de proiect

5.1

Organizing a Team Project

As a project manager, your job is very similar to the team leader from one of your favorite spy caper movies: putting together a team that has all the skills to get the job done. You will need to deal with many issues that rarely come up in a spy movie, however, such as characters who dodge work and complain about the diculty of the job. This article will help you deal with some of these problems. It is excerpted from the book IT Project Management: On Track from Start to Finish, Second Edition by Joseph Phillips (McGraw-Hill/Osborne, 2004; ISBN: 0072232021).@@@ de pus la bibliograe

5.1.1

Organizing a Project Team

Think of your favorite spy caper movie. Remember how the team in the movie is assembled? Each member has a specialty: explosives, gadgets, luck with the opposite sex, and other necessary skills to get the job done. Notice how theres never just an extra character walking around slurping coee, dodging work, and whining about how tough his job is? Unfortunately, in the world of IT project management, youll have both types of characters. As a project manager, you will recruit the die-hard dedicated workers who are genuinely interested in the success of the project. These team members are exciting to be around as they love to learn, love technology, and work hard for the team and the success of the project. The other 107

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT type of team members youll encounter are nothing less than a pain in the, er, neck. These folks could care less about the project, the success of the company, or anyone else on the team. Their goal is to complete their required hours, draw a paycheck, and get on with their lives. The reality is, however, most people want to do a good job. Most team members are generally interested in the success of the project. If you get stuck with one of the rotten apples, there are methods to work with themand around them. This chapter will focus on how you, the project manager, can assemble a team that works well together. Your team may not be in any spy movies, but parts of the project can be just as exciting.

5.1.2

Assessing Internal Skills

Whether you get to handpick your project team or your team is assigned to you by management, you will still need to get a grasp on the experience levels of each team member. If you have an understanding of what your team members are capable of doing, the process of assigning tasks within the WBS and creating the project plan will go much easier for you. As a project manager, you must create a method to ascertain the skills of your team. It would, no doubt, be disastrous to your project if you began assigning tasks to team members only to later learn they were not qualied to do the work assigned to them. In some cases, this will be easier to do than others, especially if youve worked with the team members before, interviewed the team members, or completed a skills assessment worksheet.

5.1.3

Experience Is the Best Barometer

As you gain experience as a project manager, you will learn which people youd like on your teamand which you wouldnt. If you are a consultant brought into the mix to manage an IT implementation, youll have to learn about the team members, their goals, and their abilities. 108

5.1. ORGANIZING A TEAM PROJECT You must use strategies to recruit and woo knowledgeable and hardworking team members onto your team. This means, of course, youll have to do fact-nding missions to gain information on your recruits. As gure 5.1 demonstrates, you have available to you many methods to assess internal skills. Once youve started your fact-nding mission, rely on multiple methods to assess internal skills: Prior projects Obviously if youve worked with your team members prior to this project, youll have a good idea whos capable of what tasks. Youll also have a record, through historical information, of whos reliable, dependable, and thorough, and has other traits of a good worker. Organizational knowledge You may not have worked directly with particular team members who have been assigned to your project, but you might have a good idea of their track record. Lets face the facts: in your organization, its likely there are people you havent worked with, but you know the type of workers they are by their reputation, their ability to accomplish, and what others say about them. Gossip is one thing, but proven success (or failure) is another. The best way to learn about someone, of course, is not through hearsay, but to work with him or speak directly with his manager. Recommendation of management You may not have the luxury of selecting your team members like youre picking a kickball team at recess. Youll probably be able to recruit some members of your team, but not all of them. Functional or Senior Management will have an inside track on the abilities of employees and can, and will, recommend members for your project. Management will also be able to select individuals who can commit time to the project. Recommendation of team members Most likely, you will have other IT professionals within your organization whom you trust and conde in. These folks can help you by recommending other winners 109

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT

Figure 5.1: Assesment of Internal Skills is derived from multiple sources for your team. These individuals are likely in the trenches working side-by-side with other IT pros. Use their scouting to nd excellent members to work on your project.

5.1.4

Resumes and Skill Assessments

Another source, if you have privy to the document, is the resume for each team member. A resume can quickly sum up the skill set of a team member. You may want the project team to create quick resumes for you in order to learn about the experiences of individual members. Use caution with this approach, however. Resumes have the connotation of getting, or keeping, a job, and your team members may panic. If you want to use this method but are uneasy using the word resume, have the team members create a list of projects they have worked on, their skills, and other past accomplishments. This will give you a way to quickly understand the collection of talent and then assign work to the team. A collection of skills will also allow you to determine if you have the resources to complete the project. For example, if youre about to create 110

5.1. ORGANIZING A TEAM PROJECT Table 5.1: Role matrix Project Manager Create the application A Test the application A Package the application R Test the application release R Push the application to the workstations A

Application Developer C P R

Netwo

a database that will span 18 states, with multiple servers, and provide real-time transactions for clients, itll be tough to do if none of your team members have worked with relational databases before.

5.1.5

Create a Roles and Responsibilities Matrix

A Roles and Responsibilities Matrix is a method to identify all of the roles within a project and the associated responsibilities to the project work. This matrix is an excellent way to identify the needed roles for the project participants, identify what actions theyll need to take in the project, and, ultimately, determine if you have all of the roles to complete the identied responsibilities. Heres a quick example of a matrix for a software rollout project: Heres the legend for this matrix: Heres the legend for this matrix: A = Approves R = Reviews P = Participant C = Creator The Roles and Responsibilities Matrix can help the project manager identify the needed resources to complete the project workand determine if the resources exists within the organizations resource pool. Later in the project, the project manager will use an even more precise matrix called the Responsibility Assignment Matrix (RAM) to identify which tasks are assigned to which individuals. Well talk more about this coming up. 111

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT

5.2

Learning Is Hard Work

Within the IT world, a requirement for certication has become practically mandatory. Certications such as the PMP, Microsoft Certied Systems Engineer, Oracle DBA, and even industry certications like CompTIAs A+ and Network + are proof of knowledge in a particular area of technology. Individuals can earn these certications based on training, experience, or a combination of both. Certications are certainly a way to demonstrate that individuals have worked with the technology, understand the major concepts, and are able to pass the exam. Certications do not, however, make the individual a master of all technologies. As gure 5.2 demonstrates, a balance of certication and experience is desirable.

Figure 5.2: A balance of certications and experience proves expertise Within your team, whether there or certications or not, youll need to assess if the members need additional training to complete the project. Training is always seen as one of two things: an expense or an investment. Training is an expense if the experience does not increase the ability of 112

5.2. LEARNING IS HARD WORK the team to implement tasks. Training is an investment if the experience greatly increases the ability of the team to complete the project. When searching for a training provider, consider these questions: What is the experience of the trainer? Can the trainer customize the class to your project? Would hiring a mentor be a better solution than classroom training? What materials are included with the class? What is the cost of the course? Is there an in-house training department that can deliver the training, provide assistance in developing the curriculum in-house, or assist in contracting with an outside trainer? Would it be more cost eective to host the training session inhouse? These questions will help you determine if training is right for your project team. In some instances, standard introductory courses are ne. Typically, the more customized the project, the more customized the class should be as well. Dont assume that just because a training center is the biggest that its also the best. No matter how luxurious a training room, or how delicious the cookies provided, or how slick the brochures are, the success of the class rests on the shoulders of the trainer.

5.2.1

Creating a Team

You cant approach creating a team the way you would baking a cake or completing a paint-by-the-numbers picture. As you will be dealing with multiple individuals, youll discover their personalities, their ambitions, 113

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT and their motivations. Being a project manager is as much about being a leader as it is managing tasks, deadlines, and resources. You will, through experience, learn how to recognize the leaders within the team. Youll have to look for the members who are willing to go the extra mile, who do what it takes to do a job right, and who are willing to help others excel. These attributes signal the type of members you want on your team. The easiest way to create teams with this type of worker? Set the example yourself. Imagine yourself as a team member on your project. How would you like the project manager to act? Or call upon your own experience: what have previous project managers taught you by their actions? By setting the example of how your team should work, youre following ageless advice: leading by doing.

5.2.2

Dening Project Manager Power

Project managers have responsibility. And with that responsibility comes power. When it comes to the project team you are seen as someone with some degree of power. Get used to it, but dont let it go to your head. While the project manager must have a degree of power to get the project work done, the extent of your power is also likely relevant to the organizational structure youre working in. For example, recall that a functional organization gives the power to the functional manager and the project manager may be known as just a project coordinator. A project manager does, however, wield a certain amount of power in most organizations. The project team can see this power, correctly or incorrectly, based on their relationship with you. Their perception of your powerand how you use your project management powerswill inuence the project team and how they accomplish their project work. The ve types of project manager powers are: Expert The project managers authority comes from having experience with the technology the project focuses on. 114

5.2. LEARNING IS HARD WORK Reward/penalty The project manager has the authority to give something of value to team members, or to withhold something of value. Formal The project manager has been assigned by senior management and is in charge of the project. This is also known as positional power. Coercive The project manager has the authority to discipline the project team members. This is also known as penalty power. When the team is afraid of the project manager, its coercive. Referent The project team personally knows the project manager. Referent can also mean the project manager refers to the person who assigned him the position; for example, The CEO assigned me to this position so well do it this way. This power can also mean the project team wants to work on the project, or with the project manager, due to the high priority status and impact of the project.

5.2.3

Hello! My Name Is

If your team works together on a regular basis, then chances are the team has already established camaraderie. The spirit of teamwork is not something that can be born overnightor even in a matter of days. Camaraderie is created from experiences of the teammates. A successful installation of software, or even a failed one, creates a sense of unity among the team. Its mandatory on just about any project that team members work together. Heres where things get tricky. Among those team members, youve got ambition, jealousies, secret agendas, uncertainties, and anxiety pooling in and seeping through the workers of your project. One of your rst goals will be to establish some order in the team and change the members focus to the end result of the project. Figure 5.3 illustrates the detrimental eect personal ambitions have on the success of a project. By motivating your team to focus on the project deliverables, you can, like a magician, misdirect their attention from their own agendas 115

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT

Figure 5.3: Personal ambitions must be put aside for the success of the project to the projects success. You can spark the creation of a true team by demonstrating how the members are all in this together. How can you do this? How can you motivate your team and change the focus from self-centric to project-centric? Here are some methods: Show the team members whats in it for them. Remember the WIIFM principle Whats In It For Me. Show your team members what they personally have to reap from the project. You may do this by telling them about monetary bonuses theyll receive. Maybe your team will get extra vacation days or promotions. At the very least, theyll be rewarded with adding this project to their list of accomplishments. Who knows? Youll have to nd some way for this project to be personal for each team member. Show the team what this project means to the company. By demonstrating the impact that this implementation has for the entire company, you can position the importance of the success (or failure) 116

5.3. WHERE DO YOU LIVE? of the project squarely on the teams shoulders. This method gives the team a sense of ownership and a sense of responsibility. Show the team why this is exciting. IT project managers sometime lose the sense of excitement wrapped up in technology. Show your team why this project is cool, exciting, and fun, and the implementation will hardly be like work. Remember, IT pros typically love technologyso let them have some fun! It is okay to have a good time and enjoy your work. Show the team members their importance. Teams need to know that their work is valued and appreciated. You cant fake this stu. Develop a sense of caring, a sense of pride, and tell your team members when they do a good job. Dont let them feel like they are as valued as the slave labor used to build the Egyptian pyramids. Let them own the technology, use the technology, and be proud of their work.

5.3

Where Do You Live?

In todays world, its typical of a single project to span the globe. No doubt its dicult for team members to feel like they are part of the same team when theyre in London and their counterpart is in Phoenix. Ideally, collocated teams communicate better, work together better, and have a sense of ownership. Reality, however, proves that noncollocated teams exist in many organizations, and the project manager must take extra measures to ensure the project succeeds, regardless of the geographical boundaries. When dealing with noncollocated teams, your team will likely be built around subteams. A subteam is simply a squadron of team members unique to one task within the project or within each geographical area. For example, as depicted in gure 5.4, a company is implementing Oracle servers throughout its enterprise. The company has 12 locations 117

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT throughout the world. Some of the same tasks that need to be accomplished in Madison, Wisconsin, will also need to be performed in Paris, France. Rather than having one team consisting of six members y around the globe, the project manager implements 12 subteams. In this example, each subteam has six members. Of the six members, one is the team leader for that location. All of the team leaders report to the project manager, the 73rd member of the team. The team members in each location report to their immediate team leader. Implementation of the Oracle servers at each location will follow a standard procedure for the installation and conguration. The path to success should be the same at each location regardless of geography. Certainly not all projects will map out this smoothly. Some sites may not have the technical know-how of others, and travel will be required. In other instances, some sites will require more conguration than others, or an increase in security, and other variances. The lesson to be learned is that when teams are dispersed, a chain of command must be established to create uniformity and smooth implementation. The phrase out of sight, out of mind often proves true when dealing with dispersed project teams. Finally, when working with multiple subteams, communication is paramount. Team leaders and the project manager should have regularly scheduled meetings either in person or through teleconferences or videoconferences. In addition, team leaders should have the ability to contact other team members around the globe. In some instances, team members from dierent teams will need to work together as well. For example, the communication between two servers has to be congured. The teammates responsible for this step of the conguration will need to coordinate their congurations and installation with the teammates who have identical responsibilities in other locations. 118

5.3. WHERE DO YOU LIVE?

Figure 5.4: Subteams are crucial to large implementations

5.3.1

Building Relationships

When an individual joins your team, you and the individual have a relationship: project manager to team member. Immediately the team member knows his role in the project as a team member, and you know your role in relation to the team member as the project manager. What may not be known, however, is the relationships between team members. You may need to give some introduction of each team member and explain why that person is on the team and what responsibilities that person has. Dont let your team members just gure things out for themselves. In a large project, it would be ideal to have a directory of the team members, their contact information, and their arsenal of talents made available to the whole team. On all projects, your team will have to work together very quickly. Its not a bad idea to bring the team together in some type of activity away from the workplace. Examples of team building exercises: A bowling excursion 119

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT A hike and overnight stay in the wilds A weekend resort meeting to learn about each other and discuss the project A trip to your local pool hall for an impromptu round of team pool

5.3.2

Interviewing Potential Team Members

Remember your rst big interview? You shined your shoes, made certain your hair was just right, brushed your teeth, and had a breath mint just in case. Your goal was to get the job, so you did your homework: you researched the company, investigated the position, made certain your resume and references were up-to-date, and then gave it your best shot. Guess what? As a project manager, you may nd yourself conducting interviews to woo internal employees onto your project team. Youre mission will be twofold: impressing the candidates while at the same time learning about them to see if they are the right t for your project team.

5.3.3

Why You Need Interviews

If you are one of the lucky project managers and you get to handpick your project team, youll need to interview potential project team members. You, or you and the project sponsor, may discuss which employees should be placed on the project and why. The type of work to be completed will serve as your primary guide for the talent needed on the project. You may also need to look for other attributes such as aptitude, track record, and current workload. An interview will help you ascertain each prospects level of ability before you invite that person onto the project. Or, in the instance the individual has been assigned to the project, an interview helps you learn about her abilities and how they may contribute to the project. 120

5.4. HOW TO INTERVIEW Interviews for IT projects can be completed formally, with resume, or informally conducted over lunch or coee. Regardless of how the interview is completed, youll need to learn if the prospective team member will be able to complete the type of work you have in mind. This means, of course, that youre looking for a specic type of worker based on your planning. An interview, even if its a simple, informal meeting, allows you to discuss the prospective team members abilities and how they can help on the project, and it gives you an insight into the persons goals, ambitions, and outlook regarding work. Interviews allow project managers to learn about the team members, their assets for the project, and how much of a learning curve may be required if the interviewee is to join the team.

5.4

How to Interview

Your goal when interviewing potential team members (or team members who have been assigned to your project) is to determine what their role in the implementation may be. Any project is only as good as the people completing the work. Your team will be a direct reection on your own abilities, so this task is one of the most important youll have on the entire project. When interviewing potential team members, youll need a job description for each open team position. A job description is needed for two reasons: So that you may share with the prospect what role needs to be lled So that you can focus on the attributes of the ideal team member A job description is more than a title for a role on the team. A job description details the activities of the role, the scope of the position, the responsibilities, and the working requirements of the team member. A job description should be clear, concise, and easily summarized. For 121

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT example, here is a job description for the role of a team member responsible for creating logon scripts: Logon script creatorThis team member will be responsible for the creation, testing, and implementation of logon scripts for several thousand users. The logon script creator will be responsible for following the logon guidelines as assigned by management, updating current logon script procedures, and documenting the various logon scripts created. You will also need selection criteria to determine which prospect is the best t for the team role. The selection criteria will stem from the job description, as it should be a set of requirements that, if met, indicates the individual would be able to wholly complete the tasks of the job description. Selection criteria can include: Education Knowledge on the tasks Experience with the tasks Skill sets applicable to the tasks Accomplishments within the company Other essential qualities such as aptitude, leadership, and the ability to work with others Many project managers balk at completing interviews. Dont. They are not dicult if youve prepared. Interviews can help you properly assign tasks to team members during resource assignment and scheduling. To prepare for an interview, develop good questions. When interviewing, there are several question types that you should know and use: Closed question These questions must be answered with a yes or no. For example: Have you ever created a batch le before? 122

5.4. HOW TO INTERVIEW Essay questions These questions allow the candidate to tell you informationand they allow you to listen and observe. For example: Why are you interested in working on this project? Experience questions These questions focus on the candidates behavior in past situations, and they allow you to see how a candidate has acted to predict how he may act in future situations that are similar. For example: How did you react when a teammate did not complete a task on a past project and you had to do his work for him to complete your own? How was the situation resolved? Reactionary questions These questions evolve from the candidates answers. When you notice a gap or an inconsistency in an answer, use a follow-up question that focuses on the inconsistency without directly calling it a lie. This gives the candidate the opportunity to explain herself better or ounder for an explanation. Reactionary questions also allow you to learn more information that may be helpful on your project. For example: You mentioned you had experience with Visual Basic. Do you also have a grasp on VBScript? Questions not to ask In the United States, its illegal to ask candidates questions that arent related to their capacity to do a job. Basically, avoid questions that center on child care, marital status, religion, racial background, or physical disability. Use common sense, and this area of the interview should not be a problem. Interviews are a great tool for learning about your potential team members. They are also an opportunity for potential team members to learn about you. Invite the candidate to ask you questions about your role on the project and the importance of the project. When conducting an interview, allow the candidate to do most of the talking so you can do most of the listening. 123

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT

5.4.1

Managing Team Issues

Without a doubt, people will ght. Fortunately, in most oces, people are mature enough to bite their tongues, try to work peacefully, and, as a whole, strive to nish the project happily and eectively together. Most disagreements in IT project management happen when two or more people feel very passionate about a particular IT topic. For example, one person believes a network should be built in a particular order, while another feels it should be constructed from a dierent approach. Or two developers on a project get upset with each other about the way an application is created. Generally, both parties in the argument are good people who just feel strongly about a certain methodology of their work. Figure 5.5 demonstrates how arguments over technical implementations take a project o schedule. There are, of course, a fair percentage of contrary and pessimistic people in the world. These people dont play well with others, and are obnoxious at times. They dont care about other peoples feelings, and much of the time they dont care about the success of your project. Unfortunately, you will have to deal with disagreements, troublemakers, and obnoxious people to nd a way to resolve dierences and keep the projects momentum.

5.4.2

Dealing with Team Disagreements

In most projects there will be instances when the project team, management, and other stakeholders disagree on the progress, decisions, and proposed solutions within the project. Its essential for the project manager to keep calm, to lead, and to direct the parties to a sensible solution thats best for the project. Here are seven reasons for conict in order of most common to least common: Schedules Priorities 124

5.4. HOW TO INTERVIEW

Figure 5.5: Arguments take a project o schedule and increase costs

125

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT Resources Technical beliefs Administrative policies and procedures Project costs Personalities So whats a project manager to do with all the potential for strife in a project? There are ve dierent approaches to conict resolution: Problem solving This approach confronts the problem head-on and is the preferred method of conict resolution. You may consider this approach as confronting. It calls for additional research to nd the best solution for the problem, and is a win-win solution. Problem solving can be used if there is time to work through and resolve the issue, and it works to build relationships and trust. Forcing With this approach, the person with the power makes the decision. The decision made may not be best for the project, but its fast. As expected, this autocratic approach does little for team development and is a win-lose solution. Forcing is used when the stakes are high and time is of the essence, or if relationships are not important. Compromising This approach requires both parties to give up something. The decision is a blend of both sides of the argument. Because neither party really wins, it is considered a lose-lose solution. The project manager can use this approach when the relationships are equal and its impossible for one party to win. This approach can also be used to avoid a ght. Smoothing This approach smoothes out the conict by minimizing the perceived size of the problem. It is a temporary solution but can 126

5.5. PHASES OF TEAM DEVELOPMENT calm team relations and boisterous discussions. Smoothing may be acceptable when time is of the essence or any of the proposed solutions will work. This can be considered a lose-lose situation as no one really wins long-term. The project manager can use smoothing to emphasize areas of agreement between the stakeholders within a disagreement, minimizing the areas of conict. Smoothing is used to maintain relationships and when the issue is not critical. Withdrawal This approach is the worst conict resolution tactic because one side of the argument walks away from the problemusually in disgust. The conict is not resolved and it is considered a yieldlose solution. The approach can be used, however, as a cooling o period, or when the issue is not critical.

5.5

Phases of Team Development

Teams develop over time, not instantaneously. As a project team comes together, there are likely people on the project team who have worked with one another before just as there may be people on the project team who have never met. Because projects are temporary the relationships among project team members are also often viewed as temporary. The project manager can see, and sometimes guide, the natural process of team development. The goal of team development is not for everyone to like each other, have a good time, and create life-long friendships. All of that is nice, but the real goal is to develop a team that can accurately and eectively complete the project scope. Within team development there are four stages the project team will pass though: Forming This stage allows the project team members to come together and learn about each other. They feel each other out and nd out whos who and what each other is like. 127

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT Storming This stage promises action. Theres a struggle for project team control and momentum builds as members vie to lead the project team. It is during this phase that people gure out the hierarchy of the team, and the informal roles of team members. Norming In this stage, the project teams focus shifts toward the project work. Control on the project team has been established, and people learn to work together. Performing In this stage, the project team members have settled into their roles and are focusing on completing the project work as a team. During this stage, a synergy is developed; this is the stage where high-performance teams come into play.

5.5.1

Project Management Is Not a Democracy

Despite what some feel-good books and inspiring stories would like to have you believe, project management is not a democracy. Someone has to be in charge, and that someone is you, the project manager. The success of the project rests on your shoulders, and it is your job to work with your team members to motivate them to nish the project on schedule. This does not mean that you have permission to grump around and boss any member of your team. It also does not mean that you should step in and break up any disagreement between team members. Among the team, you should allow some discussion and some disagreement. This is what teams have to do: they have to work things out on their own. Team members have to learn to work together, to give and take, to compromise. Figure 5.6 shows the power of team decisions. Step back and let the team rst work through disagreements before you step in and settle issues. If you step into the mix too early, then your team members will run to you at every problem. Ultimately, you are in charge. If your team members cannot, or will not, work out a solution among themselves, youll be forced to make a decision. When you nd yourself in this situation, there is an approach 128

5.5. PHASES OF TEAM DEVELOPMENT

Figure 5.6: Teams can make decisions on their own to working through the problem. Here are recommended steps to conict resolution: Attention Meet with both parties and explain the purpose of the meeting: to nd a solution to the problem. If the two parties are amicable to each other, this meeting can happen with both parties present. If the team members detest each other, or the disagreement is a complaint against another team member, meet with each member in condence to hear that persons side of the story. Listen Ask the team members what the problem is, allow each to speak their case fully without interrupting, and then ask questions to clarify any of the facts. Resolve Often if the meeting takes place with both team members, a resolution will quickly boil to the surface. Chances are that you wont even have to make a decision. People have a way of suddenly wanting to work together when a third party listens to their complaints. They both realize how foolish their actions have been and one, or both, of the team members will cheer up and decide to work together. Wait If this is not the case in your meeting, dont make an immediate decision. Tell the team members how important it is to you, and to the project, that they nd a way to work together. Sometimes 129

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT even this touch of direction will be enough for the team members to begin compromising. If they still wont budge, tell them youll think it over and then you will make a decision within a day or twoif the decision can wait that long. By delaying an immediate decision, you allow the team members to think about what has happened and you give them another opportunity to resolve the problem.

Act If the team members will not budge on their positions, then you will have to make a decision. And then stick to it. If necessary, gather any additional facts, research, and investigations. Based on your evidence, call the team members into a meeting again and acknowledge both of their positions on the problem. Then share with them, based on your ndings, why youve made the decision that you have made. In your announcement dont embarrass the team member who has been put out by your decision. If the losing team member wants to argue his point again, stop him. Dont be rude, but stop him. The team members have both been given the opportunity to plead their case, and once your decision has been made, your decision should be nal.

5.5.2

Dealing with Personalities

In any organization, youll nd many dierent personality types, so its likely that there are some people in your organization who just grate on your nerves like ngernails on a chalkboard. These individuals are always happy to share their discontent, their opinion, or their unique point of view. Unfortunately, you will have to nd a way to work with, or around, these people. Here are some personality types you may encounter and how you can deal with them: 130

5.6. USE EXPERIENCE

Table 5.2: Types of personality Personality Attributes The Imaginary Leader These individuals think they are managing the project this The Mouse These individuals are afraid of doing any activity on the pro Your Favorite Uncle (or Aunt) This persona is the oce clown. Always playing gags, stream The Cowboy These people love excitement. They are happy to try anythi The Prune These sourpusses are as much fun as pocket full of thumbtac

5.6

Use Experience

The nal method for resolving disputes among team members may be the most eective: experience. When team members approach you with a problem that they just cant seem to work out between themselves, you have to listen to both sides of the situation. If you have experience with the problem, then you can make a quick and accurate decision for the team members. But what if you dont have experience with the technology, and your team members have limited exposure to this portion of the work? How can you make a wise decision based on the information in front of you? You cant! You will need to invent some experience. As with any project, you should have a testing lab to test and retest your design and implementation. Encourage your team members to use the testing lab to try both sides of the equation to see which solution will be the best. If a testing lab is not available, or the problem wont t into the scope of the testing lab, rely on someone elses experience. Assign the team members the duty of researching the problem and preparing a solution. They can use books, the Internet, or other professionals who may have encountered a similar problem. Experience is the best teacher, as gure 5.7 demonstrates. A method for resolving issues by testing should be implemented. 131

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT

Figure 5.7: A method for resolving issues by testing should be implemented

132

5.6. USE EXPERIENCE

5.6.1

Disciplining Team Members

No project manager likes the process of disciplining a team memberat least they shouldnt. Unfortunately, despite your attempts at befriending, explaining the importance of the project, or keeping team members on track, some people just dont, or wont, care. In these instances, youll have little choice other than to resort to a method of discipline. Within your organization, you should already have a process for recording and dealing with disciplinary matters. The organizational procedures set by human resources or management should be followed before interjecting your own project team discipline approach. If there is no clear policy on team discipline, you need to discuss the matter with your project sponsor before the project begins. In the matter of disciplinary actions, take great cautionyou are dealing with someones career. At the same time, discipline is required or your own career may be in jeopardy. As you begin to nudge team members onto the project track, document it. Keep records of instances where they have fallen o schedule, failed to complete tasks, or have done tasks halfheartedly. This document of activity should have dates and details on each of the incidents, and it doesnt have to be known to anyone but you. Hopefully, your problematic team members will turn from their wicked ways and take your motivation to do their jobs properly. If not, when a threshold is nally crossed, then you must take action.

5.6.2

Following an Internal Process

Within your organization there should be a set process for how an unruly employee is dealt with. For some organizations, theres an evolution of a write-up, a second write-up, a suspension of work, then ultimately a ring. In other organizations, the disciplinary process is less formal. Whatever the method, you should talk with your project sponsor about the process and involve her in any disciplinary action. In all instances of disciplinary action, it would be best for you and the employee to have the project sponsor or the employees immediate 133

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT manager in the meeting to verify what has occurred. This not only protects you from any accusations from the disgruntled team member, but it also protects the team member from your disappointment by having a member of management present.

5.6.3

Removal from a Project

Depending on each situation, you may discover that the team member cannot complete the tasks required of him on the project, and removal from the project may be the best solution. In other instances it could be that the team member refuses to complete the work assigned to him for his own reasons and is a detriment to the success of the project. Again, removal from the team may be the most appropriate action. Removing someone from the project requires tact, care, and planning. A decision should be made between you and the project sponsor. If you feel strongly that this person is not able to complete the tasks assigned to him, rely on your documentation as your guide. Removal of a team member from a project may be harsh, but its often required if the project is to succeed. Of course, when you remove someone from the project, you need to address the matter with the team. Again, use tact. A disruption in the team can cause internal rumblings that you may never hear aboutespecially if the project team member that was removed was everyones best friend. You will have created an instant us-against-them mentality. In other instances, the removal of a troublemaker may bring cheers and applause. Whatever the reaction, use tact and explain your reasons without embarrassing or slandering the team member who was removed.

5.6.4

Using External Resources

There comes a time in every organization when a project is presented that is so huge, so complex, or so undesirable to complete that it makes perfect sense to outsource the project to someone else. In these instances, 134

5.6. USE EXPERIENCE no matter the reason why the project is being outsourced, it is of utmost importance to nd the right team to do the job correctly. Outsourcing has been the buzz of all industries over the last few yearsand certainly IT has been a prevalent reason for companies to get someone else to do it. There are plenty of qualied companies in the marketplace that have completed major transitions and implementations of technologybut there are also many incompetents that profess to know what theyre doing only to botch an implementation. Dont let that happen to you.

5.6.5

Finding an Excellent IT Vendor

Finding a good IT vendor isnt a problem. Finding an excellent IT vendor is the problem. The tricky thing about nally nding excellent vendors is that they keep so busy (because of their talented crew), they are dicult to schedule time with. So what makes an excellent vendor? Here are some attributes: Ability to complete the project scope on schedule Vast experience with the technology to be implemented References that demonstrate customer care and satisfaction Proof of knowledge on the project team (experience and certications) Adequate time to focus on your project A genuine interest in the success of your organization A genuine interest in the success of your project A fair price for completing the work 135

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT Finding an excellent vendor to serve as your project team, or to be integrated into your project team, is no easy task. Remember, the success of a project is only as good as the people on the project team. Its not just the name of the integrator, but the quality of the individuals on the integrators implementation team that make the integrator great (or not so great). Never forget that fact. Figure 5.8 demonstrates how a vendor can be integrated into your project team. The success of the project is dependent on the payment of the vendor. The project manager should oversee the process.

Figure 5.8: A vendor must have vision and dedication to the success of the project Size doesnt always matter. Those monstrous integrators and technical rms that have popped up in every city over the past few years dont always have the best people. Some of the best integrators you can nd anyway are small, independent rms that have a tightly knit group of technical wizards. Do some research and consider these smaller, aboveaverage tech shops. You may nd a diamond in the rough. To begin nding your integrator, you can use several dierent methods: References Word of mouth from other project teams within your organization, contacts within your industry, or even family and friends 136

5.7. CONCLUSIONS are often the best way to nd a superb integrator. A reference does something most brochures and sales letters cannot: it comes from a personal contact and lends credibility. Internet If you know the technology you are to be implementing, hop on the Internet and see whom the manufacturer of the technology recommends. Once youve found integrators within your community, peruse their web site. Use advanced searches to look for revealing information about them on other web sites, in newsgroups, or in newspapers, or magazines. Know whom you are considering working with before they know you. Yellow pages When all else fails, open the phone book and call and interview the prospective team over the phone. Prepare a list of specic questions that youll need answered. Pay attention to how the phone is answered, what noise is in the background, and how professional and organized the individual on the phone is. Is he rude? Is he happy to help? Take notes and let the other person do much of the talking. Trade shows If you know your project is going to take place in a few months, attend some trade shows and get acquainted with some potential vendors. Watch how their salespeople act. Ask them brief questions on what their team has been doing. Collect their materials and le them away for future review. Previous experience Never ignore a proven track record with a vendor. Past performance is always a sure sign of how the vendor will act with your project.

5.7

Conclusions

Teamwork is the key to project management success. As a project manager, you must have a team that you can rely on, while at the same 137

CHAPTER 5. MANAGEMENTUL ECHIPEI DE PROIECT time, the team must be able to turn to you for guidance, leadership, and tenacity. When creating a team, evaluate the skills required to complete the project and then determine which individuals have those attributes to oer. Interviewing potential team members allows you to get a sense of their goals, their work ethics, and what skills they may have to oer. Subteams are a fantastic way to assign particular areas of an IT project to a group of specialists or to a geographically based implementation. When creating subteams, communications from the project manager and the team leaders is essential. Subteams require responsible leaders on each team, and a reliable, condent project manager. When disagreements air among team members, you must have a plan in place before the disagreement happens. Document problems with troublesome team members in the event that a team member needs to reprimanded or removed from the team. The project sponsor should be kept abreast of the situation as the project continues. Should the scope of the project be beyond the abilities of the internal team, the project can be outsourced. When outsourcing the project, you need to use careful consideration in your selection of an integrator. Project managers should rely on references of vendors, their ability to work with the technology, gut feelings, and word of mouth to make a decision. Building a project team is hard work, but it is also an investment in the success of the project. Once again, the success of any project is only as good as the members on the project team.

138

Chapter 6

Managementul comunicarii in cadrul proiectului

6.1
6.1.1

Comunicarea in lumea virtuala

Introduction

The primary mission of the project manager working with either a virtual team or a traditional team is the delivery of the desired product or the facilitation of the required service. To that end, the teams eorts are focused on the activities and measures that would produce the deliverable of the project in a cost-eective and ecient manner. The team must plan the delivery of the product or service through best practices, policies, and procedures. Eective communication within the team and with the projects internal and external stakeholders is required. Communication is dened as the transfer of some type of message that contains one or more pieces of information. The information that is conveyed can be either through formal channels or informal channels. Todays project manager is both blessed and cursed by the quantity of communication tools available in the workplace. Formats for communication are extensive and include individual meetings, sta meetings, conference calls, e-mails, videoconferences, messages, and faxes. What each of these formats has in common is that all communication is interpersonal and goes from the sender to the receiver or receivers. The project manager, as a communicator, must have correct tools and skills to reach all of the dierent types of individuals on the project team 139

CHAPTER 6. MANAGEMENTUL COMUNICARII IN CADRUL PROIECTULUI eectively. If the communication is predictable and eective, it will help maintain trust and momentum among team members. Communication techniques to assure team member involvement throughout all aspects of the project, therefore, are required. This paper discusses similarities and dierences in virtual and traditional project environments in terms of eective communication strategies and presents ideas, strategies, and guidelines for consideration and possible use on both types of project teams.

6.1.2

Open and Eective Communication

Eective communication among project team members and stakeholders is important on any project team. Miscommunication can create hard feelings that might remain undetected for a long time, undermining team success. Open communication in all directions, without fear of reprisal, must be encouraged so that every team member feels comfortable contributing to discussions and debates. Project debates are exceptionally useful because it is during these debates that team members provide useful and important information to others. Improving communication involves identifying information needs and ways to best share information among the team. Predictable and eective communication will help maintain trust and momentum. The teams policies should provide an environment that assures that the information shared is valuable to the project. Many dierent communications tools can be used. A common data interchange format should be available. In order to assure that the ow of information among the team is unencumbered, the team should be given the opportunity to draft protocols as to when each tool should be used. Early involvement of team members sets the stage for encouraging them to work with one another to develop eective ways to communicate project information. Team meetings, either face to face or virtual, should be viewed as results oriented and as a useful way to spend time. Each team member should participate actively in team meetings in what140

6.1. COMUNICAREA IN LUMEA VIRTUALA ever format, taking responsibility for being heard and being understood. Agreed-upon methods to stay in contact with team members throughout the project life cycle also are useful and can then serve as starting points to discuss ideas, issues, insights, and information. A communications schedule, as detailed in the communications management plan, should be established that is exible and can be adjusted if required to changing conditions. Team members should be willing to modify their availability standards to best t those of the team.

6.1.3

Communication Challenges with Virtual Teams

In traditional and virtual teams alike, one of the benecial side eects of regular communication is that it imparts to the project team members the comfort of being physically and emotionally connected with other members of the team. The image depicted by regular face-to-face communication between employees of the same department in the same organization typies a traditional, co-located team. It is commonly accepted that working in a traditional project environment, in physical proximity with other team members, will reinforce social similarity, shared values, and expectations. Another subtle advantage of proximity is that collocation increases the anxiety pressure resulting from the possibility of failing to meet commitments [31]. Presumably this anxiety increases the likelihood of success. Research further has shown that collocation practices increase the opportunities for communication [6]and that distance inhibits communication. Allens research showed that people sitting 40 meters apart had only a 5 This research demonstrates the challenges faced in communicating on virtual project teams, particularly because the distances are such that face-to-face communication is nonexistent, a rarity at best. Additionally, communication inadequacies are more damaging in virtual team because of reduced personal access and because of a natural tendency to rely on nonverbal communication clues, which are not readily available in the virtual environment [26]. 141

CHAPTER 6. MANAGEMENTUL COMUNICARII IN CADRUL PROIECTULUI

6.1.4

Diminished Informal Communications

Informal communication in some forms tends to be eliminated when the team is geographically dispersed, or virtual, such as the type of communication that would take place around a water cooler or a coee pot. Such casual communication is reduced since the team members will rarely, if ever, see one another. on a virtual team, new or modied team processes and procedures may need to be formulated in order to maintain a healthy ow of communication within the team in spite of the signicant physical separation. After the team forms, team members must be continually aware of and sensitive to the fact that conventional human interaction is scarce in virtual teams. That is not to say that people do not make personal connections, but that modied or new venues must be used to achieve personal connections. The virtual team also may require more frequent communication so that team members continue to feel connected, especially since many of the virtual team interactions are asynchronous. Attention to peoples feelings, priorities, and perceptions, however, is equally important and becomes more challenging in the virtual environment in conveying information. Communication processes and procedures may need modication to assure cohesiveness and commitment of team members.

6.1.5

Fewer Nonverbal Communication Clues

If clarication or additional information is required during a communication of a collocated team, often the sender can sense that requirement from nonverbal clues. And, the receiver can easily ask for clarication or additional information when required. Even if the receiver does not say something, the sender is able to observe how he or she reacts to what was said, and the nonverbal reaction may convey signicant meaning. Both parties in the traditional environment then can take responsibility for content transference and can pay attention to feedback at the time communication occurs. By analyzing feedback in either direction, adjust142

6.1. COMUNICAREA IN LUMEA VIRTUALA ments can be made. This is critical, as according to the literature [35], words only comprise 7

6.1.6

Increased Reliance on Asynchronous Communications

While face-to-face communication of a collocated team is usually sender controlled, distance communication of a virtual team is primarily receiver controlled. one cannot assume that because a message was sent that it actually was received and understood. Since the virtual environment relies primarily on asynchronous communication, the receiver is left to his or her own devices to interpret the material, thus creating another level of complexity for virtual communications. The traditional process of walking someone through the comprehension of a topic obviously does not exist in the virtual mode, at least not in that exact form. The impact of errors is magnied because there is no opportunity for a continuous stream of questions and answers as there is with traditional teams. Consequently, there is extraordinary pressure, as compared to the traditional teams, to be accurate, succinct, clear, and direct in all items of information that are transmitted to other team members. It then goes without saying that the communication is ineective if the intended message takes on dierent meanings.

6.1.7

Increased Impact of Cultural Implications

Cultural dierences are another key consideration as they can alter communication symbols and meanings, thus resulting in other misunderstandings. on any project team, it is important to recognize that different people react dierently to the contents of phone calls, e-mail, and voice mail. This disparity in comprehension and in subsequent behavior is almost inevitable in virtual teams because larger geographical spans lead to greater cultural interpretations of the messages of the communication. For example, common misunderstandings that might easily occur in 143

CHAPTER 6. MANAGEMENTUL COMUNICARII IN CADRUL PROIECTULUI phone conversations can be the result of dierent interpretations of the signicance of silence and the meaning of pauses in dierent cultures. Another example is starting from the abstract and then moving to the specic, which might be accepted by some but not others.

6.1.8

Raising and Resolving Conicts

Conicts are considered inevitable on projects. on any type of project, if minor issues are left unresolved, they might grow into major conicts for which resolution is dicult. The earlier an issue is identied, the sooner it will be resolved. Early recognition of issues can result in fewer surprises, which in turn will promote open and constructive discussion among team members. Early detection and resolution of issues also can reduce the uncertainty in the work environment, which may be unsettling especially for virtual team members. In the virtual team environment, ones mood and morale are less apparent than they would be in a traditional team. It is dicult to express displeasure and frustration in the virtual environment unless someone makes an eort to send a curt e-mail that cannot be misinterpreted. If such virtual team conicts are allowed to remain and fester, they may result in decreased motivation and negative behavior, which may be more dicult to resolve in the asynchronous environment. Those conicts that might rise to the surface when two people see each other on a day-to-day basis might remain hidden in the virtual environment. When there is a conict between two members of a traditional team, the project manager can easily assemble the parties in a room and work with them to resolve dierences. By comparison, when such a conict arises in a virtual team, such a direct resolution is not available, at least not by using the same techniques and procedures. Therefore, on a virtual team, conicts should be addressed in a proactive fashion with ample forethought in planning and more commitment in monitoring. 144

6.1. COMUNICAREA IN LUMEA VIRTUALA

6.1.9

Guidelines for Consideration to Promote Effective Communications

Use of Romanian as a Link Language Since a global, virtual project normally consists of people from dierent nationalities, the project team should select a common language for the ocial project business. Research has suggested the use of English as the link language for international projects even though there are three times as many native speakers of Chinese as there are of English [18]. Simple and direct communications will help reduce the risk of distorted messages, which in turn can help reduce the probability of misunderstanding. If English is selected as the common language for the project, communications should be based on a vocabulary that is limited to essential and unambiguous words. The ocial project language, with the abbreviated English vocabulary, could easily serve as a common language for the project team. one approach to consider is to adopt an international English vocabulary, which contains the approximately 4,000 words in the English dictionary that are commonly used in order to promote a simple and clear communications tool [15]. Adoption of such a project language then will require that even those team members whose native language is English be more careful in their choice of words. Establish a System of Regular Communications A system of regular communications should be established, including regular reporting and reviews. Project managers of a collocated team in the traditional environment can easily call a meeting on a semi-regular basis. It is easy to take advantage of the physical proximity of team members and avoid the need for extensive meeting preparation, monitoring, and reporting. on a virtual team, however, project managers must be more proactive and organized, since meetings and information exchanges cannot be arranged in a quick and easy fashion. Preparation for a virtual team meeting then tends to be more complex than its tradi145

CHAPTER 6. MANAGEMENTUL COMUNICARII IN CADRUL PROIECTULUI tional counterpart because there are more variables involved in planning and conducting team meetings. More lead time is required to set up the meetings, and they might involve dierent time zones and native languages. A specic and clear agenda for meetings is required as well as ways to assure full participation. Methods are needed to check for understanding. Contingency plans are required in case the technology to be used cannot be accessed by all team members. Time limits should be established to respond to ideas and to make suggestions. It is therefore recommended that topics to cover in the virtual meeting should be ones that are narrower in scope than in traditional collocated meetings. Eective Use of Information Technology If it were not for the ease of use and rapid developments in information technology, virtual projects would not be pursued as regularly and routinely. Its components facilitate the collaboration of the virtual team members. Common technologies include Internet portals, e-mail, videoconferencing, and group decision support systems. These tools enable facilitation of task-specic feedback, notication of upcoming tasks and priorities, and collection of day-to-day progress information about the project. Information technology assists the virtual team to overcome some of the barriers crated by time, distance, complexity, and diversity of participants [45]. Information technology can become an instrument through which project team members can make personal human connections. In a virtual environment, trust is the key ingredient necessary in preventing the geographical and organizational distances of team members from becoming psychological distances [37]. Since the vast majority of virtual teams communicate over the computer and asynchronously, they lack face time to build rapport. one notable skill for developing trust is the proper use of what is known as trained respect? in that one trains oneself to suspend judgment, temporarily or permanently, in order to truly listen to a dierent point of view. Another requirement for a cohe146

6.1. COMUNICAREA IN LUMEA VIRTUALA sive team is that team members must adopt a policy of not stereotyping others. For better or for worse, on-line interaction strips away many of the clues and signs that are part of face-to-face interaction, thus making identity and organizational status more ambiguous. But while this lack of identity clues is often considered a disadvantage, it may be an opportunity for virtual team process improvement. The advantage is under the asynchronous mode of communication, people are judged more by the value of the ideas they have to contribute rather than by gender, race, religion, national origin, class, or age. Traditional chain-of-command hierarchies are less evident, which may result in team members being more willing to speak up and oer ideas and insights. Team members may become accustomed to the advantages of conducting specic communication without any knowledge of or reference to ones status in the organization. Communication can be more based on mutual respect. It is incumbent, however, that the project manager put measures in place so that communications among team members is equitable, regular, and predictable. Substantive responses must be solicited from team members to keep everyone involved in project team issues. While technology serves as the enabler of the virtual project, the specic nature of technology, however, could become a source of conict rather than collaboration. Team members must strive to reach agreement as to the purpose of each tool and the procedures for its use. Otherwise, the lack of common norms can lead to conict that could damage working relationships. For example, one team member might feel that e-mail is a tool to be used for urgent business, while another might feel e-mail is to be used for documentation of information, with urgent business to be conducted by phone. Promote Communications Consistency Consistency in communications will further be enhanced if the team subscribes to predened formats, a unifying and distinguishable logo, and 147

CHAPTER 6. MANAGEMENTUL COMUNICARII IN CADRUL PROIECTULUI operational templates. Standards should be established for format, language, and nomenclature for project management processes and technical components. It may be appropriate, for example to use lean technologies, such as e-mail for information exchange, with videoconferencing reserved for brainstorming sessions or conict resolutions [32]. Specic guidelines for e-mail also are recommended on the virtual team since group dynamics are more dicult to manage in the asynchronous environment. The ability to write concise and eective e-mail becomes a skill for virtual team members. Team members then need to exercise due diligence in complying with the guidelines that are established and agreed-upon. The Importance of a Team Charter The importance of a project charter has long been recognized to set forth the justication for the project, its business needs, and the project managers authority and responsibility. Similarly, a team charter is equally important and especially so on a virtual team. It can help to formalize the internal member-to-member behavior of the team in planning and delivering results. This team charter should be more specic than the project charter as it establishes the roles and responsibilities of team members, ground rules for the teams operation, and team development policies. It describes the practices and procedures that the team members should use to perform the project work. Additionally, it can encourage team members to set forth a vision of the project based on a common purpose, shared ownership, and collective commitment. In terms of project communications, the charter should include guidelines and ground rules for the use of e-mail and other communications modes. It should prescribe the times at which conference calls should be scheduled so that people in a certain time frame are not always unnecessarily burdened or surprised. Points of contact and modes of contact should be specied for interfaces with other groups and with key stake148

6.1. COMUNICAREA IN LUMEA VIRTUALA holders. The team charter should set forth formal procedures that describe how to raise a conict, what specic decision-making processes to use, and how responses are to be provided. The charter should also describe how one should extract a resolution from a conict and how to escalate a conict directly to upper management outside of the team when required. It should include guidelines for reviewing conicts, resolving conicts, appealing the resolutions, and tracking actions during the review and resolution process. Embedded in these procedures should be safeguards to ensure fairness and condentiality. The goal of conict resolution should not be to create a situation where one individual team member declares victory over another. Furthermore, one of the attractive features of advanced technology communications tools is that a team member can transfer information to other team members easily and quickly. Since virtual teams make extensive use of information technology, they can transmit a much larger volume of information compared to the traditional information exchange modes. In addition to addressing items such as how team members should collectively plan their work, share information, participate in making decisions, and perform their work in concert with one another, a virtual team charter must explicitly address the prudent transfer of project/company information. The team charter must include procedures to guard again infringement of intellectual property rights, propriety information, copyrighted information, trademarks, and service marks.

6.1.10

Summary

Todays projects are increasingly complex. Many projects involve creative and innovative products and services. In order to meet project challenges, team members must coordinate their eorts, share their ideas, and discuss their insights. Project teams are expected to produce results, and performance is hindered if the team members do not work together and communicate eectively. 149

Chapter 7

Managementul schimbarii

7.1

What is Change Management?

In thinking about what is meant by change management, at least four basic denitions come to mind: 1. The task of managing change. 2. An area of professional practice. 3. A body of knowledge. 4. A control mechanism.

7.1.1

The Task of Managing Change

The rst and most obvious denition of change management is that the term refers to the task of managing change. The obvious is not necessarily unambiguous. Managing change is itself a term that has at least two meanings. One meaning of managing change refers to the making of changes in a planned and managed or systematic fashion. The aim is to more eectively implement new methods and systems in an ongoing organization. The changes to be managed lie within and are controlled by the organization. (Perhaps the most familiar instance of this kind of change is the change control aspect of information systems development projects.). However, these internal changes might have been triggered by 151

CHAPTER 7. MANAGEMENTUL SCHIMBARII events originating outside the organization, in what is usually termed the environment. Hence, the second meaning of managing change, namely, the response to changes over which the organization exercises little or no control (e.g., legislation, social and political upheaval, the actions of competitors, shifting economic tides and currents, and so on). Researchers and practitioners alike typically distinguish between a knee-jerk or reactive response and an anticipative or proactive response.

7.1.2

An Area of Professional Practice

The second denition of change management is an area of professional practice. There are dozens, if not hundreds, of independent consultants who will quickly and proudly proclaim that they are engaged in planned change, that they are change agents, that they manage change for their clients, and that their practices are change management practices. There are numerous small consulting rms whose principals would make these same statements about their rms. And, of course, most of the major management consulting rms have a change management practice area. Some of these change management experts claim to help clients manage the changes they face the changes happening to them. Others claim to help clients make changes. Still others oer to help by taking on the task of managing changes that must be made. In almost all cases, the process of change is treated separately from the specics of the situation. It is expertise in this task of managing the general process of change that is laid claim to by professional change agents.

7.1.3

A Body of Knowledge

Stemming from the view of change management as an area of professional practice there arises yet a third denition of change management: the content or subject matter of change management. This consists chiey of the models, methods and techniques, tools, skills and other forms of 152

7.1. WHAT IS CHANGE MANAGEMENT? knowledge that go into making up any practice. The content or subject matter of change management is drawn from psychology, sociology, business administration, economics, industrial engineering, systems engineering and the study of human and organizational behavior. For many practitioners, these component bodies of knowledge are linked and integrated by a set of concepts and principles known as General Systems Theory (GST). It is not clear whether this area of professional practice should be termed a profession, a discipline, an art, a set of techniques or a technology. For now, suce it to say that there is a large, reasonably cohesive albeit somewhat eclectic body of knowledge underlying the practice and on which most practitioners would agree even if their application of it does exhibit a high degree of variance.

7.1.4

A Control Mechanism

For many years now, Information Systems groups have tried to rein in and otherwise ride herd on changes to systems and the applications that run on them. For the most part, this is referred to as version control and most people in the workplace are familiar with it. In recent years, systems people have begun to refer to this control mechanism as change management and conguration management. Moreover, similar control mechanisms exist in other areas. Chemical processing plants, for example, are required by OSHA to satisfy some exacting requirements in the course of making changes. These fall under the heading of Management of Change or MOC. To recapitulate, there are at least four basic denitions of change management: 1. The task of managing change (from a reactive or a proactive posture) 2. An area of professional practice (with considerable variation in competency and skill levels among practitioners) 153

CHAPTER 7. MANAGEMENTUL SCHIMBARII 3. A body of knowledge (consisting of models, methods, techniques, and other tools) 4. A control mechanism (consisting of requirements, standards, processes and procedures).

7.1.5

Content and Process

Organizations are highly specialized systems and there are many dierent schemes for grouping and classifying them. Some are said to be in the retail business, others are in manufacturing, and still others conne their activities to distribution. Some are prot-oriented and some are not for prot. Some are in the public sector and some are in the private sector. Some are members of the nancial services industry, which encompasses banking, insurance, and brokerage houses. Others belong to the automobile industry, where they can be classied as original equipment manufacturers (OEM) or after-market providers. Some belong to the health care industry, as providers, as insureds or as insurers. Many are regulated, some are not. Some face sti competition, some do not. Some are foreign-owned and some are foreign-based. Some are corporations, some are partnerships, and some are sole proprietorships. Some are publicly held and some are privately held. Some have been around a long time and some are newcomers. Some have been built up over the years while others have been pieced together through mergers and acquisitions. No two are exactly alike. The preceding paragraph points out that the problems found in organizations, especially the change problems, have both a content and a process dimension. It is one thing, for instance, to introduce a new claims processing system in a functionally organized health insurer. It is quite another to introduce a similar system in a health insurer that is organized along product lines and market segments. It is yet a dierent thing altogether to introduce a system of equal size and signicance in an educational establishment that relies on a matrix structure. The languages spoken dier. The values dier. The cultures dier. And, at 154

7.2. THE CHANGE PROCESS a detailed level, the problems dier. However, the overall processes of change and change management remain pretty much the same, and it is this fundamental similarity of the change processes across organizations, industries, and structures that makes change management a task, a process, and an area of professional practice.

7.2
7.2.1

The Change Process

The Change Process as Unfreezing, Changing and Refreezing

The process of change has been characterized as having three basic stages: unfreezing, changing, and re-freezing. This view draws heavily on Kurt Lewins adoption of the systems concept of homeostasis or dynamic stability. What is useful about this framework is that it gives rise to thinking about a staged approach to changing things. Looking before you leap is usually sound practice. What is not useful about this framework is that it does not allow for change eorts that begin with the organization in extremis (i.e., already unfrozen), nor does it allow for organizations faced with the prospect of having to hang loose for extended periods of time (i.e., staying unfrozen). In other words, the beginning and ending point of the unfreezechange-refreeze model is stability which, for some people and some organizations, is a luxury. For others, internal stability spells disaster. A tortoise on the move can overtake even the fastest hare if that hare stands still.

7.2.2

The Change Process as Problem Solving and Problem Finding

A very useful framework for thinking about the change process is problem solving. Managing change is seen as a matter of moving from one state to 155

CHAPTER 7. MANAGEMENTUL SCHIMBARII another, specically, from the problem state to the solved state. Diagnosis or problem analysis is generally acknowledged as essential. Goals are set and achieved at various levels and in various areas or functions. Ends and means are discussed and related to one another. Careful planning is accompanied by eorts to obtain buy-in, support and commitment. The net eect is a transition from one state to another in a planned, orderly fashion. This is the planned change model. The word problem carries with it connotations that some people prefer to avoid. They choose instead to use the word opportunity. For such people, a problem is seen as a bad situation, one that shouldnt have been allowed to happen in the rst place, and for which someone is likely to be punished if the guilty party (or a suitable scapegoat) can be identied. For the purposes of this paper, we will set aside any cultural or personal preferences regarding the use of problem or opportunity. From a rational, analytical perspective, a problem is nothing more than a situation requiring action but in which the required action is not known. Hence, there is a requirement to search for a solution, a course of action that will lead to the solved state. This search activity is known as problem solving. From the preceding discussion, it follows that problem nding is the search for situations requiring action. Whether we choose to call these situations problems (because they are troublesome or spell bad news), or whether we choose to call them opportunities (either for reasons of political sensitivity or because the time is ripe to exploit a situation) is immaterial. In both cases, the practical matter is one of identifying and settling on a course of action that will bring about some desired and predetermined change in the situation.

7.2.3

The Change Problem

At the heart of change management lies the change problem, that is, some future state to be realized, some current state to be left behind, and some structured, organized process for getting from the one to the 156

7.2. THE CHANGE PROCESS other. The change problem might be large or small in scope and scale, and it might focus on individuals or groups, on one or more divisions or departments, the entire organization, or one or on more aspects of the organizations environment. At a conceptual level, the change problem is a matter of moving from one state (A) to another state (A). Moving from A to A is typically accomplished as a result of setting up and achieving three types of goals: transform, reduce, and apply. Transform goals are concerned with identifying dierences between the two states. Reduce goals are concerned with determining ways of eliminating these dierences. Apply goals are concerned with putting into play operators that actually eect the elimination of these dierences (see Newell and Simon). As the preceding goal types suggest, the analysis of a change problem will at various times focus on dening the outcomes of the change eort, on identifying the changes necessary to produce these outcomes, and on nding and implementing ways and means of making the required changes. In simpler terms, the change problem can be treated as smaller problems having to do with the how, what, and why of change.

7.2.4

Change as a How Problem

The change problem is often expressed, at least initially, in the form of a how question. How do we get people to be more open, to assume more responsibility, to be more creative? How do we introduce self-managed teams in Department W? How do we change over from System X to System Y in Division Z? How do we move from a mainframe-centered computing environment to one that accommodates and integrates PCs? How do we get this organization to be more innovative, competitive, or productive? How do we raise more eective barriers to market entry by our competitors? How might we more tightly bind our suppliers to us? How do we reduce cycle times? In short, the initial formulation of a change problem is means-centered, with the goal state more or less implied. There is a reason why the initial statement of a problem is so 157

CHAPTER 7. MANAGEMENTUL SCHIMBARII often means-centered and we will touch on it later. For now, lets examine the other two ways in which the problem might be formulated as what or as why questions.

7.2.5

Change as a What Problem

As was pointed out in the preceding section, to frame the change eort in the form of how questions is to focus the eort on means. Diagnosis is assumed or not performed at all. Consequently, the ends sought are not discussed. This might or might not be problematic. To focus on ends requires the posing of what questions. What are we trying to accomplish? What changes are necessary? What indicators will signal success? What standards apply? What measures of performance are we trying to aect?

7.2.6

Change as a Why Problem

Ends and means are relative notions, not absolutes; that is, something is an end or a means only in relation to something else. Thus, chains and networks of ends-means relationships often have to be traced out before one nds the true ends of a change eort. In this regard, why questions prove extremely useful. Consider the following hypothetical dialogue with yourself as an illustration of tracing out ends-means relationships. 1. Why do people need to be more creative? 2. Ill tell you why! Because we have to change the way we do things and we need ideas about how to do that. 3. Why do we have to change the way we do things? 4. Because they cost too much and take too long. 5. Why do they cost too much? 6. Because we pay higher wages than any of our competitors. 158

7.2. THE CHANGE PROCESS 7. Why do we pay higher wages than our competitors? 8. Because our productivity used to be higher, too, but now its not. 9. Eureka! The true aim is to improve productivity! 10. No it isnt; keep going. 11. Why does productivity need to be improved? 12. To increase prots. 13. Why do prots need to be increased? 14. To improve earnings per share. 15. Why do earnings per share need to be improved? 16. To attract additional capital. 17. Why is additional capital needed? 18. We need to fund research aimed at developing the next generation of products. 19. Why do we need a new generation of products? 20. Because our competitors are rolling them out faster than we are and gobbling up market share. 21. Oh, so thats why we need to reduce cycle times. 22. Hmm. Why do things take so long? To ask why questions is to get at the ultimate purposes of functions and to open the door to nding new and better ways of performing them. Why do we do what we do? Why do we do it the way we do it? Asking why questions also gets at the ultimate purposes of people, but thats a dierent matter altogether, a political matter, and one well not go into in this paper. 159

CHAPTER 7. MANAGEMENTUL SCHIMBARII

7.2.7

The Approach taken to Change Management Mirrors Managements Mindset

The emphasis placed on the three types of questions just mentioned reects the management mindset, that is, the tendency to think along certain lines depending on where one is situated in the organization. A persons placement in the organization typically denes the scope and scale of the kinds of changes with which he or she will become involved, and the nature of the changes with which he or she will be concerned. Thus, the systems people tend to be concerned with technology and technological developments, the marketing people with customer needs and competitive activity, the legal people with legislative and other regulatory actions, and so on. Also, the higher up a person is in the hierarchy, the longer the time perspective and the wider the range of issues with which he or she must be concerned. For the most part, changes and the change problems they present are problems of adaptation, that is, they require of the organization only that it adjust to an ever-changing set of circumstances. But, either as a result of continued, cumulative compounding of adaptive maneuvers that were nothing more than band-aids, or as the result of sudden changes so signicant as to call for a redenition of the organization, there are times when the changes that must be made are deep and far-reaching. At such times, the design of the organization itself is called into question. Organizations frequently survive the people who establish them. AT&T and IBM are two ready examples. At some point it becomes the case that such organizations have been designed by one group of people but are being operated or run by another. (It has been said of the United States Navy, for instance, that It was designed by geniuses to be run by idiots.) Successful organizations resolve early on the issue of structure, that is, the denition, placement and coordination of functions and people. Other people then have to live with this design and, because the ends have already been established, these other people are chiey concerned with means. This is why so many problem-solving eorts start 160

7.2. THE CHANGE PROCESS out focused on means. Some organizations are designed to buer their core operations from turbulence in the environment. In such organizations all units t into one of three categories: core, buer, and perimeter. In core units (e.g., systems and operations), coordination is achieved through standardization, that is, adherence to routine. In buer units (e.g., upper management and sta or support functions), coordination is achieved through planning. In perimeter units (e.g., sales, marketing, and customer service), coordination is achieved through mutual adjustment (see Thompson). People in core units, buered as they are from environmental turbulence and with a history of relying on adherence to standardized procedures, typically focus on how questions. People in buer units, responsible for performance through planning, often ask what questions. People in the perimeter units are as accountable as anyone else for performance and frequently for performance of a nancial nature. They can be heard asking what and how questions. Why questions are generally asked by people with no direct responsibility for day-to-day operations or results. The group most able to take this long-term or strategic view is that cadre of senior executives responsible for the continued well being of the rm: top management. If the design of the rm is to be called into question or, more signicantly, if it is actually to be altered, these are the people who must make the decision to do so. Finally, when organizational redenition and redesign prove necessary, all people in all units must concern themselves with all three sets of questions or the changes made will not stand the test of time. To summarize: Problems may be formulated in terms of how, what and why questions. Which formulation is used depends on where in the organization the person posing the question or formulating the problem is situated, and where the organization is situated in its own life cycle. How questions tend to cluster in core units. questions tend to cluster in buer units. 161

CHAPTER 7. MANAGEMENTUL SCHIMBARII People in perimeter units tend to ask what and how questions. questions are typically the responsibility of top management. In turbulent times, everyone must be concerned with everything.

7.3

Skills and Strategies

Managing the kinds of changes encountered by and instituted within organizations requires an unusually broad and nely honed set of skills, chief among which are the following.

7.3.1

Political Skills

Organizations are rst and foremost social systems. Without people there can be no organization. Lose sight of this fact and any would-be change agent will likely lose his or her head. Organizations are hotly and intensely political. And, as one wag pointed out, the lower the stakes, the more intense the politics. Change agents dare not join in this game but they had better understand it. This is one area where you must make your own judgments and keep your own counsel; no one can do it for you.

7.3.2

Analytical Skills

Make no mistake about it, those who would be change agents had better be very good at something, and that something better be analysis. Guessing wont do. Insight is nice, even useful, and sometimes shines with brilliance, but it is darned dicult to sell and almost impossible to defend. A lucid, rational, well-argued analysis can be ignored and even suppressed, but not successfully contested and, in most cases, will carry the day. If not, then the political issues havent been adequately addressed. 162

7.3. SKILLS AND STRATEGIES Two particular sets of skills are very important here: (1) workow operations or systems analysis, and (2) nancial analysis. Change agents must learn to take apart and reassemble operations and systems in novel ways, and then determine the nancial and political impacts of what they have done. Conversely, they must be able to start with some nancial measure or indicator or goal, and make their way quickly to those operations and systems that, if recongured a certain way, would have the desired nancial impact. Those who master these two techniques have learned a trade that will be in demand for the foreseeable future. (This trade, by the way, has a name. It is called Solution Engineering.)

7.3.3

People Skills

As stated earlier, people are the sine qua non of organization. Moreover, they come characterized by all manner of sizes, shapes, colors, intelligence and ability levels, gender, sexual preferences, national origins, rst and second languages, religious beliefs, attitudes toward life and work, personalities, and priorities and these are just a few of the dimensions along which people vary. We have to deal with them all. The skills most needed in this area are those that typically fall under the heading of communication or interpersonal skills. To be eective, we must be able to listen and listen actively, to restate, to reect, to clarify without interrogating, to draw out the speaker, to lead or channel a discussion, to plant ideas, and to develop them. All these and more are needed. Not all of us will have to learn Russian, French, or Spanish, but most of us will have to learn to speak Systems, Marketing, Manufacturing, Finance, Personnel, Legal, and a host of other organizational dialects. More important, we have to learn to see things through the eyes of these other inhabitants of the organizational world. A situation viewed from a marketing frame of reference is an entirely dierent situation when seen through the eyes of a systems person. Part of the job of a change agent is to reconcile and resolve the conict between and among disparate (and sometimes desperate) points of view. Charm is great if 163

CHAPTER 7. MANAGEMENTUL SCHIMBARII you have it. Courtesy is even better. A well-paid compliment can buy gratitude. A sincere Thank you can earn respect.

7.3.4

System Skills

Theres much more to this than learning about computers, although most people employed in todays world of work do need to learn about computer-based information systems. For now, lets just say that a system is an arrangement of resources and routines intended to produce specied results. To organize is to arrange. A system reects organization and, by the same token, an organization is a system. A word processing operator and the word processing equipment operated form a system. So do computers and the larger, information processing systems in which computers are so often embedded. These are generally known as hard systems. There are soft systems as well: compensation systems, appraisal systems, promotion systems, and reward and incentive systems. There are two sets of systems skills to be mastered. Many people associate the rst set with computers and it is exemplied by systems analysis. This set of skills, by the way, actually predates the digital computer and is known elsewhere (particularly in the United States Air Force and the aerospace industry) as systems engineering. For the most part, the kind of system with which this skill set concerns itself is a closed system which, for now, we can say is simply a mechanistic or contrived system with no purpose of its own and incapable of altering its own structure. In other words, it cannot learn and it cannot change of its own volition. The second set of system skills associated with a body of knowledge generally referred to as General Systems Theory (GST) and it deals with people, organizations, industries, economies, and even nations as socio-technical systems as open, purposive systems, carrying out transactions with other systems and bent on survival, continuance, prosperity, dominance, plus a host of other goals and objectives. 164

7.3. SKILLS AND STRATEGIES Table 7.1: The four basic change management strategies Strategy Empirical-Rational information and the proering of incentives. Normative-Reeducative

Description People are rational and revealed to them. Chan

Power-Coercive

Environmental-Adaptive and gradually transferring people from the old one to the new one.

People are social beings values. Change is based norms and values, and d People are basically com told or can be made to authority and the impo People oppose loss and circumstances. Change

7.3.5

Business Skills

Simply put, youd better understand how a business works. In particular, youd better understand how the business in which and on which youre working works. This entails an understanding of money where it comes from, where it goes, how to get it, and how to keep it. It also calls into play knowledge of markets and marketing, products and product development, customers, sales, selling, buying, hiring, ring, EEO, AAP, and just about anything else you might think of.

7.3.6

Four Basic Change Management Strategies

The four basic change management strategies are summarized in the table 7.1. 165

CHAPTER 7. MANAGEMENTUL SCHIMBARII

7.3.7

Factors in Selecting A Change Strategy

Generally speaking, there is no single change strategy. You can adopt a general or what is called a grand strategy but, for any given initiative, you are best served by some mix of strategies. Which of the preceding strategies to use in your mix of strategies is a decision aected by a number of factors. Some of the more important ones follow. Degree of Resistance. Strong resistance argues for a coupling of PowerCoercive and Environmental-Adaptive strategies. Weak resistance or concurrence argues for a combination of Empirical-Rational and Normative-Reeducative strategies. Target Population. Large populations argue for a mix of all four strategies, something for everyone so to speak. The Stakes. High stakes argue for a mix of all four strategies. When the stakes are high, nothing can be left to chance. The Time Frame. Short time frames argue for a Power-Coercive strategy. Longer time frames argue for a mix of Empirical-Rational, Normative-Reeducative, and Environmental-Adaptive strategies. Expertise. Having available adequate expertise at making change argues for some mix of the strategies outlined above. Not having it available argues for reliance on the power-coercive strategy. Dependency. This is a classic double-edged sword. If the organization is dependent on its people, managements ability to command or demand is limited. Conversely, if people are dependent upon the organization, their ability to oppose or resist is limited. (Mutual dependency almost always signals a requirement for some level of negotiation.) 166

7.3. SKILLS AND STRATEGIES

7.3.8

One More Time: How do you manage change?

The honest answer is that you manage it pretty much the same way youd manage anything else of a turbulent, messy, chaotic nature, that is, you dont really manage it, you grapple with it. Its more a matter of leadership ability than management skill. The rst thing to do is jump in. You cant do anything about it from the outside. A clear sense of mission or purpose is essential. The simpler the mission statement the better. Kick ass in the marketplace is a whole lot more meaningful than Respond to market needs with a range of products and services that have been carefully designed and developed to compare so favorably in our customers eyes with the products and services oered by our competitors that the majority of buying decisions will be made in our favor. Build a team. Lone wolves have their uses, but managing change isnt one of them. On the other hand, the right kind of lone wolf makes an excellent temporary team leader. Maintain a at organizational team structure and rely on minimal and informal reporting requirements. Pick people with relevant skills and high energy levels. Youll need both. Toss out the rulebook. Change, by denition, calls for a congured response, not adherence to pregured routines. Shift to an action-feedback model. Plan and act in short intervals. Do your analysis on the y. No lengthy up-front studies, please. Remember the hare and the tortoise. Set exible priorities. You must have the ability to drop what youre doing and tend to something more important. 167

CHAPTER 7. MANAGEMENTUL SCHIMBARII Treat everything as a temporary measure. Dont lock in until the last minute, and then insist on the right to change your mind. Ask for volunteers. Youll be surprised at who shows up. Youll be pleasantly surprised by what they can do. Find a good straw boss or team leader and stay out of his or her way. Give the team members whatever they ask for except authority. Theyll generally ask only for what they really need in the way of resources. If they start asking for authority, thats a signal theyre headed toward some kind of power-based confrontation and that spells trouble. Nip it in the bud! Concentrate dispersed knowledge. Start and maintain an issues logbook. Let anyone go anywhere and talk to anyone about anything. Keep the communications barriers low, widely spaced, and easily hurdled. Initially, if things look chaotic, relax they are. Remember, the task of change management is to bring order to a messy situation, not pretend that its already well organized and disciplined.

168

Chapter 8

Decision Theory

8.1

What is decision theory?

Decision theory is theory about decisions. The subject is not a very unied one. To the contrary, there are many dierent ways to theorize about decisions, and therefore also many dierent research traditions. This text attempts to reect some of the diversity of the subject. Its emphasis lies on the less (mathematically) technical aspects of decision theory.

8.1.1

Relations and numbers

To see how this can be done, let us consider a simple example: You have to choose between various cans of tomato soup at the supermarket. Your value standard may be related to price, taste, or any combination of these. Suppose that you like soup A better than soup B or soup C, and soup B better than soup C. Then you should clearly take soup A. There is really no need in this simple example for a more formal model. However, we can use this simple example to introduce two useful formal models, the need for which will be seen later in more complex examples. One way to express the value pattern is as a relation between the three soups: the relation better than. We have: A is better than B B is better than C A is better than C 169

CHAPTER 8. DECISION THEORY Clearly, since A is better than all the other alternatives, A should be chosen. Another way to express this value pattern is to assign numerical values to each of the three alternatives. In this case, we may for instance assign to A the value 15, to B the value 13 and to C the value 7. This is a numerical representation, or representation in terms of numbers, of the value pattern. Since A has a higher value than either B or C, A should be chosen. The relational and numerical representations are the two most common ways to express the value pattern according to which decisions are made.

8.1.2

The comparative value terms

Relational representation of value patterns is very common in everyday language, and is often referred to in discussions that prepare for decisions. In order to compare alternatives, we use phrases such as better than, worse than, equally good, at least as good, etc. These are all binary relations, i.e., they relate two entities (arguments) with each other. For simplicity, we will often use the mathematical notation AB instead of the common-language phrase A is better than B. In everyday usage, betterness and worseness are not quite symmetrical. To say that A is better than B is not exactly the same as to say that B is worse than A. Consider the example of a conductor who discusses the abilities of the two utists of the orchestra he is conducting. If he says the second utist is better than the rst utist, he may still be very satised with both of them (but perhaps want them to change places). However, if he says the second utist is worse than the rst utist, then he probably indicates that he would prefer to have them both replaced. In common language we tend to use better than only when at least one of the alternatives is tolerable and worse than when this is not the 170

8.1. WHAT IS DECISION THEORY? case. ( [27]) Another important comparative value term is equal in value to or of equal value. We can use the symbol = to denote it, hence A=B means that A and B have the same value (according to the standard that we have chosen). Yet another term that is often used in value comparisons is at least as good as. We can denote it A=B. The three comparative notions better than (), equal in value to (=) and at least as good as (=) are essential parts of the formal language of preference logic. is said to represent preference or strong preference, = weak preference, and = indierence. These three notions are usually considered to be interconnected according to the following two rules: 1. A is better than B if and only if A is at least as good as B but B is not at least as good as A. (AB if and only if A=B and not B=A) 2. A is equally good as B if and only if A is at least as good as B and also B at least as good as A. (A=B if and only if A=B and B=A)

8.1.3

Using preferences in decision-making

In decision-making, preference relations are used to nd the best alternative. The following simple rule can be used for this purpose: An alternative is (uniquely) best if and only if it is better than all other alternatives. If there is a uniquely best alternative, choose it. There are cases in which no alternative is uniquely best, since the highest position is shared by two or more alternatives. The following is an example of this, referring to tomato soups: Soup A and soup B are equally good (A=B) Soup A is better than soup C (AC) 171

CHAPTER 8. DECISION THEORY Soup B is better than soup C (BC) In this case, the obvious solution is to pick one of A and B (no matter which). More generally, the following rule can be used: An alternative is (among the) best if and only if it is at least as good as all other alternatives. If there are alternatives that are best, pick one of them. However, there are cases in which not even this modied rule can be used to guide decision-making.

8.1.4

Numerical representation

We can also use numbers to represent the values of the alternatives that we decide between. For instance, my evaluation of the collected works of some modern philosophers may be given as follows: Bertrand Russell 50 Karl Popper 35 WV Quine 35 Jean Paul Sartre 20 Martin Heidegger 1 It follows from this that I like Russell better than any of the other, etc. It is an easy exercise to derive preference and indierence relations from the numbers assigned to the ve philosophers. In general, the information provided by a numerical value assignment is sucient to obtain a relational representation. Furthermore, the weak preference relation thus obtained is always complete, and all three relations (weak and strict preference and indierence) are transitive. One problem with this approach is that it is in many cases highly unclear what the numbers represent. There is no measure for goodness as a philosopher, and any assignment of numbers will appear to be arbitrary. Of course, there are other examples in which the use of numerical representation is more adequate. In economic theory, for example, willingness to pay is often used as a measure of value. (This is another 172

8.1. WHAT IS DECISION THEORY? way of saying that all values are translated into monetary value.) If I am prepared to pay, say 500f oracertainusedcarand250 for another, then these sums can be used to express my (economic) valuation of the two vehicles. According to some moral theorists, all values can be reduced to one single entity, utility. This entity may or may not be identied with units of human happiness. According to utilitarian moral theory, all moral decisions should, at least in principle, consist of attempts to maximize the total amount of utility. Hence, just like economic theory utilitarianism gives rise to a decision theory based on numerical representation of value (although the units used have dierent interpretations).

8.1.5

Using utilities in decision-making

Numerically represented values (utilities) are easy to use in decisionmaking. The basic decision-rule is both simple and obvious: Choose the alternative with the highest utility. However, this rule cannot be directly applied if there are more than two alternatives with maximal value, as in the following example of the values assigned by a voter to three political candidates: Ms. Anderson 15 Mr. Brown 15 Mr. Carpenter 5 For such cases, the rule has to be supplemented: Choose the alternative with the highest utility. If more than one alternative has the highest utility, pick one of them (no matter which). This is a rule of maximization. Most of economic theory is based on the idea that individuals maximize their holdings, as measured in money. Utilitarian moral theory postulates that individuals should mazimize the 173

CHAPTER 8. DECISION THEORY utility resulting from their actions. Some critics of utilitarianism maintain that this is to demand too much. Only saints always do the best. For the rest of us, it is more reasonable to just require that we do good enough. According to this argument, in many decision problems there are levels of utility that are lower than maximal utility but still acceptable. As an example, suppose that John hesitates between four ways of spending the afternoon, with utilities as indicated: Volunteer for the Red Cross 50 Volunteer for Amnesty International 50 Visit aunt Mary 30 Volunteer for an anti-abortion campaign 50 According to classical utilitarianism, he must choose one of the two maximal alternatives. According to satiscing theory, he may choose any alternative that has sucient utility. If (just to take an example) the limit is 25 units, three of the options are open to him and he may choose whichever of them that he likes. One problem with satiscing utilitarianism is that it introduces a new variable (the limit for satisfactoriness) that seems dicult to determine in a non-arbitrary fashion. In decision theory, the maximizing approach is almost universally employed.

8.2

The standard representation of individual decisions

The purpose of this section is to introduce decision matrices, the standard representation of a decision problem that is used in mainstream theory of individual decision-making. In order to do this, we need some basic concepts of decision theory, such as alternative, outcome, and state of nature. 174

8.2. THE STANDARD REPRESENTATION OF INDIVIDUAL DECISIONS

8.2.1

Alternatives

In a decision we choose between dierent alternatives (options). Alternatives are typically courses of action that are open to the decisionmaker at the time of the decision (or that she at least believes to be so).1 The set of alternatives can be more or less well-dened. In some decision problems, it is open in the sense that new alternatives can be invented or discovered by the decision-maker. A typical example is my decision how to spend this evening. In other decision problems, the set of alternatives is closed, i.e., no new alternatives can be added. A typical example is my decision how to vote in the coming elections. There is a limited number of alternatives (candidates or parties), between which I have to choose. A decision-maker may restrict her own scope of choice. When deliberating about how to spend this evening, I may begin by deciding that only two alternatives are worth considering, staying at home or going to the cinema. In this way, I have closed my set of alternatives, and what remains is a decision between the two elements of that set. We can divide decisions with closed alternative sets into two categories: those with voluntary and those with involuntary closure. In cases of voluntary closure, the decision-maker has herself decided to close the set (as a rst step in the decision). In cases of involuntary closure, closure has been imposed by others or by impersonal circumstances. In actual life, open alternative sets are very common. In decision theory, however, alternative sets are commonly assumed to be closed. The reason for this is that closure makes decision problems much more accessible to theoretical treatment. If the alternative set is open, a denitive
Weirich (1983 and 1985) has argued that options should instead be taken to be decisions that it is possible for the decision-maker to make, in this case: the decision to bring/not to bring the umbrella. One of his arguments is that we are much more certain about what we can decide than about what we can do. It can be rational to decide to perform an action that one is not at all certain of being able to perform. A good example of this is a decision to quit smoking. (A decision merely to try to quit may be less ecient.)
1

175

CHAPTER 8. DECISION THEORY solution to a decision problem is not in general available. Furthermore, the alternatives are commonly assumed to be mutually exclusive, i.e, such that no two of them can both be realized. The reason for this can be seen from the following dialogue: Bob: I do not know what to do tomorrow. In fact, I choose between two alternatives. One of them is to go to professor Schleiers lecture on Kant in the morning. The other is to go to the concert at the concert hall in the evening. Cynthia: But have you not thought of doing both? Bob: Yes, I may very well do that. Cynthia: But then you have three alternatives: Only the lecture, only the concert, or both. Bob: Yes, that is another way of putting it. The three alternatives mentioned by Cynthia are mutually exclusive, since no two of them can be realized. Her way of representing the situation is more elaborate and more clear, and is preferred in decision theory. Hence, in decision theory it is commonly assumed that the set of alternatives is closed and that its elements are mutually exclusive.

8.2.2

Outcomes and states of nature

The eect of a decision depends not only on our choice of an alternative and how we carry it through. It also depends on factors outside of the decision-makers control. Some of these extraneous factors are known, they are the background information that the decision-maker has. Others are unknown. They depend on what other persons will do and on features of nature that are unknown to the decision-maker As an example, consider my decision whether or not to go to an outdoor concert. The outcome (whether I will be satised or not) will depend both on natural factors (the weather) and on the behaviour of other human beings (how the band is going to play). 176

8.2. THE STANDARD REPRESENTATION OF INDIVIDUAL DECISIONS In decision theory, it is common to summarize the various unknown extraneous factors into a number of cases, called states of nature.2 A simple example can be used to illustrate how the notion of a state of nature is used. Consider my decision whether or not to bring an umbrella when I go out tomorrow. The eect of that decision depends on whether or not it will rain tomorrow. The two cases it rains and it does not rain can be taken as the states of nature in a decision-theoretical treatment of this decision. The possible outcomes of a decision are dened as the combined eect of a chosen alternative and the state of nature that obtains. Hence, if I do not take my umbrella and it rains, then the outcome is that I have a light suitcase and get wet. If I take my umbrella and it rains, then the outcome is that I have a heavier suitcase and do not get wet, etc.

8.2.3

Decision matrices

The standard format for the evaluation-choice routine in (individual) decision theory is that of a decision matrix. In a decision matrix, the alternatives open to the decision-maker are tabulated against the possible states of nature. The alternatives are represented by the rows of the matrix, and the states of nature by the columns. Let us use a decision whether to bring an umbrella or not as an example. The decision matrix is as in table 8.3. For each alternative and each state of nature, the decision matrix assigns an outcome (such as dry clothes, heavy suitcase in our example). In order to use a matrix to analyze a decision, we need, in addition to the matrix itself, (1) information about how the outcomes are valued, and (2) information pertaining to which of the states of nature will be realized. The most common way to represent the values of outcomes is to assign
The term is inadequate, since it also includes possible decisions by other persons. Perhaps scenario would have been a better word, but since state of nature is almost universally used, it will be retained here.
2

177

CHAPTER 8. DECISION THEORY Table 8.1: Decision Matrix It rains It does not rain Umbrella Dry clothes, Dry clothes, heavy suitcase heavy suitcase No umbrella Soaked clothes, Dry clothes, light suitcase light suitcase Table 8.2: It Umbrella No umbrella Decision Matrix rains It does not rain 15 15 0 18

utilities to them. Verbal descriptions of outcomes can then be replaced by utility values in the matrix: Mainstream decision theory is almost exclusively devoted to problems that can be expressed in matrices of this type, utility matrices. As will be seen in the chapters to follow, most modern decision-theoretic methods require numerical information. In many practical decision problems we have much less precise value information (perhaps best expressed by an incomplete preference relation). However, it is much more dicult to construct methods that can deal eectively with non-numerical information.

8.2.4

Information about states of nature

In decision theory, utility matrices are combined with various types of information about states of nature. As a limiting case, the decisionmaker may know which state of nature will obtain. If, in the above example, I know that it will rain, then this makes my decision very simple. Cases like this, when only one state of nature needs to be taken into account, are called decision-making under certainty. If you know, for each alternative, what will be the outcome if you choose that alternative, then you act under certainty. If not, then you act under non-certainty. 178

8.3. EXPECTED UTILITY Table 8.3: It Umbrella No umbrella Decision Matrix rains It does not rain 15 15 0 18

Non-certainty is usually divided into further categories, such as risk, uncertainty, and ignorance. The locus classicus for this subdivision is Knight ( [30]), who pointed out that [t]he term risk, as loosely used in everyday speech and in economic discussion, really covers two things which, functionally at least, in their causal relations to the phenomena of economic organization, are categorically dierent. In some cases, risk means a quantity susceptible of measurement, in other cases something distinctly not of this character. He proposed to reserve the term uncertainty for cases of the non-quantiable type, and the term risk for the quantiable cases. ( [30])

8.3

Expected Utility

The dominating approach to decision-making under risk, i.e. known probabilities, is expected utility (EU). This is no doubt the major paradigm in decision making since the Second World War ( [40]), both in descriptive and normative applications.

8.3.1

What is expected utility?

Expected utility could, more precisely, be called probability-weighted utility theory. In expected utility theory, to each alternative is assigned a weighted average of its utility values under dierent states of nature, and the probabilities of these states are used as weights. Let us again use the umbrella example that has been referred to in earlier sections. The utilities are as follows: Suppose that the probability of rain is .1. Then the expected (proba179

CHAPTER 8. DECISION THEORY bilityweighted) utility of bringing the umbrella is .115 + .915 = 15, and that of not bringing the umbrella is .10 + .918 = 16,2. According to the maxim of maximizing expected utility (MEU) we should not, in this case, bring the umbrella. If, on the other hand, the probability of rain is .5, then the expected (probability-weighted) utility of bringing the umbrella is .5 15 + .5 15 = 15 and that of not bringing the umbrella is .5 0 + .5 18 = 9. In this case, if we want to maximize expected utility, then we should bring the umbrella. This can also be stated in a more general fashion: Let there be n outcomes, to each of which is associated a utility and a probability. The outcomes are numbered, so that the rst outcome has utility u1 and probability p1 , the second has utility u2 and probability p2 , etc. Then the expected utility is dened as follows: p1 xu1 + p2 xu2 + ... + pn xun

8.3.2

Objective and subjective utility

In its earliest versions, expected utility theory did not refer to utilities in the modern sense of the word but to monetary outcomes. The recommendation was to play a game if it increased your expected wealth, otherwise not. The probabilities referred to were objective frequencies, such as can be observed on dice and other mechanical devices. In 1713 Nicolas Bernoulli (1687-1759) posed a dicult problem for probability theory, now known as the St. Petersburg paradox. (It was published in the proceedings of an academy in that city.) We are invited to consider the following game: A fair coin is tossed until the rst head occurs. If the rst head comes up on the rst toss, then you receive 1 gold coin. If the rst head comes up on the second toss, you receive 2 gold coins. If it comes up on the third toss, you receive 4 gold coins. In general, if it comes up on the nth toss, you will receive 2n gold coins. The probability that the rst head will occur on the nth toss is 1/2n . Your expected wealth after having played the game is 180

8.3. EXPECTED UTILITY

1/21 + 1/42 + .....1/2n 2n1 + ... This sum is equal to innity. Thus, according to the maxim of maximizing expected wealth a rational agent should be prepared to pay any nite amount of money for the opportunity to play this game. In particular, he should be prepared to put his whole fortune at stake for one single run of the St. Petersburg game. In 1738 Daniel Bernoulli (1700-1782, a cousin of Nicholas) proposed what is still the conventional solution to the St. Petersburg puzzle. His basic idea was to replace the maxim of maximizing expected wealth by that of maximizing expected (subjective) utility. The utility attached by a person to wealth does not increase in a linear fashion with the amount of money, but rather increases at a decreasing rate. Your rst 1000ismoreworthtoyouthanis1000 if you are already a millionaire. (More precisely, Daniel Bernoulli proposed that the utility of the next increment of wealth is inversely proportional to the amount you already have, so that the utility of wealth is a logarithmic function of the amount of wealth.) As can straightforwardly be veried, a person with such a utility function may very well be unwilling to put his savings at stake in the St. Petersburg game. In applications of decision theory to economic problems, subjective utilities are commonly used. In welfare economics it is assumed that each individuals utility is an increasing function of her wealth, but this function may be dierent for dierent persons. In risk analysis, on the other hand, objective utility is the dominating approach. The common way to measure risk is to multiply the probability of a risk with its severity, to call that the expectation value, and to use this expectation value to compare risks. ( [13]) This form of expected utility has the advantage of intersubjective validity. Once expected utilities of the type used in risk analysis have been correctly determined for one person, they have been correctly determined for all persons. In contrast, if utilities are taken to be subjective, then intersubjective validity is lost (and as a consequence of this the role of 181

CHAPTER 8. DECISION THEORY expert advice is much reduced).

8.3.3

Appraisal of EU

The argument most commonly invoked in favour of maximizing objectivist expected utility is that this is a fairly safe method to maximize the outcome in the long run. Suppose, for instance, that the expected number of deaths in trac accidents in a region will be 300 per year if safety belts are compulsary and 400 per year if they are optional. Then, if these calculations are correct, about 100 more persons per year will actually be killed in the latter case than in the former. We know, when choosing one of these options, whether it will lead to fewer or more deaths than the other option. If we aim at reducing the number of trac casualties, then this can, due to the law of large numbers, safely be achieved by maximizing the expected utility (i.e., minimizing the expected number of deaths). The validity of this argument depends on the large number of road accidents, that levels out random eects in the long run. Therefore, the argument is not valid for case-by-case decisions on unique or very rare events. Suppose, for instance, that we have a choice between a probability of .001 of an event that will kill 50 persons and the probability of .1 of an event that will kill one person. Here, random eects will not be levelled out as in the trac belt case. In other words, we do not know, when choosing one of the options, whether or not it will lead to fewer deaths than the other option. In such a case, taken in isolation, there is no compelling reason to maximize expected utility. Nevertheless, a decision in this case to prefer the rst of the two options (with the lower number of expected deaths) may very well be based on a reasonable application of expected utility theory, namely if the decision is included in a suciently large group of decisions for which a metadecision has been made to maximize expected utility. As an example, a strong case can be made that a criterion for the regulation of chemical substances should be one of maximizing expected utility (mini182

8.3. EXPECTED UTILITY mizing expected damage). The consistent application of this criterion in all the dierent specic regulatory decisions should minimize the damages due to chemical exposure. The larger the group of decisions that are covered by such a rule, the more ecient is the levelling-out eect. In other words, the larger the group of decisions, the larger catastrophic consequences can be levelled out. However, there is both a practical and an absolute limit to this effect. The practical limit is that decisions have to be made in manageable pieces. If too many issues are lumped together, then the problems of information processing may lead to losses that outweigh any gains that might have been hoped for. Obviously, decisions can be partitioned into manageable bundles in many dierent ways, and how this is done may have a strong inucence on decision outcomes. As an example, the protection of workers against radiation may be given a higher priority if it is grouped together with other issues of radiation than if it is included among other issues of work environment. The absolute limit to the levelling-out eect is that some extreme eects, such as a nuclear war or a major ecological threat to human life, cannot be levelled out even in the hypothetical limiting case in which all human decision-making aims at maximizing expected utility. Perhaps the best example of this is the Pentagons use of secret utility assignments to accidental nuclear strike and to failure to respond to a nuclear attack, as a basis for the construction of command and control devices. ( [38]) Even in cases in which the levelling-out argument for expected utility maximization is valid, compliance with this principle is not required by rationality. In particular, it is quite possible for a rational agent to refrain from minimizing total damage in order to avoid imposing highprobability risks on individuals. To see this, let us suppose that we have to choose, in an acute situation, between two ways to repair a serious gas leakage in the machineroom of a chemical factory. One of the options is to send in the repairman immediately. (There is only one person at hand who is competent to do the job.) He will then run a risk of .9 to die due to an explosion of the gas 183

CHAPTER 8. DECISION THEORY immediately after he has performed the necessary technical operations. The other option is to immediately let out gas into the environment. In that case, the repairman will run no particular risk, but each of 10 000 persons in the immediate vicinity of the plant runs a risk of .001 to be killed by the toxic eects of the gas. The maxim of maximizing expected utility requires that we send in the repairman to die. This is also a fairly safe way to minimize the number of actual deaths. However, it is not clear that it is the only possible response that is rational. A rational decision-maker may refrain from maximizing expected utility (minimizing expected damage) in order to avoid what would be unfair to a single individual and infringe her rights. It is essential to observe that expected utility maximization is only meaningful in comparisons between options in one and the same decision. Some of the clearest violations of this basic requirement can be found in riks analysis. Expected utility calculations have often been used for comparisons between risk factors that are not options in one and the same decision. Indeed, most of the risks that are subject to regulation have proponents typically producers or owners who can hire a risk analyst to make comparisons such as: You will have to accept that this risk is smaller than that of being struck by lightning, or: You must accept this technology, since the risk is smaller than that of a meteorite falling down on your head. Such comparisons can almost always be made, since most risks are smaller than other risks that are more or less accepted. Pesticide residues are negligible if compared to natural carcinogens in food. Serious job accidents are in most cases less probable than highway accidents, etc. There is no mechanism by which natural food carcinogens will be reduced if we accept pesticide residues. Therefore it is not irrational to refuse the latter while accepting that we have to live with the former. In general, it is not irrational to reject A while continuing to live with B that is much worse than A, if A and B are not options to be chosen between in one and the same decision.To the contrary: To the extent that a self-destructive behaviour is irrational, it would be highly irrational to let oneself be convinced by all comparisons of this kind. We 184

8.3. EXPECTED UTILITY have to live with some rather large natural risks, and we have also chosen to live with some fairly large articial risks. If we were to accept, in addition, all proposed new risks that are small in comparison to some risk that we have already accepted, then we would all be dead. In summary, the normative status of EU maximization depends on the extent to which a levelling-out eect is to be expected. The strongest argument in favour of objectivist EU can be made in cases when a large number of similar decisions are to be made according to one and the same decision rule.

8.3.4

Probability estimates

In order to calculate expectation values, one must have access to reasonably accurate estimates of objective probabilities. In some applications of decision theory, these estimates can be based on empirically known frequencies. As one example, death rates at high exposures to asbestos are known from epidemiological studies. In most cases, however, the basis for probability estimates is much less secure. In most risk assessments of chemicals, empirical evidence is only indirect, since it has been obtained from the wrong species, at the wrong dose level and often with the wrong route of exposure. Similarly, the failure rates of many technological components have to be estimated with very little empirical support. The reliability of probability estimates depends on the absence or presence of systematic dierences between objective probabilities and 35 subjective estimates of these probabilities. Such dierences are wellknown from experimental psychology, where they are described as lack of calibration. Probability estimates are (well-)calibrated if over the long run, for all propositions assigned a given probability, the proportion that is true equals the probability assigned. (Lichtenstein, et al. 1982, pp. 306- 307.) Thus, half of the statements that a well-calibrated subject assigns probability .5 are true, as are 90 per cent of those that she assigns probability .9, etc. Most calibration studies have been concerned with subjects answers 185

CHAPTER 8. DECISION THEORY to general-knowledge (quiz) questions. In a large number of such studies, a high degree of overcondence has been demonstrated. In a recent study, however, Gigerenzer et al. provided suggestive evidence that the overcondence eect in general knowledge experiments may depend on biases in the selection of such questions. ( [25]) Experimental studies indicate that there are only a few types of predictions that experts perform in a well-calibrated manner. Thus, professional weather forecasters and horse-race bookmakers make wellcalibrated probability estimates in their respective elds of expertise. (Murphy and Winkler 1984. Hoerl and Fallin 1974) In contrast, most other types of prediction that have been studied are subject to substantial overcondence. Physicians assign too high probability values to the correctness of their own diagnoses. ( [16]) Geotechnical engineers were overcondent in their estimates of the strength of a clay foundation. ( [28]) Probabilistic predictions of public events, such as political and sporting events, have also been shown to be overcondent. In one of the more careful studies of general-event predictions, Fischho and MacGregor found that as the condence of subjects rose from .5 to 1.0, the proportion of correct predictions only increased from .5 to .75. ( [22]) Perhaps surprisingly, the eects of overcondence may be less serious when experts estimates of single probabilities are directly communicated to the public than when they are rst processed by decision analysts. The reason for this is that we typically overweight small probabilities. (Tversky and Kahneman 1986) In other words, we make too little dierence (as compared to the expected utility model) between a situation with, say, a .1% and a 2% risk of disaster. This has often been seen as an example of human irrationality. However, it may also be seen as a compensatory mechanism that to some extent makes good for the eects of overcondence. If an overcondent expert estimates the probability of failure in a technological system at .01%, then it may be more reasonable to behave as if it is higher than .01% as the unsophisticated public does than to behave as if it is exactly .01% as experts tend to recommend. It must be emphasized that this compensatory mechanism is far 186

8.4. VARIATIONS OF EXPECTED UTILITY from reliable. In particular, it will distort well-calibrated probabilities, such as probabilities that are calculated from objective frequencies. In summary, subjective estimates of (objective) probabilities are often unreliable. Therefore, no very compelling argument can be made in favour of maximizing EU if only subjective estimates of the probability values are available.

8.4

Variations of expected utility

A large number of models for decision-making under risk have been developed, most of which are variations or generalizations of EU theory. Two of the major variations of EU theory are discussed in this section.

8.4.1

Process utilities and regret theory

In EU, an option is evaluated according to the utility that each outcome has irrespectively of what the other possible outcomes are. However, these are not the only values that may inuence decision-makers. A decision-maker may also be inuenced by a wish to avoid uncertainty, by a wish to gamble or by other wishes that are related to expectations or to the relations between the actual outcome and other possible outcomes, rather than to the actual outcomes as such. Such values may be represented by numerical values, process utilities ( [42]). Although process utilities are not allowed in EU theory, we can say that there is a presumption in favour of the view that it is not irrational to value certainty as such (because this is in accord with ordinary intuition) and that no argument has been presented and there seems little prospect of such an argument being presented that would force us to abandon that presumption. ( [42]) A generalized EU theory (GEU) that takes process utilities into account allows for the inuence of attitudes towards risk and certainty. In the words of one of its most persistent proponents, it resolves Allaiss and Ellsbergs paradoxes. By making consequences include risk, it makes 187

CHAPTER 8. DECISION THEORY expected utilities sensitive to the risks that are the source of trouble in these paradoxes, and so brings M[aximization of] E[xpected] U[tility] into agreement with the preferences advanced in them. ( [48]) Regret theory ( [33]) makes use of a two-attribute utility function that incorporates two measures of satisfaction, namely (1) utility of outcomes, as in classical EU, and (2) quantity of regret. By regret is meant the painful sensation of recognising that what is compares unfavourably with what might have been. The converse experience of a favourable comparison between the two has been called rejoicing. ( [43]) In the simplest form of regret theory, regret is measured as the difference in value between the assets actually received and the highest level of assets produced by other alternatives. ( [10]) The utility function has the form u(x,y), where x represents actually received assets and y the dierence just referred to. This function can reasonably be expected to be an increasing function of both x and y. (For further mathematical conditions on the function, see [10]) Regret theory provides a simple explanation of Allaiss paradox. A person who has chosen option B has, if state of nature S3 materializes, strong reasons to regret her choice. A subject who has chosen option D would have much weaker reasons to regret her choice in the case of S3. When regret is taken into consideration, it seems quite reasonable to prefer A to B and D to C. Regret theory can also explain how one and the same person may both gamble (risk prone behaviour) and purchase insurance (risk averse behaviour). Both behaviours can be explained in terms of regret-avoidance. [I]f you think of betting on a particular horse for the next race and then decide not to, it would be awful to see it win at long odds. (Provided that gambling on the horse is something you might have done, i.e. something that was a real option for you. Cf. Sugden 1986, pp. 72-73.) In the same way, seeing your house burn down after you have decided not to insure it would be an occasion for strongly felt regret. 188

8.4. VARIATIONS OF EXPECTED UTILITY

8.4.2

Prospect theory

Prospect theory was developed by Kahneman and Tversky ([1979] 1988, 1981) to explain the results of experiments with decision problems that were stated in terms of monetary outcomes and objective probabilities. Nevertheless, its main features are relevant to decision-making in general. Prospect theory diers from most other teories of decision-making by being unabashedly descriptive and making no normative claims. (Tversky and Kahneman 1986, p. 272) Another original feature is that it distinguishes between two stages in the decision process. The rst phase, the editing phase serves to organize and reformulate the options so as to simplify subsequent evaluation and choice. (Kahneman and Tversky [1979] 1988, p. 196) In the editing phase, gains and losses in the dierent options are identied, and they are dened relative to some neutral reference point. Usually, this reference point corresponds to the current asset position, but it can be aected by the formulation of the oered prospects, and by the expectations of the decision maker. In the second phase, the evaluation phase the options as edited in the previous phase are evaluated. According to prospect theory, evaluation takes place as if the decision-maker used two scales. One of these replaces the monetary outcomes given in the problem, whereas the other replaces the objective probabilities given in the problem. Monetary outcomes (gains and losses) are replaced by a value function v. This function assigns to each outcome x a number v(x), which reects the subjective value of that outcome. In other words, the value function is a function from monetary gains and losses to a measure of subjective utility. The major dierence between this value function and conventional subjective utility is that it is applied to changes that is gains and losses rather than to nal states. Since the value function is dierent for dierent reference points (amounts of present wealth), it should in principle be treated as a function of two arguments, v(w, x), where w is the present state of wealth. (For a similar proposal, see Bengt Hansson 1975.) However, this com189

CHAPTER 8. DECISION THEORY plication of the theory can, for many practical situations, be dispensed with, since the preference order of prospects is not greatly altered by small or even moderate variations in asset position. (Kahneman and Tversky [1979] 1988, p. 200) As an example, most people are indierent between a 50 per cent chance of receiving 1000 dollars and certainty of receiving some amount between 300 and 400 dollars, in a wide range of asset positions. (In other words, the certainty equivalent of a 50 per cent chance of receiving 1000 dollars is between 300 or 400 dollars.) Objective probabilities are transformed in prospect theory by a function p that is called the decision weight. p is an increasing function from and to the set of real numbers between 0 and 1. It takes the place that probabilities have in expected utility theory, but it does not satisfy the laws of probability. It should not be interpreted as a measure of degree of belief. (Kahneman and Tversky [1979] 1988, p. 202) (As an example of how it violates the laws of probability, let A be an event and let?? be the absence of that event. Then, if q is a probability measure, q(A) + q(??) = 1. This does not hold for p. Instead, p(p(A)) + p(p(??)) it typically less than 1.) First: Probability dierences close to certainty are overweighted. We consider the dierence between a 95 per cent chance of receiving 1000000andcertaintytoreceive 1 000 000 as in some sense bigger than the dierence between a 50 per cent chance and a 55 per cent chance to the same amount of money. Similarly, a reduction of the probability of leakage from a waste repository from .01 to 0 is conceived of as more important and perhaps more worth paying for than a reduction of the probability from, say, .11 to .10. The overweighting of small probabilities can be used to explain why people both buy insurance and buy lottery tickets. Secondly: The weighting function is undened in the areas that are very close to zero and unit probabilities. 190

8.5. SOCIAL DECISION THEORY

8.5

Social decision theory

Decision rules that have been developed for individual decision-making may in many cases also be used for decision-making by groups. As one example, theories of legal decision-making do not in general make a dierence between decisions by a single judge and decisions by several judges acting together as a court of law. The presumption is that the group acts as if it were a single individual. Similarly, most theories for corporate decision-making treat the corporation as if all decisions were to be taken by a single individual decision-maker. ( [23]) Indeed, [a]ny decision maker - a single human being or an organization - which can be thought of as having a unitary interest motivating its decisions can be treated as an individual in the theory. ( [34]) By a collective decision theory is meant a theory that models situations in which decisions are taken by two or more persons, who may have conicting goals or conicting views on how the goals should be achieved. Such a theory treats individuals as having conicting interests which must be resolved, either in open conict or by compromise. ( [34]) Most studies in collective decision theory concern voting, bargaining and other methods for combining individual preferences or choices into collective decisions. The most important concern of social decision theory is the aggregation of individual preferences (choices) into collective preferences (choices). The central problem is to nd, given a set of individual preferences, a rational way to combine them into a set of social preferences or into a social choice. Social decision theory is not a smaller eld of knowledge than individual decision theory. Therefore, this short chapter can only be a very rudimentary introduction. 191

CHAPTER 8. DECISION THEORY

8.5.1

The basic insight

The fundamental insight in social decision theory was gained by Borda and Condorcet, but forgotten for many years. They discovered that in simple majority rule, there may be situations in which every option is unstable in the sense that a majority coalition can be formed against it. To see what this means in practice, let us consider the following example. We will assume that three alternatives are available for the handling of nuclear waste. The nuclear industry has worked out a proposal, and provided documentation to show that it is safe enough. We will call this the industry proposal. A group of independent scientists, who were sceptical of the industry proposal, developed a proposal of their own. It contains several more barriers than the industry proposal, and is therefore considered to be safer. On the other hand, it is several times more expensive. We will call this the expensive solution. But in spite of the extra barriers, many environmentalists have not been convinced even by the expensive solution. They propose that the whole issue should be postponed until further studies have been conducted. In parliament, there are three factions of approximately the same size. The members of the rst faction (the economists) are mostly concerned with economic and technological development. They put the industry proposal rst. In the choice between postponement and the expensive solution, the prefer the former, for economic reasons. Thus, their preferences are: Economists:

industry proposal postponement expensive solution The second faction (the ethicists) is most of all concerned with our responsibility not to hand over the problem to the generations after us. 192

8.5. SOCIAL DECISION THEORY They want the problem to be solved now, with the best method that is available. Their preferences are: Ethicists:

expensive solution industry proposal postponement The third group (the environmentalists) prefer to postpone the nal deposition of the waste, since they do not believe even in the expensive solution. Their preferences are: Environmentalists:

postponement expensive solution industry proposal Now let us see what happens in majority voting. First suppose that the industry proposal wins. Then a coalition of ethicists and environmentalists can be formed to change the decision, since these two groups both prefer the expensive solution to the industry proposal. Next, suppose that the expensive solution has won. Then a coalition to change the decision can be formed by economists and environmentalists, since they both prefer postponement to the expensive solution. Finally, suppose that postponement has won. Then the decision can be changed by a coalition of economists and ethicists, who both prefer the industry proposal to postponement. We started with three reasonably rational patterns of individual preferences. We used what we believed to be a rational method for aggregation, and arrived at cyclic social preferences. 193

Chapter 9

Project Closure
Project Closure Phase is the last phase of the Project Life Cycle. The commencement of the Project Closure Phase is determined by the completion of all Project Objectives and acceptance of the end product by the customer. Project Closure includes the following tasks: Release of the resources, both sta and non-sta, and their redistribution and reallocation to other projects, if needed. Closure of any nancial issues like labour, contract etc. Collection and Completion of All Project Records. Archiving of All Project Records. Documenting the Issues faced in the Project and their resolution. This helps other projects to plan for such type of issues in the Project Initiation Phase itself. Recording Lessons Learned and conducting a session with the Project Team on the same. This helps in the productivity improvement of the team and helps identify the dos and donts of the Project. Celebrate the Project Completion. Its party time folks!!! The basic process of the Project Closure Phase involves: 195

CHAPTER 9. PROJECT CLOSURE Administrative Closure. This is the process of preparation of closure documents and process deliverables. This includes the release and redistribution of the Project Resources. Development of Project Post Implementation Evaluation Report. It includes Project Sign-O Stang and Skills Project Organizational Structure Schedule Management Cost Management Quality Management Conguration Management Customer Expectations Management Lessons Learned Lessons Learned form an integral part of the Project Closure Phase. It helps answer the following typical question during Project Closure. Did the delivered product / solution meet the project requirements and objectives? Was the customer satised? Was Project Schedule Met? Was the Project completed within Budgeted Cost? Were the risks identied and mitigated? What could be done to improve the process? 196

9.1. PROJECT EVALUATION The outputs from Project Closure Phase provides as a stepping stone to execute the next projects with much more eciency and control.

9.1

Project evaluation

The project managers direct responsibility to the customer ended with the sign o of the handover report however the project manager still bears considerable responsibility to the sponsor and the delivery organisation. Of particular importance is this review and evaluation activity which seeks to evaluate the project performance in terms of the success criteria and key performance indicators established in the concept phase. In addition the review seeks to identify changes to organisational processes and procedures that should be fed back into the strategic, business and project planning processes to improve organisational performance. This activity covers the actions necessary to review and evaluate the projects performance and produce a project completion report. The purpose of this activity is to: identify and document how the project performed in terms of the success criteria and key performance indicators established in the concept phase, evaluate the organisational processes and procedures used throughout the project, identify where problems occurred, and recommend improvements identify and explain any variance between the initial baseline plan, contract and schedule and their nal versions, assess how well the individual management plans performed (risk, safety environment, and so on) and identify procedural modications that would improve their performance, document the evaluation in a project completion report 197

CHAPTER 9. PROJECT CLOSURE Communication and consultation with all stakeholders is important to obtain a fair and honest appraisal of the projects performance. It may be appropriate to use a method of communication that protects the identity of people to help elicit useful criticism. The tasks to be carried out at this stage are: Evaluate against success criteria Prepare completion report Review and proposal

9.1.1

Evaluation against success criteria

Project success criteria specied in the business case should be reviewed. This task reviews the projects actual performance against those measures to determine project success. Performance should be reviewed against both initial and nal baselines. Any variance between the initial versions and nal versions of the schedule, plan and contract need to be identied and justied. The review seeks to identify changes to organisational processes and procedures that should be fed back into the strategic, business and project planning processes to improve organisational performance. This task also includes, in eect, an audit to ensure all activities to nalise the project have been completed. Final costs are determined and compared with the various estimates produced throughout the project lifecycle to determine how well the estimation performed.

9.1.2

Preparing the completion report

The project completion report documents the complete projects performance and provides a succinct history of changes to the originally justied proposal. The report further documents lessons learnt for use by subsequent projects. These lessons should be fed back into the organisations strategic, business and project planning processes to ensure 198

9.1. PROJECT EVALUATION mistakes are not repeated and enable components that worked well to be repeated in subsequent projects. This report includes the results of the previous steps evaluation of project performance against the pre-determined success criteria. It also evaluates project governance arrangements.

9.1.3

Review and approval

The completed project completion report should be circulated to all relevant stakeholders for review prior to submission to the sponsor for approval. On completion, the signed project completion report is stored in a way that makes it accessible to other project managers as required. The project manager is responsible for coordinating the review. The sponsor is responsible for a timely consideration and approval of the report.

199

Chapter 10

Concluzii

10.1

Viitorul apartine organizatiilor centrate pe proiecte

Amploarea managementului proiectelor ca modalitate de a sustine competitia economica, de a raspunde mediului economic din ce n ce mai solicitant a condus la aparitia unui nou tip de organizatie - organizatia centrata pe proiecte. In cazul unei astfel de organizatii, performanta nu se mai masoara, spre exemplu, n functie de soliditatea organigramei, ci n functie de capacitatea de a se adapta la proiecte si n functie de consistenta portofoliului de proiecte. Valoarea organizatiei nu se mai masoara dupa numarul de angajati. Competenta profesionala nu mai este nici ea o valoare n sine, ceea ce conteaza mai mult este viteza cu care angajatii si unesc abilitatile si cunostintele pentru a gasi o solutie la o problema comuna, precum si viteza cu care, o data rezolvata problema (o data ncheiat proiectul), angajatii formeaza combinatii diferite pentru a rezolva o noua problema. Armatia ca viitorul apartine organizatiilor orientate pe proiecte nu constituie o exagerare. Flexibilitatea si adaptabilitatea care caracterizeaza acest tip de organizatie permit permanenta regrupare si reorganizare a resurselor umane si informationale. Proiectele reprezinta modalitatea prin care organizatiile se adapteaza contextelor n schimbare. Ele sunt punctele de stabilitate, iar organizatiile devin uide si graviteaza n jurul lor [36]. Organizatia centrata pe proiecte nu mai este compusa din departa201

CHAPTER 10. CONCLUZII mente care lucreaza ecare pe diferite segmente ale unui proiect. Proiectul este, de asta data, cel care impune structurarea pe departamente: departamentul de productie al proiectului 1, departamentul de productie al proiectului 2, departamentul nanciar al proiectului 1 etc. Cteva dintre avantajele create ca urmare a structurarii activitatii pe proiecte sunt: exista o unitate a abordarilor si a metodologiilor aplicate; proiectele se deruleaza potrivit unei proceduri standardizate; standardizarea se extinde si la nivelul metodelor de raportare, de monitorizare a evolutiei proiectelor, de diseminare a rezultatelor intermediare si nale; activitatea de management de proiect capata o nalta nota profesionala; metodele de atenuare si contracarare a riscului sunt, si ele, unitare; ecare proiect derulat cstiga vizibilitate n ansamblul organizatiei; utilizarea instrumentelor specice managementului de proiect devine previzibila s, prin urmare, mai ecienta; protabilitatea proiectelor pe care le deruleaza organizatia creste; din moment ce se aplica o procedura standard, previzibila, care s-a dovedit viabila, posibilitatile de esec se diminueaza. Ca urmare a noii modalitati de structurare a departamentelor, organizatiile centrate pe proiecte se pot confrunta cu fenomenul de redundanta a activitatilor n cadrul diferitelor proiecte. De asemenea, exista pericolul unei birocratizari excesive a activitatii. Dar organizatiile sunt dispuse sa accepte eventualele neajunsuri, care sunt ponderate de ecienta si calitate maxima pe un proiect anume. 202

10.2. 9 LUCRURI DE TINUT MINTE

10.2

9 lucruri de tinut minte

1. Support the Creation of Historical Records Minimal historical records should include: WBS, estimates, risks and lessons learned from every past project. Use them to plan, estimate and manage future projects. 2. Provide a Project Charter with Clear Goals and Objectives. Charters include: A one paragraph description of the project. Names of the Project Manager and team members Clearly dened quantitative goals and objectives The reason the project is being done Charters serve as a target for the project and provide a way to measure success. 3. Protect Projects from Outside Inuences, Changes and Resource Stealing 4. Allow Teams Enough Time to Properly Plan Projects Teams need time to plan projects. A good plan decreases project length and cost. A project schedule can not be delivered in a few days. 5. Ensure Finalized Scope of Work Before the Project Starts There is little excuse for not having a nalized scope of work before you begin a project. Late changes can cost 100 times more. 6. Prioritize Projects Withing Company or Department Everyone in the organization should know which projects are one, two and three. 7. Require Proper Project Management to be Done Your support of project management is critical for it to be of use to your organization. Focus on project charters, WBS and risk management. 203

CHAPTER 10. CONCLUZII 8. Do Not Run at 100% Capacity Overtime is not an option. Any one problem will cause massive problems for all projects. 9. You Cannot Get Something for Nothing Changes in scope, time and cost WILL impact PROJECT scope, time and/or cost. Do not allow people to ask for little extras and not expect to pay for them.

204

Bibliography

[1] ISO 9000 Part 3 - Quality management and quality assurance standards - Guidelines for the application of ISO 9001 to the development, supply and maintenance of software. Geneve, Switzerland, 1991. [2] Software Management Guide Volume II. Software Technology Service Center, Hill AFB, 1993. [3] Practical Software Measurement, Version 2.1. Joint Logistics Commanders Joint Policy Group on Systems Engineering, 1996. [4] McDonnell Douglas Job Aid. F/A-18E/F Risk Management Process. McDonnell Douglas, 1995. [5] Rockwell Job Aid. Risk Management. Rockwell, 1995. [6] T.J. Allen. Managing the ow of technology. MIT Press. Cambridge, 1977. [7] s.a. Balog Alexandru, Olaru Ma-rieta. Managementul calitatii si protectia consumatorilor. Litograe ASE, Bucuresti, 1997. 205

BIBLIOGRAPHY [8] Henri Barki, Suzanne Rivard, and Jean Talbot. Toward an assessment of software development risk. Journal of Management Information Systems, 10(2):203225, 1993. [9] Tudor Baron, I. Ivan, and Al. Balog. The characteristic system of software products quality. Economic Computation and Economic Cybernetics Studies and Research, ASE Bucharest, (1):2944, 1982. [10] David E Bell. Regret in decision making under uncertainty. Operations Research, 30:961981, 1982. [11] B. W. Boehm. A spiral model of software development and enhancement. Computer, pages 6172, 1988. [12] B. W. Boehm. Software risk management: Principle and practices. IEEE Software, 8(1):3241, 1991. [13] Herman Bondi. Risk, chapter Risk in perspective. 1985. [14] F. P. Jr. Brooks. The mythical man-month. Datamation, pages 4452, 1974. [15] L. Chaney and J. Martin. Intercultural business communication. Prentice-Hall: Upper Saddle River, 1995. [16] JJJ Christensen-Szalanski and JB Bushyhead. Physicians use of probabilistic information in a real clinical setting. Journal of Experimental Psychology: Human Perception and Performance, 7:928935, 1921. [17] Edmund H. Conrow. Managing risk in aerospace programs. Aerospace America, 35(4):3639, 1997. [18] D. Crystal. English as a Global Language. Cambridge University Press: Cambridge, 1997. [19] Darleen A. Druyun. Software Metrics Policy - ACTION MEMORANDUM. Department of the Air Force, Washington, DC, 1994. 206

BIBLIOGRAPHY [20] Richard Fairley. Risk management for software projects. IEEE Software, pages 5767, 1994. [21] Stewart Fenwick. Analytical Methods in Software Engineering Economics, chapter CECOMs Approach for Developing Denitions for Software Size and Software Personnel - Two Important Software Economic Metrics. Springer-Verlag, 1993. [22] Baruch Fischho and R Beyth. i knew it would happen remembered probabilities of once-future things. Organizational Behavior and Human Performance, 13:116, 1975. [23] Anthony NS Freeling. A philosophical basis for decision aiding. Theory and Decision, 16:179206, 1984. [24] Brian P. Gallagher, Christoper J. Alberts, and Richard E. Barbour. A Guidebook Version 0.02, CMU/SEI-97-HB-002, chapter Software Acquisition Risk Management Key Process Area (KPA). Carnegie Mellon University, 1997. [25] Gerd Ulrich Horage Gigerenzer and Heinz Kleinblting. Probabilistic mental models. Psychological Review, 98:506528, 1991. [26] C. L. Guss. Virtual project management: tools and the trade. In Proceedings of the 28th Annual Project Management Institute 1997, 1997. [27] Sren Halldn. On the Logic of Better. 1957. [28] M Hynes and E Vanmarcke. [29] Iris Kameny, Umar Khan, Jody Paul, and David Taylor. Guide for the Management of Expert Systems Development. Rand Corporation, Santa Monica Ca, 1989. [30] FH Knight. Risk, Uncertainty and Prot. 1935. 207

BIBLIOGRAPHY [31] B. Latane, A. Nowak, and H.H. Liu. Measuring emergent social phenomena: dynamics, polarization, and clustering as order parameters of social systems. Behavioral Science, (30):124, 1994. [32] D. Leonard, P.A. Brands, A. Edmonson, and J. Fenwick. Capturing Value in the Network Era, chapter Virtual teams: using communications technology to manage geographically dispersed development groups. Harvard Business School Press: Boston, 1998. [33] G Loomes and R Sugden. Regret theory: an alternative theory of rational choice under uncertainty. Economic Journal, 92:805824, 1982. [34] R Duncan Luce and Howard Raia. Games and Decisions. 1957. [35] A. Meharabian. Communication without words. Psychology Today, pages 5355, 1968. [36] Abbe Mowshowitz. The switching principie in virtual organization. Orgaiiizational Virtuabiess, 1(1), 2000. [37] M. OHara-Devereaux and R. Johansen. Global work: bridging distance, culture, and time. Jossey-Bass: San Francisco, 1994. [38] ME Pat-Cornell and JE Neu. Warning systems and defense policy: A reliability model for the command and control of u.s. nuclear forces. Risk Analysis, 5:121138, 1985. [39] Shari Lawrence Peeger. Lessons learned in building a corporate metrics program. IEEE Software, pages 6774, 1993. [40] Paul JH Schoemaker. The expected utility model: Its variants, purposes, evidence and limitations. Journal of Economic Literature, 20:529563, 1982. [41] A. Schultz. Software Management Metrics. USAF, Hanscom AFB, 1998. 208

BIBLIOGRAPHY [42] Lanning Sowden. The inadequacy of bayesian decision theory. Philosophical Studies, 45:293313, 1984. [43] Robert Sugden. Recent Developments in the Foundations of Utility and Risk Theory, chapter Regret, recrimination and rationality. 1986. [44] Baron Tudor. Calitate si abilitate - manual practic. Tehnica, 1988. Editura

[45] J. Turman and P. McMakin. Project management for the twentyrst century: the internet-based cybernetic project team. In Proceedings of the 28th Annual Project Management Institute 1997, 1997. [46] Gerald M. Weinberg. Quality Software Management - First Order Measurement. Dorset House Publishing, 1993. [47] Gerald M. Weinberg. Quality Software Management - System Thinking. Dorset House Publishing, 1993. [48] Paul Weirich. A decision makers options. Philosophical Studies, 44:175186, 1983. [49] Richard E. Zultner. Tqm for technical teams. Communications of the ACM, 30(10):7990, 1993.

209