Jul 29, 2009 (11:07 AM EDT)
Q&A: Veterans Affairs CIO Explains IT Overhaul
Read the Original Article at InformationWeek
The Department of Veterans Affairs has experienced a number of well-publicized IT failures, most recently the February collapse of a patient scheduling application project that was 17 months behind schedule and 110% over budget.
The federal agency's new CIO, Roger Baker, is updating the department's project management processes, and he plans to revamp or cut projects that are over budget and behind schedule. Last month, Baker put the brakes on 45 projects that were more than a year behind schedule or 50% over budget. InformationWeek talked to the VA's CIO about that decision and the long-term changes to come.
InformationWeek: Can you give us some background on the decision to temporarily stop those 45 projects?
Baker: In February, the VA had a very public failure of the patient scheduling application, and the secretary [Gen. Eric Shinseki] did a five-hour review with everybody there. They just walked him through how it got to that point. As a result of that, he ordered a complete review of all ongoing IT projects at Veterans Affairs.
When I stepped through the door, waiting for me was a spreadsheet that evaluated all 307 ongoing IT projects, especially on a particular set of attributes: Where were they on their original schedule? Where were they on their original budget? Did they have access to all the resources necessary to succeed? If you sorted that spreadsheet, you very quickly came to decision criteria that said, for 45 of our ongoing projects, they're either more than a year behind schedule or more than 50% over budget, and we said, we need to change the culture that systems get developed in.
I pulled out an approach to systems development that I had been thinking about for several years. We looked at it with senior IT folks and the deputy secretary and briefed all the senior managers inside VA, and came to a unanimous decision that that’s what we needed to do.
We needed to implement incremental development and very strong and stringent management and milestones so that projects that consistently failed to meet milestones got stopped and their direction got changed. This is not going to be a painless process. We're halting 45 projects. Not everybody believes that was a good idea, but the bottom line is that we are going to change systems development inside Veterans Affairs, and the only way you make a decision like that is with a secretary who's willing to stand up for it.
InformationWeek: Can you walk us through a project that exemplifies the need to change, like the patient scheduling project? What went wrong there?
Baker: A lot of times, IT management is about hard decisions, and the culture at VA on the systems management process has been about avoidance of hard decisions. It's easier to get more taxpayer money than to wrestle with the internal political issues that might cause you to have a hard discussion about whether the requirements are still valid, whether you'll actually be able to deliver on it, whether you need to change staff or change vendors.
All those things are hard to do inside government, and if you don't make yourself, you find yourself in an environment where it's easier to go to the Hill and get another $26 million to extend the program than to make the hard decisions necessary to fix the program. A lot of what [the Project Management Accountability System] is intended to do is to force the hard decisions, to say, look, if a project can't make its milestones, it must be having problems.
InformatonWeek: So let's go into the Project Management Accountability System.
Baker: PMAS is really three things. The first is incremental development. Do things in small bites, deliver functionality to your customer on a frequent basis, and get a lot of feedback on what's working and what's not. The second is schedule driven development. By managing the schedule, we can constrain cost and features. Finally, in the private sector, the compelling rationale tends to be the bottom line. Business cases don't seem to have as much relevance in the government world, so we're looking at the schedule as the bottom line, something hard that the project has to come up against, and manage to those milestones.
It's critical that as we look at the big issues that the VA faces with things like the paperless environment, benefits, electronic records, exchanging information with the Department of Defense. We're on track with those projects, and we've got to know that they're not running off and hiding on us like the patient scheduling program.
InformationWeek: So what do you do to ensure that you don't have systems and projects in place that don't further the mission?
Baker: What comes out of this is prioritization. As part of this process, we will end up determining which projects are high priority, so they get resources, and which projects aren't, so they don't get resources. That's one way of making certain that you're tied to the mission.
Second, PMAS is making my job easy on the systems development side. Projects will come in and say, we're committing to these dates for milestones, and these are the resources we need, and we're going to mark these resources down on something as simple as a spreadsheet. And on the date when those milestones were supposed to have occurred, either there will be sitting on my desk a piece of paper from the customer that says, I have the functionality, I have tested the functionality, I accept the functionality, or the milestone was missed. Three missed milestones, we stop the project.
InformationWeek: What happens during these reviews? How do you re-jigger projects or decide which ones to scrap?
Baker: Right now, we're simply saying we've chosen to redo your project plan, so bring in a project plan that shows incremental development, access to resources, customers at the table. We've got a whole matrix of what we believe are success factors for the project.
I'm going to look at some very high level things, and item one is, is the customer sitting at the table with the project? If they can't get the customer to come to the table and get the project restarted, it must not be that important. Number two, do we believe that they understand what incremental development means and have a plan that will get them to delivery within six months with new functionality for the customer? Do they have the test plan, do they have change control, do they have the requirements nailed down, because if they walk in to restart and they don't have their schedule planned out pretty much day by day, they're not going to make it.
The other piece of this is, have they identified all the resources they require and know how they're going to get access to those resources? They come in and say, we need two systems architects but haven't been able to find them yet because they're sucked up in other programs. Do we have a management decision to make, which is, which of those programs is the highest priority and which is going to get access to those systems architects? That's where we are right now on the projects and getting them restarted.
If they miss three milestones, I think it's a whole different environment, because at that point, we basically are saying, we're going to look at the key aspects of this. Do we still have the requirement? Is it possible to deliver with the approach that the project has taken? Do we have the right project manager? Does he or she have the right skills? Do we have the right government staff? Do we need to replace some of those? Do we have the right systems vendors? If we've got contractors, are they putting the A team on things? Are they really contributing, or are they just there to provide bodies? We have to hold the whole project accountable, and maybe it’s a little bit draconian.
InformationWeek: It's almost like, "This project's now in bankruptcy, and I'm going to reorganize it as I see fit."
Baker: I like that analogy because in bankruptcy, there are parts you keep and parts you don't. To me, it's all about forcing hard decisions by ensuring that there's a hard stop on failure.