In our federated model, we have almost no “hard” way (financially or in terms of people’s annual goals, etc.) of incenting people to participate and/or cooperate with new PMO governance, standards or processes. What tactics and/or techniques have you used to generate change and cooperations with the PMO?

Question from the Gartner Symposium Forums

Bear with me, this is a bit of a round-about answer.

In the most successful implementation that I was part of, we came at it a bit backwards from the “normal” way of doing things. Our PMO was viewed as a hindrance and as unnecessary administrative overhead. Part of that was because of ridiculous requirements like managing all projects (regardless of size or type) using EVM, preparing huge complex financial models for tiny operational initiatives, religious adherence to gate processes for projects that spanned only a few weeks or a handful of resources, etc.

My team originally came in to help the Applications team move to CMM level 2 and 3. However, shortly after starting the initiative, we realized that we were going to have to take a more holistic approach. We pulled together the PMO, Service Delivery, Finance and Quality teams and started to look at where the overlaps were and how we could combine CoBIT, SOX, ITIL, CMM and ISO initiatives. We didn’t take them over or try to replace them. We just worked with them to understand where we could tie them together with what we were doing.

We started by getting out into the field and explaining to the line workers why we needed to have processes, controls and measurements and how they would benefit them personally. At the same time, we found out where the problems were and why people resisted the PMO (and other initiatives). Since the PMO was a common element to all of the work that was being done, we ended up aligning most closely with them (and ultimately becoming part of the PMO).

We continued down the CMM path and trained analysts in process engineering and documentation (using UML) as part of our Requirements and Change Management KPAs. This eventually lined up with CoBIT and the same people that were building process docs for new IT projects ended up working with the business to document their processes. A lot of technical and business analysts ended up hopping the fence between the two disciplines.

We dismantled the existing “culture of punishment” and shifted to an advocacy culture where the PMO became a mediator to make sure that the business and IT both had a voice. We clearly delineated requirements into Business, Functional and Technical and made sure that ownership was clearly enforced (this also led to a level of requirements traceability that had been lacking. It also GREATLY helped with scope creep since the Business couldn’t change functionality without a business reason and IT couldn’t add or change features that weren’t supported by the functional requirements)

With the empowerment that came with this delineation, both the Business and IT started to view the PMO as being “their” ally against the “other side”. All of the processes and artifacts were presented in a way that demonstrated their value (the WIIFM perspective) and a lot of the “crap” got thrown away. The executives fought a little bit when we did away with a lot of the EVM reporting. But they were really just trying to make sure that the projects were under control. Once we explained the simplified mechanisms and increased visibility, communication and resolution of issues (rather than numbers that were being manipulated by the PMs anyways) the comfort level increased and people focused on getting the work done rather than generating status reports. PMs were positioned as taking the administrative burden off of the engineers, developers and analysts rather than as the “Khan of the Project”. Again, the explicit shifting of control and responsibility made for a better working relationship. PMs became mediators rather than enforcers and provided the people doing the work with a way to be heard.

I apologize if this is a bit disjointed, but it was an evolution that occurred over a 2+ year period and it’s difficult to encapsulate all of the cultural and behavioral changes that occurred. The CMM team and PMO were in a continual state of flux as we incorporated each new piece of feedback into subsequent training sessions and process definition. It really generated a domino effect when a team empowered by the CIO started listening to every level of worker and negotiating “just enough process” to meet everyone’s needs. Before that, it was executive edicts that were often poorly communicated, difficult to execute and that added value to only a very small audience. Once the real dialog began, the PMO became a true agent of transformation.

Don’t get me wrong, we still tracked schedules and costs directly from the Project artifacts. But the focus was on “why” targets were in jeopardy and how to get back on track rather than focusing on whose fault it was or how it could be covered up. If a project went red, the PMO response was “What can we do to help?” not “Whose fault was it?”. We still had the underlying PMBOK type of activities and processes, they were just set in a context of practical communication and mediation instead of adherence to theory, policing and punishment.

It wasn’t perfect, but it was remarkably successful.