Aligning PMOs using Game Theory
November 05, 2010
Does your PMO Produce Multiple Obstacles for your project or Promote Many Opportunities for success?
A Project Management Office (PMO) can act as an obstacle to agile projects. This can take the form of asking for inappropriate planning detail by not recognizing the likelihood of changes; or asking for conformance to templates that are not even used on an agile project. For these reasons PMOs often get a bad reputation on agile teams, but it need not be that way, they can also add tremendous support and be a great help.
First let’s look at what a PMO actually does (or what they should do, since implementations and services vary). In the September 2010 issue of the Project Management Journal (the PMI’s research publication) there was a nice definition of PMO roles:
1. Monitor and control project performance
2. Develop and implement standard methodologies, processes, and tools
3. Develop the competency of project personnel, including training and mentoring
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
5. Strategic management, including participation in strategic planning and benefits management
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
7. Management of customer interfaces
8. Recruit, select, and evaluate project managers
9. Execute specialized tasks for project managers (e.g. preparation of schedulers)
This definition is good because it speaks to the “supporting” and “developing” roles a PMO should provide and moves beyond the “conformance” and “compliance checking” functions that many teams think of when they consider a PMO. However, when taken with a rigid, traditional-only view of how projects should be run, the PMO can lead to the Produce Multiple Obstacles issue:
Produce Multiple Obstacles
1. Monitor and control project performance – track progress against inappropriate measures such as early stage gates based on getting requirements fully documented and signed off.
2. Develop and implement standard methodologies, processes, and tools – enforce conformance to a methodology that does not incorporate or acknowledge iterative development, adaptation, close business involvement, and frequent retrospectives.
3. Develop the competency of project personnel, including training and mentoring – considering only traditional methods and creating a training curriculum that omits approaches such as agile.
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects – assuming architects and business analyst involvement should finish early on a project. Expecting people to work split across 4 or more projects.
5. Strategic management, including participation in strategic planning and benefits management – not recognizing agile prospects for early ROI, or its application on projects with fixed deadlines, or opportunities for competitive advantage.
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance – auditing projects against inappropriate guides, failure to capture iteration retrospective findings.
7. Management of customer interfaces – Failure to understand the full role of business representatives to agile projects, selecting unsuitable business champions and SMEs.
8. Recruit, select, and evaluate project managers – Looking for the wrong skills, assuming agile certifications equal competence, inability to interview well on agile practices.
9. Execute specialized tasks for project managers (e.g. preparation of schedulers) – failure to provide specialists familiar with agile practices.
It is when we have these mismatches and lack of acceptance or even recognition for agile methods from a PMO that they come up with Problematic Management Observations, that then need to be managed and explained, diverting time from an agile PM not assisting them which is the real goal.
The good news is that the end goal for PMOs is the same as for project managers: successful projects and happy stakeholders, it is just that there may be disagreement on the directions to reach that destination.
Introducing Game Theory
(Don’t worry; while real game theory involves complicated applied mathematics, my game theory is very easy to understand.)
A useful way in reconciling PMO and agile project goals is to consider Alistair Cockburn’s idea of “projects as a cooperative game”. Alistair observes that on projects, team members need to collaborate to be successful. The results of the project (game) are important, but we also need to look after the team members and set them up for success in the future.
With this view of projects, it is an easy extension to view the PMO as a supporting body to this team game approach. Viewed through this lens the roles of a PMO become much clearer and more useful:
1. Monitor and control project performance – track the game performance, are we winning, how much time do we have left, are the players OK?
2. Develop and implement standard methodologies, processes, and tools – support the game, build and maintain facilities, provide equipment.
3. Develop the competency of project personnel, including training and mentoring – train and coach the players, identify future captains.
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects – manage teams, tournaments and leagues to make sure everything stays co-ordinated.
5. Strategic management, including participation in strategic planning and benefits management – game development, new rules of play, league development.
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance – Game recording, game statistics, records, halls of fame.
7. Management of customer interfaces – organize fans, sponsors, press, and all other associated parties.
8. Recruit, select, and evaluate project managers – Scouting, recruiting new players, transfers, and monitoring performance of players.
9. Execute specialized tasks for project managers (e.g. preparation of schedulers) – Provide referees, medical support, coordinate with the cheerleaders.
Recognizing that the true role of the PMO is to support, monitor, and promote the game; project managers can better engage in value adding interactions with the PMO. It is not appropriate for project managers to try and disengage with the PMO because they feel them an impediment. You can’t expect to opt out of a game rules, scoring, coaching and governing body and still consider yourself competing in the same sport. Yet, nor is it appropriate to try scoring a football game using a tennis scoring system so let’s make sure the PMO is aligned to the rules and goals of the game.
Project managers can use this analogy to ask for the appropriate scoring system for their projects and ask that they are assigned referees and coaches who understand the rules of the game. We would not score a hockey game using squash scores so if we are allowing both games to be played, we need to get with the program.
Promote Many Opportunities
So, what should a PMO do for agile projects? Well the good news is it should perform exactly the same roles as it aims to provide for traditional projects, but applied to the game of agile projects.
1. Monitor and control project performance – track velocity, track team and sponsor satisfaction ratings, look for dangerous velocity trends, check backlog size, monitor iteration and release plans.
2. Develop and implement standard methodologies, processes, and tools – provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile PM tools, educate supporting groups on iterative development concepts.
3. Develop the competency of project personnel, including training and mentoring – provide agile training courses, coaches, mentors, send people to local agile events.
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects – coordinate between agile teams, communicate between projects outlining progress, issues, retrospective findings.
5. Strategic management, including participation in strategic planning and benefits management – identify projects with opportunities for early ROI or competitive advantage.
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance – gather project velocity profiles, capture retrospective findings, include perceived PMO cost vs. value in project metrics.
7. Management of customer interfaces – provide product owner training, provide guidance on acceptance testing and how to evaluate and give feedback on systems. Champion the importance of SMEs to projects.
8. Recruit, select, and evaluate project managers – develop guidelines for interviewing agile project managers, get prospective PMs to comment of retrospective findings, ask about the drawbacks of agile to separate the “readers” from the “do-ers”.
9. Execute specialized tasks for project managers (e.g. preparation of schedulers) – train and provide retrospective facilitators, create agreements with agile project trouble shooters, provide mentors and coaches.
Your ability to align a PMO to agile project management factors will depend on a variety of factors; some within your control (your sales skills, reasoning, open mindedness, etc) and some outside your control (willingness of the PMO lead to listen, need for change, governing standards, etc).
Yet a PMO need not Produce Multiple Obstacles or focus only on Problematic Management Observations, with a simple shift in viewpoint it can stay true to its objectives and Produce Many Opportunities to allow me as an agile PM to Promote My Objectives of successful projects.
Thanks for the nice article, Mike. Very clever.
Posted by: Andrew Fuqua | November 12, 2010 at 07:30 PM