Can IT make Uncle Sam nimble and quick?
The Affirm Roundtable
Col. Dan Magee
'Agile sends up all sorts of red flags because it seems like a new word or a new way of characterizing, 'I want what I want when I want it, and that was yesterday.' '
'OPM's Janet Barnes
Oracle's Bob Kowalski
USDA's Ira Hobbs
Interior Debra Sonderman
How agile is government?
The Association for Federal Information Resources Management and GCN recently hosted a roundtable of government and industry officials to discuss just that. The discussion was part of research for AFFIRM's annual hot-topics white paper.
The roundtable took place last month in Washington. GCN executive editor Thomas R. Temin moderated.
The 10 participants were:Skip Bailey, assistant director of the FBI's Information Resources DivisionJanet Barnes, CIO of the Office of Personnel ManagementDan Chenok, chief of the Office of Information and Regulatory Affairs' IT Branch at the Office of Management and BudgetKurt Dodd, staff member of the House Appropriations CommitteeIra Hobbs, deputy CIO of the Agriculture DepartmentRobert Kowalski, federal marketing executive for Oracle Corp.Army Col. Dan Magee, program manager for the Defense Medical Logistics Standard Support Program in the Defense Department's Tricare Management ActivityKim Nelson, assistant administrator for environmental information at the Environmental Protection AgencyDebra Sonderman, procurement executive at the Interior DepartmentTerry Ouverson, director of systems planning and integration in EPA's Office of the Chief Financial Officer.
TEMIN: In planning this talk, we came up with the word agility because it's a term we're seeing referred to more and more as a quality that should be sought by government agencies.
To achieve agility, as with any goal, you have to have the goal in mind. You have to know what it looks like. So, what does an agile organization look like? And beyond that, if your own organization were more agile, what would it look like as opposed to how it looks now?
NELSON: Well, I guess I'll start off by saying I don't think we do have an agile organization from what I've been able to see in just 18 months. It's excruciating to get anything done.
I think it was Oliver Wendell Holmes who said: 'A young man knows the rules. A wise man knows the exceptions.'
So what I've tried to do, since I really don't know the rules, is to find the people who do know the rules'but more importantly find the people who know the exceptions to the rules that allow us to do the kinds of things we want to be able to do as quickly as possible to get things done. It's not easy.
The one other thing I will say: To me, getting the agility we need to get things done involves building a team outside of my office, the Office of Environmental Information, and partnering with people like Terry in the CFO's office and our programs and our regions. Because to me, it's all about partnerships.
TEMIN: When you go from a Democratic to a Republican administration, does the agenda change in the area of the environment?
NELSON: You know, not as much as some people might think. I asked that question before I ever came to EPA, before I even thought I would ever come to EPA, because I did a lot of work with it on the state side.
But the staff in the organization really saw the direction of the agency being relatively constant in terms of its mission.
DODD: I would like to jump in and just build upon what Kim just mentioned. The agency doesn't seem to have changed its focus with administrations. The mission didn't change.
And to that extent, I'm not sure that I would concur with the mission agility aspect. But I'm very comfortable with a need for agility within an organization, within the agency, and the need to be able to respond to emerging technologies and incorporate whatever is important to get your job done better.
BAILEY: When you think about an agile organization, there are really two components: One is a mind-set within the organization. And the other is the ability to deliver.
I think it really requires both of those.
And I have limited experience in federal government, also. I'm coming in from outside, from industry. But I'd say that both of those are areas that need vast improvement within the federal government'clearly within the FBI.
And I think the way you can achieve that in part is'it's a tired old term'through empowerment, by pushing the decision-making process down in the organization, which is again countercultural, I think, in this town.
HOBBS: My sense is in the Agriculture Department, we're at our very best in an emergency. And you need only go back and look at 9-11. You need only go back and look at major forest fire outbreaks.
You only need go back and look at food safety issues in this country. And what you see is an organization like Agriculture transforms itself, from what appears to be a bureaucracy that's holding everything very tight, to an organization that moves very quickly to deal with a very specific problem in a very, very efficient way. And that is the agility of the organization.
A lot of times when we're operating day-to-day, the democratic process allows for everyone to be inclusive.
Our senior leader came to us and said, 'Get it done.' Not the usual, 'Send me papers,' or, 'Keep me informed on every step,' but 'Get this done.' And so I think then there are windows in the government where agility is very clear.
MAGEE: I would echo that. I mean, you can use the Defense Department as an example. When we have a major operation, it's very clear what the mission is.
There are a number of things that occur during peacetime, such as oversight and prudence, where you're making value trade-offs between a task and mission and whether you're doing it effectively, efficiently and being good stewards of scarce resources.
But all of a sudden when you have a very clearly defined mission that's of very high value, you can make value decisions very quickly. The cost of sending that jet now becomes inconsequential because you have a tremendous value that you were trying to achieve.
TEMIN: Janet, tell us about agility at OPM. How could OPM be more agile, or what would it look like if it were more agile, or is it agile enough now?
BARNES: I'll tell you, the word agile sends up all sorts of red flags for me. I think it's because it seems like a new word or a new way of characterizing, 'I want what I want when I want it, and that was yesterday.'
I totally agree with Ira and Dan that in an emergency, the government reacts very quickly and effectively. No question.
But on a day-to-day basis, to build in agility, you have to ask how much agility and at what cost. And the government is not the same as the private sector in this regard.
But in thinking about the organizational pieces, I think there are several that come to my mind. One is, perhaps, the work force structure issue. We have to think about the balance and how we use our work force. What are the appropriate roles for government? And then what are the appropriate roles for vendors and contractors in terms of delivering service?
I think we need multiyear, quick-reaction task orders. I think we need to think about how to appropriately use the balance of contractor, staff and in-house resources.
We have got to be experts at using what's already been invented. We need to look at what exists in the private sector, what exists in the public sector, take advantage of it, and, if it meets 90 percent of what we need, go with it rather than trying to customize individual commercial, off-the-shelf solutions to meet that last 10 percent. It may not be worth it.
CHENOK: I think that Janet has laid out a terrific set of factors that create an agile organization, so I would actually agree with her diagnosis, I guess. But I would suggest that those are indeed factors that are necessary for agility within the government generally.
I agree totally with where Ira and Dan were coming from with regard to a crisis, and the fact that the government has demonstrated its ability to respond well and quickly.
The question is: How do we, given the rapid pace of technological change, take the best of the characteristics of those situations and apply them to the day-to-day work? I don't see that we necessarily have to throw up our hands and say, 'The government is in a different place when there's not a crisis.'
I think that the other point here is the part about knowing the customer. As we see more and more Americans using e-government and expecting rapid reaction from government, I think there's going to be a greater demand for us to operate more quickly'even in our day-to-day activities.
KOWALSKI: My thoughts dovetail on a lot of the comments that I've heard.
You have to be extremely agile to redeploy resources to solve that problem, or you perish. It's literally a matter of layoffs and things of that nature that we'd like to think that we've done a pretty good job of avoiding.
But there is very little time in industry, and there's very little time when it comes to a crisis. The question that I would throw back is: How do you get that mentality for problem solving?
Every three years, your federal financials product has to be recertified. There are a limited number of months to do that. We have to have a matrixed organization, which I heard brought up, which is key.
But you need communication across that matrixed organization to make sure that, in this case, the development organization delivers what you need when you need it. So there's a lot of trust that goes into that.
The bottom line is you have to have that line of communication that cuts across that matrixed resource pool to solve that problem and to solve it in a timely fashion.
SONDERMAN: We talk about our ability to respond to emergencies, and we spend a lot of time thinking about this in Interior, because, with Agriculture, we operate the National Interagency Fire Center. We train people how to do that. We train those people how to manage.
In the homeland security discussions they are looking at the Interagency Fire Center as a sort of cadre of managers who know how to take complex problems and solve them quickly, pull a team together, figure out what kinds of resources we need and then act.
Well, those skills in managing in an agile way are things that we train. So one of the things that we're doing within Interior is looking at how we can share that crisis management or emergency management training to a broader group of managers so that they'll be able to take on problems in a more agile way and deal with it.
BAILEY: I think the key ingredient if you have repeatable processes and good management is still the ability to have good judgment. We respond to crises really well, and we do things by brute force really well.
We throw a lot of people at it and solve a lot of problems. What we don't do well, I think in general, is to build quick, elegant solutions to the normal kinds of problems and the day-to-day kinds of problems.
BARNES: I believe strongly in an art form I feel is lost to a great extent: a structured system methodology for delivering from requirements straight through to delivery, and through the lifecycle of the system.
Properly employed, it can help you very quickly define new requirements, deliver them, make expectations clear and minimize redo.
TEMIN: I think implied in what a lot of folks have said is that if you're really good at having sound day-to-day processes, you'd probably be better in an emergency as well.
CHENOK: A lot of what I would say is agility is people just understanding what's going on and knowing what their roles are and knowing they're part of the team.
Then, if something comes along that requires people from different organizations, from other teams to react quickly, this could require sort of irregular meetings of staffs from different organizations, just to communicate what's going on, where you get different parts of different divisions together in teams'not necessarily because there is a crisis, but because you want to be able to handle a crisis well.
MAGEE: In my mind, I have to draw a distinction between an agile organization and agile leadership. And this can get kind of flaky.
I want an agile organization; but from my perspective as a program manager, what I need is absolutely persistent leadership.
OUVERSON: I'd say in addition to persistent leadership, I think a lot of this is really about persistent change control'knowing what change you want, having the mechanisms in place to control the change and to guide the change.
TEMIN: How can vendors help?
BARNES: When I think about the vendor community and the role it plays, there is an attitude or a viewpoint that has to be shared, which is: Can we engage our industry partners, in a sense, in the creative problem solving rather than just buying their bodies to do work?
That takes the government being willing to engage in dialogue. I want a vendor to work with me who is willing to understand my infrastructure and work within it rather than impose theirs on what we're trying to do. So, in effect, I'm looking for an agile organization on my contractor side.
NELSON: I would like vendors to be a little bit more aggressive in some situations.
I've seen too many situations where I think the vendors are just going along with the client. This is what the client is dictating, and the vendor is going along with it. And I think they need to be a little bit more aggressive with the client or be willing to kick things up.
I have one particular case where I have a program that's been working on a system, and it's three-and-a-half years between intervals of deliverables. Well, that's not acceptable.
SONDERMAN: One of the things that we're trying to do in the acquisition community as part of our move more toward performance-based acquisition, is to try to get people to think about the objectives that they're trying to accomplish.
What's your problem that you're trying to solve? Don't tell industry what solution you want. Tell them your problem and ask them to bring you a solution. And it's amazing how much more creative things you can get. So I think it's out there. But we're our own worst enemy.
OUVERSON: In the area of financial systems, I agree with a lot of what you said. But the federal government is still 20 percent of the market, and the COTS packages are not designed with the federal government totally in mind. And it does require some adaptation they can be used.
So while I would like to be able to sort of bring in a commercial solution, at least in my area, it's not always possible.
MAGEE: We had the most success when we've found a vendor who knows what their strengths are, is willing to partner with other vendors when they realize that there are other strengths and that everybody wins when you achieve a success.
I find that you really have to have an integrated spiral development process. Throwing our requirements over the transom and putting all the risk on the contractor did not work well for us. And it has to be very much a partner-shared-risk endeavor.
HOBBS: I think this whole process of government and vendor relationships is a dual-edged sword. On one hand, I think the vendor community supports the notion of our agility.
Now, as we move more toward consolidation, as we look more at really honing our profession in terms of enterprise architectures, that clearly starts to consolidate how we buy, where we go into the marketplace singularly as opposed to a thousand little offices buying from a thousand companies.
We will see the conflict and the tension between government and industry increase because the marketplace isn't going to support everyone in the way that it does now.
On one hand, they want us to be more efficient, they want us to be more agile, because they're taxpayers. OK?
On the other hand, then we start hitting at some basic issues: Which companies will thrive and which companies whose own agility will allow them to thrive versus those that will fall by the wayside. That is where we'll start to see the other side of the sword.
CHENOK: Do we promote agility by having a thousand different contracts in hundreds of different agencies for the same sort of small types of things? Or do we promote agility by being a more stable buyer at an end-price level ... taking advantage of the best thinking in the vendor community for creating the innovative solutions that we all need to create the agility to achieve the mission?
KOWALSKI: I'd like to throw some comments back that I heard from Mark Forman [OMB's administrator for e-government and IT] at one of his presentations: For every dollar of software, it takes between $5 to $7 to implement a commercial enterprise resource planning solution in the marketplace. That sounds kind of high, but that's the reality. In the federal government, it's $20 for every $1.
BAILEY: The disparity in cost of implementing a COTS package in the government and the private sector is precisely the willingness to change processes.
You know, you normally would say that you want your business needs and processes to drive what software you use. But you almost have to reverse that process and say you better be willing to fine-tune your business processes to match the software.
If you're really hosed up about how to use a general ledger, then you've got some real problems and you ought to do what is best practice, which is usually built into the ERPs and so forth.
You may have specific areas where it really does matter, because you're unique and that's your mission. But I think there are far fewer of those than there are of the other kind.
TEMIN: From OMB, we're hearing three terms quite often: business cases, project management skill and enterprise architectures. Do these aid in being agile?
BARNES: Considering my remarks in general today, I believe structure and processes are critical to agility.
To the extent that you really have a good enterprise architecture and take the time to do it, it helps guide your technical standards. It helps set your framework for doing business, so you're minimizing learning curve.
And a third point on information sharing and system sharing: Take advantage of what's already done so that you do not need to re-create. You do not need your own payroll systems. You do not need your own travel system. You do not need your own procurement systems, necessarily.
NELSON: I think things like architecture, in particular, support agility, because what it does is allow you to build core components that can be reused many times.
I saw that from state government experience. While it was difficult getting to the first phase doing all the integration, once we were there, our ability to roll out solutions was tremendous because we had the enterprise architecture in place. And the same goes with project management.
That's what these e-gov initiatives are doing for federal agencies now, saying, 'I can provide you with a solution, and you don't have to build it.' That's tremendous.
TEMIN: Dan, would it be fair to say that something akin to the agility of agencies and quicker rollout, as Kim talked about, was part of the thinking behind the architectures, business cases and sharing of resources?
CHENOK: Yes, as an organizational imperative, that's right. It's the government acting together more effectively'to serve the people by leveraging technology, to do that in a collective manner and to create better performance.
HOBBS: There's the hidden portion that we don't talk about as much in terms of these imperatives and that's the impact that it's having on our culture.
We're being pushed in the direction of not only working as a team, but also really teaching what team performance is all about, be it resources in terms of money, dollars or whatever else. That's critical.
I think that's the hidden value of what we're getting out of this'this change in the government's culture about how we do our work and who is our co-worker, so to speak.
DODD: I certainly hope that Ira is correct that we will see this as a turning point.
MAGEE: Can I throw one dart in this? Nobody can argue with program management skills and business cases. So the devil is always in how you implement them. And what I've seen, now we have four or five different flavors.
We have an OMB business case. I have DOD-acquisition-imposed versions of business cases. There are congressionally imposed versions of business cases. So, thank God for Microsoft Word, so we cut and paste all this.
BAILEY: We're confusing means with ends. And these are clearly a means to an end. And some are treating them as if they're ends.
Enterprise architecture might be a good example of that. If you view that as the end, then you're going to create this elaborate, voluminous, beautiful piece of work that will sit on the shelf and be of no value.
CHENOK: I would agree entirely with Skip there. They are tools. They're good repeatable process tools'if you will harken back to our earlier conversation'to get you to a modernization goal that's about better service and better performance.
TEMIN: Let's move on to the issue of silos.
SONDERMAN: One way to break down the silos is to share common performance metrics. The goal of contracting is not to have a perfect contract; the goal of contracting is to accomplish some mission.
And doing the teaming and the partnering with people, working on projects together is the best way that I've seen to actually break down the silos.
MAGEE: I would agree. People complain about silos, but you've got to organize an organization some way to achieve complex missions and doing it functionally probably makes more sense than most ways to do that. The key is to get most of those functional communities pulling in the same direction.
HOBBS: You've got to have something that you can point to and say, 'Here's where I belong, but that's not where I'm locked up and chained to.' And so being able to look at interdisciplinary activities, both within your department and outside of your department, is critical to where we're going.
OUVERSON: Technology is not on the list as a way to break down silos. And I think that's correct, and yet oftentimes that's the solution we seek: 'Buy me some new middleware to connect my applications and hook up procurement to payments.'
KOWALSKI: It's looking at what is the mission and what are the key processes and who are the key stakeholders that own bits and pieces of that process and bringing together a cross-functional team that would look a lot like the people in this room'because you have a cross-representation right in this room.
TEMIN: How do you balance information sharing and security?
CHENOK: There are three pieces. At the top is what I call good policy, and we can do that through issuing a policy that allows for secure sharing appropriately.
The second piece would be good security programs within agencies.
And the third thing, I think, is good technology. You know, this is an area where I do think technology can be more of a key part of the solution than maybe the people on the process side because secure authentication technologies, well-done Extensible Markup Language use, data-sharing frameworks, peer-to-peer and distributed decision-making type technologies are about grabbing data rather than collecting it at one place. They are all things that allow for greater agility.
MAGEE: This is where industry could help us tremendously. If we could get agreed-upon standards that COTS solutions are built to and everybody recognizes the same certification processes, that would make it much easier.
BARNES: I think it really starts with stepping back and looking at your entire infrastructure and approaching it from a security standpoint, so that when you're actually developing or evolving that infrastructure, you build in security as much as you do office automation and desktop support in your system development approaches.
KOWALSKI: What about the insider threat? Most of the violations are from insider threats. And unless the security policy is enforced at the data level, you've got issues there.
TEMIN: Well, it's fair to say that the biggest security data breaches have come from people that we trust.
CHENOK: It's about management training.
TEMIN: In this whole area of achieving agility and management imperatives, what kind of training is required?
HOBBS: Well, you know, there's never enough training, Tom.
BARNES: A follow-up comment occurred to me earlier and that has to do with the leadership and the culture change.
Underlying a lot of what we've been talking about, of how the government becomes agile, requires partnerships to be able to take advantage of and see other opportunities that exist maybe not within your own organization.
I don't need to own the iron, as we used to say about owning a data center, but I don't think that comes naturally. Now, I think OMB; I have a growing appreciation for some of the leadership strides that I perhaps didn't appreciate about a year ago in terms of actually forging this governmentwide look.
And I don't think it comes naturally. So it's a little off point, but I think that's where we need to be if we really want to create an agile government.
NELSON: Training didn't strike me as a need as much as having the employees see others model the right behavior.
I'll give you an example. We did a major procurement last year through the General Services Administration's Millennia contract. There was a lot of consternation within our organization about that, from our own procurement staff, because they felt we were bypassing them.
Somebody shouldn't feel they're being penalized or take that negatively if somebody else behaves in an enterprisewide manner.
So what we tried to do in turn was say, 'OK, our next major procurement we'll try to do in-house and create an enterprisewide procurement vehicle that other agencies can use,' so our procurement office got the benefit of that.
And that's the kind of culture that's still there. We have to model different behavior.
MAGEE: That's true. Never be surprised when people do things in their own self-interest.
CHENOK: And we view some of the e-government monies through the CIO Council and through the fund to provide some of that crosscutting support as rewarding of behavior that cuts across agencies.
I don't know whether the Office of Personnel Management publishes governmentwide standards for how agencies are supposed to do that or not.
BARNES: Not at a detailed level.
CHENOK: But at a high level?
BARNES: Well, they encourage, for example, performance-based appraisal systems, but you can have a whole set of different ones.
CHENOK: I mean, it might be part of a human capital agenda discussion to basically say, 'Have you collaborated?'
TEMIN: I'd like to ask a final question. The IT infrastructure that supports all of what government does has been described as the flimsy cockpit door of the IT world. How can we fix that, consistent with agility?
DODD: I might also build on another comment, that infrastructure can tie you down. If you've already bought into one system or a software package or some technology, then that kind of defines and may create a particular path that you have to follow for certain functions. I don't know that I would agree.
We should have flexibility, and it shouldn't be dependent on a specific technology.
HOBBS: Our infrastructure in many instances has been created by happenstance, convenience of opportunity as opposed to a very-well-thought-out and structured approach.
We took advantage of funds when they were made available, and we did what we could, not necessarily because we had a modernization effort that guided us. What we need to do'and that's left us in a lot of instances somewhat ill-equipped'is to meet the demands that the citizens in this country now are imposing on us. So to a large extent now, we are scrambling to do what needs to be done.
CHENOK: I'm one of those people who builds the truck that runs on the highways. And I think one of the dangers of our business case approach is I'm always evaluating the truck; we are always making decisions about the truck, and we tend to ignore the highway.
NELSON: One of the reasons we have the problems we have in government is people tried to do everything within their domain. And I think more and more, we've realized that with outsourcing we don't need to do that.
So if as organizations we focus on our storefront business, whether it's defense or serving the agricultural community or protecting the environment, and get out of the back-end business and outsource more and more, then we fix this problem because we'll get the agility we need.
With our new performance-based contract, for instance, I can turn around now and say: 'This is the standard you have to meet. I don't care how you meet it. I don't care if you have to go out and buy five more new machines. I don't have to deal with that procurement. This is the standard you have to meet.'
That's going to allow us to keep up with technology. It's going to allow us to be agile to support our front-end business.
CHENOK: The highway analogy, I think, is a good one. And I think what we've gotten now is an infrastructure layer that is a layer of like cobblestone, pavement, cement. As Ira said, it gets built up over time. You know, we don't have a smooth road.
How do we trade off together to provide that framework that can allow for the agile mission-based, outward, customer-focused stuff to ride more smoothly?