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.

The waterfall life cycle model is the most traditional of them all. This model has a top-down, or linear, ordering to it. Normally no phase is repeated, however, there may be overlapping between the different phases if necessary. Generally, the output of each stage becomes the input for the next.

The spiral life cycle model differs from the linear approach associated with the waterfall life cycle in that the same set of life cycle phases are repeated. Phases such as planning, development, construction, and evaluation iterated until the final product is finished.

The incremental build life cycle model provides progressive development of operational software, with each release adding new capabilities. It is unique from the spiral life cycle in that it divides the product into builds, where sections of the project are created and tested separately.

The prototyping life cycle model involves heavy user involvement while developers generate functional requirements and physical design specifications simultaneously. A model is created that is analyzed, inspected, and tested by knowledge workers who can then offer recommendations to improve it.

The rapid application development (RAD) life cycle model focuses on building applications in a very short amount of time with compromises in usability, features, and/or execution speed. The emphasis on speed helps ensure that clients’ requirements do not change before the cycle is complete, as was often the case when applying the waterfall life cycle model in the past.

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.

Extreme programming (XP) focuses mainly on reducing the cost of change by introducing more flexible practices in day-to-day activities. Some of the values extreme programming emphasizes are communication and simplicity. Collaboration of users and programmers requires rapid communication where information needs to be distributed quickly among members of the team. XP also promotes beginning with the simplest solution and building from there. In this approach, the focus is on meting the needs of today, rather than those of tomorrow. The drawback to this is it could cause more work in the future. However, proponents of XP do not believe in spending resources for uncertain future requirements that may not be needed.

Scrums are similar to other life cycle models in that they use the iterative approach to address changing requirements. The difference is with a scrum, these repetitions are referred to as sprints, which normally last about thirty days. In this model, teams focus only on their discrete piece of work, while a project manager coordinates the overall body of work. One of the main priorities of a project manager is to identify and remove any obstacles that could hinder the teams’ ability to accomplish their goals. Each team, or scrum, is self-organized and is encouraged to communicate with all other teams involved on the project.

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.

See also