Managing Software Development Projects

Transcription

1 Managing Software Development Projects Technical Writing (English 4010) University of Wyoming Laramie, Wyoming By Dan Randolph Graduate Student in Computer Science May 09, 2001

2 CONTENTS page Abstract iii Background Problem Supporting Evidence Problems with Estimating Time and Cost Importance of the Software Requirements Specification Project Management Pitfalls Software Design and Customer Loyalty... 5 Risk Management Table Conclusions and Recommendation Works Cited ii

3 Abstract This report proposes the idea that omitting important steps in the software development process can lead to projects falling behind schedule and being canceled. The report goes on to analyze how leaving out certain steps will lead to a failed project. It covers the potential problems known as risks that can delay projects and cause products to be produced that software users dislike. The main elements of a software project that this report covers are the importance of software requirements specifications, project management, and how good design leads to customer loyalty. One of the most important tasks a project manager can do is implement a risk management system that is team oriented. Managing risks can help increase the quality of a software product and help control a process that can tend to fall behind schedule due to unforeseen problems. iii

4 Background Steve Adolph, an expert UNIX software developer, writes about his own experience as a team s technical leader on a project to replace a companies old software with software that would be easier to maintain (2). This product was a mobile dispatching system used by taxi companies, police and fire departments and utilities (Adolph 2). Adolph writes that even though the system was in fact very simple, the project ran into trouble and was canceled after six people had worked on it for over a year (4-8). Projects fall far behind schedule when important steps in the software development process are omitted, and many of them end up being canceled. To build a house, a contractor follows a set of procedures to prepare for construction. Floor plans are drawn, bids are requested from subcontractors, and the customers are consulted about the best way to design the house to meet their needs. Qualified people are hired who have the right equipment and tools to do the work. Similarly, the process of software development needs to adhere to certain procedures in order to create a successful product. These procedures include basic factors such as feasibility studies, analyzing requirements, design, implementation, testing, and maintenance. Marketing is also a very important factor to consider. Even a very good development effort will run into trouble if not enough sales can be generated. The sales force can become involved in the development process when they communicate a prospective customer s needs to the development team. Providing solutions and features that customers want is a good way to increase the chance that others will want the product and find it useful. Giving customers what they want is also a good way to insure continued customer loyalty. 1

5 Problem There is a certain amount of risk involved with each phase of the software development process. The biggest risk is leaving steps out of the process. This can spell the difference between the success and failure of a project. Another risk involves the level of commitment to product marketing. I have seen software products canceled at nearly the same time they were released due to lack of commitment by the marketing department. A sure way to loose talented developers is to have them spend months or years building a product that is never used by anyone. Supporting Evidence Problems with Estimating Time and Cost Adolph, in his article, writes about a number of mistakes that were made in the development process for his project (2-9). The first mistake was the team s cavalier approach to schedule estimation (Adolph 4). The team had estimat ed that it would take 18 months to do the project, and it could be done with two designers and four developers working full time (Adolph 3). This estimate proved to be far too short. After 12 months, only 30% of the project had been completed, even though 70% of the project s time and resources had been used up (Adolph 8). It is tempting for developers to underestimate the time it will take to complete a project. Either the developer is overly optimistic about his time estimates, or they suspect that the project will not be approved if the actual costs of the project are revealed to management. But underestimating time requirements on a big project is one thing that an experienced software developer will not usually repeat. I would rather have the personal satisfaction of getting a project done on time and on budget than experience the pressure of being behind on a project. 2

6 One way to improve time estimates is to keep records of how long it takes to do various tasks. This way, new tasks can be measured against how long it took to perform a similar item in the past. Importance of the Software Requirements Specification The second mistake Adolph s team made was skipping the software requirements specification (SRS) that should have been done as part of the requirements analysis process (4). Adolph had recommended the creation of an SRS, but the project manager rejected the idea (4). He felt it was unnecessary because the company had expertise in the field (4). The manager thought that staying on schedule was the greatest risk, and activities deemed unnecessary needed to be pruned from the schedule (Adolph 4). The only developer who had the experience needed to read the legacy code quit, and the only documentation the team had to work off of was the user manual for the old system they were replacing (Adolph 6). Darrel Ince, a software quality assurance specialist writes, The key document on any software project is the requirements specification (61). Skipping a detailed requirements specification will cause many problems in the development process that can otherwise be avoided. The SRS should be used for planning the project at a detailed level. The SRS breaks down a large project into many detailed steps. Each of these steps can be analyzed for things such as feasibility, cost, and quality of the product. The SRS can also be reviewed to detect errors in the design. These errors might otherwise go unnoticed until the project is nearly completed. It is far easier to correct the design in the early stages of development than to have to go back and rework source code later. This is because software modules are designed with many interdependencies. A single change in one part of the project can affect other parts because of the 3

7 way the modules interact with each other. Failure to document requirements will also lead to wrong assumptions about the other risk factors in the development cycle. Project Management Pitfalls Six months after Adolph s project had began, the project manager left the co mpany and he was replaced by a project manager who believed strongly in employee empowerment (7). I had a manager who used this self -managed team style of management, and as Adolph points out, it only works if the team clearly understands what the pr oject objectives are (7). When I worked in a self-managed team environment, no work was done without first submitting an engineering estimate that described the work and gave a reasonable time estimate that included a minimum, maximum, and probable number of hours that would be required to complete the task. In Adolph s case, since his team had no written requirements specification, they had no well -defined goals (7). When his team proposed new strategies that would require a major changes in how the system they were replacing would work, the new project manager would readily approve the changes (Adolph 8). Good planning and a detailed list of requirements for the project would have helped keep the project on track even though some key employees left during the project. The frequent changes in the project caused Adolph s project schedule to fall apart (8). A period of six months went by before the next review, and nothing was done about the fact that the team was falling further and further behind schedule (Adolph 8). After the second milestone review, management canceled the project because the team had fallen too far behind, and they were redeployed to create wrappers around the legacy system to meet the minimum requirements of the existing custo mers (Adolph 8). A common mistake with software development is to allow too much time between management reviews. Management should be 4

8 involved and take a keen interest in a project. Management needs to hold the development team responsible for what the team members say they will do. If projects are reviewed frequently, and people are willing to admit mistakes and point out errors right away, then these problems can be fixed while they are still small. Small problems, when left unchecked, will usually grow into big problems over time. Software Design and Customer Loyalty Alan Cooper, in his book, writes that good software design is another very important step in the development of a product (72). Without good design, a software product may function well and have good market potential, but it is unlikely that the product will continue to be successful (Cooper 72,74). Cooper backs up his claim by comparing Novell, Microsoft, and Apple (74-77). Novell sold millions of copies of NetWare, but it was so poorly designed that customers hated it (75). Most of Novell s former customers have switched to Windows NT or a UNIX based solution because of the ease of installation, maintenance, and reliability. Microsoft, for its part, does little or no design of its own and often relies on acquiring the technology of others (Cooper 75). Microsoft then integrates these ideas into its own products. Microsoft s products are feature packed to the point of being annoying. There are so many buttons and options that important features get lost. Microsoft tried to solve this problem in Office 2000 by shuffling items around in the pull-down menus so that the feature that was used last would appear first in the list, but this makes finding features even more frustrating. I have discovered a feature that allows you to customize tool-bars in Microsoft s applications. This can make some tasks much easier to perform and increase the usefulness of the tool-bars in general. However, Microsoft has done such a good job of hiding this feature that I have yet to meet another person who knows about it. Microsoft s business strategy relies on the economy of scale 5

9 to stay competitive. Businesses buy Microsoft s products because of the low cost and most of us have learned how to get along with the products, even though we don t really enjoy using them. On the other hand, Cooper writes that despite all of Apple s business blunders, it has remained in business because of customer loyalty that was created by Apple s devotion to design and attention to the details (76). Quark, a company that makes desktop publishing software, is another example of how customer loyalty pays off. According to Tom McGhee, Denver Post Business Writer, Quark has 2.5 million customers who want a product that they are familiar with (1). This customer loyalty has allowed Quark to remain competitive in an area that Adobe Systems would otherwise dominate (McGhee 1). McGhee writes that this loyalty to Quark is impressive in light of Quark s poor customer service record (1). Thi s evidence reinforces the fact that good design leads to customer loyalty, and customer loyalty leads to the long-term success of a company. Risk Management All of the steps used in a software development project are important because they increase the chance of a successful outcome. Another way of looking at the problem is from the point of view of risk management. At the beginning of a project, there is a lot of uncertainty. The possibilities are great that something might go wrong. As the project progresses, and more is learned, the risks become fewer. According to Potter and Sakry, risk management is like preventive medicine (1). Risks are defined as a projects potential problems, and they should be treated separately from problems that are already known (Potter 1). Once the risks are identified and prioritized, problems that arise are easier to deal with. The potential for the problem has been anticipated and contingency plans are already in place. 6

10 Potter and Sakry propose a simple approach to the process of risk management (1). They suggest that the process should only take 90 to 120 minutes for projects that are 12 to 60 person-months of effort (Potter 1). Five people involved on a project for twelve months would use 60 person -months, but the risk management process should only take a few hours. In my experience, managers seem reluctant to talk about risks, and employees are reluctant to point out potential problems because they don t want to be accused of being too negative. Risk management solves this problem by bringing a small group of people together who are stakeholders in the project to participate in a 15 to 30 -minute brainstorming session (Potter 2). The group then suggests items until a basic list of risks is completed (Potter 2). The next step to risk management is risk analysis (Potter 2). This is where specific detail is added to each of the risks in the list and priorities are assigned (Potter 2). Items are ranked on a scale from one to ten for how likely it is that the poten tial problem will occur (Potter 2). The potential impact is ranked in the same way (Potter 2). The priority is then calculated by multiplying the likelihood value by the impact (Potter 2). Some risks may have a large impact, but their occurrence would be unlikely. On the other hand, a risk may have a small impact, but carry a high probability that the problem will happen. The priority ranking system helps to order risks so the most important risks are dealt with first. See Table 1 for an example of an itemized list of risks that are ranked by priority. 7

11 Risk Item Risk Likelihood Risk Impact Risk Priority Actions to Reduce Likelihood Actions to Reduce Impact Person Assigned to Action Action Completion Date Action Status Product may not run on new version of Windows Test Software on Beta Release Warn customers about the issue Jane 6/30/01 New version may run too slow to satisfy requirements Do benchmark testing with a prototype Find a solution that offers better performance Sally 5/30/01 Changing Customer Requirements Consult with customers about issues with using software Clearly document product features and limitations Bob 5/30/01 Fred might leave the company Give Fred the raise he has been expecting Table 1 Assign someone to cross-train with Fred John 7/3/01 The third step to risk management is risk management planning (Potter 2). This is where actions are planned that will reduce the likelihood of eac h risk (Potter 2). Actions are also planed that will reduce the impact when a potential problem actually happens (Potter 2). These action items are then assigned to individual members of the project team (Potter 2). This the key factor in making risk management work. Individuals on the team are allowed to own and work on potential problems before they occur. In my experience I have worked on lots of problems after they occurred. While working on these problems, I thought about how nice it would have been if the people who created the problem could have avoided making it in the first place. Risk management empowers a team to avoid a lot of these problems. The kind that make 8

12 you want to shake your head and wonder why the problem was allowed to happen in the first place. Conclusions and Recommendation The key factor to a successful software company is being able to win customer loyalty by delivering well-designed products that people enjoy using. This can be achieved by following good software development practices and avoiding mistakes. My recommendation is to use the simple approach to risk management as outlined in the Risk Management section of this report. In the past, we have excelled in some areas of the software development process, while neglecting some important steps. Risk management can help to insure that important considerations are not omitted from a project s design and development process. This will improve the quality of our products. Risk management can also help avoid costly mistakes that lead to failed projects. By analyzing potential problems with a project, we may be able to determine whether a project is worth pursuing before we commit a lot people and resources to it. 9

13 Works Cited Adolph, Steve. Lost in Chaos Chronology of a Failure. Software Development Online January Cooper, Alan. Customer Disloyalty. The Inmates Are Running the Asylum. Indianapolis: MacMillan Computer Publishing, Ince, Darrel, Requirements Analysis. An Introduction to Software Quality Assurance and its Implementaion. London: McGraw-Hill, McGhee, Tom. Xpress survives Adobe s Quark Killer, targets the Web. Denver Post 19 March Potter, Neil, and Mary Sakry. Keep Your Project On Track. Software Development Online April