# Software project management

Software Project Management is a subset of Information Technology Project Management that deals exclusively with the development of software applications. Every application that is created follows some discernible process that can be connected to the set of steps that collectively define Software Project Management.
One of the main challenges in software project management is the balance of the "triple constraint" (scope of software, time required to implement, and development cost). Scope is the set of specific objectives that a define the problems a piece of software should address. Time required is a numeric figure that is definable based on the work needed to achieve the scope. Development cost is a monetary figure that is calculated based on the time required, as well as other planned and unforeseeable, expenses. Any of these three factors could be the most important, or there could be more than one mutually important constraint, in the context of a specific software development project. An increase, or decrease, in any of the three would have ramifications for the values of the other two. A successfully managed project will deliver the scope, while achieving time and monetary budgets.
More broadly, a project is “a temporary endeavor undertaken to create a unique product, service, or result.”(PMI) Projects have five attributes: a unique purpose or well-defined objective; a definite start and end point; develop using progressive elaboration; require resources; have a primary sponsor or customer; and involves uncertainty. Software projects have these attributes and follow the project life cycle.
A project life cycle is divided into several phases: concept: development; implementation; and close-out. In the concept phase, uncertainty is highest as the purpose of the project is defined. In the development phase, project work plans and budgets are defined. In the implementation phase, the actual work on the projects product, service or result takes place. The close out phase marks the completion of work and sponsor or customer acceptance. Software projects follow this same life cycle but have some life cycle models that are distinct from other kinds of projects.
Project management involves five process groups that integrate the phases of the project life cycle. Initiating is the first process group. It involves the concept phase of the project life cycle, but the initiating process is part of all phases of the project life cycle. Planning is the second process group and involves defining the flow of work done in the development phase, though it too extends into later project phases. Executing is the third process group and involves the coordination of people and other resources to carry out the planned work and produce the product, service or result. The executing processes span from the earliest phase of a project to the final close-out phase. Monitoring and controlling is the third process and involves issues like status reports and quality control which span all the phases of a project’s life cycle. Closing is the fifth process group and includes formal acceptance of the product, service or result by the sponsor or customer. Closing processes also include project documentation, such as closing out contracts and ‘lessons learned’ reports.
There are two unique frameworks involved in software development. They are the predictive life cycle and adaptive software development. Each one differs in their approach to the software development life cycle. The predictive life cycle favors optimization over adaptability, whereas adaptive software development is much more flexible while welcoming change.
The predictive life cycle requires that the scope of the project be clearly defined up front to include the schedule and cost of the project. A majority of time is spent clarifying the requirements of the software before anything is constructed. Because so much is invested in planning, deviations from the plan are rare. Within the predictive life cycle, there are several models such as the waterfall life cycle, the spiral life cycle, the incremental build life cycle, the prototyping life cycle, and the rapid application development (RAD) life cycle.
Adaptive software development (ASD) is a mission driven, iterative cycle that is tolerant to change. It is a good tool to use when the requirements cannot be clearly stated early in the life cycle. ASD originally grew out of rapid application development. Contrary to RAD, however, an ASD life cycle is feature based whereas RAD emphasized speed. ASD provides for continuous adaptation to the emergent state of the project. Recently, the term agile software development has become popular and is interchangeable with adaptive software development. Two of the most favored ASD life cycle models are extreme programming and Scrum.
Regardless of which model one chooses, a project manager should review each phase of the cycle before continuing on to the next. The reason for this is that as a project continues, the organization usually commits more money and resources to it. Due to various factors such as compatibility with other organizational goals, potential success, and cost, it may require redirection or even termination. These review sessions by management are referred to as phase exits or kill points. This is a very important aspect of the life cycle to keep the project on track, or in worst-case scenarios, to cease work on the project.
Software Project Management is generally accomplished with the help of some specific tools and applications. To facilitate versioning in code, systems such as CVS, Subversion, or FishEye are used to checkout and combine code created concurrently by different programmers. Traditional project planning tools, such as Gantt charts and Critical Path, can be helpful in determining task order and dependence. Numerous free, shareware, mid market and enterprise project management tools are available for the software developer.
References
PMI-Project Management Institute, Inc., A Guide to the Project Management Body of Knowledge (2004), p. 5 http://www.maxwideman.com/guests/stateofart/specific.htm http://www.softwareplanner.com/se_sp_adaptive_software_mkt.asp http://www.martinfowler.com/articles/newMethodology.html http://www.computerworld.com/developmenttopics/development/story/0,10801,71151,00.html
I don't consider myself qualified to rewrite the article, however, I think I can contribute a few comments which could help a more qualified person improve the article. Also, I'm a pretty bad wiki editor, so I'm likely to simply not be able to properly edit this article, so IMO it's safer (for the article's content) to just add a comment. Below are my comments.
Since I don't intend to edit the article itself (just throw some pebbles in the water then let men wiser than myself get them out again :-), I didn't really check what I wrote, so whoever reads this should double-check with other sources.
* IMO, the time constraint is part of the scope. AFAIK, the three constraints are scope (functional and time), reliability and cost. What each means, in detail, is that customers usually want projects delivered with maximum functionality in the shortest possible time (scope), bug-free (reliability), and for free (budget). As long as you do no testing and bug-fixing, and employ thousands of programmers, you can maximize the fulfillment of the scope requirements, but you get a minimum of fulfillment of the reliability and budget requirements. As long as you heavily invest in testing, limit the functionality, and plan a late delivery, you can maximize the fulfillment of the reliability requirements, but minimize the fulfillment of scope and budget requirements. If you invest only little money, you have no ppl to do a reliable and feature-rich app on time, so maximizing the fulfillment of the budget requirements minimizes the fulfillment of the scope and reliability requirements. What SW prj mgmt has to do, is to reach the optimal compromise between the three constraints.
* Project success is judged indeed by three criteria which are timely delivery, feature completeness and delivery within budget (for example by the chaos reports published by the standish group.) As you can see, reliability is usually not included in the evaluation criteria. This is because it is usually hidden in the feature completeness evaluation - features which are delivered but are buggy are not counted as being present. However, these are success evaluation criteria, not the constraints within which the project management process has to happen. They are of course related, but they are not the same, and optimal project management does not necessarily lead to a successful project.
* A more straighforward criteria used instead of feature completeness is whether the app ever gets to be used in production, and if so, whether the end-users get along with it (which can be easily judged by the amount of work the app generates for the helpdesk). I like this criterium more - especially when using a predictive approach it is easy to miss important requirements, by simply ignoring important stakeholders in the requirements definition process, or by getting usability requirements wrong due to a wrong assessment of the end users' computer skills.
* http://www.artima.com/weblogs/viewpost.jsp?thread=221622, when read with its comments, provides a good reference what software development is about - it's not just technology. Neither is SW prj mgmt. There is an organisation, which IMO has a smarter, broader approach than PMI - http://www.ipma.ch/Pages/IPMA.aspx, which should also be mentioned here. Also, I don't read a word about prince2.
* Prototyping is one approach to RAD. RAD is not so much about a specific SW prj mgmt method, AFAIK, but about the techniques and technology used. You could do RAD by PMBOK or prince2, and you could also do a project based on the waterfall model also using PMBOK or prince2. Prototyping can also be viewed as being more of an adaptive technology, and not a predictive one, when the final prototype is the actual final product, and prototyping is not just used to mock up something the end user can understand.
I just read some interesting article (http://www.artima.com/weblogs/viewpost.jsp?thread=221903) about stability vs. feature richness in a programming language. An interesting idea there is that if you are going to add a feature to a language, you should add it properly from the beginning (the article is partially criticizing the brain-damaged implementation of generics in Java - something I totally agree with.) Similarly, IMO it would be a better idea to scrap this article alltogether, put all existing content into a comments/food for thought section, and place an outline with links to new topics in the article's content. Then, as time goes by, one outline item at a time could be easier completed than an article covering everything.
The department of Computer_Programming has such an outline, and I like it very much.
The outline for the SW prj mgmt department could be done by simply taking the http://www.ipma.ch/Pages/IPMA.aspx list of processes and phases - IPMA and not PMI because it seems to me the list of SW prj mgmt issues covered by IPMA is broader than that covered by any other methodology. Then, in the content section, you could simply state what each SW prj mgmt method has to say, and underline the differences between the different approaches - including the structural differences between the various methods. There's just one catch: the IPMA papers are hard to get (you must be a member to get them), and there are not many freely available resources about what they preach. However, wikiversity should be a large enough community to contain members of some national organisation affiliated with IPMA. Who knows, maybe just asking them nicely would get them to write the whole outline themselves. Then, other members would just have to fill in the stuff from other methods, and IPMA ppl could write their own stuff.
IMO, SW prj mgmt is an essential success factor for most SW projects (of course, not being the only one), and it is also a topic a lot less well understood or known than other SW development topics. So IMO it is very important to have this section filled out properly.