A conversion kit “one size fits all” may be a bit too strong a term for how I’d guide a traditional PMO to go Agile. However, to your point, I’ve listed 8 general re-tooling guidelines for an Agile PMO in my latest blog post. See what you think about these and if they resonate with your experiences.

Also, congratulations with your vision of the “agile spillover” outside of the software development group. I have worked with some clients using Agile for embedded software, firmware, and hardware development and deployment. Indeed, this sense of collaboration, coordination, commitment, and overall project visibility can be profound. Magical things occur if people in all parts of the organization are prepared to truly engage and not just pay lip service to the agile transition.

I love it! Kaizen Promotion Office! Maybe that is what we should explicitly request as a name change as organizations transition Agile across teams or teams of teams (Programs). It makes the mission of “the office formerly known as PMO” so obvious. Thanks for sharing. I also think this backs up the comment from Brendan Flynn about how his PMO works at Shoplocal. Perhaps you two should hook up and share more ideas together and with the rest of us? I’d love it.

BTW, check out my blog today regarding my 8 ways to re-tool for an Agile PMO. You’ll see Kaizen and Gemba sprinkled liberally throughout.

I look at the PMO (project/portfolio management office) similar to what I have experienced in an organization driving out lean … the KPO (Kaizen Promotion Office). The KPO was responsible for driving out “continuous improvement”, managing the whole (Value stream) and for promoting a culture of kaizen throughout the company. Similarly the PMO may manage the whole (portfolio view), promote a framework of lean/agile thinking, promote a culture of community and help the organization understand and deliver business value. This to me is the mission for the modern day PMO. Further, the “project managers” that work as part of the PMO must turn to facilitation, partnering with the business to understand the whole (value stream), be an agent of change, foster high-bandwidth communication and consultation. Is this too big of a challenge? I don’t think so … it just takes leadership and passion … that however is sometimes difficult to find.

As manager of a nascent PMO and self-appointed Agile evangelist at a company(here in Boulder) where PC-based SW development projects are only ~10% of the project universe with the other 90% being development of electronics/mechanical devices, my goal is to spillover Agile practices out of the software arena and into other engineering disciplines as much as possible. Those practices may be “less-Agile” when applied to development of circuit boards, for example, where iterations can’t be had in a few weeks, but the effect on collaboration, commitment, focus on adaptation and continuous improvement is game changing.

Agile may seem foreign to a PMO whose business is outside of software development, yet would benefit greatly if someone handed them an “Agile PMO Conversion Kit”.

Also, it is so critical that you have built safety and trust with regard to setting up any agreements of standards by having the teams define them. You as PMO are faciliting those discussions of insight and then capturing as a service to the organization.

I have an upcoming post of my list of top guidelines for Agile PMOs. Hope to see you there!

Thanks again for your great thoughts. And congratulations!

We definitely fall under the B) No category. That is, we are agents of change, evangelists reinforcing the values and principles of Agile throughout the organization. This was especially true as we initially rolled out agile practices, where there were many cultural hurdles to overcome. Having this central group banging the drum every day helped with our adoption and eventually its optimization of removing wasteful practices.

In my view (as the head of a PMO), there is a place for PMO like standards in that we help to define or facilitate working agreements across the organization. The purpose of working agreements is to help define expected behaviors of each team. Sounds very PMOish. The PMO lays out the framework, but the teams define, inspect and adapt to make it their own.

PMO stands for Project Management Office. Do you have one in your organization? What are your experiences with their role? If you don’t have one, why do you think that might be valid for your circumstances? Thanks, Jean