The Business Driven PMO

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 know 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.

We recently bloggedabout key takeaways from the Gartner Symposium / ITExpo, noting a few things that CIOs are likely to be concerned about in 2012: (1) CIOs want flexibility to fall back to a Plan B, if Plan A doesn’t work out, (2) IT budgets will likely be flat, and (3) IT will focus on creating measurable, financial benefits for the enterprise.

In this “New Normal” environment of business uncertainty, there are some critical steps CIOs should consider to ensure they manage IT through the volatility and maintain healthy relationships with the business.

Here’s the checklist that every senior IT leader should consider for 2012:

1.) Create Visibility and Plan Accordingly.

Too many IT organizations are unclear about their priorities and the actual work they do from week to week, including software projects, infrastructure upgrades, enhancements, and “keeping the lights on” work. At a minimum, a CIO should have a well-defined list of projects updated monthly so she can see the forest for the trees. If a CEO needs to scale back costs mid-year or increase investment due to some positive economic signals, a CIO will be able to make strategic and tactical decisions based on accurate information.

2.) Implement a Governance Process for Unplanned Demand.

With a baseline understanding of the work being undertaken in an organization, a CIO must ensure that the IT group doesn’t become overloaded with new, unplanned work, especially if resources are tight. Without a governance process, it’s all too easy for a business unit to demand an urgent new project and bring existing work to a standstill due to project overload. Instead, put a steering committee in place to convene monthly or quarterly to prioritize demand and approve new projects.

3.) Understand Scope and Capacity for Agile Demand.

Even though it might appear there is budget and resources to take on new work, there may be hidden issues if an organization doesn’t plan in advance. Most IT organizations need to plan for non-project workloads, such as production support and administrative work. In-flight projects should not be interrupted, as this causes excessive churn. In addition, there may be future commitments, such as a new major IT project for a seasonal launch in three months, which will consume resources. If an organization doesn’t account for new projects ahead of existing commitments in a smart way, this can lead to resource contention and delays. Furthermore, if there are strategic reasons to keep some capacity available to manage, say, a potential acquisition, capacity planning enables an IT organization to remain agile and maintain service delivery.

4.) Drive IT Consensus at the Corporate Level.

If a CIO is prioritizing on behalf of the business units, it’s the equivalent of having a target on her back and it’s unlikely she’ll survive long. In an era of scarce resources and tough prioritization decisions, it’s critical that these choices are made by the business and not by IT.  I once brought a list of major projects to an executive team meeting. The list was obviously overwhelming, and a VP wondered how the list would be prioritized. “That’s why I’m here” was my response, at which point each VP started lobbying for their pet project. At the end of the meeting a broad consensus was reached based on corporate – not business unit – objectives.

5.) Communicate the value of IT in business terms.

CIOs are chief information officers, not chief computing officers. IT is part of the business – not separate from it—and IT must communicate accordingly. IT must lose the habit of speaking in technology terms and learn to express benefits in business-oriented language. A great example is defining IT in terms of business services that align with business groups and capabilities so the business value can be clearly articulated. Implementing a Sales Force Automation (SFA) tool does not tell a business executive anything of value. Telling the Sales VP that you can help him manage the incoming leads and give real-time visibility into the sales pipeline – that’s gold.

This checklist is a roadmap to success. If a CIO has most of this covered, she will be well positioned to manage the IT organization through the uncertain times in 2012.

GUEST POST BY: Alan Shefveland

“If anything is certain, it is that change is certain. The world we are planning for today will not exist in this form tomorrow.” – Philip Crosby (Quality Guru)

In this three-part series, I’ll attempt to discuss the importance of portfolio planning and provide some insights on portfolio management best practices in process, metrics, and reporting. I’ll attempt to provide an understanding of why we do portfolio planning, introduce a framework to plan the portfolio and discuss some techniques and guidelines to plan a portfolio.

I have had a number organizations tell me “just give me the process and I’ll execute it,” but portfolio planning is more of an art than a process. Tools like spreadsheets, metrics, scorecards, and investment maps can provide insight based on past experience, but you still need to make the decisions.

Today an enterprise has (or should have) a well-defined strategy that outlines its performance objectives and how it plans to reach them. In order to deliver on those objectives the enterprise organizes into multiple business units or organizations with their own unique operational objectives that contribute to the enterprise. Classically these organizations are focused around the operation of a specific asset type of the organizational value chain.

Portfolio planning is unique to the asset type, the distribution of assets, and to the performance objectives of the portfolio - not all portfolios are the same. For example:

• Enterprise portfolio versus organizational portfolio
• New product development versus IT
• Initiative versus program versus project
• Management of assets versus management of delivery

All of these are important portfolios for an organization; however, for the purpose of this discussion I will focus on an organizational portfolio of projects to manage delivery.

There have been a number of books, whitepapers, vendors and consultants that have provided us the benefits of having a portfolio, but for project portfolio management it boils down to three major points:

1. Capital constraints – we’d all like to have a blank check, but we know that’s not practical; 
2. Resource constraints – not enough or overworked staff;
3. Or both.

One of the best references for portfolio management has been the Coopers and Edgett book on portfolio management. Besides the outstanding examples on metrics and other tools for portfolios, the authors were successful in conducting a syndicated study on portfolios and metrics. The study covered 205 companies in North America; mean size of company was $6.4 billion in annual sales.

The conclusion they came to was that companies exceed business performance when the portfolio processes possessed these characteristics:

• Projects are aligned with business objectivesPortfolio contains very high value projects
• Spending reflects the business strategy
• Projects are completed on time
• No “gridlock”
• Portfolio has a good balance of projects
• Portfolio has the right number of projects

So that’s when it works smoothly. What happens when things go off track?  In my next post, I’ll discuss the pitfalls of portfolio planning and address how to keep portfolios on track when dealing with non-structured portfolio activity

This question gets asked so many times, and the interesting thing is many of the questioners assume the answer is obvious – though they may come down on different sides of the equation!

In a sense, the question comes from the name Project Management Office, which is a bit of a misnomer given the charter of modern strategic PMOs. Originally, a PMO was a temporary structure that ran the administrative and governance functions of large projects or programs. It lived and died with the life of that project. With that charter, the obvious choice to head the office would be a talented program or project manager.

But the charter has changed. First, the PMO became a permanent structure charged with oversight of all the important projects in an organization. This meant creating a standard methodology, monitoring status, and ensuring projects were executing according to plan while delivering value. This initial type of PMO was still squarely in the realm of the project management discipline.

As those projects were listed and reported to management they became portfolios of projects. Naturally, questions were raised about how projects came to be in the portfolio. Was the list the right list? Was it aligned with strategic objectives? If there were more project ideas than funding or resources, how should we decide which to fund and which to decline or defer? Someone had the bright idea to look at projects like financial investments (which they are, of course) and project portfolio management was born. And investment decisions are definitely in the realm of business planning, not project management.

Then while attempting to ascertain the resource capacity to take on the proposed projects, it became obvious that said capacity was constrained by non-project workloads. So allocating and tracking work across resource pools became a must – and became the purview of the Project Management Office. While program and project management looks at allocating staff across a project or program, this was much broader. Clearly, this is a business resource management challenge.

So now, instead of being a Project Management Office, the PMO has become a blend of Strategic Planning, Portfolio Management, Program/Project Management and Resource/Workload Management.

With today’s modern PMO charter, having project management skills – even if you’re really good, isn’t enough. While Project Management is still one of the charges of the PMO, it’s only a portion – and not the main driver. Strategic PMOs are really facilitators mediating the tough negotiations and decisions about how work is allocated and investments made across a diverse portfolio. If you’ve ever chaired a steering committee meeting full of VPs arguing for their projects, you get the point. If you’ve had those tough conversations with business counterparts about how many resources are allocated to KLO (Keep the Lights On) work, you understand. If you’ve ever tried to answer the “what has your PMO done for me lately” question, you really get it. Thus, the emphasis is on business management, strategic planning, and facilitation skills.

So, do good project managers make good PMO Directors? It depends on the PM. If they are good at understanding business strategies, if they are good at understanding what makes their company’s business model tick, then probably. Of course, we think good PMs are not just task, issue, and risk managers. We think the best project managers are true leaders that know how to lead projects to achieve positive business outcomes. And since they also understand and embrace project management, those project/business leaders can often make strong PMO Directors.

GUEST POST by Ian Knox

We see many software teams that describe themselves as agile, but still develop project plans, assign resources to tasks and track time on their project. Agile purists would argue these teams are not truly agile because they are breaking some agile principles, such as encouraging empowered and self-organizing teams, and enabling a responsive, efficient development process. Are these teams agile, traditional iterative, or some hybrid of the two?

The reality is many enterprise software organizations are comfortable with traditional project management techniques, but want to move towards an agile development approach. They are typically engaged in project-driven work versus a software product with an unending feature backlog. They also have to contend with shared resources, such as database administrators, network specialists and architects that may not be assigned to their projects full time.

Many of these organizations are moving from traditional iterative development to a hybrid methodology that incorporates some of the best ideas from agile, but fits with their culture and needs. For instance, they will take to heart the principles in the agile manifestoand introduce practices such as daily stand-up meetings, writing story-based requirements, targeting shorter development cycles and assigning a product owner. In addition, they will modify their traditional milestone-driven development to incorporate more planning and feedback loops to react to inevitable changes in project requirements.

These hybrid agile teams may also model user stories as tasks in a project plan (although they will measure progress in story points vs. task hours). They will work with resource managers to assign shared resources (such as DBAs) to tasks on their project. And they will report back on progress to executives using standard project management metrics such as percent complete, scheduled finish date and project health.

There are lots of benefits to a hybrid agile methodology and many enterprise software development teams are adopting this approach. Adding agile practices over time is highly recommended so teams can absorb the changes while still delivering on their commitments. For these teams, we also think it’s the best way to get to some of the end goals of the agile movement: a focus on customer satisfaction, frequent software delivery, close co-operation between business people and developers, and creating an empowered culture with motivated individuals.