Understanding PMAS
I had a chance to sit in this morning at a "Business and Enterprise Architecture" seminar in Reston. The speaker was Dr. Paul Tibbits, the CIO for Enterprise Development at the U.S. Dept of Veterans Affairs.
What is a liberal arts major doing at a breakfast for technology jocks and Federal contractors?
Learning to improve our IT system in Virginia, which has suffered from numerous malfunctions in 2009.
One of the things I liked about Dr. Tibbits' presentation sponsored by the Northern VA Technology Council was its emphasis on real-time accountability. In the Veterans Adminstration system, as of June 2009, each IT vendor is expected to participate in PMAS (Project Management Accountability System) which uses the "incremental development approach" to make sure that all IT projects are held to a strict development timeline.
Those IT firms that don't meet the delivery milestones are halted. Failing programs are identified early in the process and discontinued. As a result, the VA does not spend good money after bad -- to use layman's terms.
In the next year, the state's VITA technology agency will surely see an overhaul. The use of PMAS technology and principles in Virginia will need to be present, if we are to restore credibility to the state's technology structure.
Chap, giving a liberal arts professional the floor to speak about information technology definitely highlights a BIG part of the problem. Virginia has a literal IT brain trust that spans across an untold number of state funded universities. I have been in the computer field for 10 years, on the technical side, & the idea that IT can be made a commodity confuses, hurts & inflates costs... except in private establishments that live or die by its effectiveness (i.e. banks, Wall Street, content providers, Telcos & Internet based commerce). First, you must have "real" technical managers that can separate the wheat from the chaff. Too often IT managers are "former" technical folks that have become tired of staying current. In technical conversation, I see these former technical IT managers get snowed all the time. I feel like I could write a book on what I've experienced inside both private & public institutions. Most non hard science folks are baffled &/or scared by IT. Fact is, IT is simply about building a trusted in-house team of folks, that as children, took apart all their toys to see how they worked.
Circusnuts: Thanks for the comment. Actually the liberal arts guy was me (and I was definitely not speaking but listening to how VA operates their system). I very much appreciate your comments about better using the "IT brain trust" in Virginia. I don't pretend to know the right people to manage IT which is not my field of expertise. If you have an idea on that, please call me at 703-349-3361 or email me at chap@fairfaxsenator.com.
Chap - BIG problem with what these folks are peddling. Having been involved in Federal IT contracting I can say that most often, when a RFP is requested with bids, the Federal COTRs and their requirements documents are horrible. Usually the delays in the project are not due to the contractor, it is due to the lack of well developed requirements by the SMEs in the organization. Once the contract is let, I can say that from experience, scope creep is usually the failing point - and that is driven by the COTRs and SMEs changing requirements as the project develops.
Sure, you can have some bad IT folks, or folks who cannot perform proper risk analysis that can get in trouble - but scope creep and poor requirements definition is 90% of the problem.
Chas: Thanks for the comment. Sounds like you are speaking from experience here.