Voices on Project Management

By Jen Skrabak, PMP, PfMP, MBA

Governance is an extremely broad and often times misunderstood area. It can span functions, domains and types, depending on the context of an organization and other factors. Even across the various standards and current body of knowledge and research, there’s no consistent definition of governance or approach to its implementation.

Yet as portfolio managers, we all recognize that governance is perhaps the single most important enabler of good portfolio, program and project management. It helps to guide the appropriate oversight and decision-making that ensures successful execution of strategic initiatives.

That’s why I’m so proud of PMI’s recently released Governance of Portfolios, Programs, and Projects: A Practice Guide. I was fortunate to chair a committee of leading experts around the world that developed the guide, which fills a critical gap in the profession today.

An important accomplishment of the committee was to formulate a definition of governance that can be applied to the portfolio, program and project context. Governance may exist at various levels of the organization. It’s important to distinguish among those levels:

Organizational (or corporate) governance. This is typically a board of directors’ level and defines principles, policies and procedures around how the organization as a whole is controlled and directed. It typically includes areas of oversight such as regulatory, compliance, cultural, ethical, environmental, social responsibility and community.

Portfolio (or program, or project) management governance. This typically may be how an enterprise portfolio (or program, or project) management office (EPMO) determines common policies and procedures. This may define the hierarchy and relationships of governing bodies—for example, whether programs and projects report to a portfolio governing body and the specific criteria.

In some organizations, the EPMO may define guidelines for a phase gate approach to programs and projects. It also may define methodology for technology projects, such as adhering to standard processes (ITIL, RUP, Scrum, agile, SDLC, etc.).

Portfolio (or program, or project) governance. This is the oversight and leadership on an individual portfolio. In many organizations, there may be a capital investment committee made up of the senior executives of the business and technology areas that oversee all capital expenditures over a certain amount (typically US$1 million or more).

On an individual program or project level, it’s important to define the relationships of the various governing bodies and ensure that it’s aligned to a functional or portfolio level. A project may be required to report to functional governing bodies (IT and/or the business area), as well as the portfolio manager. It’s important to ensure that the thresholds and authority of decision-making are defined at the right levels.

In my next blog post, I’ll define terms related to using portfolio governance to ensure alignment to strategy.

By Conrado Morlan

Over the years, I’ve had many discussions about whether project managers should pursue the Project Management Professional (PMP)^® credential. Some people argue that extensive experience is much better than the knowledge they can acquire through the PMP credential.

I appreciate the value of my counterparts’ experience and respect their opinions. Before I earned my PMP certification, I shared their views. But while studying the PMBOK^® Guide—my employer required all project managers to be certified within six months of hiring—I found that my experiential knowledge was enhanced by the new tools and techniques I learned about. I wished I had known about them during previous projects.

My eyes were also opened by a quote from Lewis E. Platt: “The danger of success is to think what made you successful in the past will make you successful in the future.”

The project management profession, like many others, evolves constantly. As a responsible practitioner, I need to keep my skills and knowledge current by reading the latest PMBOK^® Guide edition, as well as being familiar with evolving methodologies and standards in project management.

Here’s an example of why not keeping up with the latest publications and standards can be problematic. I often hear people talk about the “triple constraint.” But that concept is not in the latest edition of the PMBOK^®. Nowadays, project management is a strategic competency for organizations. It enables them to tie project results to business goals—and thus, better compete in their markets.

Finishing a project on time, on budget and within scope doesn’t necessarily help an organization meet its business goals. Today, organizations need to respond quickly to internal and external influences, which may lead to sudden changes in scope, budget, and schedule.

The need for competent project managers will persist—PMI projects  that between 2010-2020, 15.7 million new project management jobs will be created in just seven project-intensive industries.

Organizations no longer look for project managers with technical skills only. They’re looking for people whose technical skills are complemented by business, strategic management, and leadership skills.

The project management profession is changing, and pursuing a certification makes it more likely that you’ll stay up to date with the times.

What’s your view on the value (or lack thereof) of the PMP certification? Share your thoughts below.

By Mario Trentim

I recently delivered a webinar at ProjectManagement.com on how to effectively define a project management office’s business model, functions and structure (watch the recording here).

In that presentation, I wanted to start a discussion on different modern approaches to defining and implementing PMOs. Today, I’m going to share some thoughts and examples on how to do that in practice.

A step-by-step process to define and implement a PMO helps to build buy-in. The following five phases lay out a learning process in which stakeholders are identified and engaged to discuss and develop a PMO model that best suits their organizational needs.

Phase 1: Assessment

Understand the organizational context and assess current project management practices and maturity levels. The as-is situation involves processes mapping and the use of maturity models, such as OPM3^®.

Phase 2: Definition

Once the current situation (as is) is described in detail, explore the future desired situation (to be). The Business Model Generation helps in defining the ideal solution for a desired PMO model. The gap analysis between current and desired situations will guide the implementation plan.

This phase also includes defining the following aspects of the PMO:

Mandate: mission and vision

Business model: customers and value proposition

Structure and functions: processes, resources and partnerships

Phase 3: Implementation

This is not easy. It involves a lot of change management and stakeholder management. A phased approach to the implementation is recommended, especially for large endeavors.

You might want to implement a pilot PMO in a region or department before rolling it out to the entire organization. The implementation work packages will depend on the PMO definition. Deliverables might include: training, software, processes, methodology, templates and more.

Phase 4: Continuous Improvement

The PMO is an entity that must deliver business value. Its mission is not to help individual projects thrive but to boost the entire organization’s performance through best practices and governance.

As the organization changes and matures, so does the PMO. It should be a flexible and adaptable structure to accommodate new project management challenges ahead.

A continuous improvement plan may include a maturity-growing roadmap and regular assessment of PMO functions and KPIs to guarantee that it is always reinventing itself before it turns out to be obsolete.

Phase 5: Closeout

The closeout phase should include a celebration of the PMO results, emphasizing its mandate, to engage stakeholders and keep buy-in. 

The main lesson: always involve and engage stakeholders properly. Keep in mind that a PMO is an organizational structure that should create value, distribute value and capture value. The Business Model Generation helps to identify what value is for the stakeholders (customer segments/value proposition), which drives the PMO functions and structure.

It all starts with these frequently avoided questions about PMOs. Once you answer those questions, you can go to the next step: using the business model generation.

Example of a PMO Business Model

Of course, you may have other ideas for PMO business models. What are your PMO’s customers? Value proposition? Functions? Share your comments, thoughts and suggestions below.

By Taralyn Frasqueri-Molina

A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate. 

Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.

Here's a short list of tools I've used on all of my projects.  

Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.  

Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.

Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.

Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.

Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.

Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!

What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.

       By:  Rex M. Holmlin

This month’s theme at projectmanagement.com is “communication & collaboration.” I want to focus here on a crucial part of communication: confirming that we’ve understood the message someone has given us.

The PMBOK® Guide discusses what is called the “Basic Communications Model.” One aspect of this model, also known as the Shannon-Weaver Model, is the responsibility of the receiver to both decode a message and then confirm he or she has understood it.

Here’s a story to illustrate why that model matters.

A few years ago, I was in a project meeting about some stone we were going to purchase from a quarry in Egypt for flooring in an atrium. Stone is typically sourced by a stone broker. Stone brokers know the various quarries and work with everyone involved to select the correct stone from the quarry, get it turned into the proper size of tile and then get it to the project site.

As we wrapped up, I stood up and began to think about my next meeting. At this point, the stone broker came over to me. “You know,” he said, “stone is a natural material.” That’s not something anyone had ever mentioned to me before, but I acknowledged his statement. He seemed pleased, and I went to my next meeting.

A few weeks later, we received a call from Italy where the blocks of stone were being cut and turned into the flooring tiles. We learned that the tiles were crumbling into pieces when they went through the saws.

Fortunately, we had ordered the stone well before it needed to be installed, so there was time to source another block of stone, get it turned into tile and ship it to the project site. But later, as I reflected on this, I thought about the stone broker’s words. When he told me stone is a natural material, he was encoding a message that I’d failed to decode.

The message was that every piece of stone is different. This is one of the qualities that helps make stone beautiful and a key reason we want it in our homes and offices. Unlike steel or glass, stone might have veins of quartz or other imperfections that can cause the stone to crumble when cut.

Keep You Head in the Game

As I thought about it, I realized there were two things I did that contributed to an imperfect communications process. First, as I stood up, I “changed channels.” I was beginning to think about my next meeting. The lesson here is that if you’re in a meeting, be in that meeting. As a coach would say, “keep your head in the game.”

The second thing I did was fail to ask the stone broker to “Say more, please.” He likely would have told me a lot more about stone and the process of turning it into tile. The stone broker was not trying to conceal his meaning; he was being economical and selecting words that were meaningful to him.

This is something we all do. As the receiver of the message, I was the one responsible for confirming I had understood his message.

It may not always be the other party that causes a communication to fail. But it only takes a few seconds to ask someone to say more about the message they are trying to communicate. It also only takes a few seconds for us to confirm we’ve understood it. Sometimes taking the extra step to take these two actions can make a big difference in our projects.