[1] A stat of the art rev on sftw proj perf managmnt.pdf

4th IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2010) ©2010 IEEE. A state of the art review on software project performance management Suasak Komchaliaw DEBI Institute, Curtin University Perth, Australia Abstact- Several domain experts in the feld of software development and project management have commented on the high failure rate of sofware engineering and project management. A lo
of 3
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  4th IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2010) ©2010 IEEE A state of the art review on software project performance management Sasak Komchaliaw DEBI Institute, Curin University Perh, Australia  Maxtocp@hotmail.om Absact- Several domain experts in the eld of software development and project management hve commented on the high failure rate of sowre engineering and project management. A lot of money has been wsted on failed soware projects. Additionally, software quality is not improving. Thus the successful management of software projects is critical. It is vital to understand what is important to complete software project on time within budget, and meet user requirements. Many literatures present project failure causes. However, project filure still persists. In this paper we outline soware development failure. Then we present two key variables in software project performance management i.e. trust and knowledge sharing. y: f v f;    f ; ;   I. NTRODUCTION Several domain expers in the eld of softare development and projet management have omented on the failure rate of softare engineering and projet management e.g. ã Various failure rates for software development projets are up to 85% [1]. ã 50% of all softare projets are total failures and another 40% are parial failures aording to widely quoted surveys in U, USA, and Noray [2]. ã  Approximately 31 % of orporate software development projets are anelled before ompletion and 53% are hallenged and ost 180% above their srcinal estimate aording to the Standish Group in 1994 [3]. ã 46% of soware projets are having ost or time ove or not lly meet ser' reqrements an 19% are outright failures aording to the Standish Group in 2007 [4]. This has shown that projet failure rate is high. A lot of money has been wasted on failed softare projets. Aording  to the Standish Group Inteational, roughly 15% never deliver a nal produt osting $67 billion per year [4]. Stories of softare failure attrat publi atention. Additionally Cea and Veer [5] believe that soware quality is not improving Popit W ongthongtham DEBI Institute, Curin University Perh, Australia P.W ongthongtham@bs.ur neither but getting worse. Thus the suessl management of soware projets is ritial. It is vital to understand what is imporant to omplete soware projet on time within budget, and meet user requirements. Many literatures [5-11] present projet failure auses. However, projet failure still persists. In this paper we give overview of software development failure in setion 2. Then we present the two key variables in soware projet  performane management in setion 3. We disuss and onlude the paper in setion 4. II. VERVIE OF OFTARE EVELOMENT AILURE A Ter Teamwork issues refer to issues related to team member development, omuniation beteen members, and team management. Team members also inlude ustomers, users, and stakeholders. Reason that is most ited for projet failure is ineffetive ommuiation and oordination among projet  teams. Other fators inlude inexperiened projet manager, lak of speialized skills, low ondene in team members, insuient suppor from manager, inadequately train of team members. DeMaro and Lister arged that aspet of the sills and interations of softare team is most ritial and hard to overome [11]. B rje Mee Projet management issues refer to issues related to projet  plan and shedule, budget, assessment, ontrol, quality assurane. This inludes unerainty of projet lestones, hange management, progress repor, and projet management methodology. C Te Ae Tenial aspets refer to issues related to softare proess ativities inluding requirement engineering, design, implementation, testing, validation and veriation. It ould ause by ambiguous system requrement, inorret system requirement, wrong development strategies, inappropriate soware design, inadequate testing, lak of reusable suppor of data, ode, omponent, doument, et. However, MCreery and Moranta believe that projet hallenges were more  behavioral and inteersonal than teal [9]. Issues related 653  4th IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2010) ©2010 IEEE.  to ommuniation, ollaboration, and team onnetedness are more ritial. D rje Cex Projet omplexity issues refer to issues related to the omplexity of projet requirements. This inludes the projets  utilizing utting edge tehnology and that require high level of  tehnial omplexity. III. EY ARIABLES IN ERFORMANCE ANAGEMENT From the above overview of soware development failure, we identies two key variables i.e. trst and knowledge sharing a rtal nene fato n soware development. A Tru The onept of trst is related to different and various elds inluding philosophy, soiology, business, omputing. Thee are number of trst deitions. Mayer et al. dene trust as the willingness of a pary to be vulnerable to the ations of another  pary based on the expetation that the other will perform a  pariular ation imporant to the trst or, irrespetive of the ability to monitor or ontrol that other pary [12]. Moe and Smite dene trst as the shared pereption by the majority of  team members that individuals in the team will perform  pariular ations imporant to its members and that the individuals will reogize and protet the rights and interests of all the team members engaged in their joint endeavour [10]. Jarvenpaa et al believe that trst has diret positive effet on ooperation and performane and an inrease in trst is likely  to have a diret, positive impat on team members' attitudes and pereved otomes [3). Gddens [] sees tst in different view and says that there would be no need of trst if  the ativities were learly visible and easy to understand. Hene from his view the prime ondition for lak of trst is lak of ll inforation or ambiguous information. As a result  trst requires a good knowledge sharing. Trst an be founded in different ways. The most ommon way is a diret relationship. In verial view trst is imporant  to leadership while in horizontal view trst is imporant for knowledge sharing and team working. In relation to teamwork  the two most imporant dimensions of trst that should be foused are benevolene and ompeteny. Benevolene is related to willingness within teamwork based on the idea that members will not intentionally harm another when given the oppority to do so. This kind of trst an be positive or negative whih members in the team may believe on others willingness to share knowledge and trst level an be in highest level. On the other hand, they may rese to others willingness and tt an be negatve. Te eond menion of tt  ompeteny. This kind of trst refers to trsting agent's believe on trsted agent's ompeteny. It desribes a relationship in whih a member believes that another membe is knowledgeable about a given subjet area. Competene-based  trst also an be negative or positive and members an believe on others ability or they ompletely rese others ability in a given subjet area. B ede r  Wang and Yang dene knowledge sharing as the ation in whih people dispread relevant information to others aross the orgaization [11). Melnik and Maurer divide nowledge sharing into two perspetives i.e. odiation approah and  personalization approah [15). Codiation approah is based on the notion of nowledge as objet [16-19] whih an be reated, olleted, stored, and reused [15). Personalization approah is based on the notion of knowledge as relationship [20-23] whih is unerain, so, and embedded in work  praties and soial relationships [15]. Knowledge sharing in soware development an be dened as atvties eteen team membe n spreadng poet data/informatioagreement. As seen in Figre 1 knowledge sharing inludes ommuiation, updates, advie, problem solving, deision making, issue aising, disussion, et. over  pojet data/informatioagreement. Team Members Knowedge Sharing o Communication o Updates o Advice - 0 Problem solving -o Decision making o Issue raising o Discusson Team Members o ec. Figure I. Knowledge sharing deniion Kowledge sharing in software development situation enables team members to enhane their ompeteny and mutally generate new knowledge [15]. Knowledge sharing an be onsidered by nowledge omplexty and nowedge  transferability. The omplex knowledge and/or long nowledge  transfer hain suffer from information distoion and loss whih ould lead to ineient nowledge sharing. IV. ONCLUSION Tst is the most imporant issue to reate relationship making value in knowledge sharing. Knowledge itself annot lead to a suess, as nowledge sharing or ow of nowledge is of prime imporane in an organization. Kowedge sharing depends on trst between trsted and trstee members in spei knowledge ontext and spei time slot. Trst level  between members has a high impat on soware projet  performane. The futre work ould inlude deing a role and measurement of trst and knowledge sharing in the software  projet performane. A developed framework is required to measure embedded trst in teamwork. Additionally, the framework should be developed and measured the soware  projet performane in a dynami enviroment as knowledge and trst are dynami entities. FERENCES [I] Jorgensen, M. and K. Moloen-Osvold, How large are soware cos overruns? A review of he 1994 CHAOS repor, in Informaion and Soware Technology 48. 2006. p. 297-301. 654  4th IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2010) ©2010 IEEE [2] Gilb, T. No Cure No Pay: How to Contract for Soware Services. 2006 [cited accessed 24 May 2006]; Available from: Cure_No _Pay.pdf. [3] Inteational, S.G. CHAOS: Project failure and success repor. 1994 [cited; Available from:sample_researchchaos_1994_2.asp. [4] Rubenstein, D. Standish group repor: There's less development chaos today. SO Times [cited Mar. , 2007]; Available om:arice/story-20070301-01. [5] Cerpa, N. and J.M. Veer, Why Did Your Project Fail? Communications of the ACM, 2009. 52(12): p. 130-134. [6] Linberg, K.R., Soware developer perceptions about soware project failure: a case study. Joual of Systems and Soware, 1999.49(2-3): p. 177-192. [7] Chen, J.-C. and S.-J. Huang, An empirical analysis of the impact of soware development problem factors on soware maintainability. Joual of Systems and Soware, 2009.82(6): p. 981-992. [8] Yong, H., et al. A Neural Network Approach for Soware Risk Analysis. in Sixth IEEE Inteational Conference on Data Mining -Workshops (ICDMW'06). 2006. Hong Kong, China.: IEEE. [9] McCreery, J. and V. Moranta. Mapping Team Collaboration in Soware Development Projects. in Porland Inteational Conference on Management of Engineering and Technology (PICMET09). 2009. Porland, Oregon USA. [10] Moe, N.B. and D. mite, Understanding a lack of trust in Global Soware Teams: a multiple-case study. 2007, Springer-Verlag Berlin Heidelberg. [] Juan-Ru, W. and Y. Jin. Study on nowledge Sharing Behavior in Soware Development Team. in Fourh Inteational Conference on Wireless Communications, Networking and Mobile Computing (WiCom'08). 2008. Dalian, China. [12] Mayer, R.C., OJ. Davis, and F.D. Shoorman, An Integrative Model of Organizational Trst. Academy of Management Review, 1995. 20(3): p. 709-734. [13] Jarvenpaa, S.L., T.R. Shaw, and D.S. Staples, Toward contextualized theories of trst: The role of trst in global virual teams. Information Systems Research 2004. 15(3): p. 250-267. [14] Giddens, A., The Consequences of Modeity. 1990: Stanford University Press. [15] Melnik, G. and F. Maurer. Direct Verbal Communication as a Catalyst of Agile Knowledge Sharing. in Proceedings of the Agile Development Conference(ADC04). 2004. Salt Lake City, UT, USA. [16] Alavi, M. and D. Leidner, Knowledge Management Systems: Issues, Challenges, and Benets. Communications of the AIS, 1999. 1(7): p. 2-36. [17] Hansen, M. and M. Haas, Competing for Attention in Knowledge Markets: Electronic Document Dissemination in a Management Consulting Company. Administrative Science Quarerly, 2001. 46(1): p. 1-28. [18] Szulanski, G., The Process of Knowledge Transfer: A Diachronic Analysis of Stickiness. Organizational Behavior and Human Decision Processes, 2000, 82(1): p. 9-27. [19] Zack, M., Managing Codied knowledge. Sloan Management Review, 1999.40(4): p. 45-58. [20] Boland, R. and R. Tenkasi, Perspective Making and Perspective Taking in Communities of Knowing. Organization Science, 1995. 6(4): p. 350-372. [21] Brown, J. and P. Duguid, The Social Life of Information. 2000, Boston, MA: Harvard Business School Press. [22] Nidumolu, S., M. Subramani, and A. Aldrich, Situated Leaing and the Situated Knowledge Web. Joual of Management Information Systems, 2001. 18(1): p. 115-150. [23] Nonaka, I. and N. Konno, The Concept of Ba: Building a foundation for Knowledge Creation. Califoia Management Review, 1998. 40(3): p.40-55. 655
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks