Dat Tran: IT and business divisions have to work together to achieve customer satisfaction. (Rob Curtis/Staff)
Dat Tran was appointed as the deputy assistant secretary of Veterans Affairs for data governance and analysis in May 2011 where he oversees the national Center for Veterans Analysis and Statistics and the Office of the Actuary. He leads the effort to implement data governance across the department’s eight primary business lines to ensure VA’s data is accurate, reliable and accessible. Previously, Tran held other positions leading data analysis and statistical activities within the department, served as a professional staff member on the Senate Veterans Affairs Committee where he oversaw VA’s IT programs, and served as the manufacturing operations manager for a Milwaukee-based electrical products manufacturer.
“My background is in industrial systems engineering. I didn't start out as a data guy,” Tran says. “I started out as a businessman. Because I came from the private sector, everything we do must be measurable. We don't make gut-feel decisions. Go and try to convince the CEO to invest $100 million or $50 million based on gut feel — you won’t even get an appointment. So that's the mentality that I brought to the government.”
As a panelist at the Informatica Government Summit conference in Washington on April 24, Tran discussed the challenges he faces in leading the effort to implement data governance across the department to ensure VA’s data is accurate, reliable and accessible. Following are edited excerpts.
What do you do at the VA?
My title is Data Governance and Analysis. So I am the consumer of the data, but I'm also now responsible for helping the department deal with the information that the consumer gets downstream. So the left side of my brain is the governance piece, and the right side of my brain is the analytic-data consumption-business intelligence piece.
We are all aware of the changing needs of government, and not only the changing needs of government, the changing way that resources are given to you to address these needs. Budgets are shrinking. The mission priorities are being reshuffled and moved around. At the core, data is still there. How are the needs in your organization changing?
We didn't build VA in one day. VA was built in the early 1900's with some business lines and then it continued to grow as Congress and as the country provided more services [such as education, healthcare, disability compensation, home-loan guarantees and life insurance]. Because of the way that we were built, we have a lot of what we call ‘silos of excellence,’ a system that caters to certain specific business lines.
A veteran coming to VA doesn't look at himself or herself as ‘I'm a healthcare user of VA,’ or “I'm a vocational rehab recipient of VA.’ They look at VA as, ‘I am a customer of VA with multiple needs.’ That is the mindset that, as a government agency, we need to shift to -- a customer- and veteran-centric mindset. And in order to do so, we need to be able to integrate and to have an environment where we have a 360-degree view in terms of the data and information that we have on our client. Basically, that is the drive that we are pushing VA to shift toward. It's probably the biggest transformation initiative or activity that we will be taking on for many years to come.
And so data is the foundation. Data is an asset as far as we’re concerned. If you look at it, it's no different than money. If you get money, and you just bury it in the mattress, it won't grow. It won't provide you any value except when you spend it. But if you invest it wisely, it will grow, and you can use it for multiple needs and you can expand your spending potential. And, that's how we view data assets in the VA: How we can take that data, transform it into information that can help decision makers to make better decision, policy folks to make better policy, planning folks to plan wisely with facts, data driven? So that is challenge that we see. We must shift VA from all of these silos of excellence to an integrated environment.
This isn't necessarily a technology problem. It's a “getting people to work together” problem. How are you addressing this?
When it comes to data and to data governance, it is basically people, process and technology. The old ways of doing things that I have encountered in government is either the technology folks go build a solution and then throw it over the fence and get the business folks to try to adopt it, or the IT folks have the business folks come up with the requirement and then come up with the solution for them.
But the problem is that business folks may not really understand the technologies and the new wiz-bang capabilities that are out there. They can ask for a pie in the sky, go over [budget], hand it to IT, and then IT says that we don't have money to do that, so go back and start over. So, one of the things that we've learned over the last four years — and especially in the last year and a half — is that it requires technology and business people to work together from the ground up. I'm coming from the school that IT and business is the same thing. You don't see any company out there that says that IT is a separate thing from the business. IT enables the business because without the business, IT does not need to exist within an organization.
So the first thing that we learn is that IT and business have to work together to achieve the same end goal: customer satisfaction. That’s number one.
Number two is to really understand your data. Understand your data from a business perspective, not from an inventory [perspective] of ‘What data do we have? How many bits and bytes do we have?’ Map out your business process. Whether you deal with a client or whether you deal with building a missile system or whatever. What is your business process? Map out what information is needed at each of the steps to support the business process.
And then, the next question to answer is, ‘Where is the information coming from?’ Now this is where the technology and all of this stuff comes in. What systems provide information? Who gets what at what stage? You don't just come up with the information blindly — you had to get it from somewhere. Tell us what systems you use, but don't just tell us you use system X. What information does system X deliver to you? And what system Y do you pass that information to? So the bottom line is to understand your business process from an information-flow perspective. Know where your data are coming from.
The, the third thing is that just knowing where the information is coming from is not good enough, right? You need to know the quality of your data. Now, let me caution you: Often people will say, ‘Let's wait until we get 100 percent perfect data before we go analyze.’ No. If Google did that, it would have gone bankrupt years ago. Amazon, too.
Here’s the key: Understand the constraints on your data. At least if you understand the constraints, you can make a decision knowing what your decision is based on and under what boundaries. So that's the third piece is to understand the data quality, and really to understand what constraints your data have and their completeness.
People tell us all of the time, ‘We capture X, Y, and Z.’ And then, when we go into the database, X, Y, and Z have blanks. So, that's the key: Not only knowing what data you're capturing, but how complete it is. That's where the IT and the business folks can work together to fill out those blanks, right? That's the experience that we have been running into. All of that — people, process, and technology — equals customer satisfaction. That's data governance.
The last things that we were talking about were really the challenges of governance, but also of data sharing. What are the keys that you are looking at from the data governance perspective that are going to help your organization efficiently meet some of these objectives?
From a data-governance perspective, we have a lot to do. So one of the things that we learned is that if you're going down that path, or if your organization is going down that path, look at it as a journey. Don't get even anywhere close to describe it as a project because a project has a starting and an end point. So data governance is a program, it's an initiative. It needs to be baked into the culture.
Number two is that you need to have long-term vision, but don't let that long-term vision discourage you or your senior leadership or your stakeholders. Have a long-term vision with small steps.
This is what I say to people all of the time. If you want to climb up to the top of the mountain, you see where the peak is, but you don't try to get to the peak in one step. You start small. Here's the bottom line for us, especially for those of you who are in government: We live in a political world. Many of our senior leaders are here a short time. When they leave, they want to see some achievement under their legacy. That's the bottom line to the real world. I've been working in it for 22 years. So have a long-term vision, start small, take small steps, but the key to get support, to keep that journey going, is to improve the value added to the business, whether you're in FDA, whether you're in VA, whether you're in DOD or the Education Department — it doesn't matter. If it does not show business value to the leader, they've got better things to do. Nobody wants to say after they leave four years, ‘Oh, when I left VA we put into play a process, and we hired 500 people.’ What did that do for veterans? What did that do for the organization?
So that is the business value that you need to sell to get your data governance traction and continue down the road.
My final word is that when new people come in, and good things happen, nobody will be the first one to say, ‘Oh, that thing is going so well, we're going to scrap that program.’ Everybody wants to associate with a winner. So if you have winners going, people will continue it. So that's my experience dealing in this world.
How would you respond to the fact that sometimes the business may not know what they want? How far do you go forward in advance of the business understanding what they need to develop that trust, say that analytical capability that they didn't know they need? Is that a strategy that you employ, or do you restrain yourselves from moving forward in advance of the business?
Basically we need to trust [each other]. For those of you who are in the IT world, you need to trust your business folks when they tell you that this is their requirement. But don’t just settle for a technical requirement from the business, okay? There's a big difference between a business requirement and technical requirement from the business.
To me in the business world, you've got three types of business people, at least in VA: We've got business people with data backgrounds, we've got business people with IT backgrounds, and then we have business people who actually deal with the business. Every time we have one of these data projects, we ask for a cross matrix of volunteers. We have business people, but when I look around the room, I don't see a lot of business people who are in the trench, and who understand the business process. So the key is – for those of you who work in IT and those of you who work in business — when you get together, there are different kinds of requirements. The most basic thing that you need to hit first is, ‘When I get that technology, and I use it, or my staff or the people out in the field use it, what is it going to be like to them?’
So, I'll use one quick example: Electronic health records. We're talking about building an electronic healthcare record between VA and DOD, and the question that I'm always asked when I'm in a meeting, is: ‘At the end of the day, if VA and DOD have electronic healthcare records that can talk to each other, for the VA doctor or the VA nurse down on the field, what is that like to me?’ That's the kind of business requirement that needs to be answered first and then translated into technical requirements to support the business before it goes over to IT.
And then you have to look broadly. Don't just look at your business process right now. If you need to exchange data — and I'm using like a medical example now — if you need to exchange data at some point with a private doctor, don't build a solution right now just focusing on exchanging data with one agency. Then 10 years down the road, you may find out that none of the private medical practice can talk that language. That's the business requirements I’m talking about.
I agree but on the other hand, think of Steve Jobs. He wouldn't listen to the customer because he said that the customer doesn't know what he wants until you show it to him. I think that's the advantage of IT. IT has capabilities that business people can't see. Steve Jobs showed you how to get music in your pocket. He showed you how to increase the productivity of animation and then the cellphone and the tablets and he totally revolutionized five industries because of that very concept that the customer doesn't know what he wants until you can show it to him, and then he sees it, and grabs it and says, ‘How did I ever live without it?’
I totally agree with that. And that one piece I didn't touch on is IT. You have the opportunity to educate your customer on the art to the possibility. The problem that I see in the government is that we don't do enough of that. The customers will ask for a cement boat, so we build a cement boat. We won't tell the customer that it cannot float.
I'll give you a perfect example. I know of a system where the customer said that I need to be able to see information on an applicant on the screen. No problem. We're agile, so we go and produce. Guess what we give them? We give them a jpeg! So then, we're wondering why we cannot get the phone number out of the jpeg downstream. See? Build a cement boat, you get a cement boat. So I totally agree you need to educate your business folks in the art of possibility and what is possible out there, and let them tell you what they can live with. And, you know what? They might not convert back, they might go with you with everything that you recommend in the future.