#PMO Visual Management Tools #PMOT #Agile

I have now been the Manager of the Project Management Office at the University for Manitoba for over two years. One of the first items I struggled with was trying to determine how to visually communicate the status of the portfolio of projects in a visual, intuitive way. I was a huge proponent of visual reporting and communication from my days as an Agile consultant. A textual or tabular report of the portfolio of projects just doesn’t inform stakeholders easily as to the breadth, depth, and status of the portfolio of projects.

Epiphany

Late one day, I had a discussion with our CIO in regards to how he had seen a radar diagram used as a means to communicate the life-cycle of Infrastructure within an environment. After a short discussion, we had formulated a plan as to how it could be used to display the portfolios of our projects.

We had devised a template to show the following:

• Separate portfolio sections with
  • Projects represented by coloured circles of different sizes
  • Status of projects indicated by circle colour
  • Projects on hold indicated by a diamond
  • New projects shown by a distinct circle icon
  • Size of project indicated by size of circle
  • Indication of a project being over budget by a halo around the circle
  • Project phase indicated by the circle’s proximity to center of the radar
  • Project’s progress indicated by the circle’s overlay to show percentage complete

Results

The Portfolio Radar diagram has been refined over the months. but it is probably the most requested document the Project Management Office produces.

Recently, I have created a personal radar that I use to track my to-do items. Like a lot of managers, I usually have 10-20 items on the go that need periodic attention. These items can usually be categorized into 3-4 “portfolios”. The radar template is much more appropriate than the standard kanban board used for projects as the items can be recurring and of extended duration. Some of them can be standing items which are never really done. The “Personal Radar” is a great diagram for showing which items need to have attention paid to them next week and which ones can wait.

Like the Portfolio Radar, the Personal Radar indicates:

• Separate portfolio sections with
  • Items represented by stickies
  • Urgency of attention indicated by stickie colour
  • Stickie phase indicated by the Stickie’s proximity to center of the radar

This “Personal Radar” for the PMO Manager has been a great assistance to stay of top of multitude of items required in the PMO. The Personal Radar gets reviewed at the start of the week to plan the week and at the end of the week to ensure the items received the attention they deserved.

So far, this is becoming a key deliverable to stay on top of items. An example of the Personal Radar is show below:

Summary

The Portfolio Radar and Personal Radar have been excellent diagrams to use for communication of project status and task management. I’d love to hear your experiences with other means of visual methods for Project Management and personal management.

Advertisement

Can a Project Management Office be #Agile #PMOT #PMO

Can a Project Management Office be Agile? Should it? Can agilist succeed in Project Management Office?

I must admit I had thought that a Project Management Office was one of the most non-Agile entities in an enterprise. I viewed the PMO as a command and control type of structure that primarily just created templates and enforced standards. It turns out that an enlightened PMO behaves much like an Agile coach.

The first two types of PMOs do appear to be very traditionalist. Those first two types deliver limited value to the clients.

PMO Level 1

The goal of this level of PMO is typically standardization and repeatability. The vehicle for this to be achieved is usually templates and standard project deliverables. While some level of consistency is good for projects, these templates and deliverables provide most of their value to the Information Technology organization and not the client. Given that Information Technology should be a service provider to the entire enterprise, this type of PMO is a hard sell to the clients. This type of PMO is also not very Agile as the entire focus is on obedience to the templates.

PMO Level 2

Some time after the PMO Level 1 is set up and projects are still not consistent or standard, there becomes a secondary focus on the Projects Managers themselves. This type of PMO becomes a type of Career Centre to help coach the Project Managers in their career. This type of PMO is starting to recognize that projects and project managers are unique and it isn’t as easy as just defining standard templates. There needs to be more discussions and accommodation with project team members to achieve success. This type of PMO is more Agile, but still limited in the extra value it provides client. Ideally, the extra coaching of Project Managers will deliver more value to the clients, but the focus is still Information Technology.

Thankfully, the last two types of PMOs turn and focus more on the client than Information Technology.

PMO Level 3

The third type of PMO signals an important shift in focus on the PMO. As the enterprise and the PMO grows, it becomes apparent that the PMO is still not returning much value to the clients. As moe and more projects are executed in parallel it becomes harder for the enterprise to keep track of everything. At this level the enterprise requires the PMO to produce consolidated Project Reporting and then soon after Project Resourcing. Now finally the PMO is providing value to the clients by providing brutal visibility as to the status of each project and helping to prioritize the projects, people, and initiatives across the entire organization. There is never enough hours in the day, but the PMO can help by coordinating effort towards the most important activities.

Suddenly, this type of PMO is starting to appear quite Agile. Brutal Visibility and Collaborative Prioritization!

PMO Level 4

The fourth type of PMO continues that shift in focus to providing client value. Now that the PMO has provided Brutal Visibility and Collaborative Prioritization for projects within the PMO, how can that be extended outside the PMO? This is typically done by providing Governance over an idea or innovation intake process. The PMO are the stewards of the process that provides idea and innovation information to a representative committee for approval and prioritization to become projects. Usually this type of PMO is also tasked with providing additional Financial Information that will be required to determine the number of ideas or innovations that can be turned into projects.

This type of PMO finds that an annual process to reviews ideas and innovations and approve potential projects to be too slow and cumbersome. We need to meet much more frequently. Usually these Governance Committees start out meeting quarterly and soon move to monthly Iterations. (See what I did there?)

This type of PMO is becoming more and more Agile by providing Iterative Decision Making and limiting the Backlog of Work.

Finally this type of PMO reports the final outcomes of projects, both Financial and Client Value delivered. As the PMO is now accountable for the project outcomes, the PMO conducts Project Closeouts and Lessons Learned sessions for Continuous Improvement.

Summary

Brutal Visibility and Collaborative Prioritization? Iterative Decision Making and limiting the Backlog of Work? Continuous Improvement?

Can an Agilist succeed in a PMO? Sounds to me like you have to be an Agilist to succeed in a PMO. 🙂

 

 

Project Manager’s #1 Challenge #PMOT

One thing that has always perplexed me on projects is how poorly we as Project Managers and project teams manage risk. All of us have the initial Risk Management meeting and try to capture the risks and mitigations required. But even in that first meeting, we fall short in identifying and planning how we are going to address the risks on the project.

Why?

At one time I had thought it was just because we as Project Managers got busy with the work on managing the project and forgot about scheduling follow-up Risk sessions. But that wasn’t it, even when the Risk items were incorporated into weekly status reporting, the effort and attention paid to risk management was just ceremonial. There was something else at play.

I was working on another long project and we were discussing the challenges with the issues and risks encountered. In a retrospective we discussed how we managed the issues and risks looser and looser as the project executed. We did this as we became more comfortable with the client and they became more comfortable with us. Unfortunately new players came onto the project later and changed characteristics of the project. This changed the issues and risks but we were not managing them as formally as before as we became comfortable with the issues, risks, client, and the project.

One person summed this situation up perfectly. “On projects it is natural for the project team to become the project. This eventually happens with the Project Manager.”

This is where the lack of formality and process can be a problem for the Project Manager and the project.

Become the Project

“Become the Project” – sounds rather Zen-like doesn’t it?

Become the Project to me means that you have somewhat lost your objectivity and like the rest of the team you are thinking in a positive and trusting manner. You start to expect issues to be resolved very soon, that risks will not happen, and that if things happen we will address them as one homogeneous team. Well it turns out that perspective is valuable and required by some of the team members as they are working through deliverables, the Project Management and leadership need to be careful to not fall into this lack of formality.

So what to do?

What can we do? As much as we say not to do it, it is human nature. Trust will be built up and used after working with the same people for months and years.

This is where your Project Management Office or Deliver Management Team needs to help your project team by providing the independent 3rd party or sober second thought perspective. The Project Management Office or Delivery Management Team’s role is not to own the risks and issues but to facilitate the review and consult on them as an independent 3rd party. In this way, we ensure the review happens and we make decisions based on all the most current data from the project balanced with objectivity and experience.

Ultimately you want your team and Project Manager to be the project, we just need to add a check and balance to ensure issues and risks aren’t overlooked.

#Agile PMO – A new hope #PMOT

On my most recent project, I have had the good fortune to be asked to help to lead the Project Management Office. (PMO) There had been multiple leads of the PMO before, but each one was not able to provide all the information that the senior stakeholders were asking for. Given my background in Agile, I was very interested in how I could create a PMO that was lean and focused on value as much as possible.

The Project

The project is an enterprise implementation of an SAP solution. All told, there are hundreds of sub-projects that are required. At any given time, there are 20-30 sub-projects that are executing at any one time.  It is a large, nasty, wicked matrix of sub-projects, requirements, and issues. Although I had done extensive Project Management and some Program Management, this was at a scale that I had less experience with. I did have three huge advantages though:

1. Relationships – I had excellent relationships with the other teams and Project Managers in all of the different sub-projects. I also had previous relationships with the Chief Architect and Project Director.
2. Trust – I had built up trust with the Stakeholders for the project. We had built up a relationship over the past year where we could have honest discussions on any aspect of the project.
3. Experience – Although I had limited experience on leading a PMO for a project of this size, I did have the experience of seeing what the previous PMOs lacked. This gave me a head start of what I felt we needed to ensure this PMO delivered. Of course, we would need to validate this with the stakeholders.

My Approach

I knew I wanted to implement an Agile PMO, but what exactly does an Agile PMO look like? I needed to do some research…

Luckily I found the a book titled “The Agile PMO” by Michael Nir. This book was an epiphany. It provided grounding and affirmation on what I felt an Agile PMO should be. The book also provided clarity in the ways that PMOs can go astray. In particular, Michael Nir described the three typical types of PMOs mistakes:

1. Tactical PMO – The Tactical PMO is created in response to the enterprise’s need for consolidated visibility on the all the disjointed projects that are currently executing. Sadly, there is usually isn’t analysis or planning on what value the PMO should provide other than providing consolidated information.
2. Methodology PMO – The Methodology PMO is created to provide templates and standards in the hope that everyone executing projects using these standards will result in more predictability and visibility. Closely related to the Methodology PMO, is the Tool PMO where the adoption of standard tools is seen as the solution to being able to provide more predictability and visibility.
3. Project Manager home PMO – The Project Manager home PMO is a PMO that gets created as a Career Centre for the corporations Project Managers in the hope that using standard Project Management will provide value to the corporation.

After I read these three types of PMO mistakes, I immediately recognized all the PMOs I had seen gone astray in the past. Sadly, I think most of my own previous PMO efforts were variations of the Methodology PMO. I felt shame.

Michael Nir then succinctly described the solution – the Value PMO.

Michael’s definition of a value PMO was :

“A PMO creates value through assisting the organization decide where to invest its resources for the optimal return on investments. Tools, methodology, techniques, processes are all nice to have, however they do not constitute an objective in themselves.”

awesome. We now had a vision.

Our PMO

Now that we had a vision, it seemed clear to me that we needed to confirm our PMO vision in three areas and gain agreement from stakeholders:

1) Confirm the Objectives that the PMO would have with the Project Stakeholders

2) Confirm the Value that these Objectives would deliver with the Project Stakeholders

3) Confirm the Service that the PMO would provide to the sub-projects themselves.

For points 1 and 2, the following matrix was developed and validated as being correct for the Project Stakeholders:

Objective	Value
1) Validate planning standards across the program	Minimize the probability and magnitude of changes required to the amount of project work by confirming that the project scope is understood.
2) Create a program level schedule for key development, testing, and implementation milestones – at the project and feature level	Allow Stakeholder visibility on the plan so that we can ensure people are working the most important items. Also allows for Stakeholders to have a line-of-sight so that decisions can be made if the schedule is not acceptable. These decisions can be priority calls, people assignment, or scope inclusion/exclusion.
3) Assist projects in getting assistance with issues	Help to resolve project issues asap and minimize the effect these issues have on the project and program
4) Assist projects in creating and executing mitigation plans for identified project risks	Reduces the project risks and the effect these risks will have on the project and program
5) Provide consolidated reporting	Allow Stakeholder visibility on the execution so that we can ensure people are working the most important items. Also allows for Stakeholders to have a line-of-sight so that decisions can be made if the schedule is not acceptable. These decisions can be priority calls, people assignment, or scope inclusion/exclusion.
6) Provide guidance on enterprise standards for project deliverables	Provide consistency across projects to minimize the probability and magnitude of changes required to the amount of project work by confirming that the project scope is understood.
7) Validate Resource Plan across the program	Minimize the risk of resourcing issues in the future by validating that adequate resources are allocated and that the resource plan is realistic and reasonable

For point 3, we perhaps set the PMO tone in the most important way. Instead of the PMO telling the project what they needed to do,  our focus was on asking projects how we could help them. For example, we asked:

1. Are there any obstacles we can help to remove?

2. Do you need any additional people, resources, or changes in priority  to keep to the plan?

The story so far

We have received extremely positive feedback on this new Agile PMO. I’ll create a subsequent post on how the PMO evolves as we work with the Stakeholders, but indications are that this PMO is positioned very well to succeed and provide true value to the corporation.

Mostly importantly the Project Stakeholders AND the sub-projects see value it what we are doing…