If you’re building a PMO and have a 3 year plan – drop it now! It probably will not work. If you’ve got portfolio management scheduled for introduction in September look out. If you’re two years into your PMO build and can’t figure out why you have no traction and support is slipping, then I may just have the answer. Or I might not, but here are some thoughts.
As you’ve guessed by the article title I am going to suggest that we steal a technique from the software development industry. While I am not an agile expert by any means, there are some very successful practices that you can employ while building and growing your PMO. For you Agile gurus out there, I am about to butcher the technique so you may want to look away. Here are some of the tenets of an Agile methodology that we can adopt.
Iterations: Agile methodologies have a focus on short cycles that produce demonstrable deliverables. In software the deliverable is working code. In a PMO it would be one report, process, form, method, class, etc. For example, you might have a plan to deliver a project pipeline governance process in 3 months. Under a non-agile approach you would plan out the methodology, the forms, and the activities. After three months of analysis you would demonstrate your new procedures. And then everyone would want changes.
In an Agile methodology, you might plan to develop the pipeline report first. In two weeks you would develop the report and show that to your stakeholders. At that time you would get direct feedback which may cause you to change direction. Because you have done only a small amount of work, you can easily redirect future work with only a small adjustment. As you progress through the project, you can make incremental course corrections creating only what is needed and creating that sooner.
Product Owners: The product owner is like a sponsor on steroids. Where a project manager might report to the project owner once a week and give status updates, the product owner is an integral part of the development team. The product owner is involved in the day to day decisions and activities. Using the example of a 3-month pipeline governance project again, you might visit with your sponsor weekly and give updates on progress against the plan. At the end of three months the sponsor will view the completed product.
Using an Agile approach the product owner is part of the daily decisions that make up the final product(s). When the product owner sees something they want to change, they do it immediately. They add or remove components as they are being built. This ensures that the final product meets the goals and expectations. There are no surprises after 3 months of hard work. The product owner has seen everything as it was being created, and has made adjustments wherever needed. Imaging following your new car down the assembly line and picking out what you wanted all along the way, as opposed to waiting until the car showed up at the dealer.
Product Focus: In many projects today, we tend to discuss and focus on the progress the project is making against the plan. We report on risks of not completing the work on time. We have red/yellow/green status reports on scope, schedule and cost. All of these are great, but the do not tell anything about that which is being created. It is vital to understand our costs, but not sufficient.
Agile focuses on the end result or product. The goal of agile software development is “working code.” The primary goal is to create something that works. In building a PMO, a concentration on costs or schedule can divert focus from the actual product(s) being built. Keep your attention first on quickly building something of value. Show your working product frequently and get feedback.
Communications: Agile is very clear on the importance of face-to-face, direct and frequent communications between all team members. This may not be as big a problem with PMOs as it is with software. Unfortunately when we get into “project” mode, we tend to formalize communications into such things as status reports, weekly meetings or presentations. We schedule our weekly status meeting and our monthly presentations. Often the reports are not read, and the meetings are missed by key stakeholders. We produce our information and it is often not received. Unfortunately, the project still proceeds since no response is considered acceptance and approval.
Agile advocates face-to-face discussions. It is difficult to ignore someone standing in your office. Further, you are talking about the work itself and not about the progress made. Show your stakeholders incomplete deliverables and ask them questions, get their ideas. Do this constantly and not on a scheduled basis. Granted you may need to schedule time here or there, but make it more informal and much shorter – 15 minutes on one topic rather than a one-hour review of the project. Whenever possible, work towards a face-to-face conversation. I know virtual is in and there are many advantages to diverse, global teams. The truth is that mankind has been doing face-to-face communication far longer than video conferencing. We are better at it and we communicate more information more accurately that way.
As always, I hope there is something you can use here. Some of this may be useful for you, some may not. I'm not presenting this as an all-or-nothing or comprehensive solution. Pick what makes sense for you and throw the rest away, or save it for later. It is YOUR PMO.
