This document summarizes a panel discussion on project management. Some key points made: - Project managers should provide opportunities for employees to grow their skills and abilities. Managing people is a major challenge. - Program managers create an environment that allows project managers to succeed efficiently by finding synergies between projects and shared resources. - Understanding individuals and motivating them is a challenge, especially on large projects. Project managers must get to know employees' skills, interests, and future potential to align them with roles where they can grow. - Balance is important for employee commitment and dedication. Project managers should accommodate reasonable work-life balance needs when possible.

1. Project Management Roundtable
Panelists: Jim Barrowman, NASA GSFC; Paul Thompson, Raytheon; Marty Davis, NASA
GSFC; Rich Obenschain, NASA GSFC
Main points:
• One of a project manager’s goals is to provide opportunities for and increase the abilities of
the employees in his/her organization.
• Managing people is the greatest non-technical project management challenge.
• Purpose of CAIB recommendations is to ensure that sufficient checks and balances exist.
• Program managers create the environment and increase efficiencies for projects that are part
of a program.
• Full cost will take some time to adjust to.
Project management – overview.
Anyone can be a project manager of almost anything if you follow the rules of project
management. Project management can be considered an art that is struggling to become a
science. Tools help a project manager manage his/her project, but project management still
remains a human process.
A project manager needs to:
1. Know what the requirements are and what problem needs to be solved. Know what the
project’s focus is.
2. Determine quantitatively what the available resources are: people, schedule, funding, facilities,
etc., and articulate them clearly.
3. Know when to make a decision. Usually 40-70% of the data is needed to make a decision.
Making a bad decision is better than making no decision at all.
4. Communicate. Keep everyone informed about what is being done, why it is being done, and
get inputs. This is not the same as debating, achieving consensus, or making everyone feel
comfortable with a decision.
5. Reduce uncertainty. Define, identify, and indicate a clear understanding of plans, risk
management considerations, requirements, goals, and resources that allow forward movement in
a crisp fashion and timely decisions to be made so that people are not left wondering what to do.
If people are unsure and uncertain, things don’t happen as quickly as when they understand
where they are headed and why.
6. Use an objective tool to measure the quality of performance and determine cost, schedule, and
performance status. The provider of the product or service needs to know objectively and
quantitatively that he/she is on target and meeting or exceeding the customer’s expectations. This
is not the same as having a “satisfied” customer, which doesn’t necessarily mean that the
customer likes the product or service.
7. Help project people succeed.
People.
People are the primary non-technical opportunity and challenge. This includes how to get the
people who are right for the job, how to keep them happy in the job, how to keep them
challenged, and how to keep them working with each other in a productive fashion. A project
1

2. manager must like working with people and getting the job accomplished through them. There
are other non-technical considerations in project management, like budget, schedule, office
space, etc., but they are eclipsed by the importance of focusing on the people.
A project manager must try to “grow” the people in his/her organization: provide them with an
opportunity to increase their capabilities or to find a new direction in which they might go. The
project manager needs to assess people’s capabilities so they are put in positions where they can
succeed but where have got to reach, to stretch. The last thing you want to do is to set people up
for failure.
In running service programs, people are the largest and the biggest issue. It’s inherently a human
resources problem. How do you keep everyone motivated? How do you keep them growing?
How do you give them career opportunities? Clearly, domain knowledge is essential to running a
technical service contract. However, understanding both the business challenges, in addition to
the technical challenges of the customer community, is just as important in running service
programs. By combining business and the technical knowledge, the project manager is better
positioned to continually challenge the staff, provide them opportunities to grow, and find ways
to move them from task to task. One of the biggest challenges is finding ways to transform the
management team. It’s very important to make changes over time to ensure that there is an
opportunity to test new ideas.
In a smaller project, it’s easy to get to know folks, their aspirations, and what they would like to
do. In a larger project, and also across an institution, it is a major challenge to get to know people
as individuals--just getting to know who has what capabilities and who is the right person to try
to reach when you need a job done. Understanding who everyone is and how to motivate each
individual are among the biggest challenges. The goal is to align the jobs with a person’s
interests and not just their immediate interests but also his/her future interests so that they can
grow into the job that they don’t match quite yet.
Program and project management.
[NPR] 7120.5 defines programs and projects. A program manager manages the projects’
environment. A program manager’s job is to help the project managers who work in a program
succeed by giving them the kind of environment that is conducive to success. A program
manager works to find (1) synergy between the projects, (2) common practices so that project
managers don’t have to reinvent the wheel, and (3) common resources so they can do their job
most efficiently. A program manager acts as a gatekeeper for all the community service
opportunities that come along at the institution and the distractions that come with them, and
manages all of that so that they benefit the people who end up being involved without them
being overly distracting. A program manager does not manage the projects themselves or sit on
top of the folks who are trying to do their jobs.
A program manager deals with different kinds of programs differently. For instance, the program
manager on Hubble, which is a tightly knit program with projects that are all focused on the
same thing, tends to be more deeply involved in each of the project’s activities. There is very
tightly knit configuration management and schedule management carried out in the program
office, and the projects are involved in an integrated fashion. In Explorers, on the other hand,
2

3. there is more a common budget where budgetary resources can be shifted to help with phasing
within each project. Everyone uses a common resource process.
For a service contract, there isn’t that much of a difference between a program and a project. The
program level has an overarching view, and the task level is characterized more as project
management that is very focused on the deliverable. A program manager is someone with
multiple activities underneath him/her that may or may not be well connected. On one side, the
program manager may be working on the development of a particular aspect of a mission or
program for one set of customers, and on the other, he/she is supporting something with an
entirely different set of requirements and customers. So the challenges faced by program
managers on large task order service programs are really managing available resources across
multiple, diverse activities; looking for ways that to get some synergy between the tasks; and
finding ways to help deliver a better level of performance to the customer for each of them. In
the context of a service contract, a program manager gets to understand the customer’s mission
on a broader level, how to get the resources applied across a lot of different tasks and activities,
and how to manage and motivate tasks in department-level management teams, particularly by
moving things around a little bit and finding how to apply some of the best practices from one
area of the program to another area of the program. Accomplishing this often involves some
tough decisions in terms of moving personnel around to get diversity and new thoughts into
groups that may have been together a long time.
Balance.
Balance, besides being one of NASA’s values, is very important because if the project manager
truly feels that balance is important, then he/she will end up with very dedicated, committed, and
happy employees. A project can work very nicely with employees who coach soccer and need to
leave early a few days a week, or whose young kids get sick and their parents have to stay home,
or whose spouse is on travel and so the other spouse has to get home at a reasonable hour and
can’t work late. People phone from home and participate, or take home a computer and
participate in meetings. It really is not a hardship. A person can’t do that five days a week, but a
project can accommodate things that come up. It’s just like accommodating flex time, which has
worked fine. When something important comes up, people come in without being asked.
Both the project manager and the employee want to take advantage of opportunities for growth
and balance. Of course the project manager wants to keep alert for folks who would try to take
advantage of this, but staff should be given the opportunity for growth. Sometimes a person
needs to be pushed into taking opportunities. Focusing on the future as well as on the near term
is important.
A project manager needs to make sure that he/she is “growing” his people. That requires that the
project manager or the individual identify available opportunities. Sometimes a manager needs to
push an employee “out of the nest,” i.e., get rid of them so they can take advantage of an
opportunity. Obviously, it’s a sacrifice to the manager, but it is important too that people in the
organization become better, not just getting better at holding their current skills in a particular
project but also take other opportunities.
3

4. Leaders and managers.
There’s some truth to the cliché that managers do things right and leaders do the right things. A
leader has three characteristics: 1) A leader can create a vision that everyone can get behind. If a
person is supposedly a leader but can’t create a vision that everyone can articulate and get
behind, then that person is not a leader. 2) A leader takes people to places they don’t think they
want to go, which quite often is uncharted territory. A new technique may be used to solve a
problem that is unsolvable in the normal way of doing things. A manager can use all the
techniques that he or she has gained over the years, has learned about, or has heard about. A
leader takes people in new directions and, even if they don’t want to go, they will be better in the
end. 3) A leader makes sure, when he or she leads an organization, that the people in the
organization become better.
A person can learn to be a leader and learn to be manager. It’s easier to learn to be a manager
because management consists of techniques. Leadership is envisioning, leading, inspiring, and
growing, which is a little tougher. Most managerial jobs have certain aspects of leadership
involved. It isn’t a clear distinction.
A good project manager is a leader. He/She respects his or her people and deals with them not
just in technical aspects of the job but also by leading them into new territory.
Project manager’s role post-CAIB.
Goddard and JPL already have the structure in place and use it in a way that complies with the
CAIB recommendations. But we have to change to make it more obvious that we are changing to
be compliant. Ultimately, the project manager will still be responsible and have the same
responsibility. There are now people from the engineering organization and from the system
assurance organization as part of our teams; we have always had them, and once all this blows
over and they get their signatures on the right pieces of paper to make everybody ITA happy, it
will go on and we will be able to run projects the way we always did, and the project manager
will feel, for the most part, responsible, and definitely responsible for success. If it doesn’t turn
out that way, then people in the engineering organization are going to be so inundated with
appeals that it’ll eventually work its way out.
From an engineering perspective, the day that we remove responsibility, authority, or
accountability from a project manager is the day that NASA spirals downward. You can’t do
that. The whole problem we have to solve is to make sure that there are sufficient checks and
balances in the system that will enable the project managers to have their three characteristics
and still be successful in his or her project. What the CAIB Report says is that NASA doesn’t
have sufficient checks and balances. So it suggests a very structured system, thus the
Independent Technical Authority (ITA). The need for success remains. The two can be melded
but care needs to be taken that the system already in place at JPL and Goddard that works is not
discarded just for the sake of change and replaced by a system that doesn’t work. So, maybe we
do need to strengthen up our structure a bit, maybe we do need to articulate our processes and
our procedures, but we already have all the fundamentals if we just use them properly and we
don’t have this knee-jerk reaction: “Oh my God, we have one more set of requirements that are
absolutely tangential to everything I want to do and it’s going to be a problem.” ITA, done
properly, can have a minimal impact and maybe even strengthen the way we do business.
4

5. What we really need are good, capable technical folks to support the projects. NASA made
changes in its organization that forced it to reduce its span of people and, in the process,
eliminated a very key job in the engineering directorate: the section head’s job. Section heads
were on the front line. They really managed the technical growth of the engineers in the
engineering directorate. After the change, the branch heads were inundated. NASA tried to give
them the concept of group leaders that never went anywhere because they never had any official
recognition, never had any official promotion capability or anything else, and still tried to get
them to understand, to manage the technical work that was going on. If an engineer saw
something going wrong on a project and he couldn’t get the project’s attention, he had to climb
higher to the branch head. The branch head was sifting all his or her personnel, technical, and
administrative responsibilities to see which of these concerns really needed action. It was just too
much work for one person.
NASA has lost its ability to grow people, for its engineers to be heard as well, or for the projects
to have people to go to who can respond quickly to concerns that have been raised. And that was
the section head. NASA has an opportunity to reverse the mistake it made a number of years ago.
The concept of ITA may help us re-establish section heads.
Today, 85% of people in the Engineering Directorate [AETD] are promoted on technical merit,
not because they’re a supervisor, not because they’re a “manager.” The unintended consequence
of this has been that people say they don’t need to pick up managerial or supervisory skills
because they will be promoted on technical merit. Thus, on a typical good, challenging technical
job on one of the projects at Goddard where we advertise, there are 10-15 applicants. For an
associate or a branch head, getting two people who will apply is extraordinary. This means that
when we promote someone to a senior engineering position, a 14 or a 15, we impress upon them
that if they are going to be put in that position, they will have to have a lot of the “leadership and
management capabilities” that used to be distributed between the unofficial task leader and the
section head. So we’re modifying the people. We’re promoting on technical merit but we’re
requiring some management, programmatic, responsibilities. It’s an interesting paradigm shift:
an unexpected or unintended consequence of the way the direction of the engineering workforce
has been moved.
Regarding reviews, we don’t mind reviews. Ninety percent of the value of a review is preparing
for it, not the actual review. But the review process needs to be restructured so it makes sense.
Holding both the external independent readiness review before launch and the independent
review covered the same thing and wasted time because if the independent review found
anything, it would have to be catastrophic, because you’re ready to ship to the Cape, and you’re
not going to make a change for some minor concern.
So GOES/POES made every review an integrated review with half the team civil servants, co-
chaired by a Code 300 review team manager, and half the team independent, external, with its
co-chair. Both teams participate in every review, whether it’s the PDR, the preliminary design
review, the critical design review, or the pre-environmental review. It’s not just at the end of a
program. So the project manager can take advantage of any benefits that come out of this. It
gives value. To make sure there aren’t two review teams in the same review, each team has a
5

6. limited number of people including the co-chairs, which means that they can’t staff up with the
same disciplines. They have to work together or else they’d run out of people. There are some
people from one organization and some from the other. There is partly a “dog and pony show”
and then there are splinter groups, one-on-ones with the contractor, subsystem people, and the
review team specialists. That takes a day or a day and a half, and then they come back and report
as a caucus. There is more value in this approach.
Challenges managing projects under full-cost accounting.
There isn’t much of a challenge because everything is going to be given to you. You will be told
how much things cost and how much overhead there is. GOES/POES is a reimbursable program
that is funded entirely by NOAA. It doesn’t have any NASA money and has been essentially
full-cost since its inception. GOES/POES has passed on the cost of all the people, the travel,
overhead, and everything to NOAA because it is a completely reimbursable program. Now,
everyone else is going to full cost and all these other pools of money have to be incorporated and
funded somehow. It will take a couple of years to get used to it.
From the perspective of the Engineering Directorate with 1300+ people, our job is to make sure
that those people are applied properly and appropriately to all the numerous activities, be they
projects, technology, instrument development, etc. The fantasy is that on day 1 of full cost
everything was fully transparent because the same dollar pool is available for salary, in theory.
The same dollar pool is available for R&D work, whether for projects, instruments, technology,
or anything else. In reality, what happened very quickly was that HQ and some of the user
community realized and said: “What a minute. I just realized that we have 50 civil servants and
50 contractors working on Project X. And there’s a salary pool available.” But if I went back and
said I want you to figure out how to do the job with 40 civil servants and 40 contractors, I would
free up 20 work years. Twenty work years at $200,000 a year gives me some wiggle room, so I
can either cut your program by a couple of million dollars or I can have you do something new.
So the problem with full cost is that everyone still has to be paid, at least on the civil service side,
to a large extent, to get the job done, we’ve got to pay the contractors also. So it’s not that there
are a lot of dollars in there. That’s what a lot of the programs, a lot of the user community,
thought originally. We’re sort of educating them again. The technique we’re using at Goddard is
very simple. You say you want 50 civil servants. Tomorrow you want only 25. I don’t know
what I’m going to do those 25 civil servants. I don’t know how I’m going to apply them yet. I
don’t know what new jobs are coming around. So what I want you to do is write me a check and
you give me two years of termination, so if you want to get rid of those 25 civil servants, I need a
slush fund of 2 years’ work for all those people. Now in reality, as soon as we trade them off
against new projects, new work, we can certainly buy down your slush fund. Otherwise, people
sort of go crazy. So, that’s going to be the biggest thing. From an engineering and from a support
perspective, we have to understand that the people have to be paid. This is not free money just
because it used to be salary money you didn’t control and now you “control” it.
Don’t think that now that you have full cost, you’re paying now directly for the people. They got
to go somewhere. But because you are now paying for people directly doesn’t mean you will be
able to choose who you get.
6

7. Full cost and baseline changes
In reality, he or she who has the money uses the source to pay for everything that goes on. You
take a place like Goddard, programs come, and they get cut by 50%. The last thing you probably
are thinking about is, how does the work on this project carry the 50% of the workforce they
should have used but they don’t have the requirements for any more. The only way to pay for
people is either to pay directly by project or pay for it out of overhead. Where does overhead
come from? It comes from the projects. So, if a project gets cut 50%, say one of Marty’s projects
got cut 50%, in reality, I go to Marty, and I say, “If you’re not going to use the people you said
you were, then I need a slush fund.” He says, “Well, I don’t have a slush fund.” We immediately
go to Dolly Perkins [Director of Flight Programs and Projects]. Dolly, Marty, and I sit down, and
say, “Marty doesn’t have the money. I’ve got to be able to guarantee I can pay for the people.
Otherwise, I will put them on overhead. So, then we look around and say, “Where can we use
these skill sets on other jobs that Goddard manages?” If we can move the people immediately,
the slush fund will probably go from two years to zero days. And that’s what we have to do. But
if we can’t move them, we either have the project or have all of the projects step up and pay for
the people put on overhead. It’s a zero sum game.
Those who manage contracts or contractors understand the concept of termination liability,
which is basically what we’re dealing with here. Goddard probably is going to start thinking of
itself in some respects as a contractor and establish up front the concept of termination liability.
We have more flexibility with our support contractors than we do with our civil servants. But we
don’t want to lose our good support contractors.
How do contractors retain their talent as the shift occurs? Contractors in industry do have more
tools available, a little more flexibility, but a person’s career and life is being influenced, and
there are gut-wrenching decisions to make that aren’t taken any more lightly in the private sector
than in the federal workforce. We work hard at the issue of how do we replace or move people to
other programs in the company or, if necessary, help them find other opportunities in other
companies when there is a downturn in budgets. Because, ultimately, the last thing we want to do
is to have a downturn impact the income and life of our employees. It’s a challenge for everyone,
not just for government.
7