Project Failure and Runaway Projects - Assignment Example

Test Questions Test Questions Project failure The degree of failure in projects is quite subjective and arbitrary since the scope of project failure fluctuates from one project to another. For commercial software organizations, project failure is primarily linked to the needs of software consumers (Pressman, 2005). Project failure, therefore, means that the designed project does not conform to consumer demands or the software release did not occur as scheduled, typifying a deadline violation. In addition, a project can be deemed to have failed if it consists of a wide array of bugs. The causes of project failure include, among others, ineffective ways of either documenting or tracking development as a result of oversight by project managers (Schach, 2011). Project failures also emerge from poor project planning. Planning is essential to project success since it involves proper definitions of the constituents of project failure and success. Failure can also occur if the software is not feasible or its quality cannot be measured or estimated. Additionally, indifference to warning signs and poor risk management can also cause failure since sufficient remedial action will not be instituted to save the project from collapse (Oram & Wilson, 2010). Insufficient knowledge base can also cause project failure. Since the software engineering field is relatively young, it may be short of concrete and accumulative knowledge bases. Problems in software development The problems inherent in software development stem from an array of typical errors in the software development life cycle (SDLC) (Rodgers, 2003). In the initial stage, most projects follow the conventional software development lifecycle. Problems in the requirements gathering stage emerge if the project requirements are unclear or incomplete, producing difficulties when progressing to other stages of the lifecycle. Problems gathering requirements make it difficult to offer deliverables according to customer expectations since requirements are unclear. Another problem is cramming too much work in a short timeframe due to constraints such as inadequate budgets. Poor estimation and scheduling has a ripple impact on subsequent stages of SDLC (Hamill & Goseva-Popstojanova, 2009). Problems such as increasing the scope of features inherent in software can pave way for increased susceptibility to bugs. Mistakes in the initial stages can cause problems in subsequent software development stages (Hoffer, George & Valacich, 2005). Scheduling problems can reduce the amount of time apportioned for testing, re-testing and bug fixing, making it impossible to have bug-free software development. Another major problem in software development is inefficient communication and collaboration. Communication is the basis for collaboration in the development process. Inefficient communication erodes knowledge exchange and information distribution essential for achievement of project objectives (Schach, 2011). Runaway projects Runaway projects occur when projects fail due to one reason or another, often resulting in project termination. Some of the underlying causes of runaway projects include unrealistic business objectives, an ineffectively designed project scope and inadequate efforts made towards the realization of project benefits. In addition, runaway projects stem from the use of immature technologies, as well as the unavailability of appropriate and sufficient resources, needed for project completion (Deepak, 2003). Overall, runaway projects occur when ineffective project management practices were used during the development process. These causes show the diversity of the root causes of runaway projects. Project teams can avoid runaway projects by developing systems to detect early warnings. Control procedures that assess project viability can prevent the occurrence of events that result in runaway projects. Regular scheduling and the conduct of independent reviews can also enhance project quality and deter runaway projects. Furthermore, concentrating on the quality of decisions instead of that of the result can also deter runaway projects. Evaluations should not solely focus results, but the project process, as well. Runaway projects can also be deterred by appreciating the purpose of exit champions capable of offering alternative views contingent on the same data, ultimately saving on costs (Madhavji, Fernandez-Ramil & Perry, 2006). Software quality Software quality involves two interrelated yet different concepts. Firstly, software functional quality implies the software’s degree of compliance with set designs in functional specifications. Secondly, structural quality of software concerns the way it fulfills non-functional requirements, which facilitate the achievement of functional requirements, for instance, maintainability and strength. Structural quality is measured by assessing the inner structure of the software and its source code and technology and system levels (Spinellis, 2006). Quite the opposite, the measurement and enforcement of functional quality takes place through software testing. Quality measurement typically quantifies the degree to which software rates on five primary dimensions, including, security, maintainability, size, efficiency and reliability. Quality is ultimately enforced by computing the aggregate measure of quality through a quantitative or qualitative scheme before weighing up the system in order to reflect the software’s priorities. This implies the use of a quantitative or qualitative scheme or both to allow for the measurement of desirable characteristics, which are then assessed through a set of measurable traits (Schach, 2011). Enforcement also involves a supplementary analysis of programming mistakes, which are capable of causing performance degradations or deleterious outages that make software unusable (Ho-Won, Seung-Gweon & Chang-Sin, 2004). Process control Process control refers to an engineering discipline that encompasses appropriate mechanisms, algorithms and architectures used to maintain the productivity of an individual process within a preferred range and scope. Process control is essential since it facilitates automaton, thereby enabling few individuals to operate complex processes from single and central control rooms (Garmus & Herron, 2001). As a consequence, effective process control encompasses diverse forms, which include; continuous control where physical systems are exemplified by variables, which are both smooth and unremitting. Typical discrete manufacturing encompasses the manufacture of discrete product pieces, for instance, metal stamping. The last form of process control is batch, applicable where applications demand the incorporation and combination of concise amounts of raw materials in a definite way for a certain amount of time in order to create a desired outcome (Schach, 2011). This process control is particularly useful in the preparation of software used for the manufacture of adhesives and glues since they demand the combination of pre-determined quantities of raw materials in heated vessels. Applications with components of batch, discrete and continuous process control can be defined as hybrid applications. Project plans Project plans are essential in the software development process since they ensure that projects meet customer requirements. Project plans encompass flow diagrams, which show and explain the different processes that will go into producing the desired outcome. The planning process also encompasses a number of processes, which involve management of requirements, determination of software size, estimation of both schedule and cost, the process of formal inspection, management of software configuration and project tracking and oversight. Project plans are a significant step towards the achievement of project repeatability (Hoffer, George & Valacich, 2005). This means it is essential to develop a written project plan in the initial stages of the software project. Project plans are crucial determining forces for the achievement of software projects. Poor project planning often causes project failure, especially with regard to the achievement of schedule, cost and performance objectives. Therefore, the quality of a project centers on the establishment of a quality project plan. Therefore, project plans must be precise, concise and thorough in order to fulfill all project requirements. Project managers are tasked with the development of project plans and negotiating commitments in order to allow for effective project completion (Grisham, Krasner & Perry, 2006). In order to create an effective project plan, sufficient documentation from the sponsor or customer is needed so as to offer the customer insight into the stages involved in software development. Tools for analysis and design Analysis and design is accomplished through the use of computer-aided software engineering (CASE) tools. These tools are engineered for structured analysis, programming and design. Tools such as JSP Workbench and Cradle are essential implementations of both Jackson and Yourdon methods, which are used for structured design, and analysis. These analysis and design tools are essential since they automatically test for inconsistencies, incorrectness and incompleteness in project specifications (Madhavji, Fernandez-Ramil & Perry, 2006). These tools encompass software used in all phases of software development. For instance, diagramming tools, as well as data dictionaries, facilitate analysis and design while tools such as application generators enhance the programming stage. CASE tools are essential since they provide automated ways of documenting conventional techniques involved the analyzing and designing processes. The ultimate objective of CASE is to create a language used in the description of overall efficiency in design and analysis. UpperCASE tools concentrate on software analysis and design while I CASE tools, which combine both, lower and upper CASE, facilitate the design a database form and build by creating an automated environment for system development (Hoffer, George & Valacich, 2005). Communications in system development Quality communication is vital in all processes, specifically in system development, which requires coordination. Good communication is vital since it develops and sustains strong business relations, allowing for improved coordination and idea sharing among system developers (Schach, 2011). Despite the conceptual model employed in system development, quality communication remains a vital element since it dictates project success. System developers should be able to ask proper questions and gain the correct response (Kan, 2002). However, customers are occasionally conscious of the system development issue, but are unable of relating it to enable system designers appreciate their requirements. This means that system developers must be aware of effective ways of structuring communications in order to acquire sufficient and concise information on customers’ system needs. Effective communication calls for the use of appropriate communication styles in different situations. Typical communication styles include blind, closed, open and hidden styles. Knowledge of these styles enables system developers to tailor their output for optimal impact. Therefore, good communication allows for the development of effective systems capable of meeting customer needs. Furthermore, good communication in system development deters redundancy by preventing work multiplication (Perry, 2009). This ultimately results in reduced development costs and time while increasing the quality of the systems developed. Development life cycle phases The system development life cycle represents the process of developing or modifying information systems, as well as the methods and models developers utilize. The phases inherent in the development life cycle include; system investigation, which deals with focusing on opportunities and needs required of a sponsor. This phase involves considering the management of present priorities by performing a feasibility study. The next phase is system analysis, which aims at ascertaining the root of the problem to help fix the system (Che & Perry, 2012). This involves splitting the system into distinct segments, analyzing the situation and objects and breaking down what requires creation before identifying concrete requirements. The design phase involves providing detailed descriptions of design operations and functions and gaining approval for system requirements. The next phase encompasses testing the developed code through diverse levels of software testing, for instance, system, user and unit acceptance testing. The operations and maintenance phase involves the deployment of the created system by making necessary modifications and improvements before releasing it. The last phase of the system development life cycle involves the measurement of the application’s effectiveness in order to determine potential modifications to ensure conformity with the sponsor’s needs (Oram & Wilson, 2010). References Che, M., & Perry, D. E. (2012). Managing architectural design decision documentation and evolution. Journal of Computers, 6(2), 137-148. Deepak, S. (2003). To be, or not to be: The question of runaway projects. Information Systems Control Journal, 5. Garmus, D., & Herron, D (2001), Function point analysis. Boston: Addison Wesley. Grisham, P. S., Krasner, H., & Perry, D. E. (2006). Data engineering education with real-world projects. SIGCSE Bulletin, 38(2), pp 64-69. Hamill, M., & Goseva-Popstojanova, K. (2009). Common faults in software fault and failure data. IEEE Transactions of Software Engineering, 35(4), 484–496. Hoffer, J. A., George, J. F., & Valacich, J. S. (2005). Modern systems analysis and design (4th ed.). New Jersey: Prentice Hall. Ho-Won, J., Seung-Gweon, K., & Chang-Sin, C. (2004). Measuring software product quality: A survey of ISO/IEC 9126. IEEE Software, 21(5), 10–13. Kan, S. H. (2002). Metrics and models in software quality engineering (2nd ed.). Boston: Addison-Wesley. Madhavji, N. H., Fernandez-Ramil, J., & Perry, D. E. (2006). Software evolution and feedback: Theory and practice. West Sussex: John Wiley & Sons. Oram, A., & Wilson, G. (2010). Making software. California: O.Reilly Media. Perry, D. E. (2009). Future of mining software repositories: A roundtable: Evaluate analysis and testing approaches. IEEE Software, 26(1), 67-70. Pressman, S. (2005). Software engineering: A practitioners approach (6th ed.). New York: McGraw-Hill Education. Rodgers, I. (2003). Why Bad Projects Are So Hard to Kill. Harvard Business Review, February. Schach, S. R. (2011). Object-oriented and classical software engineering (8th ed.). New York: McGraw-Hill. Spinellis, D. (2006). Code quality. Boston: Addison Wesley. Read More