The Business Driven PMO

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.

GUEST POST by Ian Knox

Gartner recently updated its 2012 global IT spend forecast. There are a number of concerns which caused them to revise their forecast downward from 4.6% to 3.7% for 2012. These included:

(1) Global Economy: Private-sector deleveraging and public-sector austerity in mature economies and lack of political leadership on fundamental sovereign debt issues

(2) Eurozone Crisis: Uncertainty in resolution of Euro debt crisis, which creates business uncertainty for business investment and consumer spending

(3) Thailand Floods: Hard disk drive supply contraints affecting consumer and enterprise server and storage markets.

Gartner also updated its enterprise software spending forecast (see slide above) and predicts a 5 year CAGR of just over 7%. The three areas Gartner sees strong growth above the average include: (1) Project and Portfolio Management, (2) Web conferencing and team collaboration, and (3) Enterprise Content Management.

We don’t think this should come as a surprise. In our recent post on 2012 predictions for PPM, we noted PMOs will evolve from being tactical, support-based organizations to become a strategic player within the enterprise. Given the tough investment and cost optimization decisions being made in the current economy, PPM is a critical business capability for success.

In addition, there is a growing trend for successful PMOs in IT to expand to an EPMO, covering business investments as well as IT strategy and planning. A Daptiv customer who has successfully made this transition is Mercy, a health care system with over 25 hospitals and 200 clinic locations, which incubated their PMO in the IT organization before creating a very successful Enterprise Project Office.

Even though the economic outlook is uncertain for the next year, we’re confident Daptiv can help our existing and prospective customers navigate the difficult choices ahead and emerge stronger as the economy improves.

GUEST POST by Claire Schwartz

In my last post, I wrote about collecting data to provide information for decision-making. There is no question that data is where we begin, but facts are not enough. What we really need is information—a meaningful interpretation and presentation of the data that gives us insight into a condition or situation.

For example, when I manage a project, I collect data about task performance, such as "Task A" started on January 5 and finished on January 12, it took 27 hours of effort and we spent $3000 on travel. Interesting facts, but they really don't tell me enough to evaluate the task's performance, its impact on the project, or help me make decisions about the remaining work or cost.

It turns out that "Task A" was scheduled to complete on January 14, making it ahead of schedule. Unfortunately, it isn't on the critical path, so there's no impact to the project schedule. We had planned to use 25 hours to complete the work, but even though we were two hours over our plan for the task, we've been running significantly below our labor estimates on the work performed to date, and we're already about halfway to completion. Now for the bad news: the total travel budget for the project is $5000 and we still have two more trips planned. What was supposed to be a one-day trip, costing $1000 for three team members, turned into a three-day trip, costing $3000 because the team got stranded in a Chicago blizzard.

So what makes the second paragraph more useful than the first? In general, the second paragraph tells a complete story that informs, highlights what’s important and clearly identifies the actions or decisions needed. If we further dissect that paragraph, we can see a few specific attributes that make it more meaningful and useful: content, context, contrast and consequence.

Content: In the first paragraph, we know the facts, but the second paragraph takes the time to combine the facts into a story. By adding a little more detail, or content, the reader has a better grasp of “the five W’s”: who, what, where, when and why. Our desire to be brief and direct often results in repeated question-answer cycles, leaving the decision-maker to ferret out the relevant and important information before taking an appropriate action, delaying the process.

Context: While the first paragraph describes the amount of money that was spent on travel, it does nothing to explain the circumstances or context behind the expenditure. By providing the information about the blizzard, the decision-maker better understands why the expenditure was high and in a better position to make an informed decision regarding future travel expenditures.

Contrast: In the first paragraph, we know what date the task finished, but in the second paragraph, we know that it finished late. By including data from the project plan, the second paragraph is able to compare what was supposed to happen with what actually happened. This provides the decision-maker with a much better sense of the problem and apply an appropriate decision.

Consequence: In addition to understanding that a variance exists, we also need to be clear about the impact or consequence of the difference. Sure, the first task took a couple more hours than we had originally planned, but in the overall scheme of things, it really doesn’t require action. The budget variance on the other hand is significant since it pretty much blows our travel budget out of the water.

Turning data into meaningful information to drive a decision isn’t rocket science, but it does require some thought. Next time you put together a report, ask yourself: does this tell the full story? If not, it’s probably just data.

In my next post, I’ll write about presentation in the context of decision-making, including some thoughts on dashboards.

I noticed a recent blog on the PMI site from Saira Karim, called ‘Use Project Management Tools in the Right Context’. Saira started her post with the following:

“Recently I came across an ad for a project management technology application. It was a picture of seven robots in a group, which symbolized humans. The slogan read, “If your team looked like this, any PPM solution would work.”

Interestingly, that’s a Daptiv ad she noticed in the PMI magazine. Saira continues:

“It made me wonder how many organizations actually believe that technology applications do the work and produce results — not humans.

How many organizations and project managers sufficiently analyze their project needs and the compatibility of new technology to their organizations’ existing set-up and processes?

Companies often buy expensive project management applications and then force teams to conform and adapt to the application rather than customize the application to the needs of the people and project.

But buying applications because other organizations use them does not by default mean you, too, will become a leader.

Like with best practices, experience has taught me that technology and tools are valuable — but only if they fill gaps and needs effectively.

Technology is important and can increase efficiency, but in the correct setting and context. Projects are planned and executed by people — therefore technology must complement and be understood by the humans who use it.

Before investing in new project management applications, you must consider things like training, costs and your team members’ willingness to use the tools. Otherwise it could amount to an expensive burden.”

Saira’s post is a great articulation of the importance of the need for tools that adapt to your organization’s business needs. Combining a flexible tool with a PPM roadmap that is improves maturity in successive steps is the key to PPM success.

Have you had experience with tool implementations that have failed (or succeeded)? What are your keys to success?