February 8, 2012 at 2:00 pm #152380
Does anyone have experience establishing an IT Project Managment Office (PMO) at the agency level? I’ve seen many examples of establishing a PMO at the Program or Project level. I’m interested in establishing a PMO that interfaces with Program and/or project PMOs….and best practices.
Thanks in advance.
February 9, 2012 at 4:37 pm #152394
I have experienced creating this kind of PMO, but what is the purpose? Executive Reporting? Cost Control? Resource Utilization? Strategic Program/Project Alignment? I’m sure there are others. The impetus to create a new organization is usually driven by some agency pain point and knowing that will start you in the proper direction. My experience tells me that concentrating on the original pain point is the best bang for the buck initially, but you also need to understand the future of the PMO. It is best to iterate the parts you wish to control or change over time so as to impose the least amount of change on current processes and to establish one good practice at a time.
Often some Enterprise software are integral to this organizational process. In my experience, it was necessary to define, install and configure the features necessary to solve the initial pain point and then to incrementally turn on other features to improve the oversight or control of the PMO. Trying to do it all at once often proved disasterous. I always advise that you take some serious planning time to understand the WHAT of the PMO before you formulate the HOW. Once that is accomplished, it is easier to understand the practices and tools you need for successful PMO creation.
February 9, 2012 at 5:47 pm #152392
I agree with Herman, this has to be driven by the question, “What’s the Goal?” – The more specific you can be about the exact value-add to the agency, the better. What before How, just as Herman said, but even more than that the goals have to be measurable and objective.
I’ve seen too many PMO’s even at the program/project level that just become another layer of bureaucratic overhead and end up hurting instead of helping the agency/organization. Without a clear definition of value and the related objective metrics, it’s really impossible to tell if you’ve created a blessing or unleashed a parasite on the organization.
February 10, 2012 at 2:32 pm #152390
I would suggest keeping the “end user” in mind before bogging us down with policy/regulations/directives. The “end user” has his/her finger on the pulse of their agencies/organizations mission. Gov is so “top down” and “so it is written, so let it be done”. Let’s dispense with the “absolutes” & looking for the “boogey man” around every corner. These regulations are always written by people who have “no clue” what is going on down in the basement of DoD.
February 10, 2012 at 2:37 pm #152388
Thanks Herman, I will send you an email message. I would like to hear more.
February 10, 2012 at 2:37 pm #152386
Thank you. This is great.
February 10, 2012 at 2:38 pm #152384
Ah, the “end user”, we are really trying to engage the end user. It’s a continuing process. Thanks for your input.
March 20, 2012 at 1:11 pm #152382
oops, I’m new to GovLoop, I didn’t know we had to be friends for me to send you a private message!
I guess I’ll start here. I’ve been involved with several organizations (DOT, USDA, SEC) who have decided that establishing an agency level PMO was needed in order for improved program/project results. In most cases, this is because they have faced some “problem” that has uncovered a lack of standardization in their day-to-day processes.
True success typically requires people – process – tool alignment. Yet, in many cases, we see investment in a tool, less so in people, and the lowest amount on actual processes. Unfortunately, the tool can only be as successful as its user is competent.
PMs can be resistant to overly complex PM governance structures, and in my experience, too much too quickly has been the death of PM culture adoption or PMO creation. Herman is right about needing to understand what the point of the PMO is, I would include that it is important to understand how mature you want that organization to become. Many times even very limited maturity (say level 1 or 2 on a five level scale) are all that is actually required to have some consistancy in process and p/pm progress measurement.
Love to talk more if you’re interested
You must be logged in to reply to this topic.