Too much time is spent testing software development projects.
Here's a trick question: When is software testing a bad thing? Usually considered a virtue in short supply, software testing can also be a vice. That may be the case when it comes to government problems with fielding enterprise resource planning (ERP) software.
At least that's the view of Mark Johnson, lead partner in IBM Public Sector's ERP practice. He believes the kind of exhaustive testing government ERP programs undergo is unnecessary.
"We go through that process of testing and testing and testing that was developed for custom-developed software and not for commercial software," he said at the Air Force Information Technology Conference in 2004.
It is possible to streamline the testing process and not give up any quality. Agencies could test ERP modules as they are developed and then string them together for a final test at the end of the program, he said. Agencies would be better off if officials spent more time at the beginning of the process to better gather user requirements, Johnson said.
The current testing process is a result of pulling together too few requirements upfront, said Lisa Mascolo, a managing partner at Accenture. Without such an assessment, users start to notice deficiencies in what they need too late in the program, she said. Extensive reworking of the software is then required, and those changes in turn need testing.
"But agencies are strapped for knowledgeable and qualified people," she said. "We often find that the most qualified people who should be involved in the initial requirements phase are doing their everyday jobs and are not available [for the ERP project] then."
Nevertheless, Johnson said the way government does things is outmoded, and something must be done to allow for change.
NEXT STORY: DISA creates tsunami ops center