Tuesday, November 3, 2009

Acquisition Professionals: VIP's on the Transformation Team

I podcasted on this subject about a year or so ago, but I believe it bears mentioning again: Without the Acquisition community's help, we're going to have a really difficult time with Defense Business Transformation.

I'm not just talking about the Acquisition policy makers. I'm talking about every person supporting the Acquisition process - from the one's who write the policy, to the COTR's and PM's who keep an eye on things. Everyone.

Groups of action level folks wearing titles such as KO (Contracting Officer), COR (Contracting Officer Representative), COTR (Contracting Officer Technical Representative), and TM (Task manager), all have significant contributions to make. These contributions are not limited to the absolutely necessary functions they already perform. I'm talking about saving the government a lot of money and wasted time. Minor changes to the way things are already being done will make a huge difference to Transformation efforts. We need to remember these folks and give them the training they need to be VIP members on the Transformation team.

First, these professionals need to be read in on the new application of the Anti-Deficiency Act (ADA). Every KO, COR, COTR and TM knows well what an ADA is: a section, 1341 (a), of legislation that uses words like "jail," "fines," and mean relief of duty. Everyone in the acquisition business got a primer on it during initial training. In short, an ADA violation is something to be avoided at all costs.

Few know, however, that the ADA has been recently (October 2005) applied to business IT projects for not asserting compliance against the Enterprise Architecture. Few understand that the act of doing their own thing with business IT projects - irrespective of their contracting authority - can land them into a career ending ADA violation that maybe hasn't caught up with them yet.

Of those that do know (I personally trained more than 80 COR's in a 3 month period) few realize that a few small changes to a Statement of Work (SOW) can save thousands or hundreds of thousands of dollars and many months of paperwork. By simply requiring contractors to submit their deliverables in DoDAF (DoD Architecture) format, the solutions architecture that is needed to assert compliance will not have to be created by a separate contract line item (CLIN, government employees, or a new contract.

Compliance assertion can happen throughout the lifecycle of the project on an annual basis. This assures both a finished project that is compliant with current and emerging DoD design specifications and constraints, AND a whole lot less time and aggravation that comes from having to re-create paperwork after the fact.

Talk about demonstrable cost savings? The average time for a certification project to get from my office (the first time I saw a project) to having certification in hand was 71 days. Most of those 71 days were spent chasing down accurate and complete paperwork, educating people along the way, and getting someone to submit the solution architecture for a project. If contractors had been asked to submit their design proposals in DoDAF format up front, we could have easily shaved weeks off the certification process and made the certification process a lot more about design and the business case and a lot less about getting the paperwork right.

How many KO's understand that a lack of obligation authority means that a project isn't legally going anywhere? I'm talking about at the time of initial certification and again at each an every annual review (not less than 12 months from initial or annual certification).

All KO's know that not timing the renewal of a contract correctly could be a deal killer, but not timing the initial certification or the annual re-certification could be just as bad. Dead is dead. Without both money in the checkbook and obligation authority, business IT modernization, development or enhancement is not allowed to proceed in the DoD without facing an ADA violation.

How many business IT projects are NOT about development, enhancement or modernization? Precious few are pure sustainment efforts. Oh I know people sometimes call modernization "sustainment" because they claim a project would die if it doesn't keep pace with the world. Believe me, I've heard it. that's a way of getting around the system.

But 10USC2222 was not enacted to create another byzantine paperwork drill that we should do our best to avoid. It was created to give us the leverage we need to force systems throughout the Department, on penalty of ADA, to become compliant with standards that enable interoperability, data exchange; and to empower leadership to force the sum total of the IT asset portfolio to support DoD priorities like visibility of personnel, finances and materiel, etc. instead of skunks works, cherry picked requirements building efforts, and pet projects.

We want these Transformation systems (investment review, enterprise architecture, annual review, etc.) to work in order to empower decision makers to make better informed decisions - to spend smarter - to create some continuity over time - to stop duplication and sub-optimized efforts in all Components - to gain some control over the spaghetti mess of IT spending across the Department and re-direct resources that are currently being wasted by poor or conflicting decisions to areas where resources are sorely needed - to enable the real mission of the DoD.

If you are a DoD acquisition professional or if you know one, get the documents into their hands. The documents explain the law and the implications pretty clearly.

Keeping out of trouble and moving the DoD towards interoperability, continuity, and data sharing isn't as difficult as some would have us believe. From an Acquisition professional's perspective, adding a paragraph or two to a SOW (e.g. A. Contractors shall prepare proposed solutions architecture models using DoDAF format B. solutions submitted for consideration will be compliant with X standards as expressed in the DoD Business Enterprise Architecture) and changing the wording on relevant deliverables tables from "Word" or "Excel" format to 'DoDAF" format are really a pretty simple maneuvers.

Adding the words "Certification" and "Annual Review" to a project calendar is pretty easy too. Backing up the proper amount of time from those calendar entries and setting a reminder or two in order to make sure there is sufficient time to conduct a solid "due diligence" review is good for the project and good for the DoD.

If we can get this word out to the Acquisition community and the Acquisition community makes a few simple changes, time and cost savings would be enormous. This would put the acquisition community one more time in the VIP seat on the Transformation team.

No comments:

Post a Comment