Poor software project management often means missed deadlines, cost overruns or even outright failure of the project. How can your company avoid this industry-wide problem? In our brief you'll learn best practices for successfully completing software projects.

By ExecutiveBrief

Software development projects are plagued with risk and impending failure. According to The Standish Group’s 2006 CHAOS Report, only about one-third (35 percent) of the researched software development projects undertaken in the previous two years were considered “successful”—that is, they met all requirements and were completed on time and within budget. Almost half (46 percent) were reported to be “challenged,” meaning that they were completed and operational, but were delivered late, went over budget, or did not support all of the features originally required. And 19 percent were considered outright failures or cancelled prior to completion. According to the same report, 41 cents of every dollar spent on software development was considered wasted.
Anyone involved with software development projects knows why bringing them to successful completion can be so difficult to achieve. The most frequently cited factors that contribute to the challenge include:
• Poor communication. The legendary communication gap between developers and business clients or stakeholders often leads to poorly defined requirements, which in turn will lead to inadequately designed software that doesn’t provide the functionality needed by the customer.
• Time. Because market forces today are continually changing—and at such a fast pace, the longer a development project takes to get off the ground and cycle through to completion, the more likely it will be that the software will fail to meet the current needs of users. Requirements and priorities can change multiple times as projects progress through planning, development, testing, and production.
• Scope. Poor communication, time creep, and intense market competition lead to scope creep, where requirements are frequently changed and added to the project without a proper evaluation of their true importance and without corresponding increases in resources, budget, or schedule. A project whose scope is too broad will become too complex, exceed allotted costs, overrun schedule, and ultimately fail. A project whose scope has been defined too narrowly may finish on time, but likely will fail to perform according to customers’ real requirements.
• Unorganized development processes. Despite the availability of established best practices in software development, such as the U.S. Software Engineering Institute’s (SEI’s) Capability Maturity Model Integration (CMMI), many development departments don’t follow a coherent development methodology. A study by the SEI in 2005 found that, when it came to the quality of their development processes, almost 40 percent of companies gave themselves a low rating of 1 or 2 out of a possible 5 on the CMMI scale.
• Budget, resources, and schedule. Software development is rife with unrealistically low budgets, inadequate resources, and limited time.
• Success for any IT project, particularly in software development, is very much dependent on effective management of risks, both early on in the project and throughout its lifespan. Not long ago, risk was defined almost exclusively in negative terms, but in the past seven years or so, risk management philosophy has expanded to include unexpected opportunities. “Risk can be defined as uncertainty that matters,” says David Hillson, director of Risk Doctor and Partners, a well-known global consulting firm specializing in project risk management. “Uncertainties, when they happen, can damage a project, but some uncertainties can help.”

For example, new hires can bring new expertise that takes a project in a positive new direction. A company could discover reusable code that it didn’t know it had. Certain parts of a project could finish early, opening up possibilities that seemed impossible at first. “You can

You do not have flash or javascript support.

Average (3 votes)

Reply