Message from the Chief Engineer — Project Management Challenge 2007: The Project Manager and the Chief Engineer: A Constructive Relationship

ASK OCE — February 23, 2007 — Vol. 2, Issue 2

 

Remarks delivered at Project Management Challenge 2007 on February 7, 2007

By Chris Scolese

 

I’m grateful to have the opportunity to speak with you today. PM Challenge is one of the few chances we have to come together from our individual organizations across NASA and share ideas with each other. It’s remarkable to see how this event has evolved in four short years. NASA is clearly a program and project-driven agency, but first and foremost NASA is a technical organization that accomplishes difficult engineering tasks. So conferences like this provide the opportunity for all of the aspects needed to make a project successful. Over the last day into today there are sessions on risk management, system engineering, leadership, scheduling, and other topics.

So it’s no secret to anyone here that the success of our programs and projects depends on our entire workforce: our civil servants, contractors, our resource, administrative, and contracting organizations, our scientists, and our engineers and project managers.

Our ability to work together — with clearly defined roles and responsibilities across those different areas — is critical. In that spirit, I’d like to focus my remarks today on the relationship between the project and engineering.

Often we see and hear about the conflicts between engineering and programmatic objectives. How often have we heard from the program or project that engineering does not care about cost or schedule or that engineers keep on adding requirements without regard to impact? Conversely, we hear from engineering that the project or program only cares about cost or schedule or that the program is ignoring physics or sound engineering. Like all myths, there is some truth to these comments. However, they are also gross exaggerations of a very complicated process to develop a spacecraft. So today I would like to explore this apparent conflict of views.

Before I do that, its important to recognize that we in the business of space exploration — be it sending humans to the moon, robots to distant planets, or spacecraft to monitor our Earth — doing things that have never been done before. Therefore, these missions represent extreme technical challenges with many unknowns. We may know how to get to Mars, but we don’t know exactly what the landing site holds in store for us. We lack the ability to predict the time, duration, or intensity of solar flares that can disrupt our missions. As our systems become more complex, we lack the ability to deterministically predict all possible operational modes. So we engineers and project managers must design systems and operate these systems in an uncertain environment. In short, we must manage risk.

Consider that we also must deal with uncertainty in budgets, advocacy, political support, and partnerships and the problem just becomes more difficult.

So it is in this complex environment with all of its challenges and uncertainties that we create systems to explore space. None of us want to fail or build unsafe systems. So how do we work together to achieve our common objective.

I began my career in the Navy’s nuclear program, which gave me the opportunity to work for Admiral Rickover, the father of the nuclear Navy. Rickover always emphasized planning for success while at the same time remaining realistic about problems. In a speech he made at Columbia University in 1982, he said, “It is a human inclination to hope things will work out, despite evidence or doubt to the contrary. A successful manager must resist this temptation.”

From my point of view, Rickover’s cautionary note is relevant to both the project manager and the engineer, but it manifests itself slightly differently depending on which badge you’re wearing. In order to examine the relationship between the project manager and the engineer, let’s first look at the world from both of those vantage points.

We all know that an on-time, on-cost failure is never desirable, and seldom, if ever, tolerated. So we are all motivated to do the right thing — to deliver a product that works. But we each have different pressures. What is a project manager’s job? In the simplest terms, a project manager is responsible for delivering a product that meets requirements at a certain cost on a given schedule. The project manager seldom gets to choose the cost or schedule; he or she has to manage within the constraints that are handed down.

On any project, after the technical requirements, we find that either cost or schedule become paramount. For example, the launch window for the New Horizons mission to Pluto was very narrow because it had to be timed to take advantage of a Jupiter gravity assist that would shave several years off the mission duration.

In that case, the schedule for delivering the spacecraft on time was top priority. On the other hand, for a weather satellite that is going to provide redundant capability and that uses a commercial off-the-shelf spacecraft bus, cost might be more important than schedule.

Over the course of a project lifecycle, the project manager always comes under pressure to do more for less. Requirements creep is a constant pressure on the “do more” side of the equation. On the “with less” side, budgets get trimmed, and talented people get taken away and reassigned to other teams.

So what does it look like from the engineer’s seat at the table? The engineer is responsible for ensuring that the product is properly developed according to sound engineering principles in all phases of the lifecycle so that it will perform its function as expected. In addition, the lead engineer or system engineer or chief engineer has to understand all the moving parts:

• the project’s place in a larger program,
• the project requirements, and
• the various disciplines necessary to meet those requirements.

In addition, each engineer on a project must serve as the technical conscience for his or her area of responsibility. This is where there has to be a relationship with the project manager: it is the engineer’s duty to keep the project manager informed and grounded in reality. This means providing clear information based on the data and when necessary by providing options to resolve issues. In the project manager’s environment of constantly shifting dynamics, the engineer has to play Mr. Spock — the cool-headed logician who can explain the pros and cons of every scenario from a systems perspective — to the project manager’s Captain Kirk.

To paraphrase Rickover, the chief engineer has to keep the project manager from hoping things will work out by presenting all the evidence and making sure that all doubts are raised, and, more importantly, that viable solutions are identified in a timely manner. That’s the chief engineer’s responsibility as the independent technical authority on the project, and as an agency we now have a process in place for raising those doubts up the chain of command if they can’t be resolved at the project level.

Being the technical conscience of the project is more than a question of a process, however. The engineer has to embody the highest standard of engineering ethics. This brings us to integrity, one of our core values as an agency. Without it, our processes and procedures are useless.

Two other critical elements that an engineer brings to the project are a systems perspective and engineering judgment. We discussed this concept of engineering judgment yesterday, so let me reiterate what I meant. As I said before, we deal in uncertain environments, so we don’t know all that we need to know. However, when we make a decision based on judgment, it has to be first based upon the data we have and our experience in similar circumstances so when we use judgment we must be clear why we are making the decision we are, why it is consistent with the facts, and what could go wrong if our judgment proves wrong. A checklist mentality will not cut it. Some of you may have seen Gentry Lee’s discussion about systems engineering, if so you understand what I mean here, if not I would suggest you get a copy of the CD with his lecture — it’s both instructive and humorous! Years before he became NASA’s fifth administrator, Dr. Robert Frosch wrote:

“There is a tendency to think entirely in terms of procedures, systems, milestone charts, PERT diagrams, reliability systems, configuration management, maintainability groups and other minor paper tools of the systems engineer and manager. We have forgotten that someone must be in control and exercise his judgment, his knowledge, and his understanding to create a system.”¹

These principles are true for any engineering project, not just spaceflight projects. I’ll give two quick examples. First, think about the Panama Canal, one of the greatest engineering feats in history.

The Canal was begun in 1880 by the French, who had just succeeded in building the Suez Canal a decade earlier. The Suez project had proved to be pretty straightforward: it was essentially a giant ditch dug through a flat, sandy desert. Not to put too fine a point on it, but anybody can dig a ditch, given enough bodies and shovels.

The same project manager that led the Suez project was put in charge of the Panama Canal, and he tried to apply the same approach. This time the work didn’t proceed as smoothly. He underestimated the complexity of the challenge, and he staffed his project with cronies who didn’t bring the right mix of technical skills to the job.

The worst problem the French faced was that their men kept dying on the job. Malaria and yellow fever were not understood at the time. In the first nine years of the project, 22,000 workers died.

When the United States took over the project in 1904, one of the first challenges it tackled was the sanitation issue that made the Canal Zone such a breeding ground for disease. Two years later yellow fever was largely under control, and malaria deaths had been reduced significantly. The American team brought a systems perspective to these seemingly intractable problems.

The Brooklyn Bridge is an even better example of a technological marvel that was based on the perseverance, talent and commitment of the people who designed and built the bridge. The bridge designer and first chief engineer, John Roebling, was one of the first Americans to develop wire ropes, which were strong enough to build long suspension bridges. Roebling died of tetanus due to an on-the-job injury just as the project was getting underway, and he was replaced as chief engineer by his son Washington Roebling.

Roebling and his engineering team were selected based upon their experience with suspension bridges. They went into the project with confidence that their design would work. They realized that there would be technical challenges and problems that they did not expect, but they had confidence based upon their engineering expertise that they could overcome the technical uncertainties.

They did in fact face numerous technical problems unique to their project. There were physical problems. Washington Roebling almost died on the job from a case of the bends — something that was not well understood at the time — but he managed to recover well enough to work from his desk for the remainder of the project, even though he could no longer supervise at the worksite. There were environmental problems. The river current created unanticipated problems. There were material challenges. The cable wire was from a supplier he did not trust and required adjustments to the overall system.

With many of the technical problems, Roebling was well prepared to adjust. What he did not account for were the political and management challenges that he had to negotiate. There were funding problems, management reviews and audits, questions of commitment, and changes to materials and suppliers. He did not anticipate these issues, but instead of acquiescing or just “going along,” he used his engineering expertise to make necessary adjustments and remain the technical conscience of the bridge. Some of the adjustments he made included better testing, more expansive sampling of everything, raising and fighting for critical engineering issues, and working to gain the support and commitment of his project manager.

Had he not adjusted to both the technical, physical, funding, and political realities of the project, had he just gone along without speaking out, the Brooklyn Bridge might have fallen down by now. Rather than walking away from tough problems that were not strictly technical, Roebling was smart enough to understand what his boundaries were. He was committed enough to work the political and management issues. He had the integrity to do and demand the right thing. And he had the dedication to stand his ground and not to give up.

Roebling faced many of the same kinds of problems that we face today — acquisition, environmental, materials, supplies, and logistics problems. He also faced the same kind of political pressures that occur on complex projects to this day. When he took charge as chief engineer after his father’s death, he had a great deal of support, but as time went on after his injury, some began to doubt his competence. This was where the relationship that we’ve been talking about — between the engineer and the project manager — became critical. Roebling’s fate actually came down to a vote, and the man who served as what we now would call the project manager played the deciding role. He supported Washington Roebling, and of course Roebling went on to complete the bridge that we have today.

On our own projects, hard questions are going to come up, and the project manager and the engineer need to have a constructive relationship where they can deal with issues as they arise:

• Both the project manager and the engineer have the responsibility to deliver a product that meets requirements.
• Both the project manager and the engineer have the responsibility to ask the right questions.
• The engineer in particular has to ask the question, “What have we not considered?” and the equally important question, “What can we do about it?”
• The engineer then has to bring the right information forward so the project manager can make the best decisions.

In other words follow the facts, follow the data, and don’t let anyone hope for the best — including yourself!

When the project manager and the engineer have this kind of dialogue, where they’re straight with each other, where they listen to one another respectfully and disagree when necessary, that creates a culture of integrity and trust that brings out the best in all of us.

Note that I did not really differentiate between project and program, nor did I differentiate between the engineer assigned to a project or the engineering leader. I did this on purpose because I believe that the principles discussed above are universal and apply between the subsystem manager and matrix engineer as well as between the Administrator and Chief Engineer. If there is a difference it is only one of scale, not of principle.

So what you might ask is, what are we doing to help foster an environment that fosters communication and mission success?

• First, we have clarified roles and responsibilities between the programmatic and institutional aspects of NASA.
• Second, we are revising our governing documents, such as our NPR on Program and Project Management- 7120.5 – to clarify the life cycle for projects and programs, to clarify the relationships between the programmatic, safety, and engineering personnel, and to identify the avenues for communicating both agreement and disagreements.
• Last and most important, we have a dedicated and competent workforce. However, we need to communicate our ideals throughout the organization. So through conferences like PM challenge we communicate discuss and debate these ideas. We are also revising our APPEL training to communicate these ideas and concepts to the “fresh-outs” just entering the workforce as well as the experienced senior managers.

So as I conclude, recall that everything we now aspire to do as an agency seemed utterly impossible a few generations ago, much the same way the Brooklyn Bridge and the Panama Canal probably seemed unimaginable in 1800. That’s the nature of our business, and it’s what motivates us to get to work early and stay late.

As we pursue those aspirations, we can neither settle for the status quo nor lose sight of our principles as engineers: we have to follow the data and base our judgments on the evidence at hand. I’ll leave you with a memorable quote from President Theodore Roosevelt that summarized this perfectly for me: “Keep your eyes on the stars and your feet on the ground.”²

Thank you.

---

¹Robert A. Frosch, quoted in “Aerospace Management” in Astronautics and Aeronautics, August 1970, Volume 8, Number 8, page 46.
²Speech at The Groton School, Groton, MA, May 24, 1904