The hottest topic in acquisition today, and for the foreseeable future, is how to acquire information technology (IT) systems affordably, timely, and functionally capable of performing as expected and intended. Everybody seems to have gotten into the act, including the Defense Science Board, Congress, and the Office of the Secretary of Defense.

     Ms. Elizabeth McGrath, in her capacity as DoD Deputy Chief Management Officer is responsible for leading the effort and establishing the new IT Acquisition Life Cycle for the department. She is leading a series of working groups which are collectively tasked with determining various aspects of the new life-cycle, specifically policy, rules, and regulations. The prevailing feeling, correct or not, is that the current acquisition life-cycle promulgated by DoD5000.02 is totally inadequate for IT acquisitions.

     OK; why should you as a member of the IT community care? It’s just another bureaucratic exercise which will accomplish nothing, lead nowhere, and change very little of consequence! It might or it might not. However, whatever results will be the IT community’s burden or blessing. As is common in DoD, this is basically a "top-down" determination. Analyze what the problem is, what the factors are which are causing the current state of events, and, thus, figure out what the optimum solution should be. The trouble with this approach is that even though a lot of well-intentioned people, myself (and others at DAU) included, are involved is insufficient; we typically don’t do this for a living. In this case, perception is not enough; we aren’t the ones who are actually experiencing the reality of current IT system acquisition.

     I am proposing to give you a role or at least a voice, should you choose to accept it. This blog is accompanied by a "sounding board" for comments, complaints, whining, etc. I will not limit the discussion. For instance, is 5000.02 truly inadequate or has it become a mantra without rationale? Is the extensive use of commercial hardware and software in IT systems the cause of so much difficulty? Are vendors "ripping" us off? Is a lack of training (or education) the issue? Do we need to redefine DT and OT for IT systems? Is ‘agile development’ the answer?

     My objective in all this is to shed light, not heat; but, heat can lead to enlightenment. Comment on what was, is, or should be relative to the subject … with the proviso that no obscenity or character assassination is acceptable. Discuss or argue with each other; it’s your "place". It is also a place that the ‘the powers that be’ can see what the real IT community thinks and believes. Finally, and perhaps most important, it is potentially your means to influence your future(s). If everybody does his or her part, there should not be any recriminations at the end that you weren’t heard. You may not be listened to; but, you will have had your chance to participate.

     This is Blog 1 of ‘n’. I do reserve the right to comment on your comments. Maybe, I will choose another topic to write about someday; I am not sure yet. But, should there be a high level of disinterest or disdain, ‘n’ will, by default, assume the value of 1. Whether that is something of a loss and to be avoided is completely up to y’all.

Larry