[Mirrored on Intelink-U]

Here’s another story about buying systems without a clear concept of who is going to operate it:

I was at my neighborhood spaghetti dinner and I happened to sit across from some guy who – it turns out – also works for OSD.  He’s a contractor working for OUSD(AT&L) on a system that he was quite enthusiastic about called “Contingency Acquisition Support Model (cASM)”.  (I have no idea why they capitalize it that way.)  This system, cASM, is a web-based application designed to assist people responsible for initiating contracting requirements in an contingency or expeditionary environment.  I understand it as workflow automation for contracting in a crisis.

Since I’d been thinking about this a lot, I immediately asked him, “Who is going to run it?”  and he said, “Oh, it’s hosted by DISA.”

I tried not to choke, and said something like, “That’s not what I meant.  Okay, DISA hosts it, but who is going to run it?”

Continue reading →

This is the one of several posts to illustrate the difference between “acquiring a system” and “providing a service”, that I raised in a previous post. [Intelink-U cross-post]

Several  years ago (~2006), I was on three peer-review-teams for big DoD ERP implementations (DEAMS, GFEBS, and IDE-GTN Convergence)

These “ERAM” reviews had a bunch of process and structure, but the important thing was that we had a team of smart folks do several days of on-site interviews with involved personnel:  we interviewed everyone from the 3-star sponsor to the GS-9 users, the contracting officer, the gov’t Program Manager (PM), the Program Executive Officer (PEO), the chief engineer, the contractor’s PM, the software jocks writing the code, and anyone else we could think of.

One of the questions I remember asking folks in the PMO (Program Management Office) was this:  “When you are done building this system, who is going to operate it?”

Generally, when we asked this question, we would get a puzzled, head-cocked-to-the-side look, like the RCA dog.

Continue reading →

[Intelink-U mirror]

I’ve had a “lightbulb moment” about the problem with the acquisition of IT systems in the Defense Department. The flash was so blinding that several of my co-workers have now filed for disability benefits.

Like most blinding-flashes-of-the-obvious, the insight was that the question was wrong.

Let me lead up to it: Beth McGrath (the DoD Deputy Chief Management Officer) famously testified to Congress:

Our current approach to implementing IT systems takes too long, costs too much, and often fails to deliver the performance improvements we seek. On average, it takes 81 months in DoD from when an IT program is first funded, to when it is fielded. Given the rapid state of improvement in the IT field, this means that we are delivering systems that are outdated before we ever turn them on. In contrast, the iPhone took two years from concept to delivery. It is clear that we need a different approach.

DoD personnel are completely fascinated by, and oriented towards, buying systems. Here’s the problem: in today’s world, most IT systems exist to implement a service.  There are not even words in our government lexicon for this; it is hard to even ask the right questions. A “system” is just a tool. It exists to make some task easier or possible. Operating an IT system is often complicated; it requires specialized expertise and there’s more to providing a service than is immediately apparent.  By itself, the operation of an IT system could be a service, but really it’s the mission function that the system enables that is the actual service being provided. “Running ATAAPS” (Automated Time and Attendance Production System) is a service, but it’s not running the software application that matters – the real service is timecard processing and reporting.

Continue reading →