The Business of Government Hour


About the show

The Business of Government Hour features a conversation about management with a government executive who is changing the way government does business. The executives discuss their careers and the management challenges facing their organizations. Past government executives include Administrators, Chief Financial Officers, Chief Information Officers, Chief Operating Officers, Commissioners, Controllers, Directors, and Undersecretaries.

The interviews

Join the IBM Center for a weekly conversation about management with a government executive who is changing the way government does business.

Patrick Ciganer interview

Friday, February 27th, 2004 - 20:00
Patrick Ciganer
Radio show date: 
Sat, 02/28/2004
Intro text: 
Patrick Ciganer
Complete transcript: 

Friday, September 26, 2003

Arlington, Virginia

Mr. Lawrence: Good morning and welcome to The Business of Government Hour. I am Paul Lawrence, partner in charge of the IBM Center for the Business of Government. We created the Center in 1998 to encourage discussion and research into new approaches to improving government effectiveness. You can find out more about the Center by visiting us on the web at

The Business of Government Hour features a conversation about management with a government executive who is changing the way government does business. Our special guest this morning is Patrick Ciagner, Program Executive Officer of NASA's Integrative Financial Management Program.

Good morning, Patrick.

Mr. Ciganer: Good Morning Paul.

Mr. Lawrence: Joining us in our conversation is Steve Sieke.

Good morning, Steve.

Mr. Sieke: Good morning, Paul.

Mr. Lawrence: Well Patrick, let's begin by understanding the mission of NASA's Integrative Financial Management Program, or IFMP.

Mr. Ciganer: Well as the name indicates, the primary mission is to develop the financial management capability that is Agency-wide, and also integrates a lot of the factors that allow you to manage more effectively. Over time, the Agency discovered that in the case of its undertakings, which are mostly projects and programs, there is more than just cost or budget data. There is human capital; there is resources; there is assets. And the ability to have access to all of that information in a fairly seamless way is what the Agency is looking for. So, although all the word "financial" is in the middle of it, the integration component is really the goal of this specific program.

Mr. Lawrence: And what is the vision of the program?

Mr. Ciganer: The vision is to provide to management and the bulk of the Agency employees the ability to access, account, track and manage information as effectively as possible. And the information is fairly broad, so therefore, we are not just focused on one specific area of the Agency. But we are looking at the institutional side, which is the administrative side and the programmatic side. So it really is to provide an overlapping umbrella and capability to all of the employees within the Agency.

Mr. Lawrence: How do you describe the size of this undertaking? Budget, people, time?

Mr. Ciganer: The current undertaking is approximately a six-year effort. The budget is $497 million. The number of people involved average approximately 300 to 400. They vary, because we broke down the program into several projects, and some projects will have slightly larger staffing requirements. But that essentially is the scope and the timeline of the project.

Mr. Lawrence: So by normal standards this would be a large project, but by NASA standards, this is a small project?

Mr. Ciganer: It's a medium-sized project. It's the cost of one shuttle launch. But from a timeline, it's a little bit shorter than some of the probes that we will build and launch. But it fits within the NASA operating parameters. People feel comfortable looking at the size of the dollars, the staffing requirements and the fact that we are touching every single center. So we are not raising eyebrows either by being too small or too large. We are within scope.

Mr. Sieke: Patrick, let me ask you a couple of questions about the genesis of IFMP. Could you start out and just give us kind of the history behind the inception of the project. And maybe you could start with what financial management looked like before IFMP, and explain why NASA decided to embark on this major undertaking.

Mr. Ciganer: NASA has been essentially aiming at developing this fundamental capability for the past decade. This is actually the third effort aiming to develop this functionality. It started in the early '90s, where the Agency took a path that looked at developing all of that software and doing all of the integration in-house, essentially soup-to-nuts-in-house development. Unfortunately, we are a scientific and engineering agency, and for several reasons, the performance that was delivered out of the early results wasn't worth the cost. So this was essentially terminated.

In the mid-'90s, the effort was started again going to an outside organization. But the thrust was again trying to develop all of the functionality using custom code as opposed to using existing functionality that you find in packages, and trying to deliver all of the capabilities serving all of the constituencies at once. In plain English, that means that we were going to have an accounting system for the accountants; budgeting system for the budgeters; an HR system for the personnel people; a project management system for the programmatic folks, all at once. Again, this did not deliver as promised. A couple of applications were developed, but due to the complexity of the Agency's structure and the wide variety of projects and programs that we're involved in, we realized by 1999 that there was way too much code that needed to be cut in order to meet all of those requirements.

So the third incarnation of this effort, which is the current IFMP, was started in late 2000. And in this case, we decided to go "COTS" -- the commercial off-the-shelf systems. Now that is a little bit of a misnomer. We are using a COTS underpinning, which is the SAP relational database environment and their core financial application, and we are using specific applications that are off-the-shelf. But the integration effort is completely discrete to the Agency. And in some of our future modules -- we don't call them applications, we call them modules -- there is also quite a bit of development. We are using tools that are off the shelf. For example, the way NASA formulates its budget is extremely specific to the Agency, and there was nothing off-the-shelf that met those requirements. So we are actually developing using COTS tools our budget formulation capability.

So the third try is, I would say, above all, a mix between off-the-shelf functionality and some custom development. But it's learning from the previous experiences two very critical lessons: One is do not try to do everything at once. And the second is to look at your business processes. Look at the functionality of the system that you are implementing and/or purchasing and try to actually make the processes fit the functionality of the software, as opposed to the other way around.

One of the many lessons-learned sessions we have had over the past couple of years with organizations, mostly in the private sector that have implemented this type of software, was focused pretty much on what went wrong. I mean, the way we decided to lead those discussions was: success is very difficult to define, but failure is a lot easier to bind. We need to understand why you failed. When we spoke to the users of SAP, which is the core software we are using, met two very large-sized organizations comparable a little bit to us, and they came and essentially out of quite a few presentations, did define three or four major drivers on why things did not go as planned. The first one was they tried to modify the software, especially when technology companies were purchasing COTS. They know they can cut code; let me go in there.

The second is you have to make sure that the system adoption goes beyond just technical success, which means -- this is such a complex environment, having the software essentially operate correctly is only part of the story. Unless there is a fundamental effort aimed at changing the way an agency operates or an organization operates and uses the software the way it is supposed to be used, you are not going to get there. And in many cases, the system dies on the vine and you go back to the way you used to do business.

And then the third element is you've got to take essentially very measured steps. And you cannot assume that previous successes are going to decrease the amount of risk that you have moving forward.

Mr. Sieke: Patrick, you had mentioned that IFMP is a kind of a medium-sized project. But it certainly is significant from the standpoint that it impacts everything at the Agency. I'm just wondering if you could share with us your roles and responsibilities specifically around the IFMP project.

Mr. Ciganer: One of the most critical elements to ensure the success of this type of project, given the fact that it indeed touches pretty much everybody that works there, is a very solid endorsement from the senior leadership. When the program got off the ground, there was a realization very early on that the changes in some cases were so significant that unless there was the perception that senior leadership was very clearly not only supporting, but also monitoring the progress, there was a possibility for some of those changes not to take place. As a consequence, the program was established in such a way that I report directly to the administrator, which means I am responsible ultimately for the implementation and the successful operation of this series of systems.

I've got a team, which is composed of program management and project management. But essentially, I am the point person on making sure that not only there is proper visibility on the program performance and progress at the senior level of the organization, but also a proper line of communication that is clearly established between the various constituencies and the senior leadership. As I mentioned earlier, we are implementing a lot of changes. And in some cases, the way we are developing some business steps is potentially not as efficient as it was in the past. As a whole, it is a lot more efficient, but specific groups, organizations, constituencies are affected in different ways, and there are cases where things are actually turning out to create more workload, rather than less. They are far and few in between, but they are still there. And we needed to develop a way for the people that were the most affected to have a link all the way up to the top of the organization.

Mr. Lawrence: That's a good point. What are the pieces of the financial management program and how is it scheduled? We'll ask Patrick Ciganer of NASA to explain this when The Business of Government Hour returns.


Mr. Lawrence: Welcome back to The Business of Government Hour. I'm Paul Lawrence, and this morning's conversation is with Patrick Ciganer. Patrick is the program executive officer for NASA's Integrated Financial Management Program.

And joining us in our conversation is Steve Sieke.

Patrick, how has your previous experience helped you in this current position?

Mr. Ciganer: Well, Paul, in a couple of ways. One of the main, I guess drivers of the Integrated Financial Management Program is obviously the ability to tie performance and financial characteristics of specific programs and projects. I come from private industry, joined NASA a couple of years ago -- 18 months ago specifically -- and previously, I was both on the technical and systems side, and more recently I was CFO of a company on the West Coast.

So I think part of the reason that attracted me to NASA and maybe interested NASA was the fact that I was able to look at this type of implementation from both a system and a project standpoint, and also as an end user. As CFOs, many organizations look at you as both the entity responsible for delivering credible numbers, but also the organization responsible for putting in place a system to generate those numbers. One of the concerns that the Agency had, based on their previous experience, was to try to be as transparent as possible in the development of the system and get the various constituencies involved, as opposed to this is a system that we are going to build and throw at you; this is a system that we are trying to build with you, and we will roll it out with your participation.

So in my case, I started my career more on the operational and systems side, mostly working for large Fortune 50 companies in the system component of financial departments, and then over time I migrated towards more of the, shall we say, the end user of the product as a CFO. In the case of NASA specifically, about 2 years ago, I was asked to look at the space station cost overruns that had been taking place. A commission had been established, chaired by John Young, and I was responsible for developing the financial management recommendations moving forward that would potentially help mitigate some of the overruns. So that was my first exposure to the Agency's inner financial works, and as a consequence potentially of some of those recommendations, I had this interesting event take place where I was asked to help implement those recommendations. And that's how I ended up at the Agency.

Mr. Lawrence: That's terrific. Can you describe, Patrick, the main components of IFMP for our listeners?

Mr. Ciganer: Gladly, yes. I mentioned earlier we have multiple projects as opposed to trying to implement all of the capabilities at once. We call them modules. We have developed and implemented roughly half of the modules that will ultimately comprise the system, the suite of applications. We started with position description and r�sum� management, partially because staffing was and continues to be a very critical element of the success of the Agency. Above all, again, we are a scientific and engineering organization, and for us, we are only as good as the people that compose our organization. So this is not so much processing specific things, this is leveraging on individual talents. So although this is an Integrated Financial Management Program, the immediate requirements were very much to support some of the staffing efforts.

So we developed and implemented the first two modules about 18 months ago, called r�sum� management and position description. This was followed by a module called Travel Manager. Again, the nature of our organization is such that we have a lot of people spending a lot of time in airplanes, going not only all around the United States, but going internationally, mostly to Russia, but also to Europe, to Australia and so forth. And a significant amount of money is spent traveling. So we needed from a financial control standpoint to develop the capability of tracking and managing more efficiently travel costs.

Now just as a quick background, though I'd like to believe most people know who we are, the Agency is actually a very decentralized organization. The Agency operates out of 10 centers that are spread across the United States. And those centers have very specific missions. They are in charge of specific programs, projects, in the sense that a lot of the work gets done there. The program management of the Agency is center-independent. Program managers in many cases will manage undertakings that are housed at several centers. If you are in space shuttle activities, you will have work being done at Stennis, at Marshall, at Johnson, eventually at Kennedy. So you need to be able to coordinate and have insight in a variety of centers.

In space science, you have work that goes on at JPL, at Goddard. So as a consequence, our organization is both distributed and also coordinated in slightly different organizational lines; the equivalent in private industry of divisions. Divisions can have multiple plants or production areas but the divisions themselves are in a certain area. In addition to that, headquarters, here in Washington, is responsible for, obviously, not only the budget but the overall policy and management of the entire organization. And their requirement for integrated data is also quite high. So this is actually comparable to a traditional distributed multinational organization. And I should mention that we also have satellite offices all over the world. So the need for something like a travel manager application is actually fairly significant if you start looking at the coordination efforts required.

After Travel Manager, the next application that just got deployed was our core financials application. That is a very traditional product. This is what you would call budget execution from a government standpoint. This is your financial accounting module from a private standpoint. This is basically the books of the Agency.

Now this was a major undertaking, because up until now, every one of the centers that I mentioned had their own accounting system. That system was autonomous, had been usually developed or contracted or purchased locally, and really was not capable of any integration with any other accounting system from any other center. There were interfaces; data could be exchanged, but there was very little capability, for example, in the traditional consolidation accounting, where, let's say a specific enterprise rolls out their information on a specific program, you look at the information at the top and you want the ability to drill back down to a specific task. That did not exist. I mean, there was a lot of data calls where the constituency needed information from another constituency and asked for the information.

But first of all, they have to ask. And second of all, it had to be extremely well-defined, because it's the old 'what you see is what you get;' in this case, what you ask for is what you get. And the analytical capabilities were very limited. So the core financial system did two things: it retired 10 family of accounting systems. It was more than just one system per center. It also put every single organization in the Agency on a single instance of the software. Which means everybody essentially operates -- puts data in, gets data out, generates reports -- out of the same environment. That is a massive relational database, and that is for us a significant step, because the ability from any angle in three dimensions to get the information out is something that the Agency has been after for a long time and is finally able to gather.

So that is the most recent module that we implemented. To date, it has been the most complex. Because literally, it was 10 separate implementations. A good friend of mine who now left NASA warned me when I first came into the Agency and said, "You know, when you've seen one NASA center, you've seen one NASA center." So the experience that we learned out of deploying in one center had some correlation to the next deployment, but it was fairly modest. What we did is we actually broke down that roll-out into three separate waves, partially because we just did not have the resources to try to get everybody up at the same time. There is a very large training component, and we just could not muster getting everybody trained at once.

Besides that, we wanted to actually up to a point create out of the first wave a semi-pilot, learn from that, and then get the second wave to address for some of the major centers the more complex conversion issues. And then the third wave would hopefully be able to close the door fairly shortly. So the core financial module which just finished implementation of its third wave on June 23 is that the future modules are as follows: there is a budget formulation module, which is the formulation of the budget as opposed to the execution of the budget. That is being developed as we speak and is slotted for complete roll-out. In this case, it is going to be a single roll-out in a single instance Agency-wide some time next spring.

After that, we have an asset management module, which for us is also a fairly critical component. Our auditors get very nervous when we are not able to track where some of our probes are. But we tell them that is sometimes fairly difficult to verify whether or not this sensor is on that probe when it is on its way to Mars. But we should be able to at least tell them roughly where it is. So the asset management module in itself is going to be a fairly large undertaking, and then following that, we are going to have an HR module, which is really a human capital management capability. It goes beyond just personnel records and employee payroll and so forth. And then finally, we are going to take the contract administration capability and move it to hopefully some of the next technological steps that are coming down the road, which is an advanced document generation system. We're discussing potentially the use of a semantic web for more efficient information retrieval. So those are the major modules.

Mr. Lawrence: All of the work just described has huge management challenges. What are those challenges and how have they been addressed? We'll ask Patrick Ciganer of NASA to take us through these challenges when The Business of Government Hour returns.


Mr. Lawrence: Welcome back to The Business of Government Hour. I am Paul Lawrence, and this morning's conversation is with Patrick Ciganer. Patrick is the program executive officer of NASA's Integrated Financial Management Program.

Joining us in our conversation is Steve Sieke.

Mr. Sieke: Thanks, Paul. Patrick, the implementation of the IFMP program has meant a lot of changes for NASA and its employees. Can you explain to our listeners how you are managing that change?

Mr. Ciganer: We discovered very early on that the adoption of the program is not something that was automatically performed. Traditionally, especially when you have a series of processes that are perfectly capable of satisfying your requirements, there is a reluctance to try to learn how to use a new system. I mean, something as fundamental as when we get a new system on our laptop, a new operating system, we are reluctant to see the benefits. It takes us a while to get used to it.

This was magnified, first of all, 10 times, because we have 10 separate centers, and therefore, 10 separate systems that could not even be taught to take the next step on a one-size-fit-hole approach. The second thing is, this type of implementation is only as successful as the adoption of its ultimate users. We can have a theoretical, technical success. And as I mentioned earlier, unless the system potential gets really exploited by the various constituencies, we are just not achieving the ultimate goals. We discovered that change management, which is a very generic term, is something that requires a lot of attention. It's not an afterthought; it is not the purview of the softer sciences. It is not something that automatically will come to people that are in charge of training the various new users. It is actually an activity that requires not only focus, but organization, tracking a specific set of metrics, quantifying to the extent possible how some of the changes you are trying to implement are catching on.

I think that is actually the most difficult part of this undertaking, especially given the scope of the IFM program where, as you mentioned earlier, we are touching not only the financial community, but also the programmatic community, the HR community, the average individual that works at the Agency as a whole. There isn't a facet of our program that doesn't touch every single individual. So what we've decided to do is two things: first of all, we have hired who we considered were the best outside organizations capable of leading us through those steps. And our selection process there was based on their previous experience in comparable environments, and also, their ability to understand how our agency operates.

We wanted to be very careful again, because I like to believe we are special, like every other organization. But it is not because this system works in organization X that you can take the exactly the same approaches and apply them to organization Y hoping to get exactly the same results. In addition to that, self-introspection in this type of activity is very difficult. I don't presume to be able to autonomously gauge how well we are doing in implementing change. So that is why we went and we continue to use an outside set of eyes that can gauge on our behalf how well we are doing and then additional outside resources that can lead us down that path.

Now how do we really measure that change? There is empirical methods, such as the good news is we can see how often people use the various modules of the system compared to -- when people get trained to get an ID and a password in the new system, and then we can develop some generic statistics on how many users got trained, how many users are using the system on a period of time after the training. How many trouble tickets or error messages are generated? How many system questions get logged? What we did was obviously maximize the capabilities of the system to gather that information, and also set up a competency center, which is the equivalent of an ultra-sophisticated help desk. Imagine a help desk that not only can answer questions on how do I log on, but also can get into the system and take care of specific processing issues or look at relationships, look at the way the data is manipulated, the way it is stored, the way you report it.

So one of the ways we measure change is also getting feedback from that center on the level of complexity of the questions being answered. Also, as time evolves, you will have users go up the learning curve and bump into more and more complex issues. So that's in a fairly balanced way the method that we use to figure out how change is taking place. I mean, we do have customer surveys and a series of workshops, but those are not, I would say, as hard-hitting for us as how often do we have problems cropping up when the various modules are being used.

Mr. Lawrence: Patrick, one of the key components of change management, as you know, is communication. And I was just curious how you are ensuring that effective communication of all the program efforts and changes is getting out the community?

Mr. Ciganer: One of the main drivers of the program is to make sure that we are as inclusive as possible. Unfortunately, we have to be located someplace. We happen to be at headquarters in Washington. But what we've done is in every single center; there is actually a local change management team. So the various centers dial only four digits on their phone to talk to somebody, as opposed to you know, calling those characters in Washington. So that's a big step in really developing a mechanism for effective communication.

The second component is one which is more of a generic approach, which is, we Literally, whether it is the administrator or myself or any of the enterprise leaders, will personally answer any phone call, e-mail that gets sent to us regarding questions about the overall system. In most cases, the questions fall into two categories. There are the technical questions that the competency center will handle. We wanted to make sure our folks understood there was an open-door policy if you had larger concerns, strategic concerns on the potential functionality of the entire suite of applications, on the impact of changing some of the processes. So the more generic, I would say global, questions are encouraged and literally percolate all the way to the top.

So that is also one of the communication lines we set up very early. The good news so far is that we are not overwhelmed by calls and e-mails, but we'd like to believe that throughout the organization, people understand that vertical communication is completely open. In addition to that, we have created a category of superusers, should we say, of the new modules, which means in every single group, department, organization, there are folks that volunteered to us the capability of sharing their knowledge and experience with their peers.

So in many cases -- you know, and we're all like that -- it's easier to walk to the office next door, the cube next door and ask a question, rather than pick up the phone and try to call a help desk. And we've really tried to build up this informal superuser infrastructure along with business process leads in each one of the organizations. They're for the folks that are not so much technical, but that are there to try to explain the logic behind some of the steps and the changes that take place. And dealing with, again, technical constituencies, you cannot just say do it because we tell you so. They we will ask why.

Mr. Lawrence: What are some of the other complexities of the program and how are you dealing with those?

Mr. Ciganer: One of the interesting aspects of this program is the fact that we have a lot of data that gets generated now which is accessible to a very broad spectrum of users. Before, it was much more stovepiped. One of the interesting by-products is how do you turn that data into information? And specifically, in something as simple as reporting specific information related to a program or project, an initiative, an undertaking, there is so much data that is now available at an incredible level of detail, that teaching people to look at exactly the same information when they want to discuss it is actually an interesting challenge, because all of a sudden people get inquisitive and they want to explore, "Well, what if I present the information, adding this and subtracting that, then putting a time component and doing this type of analysis so I can go and discuss it with my peers?" Well, it turns out that they did not exactly attract the information the same way, so they are not discussing exactly the same data.

So one of the complexities is, we have now a very powerful tool kit. And teaching folks to make sure they use the same tools when they are trying to obtain the same results is one of the components. It is an interesting by-product of enhanced capability. The other one is a little bit different. It has to do more with an evolution of our organizational structure. Information now can be shared and is readily available throughout a whole range of different activities. The ability to extract that information, or to even develop specific models, specific scenarios using the historical data to move forward, is a lot more present than in the past. So one of the things we are trying to incite is the ability to spend a little bit of time on getting deeper into what the information is and then developing maybe more what-if alternatives.

Mr. Lawrence: How does an Integrated Financial Management Program help NASA meet the goals laid out in the President's Management Agenda? We'll ask Patrick Ciganer of NASA to give us his perspective when The Business of Government Hour returns.


Mr. Lawrence: Welcome back to The Business of Government Hour. I am Paul Lawrence, and this morning's conversation is with Patrick Ciganer, program executive officer for NASA's Integrated Financial Management Program.

And joining us in our conversation is Steve Sieke.

Mr. Sieke: Patrick, how is IFMP helping NASA implement the President's Management Agenda?

Mr. Ciganer: The President's Management Agenda, the PMA, has essentially 5 components: Human capital, financial management, procurement, budget performance integration and e-Gov. I think that I have described over the past few minutes a series of modules which, fortunately or unfortunately, touch every single one of those components. Obviously, the financial management part of that is at the core of what we are doing with the IFM program. But the human capital is right there. The budget and performance integration is the cornerstone of how do you use the financial information to be more effective in managing various programs and projects.

Procurement again is separated from a PMA standpoint, but obviously is very heavily relying not only on the budget execution, but also some of the performance data. So we believe that the IFM in its totality basically will support and enhance the capability of implementing a lot of the guidance and encouragement that the PMA gives the various mentor organizations.

Mr. Sieke: How do you measure the success of the IFMP program?

Mr. Ciganer: The adoption of the functionality of the program above all is our yardstick. I mean, there is a technical success, which is something as fundamental as the ability to close our books every month and produce quarterly financial statements and produce clear, timely robust information. I mean, that is the mechanical part of the system that shouldn't be overlooked. That's easy to measure. It's binary; it either works or it doesn't. What is more complex is to hopefully see an improvement in how efficiently decisions are made and how much information is available to make those decisions on a timely basis. I mean, one of the critical elements in a lot of the work that we do in research and engineering is in some cases having very, very short timelines to make key decisions that have very long-term impact. We would like to believe that this program will allow the decisionmakers at all levels to make more educated decisions that will result in a more efficient use of what are limited resources.

Mr. Lawrence: What do you see as some of the greatest challenges facing the project before it gets completed?

Mr. Ciganer: I think there are some technical challenges over the horizon. For example, our budget formulation model, as of yesterday's latest estimate, will be manipulating approximately 140 million lines of information. This is a real-time or near real-time system. So there are some very hardcore system performance issues that we are facing in the near term. In the longer term, I would say the asset management systems that we envision coupled with the project management capability we want to give our constituencies, are looming fairly large over the horizon.

Our agency is involved in a very broad spectrum of activities, from fundamental research to near-operational activities. And they are very different. They are all categorized as programs and projects. But there is no-one-size-fits-all tool that we can offer. So the ability to build, deploy and offer systems that can support those activities in parallel is daunting. As far as I know, it has not been required by any organization so far. So we are once again in a pathfinder position. If we were only in the space science business or only in the earth science business or only in the human space flight business, we would narrow the scope of the functionality we have to offer. And unfortunately, we are doing all of it. So those are going to be interesting challenges in the next 24 to 36 months.

Mr. Lawrence: I want to ask you to put your little bit grayer future thinking cap on, and 10 years from now, when people think back and 10 years when people think about financial management or even information management at NASA, what do you want that picture to be, or that vision?

Mr. Ciganer: It's interesting. Driving up, I was actually thinking about information management and information science, partially because it is something that permeates pretty much every facet of what we do. And taking a step back from just the IFM, what this organization is above all into the business of doing is turning information into knowledge. We are in the business of gathering information, whether it is planetary information, cosmology -- I mean, it is information. We are trying to in some case validate specific theories. In some cases, we are trying to empirically prove some of the designs that we are coming up with.

But above all, what one of our objectives is is to generate and make information as available as possible to as broad a constituency as possible. As part of that, we actually have a lot of very interesting initiatives going on in supercomputing, in nanotechnology, in intelligent networks, in smart machines -- man/machine integration. Ten years from now, I'd like to think that some of the more mundane undertakings -- and I'm not saying they're not important -- but some of the more mundane undertakings we are involved in right now with the IFM program will also benefit from some of the leading-edge information science research we are doing.

As I mentioned, in one case, we are asked right now to manipulate a massive amount of information in real-time. Although it is for budgeting, not for processing cosmic microwave background information, it is nevertheless fairly daunting. And I'd like to believe that we are back on the path where possibly we, in a decade, will be leaders on manipulating the visual display of information in something that everybody is after. And maybe in a few years from now, this system will help bring into the fold those two communities that have been running on parallel paths but not crossing that much.

Mr. Lawrence: You've had an interesting career, albeit a short one in serving the public and government. I am curious, what advice would you give to someone considering public service?

Mr. Ciganer: First of all, I would say do it. One of the things that is incredibly rewarding in working in the public service is first of all the nomenclature. It is public service. But also, you are faced with, usually, issues that are of a magnitude that is not seldom encountered in the private sector that quickly. And when we are talking about young people, when I see some of the young folks that we bring in-house and they get exposed to issues, to undertakings, to initiatives that are truly beyond the traditional corporate world, unless you happen to work for an extremely large organization.

So one of the benefits of public service is literally the ability to be exposed and to learn how to operate and eventually manage in very complex situations. There's a lot of constraints. Now, you know we are a public organization, which means we don't have to show our bottom line. On the other hand, we have to maximize the effective use of the dollars that are entrusted. The stewardship of those funds is something that goes beyond buying the most cost-effective widget. It is what is the most effective way of making those choices. And there are tradeoffs. It is not an unlimited source. And bringing young folks into an environment where those tradeoffs are consistently discussed I think prepares them not only for -- should they desire so -- a continuous public service career, but when they reintegrate to the private sector, or integrate to the private sector, they will have been exposed to a series of situations that very seldom younger or more junior folks in the private environment get exposed to.

Mr. Lawrence: Well, Patrick, I'm afraid we're out of time this morning. Steve I want to thank you for joining us.

Mr. Ciganer: Steve and Paul, thank you for having me, and should anybody be interested on following up how the IFM program is doing and what our progress is to date, we've got a link, which is, so thank you again.

Mr. Lawrence: This has been The Business of Government Hour, featuring a conversation with Patrick Ciganer, program executive officer of NASA's Integrated Financial Management Program.

Be sure and visit us on the web at There, you can learn more about our programs and get a transcript of these very interesting conversations. Once again, that's

This is Paul Lawrence. Thank you for listening.

Patrick Ciganer interview
Patrick Ciganer

Broadcast Schedule

Federal News Radio 1500-AM
  • Mondays at 11 a.m. Fridays at 1 p.m. (Wednesdays at 12 p.m. as
  • available.)

Our radio interviews can be played on your computer or downloaded.


Subscribe to our program

via iTunes.


Transcripts are also available.


Your host

Michael Keegan
IBM Center for The Business of Government
Leadership Fellow & Host, The Business of Government Hour

Browse Episodes


Recent Episodes

Bob Rosen
Author of Grounded: How Leaders Stay Rooted in an Uncertain World
Jin-Oh Hahn and  Monifa Vaughn-Cooke
University of Maryland
Assistant Professors, Department of Mechanical Engineering
Vice Admiral Raquel Bono
United States Navy
Director, Defense Health Agency

Upcoming Episodes

Michael McKeown
Executive Director, Homeland Security Advisory Council
Department of Homeland Security