May 28, 2014 | Time: 12:29 | Subscribe in iTunes
Featuring Robert Brese, DOE CIO
PMs know how to deliver with the disciplines they have learned, but from an executive’s point of view, what’s missing? The answer may surprise you, from this interview with Mr. Bob Brese, CIO of the Department of Energy.
Listen online or read the full podcast transcript below.
About the Speaker
Department of Energy (DOE)
Chief Information Officer (CIO)
Mr. Brese is the Chief Information Officer (CIO) for the Department of Energy (DOE). He provides leadership, establishes policy, and maintains oversight of DOE’s annual $2 billion investment in information technology (IT), at more than 25 National Laboratories and Production Facilities, to enable urgent missions that span from open science to nuclear security. Mr. Brese is also a leader in the U.S. Government’s cybersecurity community and a key contributor to the Administration’s efforts in legislation, policy and technology research, development, and deployment. He is a Chair to the CIO Council’s Management Best Practices Committee and also serves as an advisor to the Domestic Policy Council’s Strong City, Strong Community Pilot. Prior to his current assignment, Mr. Brese served as DOE’s Deputy CIO.
Previously, Mr. Brese was the Deputy CIO for Information Technology for the National Nuclear Security Administration (NNSA) and also the Director of the Office of Program Evaluation within Defense Nuclear Security in NNSA, where he began his civilian career and his tenure in Senior Executive Service.
Prior to working in NNSA, Mr. Brese served as a submarine officer in the U.S. Navy, retiring after a 22-year career, which culminated in his assignment as a Senior Advisor to the Deputy Administrator for Defense Programs within NNSA.
Mr. Brese holds a Federal Chief Information Officer Certificate from The National Defense University. He obtained a Master of Science from Catholic University of America, was a qualified Naval Nuclear Propulsion Engineer in the U.S. Navy’s Nuclear Propulsion Program, and received a Bachelor of Engineering at Vanderbilt University.
00:03 Bob Brese: So, there's open project as a solution. Open schedule is not a solution. [chuckle]
00:09 Announcer: From the Washington DC Chapter of the Project Management Institute, this is PM Point of View, the podcast that looks at project management from all the angles. Here is your host, Kendall Lott.
00:19 Kendall Lott: PMs with certifications know the rules of the road. That is those methodologies of delivering projects within established constraints of scope, schedule, and cost. But we wanted to know, from an executive's point of view, what's missing? Today's guest, Mr. Bob Brese, is the chief information officer of the Department of Energy. He has three decades of service in the US military and with the federal government. He currently oversees a $2 billion IT budget in support of the Department of Science, Nuclear Security and Cyber Security programs. From policy, to governance, to budgeting, Mr. Brese sees it all. And PM Point of View wanted to know what matters most to him as an executive when he's engaging with project managers. It turns out the answer isn't in the PMBOK.
01:03 KL: So how have you seen the use of project management in delivering the goods and services?
01:08 BB: Project management is really I think critical to delivering almost any outcome, even if it seems small, the use of the project management fundamentals are critical to success. If you try to wing it, no matter how small or insignificant it seems at the time, chances are you won't always deliver to your boss' expectations.
01:33 KL: And you're usually the boss that has the expectations is what I'm hearing here.
01:36 BB: That's right, so you have to make sure that those expectations and the perceptions of those who are executing the project are aligned, and leveraging project management principles tends to help align those two things.
01:48 KL: In that set of things, when you say project management principles, what's one of them that's the most interesting or most important to you, when you're getting that feedback about how projects are going?
01:57 BB: Well, first, I think it is what is the outcome that is expected at the end of this? If you don't agree on the outcome and don't have a common understanding of what the project or what the activity is supposed to deliver, you can almost guarantee failure on delivery day. I think the second thing is: What's the schedule? So there's open project as a solution, open schedule is not a solution. [chuckle]
02:24 KL: So how do you feel about Agile?
02:26 BB: I think Agile is awesome.
02:27 KL: But it's an open schedule scenario.
02:29 BB: Yes and no, okay. Yes and no. Because every time you do a release or a scrum, there is something that is supposed to come out of it. You and that team should have an agreement as to what you expect to come out of it. Now, a lot of times you won't necessarily deliver everything you had hoped for, but you know what the gap is, you know what you were able to accomplish and what needs to get fixed or what gets rolled into the next release.
02:57 KL: How do you align your expectations of what should be delivered in the fact that scrum, for example, might be producing with a gap?
03:05 BB: Well, I think what we saw through some of our infrastructure improvements was that initially, the team might think they can get more done in that scrum time period than they were really able to get done, that there are unanticipated difficulties. As we got further and further along, that gap tends to get smaller, because the team better understands its own capabilities and is really better equipped to match expectations with what they're able to deliver. So I think through Agile, particularly every time a new project with a bunch of releases gets started is you're probably gonna have a larger gap at the beginning, in the initial releases than you do in the later releases as the team kind of of coalesces and really understands what its capabilities really are.
03:55 KL: So you're using some Agile here in this department with your current environment? Is that...
04:00 BB: Correct.
04:00 KL: Where you're using some of it? Do you have a sense of how much versus how much in kind of more regular PMBOK style project management, you know, tight schedule and scope?
04:10 BB: A lot of what we do is market research, alternatives analyses, selection of a preferred alternative, develop an implementation plan, execute the plan. So that's a little bit different than trying to deliver capabilities through releases of new software or new capabilities and things like that. So it's a mix. I would say we're probably closer to 70% traditional PMBOK type work, 30%...
04:38 KL: Are your deployments under project management control when you're doing a deployment or a roll out to field?
04:44 BB: We have a project execution model that we have approved. My team developed it back when I was in the National Nuclear Security Administration. We've carried that forward, we've issued it as a Department of Energy IT project management guide. And what that does is take the traditional PMBOK approach and align it towards information technology projects. It really provides critical decisions and milestones that we expect to see particular deliverables. You can compress those, you can combine them, you can disaggregate them into A, B, and C steps if they're very complex. So it's pretty flexible, but it is PMBOK-based and we've found it to work when it's used. [laughter]
05:32 KL: From an executive perspective, do you get frustrated with the interaction with project managers, in terms of what they see as their scope and what you see in terms of your need?
05:42 BB: Truthfully, I really get frustrated with project managers when they blow off project management principles. And you go ask them, you go, "Well, you know, when you put together your plan and you looked at the potential risks to your plan, why was this risk not accounted for previously?" There may be an explanation for it, it's an unforeseen risk. However, if the response is, "Well, we really didn't think it would be that big of a deal." It's like, "Okay, well, that's still a a risk." It may be a low risk and it may change through the progression of the project, but I think mostly I get frustrated with risk management.
06:23 KL: I've circled on my notes to you that I actually want to talk to you about risk. [chuckle] So you've walked right into an open door there. So how have you seen project managers handling risk and how do you see risk in comparison to that?
06:37 BB: We do use a risk register approach, and when my project managers come brief me, one of those areas is on risk. That's one of the key items that they're supposed to address with me each time I get an update on a project. What are the accomplishments? Where are we on cost and schedule? Have we had any scope changes? What are the upcoming activities? And where are we on the risks? We will see those risks go up and down in what we anticipate the probability of their occurrence. We see the severity of the risk if it's realized, adjust as the project moves and as more information is gained during the project. But I wouldn't say there's much of a disconnect on risk. It's usually the unforeseen things or the not considered risks.
07:31 KL: So you think the risk management approach is actually effective or sensitive to the variables that it purports to see?
07:37 BB: It is. It is dependent somewhat on the experience of the project manager and the team that surrounds him or her, and I think that's why when we look at the certification of project managers, whether it's in defense or in energy through the Federal Acquisition Institute certification process, is that there are different levels. Because as projects get larger and more complex, you need a project manager who has enough breadth of experience that he or she can account for a broader set of potential risks. In a small project, it's relatively simple and the risks probably aren't that critical to the success of the project, but as you get into larger and larger projects, not only on the dollar value, but on the complexity or the significance to your mission, some of the risks aren't obvious. They may not be direct risks, they're indirect risks, and there may be risks that have dependencies on each other. That requires someone with experience, and I think that goes to the whole concept of critical thinking. When you start drilling into a project manager's thought processes and you run into walls very quickly, then that project manager is not likely to be ready for a large, complex project.
08:58 KL: So you just went to a skill set or a competency which is around critical thinking. It's not about one of the silos and knowledge areas, it's more broad-based. Do project managers get that in the type of training they see or is that a separate type of training and education that people need to get with that?
09:13 BB: If you read some of the academic research papers on critical thinking, a lot of them reach back into breadth of experience. If you're giving a brief and you get asked about a PowerPoint slide you've developed, you ought to be able to answer the question. If there's a follow-up question and you can't answer it, then your knowledge is pretty shallow. Being able to answer that third level question, generally gets you out of further questions. And the same thing goes with projects and risk. "Have you considered this?" "Yes. In fact we did X, Y, and Z." "Okay. Well, now I understand the logic behind that answer." I really think that comes with breadth of experience. If there's one thing that I think has helped me be moderately successful is the fact that I've had a lot of different jobs and a lot of different occupational areas, and so I bring those to an IT project. I ask questions around things I may have learned in physical security or weapons or facility operations or something else.
10:18 KL: Now, are your projects largely in isolation or largely in your control, the control underneath your organization, or do you have stakeholder influence or are they just a risk?
10:28 BB: Clearly, the stakeholders always impose a risk to the project that has to be managed. Whether stakeholders show up as a line item in your risk register or not, but sure, there's an owner, there's a project manager. But that project manager has to ensure that the stakeholders buy in, and that goes back to managing the delta between expectations and perceptions. And particularly because the boss, the one who may own the outcome, has an expectation. The project manager's perception may be perfectly aligned with the boss' expectation. But if the stakeholders who are going to support the project along its path and support and celebrate the delivery at the end, if their perceptions aren't the same or managed or realigned where necessary, then the project generally doesn't come off as a success.
11:26 KL: Who owns that expectation setting, the boss or the owners you just described, or the project manager?
11:32 BB: It's mostly incumbent on the project manager to do that.
11:34 KL: Yeah. So you see them as executing that?
11:36 BB: Right. It's their job to execute. I think it's the boss' job to question and poke at the project and the progress and ask the hard questions about, "Are these things coming into alignment where they were perhaps not aligned?"
11:57 KL: And then the punchline. Bob reflected on, "If project management had never been invented, do you think you would have been as successful as you have been?"
12:05 BB: I would say no.
12:06 KL: No.
12:06 BB: Maybe we would have figured it out through common sense, but I like to joke and say that if common sense were true we'd all have it. [chuckle]
12:16 KL: Right. Not so common.
12:17 BB: Not so common. I think project management helps instill that common sense and the structure that's necessary to be successful.
12:28 KL: Special thanks to today's guest, Mr. Bob Brese. Our theme music was composed by Molly Flannery, used with permission. Post production performed at Empowered Strategies, and technical and web support provided by Potomac Management Resources. I'm your host, Kendall Lott, and until next time keep it in scope and get it done.
12:48 S?: Final Milestone.
About the 'Project Management Point of View' Podcast Series
© PMIWDC and Kendall Lott
This podcast series is a collection of brief and informative conversations between MPS President, Kendall Lott, and a wide variety of practitioners and executives. His guests discuss their unique perspectives on project management, its uses, its challenges, its changes, and its future.