Infrastructure needs a structure

What's more

Family: Wife, the former Annik Aeschbach of Hegenheim, France; children Amanda, 14, Briana Noelle, 10, and Colin Marshall, 7

Last movie seen: 'Spider-Man'

Car: 2000 Ford Focus

Pet: Reeses, a black cat

Special activities: Singing in his church's worship team

Motto: 'I come not to be served but to serve.'

Ronald Miller, FEMA systems chief

(GCN Photo by Henrik G. DeGyor)

Ronald Miller had three months to settle in at the Federal Emergency Management Agency before having to deal with the greatest disaster in American history. He took over as the agency's CIO and assistant director in June 2001, about a dozen weeks before the terrorist attacks posed one of FEMA's biggest challenges.

He oversaw IT systems as FEMA workers toiled to coordinate emergency services in New York and Arlington, Va. Miller since has placed an emphasis on information security and process improvement within FEMA.

Among the efforts he has overseen are a server consolidation and creation of a Transformation Office.

Before joining FEMA, Miller was an IT project manager in Tampa, Fla., for Pricewaterhouse-Coopers Inc. of New York. He worked for Science Applications International Corp. from 1992 to 2000 in Florida and Stuttgart, Germany.

Miller served in the Air Force as an intelligence officer from 1983 to 1992, attaining the rank of captain.

Among the posts he held were deputy director for intelligence of the Tactical Operations Center at Patrick Air Force Base, Fla., and chief of the center's Special Projects Division.

A native of Lake Charles, La., he has a bachelor's degree in political science from Texas Tech University and a master's degree in international relations from Troy State University.
GCN senior editor Wilson P. Dizard III interviewed Miller at FEMA headquarters.

GCN: You have created the Transformation Office to oversee changes in IT at the Federal Emergency Management Agency. What does it do?

MILLER: It starts with strategic planning. FEMA has a strategic plan, and we want to ensure that its IT strategic plan is an extension of that.

I want everything we do in IT to be consistent with FEMA's missions, goals and objectives. If it isn't, we have to ask why we are doing it, and we have to reallocate resources to the things that are critical.

Once we have the strategic plan in place, we will redo our enterprise architecture. We are one of the few agencies that have actually published one, but a lot has happened since then, and I am looking for a document that is going to reflect the current situation. Decision-makers within our organization must be able to easily see what path we've taken.

Beyond writing documents and strategic planning, the office's biggest responsibility is going to be change management.

GCN: What are FEMA's difficulties in managing change?

MILLER: We are trying to take a culture that has been largely inward-looking and reactive in nature, and we are trying to put in place structured processes, planning, testing and evaluation. We want to use best practices that ensure what we deliver to our customers works and works consistently.

For example, we recently bought 60 copies of The Project Management Body of Knowledge, a book by the Project Management Institute that is recognized as the bible when it comes to project management. This is the way we want to implement systems.

I have found that because FEMA is trained to respond'to react'the culture has really infused the way we do systems development. People react based on a deadline. They have a deadline to build something, and they rush toward that.

There's no planning on the front end, no structured project management in the middle, and no testing and certification at the end.

All the problems you read about with FEMA systems are directly the result of not having processes in place to make sure that we are checking ourselves every step of the way.

GCN: How do you solve these problems?

MILLER: We have to develop projects incrementally and methodically and get to the point where, when we have a problem we know exactly what is causing it, we trace it back and fix it. We must continue in that methodical fashion until we deliver something that is going to work consistently.

If we don't do those processes on the front end, we end up wasting time on the tail end trying to fix problems and deal with crashes and other things that keep us from getting the job done.

GCN: You have created a new office to oversee and centralize security functions. How's that working out?

MILLER: The biggest consequence is that it takes everything IT was doing in the area of cybersecurity and puts it under one person, puts all the activities in one place and ensures that the individual who is heading that office reports directly to me.

I have elevated security to one of the more strategic areas that we need to cover.

We have hired a new chief information systems security officer, Steve Schmidt. He came from the Interior Department and before that the State Department. He's got an excellent grasp of enterprise security.

GCN: Are you considering implementing seat management at FEMA?

MILLER: We are in the final stages of a total-cost-of-ownership study. Gartner Inc. [of Stamford, Conn.] is conducting it.

Based on the study, we will determine whether we want to move to a seat management model. We are waiting to see what the report comes back with.

If Gartner believes there is a positive return on investment in doing seat management, that will certainly be a factor.

The biggest reasons why I am looking at seat management are to manage assets, configuration control and lifecycle replacement. None of that exists right now for FEMA equipment.
If I know there is a standard configuration with standard software for all the PCs in the agency, that eases my total cost of ownership in terms of having to train people to maintain and provide help desk support.

Secondly, if I have configuration control, I know exactly what's running on those machines, and I can manage them better.

Lifecycle replacement means I can refresh equipment on a regular basis so that we don't have a situation where some people have the latest PCs and others are running 450-MHz machines.

GCN: In consolidating FEMA's servers, you said you eliminate systems if their use could not be justified. How many did you cut off?

MILLER: I'm not sure the number we cut off. There were at least five or six organizations that didn't report to us. I don't know how many servers that represents, but we did turn them off.

That got the response we expected, and gradually they started working with us. We started bringing them back online or recommending to them that they consolidate on a single server.

We're going to do more consolidation. It's a central component of how we're trying to clean up the FEMA IT enterprise because we duplicate spending, we duplicate data, we duplicate a lot of things, and we can't have the luxury of doing that.

GCN: Are you going to use metrics to measure the productivity and effectiveness of software development?

MILLER: Yes, absolutely. We are looking to the Capability Maturity Model from Carnegie Mellon University as a way of providing metrics in software development.

When we bring on a contractor to develop software, we want to know that they at least have that kind of certification. We want to know that they are going to apply proven best practices.

GCN: If you were to guess your organization's CMM level, what would you say?

MILLER: Zero. [Laughs]

GCN: How will you avoid requirements creep?

MILLER: We are instituting a project approval process. The idea behind it is that no dime will be spent and no person will be assigned to a project until it has met certain parameters.

Once those parameters have been met, the project is presented to an information resources board that will determine whether the project proceeds.

One of the parameters is the requirements because we've found that once a project starts, requirements continue to be submitted, creating delays. Projects must have a clear beginning and end.

When you add a new capability or upgrade an existing capability, that constitutes a new project. The upgrade and its requirements have to be defined up front. Everything has to be documented and defined before a project starts.

Once the project starts, it's locked down. If there are new requirements that come up as the project progresses, those are for the next project.

Stay Connected

Sign up for our newsletter.

I agree to this site's Privacy Policy.