Every software system covered so far in this series, from its earliest requirements through design, coding, testing, release, maintenance, and configuration management, has to actually be organized, scheduled, staffed, and paid for by someone. Software Project Management is the discipline responsible for that organizing work, making sure a software project is planned realistically, staffed appropriately, tracked honestly, and ultimately delivered within the time and budget that were originally promised.
Software Project Management refers to the process of planning, organizing, staffing, scheduling, and controlling the activities involved in developing a software product, from the very first feasibility study all the way through to final delivery and beyond. Unlike managing many other kinds of projects, software projects come with some particularly difficult challenges, since software is intangible, requirements frequently change partway through development, and the effort required to build a given feature is often genuinely difficult to estimate accurately in advance.
In this tutorial, you will learn about the core activities that make up software project management, including project planning, scheduling, cost and effort estimation, resource allocation, and project monitoring and control, and you will understand how each of these activities fits together to keep a software project moving toward a successful, on-time delivery.
Managing a software project is widely recognized as more difficult than managing many other types of engineering projects, for a few specific reasons. Software is intangible, meaning it cannot be seen or touched the way a partially built bridge or building can, which makes it genuinely harder for a manager to judge how much progress has actually been made simply by looking at the work. Software projects are also unusually prone to changing requirements, since customers frequently do not fully understand what they need until they see an early version of the system, prompting requests for changes well after planning and estimation have already been completed.
On top of this, the effort required to build a particular piece of software is often difficult to estimate accurately in advance, since two features that sound similarly sized on paper can turn out to involve wildly different amounts of actual work once development begins. These challenges are exactly why software project management has developed its own specific set of practices, models, and techniques, separate from general project management, to deal with the particular difficulties software projects tend to introduce.
Project planning is the activity of defining exactly what a project needs to accomplish, breaking that work down into manageable pieces, and laying out an overall approach for getting from the current state to a completed, delivered product. A software project plan typically covers the project's scope, meaning exactly what will and will not be included in the delivered product, along with the overall approach or process model that will be followed, whether that is something like the Waterfall Model, the Spiral Model, or another approach covered earlier in this series.
A key part of planning involves breaking the overall project down into smaller, well-defined pieces of work, often organized into a structure called a work breakdown structure, where large goals are progressively divided into smaller and smaller tasks until each one is specific and manageable enough to be assigned, estimated, and tracked individually. Good planning also identifies the major milestones a project will pass through, giving the team and stakeholders clear checkpoints to measure progress against as the project moves forward.
Project scheduling takes the individual tasks identified during planning and arranges them across an actual timeline, deciding when each task should start, how long it should take, and which tasks depend on others being finished first before they can begin. Since software development tasks are rarely completely independent of one another, effective scheduling has to carefully account for these dependencies, since starting one task too early, before something it depends on is actually finished, can create serious problems later.
Scheduling techniques commonly used in software projects include Gantt charts, which display each task as a horizontal bar across a calendar timeline, making it easy to see at a glance which tasks overlap and which are sequential, and network diagrams built using techniques like the Critical Path Method, which specifically identify the longest chain of dependent tasks in a project, known as the critical path, since any delay along this particular chain directly delays the entire project's completion date. Identifying the critical path early gives a project manager a clear signal about exactly which tasks deserve the closest attention and the least tolerance for delay.
Cost and effort estimation involves predicting, as early and as accurately as possible, how much time, money, and staffing a software project is actually going to require before that work has been carried out. Since software projects are notoriously difficult to estimate precisely, this activity relies on a mix of experience, historical data from previous similar projects, and formal estimation models.
One widely taught formal estimation approach is the Constructive Cost Model, commonly abbreviated as COCOMO, which estimates the effort a project will require based primarily on the predicted size of the software, typically measured in thousands of lines of code, combined with a set of adjustment factors that account for things like the complexity of the project and the experience level of the team involved. While no estimation technique can ever be perfectly accurate, especially early in a project when requirements are still not fully understood, having a structured estimate gives the project manager a far more defensible starting point than simply guessing, and it can be refined further as the project progresses and more is learned about its actual scope.
Resource allocation involves assigning the people, tools, and other resources a project has available to the specific tasks identified during planning and scheduling, in a way that makes the most effective use of everyone's particular skills and availability. This includes deciding which developers should work on which components based on their experience, ensuring that specialized roles, such as a database expert or a security specialist, are assigned to the tasks that actually need that particular expertise, and making sure that no single team member is overloaded with more work than they can realistically complete within the scheduled timeframe.
Resource allocation also has to account for the fact that people are not perfectly interchangeable, and simply adding more developers to a delayed project does not necessarily make it finish faster, since new team members need time to become familiar with the project before they can contribute effectively, and coordinating a larger team introduces its own additional communication overhead. Thoughtful resource allocation tries to balance these realities against the schedule and budget constraints the project is operating under.
Project monitoring and control is the ongoing activity of tracking a project's actual progress against its original plan and schedule, and taking corrective action whenever the two start to drift apart. This involves regularly collecting information about which tasks have actually been completed, comparing that against what the schedule predicted should be completed by that point, and investigating the reasons behind any significant gap between the two.
When monitoring reveals that a project is falling behind schedule, running over budget, or facing a risk that was not originally anticipated, project control is what allows the team to respond, whether that means adjusting the schedule, reallocating resources, negotiating a change in scope with the customer, or taking some other corrective action before the problem grows larger. Without consistent monitoring and control, a project could silently drift far off track for a long time before anyone realizes just how serious the situation has actually become, which is exactly why this activity continues throughout the entire length of a project rather than being a one-time task performed only at the beginning.
| Activity | What It Involves |
|---|---|
| Project Planning | Defining scope, breaking work into tasks, and choosing an overall approach |
| Project Scheduling | Arranging tasks across a timeline, accounting for dependencies |
| Cost and Effort Estimation | Predicting the time, money, and staffing a project will require |
| Resource Allocation | Assigning people and tools to specific tasks effectively |
| Project Monitoring and Control | Tracking actual progress against the plan and correcting deviations |
The software project manager is the individual responsible for carrying out these activities in practice, acting as the central point of coordination between the development team, the customer, and any other stakeholders involved in the project. A project manager needs a somewhat unusual combination of skills, including enough technical understanding to make informed decisions about the software being built, along with strong organizational and communication skills to keep a team of people working effectively toward a shared goal.
Beyond simply tracking tasks and schedules, an effective project manager also plays an important role in managing expectations, communicating honestly with stakeholders about progress and setbacks, and shielding the development team from unnecessary distractions so they can focus on actually building the software. This role connects closely with configuration management and risk management, both covered elsewhere in this series, since a project manager relies heavily on accurate configuration records and a clear understanding of project risks in order to make good planning and scheduling decisions.
| Advantages | Limitations |
|---|---|
| Gives a project clear structure, making it far more likely to be delivered on time and within budget. | Software estimation remains inherently uncertain, especially early in a project's life. |
| Scheduling techniques like the critical path method highlight exactly where delays matter most. | Overly rigid planning can struggle to accommodate the frequent requirement changes common in software projects. |
| Consistent monitoring catches problems early, while they are still relatively easy to correct. | Effective project management requires real skill and experience, and is not simply a matter of following a checklist. |
| Mistake | Correct Practice |
|---|---|
| Assuming project planning happens once and never needs to be revisited. | Understand that plans are frequently adjusted as monitoring reveals new information throughout the project. |
| Believing that adding more developers to a delayed project automatically speeds it up. | Remember that new team members need ramp-up time and add communication overhead, which does not always shorten a delayed schedule. |
| Treating cost estimation as a one-time calculation performed only at the very start. | Remember that estimates are typically refined and updated as more becomes known about the project over time. |
| Confusing scheduling with estimation. | Remember that estimation predicts how much effort a task will require, while scheduling arranges tasks across an actual timeline. |
Software Project Management brings structure and accountability to the process of actually building software, addressing challenges that make software projects notoriously difficult to manage, including intangible progress, shifting requirements, and uncertain effort estimation. Project planning defines what needs to be built and breaks it into manageable pieces, while scheduling arranges those pieces across a realistic timeline that accounts for task dependencies.
Cost and effort estimation, using techniques like COCOMO, gives the team a structured basis for predicting how much a project will actually require, while resource allocation ensures the right people are matched to the right tasks. Finally, project monitoring and control keeps the entire effort honest over time, catching deviations from the plan early enough to correct them before they threaten the project's successful delivery.
With software project management covered, you are now ready to explore software quality assurance in detail, examining the quality models, standards, and review practices that work alongside the planning and monitoring activities introduced in this chapter to ensure the delivered software actually meets the standard it was meant to.