Software Project Scope Alignment: An Outcome- Based Approach - Research Paper Example

Software Project Scope Technological advancement is at boom in contemporary times, despite this fact the projects developed by companies fail, if considered on a wider scale, most of the projects developed fail partially, not because they do not succeed in meeting the outcome, but because they meet that specific outcome by alteration in the budget, planning, quality and time, these failures are attributed to causes which remain mysterious till today (May, 1998). Richard W. Woolridge, David P. Hale, Joanne E. Hale, and R. Shane Sharpe in their article ‘Software Project Scope Alignment: An Outcome- Based Approach’ effectively address this issue of project failure and offer a unique approach to solving this problem, this solution has never been proposed in its entire form prior to this research article, and therefore the solution presented is one of a kind. It focuses on solving the problem through categorizing the problem domain needs into essential branches and demarcating the scope of these branches singularly, and eventually culminating the entire process into one outcome (Woolridge et al., 2009). Throughout history many ways have been proposed to overcome this dilemma and extend the success rate of projects to such an extent that it becomes the norm of today, but the efforts have failed to execute into reality, and hence all endeavors are responsible for a minute amount of progress towards the goal but still there remains a long way to go to achieve the ultimate aim (Linberg, 1999). Effective scope definition is crucial to accurately approximate resource requirement, Outcome Based Scoping (OBS) approach aids in reducing project failure, despite the massive challenges proposed by the uncertainty and invariability in identification of major areas of project scope which might render the scope definition inconsistent as the project escalates from concept to construction (Lewis and Slack, 2003, 446). History is a witness to the massive amount of software project failures; this article proposes that OBS would effectively reduce the rate of failure, which stood at 18% in 2004, with 53% challenged projects, the reduction in this rate would be the result of the capability of the OBS approach to substantially recognize the conflicting objectives of the parties attached to the project, and this contradiction which can render a project as a failure remains hidden under the traditional method of project scoping (Woolridge et al., 2009, 151), which focuses specifically on the objectives of the sponsoring department and ignores the cross-functional aims, objectives, threats and opportunities which would inevitably affect, and mostly hamper the progress of the project (Woolridge et al., 2009, 149), as according to Damian and Chisan (Damien and Chisan, 2003, 10), the most significant component contributing to the progress if requirement engineering in project management was a result of a shift from ‘silo or single culture’ to ‘cross-functional department culture’, thus justifying the claim that the involvement of other departments in the project scoping immensely enhances the chances of progress; cross-functionality is the major underlying feature of the OBS approach. This approach would translate in project success because it essentially recognizes the growing importance of the clashing objectives of all departments related to a project and tends to indicate an optimal way out of the paradox, and thus present a logical and acceptable stance to define the project management, such as the Human Resource department which is considered as the sponsoring department in the subject article is responsible for identification of the correct set of people, polishing their skills through training, and determining a unanimously acceptable compensation for the employees, but the management of this department would not extend to defining the technological element of the project which would specify the software requirement necessary for the measurement of outcomes, furthermore if the HR department is considered in solitude, it would overlook the management perspective which aims at the identification of culture, teamwork opportunities, motivational packages and other employee related issues which would eventually affect the end result of the project, therefore it is important to consider other related departments, hence justifying that the approach of the subject author in stating that the Problem Domain Intent (PDI) should be scoped in a manner which includes the objectives of all parties, and the perspectives of each individual stakeholder should be highlighted in detail in the Problem Domain Blueprint (PDB), since these would affect the project in some way, even if at a small scale, and these show a potential of influencing the budget, deadline, resource requirement and eventually the outcome of the project (Woolridge et al., 2009, 149). The process of defining the project scope does not end with the identification of the key stakeholders and their perspectives, but extends further into establishing the Software Project Intent (SPI) which focuses on highlighting the software requirements of each department’s PDB outcome individually, in order to achieve the desired results by provision of a systemized description of the capability of the firm to provide the required software rather than just listing the artifacts (Woolridge et al., 2009, 150). It is necessary for a project to succeed that it must receive all the required resources, in form of finances, labor, machinery, technical expertise etc., if these resources are unavailable it would prove to be devastating for the outcome of the project, not only in terms of meeting the deadline, but also in the matter of quality, because the resources outlined initially without proper consideration of the availability are not compromised with regards to quality, and the project is planned accordingly, however when the firm is unable to supply these resources to create the software required by each stakeholder as outlined by the PDB, then it results in a transition to the resources which could be made available without compromising on time, this might result in a compromise on quality, which is detrimental for the success of the project, in terms of quality, efficiency, budget and capability. This sheds light on the fact that the correct and practical recognition of the availability of software and resources is necessary rather than merely stating what resources are required without considering whether the firm is capable of providing those or not. In the traditional method these minor details are ignored, hence resulting in the need to redefine the project scope because the requirement resources are unavailable, this later changes to the project plan hampers the progress of the project, translating into loss of quality and an inability to finish the project within the deadline. When project scope is altered due to the above mentioned reasons, it is referred to as ‘scope creep’ and Mathur (Mathur, 2007, 1) considers this transient scope as a fundamental cause of a failed project in terms of efficiency in meeting deadlines and finishing the project, when the scope of a project is altered during implementation phase it leads to chaotic circumstances, hence project failure rate would be reduced when the project scope would be finalized and remain essentially unaltered and should not be tampered with during the implementation phase, however if alteration is absolutely necessary, then it must be through a formal change process Mathur (Mathur, 2007, 1). The subject authors’ state through examples that the OBS approach succeeded in providing the managers with an appropriate way to identify the distinct and separated system scope elements and therefore assign them accordingly to the most capable manager by in order to achieve maximum efficiency. These elements were initially tangled together and made it difficult to place responsibility on the manager who had the greatest potential in solving a specific problem, OBS approach thus identified the opportunity that this model presented to the leaders of a firm such that a more complete software scope could be initiated, the authors proceed to state that it is essential that the leaders should be able to properly figure out the system scope elements, and identify the managers who would be best capable to function the processes related to the specified elements, if the matter is left into the hands of managers who are not fully equipped with the essential skills, knowledge and expertise, then it would result in ambiguity, which would require clarification every now and then, further extending the time consumption, and spelling disaster for the project as the deadline would not be met and the excessive communication would translate into increased resource requirement, thus OBS model is immensely significant in distinctly pointing out the requirements of relevant system scope elements (Woolridge et al., 2009, 151). Damien and Chisan (Damien and Chisan, 2003, 3) herein again support the subject authors’ stance that responsibility and understanding is an important factor, therefore the knowledge about the system elements is necessary to properly execute the vision into final product, it is necessary for the responsible manager to be aware of the system features, the method and the ways through which these function, the other elements related to these and their interdependencies, they should also be aware of the non-functional features of the elements of the system architecture which comes under the domain of their responsibility. The concerned manager must be equipped with the necessary skills to identify the behavior, performance and portability of the elements under his control, this would reduce the involvement of guesswork and rather base decisions on concrete and solid knowledge, this also reduces resource requirement as the ambiguities are lessened since the manager is the most knowledgeable person within the firm pertaining to the specific elements under him, the time consumed also reduces as excessive communication is removed from the process, this would result in timely completion of the project, less resource utilization, less ambiguity and greater outcome quality, thus substantiating the claim that the OBS model would significantly improve the success rate of projects. Another important feature of project management is defining the deadline and time-based controls for the project, and they support the OBS Model. The basic reason for which project scoping is undertaken by firms and project managers is to provide an outline to the firm leaders upon which the entire project is based, the most important feature which the leaders are concerned about is the time when the project would be completed, this could result in major conflicts within a firm if the deadline are not being met. If the project deadline is not likely to be wrapped up within the proposed deadline then it would mean major losses to the marketing department, which interacts with the customers, and hence it would lead to reputation loss for the firm. Furthermore, if the project does not end in time and the firm operates in a highly volatile market which is full of competitive rivals, then it might result in loss of the Unique Selling Point (USP) if the rival firms launch the project before the subject firm, in high investment industries this could even result in shutdown of a firm by making survival difficult. Therefore highlighting that specification of exact deadlines is very necessary since all departments are interrelated in a firm, and in a project, from conception to construction every department is a crucial brick of the entire organization, hence planning should materialize into completion or else when the individual losses of each department would be collaborated, it would result in massive losses to the firm overall. The most crucial risks associated with the success of a project are the resource utilization and the deadline meeting risks, which can lead a project to failure (Ropponen and Lyytinen, 2000, 102). The subject article clearly focuses on this factor, and notices that deadline is an important issue in project development and management, more importantly in the implementation part, the OBS approach is capable of prioritizing the defined deadlines, and relates them to specific outcomes, therefore clarifying in detail that which specific outcome should be met within what deadline and hence define the overall completion of the entire project in a specified time. Under the traditional model the system wide approach was not considered, and therefore it resulted in underestimation of the required deadline, in the OBS model, the project scope identifies every element involved in the project development and implementation process, and therefore leaves no room for ignorance of the factors which could affect the deadline, hence each stakeholder is provided with a specific boundary within which they must operate, such as 2 staff weeks time etc. (Woolridge et al., 2009, 150). As mentioned earlier, correct resource estimation is the most crucial element of the project management process, under the process of project scoping and the defining of the plan according to which a project would be developed and implemented, it must be clearly defined that what amount of resources are needed by the development team so that the exact amount of resources could be made available at the right time, any delays caused due to underestimation of orders and late orders for more supplies would affect the deadline of the project, which as mentioned earlier is a crucial component of the project development process. The OBS Model provides a defined platform to the project management team to create a project scope in detail and provide a specific deadline which is conducive to all the departments of the organization and is not unfair to a single stakeholder, hence balancing the justice within an organization (Woolridge et al., 2009, 151). Some authors disagree with the importance of project scoping to determine resource requirement, as according to Dumont (Dumont, 1997, 54-60) some contractors and businessmen widely disagree over the importance of project scoping for stating a resource requirement. These stakeholders argue that it is not feasible for a firm to devote its resources in defining such an element which is variable and would not remain fixed overtime, and therefore is bound to change due to economic conditions and the business environment in which the firm operates, they support the claim that it is useless in defining the scope in the initial stages of the product life cycle, especially as early as the planning stage. However, other authors such as Ginzberg (Ginzberg, 1981, 459) argue that there is a developmental process, and a firm must go through it in order to achieve the optimal result, and therefore states that it is necessary to have an estimate of resource requirement, especially in MIS implementation, because most of the project failures are caused by users who are misinformed and hold unrealistic ideas pertaining to the requirements of a project, and plan their steps according to these misguided conceptions, and since the defining stage in which the project scope is developed utilizes only 25% resources, therefore it is feasible to expend resources herein rather than losing 75% of the resources if the project fails due to wrong requirement estimation. Hence, as an OBS model can provide an opportunity to identify requirements, deadlines, system elements, managerial capabilities, and cross-functional responsibilities and objectives in the greatest detail possible, through the development of the PDI and PDB and then extending into the development the SPI and the software system elements, hence it is truly the best method which could be used by the project management team for developing Software Project Scope. References Damian. D and Chisan. J (2003) An Industrial Case Study of the Impact of Requirements Engineering on Downstream Development. International Symposium on Empirical Software Engineering, 40-49 Dumont(1997) Scope Management Using Project Definition Rating Index. Journal of Management in Engineering, 13, 5, 54-60 Ginzberg. M J (1981) Early Diagnosis of Mis-implementation Failure: Promising Results and Unanswered Questions. Management Science, 27, 4, 459 Lewis. M and Slack. N (2003) Operations Management: Critical Perspectives on Business and Management- 1st Edition. London. Routledge   Linberg. K R (1999) Software developer perceptions about software project failure: a case study. Journal of Systems and Software, 49, 2-3, 177-192 Lindkvist. L ; Soderlund. J and Tell. F (1998) Managing Product Development Projects: On the Significance of Fountains and Deadlines. Organization Studies, 19, 6, 931-951 Mathur. A (2007) Improve Project Success with Better Scope Management. PM World Today, 4, 8, 1-5 May, L.J. 1998. Major Causes of Software Project Failures. Retrieved June 29th 2010 http://www.tier1performance.com/content/features/mets_files/MajorCausesofSoftwareProjectFailures.pdf Accessed June 29th 2010 Janne Ropponen and Kalle Lyytinen (2000) Components of Software Development Risk: How to Address Them? A Project Manager Survey. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 26, 2, 98-112 Woolridge. R W; Hale. D P; Hale. J E, and Sharpe. R S (2009) Software project scope alignment: an outcome-based approach. Communications of the ACM, 52, 7s, 147-152 Read More