You will spend most of your time as the manager of an engineering project dealing with people: employees, subcontractors, vendors, buying customers, paying customers, supervisors, other stakeholders, your corporate law department, your corporate human relations department, and so forth.

Since you will be spending so much of your time dealing with people, the social aspects of engineering project management – motivating people, aligning your team, resolving conflict, managing expectations, and so forth – are hugely important to your success, and to the success of your project.

If I had written this book so that the page count dealing with these social and people‐oriented aspects of managing engineering projects reflected their importance to your success, this topic would have made up more than half of the book. But I will instead content myself with this one chapter (which, at least, will be a long chapter). Of course, I have already discussed many individual topics within these social aspects of project management; in this chapter, we deal with this topic systematically.

It is my view that this chapter and Chapter 2 – about requirements and design – are likely to be the most important and most useful chapters of the book for aspiring managers of engineering projects.

I also hope that you will find the material in this chapter useful to you outside of work; we deal with people in almost every aspect of our life. This is a chapter about life.

13.1 Dealing With People, Becoming a Leader

As an engineer, you certainly expect to deal with technical issues: requirements, design, implementation, testing, and so forth. But when we become a manager – most likely, starting as the manager of a small segment within a larger project, and working our way over time up to more responsible positions – we also deal with management issues. This includes items such as the following:

• Cost estimation
• Change control
• Scheduling
• Management and direction of resources
• Contract negotiations
• Customer understanding and satisfaction
• Selecting and motivating people
• Listening to all of the stakeholders
• Conflict resolution
• Balancing the need for good decisions against the need for prompt decisions.

But in our role as an engineer, and most especially in our role as a manager, we will also spend a lot of our time dealing with people. That is, there are important social aspects to the role of an engineering project manager. This chapter, therefore, is about these social aspects, and how to deal with people.

When you are the manager of an engineering project, you lead and integrate all aspects of the project: technical, financial, contractual, safety, quality, and everything else that we have discussed so far in this book.

You also lead the interaction with all of the stakeholders:

• Your team
• Your corporation's management
• Your corporation's stockholders or owners,¹ and the investment community
• Your corporate specialist staff functions (e.g. human relations, finance, law, contracts, quality, etc.)
• Your buying customer
• Your users
• Other interested and affected parties (including, perhaps, the general public).

We will talk about how to do this in multiple stages, starting with what I call alignment.

13.2 Alignment

As the project manager, it is part of your job to synchronize and align all of these people. By this, we mean that you take responsibility for bringing all of the project's stakeholders to agreement about the items listed in Figure 13.1.

Back in Chapter 1, I introduced in graphic form the concept of alignment (Figures 1.10 and 1.11). Figure 13.1 defines the actual criteria of successful alignment. As you can see by looking at the figure, this can be a complex and difficult task. How do you go about accomplishing it?

All of the items on this list interact. I usually start with motivation: Why should someone want to pay for this project? Why should someone want to work on this project? Positive answers to questions like these will likely derive from your ability to explain the purposes of the project (e.g. “to improve the safety and decrease the cost of air travel, through the creation of a new and improved air traffic control system”), and to create a sense that you have a feasible approach to achieve that purpose, and that there are aspects of that approach which are better than competing approaches (this last item is a part of that positive competitive differentiation that we discussed in Chapter 5). We have already (Chapter 4) discussed the need for you to understand your customers and other stakeholders, and how they determine value; this knowledge will allow you to express the above in their coordinate system of value, so that they will react positively.

You must similarly provide motivation to your employees. I find that the best and most enduring motivation usually comes from engaging the employees in the value proposition of the system: Why is this system going to benefit society? If you are building a military system, your employees are participating in the defense of your country and its allies. If you are building a health‐care system, your employees are participating in improving the health and lives of many fellow citizens. Additional motivation comes from pride in good work; you can make it clear that you and the company expect – and will reward – employees who do good work. Further motivation comes from participation in the team, the sense that they are a part of something larger than themselves. Usually, this sense of being part of something larger than themselves is stronger for the tangible engineering project on which they are working every day than for the less specific role of the company as a whole; that is, the people working on a good project actually self‐identify as a member of the project team more strongly than they self‐identify as an employee of the company.

No approach to a complicated engineering system is perfect in the value system of all the stakeholders, however, so you must go further: you must engage their interest enough so that they will at times be willing to compromise, so that you can in fact create a consensus among all of the stakeholders. This particular stakeholder will pay a bit more than they wanted to, this particular stakeholder will wait a bit longer than they wanted to, this other stakeholder will accept slightly less technical capability than they wanted to, and so forth. This allows you to balance all of the differing wants and needs of the stakeholders with an approach that is feasible. People will in general only be willing to compromise in this fashion if their interest is truly engaged; that is, if they really want what you have proposed, if they really believe that your approach is better than all of the others, if they perceive you as an effective and fair leader, and so forth. You must go out and create this consensus. You must also keep re‐creating it every day; as things change, so will the perspective of your stakeholders, employees, supervisors, and the others involved, and your consensus will slip away if you are not constantly working to rebuild it.

You must also remember that there is always competition for your project, even after you have won the competition and signed the contract:

• Person 1 will come along after you have started and propose to replace your contract with a new contract, using their new‐fangled design.
• Person 2 will come along and propose to replace your contract with a new contract that does the work in the district of some particular Congressman.
• Person 3 will come along and propose to replace your contract with a new contract that does the work using only small, disadvantaged businesses.
• Person 4 will come along and propose to stop your contract because they (perhaps incorrectly) see some safety or environmental or equity issue in your approach. Even if they are completely wrong, they might be able to stop your contract.
• Person 5 will come along and propose to replace your contract with nothing, because they prefer that the money be allocated to some completely different purpose.

You must, therefore, be on the lookout every day for these types of threats to your contract, and continuously be reselling your contract, your project, its benefits, and the feasibility and benefits of your particular approach. You may discover that there are additional stakeholders out there too, that must be added to your list.

Some of these threats to your contract may come from your own stakeholders; just because they are a stakeholder does not imply that they are a supporter!

Note that the process described above for getting your team aligned is in some ways similar to what we discussed in Chapter 4, about how we would go about trying to understand our customers. In Chapter 4, we said that you must strive to understand the value system of your customers, so that you can marshal the right approach and the right arguments as you try to win the competition, and as you operate the project through to a conclusion. Similarly, you must strive to understand the value system of your employees: what do they value? Then you must use that insight to create consensus around the value of the project (this creates motivation), and around the approach (this creates alignment). And later in this chapter we will show that you do the same thing with your supervisory chain.

Also notice that you need to take the time to work out how – in the context of your specific project – you want to go about obtaining this alignment. This is why you need a team‐building plan on your project start‐up list (Figure 12.1).

Achieving alignment clearly involves getting people to listen to us, to give our opinions a fair hearing, and, at times, to actually follow our suggestions. So, next, we will talk about how you can accomplish this.

13.3 The Sine Qua Non of Leadership

Sine qua non is a Latin phrase that means something akin to “essential condition.” Therefore, the phrase “the sine qua non of leadership” means “the condition essential to being an effective leader.” My concept of the sine qua non of leadership is presented in Figure 13.2.

The key word in Figure 13.2 is persuade. Even if you are in a position of authority, you will be more effective, more often, if you operate by persuasion than just by giving orders.

I believe that this applies in all settings. As a defense contractor, I frequently had the opportunity to see senior military leaders in action. The good ones use persuasion too, even though they are operating within a structure that technically requires blind obedience. But these leaders know that they do not get the best efforts from their people when they operate by requiring blind obedience; they know that they get more out of their team when those people have been persuaded to do the desired task.

I am not the first person to notice this, of course. Here's a quote along these lines that predates my birth by more than 125 years:

I like to convince people, rather than to stand on mere authority.

Arthur Wellesley, The 1st Duke of Wellington

²

Think about the setting for this quote. The 1st Duke of Wellington probably qualifies as the outstanding military leader of documented history. He enjoyed enormous prestige due to his military successes, including the defeat of Napoleon. He was a nobleman of the highest rank within a society that placed great prestige and respect in such positions. He had a huge popular following. He was the Prime Minister of Great Britain for many years. We could easily imagine that, in such a position, he might feel that he could just give orders. But he didn't; he preferred to persuade people instead.

If the 1st Duke of Wellington believed that it was more effective to work through persuasion than merely to give orders, how much more so for the rest of us!

In the United States today, I believe that in fact we can really only get people to do what we want through persuasion. In our culture, just giving orders is not very effective, at least after the first time. People have options; they are not serfs or slaves, bound to a job or to an owner. They can go to work for someone else. This is especially true for engineers, who are often in short supply and high demand.

In some other cultures³ one might argue that things work differently, and just giving orders can be effective. There is a factor that the sociologists call the power distance, which reflects the relative variation in social standing and authority between layers of a hierarchy. This might be between a worker and a supervisor, between a student and a teacher, or between a child and a parent. What the sociologists say is that the power distance in most cultures outside of the United States is greater – often far greater – than it is in the United States. That is, the difference in social standing between adjacent layers of a hierarchy is often far greater than it would be in a similar situation in the United States. This leads some people to conclude that they can be effective in these cultures just by giving orders. I believe this to be wrong. First of all, in many of these cultures, the power distance is decreasing rapidly, and approaches to managing people that worked yesterday may not work tomorrow. Furthermore, even in cultures where the power distance remains significant in the general culture, within the special subset of those cultures that encompasses their engineers and scientists, my observation is that the power distance between adjacent layers of a hierarchy is likely to be much smaller than the same difference in the general portion of that same culture. And even in those cases where the culture retains the traditional power distance, operating by persuasion still works, and is in my opinion more effective.

The essence of the desirability of persuasion (in addition to its being politer, which is not a trivial consideration) is that persuasion helps to create motivation, and all of the data indicates that motivated employees accomplish more work than unmotivated ones. This difference is not small either: studies in the field of software development indicate that motivated employees are likely to perform three times as much work per unit of time as unmotivated ones. Three times as much work! As a manager, enabling that increase in work efficiency is very much worth doing. If persuading your employees is part of what it takes to capture that increase in work, you should do so. Now let's talk more about motivating your team.

13.4 Motivating Your Team

We all respond to multiple, different motivations, all at the same time. We have the most basic needs: food, water, shelter. Striving to satisfy these forms a first layer of motivation. Interestingly, once we are in a situation where these needs are met, obtaining more of them is only a minor additional motivation; once we have eaten a big meal, we are not strongly motivated by opportunities for food for at least a few hours.

Many motivations share that characteristic: once they are met, they cease to be major motivations. If we want to motivate our employees every single day, we therefore need a different type of motivation, one that is enduring and not readily satiated. Fortunately, there are many of these types of motivation: the quest for things such as respect, honor, the opportunity for accomplishments, recognition, and a sense of purpose do not appear to plateau in the same way that the quest for basic needs does. We can use this insight to design our approach to motivating our employees. Every employee will respond to these items a little differently, but by using a set of such motivators, we can reach most of our employees.

Interestingly, compensation appears to form a middle example; it does not plateau quite as rapidly as the quest for the basic needs of food, water, and shelter, but the beneficial effects of more compensation become diluted quite markedly once compensation passes some adequate level. My conclusion, therefore, is that you cannot buy motivation from your employees; instead, the items cited above – respect, honor, the opportunity for accomplishments, recognition, and a sense of purpose – are better ways to motivate your employees.

Let's talk now about how you can use these techniques.

• Be an inspiration. Create a compelling vision: why this project is important, how (once it is complete) it will improve the world, and how each person can specifically contribute to that success.
• Remove obstacles. Make sure that conditions exist that allow each person to succeed within their role, and to feel that they can and are succeeding. This usually involves a combination of tangible items (e.g. facilities, information, equipment, the mini‐contract that we discussed in Chapter 6, etc.) and intangible support (acting in front of others in a fashion that displays confidence in this person to do their assigned tasks, helping them privately to find ways to solve problems – but don't jump in to solve the problems for them, it is disempowering to do their job for them – and providing emotional support).
• Align the team. Drive the team to a real consensus about how we will perform and complete the project. Do all of the items listed in Figure 13.1.
• Recognize the problems. Recognize and articulate what aspects of your engineering project remain as hard and unsolved, and drive the team to a real bottom‐up consensus about how to solve those problems, or at least how to approach creating a solution.
• Provide the opportunity for personal growth. Assign each person with work that is challenging, but not impossible or unreasonable. Create mechanisms for many types of personal growth for all team members: special assignments, opportunities to present in front of customers and corporate leadership, in‐house training, mentoring, continuing education, and so forth.
• Be a role model. Always be polite, display good work habits, be calm and rational, listen before talking and before deciding, accept responsibilities, make apologies, and accept blame. In other words, be what you want your team members to emulate. Act promptly to curtail unprofessional or disruptive behavior by others; make sure that an offender is aware of exactly what behavior was inappropriate, and that they understand such behavior is not to be repeated, and that apologies and/or amends are to be made.
• Value personal growth. Encourage and reward people who acquire additional skills, especially technical people who learn how to translate their technical skills into business success.
• Provide empowerment. Delegate actual authority, always making sure that you have provided the necessary enablers for the assigned person to succeed. Provide them with someone to teach them how to do those assigned responsibilities, if they need that. Provide a mentor, from whom they can informally obtain guidance. I also try always to let many people participate in the creation of objectives and plans; feeling that they have had a chance to influence these items is very empowering to your people.
• Insist on responsibility. Meet your commitments, and expect other people to meet theirs.
• Value reasoned risk‐taking. Show that you will seek out and succeed at the hard assignments, and that you will reward others who do the same.
• Be a communicator. Become an effective communicator – especially in listening and writing. Effective communication always includes three steps, which I call “Siegel's trio for effective communication”: enumerate, stipulate, and disseminate (Figure 13.3). Effective communication to the team always includes written materials (e.g. plans, schedules, etc. – these are a part of achieving alignment), but also includes you spending time with your team, face‐to‐face, both in structured settings (e.g. all‐hands meetings, staff meetings, the meetings involved in the periodic management rhythm, etc.) and in unstructured settings (walking the hallways, engaging in informal conversations, encouraging unsolicited one‐on‐one conversations through what a former colleague called the open‐door philosophy⁴ – e.g. any person on my staff could, if my door was open, just walk in and talk, or alternatively, could get onto my calendar by talking to my secretary).
• Model and enforce ethics. Talk about and be seen always considering the ethics of each decision, and always stay far from the boundary of questionable behavior, even if the company risks losing business as a result. Ask for advice from your experts: the law department, your contract manager, your business manager, your human relations manager. Take prompt action if ethical violations occur. If serious violations occur, you need to be seen making serious responses. We will say more about ethics in engineering in Chapter 15.
• Deal with the important aspects of diversity. Every person has differing norms, differing values, differing styles, and so forth. Differences that are neither illegal nor disruptive should not only be allowed, but should actually be cultivated. This is because diversity of opinion and diversity of thought process is important to successful engineering projects and successful engineering: we need people with a range of skills, experience, points of view, opinions, and so forth. This variety of ideas and thought processes is important in order for us to solve the complex problems that our project will face. We cannot, however, look inside the heads of our employees and measure these things directly. We have to use the attributes that we can see – sex,⁵ ethnicity, educational background, and so forth – as surrogates for those attributes in which we really do want diversity. We make the assumption that people who vary in these attributes that we can see potentially have the variation in experience, point of view, and so on that we need and want, and use these surrogates as a way to build the necessary diversity into our team. In those instances where we have actually worked with people in the past, and thereby know something about their work styles, their strengths and weaknesses, we should use that knowledge too in order to create the right kind of diversity in our teams. It is also, of course, the case that we aspire to our work places and ourselves being better than was the norm in the “bad old days,” when women and minorities in the United States routinely suffered overt discrimination in our field, and in society in general.⁶ My mother (Figure 1.16) became an engineer in 1952, and she personally lived through years of overt discrimination against women in the field of engineering. My father told me of seeing signs in storefronts in Brooklyn, New York, where he grew up, saying “Help wanted. No Jews or Irish need apply.”
• Create the right reward system. Establish and operate rewards that encourage people to see success in terms of the accomplishments of the team, rather than in terms of their own personal accomplishments. Act in a fashion that causes them to believe that the team's success is truly a viable path to their own individual success.
• Tell your employees how to get promoted. Everyone is interested in promotion. My recommendation is that you be transparent about what will get your employees recognized and promoted. Figure 13.4 presents the list that I used with my employees.

It is my experience that the quest for motivation through items such as these does not get satiated, in contrast to the quest for motivation through the basic needs for food, water, shelter, and even compensation. These items are tools for motivation that never run out.

One last thought about motivation: there are many actions that can be demotivators for your team. Doing the opposite of the items on the above list is certainly likely to become a demotivator for your team members. There are others; I will mention only one:

A leader never complains, but always sympathizes with those who do.

paraphrased from William F. Buckley, Saving the Queen (Doubleday, 1976)

We all have a tendency, at times, to want to complain. I recommend that you always suppress this tendency while you are at work. No one really wants to be led by a constant complainer; it is not inspiring behavior. Furthermore, complaining does not create confidence that you have the ability to figure out how to solve problems!

At the same time, showing empathy for your employees when there are matters which are causing them discomfort is a motivating characteristic. Sympathizing with the complainers can be done without committing that you agree with their position, or that you are agreeing to fix the causes. You can just be a good listener and a soft shoulder.

13.5 Recognizing and Resolving Conflict

People are a problem.

from The Hitch‐Hiker's Guide to the Galaxy, by Douglas Adams

There is an old joke: “Two people, three opinions.” When more than one person is involved in an activity, there will be conflict. As the manager of the project, we must learn how to recognize and resolve conflict.

There are valid and productive reasons for conflict (Figure 13.5); the mere existence of conflict is actually not a sure sign that “people are a problem.” The conflict only signifies that there are multiple opinions, multiple candidate approaches. Remember that when we talked about systems engineering trade studies (Chapter 2), we went so far as to state that creating multiple candidate approaches was a virtue, and even a necessity. The problem is not the existence of multiple opinions – that is, the problem is not the conflict itself. Instead, the problem is the poor methods that many people – and, unfortunately, many project managers – use to recognize and resolve conflict. Let's talk about how to recognize and resolve conflict appropriately, so that we can gain benefit from the diversity of opinions, without letting things get personal and/or disruptive.

Notice that in Figure 13.5, I have divided the list into two parts. The first I have called reasons for conflict that may be productive; the second reasons for conflict that are unproductive. In the previous paragraph, I described situations where there might be valid productive reasons for conflict: differences in goals; different concepts about methods; and different preferences for technical decisions. Of course, now that you have read the section above about achieving alignment, you know that some of this should have been talked out and decided early in the project, captured in plans and specifications. By thereby being a part of the project's baseline, we have already discussed and reached agreement on these matters.

Of course, on something as complicated as an engineering project, you cannot realistically hope to sort out everything in advance. Each day, you will discover new matters that either require a rethinking of previous decisions, or are items that have not been previously decided. That is to say, achieving alignment is a continuous process that gets worked on every day until the project is completed.

Figure 13.5 also contains examples of unproductive reasons for conflict. These are the stereotypical “bad behaviors” to which we often attribute all conflict. Try to remember that this is not true; some conflict is valid and productive! Furthermore, just because some of the behaviors that I have called unproductive are present does not mean that there are not valid and productive issues that are masked underneath that unproductive behavior. We ought not to decide an issue solely on the basis of bad behavior, tempting though that may be. The person behaving badly might be right, even if they are expressing it inappropriately.

This distinction between productive and unproductive conflict makes clear another motivation for striving to achieve the alignment that we discussed above: if the team is aligned, they share a sense of the value of the mission; they have enthusiasm for the project; they share a definition of what the project is to produce; they largely agree on methods, tools, and sequencing; they have a shared definition of what constitutes success; they understand how they can contribute (and the role to be played by others); they understand how the project's success may translate into success for them personally; and they have some sense of a shared destiny – we all succeed or fail together.

With all of that, the team members can develop some level of trust in one another. And the presence of that trust – in combination with some guidance, and some methodology, both of which I will talk about in a moment – ought to allow them to avoid or minimize unproductive conflict.

We can say this in a negative form too. Here are some reasons that teams fail:

• Poorly developed or unclear goals
• Poorly defined project team roles and interdependencies
• Lack of project team motivation
• Poor communication
• Poor leadership
• Perception of unfairness, unequal treatment, and inconsistency in how people are treated
• Bad news is perceived as unwelcome
• Turnover among project team members
• Dysfunctional behavior.

The perception of unfair or unequal treatment can raise hackles among your team very quickly. To avoid this takes effort. I find that it helps if I think in advance about how I will respond to various situations. I essentially have practice conversations and scenarios in my head. This allows me to develop model responses in advance, and I find that this helps me a lot in being consistent and fair.

The ancient Greek dramatist Sophocles, in his play Antigone,⁷ wrote “στέργει γάρ ούδει`ς ’α&c.acute;γγελον κακω~ν έπω~ν,” which can be translated as “no one loves the messenger who brings bad news.” No one likes to receive bad news, but you must not respond by being rude or disrespectful to the person who brings you that news. In fact, you should thank them!

In the book The Lives of the Noble Greeks and Romans, by Plutarch,⁸ he writes that an arriving messenger who gave a particular commanding general (Tigranes) bad news (in this case, the pending arrival of an opposing army) had his head cut off. Plutarch goes on to say that, naturally enough, no one else would thereafter dare to provide this commander with any further information, and that he suffered on the battlefield from this lack of intelligence. If you act in a fashion that discourages people from bringing you bad news (even if your reaction is less extreme than that cited by Plutarch), people will stop bringing information to you, and your ability to be effective as a project manager will suffer.

Here are some examples of the last item on the list, what I call dysfunctional behavior:

• Rudeness. A few immature and/or disruptive people really can set you back; this can be infectious behavior!
• Not meeting commitments
• Selfishness. “Me first” rather than “team first”
• Weak ethics
• Dishonesty.

In my experience, there is not a lot of overt dishonesty in engineering. But engineers are people, and all of the other dysfunctional behavior occurs amongst our engineering teams as frequently as it occurs in any other group of people … unless we achieve alignment, set expectations for behavior, and use problem‐solving techniques that inherently lessen the personal confrontation aspect of the situation.

One item on this list warrants some extra discussion: the question of “me first” rather than “team first” behavior. We engineers spend 16 to 20 years in school, where the value system is “we do our own work, and we are judged almost entirely on our own work.” At times, we do work on team projects in school, but the overwhelming majority of our grades derive from our own work. We are even taught in school that it is generally improper and unethical to collaborate! This value system is embedded very strongly in most of us, because we experienced it for such a long period of time.

Then we graduate from college and arrive at work. In the next section, I will describe what an engineer actually does at work. But I will preview one key aspect of that now: at work, everything worthwhile is accomplished by a team, rather than by individuals. Often these are large teams. Therefore, suddenly, usually with no preparation, we find ourselves in a social setting where the value system that we used for 20 years is no longer valid! Often, no one even tells us about the necessity to make this transition.

In fact, we must transition:

from

The school value system of “I must do my own work, be evaluated almost exclusively on my own work, and derive my satisfaction only from my own accomplishments”

to

The workplace value system of “Everything worthwhile is accomplished through the combined efforts of a team, often a large team, and I must learn that I will be evaluated on the basis of my contribution to the team (rather than exclusively on the basis on my own work), and I must learn to derive my satisfaction from the accomplishments of the team (rather than exclusively from my own accomplishments).”

For many of us, this is a difficult transition, especially the fact that we must derive our satisfaction from the accomplishments of the team. In fact, usually no one tells us that we need to make this transition! But now I have told you. You need to tell your employees. Then you need to be seen taking actions that reward the team, not just individuals.

So, how do we resolve interpersonal conflict in our engineering projects? I use the following approach:

• Focus on the problem, not on the people. I make a decision by analyzing the problem causing the conflict, not by considering the characteristics or position of the people involved.
• Understand what each party wants and needs, and why. What do they have at stake? Why do they care about this outcome?
• Before starting the decision‐making process, create a wide range of candidate solutions. This is akin to the large trade space that we discussed in Chapter 2.
• Before starting the decision‐making process, create decision criteria. Insist on criteria that are both objective and reasonable.
• Be prepared. Do not “make it up as you go along”; getting facts wrong decreases your credibility and negotiation effectiveness. It is better to stop a meeting and request additional facts and analysis than to proceed in correctable ignorance. Task specific people in advance of meetings with the job of preparing analyses of the problem. What are the premises? What are the limitations and constraints? What are the available analysis methods? What are the data? What are the results of the analysis? What are the magnitudes of the uncertainties? What methods, if any, might be available in order to lessen those uncertainties?
• Make the purpose of the discussion clear: are we just gathering facts, creating options, assessing analyses, or have we arrived at the decision‐making stage? If the latter, make it clear who has the authority to make the decision.
• During the decision‐making process, keep the discussion about premises and analysis methods; do not discuss positions or the desired answers.
• During the decision‐making process, use a structure to moderate the discussion that allows everyone to have a chance to express their views, and to respond to the views of others.
• Create rules that will allow an orderly and calm discussion. Cut off inappropriate discussions (e.g. those that make use of ad hominem⁹ techniques, those that insist on jumping to a discussion of the desired answer, those that interrupt someone who is already speaking, and so forth). Make it clear that a rule violation has occurred and identify the nature of that violation. Restart the discussion. Do not prevent the offender from participating again, as long as they participate appropriately. Have a person designated as moderator in any meeting, charged with the responsibility to enforce this approach. It need not be you.
• If you have delegated the decision‐making authority to someone else, do not take any action that appears to pre‐empt that authority.
• As the project manager, you are likely to be the senior person present. You must not pre‐empt other viewpoints by speaking strongly in favor, or against, any particular approach too early in the discussion. Because of your senior position, once you make your views known, many people will be reluctant to bring forth opposing views. Try to speak last.
• Remain calm and polite. Insist that everyone else does too. Interestingly, you will likely find that remaining calm and polite is an effective negotiating tool, and not just at work, but in all life situations.
• Thank all participants. Make it clear that everyone contributed, even those who did not obtain the decision they desired.
• Keep notes about everything. Archive all artifacts; you may need to recreate the analysis later, and will want the data, the spreadsheets, and so forth. I assign a note‐taker role in every meeting; I cannot do it myself and still provide the attention that each participant deserves. Allow the note‐taker to stop the discussion and ask for clarifications, so that the notes can be accurate.

The most important and most subtle item on the above list is the one about “keeping the discussion about premises and analysis methods; do not discuss positions and the desired answers.” Let's say that you support political candidate X for the US Senate, and I support candidate Y. If we just talk about our desired outcomes (the election of X for you, and the election of Y for me), nothing can be solved, and no new insights gained. You just keep saying that you prefer X, and I keep saying that I prefer Y. We might even be tempted to slip into ad hominem arguments, or worse. There is actually nothing being discussed.

If, on the contrary, we each discuss our premises and analysis methods (that is, our lines of reasoning that we use to go from our premises to our conclusion), we can have an actual discussion, have the potential to learn something, and might discover an approach that we can both agree on. Your premises might include that social security must be protected at all costs; mine might include that the government should stop running at a financial deficit. We can each explain why we think these are valid premises, and how we reason from those premises to preferred legislative programs, and eventually to our selection of a candidate. One or both of us might learn something, change our mind, or even determine that the election of neither X nor Y is likely to advance our desires. We might decide that we should both vote for Z instead.

That is, a sensible discussion proceeds forward from the premises and analysis methods to reach the conclusions; it does not start with the conclusions. This is a paraphrase of Aristotle, and 2300 years later, it is still good advice.

In the world of engineering projects, this method works well. You may prefer that we use the C++ programming language for our project, and I prefer that we use Java. If we start our discussion with our desired conclusions, we have nothing to discuss, and are likely to annoy each other, and our colleagues too. If, on the other hand, we each start by identifying our premises, we can have an actual discussion. For example, you may say that the use of strong typing and inheritance is, in your opinion, the key aspect of the programming for our system, and that language features A, B, and C in C++ are the best‐in‐class mechanisms for those purposes. I may then say that we have 1400 user forms to create, and finding a way to make that affordable and maintainable is the key aspect for the software on our system that we ought to optimize through the selection of the programming language, and that the X, Y, and Z features of Java are just the right things to achieve this purpose.

In engineering, we usually have more flexibility and opportunity for nuance in the final answer than we do in the voting booth. For example, the software for our system will probably consist of hundreds of modules, and they need not all be in the same programming language; perhaps we will decide to build the user forms in Java, and the rest of the software in C++. We might even come to believe that this is a better approach than using either language for all of the software. Or, having identified the premises, our analysis might lead us both to realize that we both would actually prefer to use some other programming language in lieu of C++ and Java for all of the software. That is, we can create better answers through the discussion than either of us entered with at the beginning of the discussion. This is a true win–win situation, but we can get there only if we start with premises, work our way through analysis methods, and only then arrive at conclusions.

Doing this takes practice. I can only urge upon you that it is worth the effort. Not only does it often lead to better decisions, but it can also be very empowering to people, and a great team‐building activity. People really feel that they are working together and creating something better through that collaboration than any of them could have created by themselves. As the project manager, that is what we want! Also, just having your employees experience this process, and thereby believing that they were allowed to participate, makes it easier for them to accept the decision, even on those occasions when that decision is not the one that they advocated.

Conflict ends with someone – often you, since you are the project manager – making a decision. People hate ambiguity, and so the tendency for most people is to make decisions too quickly and on too little data; to throw out alternatives too soon; to close the trade space too quickly. Do not be afraid to ask for more analysis, more options, more time. But you cannot be seen as dithering either, and of course decisions need to be made in order to allow the work to progress. Life is tough as a project manager.

Only judgement and experience can help you determine when it is the right time to make a decision. In a few pages, we will introduce the concept of a mentor; he or she can help you with this type of problem.

Good management can lessen the opportunities for conflict. Notice, however, that I did not say “eliminate conflict.” Basically, through management actions, we get issues and potential issues identified, premises and analysis methods identified, people assigned to gather data and perform analysis, and then (likely through a series of face‐to‐face meetings), we actually reach a point where we are ready to make a decision. That decision then gets documented (including the rationale for the decision), and all of the supporting materials archived.

Many decisions have “natural” homes for the documented decision. For example, if a decision determines a portion of the design, the decision will be reflected in the corresponding design documents. But it is not always appropriate to capture all of the rationale in the “natural home,” so I also follow a practice of capturing all decisions in a project decision log.¹⁰ That decision log ought to include all of the data, analysis, models and tools, the various positions advocated (including those not selected), the rationale for each, and the final decision.

Documenting agreements is a vital aspect of project communication. Therefore, the project communication plan (Chapter 12) should include your plans for establishing both the project decision‐making process, the decision log for capturing decisions, and the methods that your project will use for communicating decisions (and their rationale).

Not all conflict is about technical matters. Often, it is about people: who is responsible for what pieces of work, who gets to make what decisions, who gets priority access to people or facilities, who gets promoted to an open position, and so forth. Clear statements of scope in the mini‐contracts (Chapter 6) and other project documents are the resources you use to lessen these occurrences. When such issues do arise, you must address them promptly; they do not go away by themselves and can get worse over time if left unaddressed. You use the same “Aristotle‐based method” to solve these interpersonal conflicts as we described for solving the technical conflicts. Be aware that these types of conflicts have more potential for hurt feelings than do the technical conflicts. All the more reason to be calm, polite, and fact‐based, as we described above.

Summary for resolving conflict:

• Discuss premises and lines of reasoning rather than discussing candidate answers! (Aristotle)
• Bring issues into discussion (openness; don't bury the problem or shoot the messenger)
• Be willing to listen (“We have 2 ears, but only 1 mouth …”)
• Understand your and other parties' needs/wants (their value system)
• Get the facts (premises) agreed upon before starting the process of trying to reach a decision
• Don't speak for others; that is disempowering. If you state an opinion, use “I.” Ask that others do the same
• Ask questions (the “5 Why's” from Chapter 9) to get to the bottom of an issue, paraphrase and restate what others say, so as to make sure that you understand what they actually meant
• Be willing to expand the candidate solution set – this is often a path to resolution of conflict.

13.6 Siegel's Mechanics of Project Management

I have found that certain process steps aid in my mastering the social aspects of project management. These mechanics of project management are shown in Figure 13.6.

Let's discuss each of these in turn.

• Take decisions only in writing:
  • I recommend that you create a written project policy that nothing said verbally carries any force, and is not to be acted upon. Actual decisions that are to be acted upon will be committed to writing with an appropriate level of approval; only then are they to be acted upon, not before.
  • Create a formal record of all written decisions (as noted above, I generally called this the design notebook, but it might better be called the decision log). It should include both the actual decisions (with approval by the appropriately authorized person), but also opinions, analyses, and other non‐binding but potentially informative items.
• Implement Siegel's trio for effective communication:
  • This was introduced and discussed in Section 13.4 above.
• Always capture the rationale and methodology used – including the premises, the actual data, software tools, spreadsheets, databases, decision criteria, and anything else used to inform the decision, in addition to a description of the decision‐making process – for reaching decisions, not just the decisions themselves:
  • This can be vital later on, when new information arises, and the analyses have to be redone.
  • The rationale and methodology used to reach a decision can be documented in separate papers from the decision memorandum, if desired.
  • Both should be right next to each other in the decision log, and the decision memorandum should reference the paper providing the methodology.
• Do not use face‐to‐face meetings simply to convey information:
  • That is done more effectively in writing, and
  • It also makes for boring meetings.
• Do not use electronic mail or any similar electronic forum (e.g. social media) for discussion:
  • Electronic mail and similar electronic forums are fantastic for conveying small pieces of information, such as a phone number, or the location and time for a meeting.
  • But electronic forums are weak, and even counterproductive, as a mechanism for discussion. Psychologists and sociologists tell us that something like 70% of all information conveyed between people in a face‐to‐face meeting is through mechanisms other than the words spoken by the participants. You lose all of that 70% in electronic forums. Furthermore, I find that the use of electronic forums tends to allow people to disconnect from the forms of behavior (described above) that I believe are essential for effective teams.
  • Therefore, discussion is done better at face‐to‐face meetings.
  • I recognize that in our private lives, lots of people do use electronic forums for discussion. I believe that electronic forums do not work well for discussion in our private lives either, but I cannot control what people do in their private lives. I can control what they do at work, and need to control them enough to ensure that they conform to what I believe are constructive forms of interpersonal behavior.
• Organize meeting agendas around discussion (not around just conveying information), and (most importantly) discussions of those items about which there is not yet a consensus:
  • There is a natural tendency for a group to want to spend their time talking mostly about the things about which they are all already in agreement; that is, after all, comfortable.
  • The tendency is also to avoid spending time talking about things on which they have not reached a consensus … yet those are exactly the things that need to be talked about.
  • Spending most of your face‐to‐face meetings talking about the items which you already agree on does not make for very productive meetings; nor does it move us forward toward solving the unsolved problems. I always tried to build meeting agendas to spend most of our time discussing the matters on which we had not yet reached a consensus. That is at times uncomfortable, but productive.
• You must have some meetings with all of your direct reports as a group – you cannot decide most things just by meeting with the relevant people one‐on‐one:
  • Most of the matters that you will be called upon to decide will involve interactions (and sometimes these interactions are subtle and easy to miss) between different aspects of the project, and therefore between the areas of responsibility of multiple people. If you decide such matters solely via discussions with the people involved one at a time, you will miss out on the opportunity for these people to react to, and comment upon, the opinions and points of view of the others. My experience is that such multi‐participant discussion leads to deeper insights and better decisions.
  • Such team discussions – assuming that you keep everything polite and respectful – are very important team‐building and consensus‐building opportunities. You need not just to reach a decision, you need to reach a decision that all of your direct‐report managers are willing to support. Giving them a visible opportunity to participate in the decision process through group discussions is an essential step in forming such a consensus.
• Work with, and take advice from, only those people who either have skin in the game, or are bound to you by genuine affection:
  • By the phrase skin in the game, I mean that they will be materially affected by the outcome of your project, or of a decision on which they are advising. You and your employees may lose their jobs if the project fails, and/or suffer reputational damage. Your using customer will lose capability (or at least, the improved capability will be significantly delayed) if the project fails. These people have real skin in the game; they care about the outcome of your project, and their own personal outcome will vary in both a positive and a negative sense with the outcome of your project. Consultants – even the most distinguished experts – famously do not have skin in the game; their outcome (whether they are billing you for their time or serving gratis) will not change depending on the outcome of your project. For this reason, I suggest that you never use consultants, contract labor, job‐shops, or the like; they have no skin in the game, and their advice may therefore not be aligned with the needs of you, your customer, and your team. I therefore prefer to hire employees (who always have skin in the game), or another company as a subcontractor – this subcontractor (if you write the subcontract to have real responsibilities and real deliverables, not providing bodies) will have skin in the game, both financially and reputationally, just like your own employees. Retirees – even when hired on a consulting basis – may be different. They may be bound to the company or to you by genuine affection, and therefore have emotional skin in the game, even if they do not have material financial skin in the game. Retirees also always have a concern about the long‐term financial health of their former employer; their pension may be reduced (or at least, interrupted) if the company goes bankrupt; this provides retirees (but not pure consultants) with skin in the game.

13.7 Dealing With Special People

13.8 Your Career as an Engineer

Some of you reading this book may already have substantial work experience. But many of you may not. I will therefore describe what an engineer actually does at work.

I spent many years working for a large aerospace company. For 18 of those years, I was a vice‐president and officer of the company. I held many different job positions over that time: working on engineering projects, managing engineering projects, running business units within the company, running proposals to win new business for the company, work assignments in other countries, and many years as the chief technology officer. I had as many as 12 000 employees. It was a big company, and it offered me big jobs and many interesting challenges.

I also at one point left my large company to participate with five other people in the formation of a start‐up company. This experience also offered me a lot of challenges, many of which were quite different from those I experienced at the large company. I stayed with that start‐up company until a year or so after we went public (and had grown to around 1 500 people). At that point, I felt that I had learned what I was going to learn from working for a smaller company and wanted to work on big engineering projects again. So, I returned to the same large company where I started my career, and stayed there until I retired.

The aerospace industry, of course, hires a large number of engineers and engineering project managers. There are many well‐known companies in this industry. I worked for Northrop Grumman,¹¹ but other companies include Boeing, Lockheed Martin, Raytheon, General Dynamics, and BAE.

Many other industries hire engineers, engineering project managers, and systems engineers, including:

• Shipbuilding
• Telecommunications
• Energy
• Medicine/health‐care
• Government
• Construction
• Banking
• Retail (especially those that do their own supply‐chain management)
• Entertainment.

Some of these are relative newcomers to the engineering project management business. For example, it is only in the last couple of decades that the entertainment industry (movies, video games, etc.) and health‐care (electronic medical records, digitized medical diagnostic equipment, etc.) have transitioned so many of their products to digital and computer form, which naturally required them regularly to undertake engineering projects in order to create these products.

That is good news for you; there is a diverse and growing demand for engineering project managers, at all levels of seniority.

You get to choose not only an industry to work in, but also the size of the company for which you wish to work. I found that my experiences at big and small companies were quite quite different (Figure 13.7).

But what do you actually do at work? In college, we spend much of our time learning technical skills: computer programming, digital logic design, mechanical stress analysis, and so forth. We do some of that at work, of course, but such tasks are always set in the context of the project, and as a result, the focus is always on that context. Here is my summary of what we engineers actually do at work:

• Just as we discussed in Chapter 4, we strive to understand the customer for the project, and how they determine value.
• Just as we described in Chapter 2, we create metrics for measuring the project's design that align with the customer's value system.
• Just as we described in Chapter 2, we create an engineering and management trade space, and traverse it to create a feasible and suitable solution. We measure the effectiveness of that solution using the metrics that resonate with the customer.
• Just as we described in Chapter 9, we use engineering techniques to reduce risk and exploit opportunities.
• Just as we described in Chapters 2, 10, and 11, we use processes to do the job right the first time, and to help the team do it at scale.
• All of this is quite creative; we are solving hard problems for which there is no answer already provided at the back of the book. We have to use our understanding of the customer to identify the pressure points of the design (Chapter 2).
• We are part of a large team, and must work in collaboration and harmony with our colleagues, and derive our satisfaction largely from the accomplishments of the team, rather than our own individual accomplishments (this chapter).
• Hard science and engineering drives our analysis, but does not create the candidates that we assess. Our imagination creates those candidates.
• Since so many of the factors that we must consider are in tension and competition with each other (Chapter 2), we strive not for a “correct answer,” but instead for a balance. In school, we aimed for the “correct answer,” but that seldom exists at work.
• Since the resulting system or product must be both effective and suitable (Chapter 3), we must exercise judgment, and employ a sense of fitness and artistry to make our design selections.

As you can see, I have already discussed many of these items, but here I take the opportunity to bring them all together in a single list.

As engineers, we have the opportunity to work in two principal types of roles: we can work as engineers (often called being an individual technical performer), or we can work as managers (meaning that we supervise other employees). This is not an either/or choice; in fact, if you are willing to move back‐and‐forth over your career, your company is likely to value that flexibility, and likely to reward you for that flexibility. I did so during my own career (Figure 13.8); my career started in the lower‐left‐hand corner of the figure and proceeded upwards.

I found this transitioning back‐and‐forth interesting, and my willingness to do so increased my value to the company, because I could fill more roles, and serve in whatever capacity was needed at the time. It also opened up opportunities for me to serve in roles that I would not even have asked for; I will say more about this when we discuss mentors below.

I believe that what facilitated my career path upwards to senior positions was the business benefit: I developed the ability to use my technical skills to bring business into the company. Refer back to Figure 13.4.

As we discussed in Chapter 5, the key business of many companies requires the performance and successful completion of engineering projects. Therefore, much of your career as an engineer and an engineering project manager will be spent working on these types of projects.

As we have already discussed, it is a team activity.

For me, this was a great career. It was interesting work. It was important for society; this combination of interesting and important made for a great life experience. Perhaps it will for you too.

With your training as an engineer, and your eventual experience as an engineering project manager, there are roles that you can play other than engineer and project manager too, such as:

• Testing
• Marketing/sales
• Business development
• Management
• Teaching.

I call these adjacent roles. We will say more about them in the section below about coping with career change.

13.9 Change on Your Project

Change usually makes people uncomfortable. But change is a fact of life on engineering projects; we just cannot know everything in advance.

Therefore, you must:

• Cope with it yourself, in your role as the project manager
• Help your team and customer cope with it
• Manage the changes, so that you can receive the benefits of the change, and do so without causing too much disruption.

Generally, the bigger the project, the more the amount of change there is that takes place, and the harder it is to cope.

These changes come from two different sources:

• From the customers and the other stakeholders (externally), and
• From within the project team (internally).

Usually, change from these two different sources must be handled somewhat differently, due to the fact that if the change is sourced externally to your team, there will be additional people involved in reviewing and (eventually) approving the change.

What might change? Almost anything: a requirement, an aspect of the design, the schedule, the budget, predictions of technical performance, personnel assignments, the strategy for training, the tools for software development, the legal and regulatory environment, and on and on.

How do we manage and control change? The steps are largely the same, whether the change is sourced internally or externally:

• Noticing that a change is called for
• Discussion and analysis of the impact of the proposed change (see below)
• Approval or non‐approval of the change, and of its implementation method
• Configuration control of documents and products
• Validation that the implementation of the change is correct.

One of the hardest aspects of change is that change causes “ripples”; a seemingly innocuous change to one item (e.g. contract, statement of work, specification, schedule, work‐breakdown structure, design, piece of software code, etc.) can impose unexpected (and often significant) changes on many other aspects of the project.

Therefore, before accepting and approving any change, you must exercise a process to look for any such derivative impact of the proposed change, and estimate its impact to technical performance, schedule, cost, risk, people, customer relations, and so forth.

Because candidate changes will occur almost every day, you likely need a standing process and capability to do this. This is often organized as a standing committee called the change‐control board. The change‐control board has access to a set of tools and people (usually in the systems engineering team within the project) that can perform the required assessments. The change‐control board is usually chaired by the project's manager of systems engineering.

Since changes can have such unpredictable and important effects, the question of who can actually authorize change is important.

In your buying customer's organization, there is usually only one single person who can authorize changes to your contract, deliverables, terms, schedule, and price … and it is usually not the customer's project manager! In fact, it is usually the customer's manager of contracts (often called a contracts officer). Do not act on requests for change until after they have been directed in writing by the authorized person!

Similarly, you need clear definition of who is empowered within your project team to authorize a change to controlled documents, designs, and products. Usually it is only the project manager, acting through the recommendations developed by the project change‐control board.

13.10 Coping With Career Change

Your career in engineering is a journey, not a destination. By this I mean that it ought not to be about achieving some single position or status, but instead ought to be about doing important and interesting work over a period of time, while continuing to develop your skills.

At age 20, when I received my bachelor's degree, I did not know what I wanted to do for a living. No one really expects that you will, either. So, embrace the possibility of mid‐career changes.

Over time, you will learn more about yourself, and you will learn more about the possibilities. Entire new fields and opportunities will likely emerge as well.

Here is my recipe for how to cope:

1. Acquire some foundational knowledge (e.g. knowledge that does not age quickly).
2. Understand and accept that learning is a lifelong activity.
3. Understand and accept that a lot of what you will use to succeed in a career is acquired post‐hire, on the job. It increases your value, and it brightens each day.
4. Over time, strive to learn more about yourself: what you enjoy, what provides enduring stimulation, and so forth.
5. Keep investigating possibilities!

Let's discuss each of these.

13.11 Getting Ahead

13.11.2 Getting Ahead: Understanding Your Boss

The definition for what it means to get ahead is not the same for everybody; “getting ahead” means different things to different people. Actually, it is likely that “getting ahead” will mean different things to you at different times in your life and career; what you value highly will change over time.¹⁵

But here are the most likely possibilities of what it means to get ahead:

• Moving up to higher levels in the organization
• Having subordinates
• Increased immediate financial compensation
• Increased long‐term financial compensation
• Increased retirement compensation
• More generous medical insurance
• Increased prestige
• A more impressive job title
• Getting to spend more of your time doing what you want to do
• Not having to spend a lot of time doing things that you don't want to do
• Having work that you find more interesting
• Having work that you find more important.

How do you get there? It starts by delivering value to your organization. Some of the ways that you deliver value to the organization are obvious: technical competence, good work habits, honesty, ethical work behavior, collaboration with your colleagues, and so forth (and the items listed in Figure 13.4). If these are all obvious, how do you find things that you can do which will distinguish you from your colleagues, so as to mark you as someone who is ready for advancement within the organization? One way to accomplish this starts by understanding your boss. Let's role‐play for a moment: a day in the life of a senior executive.

OK, you have made it. You are the vice‐president and general manager of a large operating unit within a great company. Profit and loss responsibility. Multiple facilities. 3000 employees. Corner office, car, and so forth.

Here's your typical day:

• Your calendar is booked solid from 8 :00 a.m. to 6 :00 p.m., including lunch. 30‐ and 60‐minute chunks.
• One person has 30 minutes on your calendar to tell you about a great success.
• 5 teams have 30‐minute chunks to seek your advice/approval for an element of future strategy (proposals, expansions, etc.).
• 10 people /teams have 30‐minute chunks on your calendar each to describe a problem, and seek your advice/approval for a corrective action.

Actually, on a typical day, you have to do all of this while on the road.

That is, most of each day is spent dealing with problems. There is too little time devoted to each topic to really learn the issue, reflect, discuss, and reach a sensible decision. In general, they will have waited so long to get to you that decisions are needed fairly quickly.

So, what do you need? You need people who have proven they can go and solve problems, so that you can assign one of them to go and work on each of today's problems. And you will need another set of such problem‐solvers tomorrow.

Usually, the executive's only degree of freedom is whom he/she selects to go and work out the problem.

One proven path to get ahead, therefore, is to become one of those people: a proven problem‐solver.

How do you do that?

• Be willing to take on the hard assignments … that is, the assignments that the boss needs accomplished; be the one who will go and fix the @#$%$^ problem!
• Be reliable; always do what you say you will do. If circumstances change what you can feasibly do, always say so promptly.
• Be success‐oriented, while always being ethical.
• Focus on success for the institution and for the team, and trust that that will eventually translate into success for you.

A word about these fix‐it assignments: many people think that these assignments are “risky” and stressful, and therefore shun them. What I learned was different: these programs are already “at the bottom”; they can only go “up.”¹⁶ It is possible to arrange things so that you can get the credit if you pull it off, but not get the blame if it fails. After all, the project was already in trouble before you got engaged. Yes, it is stressful. Be engaged and focused, but keep a sense of proportion.

What am I saying is this: Understanding how to get ahead starts by understanding what is valued by your institution, and your boss is a proxy for that institution. Take the time to learn what the boss and the organization need and want.

Understanding the boss also involves understanding the institution. Big and small companies, for example, are likely to be different in some important ways, and therefore what constitutes effective behavior and success will differ (Figure 13.9).

13.12 Two Special Topics

13.13 Summary: Social Aspects of Engineering Project Management

• The project manager is the leader of a set of people, and the interface to an additional set of people. You interact with all of those people, and facilitate their interaction with each other. People are at the center of the project manager's universe. Therefore, there are important social aspects to the role of a project manager.
• You must persuade people to want to follow you; I provided a set of specific actions and attributes that will help you.
• Since people are involved, there will be conflict. You must learn to handle and manage that conflict, and to channel it to productive discussion. Discuss premises and lines of reasoning, rather than discussing candidate answers.
• Management and customers are people too, and you must deal with them. Build credibility in advance of a problem.
• There are useful and important “mechanics of management.” “Take decisions only in writing” is number 1. Work with, and take advice from, only those people who either have skin in the game, or are bound to you by genuine affection.
• Your working career will consume a lot of your life. Therefore, satisfaction is at least as important as success. Just as in systems engineering and project management, you must strive to achieve balance between satisfaction and success.
• To me, such balance derives from having work that is important and interesting, in combination with never acting in a fashion that can cause you to have ethical regrets. Then you can evolve other factors (such as success and compensation) so as to suit your character.
• The definition of “getting ahead” is not static. Your definition will be different from that of your colleagues, and your own definition will evolve over your lifetime.
• Understanding how to get ahead starts by understanding what is valued by your institution; and your boss is a proxy for that institution. The key enablers and disablers are all discoverable.

13.14 Next

Many management books tell you that you need to focus your management efforts on schedule, cost, and technical capability. In the real world, that is insufficient. Factors such as reliability, safety, low defect rates, and environmental friendliness increasingly play a role in product and company success. We can group all of these types of factors under the title quality.

13.15 This Week's Facilitated Lab Session

Today, you will continue working in your teams.

Today's topic is team exercises about the social aspects of the role.

Assignment:

• Refer back to the project that your team selected previously.
• As a team:
  • Boss exercises. List and describe your boss's coordinate system of value. Create measures that reflect his/her value system.
  • Staffing profile. Create a staffing profile for your project. Discuss where the profile is easy to achieve, and where it is difficult to achieve. Discuss what you might have to do to the activity network and other project artifacts to make the staffing profile feasible (e.g. will you have to slow down the beginning of the project and extend the schedule a bit, to reflect the reality of how fast you can bring people onto your project?)
  • People exercises. Assign everyone on your team to a project role (e.g. project manager, software development manager, test manager, human relations manager, and so forth). Using the materials on charts 7 and following from lecture 12, discuss how you will build effective interpersonal interactions within your team, and with your customer(s), boss, and other stakeholders.
• The above will be turned in as a section in your team project report.