PMO Setup T3 - Tips, Tools, and Techniques

Top 10 Tips for a PPM Software Selection Project

Tip 1: Treat PPM software selection as a project. When selecting a PPM solution, manage the selection process just as you would a project. Applying good project management techniques in the effort will ensure that the solution you select best meets the requirements for which the solution is intended and justified. A rich in function solution that provides features that are not needed may not be better than a simpler solution or approach that meets the core needs of the organization. Likewise, a simple solution might not provide long term viability as the organization matures. Use project management techniques to ensure focus is placed on needs and requirements as opposed to vendor bells and whistles.

Tip 2: State the business problem. State the business problem driving the selection of the PPM solution. Does the current system or tool fail to provide the needed functionality for managing projects and resources? Do specific needs exceed the abilities of the current system? Is project performance below management expectations? The first two problems are more easily addressed from a tool perspective, whereas the third is more problematic. If processes are flawed or non-existent, implementation of complex software will not resolve them problem; rather it will add to it.

Tip 3: Set improvement objectives. In order to define and prioritize requirements, set improvement objectives early on in the PPM tool selection process. The project manager for the PPM software selection project should document and gain agreement for both the current state as well as the desired state. And to achieve the goals of the desired state, set measurable objectives to be achieved. This will keep the software evaluation and selection process on track and aligned to business needs, rather than vendor software bells and whistles.

Tip 4: Document the proposed project management process. Before continuing with software selection, document the proposed project management process. If the current project management process is not working effectively, correct the process. If specific project management goals are not being met, perform root cause analysis to determine the required improvements in the current process. Until such time as the project management process has been thoroughly documented, hold off on further PPM software selection activities.

Tip 5: Integrate the appropriate software tools into the project management process. Use your project management processes to contextual show how the various software tools and applications are used throughout the entire project life cycle. Document the inputs, outputs, tool usage best practices, tips and techniques. Do not limit tool integration to just the project portfolio management application.

Tip 6: Generate requirements from process mapping. Process mapping will identify requirements critical to the success of the PPM software application. Use process mapping to arrive at a full view of requirements including both the requirements to be addressed by the PPM application and the requirements to be addressed outside of the PPM application.

Tip 7: Select a short list of three vendors. A small number of vendors is desired for the short list. The detailed set of requirements will result in identification of needs that can best be met by two to three vendors. Too many vendors making the short list is an indication that requirements definition has not produced differentiating features and that any product can do.

Tip 8: Test the vendor products. Request that the vendors provide a testing environment for their software. Test each of the shortlisted vendor product offerings with data that best represents your business environment. Used experienced staff that understands the how the products work to evaluate the capabilities of the software and results achieved of the product tests.

Tip 9: Judge the vendors. All vendors have strengths and weaknesses. Before making a final decision, judge the vendors on their track record. Key considerations include their reputation, customer base, years in business, financial condition, and long term strategy. Seek to discuss the performance of the vendor and their offering with at least three customer references. If the vendor and their product were successfully implemented at organizations similar to your own, then you can expect a similar success.

Setting up a PMO is not easy and there is no one right approach to go about. Some folks advocate focusing first on the kind of PMO that you want to have - the PMO Model. From there, organizational decisions can be made, PPM tools can be implemented, and the PMO is off and running. Sometimes this works, but far too often the PMO and the leadership team is faced with the reality that despite the investment in the organization and the new tools, project results have not significantly improved.

An alternative approach that is applicable to PMOs of all shapes and sizes is to focus less on organization and rushing to purchase a PPM tool (at least initially) and more on the processes of the PMO as the mechanism to predictably and consistently achieving the objectives for which the PMO was established. Toward that aim, four steps emerge as a practical roadmap that just about any project office can follow:

First, define a useful and usable process for project management that describes not just the "what", but the "who, when, where, and how" of the what is to be done. Don't think methodology such as "how to scramble eggs", rather think process such as "how to make breakfast for your mom and in her kitchen!" In defining the process, provide structure, and flexibility within structure with such things as scalable workflows, multiple process views, and tool options. And, don't forget the process owners, subject matter experts, and mentors.

Second, the setup of a workplace process framework. This involves a few things such as defining the PMO architecture (PPM application, collaboration platform, PMO content assets). Ensure that the content assets of the PMO are accessible and easy to use by all those involves; project managers, project team members, management and the leadership team. PMO assets to consider include processes and templates, policies and dashboards, and supporting guidance, tools and techniques, and subject matter expert knowledge. And seek to balance "technology vs. theory". Technologists often focus on the latest in product bells and whistles. PPM tool features help, but they don't replace the processes of the PMO. Likewise, theorists can sometimes focus too much on by the book knowledge and approaches that work better in theory than in practice with respect to the constraints of the organization. And lastly, in setting up the process framework, avoid project management methodology "blackholes" - such things as Gap Analyses, PMMM assessments, and methodology updates, etc. Don't take too long to learn (or have someone tell you) what you already know.

Third, use what you already know and have. Often, implementation of new project management systems are met with difficulties, to no discredit of the vendor’s application, rather on account of the fact that tool functionality was not the real problem in the first place. As Deming says, “95% of a problem is the process”. Seek to fully maximize the return on your "past" investment and use continuous improvement processes to identify, confirm, and drive changes in tooling.

And fourth, forgive human errors but not process errors. In a project management culture, every project is an opportunity for some kind of lessons learned. Expect and embrace human errors as they can serve to identify those things in the process (errors and/or omissions) that led to the problem in the first place. Some organizations even tie bonuses for project managers to their improvement suggestions.

These practical steps don't necessary need to take a lot of time or money to do. And, they can support and be performed periodically as well as before, during, or after such things as organizational and/or new tooling decisions. The end result offers to be a PMO with a improvement oriented culture based upon soundness of method that delivers projects consistently and effectively.

Why is it that so much deliberation is placed on PMO Models? Too often, organizations myopically focus on "the model" and in end up choosing which of many potential approaches is the best fit. And sometimes lost in the deliberations is the fact that each of these many models have practical characteristics that would well serve just about any PMO.

Of course models are helpful. They allow us to envision, in advance, what the final outcome will be. And, they also allow us a common view from which we can have a meaningful conversation, exchange of ideas, and some degree of debate and consensus. And the better the model, the better the chance of successfully achieving the outcome for which the model was entertained in the first place. Like a blueprint for a skyscraper. Right, well maybe not.

One of the problems is that models, especially PMO models, unlike blueprints are typically high level constructs. PMO models often offer a buzzword or catch-phrase followed by just enough description to sound plausible or should I say sellable. Some of the many PMO models out there include such examples as:

• Example 1: The Easy to Visualize Model
  • Control Tower
  • Weather Station
  • Resource Pool
• Example 2: The How Good Can We Be Model
  • Basic PMO
  • Advanced PMO
  • Center of Excellence PMO
• Example 3: The How We Do Things Model
  • Supportive
  • Controlling
  • Directive
• Example 4: The Organizational Chart Model
  • Enterprise Level PMO
  • IT Department PMO
  • Project Control Office
• Example 5: The Simple This Way or That Way Model
  • Support Role
  • Supervisor Role

No doubt about it, PMO Models make for great, entertaining, short little presentations at conferences, seminars, and events. They are ideal for those dinner meeting venues where you can enjoy a fine meal and then listen to just about anyone for the next sixty minutes, especially if also provided is a good cup of coffee, a rich chocolate dessert, and a PDU. But for many organizations, the problem with PMO Models, as a concept, is that they intrinsically are self-oriented and direct much, if not all, of the attention on the PMO as an entity unto itself. This creates a different kind of thinking and mind set and soon lost, forgotten, or misplaced as a priority is the business reason for which the PMO was created and exists to serve. Placing more emphasis on the business reason for the PMO and how the PMO can help people succeed, as opposed to the "model", helps all those involved in a number of ways. For one, it keeps the PMO, as an entity, aligned to the needs of the business and to the changes in the business. Additionally, it enables the PMO to be structured and to exhibit optimal and situational behaviors of more than just one PMO Model.

Are PMO Models helpful? You bet. Is there one PMO Model that is right or right for you? Probably not. How much time should be spent debating PMO Models? About an hour, coffee and dessert are optional.