Projectmanagement411 Engages: The PMO Relieves Pain
Margaret Rouse blogs at IT Knowledge Exchange on an amazing variety of topics. Read it and be informed! I find some of the most interesting blog commentors are IT people who engage with me about innovative project management processes- clearly they are making an effort to bring IT and the user together. Her post about my Choosing the Right PMO Vision Series led to a very nice conversation, edited for brevity, and repeated here today and tomorrow:
Margaret: The line that stuck in my head from [your] post was: Usually something painful drives the creation, or reevaluation, of a Project Management Office (PMO). Amen.
Bob: That same pain that drives creation of a PMO can be it’s undoing: PMOs are often eliminated after the pain goes away. The pain also tends to create a PMO that is monitoring/cost based instead of value based- i.e., focusing on the value that can be created by projects vs. merely working to a budget. The value based PMOs tend to spur innovation and have projects aligned with strategies.
************
What pain created your PMO? Is the pain gone? How about the PMO? Contribute your thoughts to the conversation!
Don’t miss a post! Subscribe via RSS or EMAIL.
I think that pain is crucial to gaining people’s attention. Many times IT is ignored as their presentation is not geared to leverage to right decision “making levers”. If the delivery could be improved, then more mistakes could be avoided.
That’s where a PMO can step in, as they generally have been communication skills and the ear of the right parties to implement concepts of change.
Most programmers don’t realize this. I have a small post that tries to shock them out of there shells:
http://activeengine.wordpress.com/2008/01/10/the-art-of-letting-bad-things-happen/
Sensei- pain is an interesting phenomenon. One of the analogies used for improvement is “draining the swamp”. When you drain the swamp you start seeing a bunch of ugly rocks. In project management this means getting rid of the projects you don’t need by doing a project inventory and then getting rid of some more by eliminating those that don’t align with strategies. What this does is focuses resources on the remaining projects and the problems they have which now beg to be solved. Same thing when you do a lean manufacturing program and eliminate wasteful processes- the real problems (pain) start to emerge; you are now on the road to solving real problems and root causes, not just symptoms. Back to software development- do you find that excessive documentation can hide problems in the process? I’ve heard that documentation is the “excess inventory” of software development.