Software project management

Software project management is an art and science of planning and leading software projects.[1] It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

History[]

In the 1970s and 1980s, the software industry grew very quickly, as computer companies quickly recognized the relatively low cost of software production compared to hardware production and circuitry. To manage new development efforts, companies applied the established project management methods, but project schedules slipped during test runs, especially when confusion occurred in the gray zone between the user specifications and the delivered software. To be able to avoid these problems, software project management methods focused on matching user requirements to delivered products, in a method known now as the waterfall model.

As the industry has matured, analysis of software project management failures has shown that the following are the most common causes:[2][3][4]

  1. Insufficient end-user involvement
  2. Poor communication among customers, developers, users and project managers
  3. Unrealistic or unarticulated project goals
  4. Inaccurate estimates of needed resources
  5. Badly defined or incomplete system requirements and specifications
  6. Poor reporting of the project's status
  7. Poorly managed risks
  8. Use of immature technology
  9. Inability to handle the project's complexity
  10. Sloppy development practices
  11. Stakeholder politics (e.g. absence of executive support, or politics between the customer and end-users)
  12. Commercial pressures

The first five items in the list above show the difficulties articulating the needs of the client in such a way that proper resources can deliver the proper project goals. Specific software project management tools are useful and often necessary, but the true art in software project management is applying the correct method and then using tools to support the method. Without a method, tools are worthless. Since the 1960s, several proprietary software project management methods have been developed by software manufacturers for their own use, while computer consulting firms have also developed similar methods for their clients. Today software project management methods are still evolving, but the current trend leads away from the waterfall model to a more cyclic project delivery model that imitates a software development process.

Software development process[]

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:

Project planning, execution, monitoring and control[]

The purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion. The project execution is the process of completing the tasks defined in the project plan.

The purpose of project monitoring and control is to keep the team and management up to date on the project's progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, change control is used to keep the products up to date.

Issue[]

In computing, the term "issue" is a unit of work to accomplish an improvement in a system.[citation needed] An issue could be a bug, a requested feature, task, missing documentation, and so forth.

For example, OpenOffice.org used to call their modified version of Bugzilla IssueZilla. As of September 2010, they call their system Issue Tracker.[needs update]

Severity levels[]

Issues are often categorized in terms of severity levels. Different companies have different definitions of severities, but some of the most common ones are:

High
The bug or issue affects a crucial part of a system, and must be fixed in order for it to resume normal operation.
Medium
The bug or issue affects a minor part of a system, but has some impact on its operation. This severity level is assigned when a non-central requirement of a system is affected.
Low / Fixed
The bug or issue affects a minor part of a system, and has very little impact on its operation. This severity level is assigned when a non-central requirement of a system (and with lower importance) is affected.
Trivial (cosmetic, aesthetic)
The system works correctly, but the appearance does not match the expected one. For example: wrong colors, too much or too little spacing between contents, incorrect font sizes, typos, etc. This is the lowest severity issue.

In many software companies,[which?] issues are often investigated by quality assurance analysts when they verify a system for correctness, and then assigned to the developer(s) that are responsible for resolving them. They can also be assigned by system users during the User Acceptance Testing (UAT) phase.

Issues are communicated using Issue or Defect Tracking Systems. In some other cases,[example needed] emails or instant messengers are used.

Philosophy[]

As a subdiscipline of project management, some regard the management of software development akin to the management of manufacturing, which can be performed by someone with management skills, but no programming skills. John C. Reynolds rebuts this view, and argues that software development is entirely design work, and compares a manager who cannot program to the managing or of a newspaper who cannot write.[6]

References[]

  1. ^ a b Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. Archived from the original on 2015-02-09.
  2. ^ "Why Software Fails", in IEEE Spectrum
  3. ^ a b Producing Open Source Software: How to Run a Successful Free Software Project (e-book, freely downloadable), by Karl Fogel
  4. ^ a b Robert Frese and Vicki Sauter, "Improving your odds for software project success," IEEE Engineering Management Review, Vol. 42, No. 4, Fourth Quarter, Dec 2014
  5. ^ Philip Greenspun, in Jessica Livingston's Founders at Work (2007), ISBN 1-59059-714-1
  6. ^ John C. Reynolds, Some thoughts on teaching programming and programming languages, SIGPLAN Notices, Volume 43, Issue 11, November 2008, p.108: "Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing or who cannot write."
General

External links[]

Project failure[]