Project portfolio management (PPM) refers to a process used by project managers and project management organizations (PMO’s) to analyze the potential return on a doing a project. By organizing and consolidating every piece of data regarding proposed and current projects, project portfolio managers provide forecasting and business analysis for companies looking to invest in new projects.
Project portfolio management gives organizations and managers the ability to see the big picture.
Taking risks is an inherent part of business. However, when taking a risk it is important to remember, the bigger the risk does not always equal the bigger reward. Risk vs. reward all boils down to smart decision making.
The project portfolio management process helps companies predict the outcome and plan for projects that will offer the best results. It highlights questions such as:
Project portfolio management helps companies break down every detail of a proposed project – budgets, resources, tasks, timelines and goals. Using in-depth analysis of proposed projects, weighed against current projects, a company can define what risks offer the most rewards.
Using key indicators that illustrate costs versus returns, organizations are able to determine whether a project should go forward. This allows for the creation of fluid and replicable workflows that ensure efficiency and optimal team performance.
By using PPM, project managers and PMOs have a global view of each project. When every element of a project is presented as whole, problems can be predicted before they ever occur.
The PPM process gives organizations the foresight to identify potential risks and put the necessary measures in place. This helps a company proactively manage risks, allowing teams to realistically estimate potential delays and put into place measures to prevent or mitigate those risks, should they prove to be unavoidable. Risk mitigation can entail:
At the most basic level, PPM and project management differ by number of projects. Project management looks to focus on an individual project’s road to completion, whereas project portfolio management takes into consideration every project or potential project and its viability to meeting overall business goals.
A smarter approach views project portfolio management as the process which lays the foundation for more efficient project management.
Here are a few ways in which project portfolio management helps support the fundamentals of project management.
Effective PPM helps project management become an easier road to travel. When used in tangent, they are invaluable to a organization.
Project portfolio management lays down a methodology used to predict potential problems, review progress towards operational goals, manage budgets and stakeholder concerns. Allowing project managers to then follow up with precision execution.
Project portfolio management gives companies a “bird’s eye” view of upcoming, current and past projects. By seeing the big picture of how a proposed project will fit into the goals and objectives of the organization, companies can make better decisions on what projects to choose and what initiatives will create the most return.
Project portfolio management helps leadership plan projects and predict outcomes. To effectively plan, PMO’s use project portfolio management tools such as project portfolio management software, scenario analysis tools and good old-fashioned spreadsheets, in addition to other software tools used by project managers.
Though there are many types of project portfolio management tools, the best ones:
Outlined are a few of the benefits that come with using project portfolio management software.
Enterprise means one resource with multiple functionalities that can be used across the entire business spectrum.
Most PPM tools are created as enterprise software, decreasing the reliance on multiple applications that can increase overhead and confuse workflows. As an enterprise solution, this usually means you do not have to be an Information Technology whiz to figure how they work. These tools incorporate simple functionality like the “drag and drop” and do their best to organize information in ways that seem intuitive to most users.
Often businesses and organizations who take on multiple projects have employees and team members working remotely. When you have various team members working from multiple locations, effective communication can be difficult.
The best PPM tools are accessible online, eliminating communication barriers.
When communication is streamlined through one central hub you can:
A good PPM tool should offer robust reporting options. Report data provides executives and managers perspective that allows them to predict what projects may require excessive resources by highlighting active projects or circumstances that may act as impediments to organizational goals.
PPM reporting tools also allow companies to actively monitor every facet of the organization’s current and potential projects, including budgeting, forecasting and risk/reward analysis.
Individual project budgets may go over, but effective use of PPM tools may help a company see the potential impacts to other projects and determine whether going forward with a project that is already over budget will pose a problem in terms of multiplied financial overages in other areas. When projects fall behind, leadership has the ability to stifle the potential ripple effect using project portfolio management techniques.
Reporting makes for factual and informed project portfolio management that in turn helps set expectations within the company regarding what projects should, and should not, go forward.
Let´s take a look at the concept of process maturity, which shows until what extent a process is manageable and predictable.
There are five levels of business process maturity:
Every new level makes a company more able to meet competition, timely react to market requirements and wisely use its resources. Fully describing and specifying the processes can take the company to Level 3 at the most. It is possible to go from Level 3 and higher only if the workflow (business processes, document management and so on) is automated.
According to the Deming cycle (Plan-Do-Check-Act), the simplest model for process improvement consists of four steps:
Deming cycle in business process management
Let us sum it all up.
BPMN allows you to model an executable process. The main concept of an executable process is as follows: first, you draw the diagram, and then the process is executed according to the diagram. Processes described with BPMN and automated in BPM systems are manageable from the moment they are modeled to the moment they are executed, allowing for constant improvement.
To identify the stakeholders, ask yourself whose help you need to develop, release, and provide the product. The answer to this question will be specific to your product and company. For a commercial product, the group is likely to include representatives from marketing, sales, support, and management. But it might also comprise legal, finance, and human resources. For an in-house product, your stakeholders may be operations, the affected business units, and management.
Once you have identified the stakeholders, take the next step and analyse them to understand how you should engage with them. This focuses your efforts, generates the desired buy-in, and allows you to spend your time wisely.
A common stakeholder analysis technique is the power-interest grid, which was originally published by Colin Eden and Fran Ackermann in their book Making Strategy. As its name suggests, the grid assesses the stakeholders by taking into account their power and their interest. The grid assumes that stakeholders take a low or high interest in your product and that they have low or high power. A stakeholder is typically interested in the product if it noticeably affects the individual. Someone has a high power if the person can influence the product decisions, for instance, if or when a feature is implemented.
Taking into account low and high power and interest results in four quadrants and stakeholder groups, players, subjects, context setters, and crowd, as the following picture shows.
Each stakeholder group on the grid above requires a different level of engagement, as I explain below.
Stakeholders with high interest and high power are called players. These individuals are important partners for you as the product manager or product owner. You should therefore collaborate with them closely, for instance, by inviting them to product strategy and roadmapping workshops and sprint review meetings. Aim to secure their buy-in, leverage their ideas and knowledge, and establish a close and trustful relationship with them.
Additionally, ensure that the individuals are involved with the product on a continued basis to avoid loss of knowledge and hand-offs. It is undesirable, for instance, that the marketing group sends a new representative every time a strategy workshop or review meeting takes place. Instead, one marketer should represent the group on a continued basis.
Bear in mind that collaboration requires leadership. You should be open and collaborative but decisive at the same time. Aim to build consensus with the players but don’t shy away from difficult conversations. Don’t settle for the smallest common denominator and have the courage to make a decision if no agreement can be achieved.
Subjects are individuals with high interest but low power. They feel affected by the product and are keen to influence it but they can’t veto or change decisions. Subjects can make great allies who can help you secure understanding and buy-in for your product. Keep them engaged and involve them on a regular basis, for instance, by inviting them to sprint review meetings and encouraging them to share their feedback.
But don’t make the mistake to say yes to every idea and request subjects raise. Use the product strategy and roadmap to assess if an idea is helpful or not. If in doubt, consider running a brief and cheap experiment to find out if adding a feature would be beneficial, for example.
People with low interest but high power are called context setters or referees. They affect the product’s context but they take little interest in the product itself. An example is the person in charge of the development group: If the individual does not help staff the development team properly, then the success of the product may be at risk.
Make sure that the context setters feel that their opinions, concerns, and ideas are heard and understood. Regularly consult them, for instance, by having one-on-one meetings. This ensures that their ideas and concerns are heard and it helps avoid nasty surprises. Don’t let the context setters intimidate you and don’t allow them to dictate decisions. Be strong and have the courage to say no even if faced with a powerful and pushy stakeholder.
The crowd are stakeholders with low interest and low power. As they are not very interested in your product and don’t have the power to influence product decisions, it’s usually sufficient to keep the individuals informed, for instance, by giving them access to the product’s wiki web or by sending out a status report to update them on important developments.
The following table summarises my recommendations on how to engage with the four different stakeholder groups.
Recently, I was engaged in a lively conversation about enterprise agile transformations and the topic turned to Project Management Offices (PMOs) and, specifically, Project Managers (PMs). The gentleman I was speaking with said that in ideal agile, there is “no need for Project Managers”. His argument was that they are replaced by Product Owners, Delivery Teams, ScrumMasters, and/or Functional Managers.
At first glance, there may appear to be merit to his statements. Let’s look at some of the evidence:
So was the gentleman correct? I contend that he was not, especially as you start to scale agile in larger organizations. In fact, in my experience, buy-in and alignment of the PMO and Project Managers could make or break your transformation.
I will not deny that the traditional role and responsibilities of a Project Manager changes and may be distributed in agile, however, the skills and experience PMs bring to the table are extremely valuable.
Effective Project Managers have good organization and communication skills. They are well versed in risk and dependency management. They understand ways to manage time, cost, and scope. They know the organization and how to remove impediments.
So what becomes of Project management in an enterprise agile world? There are many roles a traditional Project Manager can play. One such role is as a Portfolio Manager on a Portfolio Team.
The Portfolio Team is responsible for setting the vision and strategy, deciding on initiatives in which to invest, and ensuring value is aligned with business strategies. The Portfolio Manager helps make sure that the team has everything it needs to function effectively. This goes beyond just scheduling recurring meetings. The Portfolio Manager can act as a servant leader, removing impediments, measuring progress, and enabling the team to make decisions on the portfolio.
The Portfolio Manager is the facilitator for the team. They help keep the team accountable to adhering to processes and working agreements, as well as ensuring the team operates efficiently.
Another role could be that of a Program Manager on a Product Owner team. As an organization scales, it becomes difficult to manage dependencies and risks. It becomes overwhelming for a Product Owner to provide clarity of the backlog to their delivery teams.
By forming a team around a Product Owner, many individuals can lend support and capacity to the Product Owner, providing delivery teams that backlog clarity. A vital part of that team is the Program Manager. They help to clear impediments, manage dependencies and risks, hold the team accountable to providing all the things necessary to ensure the delivery teams are never starved of requirements. They can also serve as an escalation point for blocks and issues that cannot be resolved within the delivery teams.
Other areas and roles a traditional Project Manager could serve or grow into include Release Manager, ScrumMaster, Community or Practice Lead, Product Owner, or Internal Coach. I tell Project Managers to really think about their long term career goals and be proactive in pursuing those areas of interest.
The biggest lesson I try to impart is how to be a servant leader. Changing your mindset from directing to serving can be difficult. But, in an Agile world, servant leadership is what is needed to be truly successful. Enabling others to be successful, will make the organization and the individual successful. When the teams win, everyone wins.
I encourage Project Managers to seek opportunities where they can help the organization and the transformation. With a Project Management background and a servant leader mindset, PMs can grow into incredibly effective agents of change.
Quite often, when process work enters the analysis phase, there is either a fair bit of confusion or (perhaps more typical) a lot of running forward with no direction. At this point in a project, the effort of gathering process information is finished and people are eager to move on to the next phase of fixing/improving the process or redesigning it. However, they know they "should" do some analysis first. Sadly, the very approach that created problems in the process may be used at this point to analyze the problems, e.g., fire-fighting, checking the box, or "the way we've always done it" (whatever that is). This is really unfortunate. The highest Return On Investment (ROI) from a process improvement effort will be generated by excellent analysis. Really good analysis of a process will uncover the real problems instead of the symptoms, the perceived problems, or the personal pain points. Improving/changing a process based on the symptoms or pain points results in sub-optimization and frequently produces negative, unintended consequences.
For example, I recently sat in on a presentation by a group whose project objective was to solve the problem of not knowing who, how, or where to contact the staff in the event of an emergency situation (such as a hurricane in the Gulf). They put together a very good presentation on their solution, which included compiling all the necessary information so that it would be readily available in the future. That's a great idea, right? Not really. They missed the fundamental problem. The real problem was that the assessment process that was supposed to ensure that there was a process in place when an "event" occurred to contact people was completely inadequate. Otherwise, the problem would never have been a problem. With their solution, they now have a contract list, but the next time an "event" occurs, if the people are different or their numbers have changed or the person responsible for actually doing the contacting is different or... they will still have the same problem. Had they done a proper job of analysis, they would have realized where the real problem was. And by fixing that core problem they would have helped not only their own area of the business but several others as well since this safety assessment is an integral part of almost everything in their business.
Understanding the various analysis techniques won't necessarily fix this kind of problem, but it does provide a well-stocked tool kit to pull from when planning the analysis of current business processes. This in turn results in higher quality, with more accurate and valuable results.
There are a multitude of analysis techniques that can be applied to business processes in an effort to determine what problems need to be addressed. This article provides a brief overview of the most common and useful techniques. Many of the techniques are referred to by different names in the various disciplines of process analysis. The most common/generic names will be used although it should be noted that many of these techniques are also used in Continuous Improvement, Lean, and Six Sigma efforts but have acquired different names even though the techniques remain the same. This can cause confusion for people who are new to process and process analysis efforts and it can create the impression that the Lean and Six Sigma concepts are new ideas. In fact, the techniques in both disciples have been in existence and have been used by analysts for many years prior to the Lean and Six Sigma 'branding'. A mapping of the original or most common name to the Lean or Six Sigma names will not be part of this article but will be included in follow-up articles that go into more detail.
Focus on the "Right" Things
Often, just deciding on what to analyze creates a frustrating dilemma. It's so easy to be distracted by the identified pain points and symptoms, making it very difficult to step back and view the information objectively. There are no "silver bullets" for this but the following concepts should help.
There are other questions, but hopefully this list will get you started and will help generate ideas for other appropriate questions to ask.
Process Analysis Techniques
There are a multitude of techniques that can be used to analyze processes. This is part of the problem — too many choices. It has been my experience over that last twenty years that there are five techniques that should be used every time. Beyond that, the answers to the questions in the previous section, as well as common sense, help determine if other techniques will be necessary or useful.
Critical (5) Analysis Techniques
The critical five techniques are:
The first three can be done in facilitated sessions.
Other Analysis Techniques
Other useful and frequently-used techniques include:
The Critical (5) Analysis Techniques
Gap Analysis — Utilizing all Process/Activity Information
Gap analysis is one of the most useful types of analysis. However, if complete information about the process isn't available to conduct this analysis then most of the value it should provide will be lost. The complete information about process includes inputs, guides, outputs, and enablers. This is not a new concept, although many people haven't seen it or haven't seen it in a long time. It is part of the oldest modeling technique. Definitions of each component follow.
Input: something that is consumed by or transformed by an activity/process. Guide: something that determines why, how, or when an activity/process occurs but is not consumed.Output: something that is produced by or results from an activity/process.Enabler: something (person, facility, system, tools, equipment, asset, or other resource) utilized to perform the activity/process.
Input: something that is consumed by or transformed by an activity/process.
Guide: something that determines why, how, or when an activity/process occurs but is not consumed.
Output: something that is produced by or results from an activity/process.
Enabler: something (person, facility, system, tools, equipment, asset, or other resource) utilized to perform the activity/process.
When analyzing gaps in the process from an input/output perspective, it is useful to consider the following items:
Guides are the source for the greatest opportunity for improvement; therefore they should be carefully analyzed for:Legitimacy Accuracy Relevancy Appropriateness Value to the Customer/Business
Guides are the source for the greatest opportunity for improvement; therefore they should be carefully analyzed for:
Value-added analysis is a detailed examination of every activity/task in a process to determine if it supports/contributes to customers'/stakeholders' requirements or needs. To add value, a process/activity must produce an output that creates value for the customer, and the completion of the activity must be required to create that output. The objective is to optimize the value-added steps and to minimize or eliminate non-value-added steps. It is worthwhile for the team to identify the non-value-added actions as early in the analysis as possible.
The decision tree shown here depicts a very basic approach for the initial evaluation of the "Outputs from Activities." Each activity should be evaluated for its true value to the process. This technique can be used as a starting point in a facilitated session with the business.
Depending upon the discipline for "process improvement" that is being followed or implemented, the titles assigned to the three categories of value-add are:
When evaluating the potential for value, activities are classified into the four phases of a typical process life cycle: Plan, Execute, Review, and Adapt. Furthermore, Plan can be broken down into planning (VA) and preparation (NVA) activities. Execute can be broken down into execution (VA), storage (NVA), movement (NVA), and handling (NVA). Review can be broken down into prevention (VA) and control (NVA). Adapt can be broken down into prevention (VA) and processing defects and waste (NVA).
The Planning part of Plan and the Execution activities in Execute normally are considered value-add activities based on these definitions:
The verbs in the table below describe activities that are normally considered value-added.
Utilizing the concept of the process life cycle to evaluate value, the verbs used in the activity naming convention are the focal point. This method examines the verbs that should be part of the verb-noun naming convention. There are many verbs that indicate a strong potential for an activity to be non-value added from both the customer and business point of view.
As a key to identifying non-value-added actions, the following is a sample list of verbs or actions that are normally considered to be non-value-added. This is a valuable method for creating the "top suspect" list. This list can be used to ask more detailed questions, if necessary, regarding who, what, where, when, how, and why (5 times).
To change something to make it fit, conform, or suitable for use.
To give consent to someone or something as being good or satisfactory.
To set something apart from something else or mark it for a specific purpose.
To alter, substitute, or replace something with something else.
To put something in its proper order.
To gather things together for some purpose.
To make an imitation of an original thing.
To carry something and leave it at the proper place or places.
To give something out, scatter, or spread it out.
To take someone or something out; remove it or get rid of it.
To speed something up or make the progress easier.
To arrange something in order for future reference or to put it in its proper place or order.
To look at something carefully or examine it critically in order to detect flaws or errors.
To put someone or something into or on something else.
To keep something in good condition, position, or repair.
To determine or estimate the dimensions of something by the use of a standard.
To check on or regulate the performance of someone or something.
To change the place or position of something by pushing, carrying, or pulling it from one place or position to another.
To make arguments, ideas, texts, or accounts of something consistent and compatible with something else.
To put something back in good condition after damage or decay.
To express a wish or desire for something in a polite or formal way.
To bring, send, carry or put something back.
To examine or inspect something formally.
To read something over carefully and to correct, improve, or update it where necessary.
To choose or pick something from among several alternatives.
To prepare something for future use.
To stop something on its journey through a process and hold it in a particular place.
To bring something up to date or make it conform to the most recent facts, methods, or ideas.
To test or check the accuracy or correctness of something through investigation, comparison with a standard, or reference to the facts.
To stop and wait for someone or something to catch up.
Root Cause Analysis
Root Cause Analysis:
This technique uses what is commonly called a "fishbone diagram," Ishikawa diagram, or "cause and effect diagram." This diagram relates all possible causes to specific effects. Finding the real root cause of an identified problem is not a science but rather a technique that repeatedly asks why things are the way they are.
In conducting root cause analysis, examine the following areas related to a process:
Root Cause Analysis-Cause and Effect
Another technique often used to determine the "real" root cause is a Cause and Effect Matrix (or Table). This technique identifies the potential cause or scenario where a problem occurs then records the most likely effects of that scenario for analysis. For example:
Observation — Observing the Process ... "In Person"
One very important (but rarely applied) analysis technique is that of "observing the process." This must be done in person. As workers and workplaces have become more decentralized and many teams work in different locations, this has become very difficult to do, but that doesn't reduce the importance and value of the technique. Nothing is as enlightening as actually seeing the work done. More often than not, when people simply talk about how they perform their work, the description is more of a "should be" than it is a true representation of how the work is actually done. Observing people at work confirms whether there is an accurate understanding of the current As-Is process.
In a perfect world, it is best to see the work under various scenarios. The list below represents various scenarios or approaches for seeing and understanding the "real" process activities.
Examining the Experience
Quite often the quickest way to reach a destination is not via the most obvious path.
All organizations have experienced and competent staff. These individuals (who typically have 15+ years of experience) are a wealth of knowledge for a process analyst. Their knowledge and experience is an integral part of why the business runs smoothly, even when the unexpected occurs. These are the individuals who know how to expedite a six-week activity and make it happen in two days. They intuitively know all of the non-value added activities and the policies, traditions, or culture that drives them. A complete and accurate analysis of process is never complete without input from this group.
The analysis phase is often the phase where the focus of the improvement effort is lost as the goals and objectives are forgotten and the assumed problems are addressed and solved without due consideration given to whether these are the real problems. Or it can be the phase that is given the least attention due the fact the initially-identified problems are the only problems to be solved and little or no actual analysis is done. Yet, the analysis phase has the potential to provide the highest ROI of all the phases. That includes the To-Be or redesign phase because if the real problems are not identified then the To-Be work may (unintentionally) actually design the same problems back into the processes.
The world has changed dramatically over the past two decades. Email, the Internet, and now social media have increased the interconnectedness of the world. Globalization has led to intense competition, forcing companies to expand product portfolios and design increasingly complex manufacturing processes and supply chains. Government regulation has become progressively more active, forcing companies to create new organizations and processes to ensure compliance. All these changes have driven substantial complexity into the environment in which companies operate, and the pace of change continues to accelerate.
Complex systems have several characteristics that make them especially susceptible to high consequence/low probability events. First, complex systems have many interdependent variables that do not necessarily act in linear or predictable ways. Second, they have feedback loops that act to amplify or dampen reactions. As these interdependent variables are amplified or dampened by feedback loops, complex systems often exhibit emerging properties causing them to behave in ways that are virtually impossible to predict.
A flock of birds is a classic example of a complex system. No one bird is in control of the flock. In fact, no single bird even knows in which direction the flock will move. Each bird follows a few simple rules (i.e. don’t run into each other, maintain a standard distance, align flight to match neighbor, etc.), and from these simple rules, a very complex pattern of behavior emerges. As companies become more and more complex, their performance becomes more like the flock of birds in that it is difficult to predict and impossible for a single person to control.
Traditional approaches to risk management are not well suited to preventing the high consequence/low probability events that arise from complexity. First, traditional approaches rest on the ability to predict potential failure modes so that actions to prevent or mitigate the risk may be put in place. The emerging properties exhibited by complex systems make this virtually impossible. Second, the feedback loops present in complex systems often cause circumstances to change so fast that there is not adequate time to identify the risk. Finally, these events happen so infrequently, and with so little notice, that there is not ample opportunity to study and learn from them.
Unfortunately, recent history is evidence of this trend. High consequence/low probability events are becoming more and more frequent. Disasters of the scale of BP’s Deepwater Horizon, Fukushima Daiichi, and the West fertilizer plant are becoming all too common. And this increase in catastrophic failures is not limited to safety and environmental incidents. We have seen similar trends in financial markets (e.g. 2008 housing collapse, current collapse of oil prices) and product quality incidents (e.g. Takata air bag recall, Blue Bell Listeriosis outbreak). The bottom line is that unless we do something differently, as the world grows increasingly complex, we will continue to find new ways to cause destruction and devastation. In fact, some leading thinkers have resigned themselves to this fact and simply accepted these catastrophes are the new normal.
In fact, a select few organizations have been able to defy this trend. These High Reliability Organizations (HROs) have been able to demonstrate extraordinary levels of performance even in highly complex operating environments. We look to these HROs to understand how they are able to achieve extraordinary levels of performance, over sustained periods of time, despite operating in highly complex, high-risk environments.
One of the most significant lessons we take from HRO’s is the importance of culture. An organization that expects people to just do what they are told, mind their own business, and not question authority, simply will not succeed in today’s complex world. It can’t because it is impossible for leaders to predict what will happen next and direct all activities. To survive and thrive in a complex environment requires a culture that encourages people to understand not just what they do but why they do it, question things that are out of the ordinary, and back each other up. Organizations that can create a culture consistent with these characteristics of HROs will not only avoid catastrophic failures, they will outperform their competition across every measure of operational performance