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.
There's a big buzz surrounding Government 2.0 -- the revolution that's bringing the principles and value of the Web as a platform to the business of governing. Attend Gov 2.0 Expo Showcase and hear innovators show how this is really happening. At the Washington Convention Center, Sept. 8. Find out more and register.