EPISODE 02: DECISION VELOCITY

Transcript

Jeremy Parsons: You have to look at the decisions that you’re making on a daily basis and decide are these critical, and can only I make these decisions.

In some cases, a floor engineer can make a better decision than a board or committee that’s several layers removed.

We have to make decisions of a high quality more quickly.

Deana Nunley (Host): You’re listening to Small Steps, Giant Leaps – a NASA APPEL Knowledge Services podcast featuring interviews and stories, tapping into project experiences in order to unravel lessons learned, identify best practices and discover novel ideas.

I’m Deana Nunley.

In our last episode, we heard stories from Orion Program Manager Mark Kirasich about America’s next generation spacecraft.

A companion program, NASA’s Exploration Ground Systems based at Kennedy Space Center, develops and operates the systems and facilities necessary to process and launch rockets and spacecraft, including Orion.

For the next couple of weeks, we’re going to take a closer look at the Exploration Ground Systems Program and feature Angelo Conner, one of the program’s analysts, as guest moderator.

The topic today is decision velocity. Jeremy Parsons, Systems Engineering and Integration Division Chief for the Exploration Ground Systems Program, joins Angelo to discuss practical ways to make quality decisions faster.

Angelo Conner (Guest Moderator): Maybe we could start off with a once upon a time. So once upon a time, at the launch equipment test facility, you were tasked with heading up some verification/validation testing efforts there.

Parsons: Yeah. Before I came into this role, I was serving as a project manager, and actually was tasked to go lead a project that was pretty significantly behind schedule and was running into a lot of technical problems, pretty much not unlike a story that a lot of people encounter. In the space industry, that’s something that’s pretty common, but what was being faced was this was all of the launch accessories and umbilicals that were going for our new rocket that’s really set up to replace the shuttle. It’s called the Space Launch System. So it’s a really big deal for us.

So these launch accessories were all critical path to us finishing our mobile launch tower. So this is a really big deal. We had only gotten into testing of one of them and we had to go finish, essentially, 22 launch accessories in less than two years from then. It had been about a year and a half and we’d really only just started testing one. So there was a whole lot of work that needed to be done.

The fabrication of them wasn’t even nearly complete. Design wasn’t complete. There were a lot of things that really needed to be done. So they called me in and asked me to help staff up and get things moving forward, because we needed to start really hitting it hard and start making deliveries. So one of the first things that I was really asked to do was go and diagnose what was slowing some things down, and figure out what are some mitigations we could do really ramp up both personnel, test teams, et cetera, and then start implementing some of those solutions.

So when I went down there, one of the first things we noticed was between the programmatic personnel and the engineering personnel and stuff, we had about nine people that were all at the same level that were required to make a decision. So what you can find is you might get really high-quality decisions in certain cases, but they were extremely slow and people would debate for a very long time. The other thing was the area to make some of the monetary decisions, they would take several weeks to elevate, and almost everything we were doing down there required money.

So one of the first things we did was we said, “Okay. I’m going to take responsibility for every one of those decisions. We’re going to make them real-time. We’re not going to institute any boards or panels, and you’re going to have immediate access for any funding decisions or any risk decisions. Anything above this certain level of point, we’re going to call either the program manager or the right program authority that day, and we’re going to start accelerating decisions.”

We also instituted a daily afternoon chief engineer meeting to resolve any non-conformances. So rather than wait once a week for a chief engineer panel, we were having those daily, to start beating down some of these major non-conformances we were having during testing. One of the things I also instituted was metrics on non-conformance resolution time, and set goals for how long it was taking us to resolve non-conformances.

Originally, it was taking upwards of 60-plus days to resolve some of these non-conformances. So that can be a major driver for critical path work as well as backlog of paperwork. So these are things that we instituted, major things.

There also wasn’t a clear schedule or schedule-oriented culture. So we had to get a good schedule in alignment, and then establish a culture that was accountable to the schedule. So that was by having some really great people that were able to implement that. We brought in some great operations managers that really put that in place, and then put in great operations leads over each one of the testing, that then filtered that down into the culture.

So then, every single morning, they started on each one of the teams at 6 AM with pretest briefings. Then there would be teams where we’d review the schedule every morning. That’s how they would start each one of the days, to get clear guidance to each one of the teams.

Again, it was kind of switching the culture from one that was maybe more development, like let’s do some engineering sandbox sort of work, to let’s do production sort of environment and operations sort of environment.

Conner: So this type of culture, the environment that you found there wouldn’t necessarily be specific to this type of work that we’re doing. You might be able to find these types of organizations, where you have slow decision processes, where, like you said, you might make really good decisions, high-quality decisions, but in a slow way. So how do you know if your particular organization might be falling into that state of a bureaucratic, risk-averse, slow decision-making culture?

Parsons: That’s a really good question and it’s one that I tend to think sneaks up on you. I think in today’s culture, you have to constantly assess where you’re at. So you have to have some sort of baseline to understand am I performing to the goals that we’ve set out. So you have to look at the decisions that you’re making on a daily basis and decide are these critical, and can only I make these decisions, or the decisions that I’m making on a daily basis, can I push those down?

So one of the things, we’ve instituted a team here to try and look at our speed of decisions within the program. How can we realign some of them? One of the ways we drew it out was we have decisions that need to be fast and that we can accept some risk on. They can be fast and are low consequence. We don’t want to say low quality because, quite frankly, we can make some very high quality decisions very quickly, but they are low consequence. We have some decisions that are very high consequence and need to be made quickly, and high consequence that need to be made very slowly and deliberately with every stakeholder involved. So you can categorize some of these decisions and then bucket them.

What I’ve found is in some organizations, in some areas, when you’re constantly driving everything to the same process, which is that high consequence top bucket, which basically says everything has to go through an extreme board, an extreme panel, and have every stakeholder involved, well, that’s going to be a very slow process. And maybe, just maybe, you’re not getting the risk buy-down that you really wanted or were going for.

Yes, there are a lot of people that want to be informed, and that is one way to do that, but it has consequences. So you can step back and look at are there other ways to achieve the same goals, but do it more quickly.

Conner: In our particular organization, and I’ve seen it elsewhere, we like the stoplight charts. We like the green, yellow, red. That can be okay sometimes. It might boil down the analysis of the data too much, but because we’re looking at red, yellow, green, sometimes we start to feel scared of the red metrics. We start to feel afraid if we’re going to move something from green to yellow. So we start to kind of put things forward that are in the green, things that we know are good. That might not give us the appropriate understanding of where we are. 

But maybe if we were to look at metrics more agnostically and say it’s data. It’s an analysis. It’s a number. It’s not necessarily bad. Maybe that might help us from falling into that kind of slow, risk-averse, methodical process that you were talking about. 

Parsons: That’s absolutely something that I’m an advocate for, obviously. Now that could be the background in working with folks such as yourself that do probabilistic risk assessments. I think that we have to be driven by data rather than emotions, especially when, again, the atmosphere we’re talking about here and in my mindset, the project management and technical hardcore engineering decisions. So those really have to be driven. In my opinion, you have to take the emotion out of it, and you have to be driven by what is the data telling us.   

Again, depending on what is the figure of merit of the organization, if, as an organization, we are meeting all of our goals, we are meeting all of our objectives and we are hitting schedule, then maybe that’s okay. But if you look at what our schedules are, maybe that’s not the case and we need to figure out ways to start trimming out everywhere we can to not lose any ground. So when those sorts of conversations come up, it’s incumbent on leadership and whatever to say, “This is low consequence. Who’s got the ball? Go with it,” that sort of thing.     

Also, there are things where we need to try and stop talking about some things, drive it to the less emotional realm, go say, “We need to get quantitative analysis on this. This isn’t great for discussion until we actually have data to back it up,” and then bring it back for some of the larger forums. That can actually be done, in many cases, more quickly.

Conner: So in all of this so far, you’ve been talking about knowing what decisions you can make quickly, what decisions need to be elevated. How do you look at a decision that comes before you and decide? Are there labels that you put to it? Are there certain tick boxes, checkmarks that you want to place on it, to say this is more of a strategic type of thing that we can move a little bit slower on or this is something that needs to happen now? What are the types of characteristics of those types of decisions?

Parsons: That’s a good question. There are some general hallmarks that decide whether or not this needs to be really slow and deliberate or it can be something that can be made very quickly. One, you should always understand who your stakeholders are and what involvement they’re going to need in the decision. Cost is going to be a big factor. Is it even in your authority chain? That’s going to be one big culture thing that’s important for us as an organization, for any organization to decide. What authority are they going to delegate and empower to the people, and what are they going to push down?

The other thing is, is this decision reversible? If I can quantify to my boss, “Boss, this is how I intend to proceed. This is the cost I am going to spend. But, by the way, if I’m wrong, three months from now I can back out of this, and here’s what we’re going to go do,” he’s going to be much more inclined to let us just pick a path and move, because sometimes that’s what you’ve got to go do. I can spend six months doing analysis and still be wrong, or I can pick a path now and we can go. Then what are the consequences of doing that?

So often, we’re so scared to just pick that point and move on. So if I can outline what that is, that allows them to be comfortable in making that decision. So is it something I can back out on? Is there another course I can take? Or what would those consequences be?

Sometimes, if they’re financial dollars, what we as an entity oftentimes don’t realize is my burn rate of a workforce. For example, at the Launch Equipment Test Facility, my burn rate was – I mean I’m spending a couple of million dollars a month just to keep that workforce going. If I fail to make a decision, that’s huge dollars outflow. So we needed to make decisions and move because that was cash that was going out. They were sitting around not testing if we weren’t making decisions. So that’s something that I always keep in mind.

The risk, obviously, which is, is this going to impact larger critical paths, things like that. So all those kinds of factors go in. Then, quite frankly, because we are a government organization, what is the outside visibility? What is that visibility? This is something that we need to be fully aware of, and what are those implications of a larger failure or something like that?

Off the top of my head, those are some of things that I think are really relevant. So all those things kind of factor in and then you say, “Okay. Can I make this at my level or within my level of authority, or did I need to bump it up?” What I find is in most of my experience there’s a whole lot of stuff I’m able to make at my level, but there is a culture of fear in doing so.

Conner: It was kind of interesting, you leading off this discussion about the different hallmarks, the types of decisions that you can make quickly. You mentioned the term “being afraid of.” You kind of ended the discussion with the word “fear.” Maybe it’s not necessarily a fear of blame or a fear of the consequences of the actions, but it’s kind of this overall reticence, really, to be the one to make that decision. Maybe that’s why we try and spread things out among a committee. 

But what are some ways that leaders can – what are some of the characteristics that a leader might want to develop, in order to be able to overcome that hurdle and really be the one to say, “I’m going to head this. The buck stops here,” as far as, like you said, to my decision authority level? What are some of the characteristics that you can develop?

Parsons: NASA has a long history of both extraordinary leadership and has been a model in a number of leadership books and classes and things like that, but also some of our more public – I would say failures probably isn’t the right word, but the accidents that we’ve had in Columbia and Challenger has definitely imbued a culture where fear of failure and the consequences of some of those failures has definitely filtered into the organization. We want to double-check, recheck, triple-check our work. So that also means that we’ve set up boards, committees, and things like that to make decisions, and that’s generally how a lot of those things go along. It’s a risk-averse culture in certain instances. So we’ve got to be careful not to swing the pendulum too far out of the way, and go for that sweet spot in the middle.    

The Exploration Ground Systems Program right now is in a design and development phase that’s then entering into its test and operations phase, which means we have to be ready to go take what’s been on paper for a long time and in construction, and then put it into operations, which means you really have to enter into a different mode of mindset and thinking. So that also requires people to be a little bit more willing to accept some of that personal responsibility, but that doesn’t mean that you don’t communicate. So what it really has to be is ensure that, as managers, we put the right people in the right jobs, know what their capabilities are, and then empower them appropriately. When you have the wrong people in the wrong job, you have to take action on that as well.

Then ensure that those lines of communication are incredibly open. Not everything has to be done via board or committee. It can be done by empowered individuals, but that have clear lines of communication up to route that information quickly, to where if they feel or are over their head, it’s quickly elevated, quickly communicated, and that they have the backup and the resources that they need in order to get the appropriate decisions made. But necessarily elevating some of these things to boards and committees, does that buy-down your risk? Maybe it’s perceived, but in some cases, a floor engineer can make a better decision than a board or committee that’s several layers removed. 

Conner: That kind of comes down to trusting your workforce. Can you think of any times where maybe you might have disagreed with the floor engineer or someone that was in a position, but you felt that maybe they knew better or maybe they had some information that you didn’t, that then you just accepted their path, their recommendation, and made the decision that way, even if you didn’t necessarily think that that would be the decision you would make?

Parsons: I was really, really fortunate in all of the testing environment that I worked in to have really amazing lead design engineers that I was working with, and chief engineers, to be honest, some of the most intelligent, hard working individuals I’ve had the good fortune of working with. Most of the time, any solutions that we would arrive to, they would obviously come up with the solutions. 

We would work together. I would set, in a lot of cases, a goal or a vision, which would say, “Hey, guys, we need to get this done in two days,” or they would come with an initial solution and I would be like, “That’s really costly and it’s going to take too long. Are there any other ways we can think about this, if I remove this constraint from the problem or if I get you more of this?” Then they’d say, “Well, I hadn’t thought about it that way. Maybe we can go do this.” What I found is if you take a couple constraints away or change a couple of the variables, they came back with some amazing solutions.  

One of the gentlemen I worked with, Steve Larsen, was one of the more creative individuals I ever worked with. He came up with things that I just never would have thought about. My job, in most instances, was to provide perspective that they didn’t have, which would be what were the other programs that were interfacing think. What is the higher level schedule? What sort of budget? In a lot of cases, they would think, “Oh man, I don’t have much money. I don’t have much time. I don’t have other engineering resources,” and I could bring all of those things to bear and then provide them the bigger picture in some of those conversations, but never would I disagree with them on a technical basis. That was maybe the job of our chief engineer that was there or something like that, but I would just change the constraints of the problem.

Conner: Any final thoughts you want to leave with us about this particular topic, anything you think we didn’t discuss that might be of import?

Parsons: Decision velocity is in and of itself, I think, going to be one of our more critical cultural challenges that we face moving forward. As an organization, both at a programmatic level and at an agency level, we are going to be continuously faced with a culture that we have to push back on, that we have to move against, in certain cases, where we are going to have to make decisions in a timely and effective manner.

That doesn’t mean we have to make poor quality decisions. That means we have to make decisions of a high quality more quickly. So if we want to stay relevant, that means we have to accept responsibility. We have to accept the different methods of both managing and leading in different environments that allow us to move more quickly and rapidly through design, development, test, that helps us get to that same result. So that means how do we look at our risk management? How do we look at our decision velocities? And how do we force some of these things down without accepting an undue amount of risk?

There are sweet spots available. When we looked across the program and said, “What are ways we can start to change our culture,” we targeted about four to five different subsystems, set up Lean teams and said, “How do we get drawings out?” Right now, in some of these areas we had nine signatures to release a single drawing, so those had to go to nine different people, and for our work authorization documents, very similar sorts of things, and all of things take immense amounts of time.

So we looked at each one of those things and said, “How can we force accountability to a lower level and not unduly increase our risk?” Then, does that create a groundswell of a culture change, which says how do we force that down? How do we increase some of the decision velocity and decrease some of the burden on the upper grounds of the system? 

I think those are things that we’re going to have to do in order to really move us along quicker, but also, create the accountability and responsibility at some of the lower levels that also makes them better. Then it builds on itself over time. 

Deana Nunley (Host): Thanks to Jeremy Parsons for sharing his thoughts and expertise on decision velocity. And thanks to Angelo Conner for serving as guest moderator.

For Jeremy’s bio and more information about Exploration Ground Systems [and decision velocity] as well as a transcript of this podcast episode, please visit APPEL.NASA.gov/podcast.

We invite you to subscribe to the podcast, and tell your friends and colleagues about it.

If you have suggestions for future topics, please let us know on Twitter at NASA APPEL, and use the hashtag SmallStepsGiantLeaps.

Thanks for listening.