Information Systems in Project Management Reassessment - Assignment Example

Information Systems in Project Management Reassessment 1. Introduction To be considered successful, a project would need to meet the business requirements, be delivered and maintained within schedule, be delivered and maintained within budget and be able to deliver the anticipated return on investment and business value (Kezner & Learning, 2013). From a vast number of surveys, there is evidence that IT based projects have experienced failures in the past. This calls for a need to exercise proper software project management practices. Software project management entails the application of skills together with knowledge in successful planning, management and completion of a software project. A number of organizations involved in the development of software products have still not resorted to the use of sets of vital signs in monitoring the status of different projects that they undertake. Similarly, other organizations never even use properly documented processes to discover half-banked project concepts at the early stages of a development process and others are not even in a position to discern or rule out a troubled project in a timely fashion. In addition, some organizations are fond of neglecting or treating with a little regard the need to train the targeted clients on the benefits attributed to successful projects along with the crucial success factors that surround the development processes. Some of the factors that often contribute to failure are issues like incomplete or vaguely stated business requirements and specifications, insufficient or lacking executive support, changing business specifications, insufficient planning, technological incompetence and insufficient resources among others. On the other hand, success factors for different projects include but not limited to realistic schedules and estimates, clearly defined project goals, prior specification of the quality criteria of the anticipated deliverable, active support from top management, team competence, and proactive issue resolution together with the project manager’s level of competence. In the context of project management, a critical success factor is an important influence which can determine the success of a project (Kezner & Learning, 2013). Thus, critical success factors refer to the series of conditions, influences or factors that contribute towards the outcome of a project. Examples of success factors regarding software projects include open communication, careful risk management, proper planning, and properly defined scope together with selection of a competent staff. 2. Team Selection Team effectiveness is crucial in the software development teams. The team roles defined by Belbin show the possibilities of staying committed, interested or participative in a team that is involved in the execution of a software project. Thus, project managers who adopt the model while selecting the participants of a project stand higher chances of witnessing an improved performance from the involved team. 2.1 Belbin’s Model Belbin’s model has, to a great extent, influenced the project management practices. In his book Management teams: Why They Succeed or Fail in 1981, Meredith Belbin explains behaviors from the aspect of the interaction that takes place between team roles that members of an involved team represent. He stated 9 roles under three broad categories: action oriented roles, people oriented roles and thought oriented roles. Action based roles include completer-finishers, shapers and implementers. Team based roles constitutes the coordinators, team workers and resource investigators. Thought related roles include the monitor-evaluator, planter and the specialists. The described model offers explanations regarding the reasons for failure of talented and high skilled though imbalanced teams. Developers would for instance be happier sitting in a closed room and coding for a whole day and cannot do much if made to assume the role of a shaper. Application of Belbin’s theory is known to improve the performance level of an involved team. Whereas the improvement can appeal to the project manager, reshuffling the project staff members might introduce another fashion of imbalance in view of other issues like personal attitude or interest, domain knowledge and level of skills. Nevertheless, Belbin’s team roles remain to be a useful way of thinking about a team structure as well as tools that could be adopted at some stage during the execution of the project. The 9 Belbin Team Roles helps to represent the manner of interaction or behavior that team members would prefer while inside a given group (Walker, 2011). In this software project, there will be individuals who will feel more relaxed as they work behind the scenes while others will prefer continual interaction with the targeted clients for the software product under construction. In the same team will be fellows who prefer decisions while others will just like ideas. The bottom line is that a top-performing team is built on striking a balance of nine primary roles and every time member is to carry out a task that reflects his or her inherent strengths and unique characteristics. The implication of team members who bear similar manner of behavior on a software project is twofold. In the event that every team members has the same weakness as the other colleagues, the entire team could be headed to failure. On the hand, if the team members have a similar level of strength, a competition-filled spirit is likely to arise. Team members could be tempted to focus more on opportunities that can allow them display their level of proficiency- a move that might result into delivery of a software product that fails to meet the predefined business needs. In view of this, Meredith Belbin’s model finds a place in the process of selection of team members. Such a move helps in ensuring that roles that are crucial to the success of the software project are accomplished and that the behavioral weaknesses or tensions likely to arise during the execution of the project are avoided. 2.2 Belbin’s Role in the Context of the Project 2.2.1 Implementers The implementation role will strike on the developer given that the developers are to keep in touch with the code, translating the project idea into a software product. 2.2.2 Co-coordinator Looks more of a managerial position and should be assumed by a person who can make sure that every deadline is met by the appropriate team members (Utley, 2011). A single senior developer and a single senior programmer can serve in this position. The senior developer will keep ensure that the other developers design, modify or develop specifications and avail them in time for the programmers. The senior programmer will ensure that the other programmers write then implement coding as per the specifications issued by the developers and within the predefined time. It is difficult finding a senior developer permit non-developers to perform developer-related roles. Neither is easy for a senior programmer permit non-programmers to engage in programming. This has the implication that the team will be sure of the predefined deadlines being meet by the right people. 2.2.3 Completer or finisher Finishers should have detailed knowledge of the work carried out by the specialist in order to succeed in scrutiny. In case a developer is a perfectionist, he is likely to be an expert in his field. He will therefore be fit for being a specialist. This has the implication that two developers selected for this project will perform roles that are inclusive of that of an IT specialist. In addition, introduction of a third party to scrutinize the work done by the developers does not make much sense. This position is best assumed by any developer who is greatly experienced in the development of projects that bear some similarity to the project under execution. The person’s knowledge about things like the appropriate test approaches and common bugs associated with the application makes him or her ideal for appointment to this position. 2.2.4 Monitor/ Evaluator This person can never get too absorbed into the project under execution mainly because they are aimed at making objective observation. With regard to this project, it is the business analyst who remains fit for such a quasi-supernumerary role. A single business analyst will do. The team roles that are detailed by Meredith Belbin are applied in increasing the efficiency of the different development teams. Belbin’s self-perception and Belbin’s theories can be employed in recognizing useful positive and negative features of a team. Therefore, positive characteristics could be supported while the negative features can be suppressed. With the move that is headed to software development processes that are based on iterative and Agile methods, like extreme programming, where flexible and rapid response to changes is mandatory, the role entrenchment that Belbin proposes appears to be a little bit difficult to use. Cross functional teams are instrumental in these light weight approaches and a dynamic approach replaces the delegation of concrete roles particularly where no determinants to the hierarchies already in place can influence the manner of operation of the team. 2.2.5 A plant could be an implementer Developers often prefer implementing their own concepts and ideas rather than attempting to comprehend an idea that somebody else brings up. Thus, letting the plant introduce ideas and concepts then have no additional input appears as a waste of resources. Again, the development process is naturally creative, meaning the implementer must possess given creative experience to be capable of overcoming challenges that arise during the implementation stage. The reverse of this does not have to be true given that implementers may not exhibit the creative drive featured in plants. 2.3 Gantt Chart Other than its roles to allow members of the involved team to have their thoughts organized and acting a proof of a team that is informed about its course of action, the chat will allow the team to set targets that are realistic (Puntambekar, 2010). This is attained through the bars featuring in the chart. The bars suggest the time period during which a particular task or a series of tasks is bound for completion. 2.4 Network diagram The corresponding network diagram is as shown here below 3. Possible Project Problems 3.1 Incorrect Definition of Project Scope Project scope is one of the project management crucial success factors for the reason that it does lay the foundation for final success in a project. The term refers to defining the client, deliverables, financial and human resources, work packages and outcomes pertaining to a project (Stellman & Greene, 2006). Any inadequately defined project that fails to have a suitable link with an organization’s strategy increases the chances of a project failure. Besides, insufficient project scope is bound to haunt the project in question all through its life cycle. Therefore, there is need to allocate sufficient time for the phase involving project scope definition. 3.2 Unattended Budget In every project, Alliance software project inclusive, overruns are likely and can bring a whole project down if not identified then corrected in time. Therefore, it would be recommended that the budget of the Alliance software project be managed on a weekly basis separate from the long term budget (Wysocki, 2013). This measure can help evade a situation whereby the budget for a project gets so much out of control that any corrective or proactive action proves hard to realize. 3.3 Poor risk management It is a common practice for team members to give a minimal emphasis to risks related to the software projects. Treating risks with a little regard can be a great project killer. It is thus recommended that every possible risk is identified at the start of the project then plans for avoidance and mitigation of the same be put in place (Chemutur & Cagley, 2010). All these factors narrow down to the need for a risk management plan in a software project. 3.4 Lack of Proper Plan A comprehensive project planning is able to set a project for success just from the beginning. The planning process would require that every stakeholder be on board which each of them knowing the direction that the project is to take. Planning lets a team look organized and meet the predetermined deadlines. Besides, good planning can help stakeholders in staying informed about the project progress. This initial phase of project process permits for creation of realistic and reliable time scale (Phillips & Luckey, 2013). Providing an assurance regarding precise times for the cost estimates that are to be produced or for clearer deliverable and milestone documentation simplifies the progress of the project. Proficient plans will always detail every resource requirements while doubling as warning systems. In case it is the task slippage at risk, a warning system follows providing an appropriate visibility of what to anticipate. 4. Development Approaches A software development process includes tasks such as requirement elicitation, system analysis and design, development, implementation and maintenance. In view of the fact that every project will have a set of requirements that are unique to it, there arises a need to identify a software development life cycle (SDLC) based on the needs that are particular to the project in question. 4.1 Recommended Development Approach For this software project, the evolutionary prototyping model will be appropriate. In this approach, a prototype will be made first then a final product will be developed based on the prototype. The prototype will act a sample test as far as the development process is concerned. From the sample, then developers will learn attempt building a higher quality product. This system development method will be appropriate for this software project for the reason that the concept of introduction of the new software application is something that has never been tried earlier on in Alliance as a company and encompasses several risks. In addition, it will be challenging obtaining exact system requirements considering that this will be a new idea. In the method, a completely constructed sample model is demonstrated to the targeted user then the business specifications document is drafted based on user feedback (Bailey & Martin, 2010). Following the completion of this, a better business specifications document is prepared then the development task can commence through a new model such as the waterfall model. The particular reasons why the prototyping method would be appropriate for meeting the business needs of the employees of Alliance Company are: First, in showing the prototype to the targeted user, the later acquires a feel and an insight of the functionalities that will be supported in the expected software product. Second, the set of employees of Alliance Company certainly constitutes non-IT-literate fellows who are less likely to be capable of stating their requirements. Neither are they in a position to tell with preciseness their expectations concerning the anticipated software product. Third, the clients, in this case the employees, are not very confident about the abilities of the developers as far as this software project is concerned. A request for a prototype will therefore provide the clients with an avenue to judge the ability of the developers who are to form part of the participating team. Finally, the prototyping model is fit in case of a need to display the concept to the prospective investors so as to obtain funding for the software project. In the same way, the prototype required in this project is expected to help the stakeholders to validate the broader project objectives. 4.2 Disregarded Development Approaches 4.2.1 Waterfall Model The assumption of making the specifications frozen as it happens in the waterfall model makes this method to be inappropriate for this new project. It does not making sense trying a new idea then using a development approach that is less permissive of the involved team getting back to a previous stage (Agarwal, Tayal & Gupta, 2010). In addition, it would not make sense for the company to adopt the waterfall model – which is expensive in terms of cost and the need for the detailed plan- yet it is not sure about the feasibility of the project being undertaken. 4.2.2 Agile Development Though it is possible using agile development for any category of project, the approach requires more engagement from the client and a high level of interaction (Stober & Hansmann 2010). This has the implication that the targeted users should be in a position to state the actual business specifications. How would we expect that to happen in a new adventure? How can end user state actual requirements when their routinely production processes have never been oriented to information technology earlier on? Besides, the method is fit in situations whereby the customer requires given functional requirements implemented in less than 3-weeks period. Unfortunately, that will not be the case in this software project given that it is the response of the targeted users to the software prototype that will be used in drafting the business specification document. 5.0 Conclusion Poor project management is known to affect organizations culturally, strategically and economically though they may also jeopardize the relationship with the clients, introduce cost-based overruns and reduce the morale of the involved team. Despite the common place knowledge about the usefulness of proper project management practices during software construction, limited knowledge still exists regarding the best possible way to evade the effects of project issues and problems on the delivery time, quality and budget that pertain to software projects that are undertaken by different teams. Bibliography AGARWAL, B. B., TAYAL, S. P., & GUPTA, M. (2010). Software engineering & testing: an introduction. Sudbury, Mass, Jones and Bartlett. BAILEY, B., & MARTIN, G. (2010). ESL models and their application: electronic system level design and verification in practice. New York, Springer. CHEMUTURI, M., & CAGLEY, T. M. (2010). Mastering software project management: best practices, tools and techniques. Ft. Lauderdale, FL, J. Ross Pub. KERZNER, H. R., & LEARNING, I. I. F. (2013). Project management - best practices achieving global excellence. Hoboken, N.J., Wiley. PHILLIPS, J., & LUCKEY, T. (2013). Software project management for dummies. Hoboken, N.J., John Wiley & Sons. PUNTAMBEKAR, A. A. (2010). Software engineering and quality assurance. Pune, India, Technical Publications. STELLMAN, A., & GREENE, J. (2006). Applied software project management. Beijing, O'Reilly. STOBER, T., & HANSMANN, U. (2010). Agile software development best practices for large software development projects. Berlin, Springer. UTLEY, R. A. (2011). Theory and research for academic nurse educators: application to practice. Sudbury, Mass, Jones and Bartlett Publishers. WALKER, A. (2011). Organizational behaviour in construction. Chichester, West Sussex, UK, Wiley-Blackwell. WYSOCKI, R. K. (2013). Effective software project management. Hoboken, N.J., Wiley. Read More