Project Management

PMO Setup T3 - Tips, Tools, and Techniques

Bringing you PMO Setup Tips, Tools, and Techniques for PMOs of all shapes and sizes.

About this Blog


Recent Posts

PowerPoint Presentation Tips

Planning tips from a mouse..!

Fool me once shame on you, fool me twice shame on me..!

Project Manager Knowledge Areas

Who is to blame when a project fails?

Top 10 Tips for a PPM Software Selection Project

Categories: PMO Setup

Selection (noun) / the act of choosing or selecting; "your choice of software was wisely made."
PMO Comics, by Mark Perry

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.

Tip 10: Select a vendor. Be mindful that there is a point of diminishing returns on the time that is spent in evaluating vendors and their product offerings. The leading software solutions will address a majority of the business requirements of most customers and few customers will implement and use all of the features of the vendor's product. While the identification of all costs is important, too much focus on price can overshadow other vendor selection criteria such as how well the product meets the needs of all of the intended users, how well it works with your existing architecture, and the extent to which it can be easily and effectively used in support of the project mix of your PMO.
Posted on: January 31, 2009 09:42 PM | Permalink | Comments (6)

Top 10 Tips for PMO Setup

Categories: PMO Setup

Setup (noun) / the way someting is organized or arranged; "what is your plan for the setup?"
PMO Comics, by Mark Perry

Top 10 Tips for PMO Setup

Tip 1: Start with a "virtual" PMO. For many organizations, not just small ones, a "virtual" PMO can be a great way to start. In the "virtual" PMO model, a sole individual or very small team is tasked to quickly get things set up and started, such as processes, polices, tools, and dashboards, etc, with minimal debate and distraction. Once set up, the manager of the "virtual" PMO, who may or may not be a manager leveled individual within the company, continues to maintain, improve, and promote the PMO to ensure that it meets the needs of those served by it and is positioned to take on further PMO responsibilities with time and success.

Tip 2: Establish a PMO Charter. Seek to establish a charter for the PMO that sets the tone of the organization and of the value add delivered. To start, keep it simple and ensure the participation of others in the development of the charter for "their" PMO. Where possible and measurable, align the charter of the PMO to enabling, facilitating, and achieving the key business objectives of the firm such as revenue growth, time to market, cost containment, customer satisfaction, productivity, and quality.

Tip 3: Beware of "Community of Practice" black-holes. A project management "Community of Practice" offers the promise to PMOs of increasing project management knowledge and skill throughout the organization. However, in far too many cases, the focus and effort to create a "Community of Practice" takes on a life of its own and becomes a black-hole in the organization where too much work goes into it and too little results come out of it. Seek balance to ensure that a "Community of Practice" initiative quickly adds value and leverages already existing works, rather than becoming an exhaustive, self-centric, effort unto itself.

Tip 4: Keep it simple. First and foremost, bear in mind that few PMOs have had start-up difficulties or have failed because things were too simple. Rather, complexity and too much detail in things are likely to be a far greater problem and contributor to execution difficulties and potential failure. So, be realistic and be balanced. Keep things simple, at least to start. A good foundation can enable lasting success and continual improvement. For example, don’t worry about sophisticated processes at first, but at getting the basics in place. Birth precedes maturity.

Tip 5: Seek to fully use what you already know and have. When setting up a PMO, there can sometimes be a rush to evaluate and implement new tools, in particular PPM tools. This rush to judgment can often result in selecting a tool based more on vendor supplied criteria rather than specific business use case needs of your PMO. Seek to first fully utilize the tools, platforms, and capabilities that you already have. Then, based upon your identified needs and improvement opportunities, evaluate vendor tools and service offerings that best serve your PMO.

Tip 6: Think processes, not methodology. Few people will read methodology documents. And, usually, they are static and quickly become out of date. Methodologies often give an illusion of project management consistency, when in reality most users find them too detailed to use or too time consuming to follow. Focus on net, streamlined processes that answer not just the "what is to be done", but the "who, when, where, how, and why" of the work effort as well.

Tip 7: Establish the components of your PMO architecture. There is no one vendor application or tool that does everything for your PMO, nor should it. Identify all of the tools, technologies, and services that support the project management office such as desktop applications, server applications, collaboration platforms, internal and external informational sites and services. Align project management maturity and capability maturity objectives with improvements to the architecture. Seek to first use the lowest level of technology architecture that gets the job done.

Tip 8: Identify what type of technology buyer you are. No one vendor has a lock on the market when it comes to tools and applications for your PMO. Nor can any one vendor give you an automatic guaranty that their offering is truly the best for your PMO and set of needs. So, when it comes to buying technology there are several factors to consider. One of the most important factors is the type of technology buyer that are you. Are you highly innovative and prefer to implement brand new technologies? Are you an early adopter? Or do you fall into a buyer type of early majority, late majority, or even a laggard? There is nothing wrong with any of the buyer types. In fact, you need to align your technology acquisition strategy and purchases with the buyer type that is best for your company and working environment. By understanding and knowing your buyer type, you can purchase and implement the vendor offerings that are best for you whether that is the latest bells and whistles or a time-tested, mature product that already enjoys an established customer base.

Tip 9: Use PMO dashboards to drive the PMO strategy. Many people think of PMO dashboards as something you can only get when you purchase a complex and costly PPM application. The dashboards that you get from your PPM tools, for the most part, are excellent, but don't limit your dashboards of key PMO information to only that of your PPM application. For one, not everyone in the organization will be authorized or have access to your PPM application. And two, you will no doubt want to "push-out" key PMO information and measurements to the executive and leadership team that may not be, or ever be, contained in your PPM application. Use PMO dashboards to drive your PMO strategy.

Tip 10: Create a journey, rather than destination, mindset. Sometimes, those that make up an organization can be too impatient for immediate success when it comes to the introduction of change. Whether implementing new systems, new programs, or new policies, often the introduction of change will not be a walk in the park. Usually, those with a destination mindset are too quick to rush to judgment and too quick to become frustrated when things do not work quite right. Establish a journey mindset within the organization that sets an expectation up front that execution difficulties are to be expected and should serve as input to get things right and not a reason to give up on the journey.
Posted on: January 24, 2009 06:41 AM | Permalink | Comments (2)

PMO Setup: A Practical Roadmap

Categories: PMO Setup

Setup (noun) / all the parts that work together in a system.

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:

  PMO Setup

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.

Posted on: February 06, 2008 11:08 AM | Permalink | Comments (2)

PMO Models: Are PMO Models emphasized too much?

Categories: PMO Setup

Model (noun) / a small copy of something that can be put together from parts.

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.



Posted on: February 02, 2008 08:11 AM | Permalink | Comments (1)

"I'm sick and tired of hearing things from uptight, short-sighted, narrow-minded hypocrites. All I want is the truth. Just gimme some truth."

- John Lennon