NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: August 1, 2009
This is the fourth in this series of columns on being your own boss. In the first two columns, I discussed ideal jobs and autocratic management. Then, in part III, I talked about knowledge work and why only the knowledge workers can competently manage their own work. The key question remaining at the end of part III was: How can we take charge of our own work? That is the topic I cover in this and the final columns of this series.
When I ask software developers about the issues they face and the problems that typically cause their projects to fail, I hear lots of complaints. There are many reasons why our projects fail, and we typically blame somebody else for the failures. Management gave us an impossible schedule, the customer changed the requirements, the organization has an impossible bureaucracy, or there are too many meetings and distractions. This is victim talk. Have you ever heard a first class surgeon, a top flight scientist, or a winning ball player talk like this?
Winners win; they don’t complain. It is the perpetual losers that complain about how unfair life is and how somebody else is always to blame for their failures. While it is true that software development is a challenging business and that we almost always face tight schedules and changing requirements, these problems can be managed. However, they can be managed only if you know how to manage them.
You might wonder why more software professionals don’t manage themselves, and why essentially all software developers act like victims. These smart and capable people seem willing to spend their lives behaving like losers. The principal reason is that nobody ever showed them how to break out of their victim trap. The second and almost as important reason is that, even though self-management methods are not that difficult, they are not obvious.
The alternative to being a victim is to take charge. There are two parts to doing this. The first is the hard part: actually taking control of your own work. Then, once you know how to manage yourself, the second part is much easier: convincing management to let you manage yourself. The rest of this column discusses the first part, and in the next column, I describe how to convince management to let you control your own work.
There are five principal steps to managing yourself, but they are not necessarily followed in linear order. Since all of these steps are interdependent, you must treat the entire process as cyclic. The principal reason to follow a cyclic strategy is that you will almost certainly make mistakes the first time, and with a cyclic strategy, you can quickly identify and correct these errors. However, you will be surprised at how quickly you will learn and how, assuming that you have a little guidance, you will do a good job of managing yourself the very first time you try. If you stick with the self-management process, your performance will quickly improve. In brief, the five basic steps to self management are described in the following paragraphs.
It is important to be clear about your goals and to make sure that these goals are ones that you are willing to strive to meet. With a little reflection, the importance of goals is obvious: if you haven’t decided where you want to go, you are unlikely to get there. Examples of process goals are “meeting commitments” or “building high-quality products.” If you don’t feel that goals like these are truly important, you will not likely strive to meet them. And then, of course, you will almost certainly not do so. The other part of establishing goals is to make sure that they are consistent with the problems you are trying to solve. That means when trying to demonstrate to management that you can manage yourself, your goals must relate to the self-management problem.
It is also important to be clear about the principles you will follow when using the self-management process. For example, one key principle is that it is always faster and cheaper to do the job right the first time than it is to build a poor-quality product and spend a lot of time fixing it. Another way to state this principle is that high-quality software products are always cheaper to develop and test than poor-quality products. Since few software developers truly believe this principle, it may not be one that you are willing to follow. Once you actually do follow it, however, you will be surprised to find that it is indeed true.
Another important principle is that, to meet commitments, you must plan and track your own work. An extension of this principle is that, to make accurate plans, you must know how long similar work has taken you in the past. This principle also relates to the first principle because poor-quality work is inherently unpredictable. While few software professionals will find this principle obvious, most experienced developers know that unplanned software work is rarely if ever delivered on time. The reason is that the key to making commitments is to only make commitments you can likely meet. And, of course, the key to making commitments that you can likely meet is to accurately estimate how long the committed work will take.
While there are many possible principles, it is important to be clear about the principles you intend to follow when you define your work processes, practices, and plans. Then, of course, you must consistently follow these principles while doing the work.
To consistently do competent work, you must define and document the process and plan you will use to do the work. While doing this, start the process with a planning step and conclude with a postmortem. Also define the measures you will use to track your work as you do it. This is essential so that you can analyze your performance during the postmortem and then have the data you need to make progressively better estimates in the future. Since you will need this information for the very next cycle of the job, you must start gathering it right away.
The process you define is not some vague document to be put on the shelf; it is a working document to use in doing the work. That means that it must be an operational process. That is, it must be sufficiently detailed and precise to guide your work. Only then can you measure and estimate the work, track your process, and know if you are on schedule every day. Furthermore, the only way to consistently meet commitments is to work every day to recover from whatever problems you had the previous day. To do this, you must produce a plan with estimates and schedules for every step. For more information on defining operational processes, see my latest PSP book [Humphrey 2006].
The second part of step three is to actually produce a plan for the work. Once you have a little historical data and an operational process, the planning task is straightforward [Humphrey 2006]. If you don’t have historical data, you will have to make some guesses. Usually, however, once you have used a defined and measured process to write even a few small programs, you can accurately tell how long such work has taken in the past. Then you can use these measures to guide the estimates for the next job. However, if you don’t have any data and, since unmeasured recollections are generally inaccurate, you must be cautious about over-committing. Again, my PSP book can help you in doing this.
In starting any job, use your plan to establish and negotiate your commitments. This, of course, is the bottom line. The key point to remember is that unless you make your commitments properly, you will rarely be able to meet them. That is why so many software projects get into trouble: few software professionals know how to make realistic commitments or to negotiate them with management. While negotiating commitments is not as hard as it might sound, it is not a trivial step. I will discuss it in more detail in the next column.
In doing the work, you must follow the process, gather the data, and use the data to plan and track this and all of your subsequent work. While this may sound simple, it is not easy to do, particularly the first time. That, however, is the reason that I developed the PSP process and course [Humphrey 2006]. While PSP takes a little effort to learn, it is really not difficult, particularly for competent programmers. A few people have completed PSP training on their own, but most find it is best to take a PSP course. The SEI offers such courses, but another and often more practical way to learn it is to convince your organization to have a qualified PSP instructor train you and your coworkers in PSP methods.
The purpose of this discussion is to explain why software professionals don’t manage themselves and to convince them to do so. The simple reason that few developers do this today is that, while the methods are relatively straightforward, they are not trivial and they are not widely taught in a typical software engineering education. That is a shame, because understanding and following these principles will transform your life. Instead of being a victim, you can actually manage your own work. And that is the key to turning any job into an ideal job. The next column concludes this series on being your own boss with a discussion of how to negotiate with management.
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Eugene Miluk and Said Nurhan.
In these columns, I discuss development issues and how they impact the work of engineers and their organizations. However, I am most interested in addressing the issues that you feel are important. So, please drop me a note with your comments, questions, or suggestions. Better yet, include a war story or brief anecdote to illustrate your ideas. I will read your notes and consider them when planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
Watts S. Humphrey, PSP: A Self-Improvement Process for Software Engineers, Reading, MA.: Addison Wesley, 2006.
Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and 11 books. His most recent books are Winning with Software: An Executive Strategy (2002), PSP: A Self-Improvement Process for Software Engineers (2005), TSP, Leading a Development Team (2006), and TSP: Coaching Development Teams (2006). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago. In a White House ceremony in 2005, President George W. Bush awarded him the National Medal of Technology.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.