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.
I remember having this conversation (in 2006) with the GFEBS chief engineer. His first response was, “What do you mean?”
“Who is the operator of your ERP? Running a big ($1.6B) IT system takes a lot of work… who is going to run it?”
“Oh, the program office will.”
I try again: “No, I must not be asking this right. The program office is responsible for buying it. Who is going to operate the production system after IOC (Initial Operational Capability)?”
GFEBS chief engineer: “No really, the program office.”
I say, “The program office is not staffed to do operations on that scale. Look, I visited the F-22 SPO in 1996, and when I asked them who was going to operate their system, they told me the 1st Fighter Wing at Langley AFB, and after that the 49th Fighter Wing at Holloman AFB, and so on. They knew exactly who the operator was, and it wasn’t the Program Office. There’s a big skill-set and doctrinal difference between acquisition and operations, even in IT. So who is going to operate GFEBS?”
“Umm… Accenture?” he ventured.
Which was probably true, but wrong at the same time.
I didn’t understand the issue enough then to point out that not only was the PMO trained and staffed wrong for operating an ERP, it has the wrong mission. The GFEBS PMO was part of Army PEO EIS, which reports to Army Materiel Command ASA(ALT). The ASA(ALT) mission is to buy stuff (“developing, acquiring, fielding, and sustaining…”) but GFEBS purpose was to provide financial and accounting services. That’s the either the G-8‘s mission or the ASA(FM&C). Or maybe DFAS. Truthfully, it wasn’t anyone’s mission, which is why the PMO was stuck with it – but it’s exactly why there is a universal refrain that ERP implementation requires Business Process Re-engineering (BPR). If the Army wanted to centralize finance and accounting services, they should have stood up a “Army Finance and Accounting Service”, but that would have sounded too much like DFAS, so I guess they couldn’t.
From what I can tell, GFEBS soldiered on (pun intended), and had it’s Full Deployment Decision (FDD) in 24 June 2011, which means it took them “only seven years“. I have not been involved with GFEBS since the 2006 ERAM review, but a cursory review of the internet makes it appear that the system is still being operated by the PMO. I think this is a mistake that occludes the proper lines of accountability. “No man can serve two masters.” Does the GFEBS PMO serve the Army Acquisition Community, or the Army Financial Community?
I applaud the successes that they’ve had, despite the lack of clarity about roles and missions. I argue that this is a deep, and widespread problem across government IT.