When enterprise architects meet up over beer and start parsing the terminology of enterprise architectural modeling, the concept of perspectives comes up, i.e. the ability to model the underpinning structure of the enterprise from a number of different perspectives – whether that be from the business, technical or actor perspectives.
A perspective is a useful tool insofar as it forces us to examine the same problem from a different angle – thus ensuring that we reduce the risk of missing something critical from our problem analysis. When I teach project management workshops, I always have teams develop WBS from both a product and a process perspective – as that forces them to identify elements they may not think of when sticking with a single perspective.
The issue with perspectives, however, is that it is quite easy to get wrapped around the axles and stuck in an endless analysis paralysis as new perspectives are introduced. At some point, we need to declare that “enough is enough” and move on with our current understanding of the problem.
So in selecting perspectives, as in all things, moderation is key. We need to choose the 1,2 or 3 perspectives that will almost always give us the 80% of the problem we need to focus on for now, and then trust the ability to modify our approach in the future to ensure that anything we may have missed in the analysis is dealt with in a timely fashion.
Thus, when we look at project portfolio management, we typically arrive at the critical point where we need to determine an appropriate perspective to use when reviewing the issue.
The Process Perspective
The default perspective is probably the simplest one. Perhaps because of PMP training, ISO standards or natural inclination, many folks start looking at portfolio optimization from the process perspective. In this perspective, the portfolio management process is broken down into discrete steps: intake, business case development, prioritization, authorization, execution, benefits realization, etc.
Each of these steps is broken into subprocesses: inputs, tools & techniques, outputs (ITTO). We then start looking at project portfolio management as an exercise in ensuring that all the ITTO are technically accounted for and flow into each other. With this perspective, we end up with a technical solution to the problem, a linear path to success.
The Capability Perspective
An alternative perspective is that of the capability. Instead of looking at project portfolio management as a process, we look at it as a strategic capability that enables the company to make intelligent decisions about the projects that it will execute. Then, we break that strategic capability down into its component parts. To support project portfolio management, we will need to be able to perform resource management, financial management, enterprise architecture and strategic planning. Each of these elements becomes its own strategic capability with its own subcapabilities.
Capability Over Process
See what we did there? We took the problem of how to do project portfolio management and we flipped it on its side. We went from treating it as a process to a capability. Both perspectives are valid – but we find the capability perspective to be more useful in framing the solution. The capability perspective is more useful for a number of reasons:
Thinking in terms of capabilities doesn’t trap us into thinking in the context of a single process or system. Instead of focusing on project portfolio management, we can focus on the financial management that underpins project portfolio management. Chances are this is the same financial management that supports project execution or operations or any of the other elements in the Request-to-Fulfillment value chain. Hence, when looking at financial management (as an example), we need to make sure that we can support all of these needs using a harmonious structure, taxonomy, nomenclature, process, etc.
The flip side of that is to develop financial governance to support each new process individually. When organizations do that, they end up with a spaghetti mess of poorly coupled systems and data silos. One financial system is used to manage projects in engineering, and a whole other system is used to manage projects in execution. Meanwhile, bids and contracts are all tracked somewhere else. Focusing on the process perspective denies the complexity inherent in the organization as a system.
The second reason to think in terms of capabilities and not process is that continuous improvement is better built on a platform of capabilities than it is on a defined process. As the organization matures and improves performance, whole capabilities can be enhanced or invested in without forcing a reengineering of the entire process. This phenomenon is particularly true in the field of project portfolio management, which arguably itself is precisely an exercise in ongoing improvement. Reengineering an entire process to support continual improvement becomes a significantly more complex endeavor.
Remember, when looking at implementing project portfolio management within an organization, you’re never focusing on solving today’s problems. You’re not even focusing on solving tomorrow’s problems. You’re focusing on giving the organization the ability to solve the problems that will arise next week that we haven’t event thought about yet. Selecting a capabilities based perspective is the first step in identifying how that will be done.