I am concerned when I learn about acquisition programs that do not have adequate insights into development. In a recent discussion, I learned that a government group acquiring software was developing measurements they would use for their own quality assurance group. When I pointed out that their measurements were deficient because none of them tied directly to the software being developed, I was told the acquisition organization had no authority to obtain insights to the quality measurements from the developers.

As an acquisition organization, it is your right and responsibility to be certain you have all the data necessary to ensure the program is proceeding as it should. The organization mentioned above was correct in some respects because the developers are not required to provide this information if it is not stated as a deliverable in the contract (and apparently it was not stated in this contract). I would like to send a message now that all contracts are negligent if they do not require the contractor to provide the data needed to oversee the contract. While current rules no longer allow acquisition organizations to stipulate data format, you can still require information related to cost, schedule, quality, risk management, etc. If the developers consider this to be proprietary information, you can sign a nondisclosure agreement, but you should require the information.

This also should not result in substantial additional costs to the program. I know of one program where the acquisition organization simply required a copy of the developer's software development plan and access to their databases. The acquisition organization was able to use the development plan to learn what data was available and where it was located. They then looked for the information as they needed it. The result was minimal additional cost.

Our first article this month is a discussion on Section 804 of the Bob Stump National Defense Authorization Act for Fiscal Year 2003. Lisa Pracchia's Improving the DoD Software Acquisition Processes discusses some of the issues that resulted in 804 being passed, the intent of 804, and some suggestions for implementing it.

Our next article is Why We Need Empirical Information on Best Practices by Dr. Richard Turner. This author's experience in the Office of the Under Secretary of Defense has given him many opportunities for insight into programs going right or going wrong. In this article, Turner suggests some questions we should ask ourselves before jumping onto the latest best practice.

In A Project Risk Metric, Robert W. Ferguson reminds us of the need for managing risks throughout a project and suggests some values to quantify the actual risks. In our supporting articles, John S. Willison discusses some benefits his project has seen while implementing agile development in Agile Software Development for an Agile Force. Michael S. Russell then provides criteria to use while considering reuse software in Applying Decision Analysis to Component Reuse Assessment. Michael J. Hillelsohn provides an additional benefit to good requirements management in Better Communication Through Better Requirements. Requirements management is essential to any software development. However, have you considered that better reviews of requirements could also aid understanding between the acquisition and development organizations? Finally, D.B. Robi reminds us that we need a reason for many of the best practices that we are asked to implement. He states a motivational view should be added to the Department of Defense (DoD) Architecture Framework in Enterprise DoD Architecture Framework and the Motivational View.

With Section 804 of the National Defense Authorization Act, there is more pressure on acquisition organizations to take responsibility for taxpayer dollars. I hope they will take this responsibility seriously and start getting the information they need to oversee a successful project. Four key points to remember are 1) know the rules for acquisition; the Federal Acquisition Regulation and Defense Federal Acquisition Regulation Supplement are too long to read and memorize, but an overview and retention of key points applicable to your project are essential, 2) tailor the data item descriptions for your needs; do not let the weight of the whole bureaucracy overwhelm the project, 3) work closely with your Acquisition Center of Excellence and your legal office's Contract Law Division, and 4) stay current on new acquisition approaches and review lessons learned during development. CrossTalk's Web sites on Page 8 provide sources to help with these key areas.