Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me.  Experience and project leadership trumps a certification any day of the week.  But, for those of us who believe we know what we’re talking about, a credential is sometimes a necessary evil.  As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered.  Rather, successes are measured with earned value. Sometimes, I think it’s just the nature of the beast. But, it doesn’t have to be that way.

You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one CSM…me.  I’m not going to go into the details of the project.  But, how could the opportunity be seized to leverage Agile?  Rather than answer that directly, I’ll ask a question.  If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you’re talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.

One of the first things I would recommend you say is “Agile is actually in the PMBOK”. If your stakeholders are PMPs and they believe the dogma of the PMBOK, you’ll have their attention. It’s not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you’ll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.

…only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables.  This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research , but it can reduce the ability to provide long term planning.  The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value.  It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases.

For the Agile pundits out there, does that sound a little familiar?  For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered?  Agile is not a bunch of voodoo for the wild and undisciplined.  It’s an excellent opportunity to deliver value.

Today I realized I’ve been supporting and advising a Federal Government PMO for a whole year.  Prior to that, I was the Manager of Software Engineering at an online company that had recently gone public.  I was the sole PMP (Project Management Professional) and  sole Agile Evangelist. Upon my leaving that company, I told my superiors they really needed a PMO if they wanted to offer consistent results, measurable improvements, and increase stakeholder satisfaction.  It was hard at first to shift gears, away from a private profit-driven organization, to Federal governance-driven organization.  At the private company, it was all “being creative” to meet unrealistic goals set by those not versed in best practices.  Since there were no other PMPs, I felt like the lone sheriff in the Wild West.  Now that I’m dealing with the government, I’m surrounded by other PMPs.  There is policy, process, and governance.  Everyone knows their jobs very well.  They know best practices.

So you can differentiate the type of PMO I work in compared to others, I’ve included the 3 basic types below with their definitions.

There are 3 basic types of Project Management Office (PMO) organizations are [1] supportive, [2] controlling, [3] directive.

1. Supportive PMO generally provides support in the form of on-demand expertise, templates, best practices, access the information and expertise on other projects, and the like. This can work in an organization where projects are done successfully in a loosely controlled manner and where additional control is deemed unnecessary. Also, if the objective is to have a sort of ‘clearinghouse’ of project management info across the enterprise to be used freely by PMs, then the Supportive PMO is the right type.

2. Controlling PMO has the desire to “reign in” the activities – processes, procedures, documentation, and more – a controlling PMO can accomplish that. Not only does the organization provide support, but it also REQUIRES that the support be used. Requirements might include adoption of specific methodologies, templates, forms, conformance to governance, and application of other PMO controlled sets of rules. In addition, project offices might need to pass regular reviews by the Controlling PMO, and this may represent a risk factor on the project. This works if a. there is a clear case that compliance with project management organization offerings will bring improvements in the organization and how it executes on projects, and b. the PMO has sufficient executive support to stand behind the controls the PMO puts in place.

3. Directive PMO goes beyond control and actually “takes over” the projects by providing the project management experience AND resources to manage the project. As organizations undertake projects, professional project managers from the PMO are assigned to the projects. This injects a great deal of professionalism into the projects, and, since each of the project managers originates and reports back to the Directive PMO, it guarantees a high level of consistency of practice across all projects. This is effective in larger organizations that often matrix out support in various areas, and where this setup would fit the culture.

Definition Source:  http://ezinearticles.com/?expert=John_Reiling

A little over a month ago, Agile Zen started following me on Twitter.  They are creators of a very clean web-based kanban solution.  Around the same time, I connected with Jim Benson.  Jim is a collaborative management consultant.  He is the CEO of Modus Cooperandi, a consultancy which combines Lean, Agile Management and Social Media principles to develop sustainable teams.

Though I’ve used information radiators like kanbans in the past, I’ve been working in a non-Agile PMO for the last six months and it’s all very foreign to them.  Thanks to reading the works of David Anderson, Jim Benson, and AgileZen, I’m back in the game.  I’m using AgileZen on a daily basis for everything from business deliverables, to an entrepreneurial project, to my wife’s honey-do list.

My actual task completion velocity has noticeably increased in the last month.  I attribute that to AgileZen having a very easy to use product, Jim musing on a daily basis on the topic, and most importantly limiting what I’m working or focused on.

You can read one of Jim’s recent postings [here]
You can check out AgileZen [here]

I wish I could thank all of the kanban supporters out there that I follow on a daily basis.  These 3 really have to be mentioned.  If you’re interested in Kanban, look them up.