Culture, Trust, Communication Critical for IT Modernization Success

 

 

 

 

In the final  segment of a three-part video discussion, Nathan Brewer, Group Vice President for Sapient Consulting Public Sector, Chad Sheridan, Chief Information Officer at the Agriculture Department's Risk Management Agency, and Jeff Weiner, Deputy Executive Officer of the National Institute of Diabetes and Digestive and Kidney Diseases at the National Institutes of Health, weigh in on the critical role of trust and communication both inside and outside of the organization to successfully achieve your  IT modernization goals. 

See full transcript below. To view all three panel segments, please visit federalnewsradio.com/sapient.

Jason Miller:  Welcome back to the panel discussion "Driving IT Modernization in Government" sponsored by Sapient on FederalNewsRadio.com and 1500 AM. I'm your host, Jason Miller. My guests today are Chad Sheridan, the Chief Information Officer of the Agriculture Department's Risk Management Agency; Jeff Weiner, the Deputy Executive Officer of the National Institute of Diabetes and Digestive and Kidney Diseases at the National Institutes of Health; and Nathan Brewer, the Vice President for Sapient Consulting Public Sector.

We ended the last segment on a very interesting idea e about communication internally and curmudgeons. I'm glad we got that word out there. It's one of my favorite words. Jeff, you were about to talk a little bit about trust and this idea that it's not just do it because I said so, but do I have trust in the leadership? Talk a little bit about that trust piece.

Jeff Weiner: As we are trying to deploy technologies and as we're trying to support the mission, one of the key things that happens is there has to be trust between the community of users, the stakeholders, the people who are using our technologies and the technologists. IT is no longer a group of people behind the curtain. You've got to find a way to bridge that, and so what our community has to understand is that we're really trying to help them, that we're doing this for them and that it's a service orientation. It's almost like you flip it around. We're not the wizards anymore. We're the service providers to try to help make things happen that they want, and that trust extends between us and our community as IT people. It also extends between us and the companies and organizations that we partner with, whether it's the cloud providers or whether it's a consulting firm like Sapient or whether it's other government agencies.  I think one of the comments that was made earlier is that people are working from a place of goodwill, where you anticipate people are going to want to do the right thing. I think that does make it easier, and the rest is for us as leaders to keep promoting that.

JM: I think you make a good point. Not to start it from the place of goodwill but the provider. I think that's been the shift from the IT perspective, from the CIO's perspective that I've seen over the last maybe five years. Chad, talk a little bit about how that's shifted at RMA.

CS: Well, I think it's more than just being a provider. It's moving beyond provider to partner, and part of that is we have to build a trust that we're going to do what we say we're going to do, and when we don't, we own it. So we've kind of vacillated in IT between this idea of, “Hey, we know our business, we're just going to go do our job and that's it.” You know you're going to get what we get, or we're a doormat and we're going to give you everything you asked for, everything you say, and we're either a position of obfuscation or a position of we're the low man on the totem pole. So we need to find a balance that says, “Hey, we're going to stand up for ourselves and not go from a position of fear, but we're going to be vulnerable in that we own our issues. We're going to tell you where our problems are and what we're doing to fix them, and if something goes wrong, it's ours.”

So we build trust by being vulnerable, by listening and by trying to understand what people's problems are. That’s not from a position of defensiveness, but from a position of, ”I'm here to help.” If we can do that without being doormats, now they go, “‘Hey, if this guy screws up, he owns it, he's going to fix it, and we can hold him accountable.” So it's kind of that idea of we're going to go first, not just within our own organization, but in the broader agency, in the broader government is I'm going to go first. If I go first, then I'm going to encourage other people to follow. I'm going to encourage other people to act without fear.

JM:  Nathan, what he's talking about is the early adopter. The champion within the business. You hear that very often, find a few champions and word spreads. Are you starting to see that? The process works, we know it does, but is it starting to catch on more?

Nathan Brewer: I think one of the larger cultural shifts in the government has been the effectiveness of the government-wide CIO council and the large agency-specific CIO councils. That culture of sharing lessons learned and also, back to Chad's point about being vulnerable, is really going out there and extending yourself.

In terms of early adopters, it's about listening to what users say and really trying to put yourself in their shoes. Spend lots of time with them and incorporate what you learn from them back into your organization. I'll never forget we had one government client once who one of their key constituents, the feedback was the internet doesn't work this way. I'll never forget that line of the internet doesn't work this way, but what was amazing about that one comment was that the client was able to use that within their organization, “Okay, this is how we're viewed by who we're serving, so this is the rallying cry of everything we do.” They were able to change that perception very quickly.

JM:  One of the things that Chad brought up, let me turn to Jeff real quick, is this idea of moving – not being a doormat but also not being the no. You've got to find that balance. Are you guys finding that balance? As you mentioned earlier, scientists are always kind of poking and prodding.

JW: They are, and the great thing about that is it makes us as service deliverers to keep raising our game, to keep coming up with better ideas, to deliver reliable services and not just talk about them. That's where, whether it's improving the quality of our staff by training and experience, whether it's building collaborations with other people who have been highly successful, reaching outside agencies or other organizations that have subject matter experts, as a group, we're just trying to deliver and be better all the time.

JM: And you bring up better ideas, and that's a great segue to this idea of user design, user feedback. We talked a little bit about it when we talked about the agile discussion. Let me turn to Chad to start us off. When you guys are looking at your systems and redesigning systems and modernizing them, since that's really what the topic is about, how do you make sure that the people who are going to use those systems are giving you the proper feedback or the necessary feedback?

CS: Everything we do when we develop a system proceeds from an empowered business product owner is in there driving the how. What's important, where it's prioritized, what gets done first. We work with our experts in design to give them ideas and possibilities and options, but ultimately the what we're going to deliver and when comes from the business first. And it's every day and every week. Then before we release anything at the end of every sprint, they're going to be testing it to make sure that we actually delivered the what and by when that was expected. So it's a partnership. They have ideas of what they want and then we bring the design centered on their needs.

JM: That becomes the partnership piece because if they say, “We want to do this,” but there's a security risk there. Let me tell you what that security risk is, and then they as the mission owner can accept or not accept it.

CS: It's extremely important to bring those non-functional discussions at the same level as the functional discussions because if you bring them in as the afterthought, now I'm taking away your needs to serve my needs. So they have to be done at the same time, say “Hey, that's a great idea. Here's an equity I've got to deal with because if I don't do that, we're going to lose our data.” Now my mission understands what happens because we turned that security discussion into a mission discussion.” Oh, if I have a security risk, my whole program goes away,” now it's as important to them as it is to us.

JM: We could talk all day about security. We know that, but I think with OPM hack, with the other problems you're seeing, whether it's Target or JPMorgan Chase or now the WannaCry, people are much more aware and cognizant of the importance of security from the mission side.

CS: They don't want to accept that risk. Unless there's a competing mission need, our mission folks don't want to accept the risk of something that's not as good from a security standpoint.

JM: Nathan, talk a little bit about what you're seeing within the government of when we talk about user-centered design. We hear a lot – again, I mentioned earlier 18F and USDS as two examples, but a lot of agencies are really doing more to reach out to their constituents.

NB: Yeah. I think the challenge with any modernization effort, and particularly with user design, user experience is, how do you bridge that gap from the IT – or from the idea to something that actually exists in terms of a system or a capability? If you were to ask any of us, okay, design a typewriter replacement, we would give you a description for either Google Docs or Word because that's what we know. So this is where, to overuse cliché, you know, you don't want to repave the cow paths. So it's really, “Okay, how do you work with your stakeholders to tease out those key things that are going to enable you to move whatever you build forward and not just repeat what you already have?”

JM: Are there certain things that work in terms of teasing that out? Because it's almost the, “I don't know what I don't know, so you're asking me how to think about this differently, but pen and paper, it's always worked before.”

NB: it's setting up a structured process to really be able to intake an enormous amount of perspectives, particularly at all levels of the organization. It's one of the things I love about how we work with clients. We're engaging from the lowest levels to the highest levels to really get those perspectives, and then also, of course, with the end users.

JM: Jeff, one of the things about getting those different perspectives is how do you ensure that you're not getting the craziest idea that's ever out there . You get this kind of groundswell of craziness that you're, like, as the IT people, “Okay, you know, we can't have the rocket ship to the moon yet?”

JW: I think it's by having a broad representation. You know, when I think of diversity, I'm thinking about intellectual diversity. I want IT people at the table. I want our leadership and our businesspeople at the table. I want our stakeholders who are consuming our services at the table. And I do want some people that are what we'll say out-of-the-box thinkers at the table. I think that is what we find over time, that you want this broadest range possible to really mine these ideas and brainstorm and think it through and pull on the threads and see if there's practicality. Something that started off as a nugget of something very strange might have turned out to be something that actually added something to the overall product.

JM: Chad.

CS: I think you add to that by doing it with product. We can do all these tabletops that you want, you can do storyboarding and all that, but if you can do that in a software development environment where you are showing them real product, you know, with subbed in things for future features, but if you can show that in real product, it's so much different. Actually, the difference of software development is you can show them something real as opposed to words on paper. Words on paper do not capture what you can do in software, so if you can get the product, that changes the dynamic of the conversation.

JM: That's been the change we've seen within the government around agile is two-week sprints or however long a sprint is, “Yeah, I don't like that, change this, this and this.” Okay, we can do that versus what's been before, which was, “Here are my requirements, come back in six months or a year. Oh, wow, we don't like that.”

CS: You change the mindset from it's a hard requirement written in – you know, on stone tablets - to I have a hypothesis of value. Let's go test that hypothesis and see if it works. If I do that in two weeks as opposed to two years, now I'm reducing risk, I'm getting to better value faster.

JM: Jeff.

JW: I would say one of the things we learned in the industry as technologists is people following best practices is that it is much better to explore things, as Chad is saying, start them early. Test it. Because it's easier to course correct early on in a project. It's much less expensive. It's more dynamic, it's more responsive, and I think that's what most of us have come to learn is that you want some fluidity in this process. It's not like the old days where you would plan something up front, build it and deliver it two years later and find that the technology or the people's needs have changed.

JM: Nathan, what we're talking about here, in many ways, is this idea of culture change, and before everyone groans and sighs, we have to talk about culture one more time. In many ways, it's defining that culture change. Talk a little bit about if you're seeing that definition changing. It's not just you've got to change the culture, but what does it mean to do that?

NB: Well, the topic of change in government's always interesting to me. I was talking to a former department-level CIO just last week, and his advice, it was hilarious. He was, like, “When people come into government from the outside and they're, like, we're here to change something, it's like there's enough change happening already. It's like get onboard, find where you can make impact.” So you know, to me, I think back to the IT modernization piece and what that does. Triggering a culture mindset of modernization isn't something you do once. It's a way of thinking. It's a way of addressing the needs of the organization and how it's serving its mission, so it's an ongoing process.

JM: I think, like security and so many other things, you have to keep that in mind. This has been a fascinating conversation but we're just about out of time so I'm going to throw out the getaway question for everyone. We've had the conversation touch a bunch of different topics, bunch of different things. If you're an agency or you're an organization who's just either starting to look at this modernization because of all the things coming from OMB and the White House and Congress, or if you're just kind of in the beginning stages, what are some of the best things, what are some of the takeaways? So we started with Chad at the beginning, so we'll start with Jeff in the end here.

JW: I would say be thoughtful. Recognize that making IT investments are very expensive. You're committed to them for some period of time. Bring the right people together. You've got to have a group of smart people that represent the broad range of technologists and business people and customers to make this happen. Do planning. Be ready. Use some project management skills. Actually have budgets, have schedules, have the fortitude to actually use them and to keep some discipline because it will help the organization stay focused, and I think that's where leadership really does have a great contribution is to keep the community together, make sure it's important and explore your options together as a community.

JM: You said bring together smart people. You said something earlier, diversity too, not just IT people, not just mission people, but the whole kit and caboodle. Nathan, you're still in the middle, so you get the middle word again.

NB: Fantastic., I would just say be realistic with what is possible. I think where technologists get a bad rap is the next whiz-bang thing will cure all our problems and be a panacea. I really think if you're realistic about the skills you have in the organization, the financial resources you have, and then use that to basically really sell what you're trying to do with leadership. I think that's key.

JM: I think the point you made earlier that modernization is never done. We kind of know that, but it's really the whole marathon versus a sprint. I hope that, as agencies are going down this path and the people who oversee the agencies understand that this is not a turn the light switch and you're good to go. I think too often that happens. Chad, take us home. Tell us from your perspective. You've had a lot of experience with this.

CS: Two things. One, the end in mind is the mission. What do you need to support the mission? So always focus on mission. Two, I love the idea of planning. Not the plan, but planning. So what Eisenhower said, no plan survives first contact with the enemies. So the activity of planning is extremely important. The plan itself, not so much. So we try to build roadmaps. What's that roadmap look like? How does our short term fit into that long game? So remember the long game, but focus your execution on the short game.

JM: How do you get people to focus on the long game?

CS: You build. They'll actually focus on building that one- to three-year plan.

JM: So is it the idea that of here's where we are today and here's where we want to be in a year, two years, three years?

CS: What's our target state? But the target state needs to be way up here, not down in the gory little details so that I know the decisions I'm making. If we want to get out of the data center business or we want to move to the cloud, our short-term plans need to map into that longer term focus.