Interview: Eugene C. Bounds, Robbins-Gioia's process master

BOUNDS: It's success at meeting expectations with regard to scope, cost and quality. Every project is launched with some expectations as to what it's going to do, when it's going to do it and how well.Good project management enables that to happen, and if it doesn't, it provides visibility into the delta between what's expected and what's really happening.BOUNDS: I think it's fair to say they're on par. Most commercial projects are not of the same magnitude as modernizing a tax system or a weapons system.We have within the government the same types of skills and probably more complex requirements for project management than we have on the commercial side.I could go so far as to say the federal agencies were the leaders in this area, because they put more focus on program management much earlier than their commercial counterparts.BOUNDS: Three are at the top of anybody's list, including ours.One is managing requirements. An organization launches a project but doesn't get a good definition of the requirements. And down the path and midway through, it finds that what is being done is not what the users expected.I think sustaining the work force is going to be second or third on most people's lists, particularly in the government where we see the IT work force and the project management work force migrating or retiring.Third is a combination of controlling changes and managing risk.BOUNDS: For all complex projects, IT or non-IT, you have to scope and plan the project. If you don't do that, you'll never know where you're going.For federal agencies, it's a matter of smart supply team management because fewer and fewer agencies have the in-house skills to manage and implement large systems organically.The next step is having a governance structure that provides oversight and approval of changes'at a minimum, having a monthly status review throughout the program.BOUNDS: There were two evolutions while I was a software engineer in the Air Force.I was a programmer at Cheyenne Mountain [in Wyoming], writing software that interfaced with satellites and radar systems and airplanes. In those days'the late 1960s and early 1970s'there were lots of blue-suit people in the Air Force who had those kinds of skills: analysts, engineers, programmers. As a lieutenant, I coded systems, and I even went back to Cheyenne Mountain as a major and did another system upgrade.I think the biggest change is that federal agencies no longer have the luxury of drawing on those organic skills as we did then. We didn't have to look for a supplier. We had IT resources. As you look across agencies now, you rarely see that. There's been a migration to outsourcing the real technical skills.The second transition, I would say, is management interest in technology. When I was a lieutenant, the generals all said, 'I don't care to know what you do. Just do it.'I no longer see that lack of desire to understand on the part of management. No longer are generals saying, 'Just go fix it.' They know enough to ask smart questions, to give advice and put the business spin on a technology issue.We learned that most of our issues in IT were not technical issues. They were management issues, and many of them were process issues. In our early days, we treated everything as a technical issue, and the way we fixed it was by more technology.When we address issues today, there's clearly a technology component, but we also look at what processes need to be changed. We look to see what skills need to be enhanced, and we also give some guidance to management.BOUNDS: A number of agency applications have been deferred. Now we're going to see the IT budgets redirected at them. The applications are clearly development-intensive, but they won't all be software development.Many of them are going to be looked at from a buy vs. develop perspective. I think they'll be looked at in a much more prioritized fashion because Y2K has afforded agencies the opportunity to look at the big picture of how IT supports their business.BOUNDS: My last Air Force assignment was to manage almost a $300 million software-intensive program at Cheyenne Mountain. We were successful in the sense that we were close to the schedule, functionality and requirements that we signed up for. But it was at extreme expense.For about 18 months, 60 people didn't get to take vacations. They didn't know what a 40-hour workweek was. It was closer to 70 hours. To some people, that's success, but I thought there had to be something we weren't doing right if that's what it took to be successful.At SEI, my mission was to find out if its methods could make the job easier. The Capability Maturity Model had been out for just a couple of years, but it had not been adequately tested.I worked with all of the Air Force and Army software development organizations. After about three years, we were able to produce data that showed the before and after effects of applying basic project management to IT programs, much as it has worked in building bridges and in other disciplines for many years.BOUNDS: A lot of them do. It's fair to characterize most federal agencies' software shops as immature.Keep in mind that the model has levels going from relatively immature to relatively mature. They're immature because they're new to the CMM quality framework.Data shows the average time to graduate from a relatively immature level to a repeatable or defined level is around 20 months. That's why most agencies remain on the immature side of the scale. It takes time, and they haven't been at it for much longer than two years.When you look at the Army and Air Force, some shops have announced that they are at Level 3, 4 or 5. But they have been working at it since 1991 and 1992.BOUNDS: What they do is to get some awareness, set some expectations and a plan for training, plus incorporate process improvement into the technology base and the workers' skill enhancement.Remember that less and less development is being done inside. More and more is being done through suppliers. The target we had for the software CMM was for organizations that did it in-house.Agencies now need to think about the CMMI, or an integrated Capability Maturity Model, because it integrates the acquisition component along with the people component.