Applied Software Project Management – Slides and Lecture Notes

This is part of the supporting material from our first book, Applied Software Project Management, which was published by O’Reilly in 2005. You can see all of the material here: https://www.stellman-greene.com/applied-software-project-management/

These slides can be used by professors, teachers and trainers who have adopted “Applied Software Project Management” as a textbook. The PowerPoint files and their contents can be used (with attribution) in other presentations and publications.

There is one slide set for each chapter in the book.

Lecture 1: Introduction to Applied Software Project Management

Why projects fail, how to make them succeed.

Abstract:
Many software organizations have problems delivering quality software that is finished on time and meets the users’ needs. Luckily, most software project problems have surprisingly few root causes, and these causes are well understood. Solutions to these problems have been discovered, explained, and tested in thousands of software organizations around the world. These solutions are generally straightforward and easy to implement. However, they are not always intuitive to people who do not understand project management, and that makes them difficult to introduce. It’s possible to make projects succeed by recognizing the common causes of project failure, and applying basic project management principles in order to address those causes. (This lecture corresponds to Chapter 1.)

Lecture 2: Software Project Planning

Using a Vision and Scope document to identify needs; Elements of a project plan.

Abstract:
If a project manager does not really understand the context in which the software is being built, then the only thing that the project team sees is the urgency; they lose track of the needs. They can see the individual problems that they are working to solve, but they may lose track of the big picture. Unless the team understands the needs that drive the project, they may end up with a narrow focus, causing them to waste time addressing problems that are of little importance to the stakeholders. It’s easy to build great software that solves the wrong problems, but the only way to build the appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begins. That’s the purpose of project planning. (This lecture corresponds to Chapter 2.)

Lecture 3: Estimation

Helping the project team create realistic estimates.

Abstract:
To someone who has never estimated a project in a structured way, estimation seems little more than attempting to predict the future. This view is reinforced when off-the-cuff estimates are inaccurate and projects come in late. But a good formal estimation process, one that allows the project team to reach a consensus on the estimates, can improve the accuracy of those estimates, making it much more likely that projects will come in on time. A project manager can help the team to create successful estimates for any software project by using sound techniques and understanding what makes estimates more accurate. (This lecture corresponds to Chapter 3.)

Lecture 4: Project Schedules

Creating, optimizing and tracking a project schedule.

Abstract:
The project schedule is the core of the project plan. It is used by the project manager to commit people to the project and show the organization how the work will be performed. Schedules are used to communicate final deadlines and, in some cases, to determine resource needs. They are also used as a kind of checklist to make sure that every task necessary is performed. If a task is on the schedule, the team is committed to doing it. In other words, the project schedule is the means by which the project manager brings the team and the project under control. (This lecture corresponds to Chapter 4.)

  Lecture 5: Reviews

Different practices for reviewing work products.

Abstract:
A review is any activity in which a work product is distributed to reviewers who examine it and give feedback. Different work products will go through different kinds of reviews: the team may do a very thorough, technical review of a software requirements specification, while the vision and scope document will be passed around via email and have higher level walkthroughs. Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members. In all cases, the work product coming out of the review has fewer defects than it had when it was submitted—even though the author thought it was “complete” before the review. Every defect that is found during a review is a defect that someone did not have to spend time tracking down later in the project. (This lecture corresponds to Chapter 5.)

Lecture 6: Software Requirements

Eliciting requirements, creating a software requirements specification and controlling changes.

Abstract:
Most software is built to meet the needs of someone other than the programmer. If those needs are going to be satisfied, the behavior of the software must be planned before the software is built. Software requirements engineering is the art and science of developing an accurate and complete definition of the behavior of software that can serve as the basis for software development. Like project management, programming, and testing, software requirements engineering encompasses a set of skills that require training and practice. Many projects are delayed (or fail completely) because development begins before anyone on the project team really understands how the software should behave. The solution to this problem is to take the time to gather and verify the software requirements — documentation that completely describes the behavior that is required of the software — before the software is designed, built, and tested. (This lecture corresponds to Chapter 6.)

Lecture 7: Design and Programming

Reviewing the design, refactoring, unit testing and project automation.

Abstract:
While many development problems originate outside of the programming team, there are some basic changes that the programmers can make that will improve the quality of the code they produce. Most teams, even ones with skilled and talented programmers, are vulnerable to the same design and programming problems. These problems can be addressed with a few basic tools and techniques—which can often be put in place entirely within the programming team, without involving anyone else in the organization. (This lecture corresponds to Chapter 7.)

Lecture 8: Software Testing

Test plans, test cases, defect tracking, automation and post-mortem reports.

Abstract:
In software testing, quality is defined as “conformance to requirements.” Every use case, functional requirement, and other software requirement defines a specific behavior that the software must exhibit. When the software does not behave the way that the requirements say it must behave, that is a defect. This means that your software testers are responsible for figuring out whether the software that was produced by the team behaves in the way that the requirements it was built from say that it should. Throughout the entire software project, the team does many things to find and prevent defects. Once the software has been built, it’s time to look back and make sure that it meets the requirements. The goal of software testing is to make sure that the product does what the users and stakeholders need it to do. Software testers review the final product to make sure that the initial requirements have been met. (This lecture corresponds to Chapter 8.)



Lecture 9: How to diagnose and fix a troubled software project, part I

Lecture 10: How to diagnose and fix a troubled software project, part II

Abstract:
There’s an old saying: “There’s only one way to be right, but a million ways to be wrong.” This is not necessarily the case with software projects. In practice, the vast majority of projects go wrong in one of a small number of ways. Throughout Part I of “Applied Software Project Management,” many scenarios are identified which highlight the most common causes of project failure. Lecture 9 shows how projects can fail due to problems with project planning, estimation, and failure to hold reviews. Lecture 10 shows project problems that are caused by poor requirements engineering practices, bad programming habits, or a lack of software testing. Both lectures cover many scenarios that typify how projects fail, and point to some of the tools, techniques and practices that project managers can use to fix them.

 

Lecture 11: Understanding Change

Why change fails, and how to make your changes succeed.

Abstract:
It would be nice if it were sufficient to understand why projects fail, and to know how to apply specific tools, techniques and practices to fix them. Unfortunately, that’s not enough. Building better software requires changing the way things are done in your organization, and change makes many people very uncomfortable. Project managers around the world have tried to implement straightforward improvements to the way they build software, only to find that they can’t convince the other people in their organizations to agree to discuss those changes, much less to actually alter the way their projects are carried out. It can be frustrating to see a problem, feel like you have the solution, and not be able to do anything about it. By understanding the most common ways that people respond to change and learning how to convince or reassure the ones who are resistant to change, it is possible to overcome these obstacles and successfully make the changes that your organization needs. (This lecture corresponds to Chapter 9.)

 

Lecture 12: Management and Leadership

Managing your organization, team and project.

Abstract:
In a sense, part of the job of the project manager is to serve as an information conduit. The project manager helps information flow from the team up to senior management in the form of project status and analysis information. It is his job to understand all of the work being done, so that it can be summarized to the people who make the decisions about the future of the project; they need this information to make informed and intelligent decisions. This requires that the project manager put a lot of effort into understanding what it is the team is doing and why they are doing it. The project manager cannot simply ask for estimates, fit those estimates in a schedule, and quiz the team on the percentage they’ve completed. He must understand what actions each team member is taking to complete the task, and what possible complications they are running into. The project manager is the only person looking at how the tasks interrelate; he is the only one with the perspective to see the problems and, ideally, fix them. (This lecture corresponds to Chapter 10.)

 

Lecture 13: Managing an Outsourced Project

Avoiding the common pitfalls that happen when working with an outsourced vendor.

Abstract:
Managing projects is hard. Scope creeps, changes go uncontrolled, defects are introduced, schedules are delayed…and that’s all in your own organization, where your software engineering team is right down the hall. Imagine how difficult it is to get even these results when your team is in another organization in an entirely different building—and possibly in a city halfway around the world! When you hire a company outside your organization to build your software, you open up yourself, your project, and your organization to exactly these problems. (This lecture corresponds to Chapter 11.)

Lecture 14: Process Improvement

A formal software process can help the organization expand its capability.

Abstract:
If you ask a dozen people on a software team to describe how the team should build software, you’ll get at least a dozen different answers—and most of those descriptions, if followed, will produce something. But what’s produced may not be very good: it may not be useful to the users, it may not be of very high quality, and the team may not be comfortable building, delivering, or maintaining it. A software process makes sure that everyone on the team agrees up front on how they will build software, while simultaneously ensuring that the software will be built in a way that works for the team and the organization. (This lecture corresponds to Chapter 12.)

All photos by Nisha Sondhe, except Lecture 7 by Steven Stellman.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.