Systems Development - Free Essay Example

Sample details Pages: 13 Words: 3930 Downloads: 10 Date added: 2017/06/26 Category Statistics Essay Did you like this example? Department of Information Systems Abstract Various factors influence the success of a Systems Development (SD) project. As a result, project teams must comprise of practitioners with various skills (Katzenbach Smith, 1993); and a certain ambience must exist for the groups to flourish. This paper sought to discover exactly what these factors are. Don’t waste time! Our writers will create an original "Systems Development" essay for you Create order Having previously completed an SD project, we compiled a list of factors that our group deemed as vital in guaranteeing our project success. We considered soft and technical skills; the project and its scope and requirements; as well as other stakeholders as some of the critical success factors (CSFs). We then conducted a study with IS students, who completed a survey, rating certain factors in order of importance. The results revealed that most students considered the given factors as important, with programming seen as most critical, and effective communication being rated second. We then looked to literature for academic opinion. The literature outlined that while most SD projects require technical skills, the teams also needed soft skills and a good blend of personalities to ensure success (Reel, 1999). Academic support and a clear scope were also considered important by students and academics. A flaw in the study was that it failed to acknowledge to what degree these factors are necessary, whether these are the only factors needed, and the intra-relationship between the factors. The results of the study can aid academics in deciding on the composition of future IS curricula. Introduction There seems to be no consensus in literature regarding what the Critical Success Factors of SD projects are (Wateridge, 1995). For instance, Belassi (1996) reported that team members commitment, their technical background, project attributes and environmental factors are viable and critical factors. On the other hand, Fortune White (2006) cited support from seniors, clear realistic objectives, detailed plans and good communication and feedback as the necessary factors; while a study by Ewusi-Mensah (1997), suggested clear project goals, good team composition, technical know-how and adequate technology as most critical for success. Evidently, many factors can be seen to contribute to the success of SD projects. However, there are countless lists all with varying ideas of what these factors are. Our studys aim is to find the right combination of factors, from the perspectives of UCT IS students. We then want to see whether existing literature is in support of, or against these factors . SD projects in particular, consist of many tasks which require various competencies. Completing an SD project entails everything from documenting the details of a system, to creating the actual system. In order to succeed, the project group must be composed of programmers, business analysts, project leaders, strong communicators, and essentially, a dedicated team (Scott, 2008). Good performance is dependent on the coordination of expertise within a team. (Faraj Sproull, 2000). Klein, Jiang Tesch (2002), recommend that teams be composed of people with complementary skills, who are committed to a common purpose. The key, they suggest, lies in matching people to tasks. This paper focuses on technical skills, with most emphasis on programming; soft skills, namely communication and good conflict resolution; project requirements and scope; as well as the role of stakeholders in ensuring project success. The aim is to highlight the most important of these factors and substantiate for them. The section following this introduction will deal with the research design. It will then be followed by a further discussion of the findings. The limitations of the study will also be stated and will be followed by the conclusion. Key words: Systems Development, Critical Success Factors, technical knowledge, interpersonal skills, project scope, resources Research design A mini survey of 3rd year students who are currently in their honours year was conducted in order to get a better understanding of what students felt were the most important factors for successful SD projects. The factors, as shown in table 1 below, were personality, skills set, the project and other stakeholders. These factors had sub factors (e.g. communication, conflict resolution and work ethic fell under personality; while staff, tutors and sponsor support all fell under other stakeholders). The survey asked students to rate the given sub-factors on a scale of 1 to 3, in order of importance, 1 being most important, and 3 signifying least importance. As seen in table 1, the blocks highlighted are the factors that got the highest ratings. For example, good communication skills were considered the most important trait for personalities within a team, and ability to program was regarded as the most important technical skill. Table 1. Results from 3rd year students mini-survey Personality Technical Skills set Project Other stakeholders Communication Skills 1s: 60% 2s: 40% 3s: 0% Programming skills 1s: 100% 2s: 0% 3s: 0% Adequate Resources 1s: 20% 2s: 50% 3s: 30% Tutors 1s: 30% 2s: 50% 3s: 20% Conflict resolution skills 1s: 40% 2s: 40% 3s: 20% Documentation skills 1s: 0% 2s: 70% 3s: 30% Clear Scope Requirements 1s: 70% 2s: 20% 3s: 10% Staff 1s: 40% 2s: 20% 3s: 40% Work ethic 1s: 0% 2s: 20% 3s: 80% Presentation skills 1s: 0% 2s: 30% 3s: 70% Work environment 1s: 10% 2s: 30% 3s: 60% sponsor 1s: 30% 2s: 30% 3s: 40% Key: 1: Very important 2: Somewhat important 3: Least important Highlighted: Received the highest rating (mostly 1s) Findings: Evaluating the Critical Success Factors Technical Skills: Programming During our SD project, we identified the ability to program, document and present the system as the most critical technical skills. However, programming proved to be most important. This could be attributable to the fact that we were not very strong programmers; and this is the skill we spent most of our time perfecting. On enlisting UCTs IS honours students to rate the same technical skills, i.e. programming, documenting and presenting in order of importance based on their past experiences, our survey results concluded that programming was also considered most important by other students. Several reasons can be given for this. Firstly, students differentiate courses by what modules predominate. In IS, the dominant modules all centre on programming. Secondly, since the programming of the system weighed more than the documentation and presentation, it is normal for programming to be deemed more significant than the other skills. In effect, the teams realized that if none of the member s within a group were competent in terms of programming, they were almost guaranteed failure, as programming constituted the bulk of the SD project. Several studies are in support of these findings. Reel (1999) suggests that because software development projects deal with complex problems, members must be intelligent and grasp programming easily. Literature advocates for strong abstraction and programming skills if one is to be a good systems developer, (White Leifer, 1986). Also, Scott (2008), supports that an IS professionals competence is reflected in the effectiveness with which analysis and design specifications can be translated into code. Soft skills: Communication It is not only technical skills that guarantee success. A balanced team is also important for SD projects. Reel (1999), defines a balanced team as one where all members can play a key role, where contribution is equal and there is mutual accountability. Our group found that communication serves as key for the formation of a balanced team. According to Noll Wilkins (2002), a good team is characterized by good communication. Gorgone et al., (2002), rank interpersonal, communication, and team skills as some of the main categories of exit characteristics of IS graduates (as cited in Miller Luse, 2004). Ultimately, team members need to be able to relay their opinions in order for there to be direction and progress in the project. Further, researchers are finding that ineffective communication skills have been a contributing factor to project failure (White Leifer, 1986). For example, a recent study found that while current technical skills, such as programming and documenting, that IS graduates possess are adequate for the market; interpersonal and personal trait skills, such as communication, and critical thinking skills, were amiss (Yen, Lee, Koh, 2001 as cited in Miller Luse, 2004). This supports the idea that while programming is needed and must be improved, the soft skills also need development. Our group found solid communication to be beneficial and this was supported by the IS students surveyed, as they rated good communication as the most important soft skill. Conflict Resolution According to Katzenbach Smith (1993), communication can only be beneficial if it represents a set of values that encourage listening and constructively responding to views of others and providing support while also managing conflict. It is no wonder that conflict resolution was rated a close second in our survey under personality. Also, a study by Clark (2002) found that 67 percent of respondents attributed project failure to poor communication and team conflicts. Interestingly, many studies that look into reasons for project failure ignore the group dynamics of the project team as a factor. This is a flaw, as most work within IS curricula is done in groups. It thus seems careless not to consider team incompatibility as a probable cause of failure. For instance, it would serve no purpose to place the best people within one group when they are at risk of personality clashes due to each of them wanting to outshine the other (Belassi, 1996). We can deduce from this that an ability to s olve conflicts is also necessary for SD project success. Also, the goals of the members need to be aligned. This can only be so if communication is solid and conflict is minimal. Daft (1994) found that when individuals worked together, as in SD projects, conflict ensued because members were not pursuing the same objectives (as cited in Miller Luse, 2004). Consequently, IS developers need effective communication and conflict resolution skills to be able to determine common goals and ascertain that a usable system is produced (Noll Wilkins, 2002, Levesque, Wilson Wholey, 2001). Project choice: scope and requirements Most of the 3rd year (now honours) project teams found that choosing a project with a manageable scope and well understood user requirements reduced the risk of failure quite substantially. This makes sense because of the limited time and resources that most teams had. They also found that they needed to appoint a team member who is good at communicating, in order to capture user requirements properly. If the user requirements were not fully understood, the teams had to go back to the users to get correct requirements. This often hampered the progress of the project. In a study by Procaccino, Verner Lorenzet (2006), the authors found that understanding user requirements was ranked as the most important driver of project success. According to Belassi (1996), most projects fail because teams dont pay particular attention to the size and the value of a project, the uniqueness of project activities (vs. standard activities), the density of a project network, the project life cycle and t he urgency of a project outcome. This is why it was important for the teams to choose a manageable project, with well understood requirements. Resources The availability of resources cannot be overemphasized. This relates to an enabling environment and up to date technology. This sentiment is shared by Reel (1999) as he emphasizes that teams need a working environment that will minimize distractions and encourage productivity. Moreover, teams need proper equipment. In the case of 3rd year teams, there were numerous complaints about the working environment in the commerce labs as well as the equipment i.e. lab computers. Most teams complained about the uncomfortable chairs; the extremely cold conditions during winter months, the inability to eat in the labs, even after being there for countless hours, as well as the computers which were often dysfunctional and ridden with viruses. Although these complaints seem trivial, they hampered the progress of most teams. This is perhaps why some teams chose to work at home instead of the commerce labs. From this, we can deduce that the need for comfortable working spaces is not to be underestim ated. According to May, Schwoerer, Reed, Potter (1997), human resource practitioners should fit workstations to their employees to avoid employee dissatisfaction and most importantly, any bad effects on employee wellbeing. Their studies found a moderate to strong link between productivity and office ergonomics. Looking at what most of the teams had to say about the working environment in the commerce labs, it is safe to say that the working environment can have negative impact on team productivity. Academic support Freemans (1986) stakeholder model emphasizes the need for managerial guidance. This strengthens the case for support from the sponsor as well as the project manager. In the case of 3rd year SD teams, the project manager has to oversee the projects and ensure that the final product fits the three requirements of: scope, time and budget (although budget is less significant for university teams since no money is involved in systems development projects). Joshi, Sarker Sarker (2007) concede that stakeholders, especially project managers, can be useful for knowledge transfer. Knowledge transfer can be for technical knowledge and project management knowledge. This was the case for most if not all 3rd year teams since they had to rely on lecturers who acted as project managers to impart knowledge. For instance, when teams were faced with technologies or methodologies they could not understand, they often consulted their project managers. Cumming Teng (2003) agree with Joshi et.al (2007), but go on further to suggest that project managers also have to encourage knowledge transfer among team members. This makes it easier for team members to trust each other and be open to criticism and feedback from team mates. It is interesting however, to note that in the study by Procaccino et.al, the importance of the project manager in terms of providing feedback was ranked twelfth out of fifteen drivers of project success. Project sponsor The project sponsor is one of the stakeholders for 3rd year project teams. The sponsors purpose is to approve a teams proposal and also provide user requirements. In other words, the sponsor is the client and the team is the service provider. If there is insufficient communication between the client and service provider, the project progress is slowed down or at worst, the project fails. Our team found it useful to get regular feedback from our sponsors to ensure that we were still adhering to the sponsors requirements. Since the sponsor is the user of the system, there is often a risk that the final product has incorrect functionality; it does not perform well and is unreliable (Boehm, 2007). Ropponen Lyytinen (2000) mention that, continuous and uncontrolled changes in requirements lead to changes in timetables and make it difficult to keep resource consumption steady. Some of the teams received complex requirements from the sponsors and had to negotiate for simpler user requiremen ts to ensure that the project was completed on time, given the limited resources that teams had. It is however interesting to note that while the sponsor may appear to be highly needed, the IS students surveyed ranked sponsors as least important to their project success. This could indicate a flaw in the SD teaching methodology, as one could argue that since the sponsor is representative of the client, he must be treated as most vital, since he will be using the system. Study limitations Though the study yielded useful results, its not without limitations. One such limitation was the structure of the survey. The survey made students rate answers from a list of pre-determined factors. These were factors we considered most necessary during our SD project. However, it is not guaranteed that other students would have primarily thought of these as CSFs for their project teams. Not all IS projects are similar. Therefore, the CSFs laid out in this text may not be universally applicable. For example, it is possible that even the right combination of people, adequate skills and enough resources may be affected by other factors e.g. environmental factors, which may lead to project failure. Therefore, projects must be treated uniquely (Miller Luse, 2004). For this reason, another survey could look into allowing students to give their own answers as opposed to picking from a list when completing a similar study. It is crucial that we not discredit the unlisted factors as comple tely unnecessary. Another limitation is the limited sample size of the survey. The survey was only exposed to 20 IS honours students, and only 10 responded timeously. Further studies could increase the sample to generate richer feedback. Finally, another flaw is that the study dealt with the factors in each category in isolation. This ignores the intra-relationships between the factors. However, the considered factors do not provide a full picture when looked at in isolation (Belassi, 1996). Usually, a domino effect ensues when one factor is not met, causing all the others to also fall behind. For example, since no one in our group was strong at coding. This led us to seek tutor help. When the help seemed inadequate, the results were conflicts between members, which led to an unconformable work environment, which led to an almost incomplete project. Thus, an interesting but challenging area of study would be the analysis of the effects of each factor on the others. Conclusion In conclusion, if teams are to produce projects of a high standard, they must fair well in terms of programming and documentation. They must understand what the systems exact requirements are, have the means to produce the system; and also have a cohesive team that strives for the same objectives. Moreover, teams must ensure that they have a clear understanding of the project scope and user requirements in order to mitigate risk, and sponsors should provide teams with adequate user requirements and be willing to evaluate the finished product. It is also important that a team has good balance of technical skills i.e. it would be risky to have a team composed solely of programmers or business analysts. Good communication is also essential as it can help in mitigating conflict due to misunderstandings, as well as in obtaining user requirements from the project sponsor. There is also a need for support from lecturers and sponsors. In essence, A good blend of the afore-mentioned factors w ill go a long way in ensuring project success. Reference list Belassi, W., Tukel, O. (1996). A new framework for determining critical success/failure factors in projects, International Journal of Project Management 14(3), 141-151. Retrieved Feb, 12, 2010, from: https://www.sciencedirect.com/science?_ob=ArticleURLHYPERLINK https://www.sciencedirect.com/science?_ob=ArticleURL_udi=B6V9V-3VW1S2D-3_user=635696_coverDate=06%2F30%2F1996_rdoc=1_fmt=high_orig=search_sort=d_docanchor=view=c_searchStrId=1216419529_rerunOrigin=google_acct=C000033878_version=1_urlVersion=0_userid=635696md5=840e66cbb5859197452edf0332037103HYPERLINK https://delivery.acm.org/10.1145/1140000/1138430/p39-bennedsen.pdf?key1=1138430key2=6166386621coll=GUIDEdl=GUIDECFID=77159483CFTOKEN=36971865CFTOKEN=36971865. Boehm, B. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1): 32-41.Retrieved Feb, 13, 2010, from: https://classes.cec.wustl.edu/~cse528/PrinciplesandPractices.pdf Cumming, J., Teng, B., (2003). Transferring R and D Knowledge: The Key Factors Affecting Knowledge Transfer Success, Journal of Engineering and Technology Management 20(2), 39-68. Retrieved Feb, 19, 2010., from: https://www.sciencedirect.com/science?_ob=ArticleURLHYPERLINK https://www.sciencedirect.com/science?_ob=ArticleURL_udi=B6VF3-48125D2-1_user=635696_coverDate=06%2F30%2F2003_rdoc=1_fmt=high_orig=search_sort=d_docanchor=view=c_acct=C000033878_version=1_urlVersion=0_userid=635696md5=b060412735136fff27ca80b1d66f15d3HYPERLINK Ewusi-Mensah, K. 1997. Critical Issues in abandoned I.S. Development Projects, COMMUNICATIONS OF THE ACM 40(9), 74-80. Faraj, S., Sproull, L. (2000). Coordinating Expertise in Software Development Teams Management Science 46(12), 1554-1568. Retrieved Feb, 12, 2010, from: https://mansci.journal.informs.orHYPERLINK https://mansci.journal.informs.org/cgi/reprint/46/12/1554g/cgi/reprint/46/12/1554. Fortune, J., White, D. (2006). Framing of project critical success factors by a formal system model, International Journal of Project Management 24, 53-65. Freeman, R. E. (1986). Strategic management: A stakeholder approach, Boston: Pitman Publishing. Joshi, K.D, Sarker, S. Sarker, S. (2007). Knowledge transfer within information systems development teams: Examining the role of knowledge source attributes, Decision Support Systems 43(2), 322-335. Retrieved Feb, 12, 2010, from: https://www.sciencedirect.com/science?_ob=ArtiHYPERLINK https://www.sciencedirect.com/science?_ob=ArticleURL_udi=B6V8S-4MFJT35-1_user=635696_coverDate=03%2F31%2F2007_rdoc=1_fmt=high_orig=search_sort=d_docanchor=view=c_acct=C000033878_version=1_urlVersion=0_userid=635696md5=64f64ee2e1e19251cb8367e9e31ebb05cleURLHYPERLINK Katzenbach J. R. Smith D.K. (1993). The discipline of teams, Harvard Business Review, best of HBR Retrieved Feb, 12, 2010, from: https://meridiancoaches.com/resources/Discipline_of_Teams.pdf. Klein, G., Jiang, J., Tesch, D. (2002). Wanted: project teams with a blend of I.S. professional orientations, Communications of the ACM 45(6), 81-87. https://delivery.acm.org/10.1145/510000/508452/p81-klein.pdf?key1=508452key2=0294386621coll=GUIDEdl=GUIDECFID=78915205CFTOKEN=89684535CFTOKEN=89684535. Levesque, L.L., Wilson, J.M., Wholey, D.R. (2001). Cognitive Development and Shared Mental Models in Software Development Project Teams, Journal of Organizational Behavior 22(2), Special Issue: Shared Cognition, 135-144. Retrieved Feb, 13, 2010, from: https://www.jstor.org/stable/3649587 . May, D.R., Schwoerer, C.E., Reed, K., Potter, P. (1997). Employee reactions to ergonomic job design: The moderating effects of health locus of control and self-efficacy. Journal of Occupational Health Psychology, 2, 11-24. Retrieved Feb, 22, 2010, from: https://web.ebscohost.com/ehost/pdf?vid=2HYPERLINK https://web.ebscohost.com/ehost/pdf?vid=2hid=6sid=ea49a0ff-c90d-456c-9796-d905578b24a2%40sessionmgr4HYPERLINK https://web.ebscohost.com/ehost/pdf?vid=2hid=6sid=ea49a0ff-c90d-456c-9796-d905578b24a2%40sessionmgr4hid=6HYPERLINK Miller, R.A., Luse, D.W, (2004), Advancing the IS Curricula: The Identification of Important Communication Skills Needed by IS Staff During Systems Development, Journal of Information Technology Education 3, 117-131. Noll, C., Wilkins, M. (2003). Critical Skills of IS Professionals: A Model for Curriculum Development, Journal of Information Technology Education 1(3), 143-154. Retrieved Feb, 16, 2010, from: https://202.198.141.77/upload/soft/0-article/+02/v1n3p143-154.pdf. Procaccino, J., Verner, J. Lorenzet, S. (2006). Defining and contributing to software development success, Communications of the ACM, 49 (8), 79-83.Retrieved Feb, 22, 2010, from: https://delivery.acm.org/10.1145/1150000/1145291/p79-procaccino.pdf?key1=1145291key2=1457257621coll=GUIDEdl=GUIDECFID=78293776CFTOKEN=12894723. Reel, J.S. (1999). Critical Success Factors in Software Projects, IEEE Software, 18-23. Retrieved Feb, 16, 2010, from: https://ece.arizona.edu/~ece473/readings/8-Critical%20Success%20Factors%20in%20Software.pdf. Ropponen, J., and Lyytinen, K. (2000). Components of Software Development Risk: How to Address Them? A Project Manager Survey, IEEE Transactions on Software Development 26(2), 98-112. Retrieved Feb, 17, 2010, from : https://www.de9.ime.eb.br/~tssouza/eng_soft/Artigos/Artigo.pdf Scott, E. C. (2008). From Requirements to Code: Issues and Learning in IS Students Systems Development, Proceedings of the 2007 Computer Science and IT Education conference, 650-660. https://www.sciencedirect.com/science?_ob=ArticleURL_udi=B6V9V-3Y44SG6-11_user=635696_coverDate=06%2F30%2F1995_rdoc=1_fmt=high_orig=search_sort=d_docanchor=view=c_searchStrId=1216465917_rerunOrigin=scholar.google_acct=C000033878_version=1_urlVersion=0_userid=635696md5=a28f47b6f363478c1bcf82a89f466a8dmd5=a28f47b6f363478c1bcf82a89f466a8d White B.K., Leifer, R. (1986). Information Systems Development Success: Perspectives from Project Team Participants, MIS Quarterly, 10(3), 215-223. Retrieved Feb, 18, 2010, from: https://www.jstor.org/stable/249HYPERLINK https://www.jstor.org/stable/249253253.