Software development and the value of stakeholder participation. feasibility study

DQ1: Stakeholders As the implies, in the software arena, a stakeholder is anybody who has a proprietary interest in the use or development of the software. Sometimes those stakeholders know what they want the program to do but may or may not be able to articulate what they want. There is even a career field to determine what the people in an organization actually want from their computer and its various programs, the systems analyst. This person makes a survey on the needs and wants of the executives and staff; from there he designs a system to suit their needs. But often, no matter how careful the planning, some of the stakeholders get left out of the loop, especially those in key positions. It seems redundant to say but everybody involved needs to be treated with respect and their concerns or questions must be treated like they matter. Sometimes the software engineer develops a sort of tunnel vision and gets caught up in the needs of the end user, while still trying focus on the needs of the organization. This could cause higher costs for both the company and the software maker as sometimes the software must be rewritten. In 2009 and 2010, Scott Ambler and Associates (2012) did a survey among key stakeholders concerning the agile modeling concept of software development and the value of stakeholder participation. They found that 71% of developers of programs that worked felt it was important to identify the goals of stakeholders. Almost three quarters also said regular discussions with them (the stakeholders) were important. After the Ambler team finished the survey, they came up with a set of nine “ Rights and Responsibilities”, one of which was “ to produce and receive quality work at all times based on agreed to project standards and principles”. This writer has not had any personal experiences with key stakeholders being left out. However, Robin Dudash in her white paper (2012) reiterates the above statements and starts out with a sample scenario whereby the project team spends almost a year working on new software for the sales people, even developing elaborate training seminars for the sales people. Yet from day one the sales staff complains about the confusing software. Ms Dudash says the moral of the story is the project manager “ is also responsible for managing stakeholder expectations” DQ2 Feasibility Study As far back as the 1990’s, McConnell (1998) spoke about the importance of the feasibility study. In his article, he pointed out that thirty per cent of software projects fail or are cancelled prematurely. That in of itself is not necessarily a bad thing, needs change, policies are different, and sometimes the executive simply changes his mind. McConnell gives the first twenty per cent as a measure of success. Anything after that entails a poor feasibility study. First of all it is imperative that the software team gets the full commitment of the executive in charge, along with publishing a clear and concise vision statement. In it there should be a definite timeline and what should happen if there should be any delays. Are there any risks? If so the vision statement should specify what actions will be taken to minimize those risks. The feasibility study should also answer one major question that managers normally have. Is this software process even necessary? Does current technology allow it to be accomplished? A good study beforehand might not halt a project’s cancellation, but the software team will be confident that good prior planning was producing a quality product. Research suggests that things haven’t changed much in the fourteen years since the above study. Not only does Ambysoft (2012) advocate the same advice as above, they further the technology available question by suggesting that sometimes doing nothing is the best alternative. Also would it be possible to integrate a commercial software already available? But there are two other areas they also bring up that are no less important. Indeed, a lot of executives believe them to be most important. First is the political line that the software project manager must balance. Going into a project meeting with the “ it’s needed because we IT people says it is” is probably the easiest way to see a project doomed to failure. The other is no doubt the reason most projects are cancelled, money. The manager should be able to answer two questions beforehand. What is the total cost for this project? What are the long run savings and cost benefits for this software? Also, since personnel costs are a business’ major expense, the executives will inquire as to whether the new software will require more or less people. . References: Ambler, Scott and Associates, 2012, Agile Stakeholder Participation: An Agile Best Practice, viewed November 8, 2012, < http://www. agilemodeling. com/essays/activeStakeholderParticipation. htm> Ambysoft, 2012, Justifying a Software Development Project, viewed November 8, 2012, < http://www. ambysoft. com/essays/projectJustification. html#EconomicFeasibility> Dudash, Robin, 2012, Software Stakeholder Management: It‘ s not all it’s coded up to be, viewed November 8, 2012, McConnell, Steve, 1998, Feasibility Studies, viewed November 8, 2012, < http://www. stevemcconnell. com/ieeesoftware/bp15. htm>