Manage Learn to apply best practices and optimize your operations.

How to set goals and manage software projects and teams

As a project manager developing software, how do you set goals, how do you assess problems and instruct your team to solve them? Learn how industry leaders have found success ways to address managerial and application pitfalls.


Software Project Management

When projects go badly, our reaction is often to work harder— by which we mean work longer hours. But it's rarely that simple. Projects often go wrong at the very start, and their problems are generally symptoms of a deeply dysfunctional organization.

In a career spanning more than 60 years as a senior manager and researcher, Watts Humphrey has personally helped dozens of organizations go "from the brink of chaos to a sound, businesslike operation," as he wrote in his 2002 book Winning with Software. That description applied to Watts's experience with IBM, where he worked for 27 years, supervising 4,000 software professionals in 15 laboratories and 7 countries.

Title Information:
Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself
  • By Watts S. Humphrey, William R. Thomas
  • Published Mar 29, 2010 by Addison-Wesley Professional. Part of the SEI Series in Software Engineering series.

Later, as a senior fellow overseeing the process program at Carnegie Mellon University's Software Engineering Institute (SEI), Watts made an "outrageous commitment"—his words— to transform the world of software. Beginning in 1986, he pioneered the Capability Maturity Model (CMM), the Personal Software Process (PSP), and the Team Software Process (TSP). Those methodologies have helped thousands more organizations and engineers establish and, most importantly, commit to following effective engineering and management practices for their software projects.

Watts did not stop at describing methods for improving software engineering processes. Rather, he made it his personal responsibility to instruct "all software professionals and their managers to plan and track their work, use the best technical methods, and measure and manage the quality of this work." In addition to teaching courses and presenting at conferences, Watts invoked the power of the pen, authoring 11 books and hundreds of technical reports, journal articles, and columns.

In 2005, at a White House ceremony, Watts was awarded the United States National Medal of Technology by the President of the United States "for his vision of a discipline for software engineering, for his work toward meeting that vision, and for the resultant impact on the U.S. government, industry, and academic communities."

Much of Watts's writing focuses on detailed descriptions of the tools of process management. But an equal amount is a remarkably clear presentation of his vision for properly planned and committed work. He writes in a straightforward and personal style. He draws on anecdotes from his years at IBM and the SEI but also from his earlier experience on the Auburn University wrestling team, for example, and from his service in the

U.S. military. While he often describes success, he also recounts times when he felt that he failed and how he learned to approach a problem differently the next time. This book, drawn from Watts's books, articles, and columns, comprises a collection of advice, stories, and hard-earned wisdom, rather than specific instruction on how to implement the PSP or TSP (which are thoroughly covered in Watts's books on those specific subjects). What emerges for the reader is an understanding that successful software project management is a journey with many obstacles. To succeed, engineers must manage more than their projects. They must use their own experience and that of their teams to first understand and then plan the project ahead. They must influence their teams' attitudes and methods for doing disciplined work. And they must persuade their bosses to set aside ill-informed notions of schedules and resource commitments and look instead at hard, historical data.

The essays in Part I provide insights on types of plans and the planning process. Part II covers team building and motivation. Part III describes how to work with your managers and persuade them to use best practices. And Part IV examines your personal responsibilities, commitments, and processes.

These essays shine a light on the challenges inherent in software development and can set engineers on the road to understanding how to succeed. And while Watts's particular expertise is software, practitioners in every field of business will benefit from the wisdom and advice contained here. —Bill Thomas


The dictionary defines a goal as "the result or achievement toward which effort is directed." Goals concern results and efforts, but most importantly they concern direction. Goals provide direction and focus for our efforts. They clearly define the end that we desire and establish a priority for the required work.

Goals also imply several other things. For example, you need to know whether you have achieved the desired result and where you are along the way. Are you winning or losing and are your efforts likely to be successful? All of these—the result, direction, measurement, and effort—are involved in setting and achieving goals.

Goals are useful for individuals. Few would argue that, without a goal, it is impossible to strive. Without some objective, all the effort seems pointless and a waste of time. After all, if the effort doesn't get you anywhere, why bother? Thus, a goal concerns a destination, and this destination must be some place or some state that you really would like to achieve. This could be losing weight, getting a higher score, or delivering a product, but the goal provides a concrete objective toward which to strive.

Another way to think about goals is in the negative. A key reason given when the presumed better competitor loses in boxing, track, or any other sports competition is that he or she did not want to win badly enough. Similarly, in building products, it is widely accepted that when people don't strive to build quality products, they generally won't. In fact, they really cannot. Challenging goals are not achieved by mistake. If you don't consciously strive for them, you almost certainly will not achieve them.

So, goals are not just an invention of management, they actually satisfy a fundamental human need. The goal defines our purpose: why we are here, why we are working, or what we intend to achieve. Simply put, without a goal, you cannot succeed and, if you cannot succeed, why try? Goals are the motivators for human endeavor. They energize our lives and our work. They give us purpose. Achieving a goal provides a sense of achievement and satisfaction. Goals are important to people and they are even more important for teams.

Teams need goals for all of the same reasons that individuals do. In addition, goals provide a common working framework for the team. The goal is something that everyone agrees on and can cooperatively work to achieve. The goal helps to resolve issues. Does this activity move the team toward the goal or would something else be more effective? If some action does not help to achieve the goal, why bother doing it? After achieving a goal, the team members have something to celebrate. It was hard work, but they brought it off. It was a team achievement and everyone shares in the celebration and in the credit.

Without a common goal on which all members agree, you have a loose collection of individuals who share only a common trait or facility; you cannot have a team. It would be hard to imagine an athletic team where the members did not all share a common goal, agree on precisely what that goal was, and know exactly what the score was at every point in the play.

Next Steps

The non-tech skills of software development project managers

Dig Deeper on Topics Archive