Agencies begin to alter approach to IT system development

Monday - 10/17/2011, 6:01am EDT

Jason Miller, Federal News Radio

Download mp3

Agencies will have to start breaking some IT eggs to build a better IT omelet.

The move to agile system development is forcing agencies to get away from the decades-old concept of trying to build an entire system over three-to-five years and toward iterative segments.

"You ensure that as you go through that environment you put each of those chunks in front of the customer and so they know that what you are developing is what they are looking for. They can redirect what you are doing as the project goes along," said Tyler Bond, a senior IT specialist and project manager in the Agriculture Department's application service office. "It's a way of incorporating project management that is not afraid of change but really embraces change and allows you to incorporate change into your process."

The Office of Management and Budget has been pushing for the use of agile development over the last two years. Former federal chief information officer Vivek Kundra made agile development a central piece of the administration's 25-point IT reform plan released last December.

OMB also has strongly encouraged the use of agile development through its TechStat sessions to help fix troubled projects.

But only in the past year have agencies begun understanding how this new approach works. And now as many are starting to put agile in place, they are realizing it changes nearly every construct they have followed over the past two decades when buying and developing technology systems.

"There are significant differences in how we traditionally do the waterfall approach," said Robert White, a supervisor engineer in the FBI's chief information officer's office. "Usually, it is a linear approach where you go through design, test and other parts separately. You have to throw that all out the window. There are multiple-design, multiple-test and multiple-review phases as you put each phase into production. It's a more trigger-based approach."

Bond, White and others discussed how their agency is using agile development during a panel discussion sponsored by AFFIRM in Washington Friday.

The use of agile development changes the role of program managers, contracting officers and the business-line owners because traditional project management approaches are used much differently.

"We take our concepts of production and engineering from the 1970s and speculate on what value we want to have at this point of time and measure our progress against what we guessed. It just doesn't work. Earned Value Management has got to be thrown out," said Rob Vietmeyer, cloud computing portfolio manager for the Defense Department. "It changes. If you are fielding to production every two weeks, literally going through every step necessary to field a new system to production, system upgrades and enhancements every two weeks, the level of documentation, the level of conversation you are having is completely different than if you are planning for release every six months, 12 months and 18 months. To do this you really have to automate."

The automated reports help show the progress of the system and cuts down the time it takes to do the necessary steps to field the new functionality, he added.

The widely-used waterfall approach is problematic because agencies end up guessing what their long-term needs are or will be and buying systems based on those ideas, Vietmeyer said.

He said this is why so many large programs from the Homeland Security Department's Secure Border Initiative-Net to DoD's Defense Integrated Human Management Resources System to the FBI's Sentinel program have failed to meet expectations over the years.

"If you take a big project and say, 'We're going to set these objectives,' but then break those objectives down into modular pieces, then you can roll either in parallel or roll incrementally," Vietmeyer said. "It's not to say you can't take a big large challenge and approach it that way. We need to start to separate the engineering governance with our financial governance. What we have done in the past is we've tried to link the financial governance and the engineering governance to a single set of milestones. And it's held back the engineering teams from actually moving forward when they can because we haven't hit this milestone yet so we can't make this next step. So we have built in, in my opinion, these unnecessary links between program financial governance and the technical engineering governance. If we can break those links, let the engineering teams move faster, but then still have the necessary financial oversight necessary on top of that but not directly linked to a single set of decision points then we can succeed with these bigger programs."