Continuing on my efforts to leisurely blog the ongoing PMOSIG confab in Dallas, TX. Here’re a couple more highlights from the Tweetstream yesterday.
For Day One notes, please see here.
The main thread I seemed to see today was about the difference between an internally facing PMO serving the needs of the enterprise users, and an externally facing PMO supporting project standardization in service providers. Rodney Johnson kicked off that discussion with his talk about deploying a PMO to support projects in a technical service provider, and a Siemens case study wrapped up on the same topic.
I also saw that a number of presentations mentioned the technical writer as a key member of the PMO staff.
That led me to my first nugget for the day:
Tweet #1: “Internal vs external facing PMOs: external projects have cost, so the ROI is easier to calculate. Weird logic.”
It seemed that the ROI on external projects was always very evident. Since cost for delivered projects is always tracked against predicted margin, each of the companies implementing externally facing PMOs were able to demonstrate clear cost savings. So the real question is why doesn’t this work for internal project organizations? As usual, this comes back to the weird fact that internal project costs are rarely tracked for some reason that I still fail to understand.
Start tracking internal project cost, and all the rest of the governance process will simply fall into place. Most people agree with that, few organizations implement.
Tweet #2: “R. Johnson talking about sensing mechanisms implemented by PMO: audits, client 360.”
As part of the external PMO, his company implemented extensive feedback mechanisms from the client around the delivery resources. The goal was to identify the good performers, and also to identify opportunities to stage performance improvement interventions. Going back to the model of a change management framework I discussed briefly in yesterday’s post, this seemed like some great examples of sensing mechanisms that a PMO may put into place to determine if the current state is at a variance from the desired state.
The next time, I attend something like this, I am tempted to develop a couple of worksheets listing the components of a change management structure (desired state development, problem sensing, work prioritization, execution) and then sit in each presentation and see if I can’t map each of the elements discussed to one aspect of the model.
Tweet #3: “Siemens PMO case study: ‘We decoupled vertical development from the horizontal processing of the project.’
Another topic near and dear to my heart….implementing controls at the appropriate level of an organization. The scale of the Siemens PMO was enormous, and mind numbingly broad in deployment. What’s interesting is that it wasn’t very deep from the context of prescriptive project management. They basically implemented a set of 10ish milestones which are required to be in every project implemented globally, but then how those milestones are derived is up to each business unit or PM. They focused on the horizontal development of a project, not the vertical development.
To a certain extent, this is what I’ve also heard described as “Object Oriented Project Management.” The PMO doesn’t care how you get to that milestone, but they have specific requirements for the deliverable.
From a complexity management standpoint, this seems like a textbook case of implementing hierarchical structures, with the top structure defining the bare minimum required in absolute rules for projects throughout the organization, and then each business unit cascading down defining more and more detail as appropriate to their own specific needs. As a metaphor, think of the federal structure of the United States: there is the Constitution which contains certain inviolable principles which all lawmaking groups must abide by, followed by federal law, state law, county, and finally municipal regulations. Each level in theory provides more detail and is tailored specifically to the needs of the local environment.
Change management rigor then varies by the level in the governance structure it is implemented, with governance at the top being incredibly difficult to modify, but the governance at the bottom being relatively easy to change. That’s probably a worthy blog post one day.
Tweet #4: “Also liked this: risk event occurred…When did you find it? When was it created?”
As part of their basic project standards (some might refer to it as “elegant”), Siemens boiled the risk management methodology down to two questions. When a risk occurred, two questions were asked:
1) When did you find the risk?
2) When was it created?
With those two bits of information, you can basically perform most of your lessons learned activities and assess where the process may be improved. This is an excellent example of boiling down lessons learned development to its absolute bare minimum.
A couple of other key nuggets that didn’t make it onto Twitter:
- Joe Tannenbaum’s metaphor of the PMO as a church was excellent. According to him, as the church is the realization of the needs of its congregants, so must a PMO be the realization of the needs of its constituents. That was a fascinating viewpoint and presented in a way that I had not previously considered.
- Kent Crawford talking about the PMO services using the terms of ITIL & ITSM.