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.
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.
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.
Project Leaders as Ethical Role Models
Human Aspects of PM,
New to Project Management,
Nontraditional Project Management,
PM Think About It,
Reflections on the PM Life,
Categories: Best Practices, Career Help, Communication, Communication, Complexity, Ethics, Facilitation, Generational PM, Human Aspects of PM, Leadership, Leadership, New to Project Management, Nontraditional Project Management, PM Think About It, PMI, PMOs, Portfolio Management, Program Management, Project Delivery, Project Failure, Project Planning, Project Requirements, Reflections on the PM Life, Roundtable, Social Responsibility, Stakeholder, Strategy, Talent Management, Teams, Tools
By Peter Tarhanidis
This month’s theme at projectmanagement.com is ethics. Project leaders are in a great position to be role models of ethical behavior. They can apply a system of values to drive the whole team’s ethical behavior.
First: What is ethics, exactly? It’s a branch of knowledge exploring the tension between the values one holds and how one acts in terms of right or wrong. This tension creates a complex system of moral principles that a particular group follows, which defines its culture. The complexity stems from how much value each person places on his or her principles, which can lead to conflict with other individuals.
Professional ethics can come from three sources:
In project management, project leaders have a great opportunity to be seen as setting ethical leadership in an organization. Those project leaders who can align an organization’s values and integrate PMI’s ethics into each project will increase the team’s ethical behavior.
PMI defines ethics as the moral principles that govern a person’s or group’s behavior. The values include honesty, responsibility, respect and fairness.
For example, a project leader who uses the PMI® Code of Ethics to increase a team’s ethical behavior might:
Please share any other ideas for elevating the ethical standards of project leaders and teams, and/or your own experiences!
By Kevin Korterud
I’m frequently asked how program managers can synchronize projects using waterfall approaches with those using agile or other approaches. As programs are launched to address larger and more complex business problems, harmonizing a program’s projects becomes an essential component of success.
In my last post, I shared two tips for achieving harmony: remember that there’s no such thing as agile or waterfall programs, and make the correct delivery approach choice before a project begins.
Here are two more tips.
3. Establish a Program PMO and an Agile COE
One of the critical success factors for any large program is the program management office (PMO). The program-level PMO enables the program manager to spend time on higher-value activities while the PMO creates the operational governance, reporting and overall management foundations required to run a program.
As agile and other delivery approaches mature, there is a great need for a COE (Center of Excellence) model that fosters efficient and effective delivery approaches for projects on programs. Just as PMI has created a consistent approach to project management, agile and other delivery approaches are at a point in their maturity cycle where consistency is needed for them as well.
An agile COE can facilitate this consistency while serving as a clearinghouse for improved agile practices. This COE can also address different variants in waterfall, supplier and governmental delivery approaches, thus resulting in an overall harmonized approach for program and project delivery.
4. Speak the Same Metrics Reporting Language
George Bernard Shaw once said, “England and America are two countries separated by a common language.” Being a program manager with projects utilizing multiple delivery approaches can feel like living in one country separated by multiple languages!
On a program, it is essential that no matter their delivery approach, projects need to be able to both accurately describe their progress and do it in a way consistent with other projects. When dealing with projects with multiple delivery approaches, a suitable translation needs to be in place for progress metrics. This is particularly necessary for stakeholders such as finance, human resources or other business functions where an easily understood definition of progress is critical.
For example, agile projects do a great job in counting projected versus actual requirements and their weighted points. Using the total and completed requirements, a percentage completion can be calculated that is consistent with a waterfall delivery approach. Other agile-specific metrics such as effort per story point can be used to supplement the core progress metrics.
In addition, even between waterfall delivery approaches there needs to be defined a consistent approach for earned value structures, tracking actual cost and other progress essentials. (Note that aside from progress metrics, the concepts of risks, issues, dependencies, milestones, cost forecasts and governance escalations all remain the same no matter the project delivery approach.)
Program managers are orchestrators of both project delivery and the attainment of business results. They need to be always thinking about eventual business outcomes, no matter which delivery approaches are in play. Remember: no one chooses an airline or car model because the company used agile or waterfall on their projects—it’s all about the experience.
What methods have you seen employed in programs to handle multiple delivery approaches?