Evaluating Organizational Readiness for a PMO

May 1, 2013 By Leave a Comment

According to industry experts, a majority of efforts to establish a Project Management Office fail because leaders do not sufficiently assess organizational readiness for change. How do you know if your organization is ready to take on the challenges and embrace the opportunities of implementing a Project Management Office?

The best time to assess an organization’s readiness for change is well before you begin implementing a solution. The importance of assessing your organization’s readiness for change cannot be underestimated. Projects, resources and work will form the core of any PMO; hence, project management maturity is a critical factor in determining what systems or practices should be introduced and to what level of functionality.

But remember, just because you are not operating at top levels in every discipline of a Program Management Office does not mean you’re not ready to take the plunge. Deployment of a PMO is a journey–one that goes through many iterations and cycles as it grows and matures.

To begin with, don’t be surprised if you end up spending the bulk of your design session answering just the basic questions. It’s imperative to identify the pain points before finding any kind of solution. The challenge here is that this is often a “rubber hitting the road” moment, where different departments and groups realize for the first time how different they think core processes are managed. Looking at these symptoms will help you to determine whether the need for a PMO exists in your organization:

  • Project Inventory: Do you have a clear record of every project and initiative under your area of control? One of the most basic functions of a PMO is to gather record and track progress of all initiatives so you can make informed decisions on which projects to invest in and on which projects to pull the plug.
  • Strategic alignment: If there is a lack of strategic alignment of individual projects with the overall objective to achieve desired results, the effectiveness of projects delivered will always be unsatisfactory. This is often called “doing the right projects”.
  • Project intake and selection: Without a well-defined project intake process, there is no way for the business to effectively prioritize new investments with business priorities.
  • Project overload: If there are too few resources available to meet project demand within an organization, it will extend the project delivery time and provide very little visibility into individual projects
  • Resource bottlenecks: An immature resource management process can lead to resource contention, underutilized resources and late project delivery.
  • Lack of established processes: Without established processes and consistent use of the processes, the risk of project failure rises.
  • Lack of approved tools: A lack of approved tools can result in each project manager using a different set of tools and will likely be overloaded without a way to make smart tradeoffs.
  • Lack of visibility: An organization that has little or no visibility into the various projects that are currently going on is essentially sailing blind. The ability to monitor projects in various businesses and align them with the strategic plan is vital to a company’s success.

The next step would be to gauge the maturity level of the organization by just looking at some of the most fundamental processes already in place for different projects across the system. For example:

    • Are processes clearly defined or are they ad hoc?
    • Do users use the same tool consistently or is everyone on their own when determining what tool works best for them?
    • How are projects being managed at different task levels?

The answers to the questions will not determine if an organization is ready for a PMO–they will help you set expectations for what is possible and where to focus your energy to set realistic and achievable objectives for deploying your PMO.

Once you have clearly identified the information that must be captured for all your projects, clearly define what processes will take place to execute on them. The level of project detail and the depth of your processes will help determine maturity and corresponding functionality that should be introduced to the business as a part of the PMO.

All this analysis activity is neither a gap analysis nor an “As-Is/To-Be” analysis. Rather, it is an analysis of the needs of the business. It could be compared to a market analysis that organizations do to understand their markets and identify products and services to match that market. The objective here is to identify the challenges, pain points, objectives of the business, and to learn as much about the business and its strategy as possible. These translate into opportunities for the PMO to be a “value-add” department instead of an “overhead” department–and makes it easier to make the case for a PMO to the leadership and the rest of the organization.

In my next article, you will learn more about setting up a PMO charter and how to introduce PMO processes and tools within an organization.

Filed Under: The Business-Driven PMO Tagged With: , , , , ,

Programs and Portfolios – Striking Strategic Balance

April 11, 2013 By Leave a Comment

A kid squeezes a couple lemons, mixes it with some sugar and water and sets up a table on their front step. After a few hours of minding the lemonade stand they have a fistful of quarters and dollars to show for the efforts.

Your company is a little more complicated. You develop, market and sell products and services that number in the hundreds or thousands. Your clients’ needs are as complex and sophisticated as the environment you compete in. Your teams in different business functions are working to prioritize demand and try to launch the project that is the most strategic and valuable, while considering risk, complexity and time. How does anyone balance it all? The answer:  programs and portfolios.

First a definition. While the two terms are used interchangeably, there is a distinction between them:

  • A program is a grouping of projects aligned by a common theme from an organizational standpoint. Examples can be seen as aligned by a product launch or a corporate strategy. Typically all projects in a program are aligned with that program exclusively – projects tend not to contribute to multiple programs at once because it makes aggregating information, especially financials, very difficult.  One last and important point is that there is a common understanding of the program’s themes and goals and every project in the program is working toward furthering the objectives of the program.
  • A portfolio is best described as the “dotted lines” where the project is aligned. Your project may be aligned with the ‘Mobile Apps’ program, but it is also aligned with the ‘Customer Service’ department, the Seattle office, the ‘Customer Retention’ strategy and the ‘high risk’ project category. Portfolios also tend to be personal:  “I’m the operations manager.  Show me all the active projects that are aligned with our Cost Reduction initiative, that are based in Paris, Pittsburgh and Sao Paolo, where Operations has contributed resources.” With all the dimensions of a portfolio, the common understanding is that projects can have a many-to-one relationship with multiple portfolios.

A great ‘real world’ example of programs vs. portfolios is that you report to your immediate boss (program), but also have responsibilities – the dotted lines in an organizational chart – to other groups or business leaders (portfolios).

So what is the best way to organize project? The most common ways are by business unit, by overall location, or by business function – all of these structures help group projects along a common theme or user community. All HR or IT project are grouped together, or all Aerospace or Currency Exchange projects are grouped together. This gives us a manageable size of projects to deal with. As a best practice, however, if you find that your organization reaches 50-70 active projects, it is likely time to further divide your program into sub-programs.

A best practice on portfolios is to treat them as personal lists of projects based on what is important to each key user. Since portfolios are “invisible” and can be as unique as the people who define them, it is not unusual to have dozens of portfolios for every program.  Portfolios also tend to be dynamic in that projects are launched and completed, and realigned based on the stage they are at, which can add and remove them from portfolios almost daily.

So here is the take away: when reviewing your project groups, ask yourself these questions:

  1. Is this grouping something that most people in the company are familiar with?
  2. Does the grouping remain constant – is it a fundamental structure in the company that does not change often?
  3. Does this grouping have common properties, and are they used by homogeneous groups?
  4. Do we often want to control or direct a group of users to this list of projects?
  5. Do the projects in the group align with other groups equally?
  6. Does this grouping look like it only serves a small group of individuals in the organization?
  7. Do projects listed in this group frequently change?

If you answered yes to the first four questions, you probably need a program. If you answered positively to the last three questions, a portfolio is probably better suited for this organizational structure.

Ultimately, there are no hard and fast rules for structure or size of a program or portfolio. Gather feedback from your user community to determine if the current structure works, or if it is too complex, too deep, tpp confusing or simply doesn’t meet the reporting requirements of the business leaders.

 

Filed Under: The Business-Driven PMO Tagged With: , , , ,

Principles of Scoring Models

December 11, 2012 By 1 Comment

When I was running the IT-PMO at PeopleSoft we faced an interesting dilemma. As we finished work on the integration of JD Edwards there was a ton of unmet demand for IT work from all corners of the enterprise. This ranged from tweaks to the purchasing system to an all-new global training environment. We quickly realized even our ability to analyze the demand would be swamped by the incoming flood of work.

So, we devised a scoring system. Why? There were three main reasons, all of which really comprise some fundamental principles when creating a scoring model.

First was the need to analyze and separate the wheat from the chaff quickly. Our primary driver was to be able to make an initial cut from 120+ requests to something more manageable for more in-depth analysis. So we needed a way to make quick judgment calls to find the top 20-30 project requests with the most merit.

We further realized that any analysis that came up with a specific number (like $300K for changing the purchasing program), even with a caveat of +/- 100%, would become sticky. That is to say, if the $300K estimate was later revised to $400K – well within the +/- 100-% – the executives would still want to hold us to the $300K! “I thought you said $300K 2 months ago – what changed!” was a familiar refrain. Scoring models, on the other hand, place estimates in ranges. So as long as you don’t exceed the top range it’s all good.

Many project-driven organizations today face this same dilemma on an ongoing basis. Scoring models meet this challenge well. So, to create a scoring model that will quickly find the projects with the most merit without being nailed down to estimates too early, keep these key principles in mind:

  1. Group your scoring criteria into around three buckets – these will be used as axis on a bubble chart later. My favorites are benefits, cost/size, and risk. Others include impact, and for product development groups may include market share, technical feasibility, and margin.
  2.  Scoring criteria should comprise ranges.  An example would be a 1-5 rating of potential revenue increase, with 0 = none, 1 = less than $1 million, 2= 1-5 million, 3 = 5-10 million, etc. Same goes for project cost or other financial metric. For criteria like risk, an example would be a rating on project familiarity with 1 = very familiar with this type of project and 5 = never done this kind of work before. Make sure all the criteria produce the same range of scores (e.g. 0 – 5) so you can create weighted averages for each group and a weighted average total project score.
  3.  Scoring criteria should fit the company’s strategic direction and business needs. A retailer will be concerned about increasing market share, while a SaaS company like Daptiv is concerned with customer satisfaction.
  4.  Bubble charts are a great tool for graphically envisioning which projects will produce the most bang for the buck. While the simplicity of a single chart is more efficient, I have seen new product development organizations with up to 6 criteria groupings used on 2-3 bubble charts.
  5.  Back test the model. Take the scoring model produced and score the current slate of active projects. When I did this with a major retailer a couple of years ago, we knew we had it right when the only current projects that wouldn’t have made the cut turned out to be problem children that should never have been launched.
  6.  Always analyze requests in cycles. Applying a scoring model to each request as it comes in negates the comparative process. It also leads to new priorities interrupting live projects, which results in project and resource churn. We typically recommend quarterly cycles. Monthly can work in an environment with larger quantities of shorter lifespan projects. Generally annual cycles are too long as too much work comes up in the interim. However, an annual planning process for the larger, more strategic work can be coupled with a quarterly cycle for the smaller work.
  7.  Scoring models work best when there is a cross-functional team empowered with the ability to make decisions. This means they will be high enough level in the company to not be second-guessed by colleagues or superiors.

Once requests are reviewed and sorted using a scoring model, decisions can be made about which should proceed for further analysis. Those that pass muster then pass into the more traditional initiation process for projects, ensuring that valuable analysis time is not wasted while allowing the focus necessary to properly present the best projects for funding.

 

Filed Under: The Business-Driven PMO Tagged With: , , , , ,

Has PMO become a bad acronym?

July 9, 2012 By Leave a Comment

What’s in a name? As far as PMOs are concerned, it matters quite a bit.  Standard parlance maintains that PMO stands for Project Management Office. Back in the days when the PMO literally ran a single project or program, the name was fine. But over time the PMO has evolved. Its scope of work has increased manifolds- first, it performs its core responsibility- to run all projects, next it sets up a methodology, and finally serves as a center for strategic portfolio planning.  The charter of the PMO has now evolved to a point where the acronym bears little relevance to its traditional meaning.

To begin with, there is this notion that the new strategic PMO can be run by a good project or program manager. Indeed, most PMO Directors that I’ve met come from the project management ranks. While many perform admirably, their first inclination is to enforce methodology discipline – the death knell of many a PMO. Without a solid business background PMs are often ill prepared to handle the strategic trade-offs of the portfolio selection and planning process. Portfolio management is in essence a business process requiring strategy and operations expertise. In fact, analyzing competing business priorities does not require PM skills at all. It requires keen facilitation skills to handle the contentious debates that crop up between VPs arguing for their pet projects. Furthermore, a solid understanding of what makes a company tick while holding business stakeholders accountable for business cases.

Consequently, this leads to another area where PMO struggle and that is Benefits Realization. If we’re going to posit a business case during portfolio planning, shouldn’t we harvest the results as feedback? Shouldn’t we hold the business sponsors accountable for the benefits they claimed would be returned? Yet this is, again, a business function that occurs post project, and is often not dealt with by the “Project Management Office”. Project Managers like to “close” projects and assume they’re done once they hit “go-live”. But, benefits take months and even years to be realized and gathered and so fall outside this traditional project management thinking.

Finally, even if a solid PMO Director is in place, the “project” moniker still invokes too narrow a scope in the minds of business stakeholders. Without their full buy-in to the strategic nature of the PMO charter it is very hard to succeed.

So, the question here is – how to fix this problem? Is it really just about changing the name? Well, in my opinion that’s a start but what would really help is a change the way organizations perceive the charter of the PMO and its implementation process. The evolved PMO is really a strategic planning function focused on implementing change (the project management part) in the organization. It should facilitate portfolio planning, monitoring, and results to ensure strategic alignment and analyzing benefits returned for th investment. Project Management, Resource Management and the like are tools in service of the broader business goals. Several new acronyms have been proposed, including Portfolio Management Office (keeping the PMO moniker), sPMO (Strategic PMO), Project and Portfolio Management Office (PPMO) and the more light-hearted 3PO (Project, Program, and Portfolio Office).

The PMO has already grown well past the Project Management Office charter – isn’t it about time the name did as well?

Filed Under: The Business-Driven PMO Tagged With: , , ,

Portfolio Management: Why Theory is Rarely Put Into Practice

February 21, 2012 By 1 Comment

Back in November, I gave a presentation to an audience of PMO practitioners at PMO Symposium on the reality of putting theory into practice—the feedback was fascinating. While I knew how rare full life-cycle portfolio management is, the audience feedback confirmed that fact and the reasons.

In brief, portfolio management can be broken down into three parts: 1) Portfolio Planning, the process by which projects are selected and placed on the active portfolio, 2) Portfolio Monitoring, the practice of reviewing the active set of projects to ensure balance and performance, and 3) Portfolio Results (aka Benefits Realization),  the practice of measuring the return on the investments the projects represent.

I asked the 100+ PMO directors, managers, and other practitioners in the room to raise hands for each practice they have actively in place. As expected, almost all hands went up for monitoring, a little more than half went up for the planning processes, but only two hands were raised for Portfolio Results. That’s two percent in an admittedly non-representative sample. Non-representative in the sense that the attendees at the Symposium are the more mature PMOs!

So what’s going on here? A look at each piece brings the problems into focus.

Portfolio Monitoring at its most basic is simple to implement and provides a lot of bang for the buck. Simply listing all active projects and tracking their health gives executives a much better view of where the money and resources are being spent, allows them to re-allocate if needed, helps them provide visibility to their business colleagues, and allows them to manage performance by exception. Most of this work can be performed by the PMO and project managers, with the results distributed to all stakeholders.

Portfolio Planning requires a bit more effort and requires stakeholders to actually get involved. Many companies have serial, or ad hoc, demand management processes. This path of least resistance requires specific steps be followed,—such  as a business case, formal review, and funding approval—be followed. However, by not comparing all requests, serial demand management suffers from prioritization issues and project churn, often since higher priority projects interrupt already approved lower priority projects. By show of hands, this was the most popular, though definitely not the majority, method in use by these PMOs.

Cyclical demand-management reviews on a regular cycle – often monthly or quarterly –forces project stakeholders to compete for resources to support them where a cross-functional steering committee often makes the final decisions. The result is a high-priority portfolio where investments are strategically aligned with corporate objectives. The roadblocks center on getting those cross-functional reps engaged – and getting reps that can actually make decisions!

Of all the components of portfolio management, one would think results would be the most important. And most everyone in the room felt the same. So why is it so rarely practiced? In a word: accountability. To work, business sponsors need to not only to present a business case, but propose metrics that actually get measured post go-live. These measurements might be taken in increments for months or even years in order to fully understand the impact of a given project. Turns out business sponsors know they need certain work (aka projects) performed, but don’t want to take the time for full ownership of the results.  

How did the few that successfully implemented benefits realization manage to overcome this organizational resistance? Typically, it was a CEO mandate. Proving once again there’s nothing like good executive sponsorship to drive success.

Filed Under: The Business-Driven PMO Tagged With: , ,
« Older Posts