“Project Management is the discipline of organizing and managing resources (e.g. people) in such a way that the project is completed within defined scope, quality, time and cost constraints. A project is a temporary and one-time endeavor undertaken to create a unique product or service, which brings about beneficial change or added value.” [3]
The goal of software project management is to understand, plan, measure and control the project such that it is delivered on time and on budget. This involves gathering requirements, managing risk, monitoring and controlling progress, and following a software development process.
Software project management requires trained and experienced Software Engineers in order to increase the likelihood of project success because software development for large projects is extremely complex and following strict engineering principles will help reduce the risks associated with the project.
Software project management is extremely important for the following reasons:
- Software development is highly unpredictable: [as of 2007?] only about 10% of projects are delivered within initial budget and on schedule. [1]
- Management has a greater effect on the success or failure of a project than technology advances. [1]
- Too often there is too much scrap and rework. The entire process is very immature, not enough reuse. [1]
According to the 10th edition of the annual CHAOS report from The Standish Group, only 34% of projects are completed successfully. While this actually represents a huge improvement, there is obviously still room for more! Why have things started to get better?
Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward. [4]
Project failure in itself is not the only reason why software management is so important. When a project fails, not only is a product not delivered, but all the money invested in the product is also lost. Without proper software management, even completed projects will be delivered late and over budget. Take a look at some of these examples of expensive software failures.
The 2004 CHAOS report, entitled “CHAOS Chronicles,†found total U.S. project waste to be $55 billion, made up of $38 billion in lost dollar value and $17 billion in cost overruns. Total project spending was found to be $255 billion in the 2004 report.
In 1994, The Standish Group estimated U.S. IT projects wasted $140 billion—$80 billion of that from failed projects—out of a total of $250 billion in project spending. [4]
If the risk of failure and loss of money is not enough to convince you of the importance of proper software management, consider that some software will also put the lives of people at risk. Go read Software Horror Stories or History’s Worst Software Bugs to see some examples…
failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. [5]
So why does software fail anyways? Here is the list from the IEEE Spectrum [5]:
- Unrealistic or unarticulated project goals
- Inaccurate estimates of needed resources
- Badly defined system requirements
- Poor reporting of the project’s status
- Unmanaged risks
- Poor communication among customers, developers, and users
- Use of immature technology
- Inability to handle the project’s complexity
- Sloppy development practices
- Poor project management
- Stakeholder politics
- Commercial pressures
Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don’t aim to fail. When a commercial plane crashes, investigators look at many factors, such as the weather, maintenance records, the pilot’s disposition and training, and cultural factors within the airline. Similarly, we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures.
THE PILOT’S ACTIONS JUST BEFORE a plane crashes are always of great interest to investigators. That’s because the pilot is the ultimate decision-maker, responsible for the safe operation of the craft. Similarly, project managers play a crucial role in software projects and can be a major source of errors that lead to failure.
Bad decisions by project managers are probably the single greatest cause of software failures today. Poor technical management, by contrast, can lead to technical errors, but those can generally be isolated and fixed. However, a bad project management decision—such as hiring too few programmers or picking the wrong type of contract—can wreak havoc.
Project management decisions are often tricky precisely because they involve tradeoffs based on fuzzy or incomplete knowledge. Estimating how much an IT project will cost and how long it will take is as much art as science. The larger or more novel the project, the less accurate the estimates. It’s a running joke in the industry that IT project estimates are at best within 25 percent of their true value 75 percent of the time.
Poor project management takes many other forms, including bad communication, which creates an inhospitable atmosphere that increases turnover; not investing in staff training; and not reviewing the project’s progress at regular intervals. Any of these can help derail a software project. [5]
Another problem which distinguishes software engineering from other engineering fields is the fact that software is not concrete. There is a common misconception that software can be easily changed to do anything no matter which stage the project is currently at. If construction on a building or bridge is nearly complete, people understand that it is too late to make significant changes to the architecture or design. However with software, clients tend to have the impression that making changes are always easy even though the end result could be the equivalent to tearing down a nearly completed building!
A common misconception is that developing software means writing code, which is definitely not the case. Code writing itself only counts for about 40% of software development. There are many other important steps such as requirements, configuration, deployment and maintenance. [1]
The main goal of software project management is to try and reduce the risks involved with a project such that the project can then finish on budget and on time with all of the features desired by the clients..
Project management helps us achieve the following [1]:
- Estimate the budget needed to complete the project before it starts and to monitor the progress so that at any given time we know how much a project has cost and how much more it will cost.
- Estimate the time needed to complete at project before it starts and to monitor the progress so that at any given time we know how much time is left before completion.
- Estimate which features can be developed in the given time and cost frame.
- Monitors the project progress and so we know which features have been completed and which ones will be completed before the end of the project.
- Software delivered must provide all the features specified in the requirements (feature complete). Project management therefore helps project managers re-negotiate features and requirements.
Software users are among the worst treated customer in engineering. It is taken for granted without much complaint that software has bugs, crashes from time to time, doesn’t work occasionally and is too complicated to install and use. Quality must be a given part of the scope; the completed features must be of high quality. [1]
Since project management is so important, we need to be able to rank organizations in terms of their software capability and maturity. We use the Capability and Maturity Model (CMM) to achieve this.
CMM ranks the software development process of a firm by using 5 levels of maturity
Level 1 – Initial
At maturity level 1, processes are usually ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects
Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes again.Level 1 software project success depends on having high quality people.
Level 2 – Repeatable [Managed]
At maturity level 2, software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.
Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).
Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates.
Level 3 – Defined
The organization’s set of standard processes, which are the basis for level 3, are established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines.
The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed.
A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.
Effective project management system is implemented with the help of good project management software.
Level 4 – Quantitatively Managed
Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Organizations at this level set quantitative quality goals for both software process and software maintenance. Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.
Level 5 – Optimizing
Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities.
Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed.
Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.
A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.[2]
Project Performance Expectation
Capability Maturity Model Key Process Areas
Initial
- Ad hoc
Repeatable
- Software Configuration Management
- Software Quality Assurance
- Software Subcontract Management
- Software Project Tracking and Oversight
- Software Project Planning
- Requirements Management
Defined
- Peer Reviews
- Intergroup Coordination
- Software Product Engineering
- Integrated Software Management
- Training Program
- Organization Process Definition
- Organization Process Focus
Managed
- Software Quality Management
- Quantitative Process Management
Optimizing
- Process Change Management
- Technology Change Management
- Defect Prevention
Key Process Areas Across Categories
[1]
—
[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 1
[2] Wikipedia, Capability Maturtiy Model
[3] Wikipedia, Project Management
[4] Softwaremag.com, Standish: Project Success Rates Improved Over 10 Years
[5] Robert N. Charette, IEEE Spectrum, Why Software Fails
