The PMO Lifecycle: Building, Running, and Shutting Down The PMO Lifecycle: Building, Running, and Shutting Down

Transcription

1 The PMO Lifecycle: Building, Running, and Shutting Down By William D Dow, PMP, ITIL, CSM, SA, PMPO 1

2 Copyright 2017 William Dow, PMP Dow Publishing LLC 1210 N 42nd Place Renton, WA All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without permission from the author. ISBN Printed in the United States of America All trademarks are the property of their respective owners. PMI: Always provide an attribution statement when using PMI marks. Registered Marks. Registered marks are marks that are registered with the U.S. Patent and Trademark Office. If the PMI List of Marks indicates that the mark is registered, the attribution statement should include the word registered, as follows: PMI, PMP, PgMP, ACP, PfMP, PMI-PBA are registered of Project Management Institute, Inc. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Inc., Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI. PMBOK is a registered mark of Project Management Institute, Inc. The Standard for Program Management Third Edition Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI. 2

3 Chapter 13 PMO Tools and Processes Review Questions 1. What are the five critical questions to ask when selecting tools? 2. What are the standard PMO tools? 3. What are the pitfalls of the magic pill solution? 4. What are the generic PMO processes? 5. What are the tips and best practices around PMO processes? One of the most important parts of building a PMO is selecting the tools for the organization, such as software. For the PMO manager, the tool-selection process is critical. In most cases, the PMO manager not only makes the recommendation as to what tools to select, but must also implement them in the PMO. Because of the importance of this process, it s a best practice for PMO managers to take it slow. Taking a slow (but structured) approach enables you to understand the needs of your management team and employees, and to find a solution that will work for everyone. As PMO manager, expect to be bombarded by software companies who use hard-sale tactics and promise their tool will save the day. This rarely works out in your favor and can end up costing you a lot of time and money. The last thing you want is to select some one-size-fits-all solution that your employees hate! Trust me: There is no magic pill solution. With regard to tools, budget is a concern. When building a PMO, it s easy to overlook the expenses associated with purchasing and developing PMO tools, not to mention the ongoing costs to maintain each tool, train employees to use it, and provide the necessary support. The PMO manager must understand the cost ramifications of these tools and work with the management team to secure the necessary budget now (and ongoing) to support them. In some cases, budget may not be an issue. In other cases, especially if you are still proving the value of the PMO, the budget might be limited and, therefore, your options will be, too. In addition to selecting tools, you must also define and drive key PMO processes. PMO processes, such as those pertaining to governance, change control, and escalation, are critical. Once you ve defined them, you can make adjustments as necessary. 3

4 Selecting tools and processes is exciting! When you select tools and processes, you set the foundation for how your organization will run. This gives you the ability to influence the execution of the PMO s portfolio, programs and projects. This is one of the best parts of being a PMO manager! Be warned, however, that rolling out these tools and processes requires great care. Even if the tool or process really is a perfect fit, if you fail to roll it out correctly, it could fall flat. It is a best practice for PMO managers to take a hands-on approach to selecting tools and creating processes. Otherwise, you may end up with PMO tools that aren t what you need or processes that don t align with your expectations. You can, however, expect your PMO employees to help evaluate PMO tools and assist in creating PMO processes. Indeed, this should be part of their job responsibilities. Their input is valuable because they are the ones who will use the tools and processes as they execute their programs and projects. For the same reason, leaving them out of the decision is unwise from a political standpoint. As PMO manager, you must strike a balance between sharing the load and dumping this work on PMO employees. 4

5 Standard PMO Tools When selecting tools for your PMO, you ll need to look at tools specifically for the PMO as well as tools that will be required by your company, whether they relate to your PMO or not. Here is a list of some standard company tools: Microsoft SharePoint or some other centralized repository for information A centralized status system A centralized financial system A centralized human resource performance system A centralized timesheet system Centralized purchasing processes and systems for processing POs and work orders A centralized employee-training system These tools are not PMO-specific. However, as company employees, your PMO staff will likely use them on a regular basis. As PMO manager, you should not purchase or re-create these kinds of tools without checking with management first. Here are some tools that are specific to the PMO: A centralized project repository, LAN directory, or website: Project teams must have access to and store project deliverables in a central location, which is backed up and secured by the IT department. Storing these items in a central location also enables the PMO manager to review project deliverables such as project milestone decks, program and project risks and issues, communication plans, and so on, without having to trouble the team. A centralized scheduling system: Your organization may require the use of a centralized scheduling tool such as Microsoft Project for all programs and projects, regardless of whether they all roll into your PMO. Tip If there are projects that do not roll into the PMO, then it is a best practice for them to still follow the same processes as the ones that do. That includes storing their project schedules in a central location for easy retrieval and reporting. A centralized status-reporting system: It is so important for PMO managers to be able to pull data and reports on how programs and projects are executing. Whatever system you choose must come with some reporting abilities that compile data into summarized reports, such as dashboards, or management reports, such as weekly program- and project-status reports. Bill s Thoughts A centralized reporting system is critical. It is the single repository for storing program and project status. In my PMOs, I not only ensured these systems were in place, I made sure I specified what data should be entered in those 5

6 systems by the project managers on my team. It is so important that you know what information is stored about the programs and projects in your PMO. In most cases, you are going to be the one who reports this data to your management team and customers. A centralized financial-reporting system: The PMO manager uses this system to track how programs and projects are executing against their budget. A centralized auditing system: This auditing system tracks how well program and project managers are tracking on creating their specific work deliverables. The PMO manager can review specific deliverables and audit items. A PMO engagement list: In this centralized document, PMO employees and vendors record their work efforts, including the percentage of work done for example, Bill Dow, Payroll Upgrade project, 60 percent. This gives the PMO manager an ongoing understanding of resource allocation within the PMO. When new programs, projects, or other tasks filter into the PMO, the PMO manager can check this list to determine resource availability. Program and project transition plans: These plans document key information about the program or project. They come into play when a resource (usually a program or project manager) rolls off the effort and you need to get the person who is taking over up to speed. Transition plans for both programs and projects typically include the following information: Schedules Centralized repository 10 PMI knowledge areas Governance process Change-control process Resource list Critical links Other information PMO managers should ensure that their program and project teams have transition plans in place right from the start. These plans will save hours if there is a change in program or project leadership. In addition to these tools, you, as PMO manager, might also need specific tools to run the PMO. In most cases, the tools you use will be the same as the ones used by your portfolio, program, and project managers. However, you may have some additional requirements, such as tools to generate special PMOoriented reports. You can identify what additional tools you might need by focusing on the critical five questions (who, what, when, where, and how) we discussed earlier. My book Project Management Communications Tools (Dow and Taylor, 2015) goes into great detail on a huge selection of communications tools more than 70 in all. 6

7 Who, What, When, Where, and How When evaluating and selecting PMO tools, you can use the same approach as a newspaper reporter. In other words, first consider the various processes, resources, and information needed in your PMO. Then ask the following questions: Who: Who needs access to PMO data? The answer to this question might include leadership, management, and/or team members. It s a best practice to assume you ll need to make your PMO data available to everyone, and then lay out the process for limiting access to that data if and when the situation arises. What: What type of information should your PMO produce? This answer will vary depending on who is asking and what level that person is in the organization. For example, a company vice president will likely want high-level information from your PMO, while someone who works as a team member on a particular project will need more detailed data. The PMO manager must select the right tool to satisfy both individuals and everyone in between. The PMO manager must also consider the PMO s organizational structure. For example, if the PMO has portfolio managers, program managers, and project managers, the data needed to satisfy them will be different than if your PMO has just project managers. When: When will current data be made available for reporting purposes? To answer this, you, as PMO manager, will need to consider internal administration timeframes and companyspecific deadlines for all the various types of information needed. You ll then use that information to determine when PMO employees must enter their data. For example, many companies have end-of-week status report deadlines, so company employees, including PMO employees, enter their data by end-of-day on Fridays. Where: Where will the PMO data be made available for reporting purposes? Think about where PMO data is stored and how best to access it for reporting. How: How is the data extracted and reported? Will it be available automatically, or will users have to pull it manually? Answering these five questions will give you an enormous advantage in identifying what PMO tools you might require and will provide you with the structure needed to start this process. With this information in hand, you can start to determine which tools might meet your needs. You can also consider the 10 knowledge areas of a project: integration management, scope management, time management, cost management, quality management, human-resource management, communications management, risk management, procurement management, and stakeholder management. These knowledge areas will drive many of your PMO reporting requirements, so you ll need to look at different tools with those areas in mind. For example, financial tools give you cost information, scheduling tools provide time and resource information, and so on. Tip Combining the five critical questions with the 10 knowledge areas provides a very structured approach for determining which tools are right for your PMO. Factors in Tool Selection Deciding which tools to use is not easy, and making the wrong choice can be costly not just from a financial point of view, but from a credibility perspective, too. For best results, you must understand various factors, including (but not limited to) the following: 7

8 PMO model (controlling, directive, supportive, and so on): Your PMO model will be one of the main deciding factors when choosing software tools for your PMO. For example, if you are running a directive PMO, your tool requirements will be much more than running a supportive model. Available budget: You need sufficient budget not just to purchase software and provide training, but to cover licensing costs, ongoing maintenance, or third-party support. that if your PMO is in its early stages, it s less likely you ll receive the funding you need. When the PMO starts demonstrating value, securing a budget for PMO software becomes much easier. Buy or build decision: Some PMO software products can be produced in-house rather than purchased. Results of pilot programs: You should conduct a pilot program for any software you bring into the PMO. The results of the pilot program will direct you in your decision. Methodology process groups: The portfolio, program, and project methodologies all play a role in deciding what type of software to purchase for the PMO. If your PMO is a programand project-only PMO, for example, you do not need portfolio-level software. Management team expectations: Management expectations, including what types of reports they expect from your team, will factor into what software you choose. Software features and various options: Most PMO software includes the following standard options: Professional support notifications to task owners Dashboards Web-based interface Time tracking Task lists Access control Budget tracking and reporting Calendars and schedules Third-party calendar integration Task assignments Resource allocation Advanced reporting, including charting and graphs Multilingual support Mobile device support Timing in Tool Selection In addition to considering what software to buy, as PMO manager, you must decide when to buy it. Variables that factor into this decision include whether your projects: 8

9 Regularly run late and miss internal deadlines Are of poor quality Constantly run over budget In addition, you must consider whether your management team and customers require hand-holding and constant reports on program and project progress. You must also take into account your available budget. As PMO manager, you should not bring in software if the PMO team is not ready for it. At the same time, you should not delay bringing in software until teams are struggling to execute their programs and projects. As PMO manager, your job is to help your teams be successful. Software products, such as a project-scheduling tool (for example, Microsoft Project), are critical tools assuming they re brought in at the right time. Tip It is a best practice for PMO managers to follow the same process for purchasing software that I have championed throughout this book: crawl, walk, run. Evaluating Tools Before you purchase tools, you must evaluate them to determine which ones are most suitable for your organization. Here is a simple process to evaluate PMO tools: 1. Select the evaluators 2. Set the evaluation criteria 3. Perform the evaluation 4. Generate the recommendation document Software salespeople can be quite convincing. Be sure you have a structured methodology for evaluating software products one that includes asking the right questions before you even think about bringing them into the organization. As PMO manager, you should own and drive this process. Otherwise, you ll be the one to suffer most. PMO members will come and go, but you ll be stuck with these tools for years. Your team members can certainly assist you with this process, but you must take ownership of it. It s up to you to know what software tools you are purchasing and why. Tip Before you get too far into this process, familiarize yourself with any company-specific rules and procedures around bringing in new software. Meet with your IT department or support desk to make sure you re on the right track. Otherwise, you might find yourself in some hot water. Step #1 - Select the Evaluators You need a good group of people to test the PMO tool. This pilot group should include personnel at all levels of the organization. It should also include at least two project managers and their teams. It is a best practice to include, at a minimum, these people: Executive or leadership team 9

10 PMO team members Program and project team members (include at least two teams) Customers or external staff outside of the PMO Tip Gather a broad group audience for your pilot programs. Don t limit the PMO tool-evaluation process to just PMO employees. Step #2 - Set the Evaluation Criteria Set the PMO software requirements according to the following factors: Executive or leadership team requirements Customer requirements PMO team-member requirements Costs (up-front and ongoing, support, and maintenance) Tool functionality Tool reporting capabilities Tool processes (and any associated processes that come with using the tool) Other company- or industry-specific criteria Step #3 - Perform the Evaluation Complete the evaluation, including testing and pilot programs. Your goal is to answer at least these minimum questions: Is the tool easy to use for a wide range of employees? Does the management team find value in using the tool? Did the pilot program teams use the tool? Did the pilot program teams find the tool valuable? Did the tool provide the required reporting capabilities for various evaluators? Does the tool fit within available budget? Tip Many companies will let you pilot their software before purchasing. Work with these companies directly to be sure you understand their evaluation requirements and processes. Step #4 - Generate the Recommendation Document Create the recommendation document. In addition to your recommendations, this document should include recommendations documented by PMO employees (after you review and approve them). It should 10

11 also include a training plan for the tool. When you re finished with the document, present it to management for approval. Do not bring in a tool without your management team s support. Tools often require process changes. Without management support, these process changes are next to impossible. The bottom line: It s not important how many tools you buy. Overburdening your PMO employees with too many tools can reduce their efficiency. On the flip side, not providing enough tools can be an issue as well. What s important is that you buy the right tools. Think about finding the right balance into your PMO. Bill s Thoughts It is very easy to make mistakes when evaluating and purchasing PMO tools. I know, because I ve made them myself. In one case, I brought in a risk-management tool before my PMO employees were ready to use it on their projects. It was my fault. I had failed to grasp the maturity level of my organization. Luckily, it was not too expensive. It did not break the bank. Still, it was a waste of money. To avoid mistakes like this, don t do what I did. Be certain your team is mature enough to use the tools you bring in. Also, start slowly. Purchase only a few copies of the software to begin with; then buy more if the tool proves to be useful for your organization. 11

12 Portfolio-Management Tools Chapter 10, Portfolio-Management Methodology, contains a list of top portfolio-management tools. This list changes all the time, however. There s no good way for me to keep it up to date. For the latest in portfolio-management software, your best bet is to spend some time researching the topic online. Interestingly, the market for portfolio-management tools is much more mature than the portfoliomanagement function in most companies. This is good news. In many cases, immature businesses can use these tools to raise their level of maturity. Then again, it s bad news, because forcing one of these tools on an immature portfolio-management could end in failure. Once again, as PMO manager, you must make sure your PMO is ready to adopt a tool before you implement it. Here is a list of the more popular Portfolio Management tools, most companies are using: IBM Rational Portfolio Manager Microsoft Dynamics CRM Microsoft Project Server Microsoft Project Service Automation UMT Project Essentials Planview Enterprise Most companies start by using one (two at the most) portfolio-management tool and focus on getting it to work before expanding any broader. Bill s Thoughts Don t spend lots of time evaluating tons of portfolio-management tools. Instead, talk to other PMO managers or IT managers about what they use to see what is working for them. I have several PMO managers and industry experts that I bounce ideas off. I highly recommend you assemble a similar group of individuals to do the same. 12

13 Program- and Project-Management Tools I ve combined coverage of program- and project-management tools into one section because program managers and project managers use similar tools. For example, you can just as easily use Microsoft Project to review a program schedule as you can to review an individual project schedule. As with portfolio-management software, the best way to stay up to date on program- and projectmanagement software is to conduct your own research online. You ll quickly notice that there are many tools available. Each has its own set features and functionality, which might align nicely with your needs. As PMO manager, you should filter through all these tools to determine what is right for your organization. Here is a list of some of the more popular Program and Project management tools used in the industry: Microsoft Project 2013 & 2016 WBS SchedulePro Deltek Active Risk The fact that there are so many tools on the market is good because it means PMO managers have an amazing array of choices. It s bad, though, because having that many choices can make it harder to choose! 13

14 PMO Processes As PMO manager, it s your job to define the processes your PMO will follow. Implementing processes that add value, improve efficiency, and move your PMO forward will help you increase the maturity level of all PMO employees When it comes to adding processes, you must strike a balance. Too many processes, and your PMO employees will feel overburdened. Too few, and project management goes right out the window. Types of PMO Processes Some PMO processes will be generic. That is, they ll work across the PMO. Others are specific, relating to portfolio, program, and project management. Figure 13.1 outlines these four types of processes. Figure 13.1: PMO processes Following are examples of each of these types of processes. These lists do not cover all processes, but they do include the main ones that PMO managers should create for their PMOs. Generic PMO processes include the following: Governance process Escalation process Change-control process 14

15 Financial process Lessons-learned process Procurement process Resource-management process Portfolio Review Board process Examples of portfolio-management processes are as follows: Portfolio-initiation processes Portfolio-planning process Portfolio status-reporting process The following are key program- and project-management processes: Program- and project-initiation processes Program and project status-reporting process Issue-management process Risk-management process Schedule update process Program- and project-quality processes Performance-reporting process This is the minimum set of processes the PMO manager should create. As for other processes for example, processes that are specific to your industry or company the need for these will reveal itself as you establish your PMO. Of particular importance is the performance-reporting process. Often, PMO managers wait to set up this process much later in the PMO lifecycle. This is a mistake. It s a best practice to develop the performancereporting process right out of the gate. That way, your program and project teams will focus on performance reporting from the very beginning. As a result, they ll think and behave very differently (for the better) while executing their efforts. For more information on the performance-reporting process, as well as the other processes listed in this section, you can search the Internet or consult with your peers. (I ve omitted detailed coverage of each process here because these details will vary from company to company.) Tip Most companies use many of these processes already. As PMO manager, you should see if any of these processes are already in place and adapt them as needed for use in your PMO. Then, you can add any processes the company doesn t already use. Rolling Out New Processes When it comes time to introduce a process, don t just toss it out there and leave it to everyone in your PMO to figure out how to use it. This not only diminishes your credibility as PMO manager, it also reduces the likelihood that your staff will accept and adopt the process. Instead, roll out the process in a careful and intentional way. 15

16 Some teams may not be ready to accept and adopt new processes. It falls to you to encourage them to take on that challenge. The best approach is to run a pilot program for the process, consisting of participants from highperforming teams. Let them vet each process and iron out any kinks. Then have them use the process regularly on their programs and projects. Finally, assuming the process is proven to be effective, roll out the new process to the general population. This will go a long way toward driving acceptance and adoption of the process across the organization. Before rolling out a process, the PMO manager should meet with the program and project manager to negotiate the timing. You don t want the roll-out to hamper your team s ability to execute. As PMO manager, you are in charge of driving process change, including creating a process, training staff to use the process, and mentoring and coaching when applicable. PMO Processes: Tips and Best Practices Following are some things to think about when rolling out processes in your organization to improve your chances of success: Understand the importance of piloting the process: You will have no idea if your proposed process will be useful until some groups try it on their programs or projects. Identify the program or project stage: Determine which stage in the lifecycle the program or project is in. Then decide whether adding a new process at that stage is appropriate. For example, introducing a new process during the closing stage would not make sense. Assess the time impact: Determine how much time the new process will add to team members schedules. Identify tools to support the process: There may be software tools available to support the new process. Identify training needs: Make sure team members have been trained and understand the process. 16

17 PMO Roundtable and Best-Practices Sharing Sessions We ve talked about formal approaches to rolling out PMO tools and processes. There are informal techniques, too. One of these informal techniques is the PMO roundtable meeting. Another is the bestpractice sharing session. Both of these meetings are open-forum gatherings, driven by the PMO manager, to provide informal training on required PMO tools and processes. All PMO employees are encouraged to come, but anyone working with the PMO is also welcome. The goal for attendees is to gain awareness of what the PMO is rolling out and to pick up some new tips and tricks for using a tool or process. Here s a sample meeting agenda: Meeting duration: 1 hour Time: 12 p.m. (local time) Attendees: All PMO employees and contractors Topics: Microsoft Project Server 2010, change management, project planning, WBS training, risk management, and issue management These meetings are a best practice. It s highly recommended that PMO managers implement them in the PMO. Do not miss the chance to update staff on the tools and processes in your organization. Summary This chapter covered a broad range of topics, from what kinds of tools and processes are needed, to the evaluation process, to rolling out tools and processes to the PMO. As PMO manager, you must drive the acceptance and adoption of PMO tools and processes. This is something you need to take seriously, and to continually address. You do not need to purchase all the types of software tools mentioned. Just because software is available does not mean it is right for your organization. Also, remember there is no magic pill in software no matter what some software salesperson says to the contrary. It is a best practice to pilot any software products you are thinking about buying for your PMO to evaluate them first. The pilot process, which does not have to take long or require much effort from team members, could prevent the long-term adoption of a product that won t work for the organization. Piloting processes is also a good idea. Embrace the task of selecting tools and processes! Introducing new tools and processes can be exciting not to mention add rigor and structure to your PMO. PMO Build Decisions Back in the introduction to this book, I talked about key PMO build decisions and presented a table you can use to map them out. This table will be an excellent asset to you through the PMO build process, so keep it handy, and use it to track everything as you go. For now, fill in the following: 1. Decide on the initial standard PMO tools and processes needed for the PMO. 2. Decide which portfolio-, program-, and project-management software you will purchase for your PMO. 17

18 3. Decide on your tool-evaluation criteria and how you will apply it in your PMO. Will it just be for tools, or will it include processes, too? How long will it last? 4. Decide which of the generic PMO processes, such as governance, change control, issue management, and risk management, you will create at the outset of your PMO. 5. Decide how you will use your PMO employees to create and roll out PMO process training. Company Profile Information Questions Earlier in the book, we also presented a set of questions to help you define the profile of your company. It is a best practice to review these again while you are filling in your PMO build decisions. If the company s profile information has changed since you first answered the questions, make sure to update accordingly. Failing to keep the company profile information current, could cause you to make PMO build decisions, that are out of date or not tailored to your business. Answers to Review Questions 1. The five critical questions to ask when selecting tools are who, what, when, where, and how. 2. Standard PMO tools include a centralized repository, a centralized status system, a centralized financial system, a centralized human-resource performance system, a centralized timesheet system, centralized purchasing processes and systems for processing POs and work orders, and a centralized employee-training system. 3. Not all tools accomplish what they promise. You could buy a product that says it can do this or that, and then end up stuck with a tool that is worthless to your organization. 4. Generic processes include governance processes, escalation processes, change-control processes, financial processes, lessons-learned processes, procurement processes, resourcemanagement processes, and Portfolio Review Board processes. 5. Tips and best practices include conducting a pilot program for the process, know what stage the program or project is in, assess the time impact of using the new process, identify tools to support the process, and identify training needs for the new process. 18