Roundtable Interview on PSP/TSP


This library item is related to the following area(s) of work:

Process Improvement

This article was originally published in News at SEI on: June 1, 1999

This article captures an exchange of ideas among people who conduct training in

the Personal Software ProcessSM (PSPSM) or Team Software ProcessSM (TSPSM)

for either academia or software development organizations, or who have

conducted research related to PSP and TSP:

· Robert Cannon is a professor of computer science at the University of South

Carolina and is currently a visiting scientist at the SEI, working in the Process


· Gina Green is an assistant professor of information systems at Baylor


· William Hayes is a member of the technical staff at the SEI, working in the

Software Engineering Measurement and Analysis (SEMA) group.

· Alan Hevner is an eminent scholar and professor in the Information Systems

and Decision Sciences Department in the College of Business Administration

at the University of South Florida.

· Thomas Hilburn is a professor in the computer science department at Embry-

Riddle Aeronautical University, which offers an undergraduate degree in

computer science and a master’s in software engineering.

· Robert Pauwels is the commercial training director for Advanced Information


· James Tomayko is director of the Master of Software Engineering program at

Carnegie Mellon University.

Topics include

· experiences with PSP and TSP

· the reception of PSP and TSP; contributors to their success

· overview of a new SEI special report featuring PSP

· the importance of maintaining teams for training and later project work

SEI Interactive, 06/99 page 2

· the challenge of diffusing PSP into the workplace

· the need for management persistence

· lessons learned from PSP and TSP training

Experiences with PSP and TSP

Bill Thomas (BT) (Moderator): The idea of this Roundtable is to have a group

discussion about your experiences with training engineers to use the Personal Software

ProcessSM (PSPSM) and Team Software ProcessSM (TSPSM), and to get an idea of how

engineers and—for those of you in academia—students receive these new ideas. To start

with, give us a brief description of your experience with PSP and TSP.

James Tomayko (JT): Watts Humphrey used my graduate students at Carnegie

Mellon as guinea pigs for the first PSP course back in 1994. Their data appears in his

textbook, A Discipline for Software Engineering [1995]. We’ve been using PSP since

then and we require it prior to students arriving on campus. After they’re admitted, I send

them a package of CD-ROMs with lectures and other materials about PSP and TSPi.

They take the course before they get here because we use TSP on all of our project teams

in the software development studio. The studio is 40% of the curriculum for the year. We

had one team last year and four teams this year.

Thomas Hilburn (TH): When Watts was first developing his original PSP book, he

was on the Embry-Riddle advisory board and he convinced us to try out the draft that he

was working on. One of my colleagues taught it. We thought it worked pretty well and

it’s now part of the core—the first courses that entering master of software engineering

students take. We’ve been using it for about four years.

A couple of years later, Watts was convinced that maybe we needed to introduce PSP at

an earlier stage, so we also used an early draft that he had of the Introduction to PSP,

sometimes called “PSP Lite,” in our freshman sequence of courses. We’ve been using

that for about three years with some modest success.

Last year, we started using TSP in the junior/senior-level course Introduction to Software

Engineering, which is a broad-brush course with a project. For the first time this

semester, we used it in our undergraduate senior design course.

I also worked at the SEI as a visiting scientist a couple of years ago in the process

program and worked with Jim Over and Dan Burton, helping to develop some of the

instructional material for the first PSP courses. I sat through the instructor’s course. For

SEI Interactive, 06/99 page 3

the last couple of years at Embry-Riddle, with the help of the SEI, we’ve developed and

delivered a one-week summer workshop for faculty on PSP. Some of my colleagues have

worked with Motorola and Boeing and several other organizations, helping them

introduce PSP into their workplaces. I’ve had some involvement with that.

Robert Pauwels (RP): Advanced Information Services got involved with PSP in 1994

when we were looking for answers on how to apply the Capability Maturity Model® for

Software (SW-CMM®) to small software projects or small software teams. We had been

struggling with CMM. Watts Humphrey recommended that we take a look at PSP as a

way of trying to progress and solve some of the issues. I was involved with the initial SEI

train-the-trainer course in fall 1994. It’s a required training course for our software

engineers and project managers at our organization.

Currently, we have two sides to our business, the development group and the consulting

group. As of yesterday, we have 100% of the people in our development group trained.

Training in our consulting group is a little bit more spotty. We’re trying to solve the

issues in terms of how to get people to use PSP effectively when they’re the only people

who have been trained in it and when they’re off working at a customer site and the

customer has very chaotic processes, if anything at all.

At this stage, we have not utilized TSP, primarily because it was not around in 1994

when we were dealing with the issue of how to integrate PSP into our software

development work. Somewhere down the road, we will give it a shot. It’s a timing

issue—we’re trying to figure out which project to introduce it with.

Robert Cannon (RC): My first PSP training occurred in South Carolina, through the

South Carolina Research Authority. I was trained at an industrial site, which is fairly rare

because most PSP instructors have actually been trained in Pittsburgh. There was a

special arrangement that allowed some instructors to be trained off site. Since then, I have

taught the PSP class at my university. I intend to do that again in the fall and follow that

with a Team Software Process course in the spring.

I had a tremendous opportunity this year to work with the PSP/TSP group. I’ve been

involved in teaching virtually every one of the PSP and TSP offerings at the SEI. The

opportunity to work at an industrial site has been extremely valuable for me. I’ll be the

coordinator for a summer faculty workshop, where we’ll be doing essentially the same

course that Tom did for the last two summers to train faculty to teach PSP. We’re also

going to have a separate workshop to help faculty plan to introduce TSP into their

curricula, or at least to give a course based upon the new Team Software Process book by

Watts Humphrey.

SEI Interactive, 06/99 page 4

William Hayes (WH): I’ve been working with the PSP initiative as a member of the

SEI’s Software Engineering Measurement and Analysis (SEMA) Group to help collect

data initially from the training courses and now from the field where engineers are using

PSP on the job. I’m helping to characterize the impact, using some fairly rigorous

statistical techniques, of what happens when you use the technology.

I’ve had occasion to visit with and interview a lot of folks in industry. I’ve also gone

through the training myself and am currently applying some of the methods to my work.

Though I don’t develop software, a lot of the discipline methods and data-collection

techniques are actually quite applicable to a variety of settings. I’m using it in the impact

study work that I’m doing now.

Alan Hevner (AH): I’m a professor at the University of South Florida. I started getting

interested in PSP because I taught a little bit of it in my classes at the graduate level for

master of science students. I didn’t get into the full-blown course, but I did show it to the

students and it was quite interesting to them. Then when I started working with Gina

Green on her doctoral dissertation, we selected PSP as an innovative technology to study

our research model.

[Editor’s Note: The SEI special report “Perceived Control of Software Developers and

Its Impact on the Successful Diffusion of Information Technology” by Alan R. Hevner

and Gina Green is based on the doctoral dissertation to which Hevner refers. The report

is available at:


Gina Green (GG): As Al said, PSP was selected as the innovation that I wanted to

study in my doctoral dissertation, which looked at software development technique


The reception of PSP and TSP; contributors to their success

BT: From your perspective, how are PSP and TSP being received by software engineers?

For those of you working with students, how would you say they are being received by

students? Also, could you describe some of the circumstances that contribute to success

with those groups.

JT: I’ve been finding that by spending a lot more time at the very beginning, explaining

how we’re actually teaching the process—we’re not really teaching the programming

style—people are a little bit more oriented toward picking up the points. There is a lot of

process for relatively small problems during the training. Sometimes the students focus

SEI Interactive, 06/99 page 5

on that instead of seeing the end result. We’ve had some problems giving appropriate tool

support for PSP. Our spreadsheets haven’t been that good, but that’s probably our fault.

On the other hand, using the TSP spreadsheet program that Jim Over developed—and

which is still being developed now—has worked very well for us. The detail I get from

that has been exceptional. Since we have a collaborative tool that we use on the Web to

keep track of all of our data and products within the various projects, the mentors at the

SEI and myself can see what’s going on at any given time. We put those spreadsheets out

there so that we can see each cycle—we can see how things are going along. We can see

earned value, actual and predicted, the amount of time they’re spending, how good their

estimates are. I can, on an individual basis, tell how somebody may have messed up in

underestimating or overestimating. Then we can talk about that because we have regular

meetings with individual students. So, we’ve found in cases where there are tools

available and where people understand that they’re learning a process, it seems to be

pretty successful. If you leave them to their own, to invent their own tools or to spend too

much time concentrating on the problems themselves, that doesn’t seem to work.

TH: We’ve worked quite a bit with Motorola. During training, the engineers accept it

very well. I’d say 90% of them think it’s great and they’re able to complete the PSP

material. The difficulty comes on the job: they’re going into embedded systems, trying to

apply PSP or use it for maintenance. Adapting it to their job has been difficult. Some of

our faculty have worked to help them, mentor them, support them, and coach them.

That’s helped, but that’s the difficulty, actually bringing it into the workplace. This is a

place where management supports PSP. There were similar problems at Boeing. In the

classroom setting PSP, at the graduate level, goes over pretty well. Then we ask students

to use it in some other courses. It hasn’t always been that effective. In the freshman-level

course, we struggle with how to motivate students and produce pretty good results. The

problem in our freshman courses is that students can’t really see the improvements that

you get in a typical PSP course. The training effect has been pretty good, but the followup

in using it has been a little bit of a problem.

We started using TSP about two years ago and did two graduate student projects. Watts

came down and helped us launch development of a new scheduling program for our flight

line. We did a database program for the county assessor’s office. They were both very

successful. They used early versions of the TSP and I think students really started to see

the value of PSP. I’d say those were successful and students were able to follow the

process and use the process to their benefit.

Software engineering is a junior/senior-level survey course. It usually has some sort of

team project involvement. I’ve been doing this for about eight years with marginal

success. I used TSP last fall and it was the most successful as far as students learning to

work as part of a team to develop a piece of software. In this case, it was a toy project,

SEI Interactive, 06/99 page 6

using Watts’s new text, Introductory TSP. I did two anonymous surveys. The students

still didn’t like filling out all the forms and collecting all the data, but they grudgingly

admitted that it was worthwhile to do that. I did hear comments from a number of

students, “Now I see why we study PSP.” It has been, I think, a grand success so far.

RP: Our own organization reached the stage of institutionalization about two years ago.

Not too many things are questioned anymore in terms of what we’re trying to do with

PSP and the engineers’ acceptance of it. Everyone in the organization is doing it on the

projects that we have management control over. Obviously we’ve got strong management

ownership and support to make sure that it gets done. We’ve done quite a few things to

integrate PSP into our culture to where, I think, the engineers really appreciate it, even

though they still don’t like filling out some of the forms. They really do appreciate how it

helps them during the development work.

My experience has been in working with our own software development staff and with

outside organizations. It’s not uncommon at all—especially for experienced engineers—

to be resistant, early on, to all the planning and all the forms you’ve got to fill out. But

90% of the time the data that’s being collected and the feedback they get from that tends

to turn the disbelievers into believers by the time the course is over. We recognize that

there’s a certain class of people who will never buy into these things no matter how much

you try to convince them.

The theme of filling out forms seems to be a common, recurring issue. During PSP class,

I have to spend time reintroducing most engineers to what a pen and pencil are. I had one

engineer claim that he would get hand cramps from filling out the forms. Even though the

course gets better and the support tools get better, there’s still room for us to work on

things and to make them even more acceptable. To a certain degree, a tool will ease that

transition for people.

Other interesting reactions I get from students—especially as I start working with

organizations that are much larger than our own—is that although many of them

understand the value of PSP, they have total disbelief that their management will be able

to successfully pull it off. They think that everything will go fine until the first schedule

crunch comes around, and then managers will tell them to push all of this stuff aside and

get back to it some day when they have more time on their hands. Organizations of that

size are not far enough into implementation yet to find out whether or not that’s actually

going to be the case.

AH: In our survey, some people said they felt that in their training they received some

reasonable tools and other people developed their own tools. We also got a number of

comments like, “We can’t be very productive with this unless the managers and

development team agree on a set of tools that we’ll all use.” So, there is still some flux in

SEI Interactive, 06/99 page 7

the field about what are the right tools and who should supply those tools.

RP: I think a certain class of people who put tools as the show-stopper may come from

that 10% of the people who just don’t want to do it. They’re searching for excuses. On

the other hand, I think we can appreciate that handy tools make it a lot easier for the

amount of data that PSP wants us to collect.

RC: About half of my students would come and say, “I’ve really learned something

about myself and about the way I tend to work.” There were others who would never

really want to use PSP unless they were in an environment where it was expected of

them. I taught an industrial course, where unfortunately there was little management

support, for programmers who didn’t work in the traditional programming environment.

They were not all familiar with even C or Java or Pascal, for example. They kept insisting

that because the problems were irrelevant to their work that they couldn’t see why they

should be doing it. The effort to motivate and say “We should all be working on common

problems to collect data” was not one that was effective with them. If I ever worked in

such an environment again, I’d want to be very careful to determine with management

that they’re much more supportive. In teaching an industrial course here at the SEI, I

found a very positive reaction to PSP by an extremely skilled group of programmers.

WH: I’m a research guy, so neat models that involve data easily catch my interest. It

seemed logical that the software industry would want to take this up—why wouldn’t they

want predictability? But it’s very difficult to really be honest with yourself and to instill

that discipline to change the way you work. It means recognizing that you’ve got to keep

your attention on it—you can’t take a holiday from it. But to be that attentive to what

you’re doing requires a tremendous amount of concentration and discipline. I found it to

be a very big challenge to use these methods. When I’m interviewing people in the field,

I now have a different appreciation for what they’re doing. I really enjoyed the course,

though I struggled to complete it. It was very difficult for me to complete it.

I’ve seen people succeed very well with paper and pencil—they don’t need a tool. I’ve

also seen people with the greatest tools who don’t collect the data because they don’t

want to be honest with themselves. I’ve seen people who were the only PSP-trained

people in a chaotic group project and still hold on. I’ve seen groups of people working

together who really benefit from having each other to talk to. At the same time, within

organizations where there are groups that are successful, you’ll find other engineers who

struggle initially to try to keep the data, try to keep their investment in what they’re

doing. But when a management fire drill comes along, the message comes to them very

clearly that spending time collecting data and getting better as a professional is not a high

priority. Making this delivery is a higher priority. Senior management and middle-level

managers can make that message very clear to engineers without having to be very

SEI Interactive, 06/99 page 8

explicit about it. That’s one of the things that really gets in the way. I think the comments

we’ve heard thus far really support that as well.

TH: I think there’s a little too much emphasis on the need for tools. I think tools are great

for computations and rolling up the data. That’s not the hard part. The hard part is that

discipline—that relentless, continuous observation of the way you go about your work.

Recording the time and defects just requires attention to details.

RP: Time tracking seems to be one that most organizations and engineers have a lot of

reluctance to. They claim that they’ve got to have some sort of stopwatch tool in the top

right-hand corner of their window or monitor or they just can’t do it. It is perceived as too

much overhead to write down on a sheet of paper something like, “It’s 1:40 and I’m

starting to code.”

Overview of a new SEI special report featuring PSP

BT: Al and Gina, in your research on the diffusion of information technology you

surveyed software engineers about their experiences with PSP. Could you summarize that

project and your findings?

AH: We were interested in looking at some of the behavioral issues of what happens

when new technology gets put into place in organizations. Most people have looked at

end-users of technology. We wanted to look specifically at software development groups

and individuals and analyze a good innovative idea that they were using. We came on the

idea of using PSP because of its newness to the market and the idea that it was an

individual type of technology as opposed to a group or a team technology. Most of the

past research was on individuals, so this would allow us to relate what we found to some

past research in this area. The model that we developed is in the SEI special report.

GG: From a theoretical standpoint, one of our key findings is that a software developer’s

sense of personal control in the software development process is very important. In fact,

we found that that was strongly related to the developer’s overall satisfaction with using

PSP and the developer’s use of PSP. PSP tended to provide a pretty high sense of

personal control to the software developer. That was good news from a theoretical

standpoint. From a practical standpoint, we chose PSP because there was a lot of interest

in it, but we found that the actual use of PSP was not as widespread as we had


AH: We wanted to find people who had used PSP on at least one actual development

project for at least three months and not more than two years. That made the use of PSP

an innovation. With that constraint, we eventually got good surveys from about 72 users.

SEI Interactive, 06/99 page 9

GG: The survey respondents indicated that PSP did, in fact, improve the quality of the

software that they developed. In addition, they felt that PSP made them more conscious

of quality-related issues in software development. This means that PSP is fulfilling some

of its intended goals, at least as far as the respondents’ perceptions go.

The importance of maintaining teams for training and later project work

BT: I want to ask a little bit about the issue of people being trained as a team and then

using PSP for projects together. What do you think is the importance of keeping team

members together both in the training and then in the project work?

JT: I think it’s really critical. It’s a way of getting positive peer pressure. I don’t know if

“pressure” is the right word—maybe peer acceptance might be a better word. When we

introduce PSP, there are some who want to do it right away and some who don’t want to

do it. There are some who sort of will do it if everyone else is doing it. Of course, we

have a clear advantage in that I can just order everybody to take the course. I could even

pay attention to whether they’re using it later. But I still think that they’ve been much

more effective when they could use it as a group, when they could talk to each other in

the same language.

AH: We found in our survey that if developers felt that their training was individualbased,

it was difficult to implement because their work was team-based. Just looking

specifically at PSP, developers found that there was a disconnect between individual- and

team-based training.

TH: Watts Humphrey’s new TSP book works very well concerning some of the

beginning mechanics of building an effective team. In industry or academia, these team

projects often don’t have a process. They may have an organizational process, but not a

process that’s attuned to teamwork. TSP guides you through some elementary things that

you’ll want to do in the beginning, launch, planning, and strategy phases as a team.

Students can look ahead through a whole project and have some idea of what they’re

going to be doing week by week. This provides some assurance and a basis for the team

to start understanding what they’re going to do and communicating about that. Like so

much of PSP, it’s really not that astonishing as far as the complexity. A lot of it is just

common sense and good guidance in a structured form. I think that’s as important as

anything else in building a good team.

RP: Our experience is that if you do not train people in teams, PSP will not be used.

Unless everyone on the team is trained—from the project manager through all of the

engineers, and especially the project manager, being the leader of the team—it doesn’t

get used. That’s generally a difficult and tricky thing to do because often organizations

SEI Interactive, 06/99 page 10

are reluctant to shut down a project for a month or so as they get a team trained. They’d

much rather steal one person from each of their teams and have them go through it. Then

a few months later steal another person from each of their teams and have them go

through it. Then, maybe, a year or so down the road, they can have everyone trained.

That, in itself, leads to all kinds of additional problems. It’s hard to pilot things like that

unless everyone’s ready to go at the same time. Our experience is that biting the bullet

and doing it in teams is the most effective way.

RC: I’d like to also mention the Introduction to TSP. I think that students can spend a

great deal of time figuring out what to do. To have their roles defined for them when they

begin is extremely valuable. We really only have a short time—about 16 weeks in a

semester—and that’s not enough time to get anything of significance done even in the

best circumstances. When you spend a few weeks just organizing and figuring out who is

going to do what, you’ve lost valuable time. The fact that roles are defined so that there is

minimal overlap helps a great deal. I believe that it would be true likewise for our TSP

groups in industry.

JT: The organizational aspects have been really important. We have a longer time—

we’ve got a year. The students do part-time in the fall and spring. They do about 12 hours

a week. Then, they do full-time during the summer. Because of the pressure of the other

core courses and electives and just getting organized, I was getting late deliverables. In

many years, deliverables that were due in December were arriving in April on many

projects. This year, I know that four teams used TSP for the first time and at the end of

the second cycle, which would be somewhere in November, we had more things done

related to the project that we normally would have had in April. That impressed me. All

four teams were more productive than all of the teams prior to them, except for a couple

of really outstanding groups in the past that were just exceptions.

WH: One of the components of PSP training that’s very powerful is the availability of

data, not just your own data, but a way of judging your own data by looking at the group

data. That team dynamic is an important component. Having said that, I have had

occasion to interview engineers in the field who were very nervous about anyone seeing

their data. I couldn’t find any reason, through interviews with other people in that

organization, that they should be nervous. Yet, they were nervous about sharing personal

data with teammates for fear that they would misinterpret the information. I’ve also come

upon engineers who have been using it for six months to a year and their first question to

me, when they hand me their data is, “Is this any good?” They’re not able to step back

and evaluate it on an objective basis, or at least they don’t feel confident in doing that.

So, having peers to interact with, who don’t threaten the protectiveness you might feel

over your data, is a very important part of successfully adopting the PSP. TSP is one of

the best mechanisms we can find to build in that peer interaction. You also have a coach

whom you might view as a mentor, someone of some seniority, whose opinion you

SEI Interactive, 06/99 page 11

respect. Having that person to help you analyze your data is a very important component

to the continued use of PSP in industry.

TH: There is a lot of emphasis put on analyzing your data, but I think that’s the most

valuable part: the self-analysis. I know there’s probably a fear that it’s used to judge the

effectiveness of individuals by management. I know that there are some groups in certain

organizations that try to dispel that. At Motorola, even though management has said that

they wouldn’t use it as a means of evaluating individual performance, they did want to

look at team PSP data. They decided that each team would elect a data security person

who would collect the data, roll it up, and answer questions about individual data without

associating it with individuals in a way that they could be identified. That is a fear and

it’s too bad because I think the data is very valuable for improving individual

performance and, in the long run, team performance as we figure out ways to get team

metrics. I’m not sure we have that yet.

The challenge of diffusing PSP into the workplace

BT: Gina and Al, the idea behind your research was to figure out why some of these

methods for developing software weren’t getting diffused more readily. In your research,

you discovered that PSP is not getting diffused as readily as it might. What do you think

is the reason for that?

GG: There are a couple of things. We found that the degree to which the actual software

engineers are involved in the initial decision to adopt a new technology—for example, to

bring in PSP—has an impact on how widespread the use is. In general, we found that the

degree of developer involvement was on the low side. That could explain some of the

reasons why the use is not as widespread as we thought. In cases where the involvement

by the developer is greater, we tend to find a greater degree of use of PSP by that


Another issue is training. It turns out that training is an important indicator of sustained

use. So, the degree to which the developer was able to receive quality training and was

able to have sufficient time to work on the training-related assignments also seems to be

an important factor in the diffusion.

AH: Some survey respondents said that a weakness of PSP was that it was difficult to

understand how to adapt it to a requirements stage and also to a maintenance stage. Some

people felt that their projects were primarily maintenance or the evolution of an existing

system. They weren’t quite sure how to adapt PSP to those types of environments.

GG: Another challenge was related to the whole issue of improvement in productivity.

SEI Interactive, 06/99 page 12

Respondents indicated that PSP did seem to provide them with improvements in software

quality as far as decreasing the number of errors. However, we weren’t able to show

productivity improvements through the results of the survey. Respondents said there was

a lack of immediate improvement in development productivity. I think part of that could

be due to the fact that we are talking about an innovation, so there is a learning curve.

The need for management persistence

BT: We’ve already heard that management support is critically important. What about

management persistence—the idea that management must not only support the effort, but

constantly encourage it.

AH: Regarding the amount of management support, or “champion support” as we titled it

in our research—we found somewhat equivocal results. It’s clear that champion support

is essential to get an innovation off the ground. But we also found a need for developer

involvement in the decisions to be made to bring that innovation in. Some people felt that

the champion was too demanding: “You will do this no matter what.” That took away

from the developer’s personal control or personal choice in the matter. One of our

recommendations in the report was that there is a fine line to be drawn between the

amount of champion support and the amount of user decision-making and involvement

on the developer’s side.

GG: On the issue of management support, you don’t want to do too much, but at the

same time, you don’t want to do none at all. There’s that fine line. As far as management

support for training, we had good news. Software developers seemed to believe that

management had provided enough time and funds for training. They felt that they had

enough access to PSP experts and felt that they had a fairly good network of support.

There is, however, the challenge that managers give them enough time to go to class but

not enough time to effectively work through the assignments. There was also a comment

about class sizes: classes might be more effective if they’re smaller.

TH: In the academic environment, it’s not so much the persistence of management as it is

the persistence of the faculty throughout the curriculum. You can’t simply teach it in one

course and then expect students to acquire some sort of disciplined process that they’re

going to automatically apply in other areas.

RP: In our organization, PSP was not brought in by an engineer or a project manager

who had to sell it up the management chain. It was brought in by the owner of the

company and pushed out, which has some obvious advantages. We changed a lot of our

management and organizational practices to be consistent with the use of PSP. We

developed software engineering policy statements, stating that these things were going to

SEI Interactive, 06/99 page 13

be used. We integrated it into our performance-evaluation system at both the engineer

and project-manager levels. Project managers have to report quarterly to senior

management about which PSP practices are being applied to their projects. We provide

support via PSP user group meetings at least once a quarter. Our organizational goals and

objectives include developing high-quality components, which indirectly relates to using

PSP in our development work. We decided that this was important to us, and that we

were going to have to change our culture to accept it. We really took a serious look at it

and changed things at the organizational level to support it all the way.

RC: When students write informal answers on a survey or a test, their writing looks

totally different from when they write about something that they’ve thought about. It’s as

if they write with two different styles. What we’re trying to do with PSP is to convince

them that there’s really one style of work. You don’t have a formal working style and an

informal working style. Your approach to the work is disciplined all the time.

Lessons learned from PSP and TSP training

BT: What are some lessons that you’ve learned from your experiences with PSP and


TH: I went through the PSP exercise one summer and it made me rather humble. I

thought I was a lot better software developer than I was. But it did show me ways to

improve and I saw improvement from the beginning. That’s the sort of experience you

hope all students and engineers who go through PSP training realize themselves. I have

also changed my view of the way I teach programming. Software development and

software engineering have changed dramatically. I hope I am much more of a coach and a

mentor and a supporter than I am just a lecturer or a one-way facilitator. When I was at

the SEI and sat through the engineers’ course, I saw people who had been programming

for 10 or 20 years who were struggling with some of these problems. The SEI does a very

good job in their afternoon labs of helping people plan and learn PSP and develop quality

software. I thought, “Here are some experienced engineers who are struggling with how

to develop programs effectively.” We just throw things at students sometimes—

especially at the undergraduate level—and expect them to develop their own effective

process. So, it changed my viewpoint of the way we’ve been educating our computer

scientists and software engineers.

RP: There are two lessons that revolve around the training itself and one that had an

impact on my associates and me. The industrial delivery of the course is a substantially

different professional training course than most of the courses you go to. This is not a 9-

to-3 type of course that meets for a handful of days for a light break away from the

normal workflow. This training is much more intense than what people are facing in their

SEI Interactive, 06/99 page 14

normal daily efforts. There needs to be a strong understanding of the commitment and

time it takes to get through the training and an effort to make sure people have enough

time to get through the assignments and realize the full benefit of PSP. Then, afterwards,

it’s important for people to understand that since this is not your typical professional

training course there needs to be some sort of vision. Why are we doing PSP? Are we just

throwing money at something, putting people into a class and hoping that productivity or

quality will improve afterwards? There really needs to be some sort of vision about

what’s going to happen on that day after class is over. How do we see things changing?

How do we want to see things change? What kind of practices do we expect people to

start incorporating into their daily work? We should set the expectations of it and make

sure the infrastructure is in place to support that.

The third item reflects more on our organization. For about two years before we got

exposure to PSP, we were trying to get a CMM effort going and we went through some

early growing pains with that. When I went into the PSP class, I thought I had a good

notion of what the CMM was all about. However, the CMM is really big on telling you

what you should do and says very little in terms of how you should go about doing it.

Going through the PSP class was an eye-opening experience. I started understanding

exactly what all these things in the CMM were about and how they related to one

another. It really showed me exactly how to do these things. By the time the course was

over, I felt that it was a total eye-opening experience in terms of what our organization

was really trying to accomplish at a much higher level.

RC: For me, the principal lesson has been to approach much of the work I do in a manner

similar to the way I learned to do things for PSP. I had never thought that I could work at

some things in such a disciplined manner.

RP: The other lesson learned from our perspective is that it works. We recently reported

that out of 148 components that were delivered to the customer over the past two years,

100 of them were defect-free. Our most recent project, which is now a month into

customer use, has about 80,000 lines of code and the customer has reported only four

defects. That’s clearly superior quality in terms of what most organizations are able to


Robert Cannon is professor of computer science at the University of South Carolina.

During the 1998–99 academic year he was a visiting scientist in the Process Group of the

SEI, working primarily on PSP and TSP. He has also been a visiting scientist with IBM

Corp. and at the Center for Automation Research of the University of Maryland. A

principal interest in recent years has been visualization of sedimentary processes, which

he has performed jointly with a team of geological researchers. He is a member of the

SEI Interactive, 06/99 page 15

Association for Computing Machinery and the Computer Society of the IEEE. He has

been active in computer science accreditation and was president of the Computing

Sciences Accreditation Board in 1998–99. He received the B.S. in mathematics from the

University of North Carolina at Chapel Hill, the M.S. in mathematics from the University

of Wisconsin at Madison, and the Ph.D. in computer science from the University of

North Carolina at Chapel Hill.

Gina Green is an assistant professor of information systems at Baylor University. She

holds a Ph.D. in management information systems from the University of South Florida,

an M.S. in computer science from the University of Pennsylvania, and a B.S. in computer

science from Southern University. She recently co-authored, with Alan Hevner, a special

report published by the SEI titled Perceived Control of Software Developers and Its

Impact on the Successful Diffusion of Information Technology (CMU/SEI-98-SR-013)

[URL to come]. During her professional career, Dr. Green worked as a systems engineer,

database administrator, and software development manager for IBM. Her academic

research interests include the diffusion of innovations, systems development methods,

project management, and complexity in computer-supported work. She is a member of

the Association for Computing Machinery, SIGMIS, and the Decision Sciences Institute.

Will Hayes is a member of the technical staff at the Software Engineering Institute. As a

research methodologist, Will participates in a diverse set of activities at the SEI including

empirical studies focused on the impact of technologies and methodologies in software

development organizations. As a member of the Software Engineering Measurement and

Analysis (SEMA) Initiative, Hayes provides consultation both within the SEI and to SEI

customers, in the area of measurement and empirical studies. He is an SEI-authorized

lead assessor and instructor of “Introduction to the CMM” and “Personal Software

Process” as well as “Implementing Goal-Driven Software Measurement.” He holds a

master of science in research methodology from the University of Pittsburgh, and a

bachelor of arts in psychology from Washington College in Chestertown, Md.

Alan R. Hevner is an eminent scholar and professor in the Information Systems and

Decision Sciences Department in the College of Business Administration at the

University of South Florida. He holds the Salomon Brothers/HRCP Chair of Distributed

Technology. Dr. Hevner’s areas of research interest include software engineering,

distributed database systems, database system performance evaluation, and

telecommunications. He has more than 70 published research papers on these topics. He

has consulted for a number of organizations, including IBM, MCI, Honeywell, Cisco, and

AT&T. Dr. Hevner is a member of ACM, IEEE, AIS, and INFORMS.

Thomas B. Hilburn is a professor of computer science at Embry-Riddle Aeronautical

University. After graduation from college, Dr. Hilburn served in the U.S. Navy and did

work in the area of computer navigation systems. In 1973, he received his Ph.D. in

SEI Interactive, 06/99 page 16

mathematics from Louisiana Tech University. Dr. Hilburn has taught mathematics,

computer science, and software engineering for 25 years and has received numerous

teaching awards. In 1991, Dr. Hilburn worked as a visiting scientist at the MITRE Corp.

in the AERA 3 group. He headed a project investigating the use of pattern recognition to

automate analysis of airspace complexity. In 1993, Dr. Hilburn served as a senior

computer science lecturer for ICAO, in Cairo, Egypt, and taught Ada and software

engineering to Egyptian engineers engaged in developing ATC software. More recently,

Dr. Hilburn completed a sabbatical in the Process Program at the Software Engineering

Institute, where he worked on the transition of the Personal Software Process to industrial

and academic organizations. Dr. Hilburn’s current interests include software processes,

formal specification techniques, and curriculum development. Dr. Hilburn is a member of

the ACM and the IEEE Computer Society, is the current software engineering category

editor for ACM Reviews, and serves on a number of professional and educational

committees for software engineering and computer science.

Robert J. Pauwels is the commercial training director at Advanced Information Services

Inc. (AIS). He has four and a half years of experience in Personal Software Process

education, consulting, and coaching. As commercial training director he is responsible for

working with commercial organizations in software process improvement and training.

He has 12 years of software development experience and has held other positions as

internal training director, project manager, and software engineer. He is an SEI

Authorized PSP instructor and delivers PSP courses to industrial organizations

internationally. In 1987 he received an undergraduate degree in computer science from

Rockford College. He is a steering committee member for the Chicago SPIN and is a

member of the IEEE Computer Society.

James E. Tomayko is a principal lecturer in the School of Computer Science (SCS) at

Carnegie Mellon University and a part-time senior member of the technical staff of the

Software Engineering Institute. He is the director of the Master of Software Engineering

Program in SCS. Tomayko directs the Software Development Studio for the MSE

Program. Previously he was leader of the Academic Education Project at the SEI, and

prior to that, he founded the software engineering graduate program at the Wichita State

University. He has worked in industry through employee, contract or consulting

relationships with NCR, NASA, Boeing Defense and Space Group, CarnegieWorks,

Xerox, the Westinghouse Energy Center, Keithley Instruments, and Mycro-Tek. He has

given seminars and lectures on software fault tolerance, software development

management and software process improvement in the United States, Canada, Mexico,

Argentina, Spain, Great Britain, and Brazil. Tomayko’s courses on managing software

development and overviews of software engineering are among the most widely

distributed courses in the SEI Academic Series.

SEI Interactive, 06/99 page 17

The views expressed in this article 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.

The Software Engineering Institute (SEI) is a federally funded research and development

center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon


SM IDEAL, Interim Profile, Personal Software Process, PSP, SCE, Team Software

Process, and TSP are service marks of Carnegie Mellon University.

® Capability Maturity Model, Capability Maturity Modeling, CERT Coordination

Center, CERT, and CMM are registered in the U.S. Patent and Trademark Office.

i In order to use the Team Software Process, all team members must be trained in the Personal Software


Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.