Home > Articles > Programming

An Interview with Watts Humphrey, Part 32: International TSP Use and the Trouble with Knowledge Work

In this transcript of an oral history, Grady Booch interviews SEI Fellow Watts Humphrey. In Part 32, Humphrey discusses the use of TSP and PSP in other countries, why knowledge workers need to learn to manage themselves, and how TSP can give engineers the power and credibility to negotiate with management.

This interview was provided courtesy of the Computer History Museum.

See the entire interview.

Like this article? We recommend

International TSP Use

Humphrey: So there's no question this stuff [PSP] works and, as I say, what's frustrating to me is with all of that data and all the absolutely rock solid evidence we've got, why is it that people aren't just saying, "Oh, yeah, we've gotta do this and we're not." And so that gets me to another one of the things I wanted to talk about.

Some of the other countries, by the way, we're working with: we've got interest from Turkey, some companies and the national government there is starting to work with us. South Africa, actually, it's quite an effort there. There's a major effort under way in Colombia, South America. They had our folks down there and they want to launch a big effort. We've got something in Mauritius, I mean, so it's kind of popping up in a lot of places, and a lot of these countries want to get in on the act. The software industry is a very attractive industry and, by and large, most of them know that you literally can't undercut the cost of labor. If people really want to buy by the hour, India and China are probably lower than most everybody else. Some of the African countries may be able to get lower rates at some point, but I think everybody's beginning to realize that the Toyota strategy is a hell of a lot better than the China strategy in terms of really getting in there and building an industry. Build a quality business, build on performing and doing what the customer wants. As you probably know, Toyota got way ahead of U.S. industries from a quality perspective, and it took a U.S. industry about 20 years to wake up, and once they got started, they still haven't caught up. Toyota keeps improving, and the other people can't catch them, and that's why GM is now a smaller company than Toyota, which is kind of astounding. These people, basically, that's a history that they see and they say, "Hey, maybe we can do that here." That's what we’re beginning to see.

As I say, I'm terribly frustrated that there is essentially no interest in that in the U.S. Even the academic side, the government side, industries are all looking at it very narrowly. And I had some experiences with a couple of big companies, one of which we know well. The big software contracting companies that go out, and they do body shop work -- contract software work. They run facilities. And basically, I talked to them, and the reaction that I got was -- these are from senior executives in both companies -- basically, they asked me, “You mean you want me to spend profit dollars to cut revenue?” And that's staggering. Well obviously, when you do quality work, you do it right the first time, people don't pay you for doing it wrong and then fixing it. So it actually does reduce revenue, there's no question

But I contend that any executive worth his salt, or any business that wants to look at the future, the choice they've got is whether they want to be the GM down the road, or the Toyota. And I think the choice is pretty clear cut, unless you've really got very short-term vision. And so that is, as I say, terribly frustrating, and what's most frustrating is, I get that from DOD contractors as well, these great big companies. I've gotten this from several of them. They basically say, “We can't afford to do it.” I think the lower level managers, that's true. The lower level management really can't afford to take money out of their profit pocket and actually end up better controlling their costs, cutting their revenue stream and that sort of thing. Even though it would improve their competitiveness and certainly help the national economy, and certainly the defense business, they just aren't willing to go into it, and they don't feel they can fight it through their own management. And that's a real risk and a real problem for the future of our country.

Knowledge Work

Humphrey: The question of why the TSP works is an interesting one. You've, I'm sure, heard of Peter Drucker.

Booch: Oh yes.

Humphrey: Died a couple of years ago. I've heard him talk on a number of occasions. I've thoroughly enjoyed his books and papers. One of the things he has said, and he's talked about it for a number of years now, is knowledge work. He talks about the knowledge workers, and he makes a point, which I think is enormously perceptive. He fundamentally says you can't manage knowledge workers. They have to manage themselves.

Well, what's astounding to me is, first, that's a terribly perceptive point, and second, no one has picked up on it anywhere. Everywhere you turn someone says, “Sure, that's true. They've got to manage themselves. Let's have them manage themselves. Great!” But the knowledge workers don’t know how to do that. So it's a fundamental change in the whole management system to do that. And Peter Drucker clearly thought through that, but he wasn't in a position to go do it and make it happen. And so that's the question that I have been struggling with regarding the TSP and the PSP. The question I had, and I think I mentioned when I started with the CMM and then moved on to the PSP and TSP, was to look at how would individual developers really do software if they did it right? And a big part of that was learning to be a personal manager, learning to make your own schedule, track your own progress, to manage the quality of your own work, to make commitments and to consistently meet them.

How could individuals do that? That's the framework on which the TSP and PSP are built, giving people the tools to do that. And as you probably know, most software folk, you tell them to do something, unless they really know how to do it, they'll probably put it off. As I think I mentioned in my IBM story, the software people had an enormous number of things they had to do, but there were only two they really must do before they could ship a product. That was code and test. So they never got around to anything else. That's exactly true of the software community. You tell them, “What you really need to do is get your requirements nailed down and do inspections and do all this and that.” And the question most of them have is, “Well how do I do that?” They by and large don't know. They've never gone through that. They don't have a framework to do that. They don't have a process or guidance on how to do it. Hard to find people who can. So they start off coding. I mean, they start off trying to put together a design. They start doing what they know how to do. They don't have time to play around.

And that's the issue we run into in the software business. The people really are so busy, they're under such enormous pressure, that they just can't take the time to figure out how to do something. And that's very obvious. I mean, I sit down and I've got all kinds of data on how long it takes to develop a process, and the TSP process that I developed, with all the guidelines and the scripts and stuff like that, was several hundred hours of work. And I'd been developing processes for years. Software developers just don't have the time to do that. They'll use what they can get their hands on. They're very pragmatic. They'll use my process if they know about it, and they're convinced it will work.

Every time I wrote a program with [PSP], I would sort of modify it and update it, so when I write programs, I want to change the instruction set. When I work and use a process, I like to fix it and adjust it. I don't change it on that particular project, but I'll make notes and I'll go back and fix it.

And so I'm constantly evolving my process, but I find engineers don't do that. By and large, they use whatever process they have got. If it works, they're happy and they use it. So we learn from it when people use our processes, and we update them to make them more convenient. But the developers won't do it. They aren't willing to take the time. They don't have the time. And so fundamentally, this whole idea that “just tell the developers to manage themselves,” managing themselves takes a lot of work. People have got to be able to find out what their requirements are. They've got to understand what management's goals are. They've got to put together an overall plan and strategy for how they're going to do it. They've got to negotiate their schedules and commitments with management, all of that stuff. Then they've got to do the work and they've got to track their progress, they've got to handle it.

There's an enormous number of things, and without guidance on how to do that stuff, they can't do it. And by the way, they also need room from management. Management has got to really take the time to meet with these people and say, “Here's what we want and why.” That's what the launch process does. It's extraordinarily effective. The whole idea of it is to actually give the developers and their teams the power to figure out what it takes to do the job. And so when management assigns a project to a team, the team goes off and takes several days to put together a plan to do it, and they really crawl through it and they do a thorough job. They've got historical data, either on their work or other teams, and stuff like that. And they'll go through and make a plan.

More Example Projects

And when they've finished, they know what it'll take to do the job, and they have so much confidence in what they've done, and so much conviction, that when they present their story to management, management doesn't argue with them. I mean, basically, these people know. They've got the conviction. Management is universally impressed with the teams when they come back. They've got credibility, so they negotiate with management. The teams always end up winning, and they've done that time and again. I remember one case, this was a good many years ago now, it was a team at Ford, the Ford Motor Company. It was a small team. I don't know if they're still doing it or not. I think they've got some people that may be, but I'm not sure. But I haven't been in touch with them for years.

But in any event, this team had started a project. I think there were five engineers on it. Management had gone through with them and given them the goals, the goals where you had to get this done in a year. Well, it turned out to be an enormously ambitious project, and the team basically went through it.  The management reason you had to have it in a year was, they had a market window and they had cost limitations. And the team went through this thing and came back and presented the story to management and said, “Look, with this team, this will take five years. If you want to put twenty-some people on it, we can probably bring it in a lot closer, but no way we can get to a year, and here's what we've got to do.”

And they went through the story and that sort of thing, and so management said, “Let's think about that,” and then they canceled the project. Well, that's an enormous success. What teams typically do is management tells them they've got to do it in a year. “Okay, chief.” Then the team will say: We'll try.” And they'll break their hump for about eight or nine months, and the management says, “Where are you?” and they'll come back, “Oh, it'll be another six or eight months.” And so the delay will keep going and they'll lengthen the schedule. After about two and a half years, they will have gotten where they're working under enormous pressure. They don't do the work right. There are all kinds of problems. Then they kill the project, and they waste a lot of money, they waste a lot of the engineers' time. Nobody wants to do that.

So having reality on the table right away, by and large, with very few exceptions, that works. We do run into a few cases. I remember one case in one company, which I won't name, the senior vice president had basically given a directive: “You'll get this project out by this date.” I was there talking to the management team. And they were scared to death, because this VP was unwilling to come to the lab and talk to the team. He was unwilling to listen to what they were doing. It was all done remotely. And the last time somebody had gone back to him and told him they couldn't do it, they fired him.

So they finally concluded there was no way they were going to do this. This guy was dealing through a pipe. He didn’t have the guts or self-confidence or something to deal with his people directly and he was totally unreasonable. And so they did. They basically did not use the TSP, and about a year and a half later, the lab director was fired, and so was the VP. I mean, this sort of thing goes on all the time. It's crazy. And so you do get a few nuts like that in the management chain, but not too many. Most of them are smart enough to know that when the team really says they can't do it on this schedule, that's probably true. The problem is that few teams know enough to say they can’t do it on management’s schedule. If they did, then we wouldn’t have so many disasters.

So the point I'm making here is that the teams discover that when they have data and they have facts, they can talk to anybody. I mean, we've had cases where brand new engineers, with a year or two of experience, going through this stuff, will explain to a senior vice president something, and the senior VP buys it, because the engineers have the data and they understand what they're talking about, and they've got conviction. And so what these engineers discover is, they've got enormous power that they never had before, and they're able to actually negotiate schedules that make sense. Their work is a hell of a lot more fun. They work at a reasonable schedule, and it works. It works extraordinarily well.

Let me talk about one case in India, one of the Microsoft projects. They'd done a great job and I was there reviewing their results. And it turned out when they'd launched the project, they had just come off a previous project which was an absolute disaster. They worked 70-hour weeks, they were late. The project had all kinds of problems in test. It was a mess. And so they decided to learn the PSP and do the TSP on the next project. So this was the first TSP project that they'd done, the very first one.

And so in the launch, the team had gone through and said, “We've got a team goal of working 40-hour weeks. We're also obviously going to meet the schedule and all that sort of stuff.” I was reviewing the results of the project. They said, “We didn't quite make our goal. We worked 45-hour weeks on average, but it was a hell of an improvement over 70.” They were home for dinner. It was an experience they enjoyed. It was great. They delivered on schedule to test. The product sailed through test without any particular problems at all, and the team was just terribly excited about it.

And so we see engineers, software folk, all of a sudden becoming heroes instead of bums. And these people deserve to be heroes. They're bright, they're capable. They do marvelous work, but at the moment, they are suffering under this cloud, because they really don't have the skills to manage themselves.

And the reason this is an important issue is because -- this is back to Peter Drucker -- the first real large-scale knowledge work was in software. And I'd always wondered, years and years ago, when I started, I'd done all the hardware stuff. I could manage 30, 40, 50 people doing hardware work. I could walk around. I knew where things were. I didn't have any problems. But even with a team of ten software people, unless I was really willing to take the time and really sit down and go through with each one what was going on, there's no way I could know what they were doing.

And furthermore, as Fred Brooks once said, they're 90 percent through coding most of the time. The software people have no idea where they are typically today. So you go ask them where you are, and they'll go, “Oh yeah, I'm on schedule. I'll be in to test shortly,” and that sort of thing, and they literally don't know when they'll be done. So all of that, the lack of skills and all of that, we end up with people who have no credibility with their management. They end up getting pushed into commitments they can't meet, they're failures. They'll work god-awful hours and we see that throughout the field. It is not the kind of industry that is going to be healthy and growing over time, the way it's being run today.

Booch: I do have one question, and that is, you spoke about not really being able to know when they're going to be done. That triggers a thought with regard to Barry Boehm and his work on economics. I'm wondering what connection you might have with Barry's work.

Humphrey: Oh, I've been involved with Barry. I know him well. Certainly his book on software economics, I've used that. At the beginning, I used it in writing my Managing the Software Process book 20 years ago when I first joined SEI. So I've enormous regard for Barry, and actually, he has had some people teach the PSP in his program. I'm told he's familiar with it, although again, the same thing, they don't have the same kind of commitment to it that we do, because they don't have that experience. So Barry has been a supporter, but as I say, he's not really on the inside making it go. He's got other things he's committed to. Okay?

Booch: Got it. Very good, thanks.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020