Beware of Project Dependencies


Managing Project Dependencies

Managing project dependencies are an important part of portfolio planning as well as tactically managing project execution. Unknown dependencies represent a major portfolio risk and in complex environments, inadequate identification of project dependencies can derail projects or programs. Dependencies can be any deliverable, process, standard, technology, or product that is produced by one project team (or work group) but impacts another project or program. Projects that impact other projects may be referred to as upstream projects, predecessors, or givers. Projects that are impacted by other projects may be referred to as downstream projects, successors, or receivers.

Senior leadership needs to proactively manage and monitor project dependencies within the portfolio. If left unmanaged, the negative impact of such dependencies can severely affect schedule, scope, and cost. Schedule slides will be the most common impact when project teams have a technical dependency with another project and need certain deliverables to fulfill the scope of the project, but higher project costs can be incurred when projects are delayed or reworked due to scope changes. When a downstream project is impacted by an upstream project, the dependent project may still be able to move forward with reduced scope or an expensive scope change required to accommodate a work around as a result of the dependency. I have seen expensive work-arounds implemented as temporary (i.e. “throw away”) solutions that would not have been developed had the upstream deliverables been ready on time.

Proactive management of project dependencies can significantly reduce these risks and expenses. Senior leaders should ask the right questions at gate reviews such as, “what is the real impact to this project if upstream project deliverables are not ready in time?” Will it impact the schedule by a week? By a month? Or longer?” “Are workarounds available if upstream project deliverables are not ready in time?” “If yes, what is the cost of the workaround?”

Thorough investigation and planning is needed in order to mitigate against these risks. Good portfolio planning will give decision makers the information they need to launch the right new projects at the right time and sequence the work in the right order to minimize schedule delays, scope change, and budget increases. When it makes sense, a program manager may be needed to oversee the execution of related projects and help manage dependencies between multiple projects. Furthermore, without understanding the relationships between projects, senior management may make a decision regarding one project without understanding the downstream repercussions to dependent projects.  Having this information will also help decision makers make better decisions about in-flight projects. Understanding the impacts of one project on another project is very important, but may be missed unless dependencies are proactively tracked and managed.

The Types of Project Dependencies

There are several types of dependencies that portfolio teams should be aware of:

  • Technical dependencies: “a relationship between two projects that affects the technical outcome of project deliverables”. A technical dependency exists when one project cannot move forward (easily) without a deliverable from another project. This is similar to a finish-to-start relationship common in project schedules, except that it exists between projects. Example: in the IT environment projects may need certain infrastructure to be in place before the project solution can be released. If another project is responsible for setting up the new infrastructure, then there is a hard dependency between the two projects. Having multiple dependencies of this type only compounds the problem and quickly increases the complexity of completing the project on time, within scope, and within budget.
  • Schedule dependencies: (sometimes referred to as a synchronization dependency): “a relationship between two projects where the timing of one project impacts the outcome of another project”. A schedule dependency occurs when project deliverables are needed at the same time in order for both projects to finish. An IT example would be one project decommissioning a system but waiting on another project to complete a data warehouse needed to archive the legacy system’s data. This type of dependency is similar to a finish-to-finish relationship common in project schedules.
  • Resource dependencies: “a shared critical resource between two projects”. A resource dependency only exists when critical resources are shared between projects. This dependency type is often managed at the portfolio level and resource manager level, but project teams should be aware of shared critical resources. If one project is off track and needs additional unplanned effort from critical resources, the other projects may be impacted as well.
  • Information dependencies: this is a less critical relationship, but may be worth noting so that important information is communicated to the impacted projects in a timely way. There are two aspects of an information dependency:
    1. Information shared from one project to another that would impact the latter’s scope or approach to completing the project. An informational dependency commonly exists when there is a known touch point between two projects and is based on changes to engineering standards, operational procedures, architecture, security, etc. For example, one project is working on changes to certain standards and procedures that affects another project. The upstream project team may not yet know what the final deliverable or solution is, but a downstream project knows that the results may impact its project’s design. There may not be a technical deliverable as described above, but changes to standards and procedures could create future re-work, so both project teams need to stay in close communication.
    2. The need to incorporate the capabilities and knowledge gained through another project. In this instance, important information gained from one project team should be passed on to another project team. This may occur more often in engineering environments.

In addition to the various dependency types, it is also important to denote the level of impact for each dependency. This is similar to project risk management where the level of impact varies from risk to risk. Impact could be measured in terms of schedule delays, scope impacts, and cost. Mature organizations may use more sophisticated methods of measuring impact, but less mature organizations can utilize a simple high, medium, low scoring to denote levels of impact. In the next post we will cover the tactics of managing project dependencies.

Read More

Greater Value From Portfolio Management Systems


Portfolio management systems have a very real place in making PPM processes successful. These systems have the potential to drive value in a number of ways, some of which are highlighted below:

1) Enterprise repository (“single source of truth”)—having a single system that contains up-to-date and accurate project and portfolio data is valuable. Gone are the days of maintaining multiple versions of static Excel files that contain the current “authorized” list of projects. This value is magnified the easier it is to access the system and the greater the number of users who access the system.

2) Process enabler—on top of merely storing project and portfolio data, portfolio management systems can better enable portfolio processes through workflow automation. This is particularly useful for stage-gate project reviews that have a number of review steps and need approval by multiple parties.  Portfolio management system can also better enable project management and capacity management processes. Thus the tool reduces the amount of work needed to carry out these processes, reducing lead time and costs.

3) Portfolio tools—portfolio management systems commonly come with tools that make portfolio management easier overall. One clear example is portfolio optimization, which is difficult (if not impossible) with spreadsheets and other databases. Portfolio management systems can make this otherwise difficult job easier by providing the tools needed to effectively get the job done.

4) Reporting and analytics—one of the greatest benefits of utilizing portfolio management systems is to get accurate and up-to-date reports on the status and health of projects, programs, and portfolios. Buying a portfolio management system and not utilizing the reporting capabilities or analytics is like buying a car with only two gears—you’ll make progress but not as quickly as you will by providing decision makers with insightful information and up-to-date reports.

The critical question then is, “how much value are you getting out of your portfolio management system?” If the cost of the system plus the cost of entering data plus the cost of maintaining the system exceeds the value of the information coming out of it, senior leadership either needs to reconsider its ways or change its portfolio management system.

As we discussed in an earlier post, leadership plays a huge part in making sure the right data gets fed into the system at the right time. Yet, leadership plays just as big of a role in making sure the organization gets value from its portfolio management system. Let’s quickly review the four areas where companies can derive value from portfolio management systems and the potential risks.

1) Enterprise repository—if employees and managers do not access the system often, or if there are competing places to get similar project and portfolio data, the system loses value.

2) Process enabler—if project and portfolio processes are not regularly followed, then the effort to load the system with data to enable those processes is a waste of time.

3) Portfolio tools—if the organization does not leverage the tools available in its portfolio management system, then it paid extra money for tools it doesn’t use.

4) Reporting and analytics—if senior management does not pull reports and use the data, then all the effort to ensure that quality data is going into the system is a waste of time. Even worse, if management does not communicate that it uses the data and demonstrate how it uses the data, the organization easily becomes skeptical of the value of portfolio management.

What value do you currently get from your portfolio management systems? Have you encountered any of the problems mentioned above?

Read More

Tactical or Strategic PPM


Fundamentally, portfolio management is about strategic execution and maximizing value to the organization through important project investments. Through various processes, leadership teams can determine how well their project investments align to key strategic goals. Optimization techniques can further enhance the value of the portfolio, ensuring that organizations get the biggest bang for their project buck. Nevertheless, some organizations turn to portfolio management to merely help at the tactical level—getting projects done—and are less concerned with using portfolio management for strategic execution. Organizations should be mindful of their portfolio management approach—is it strategic, tactical, or both?

Tactically, portfolio management as a discipline can help organizations execute projects through better portfolio planning which includes: short-term resource capacity management, managing dependencies, and sequencing projects.

1) Resource capacity management from a short-term tactical perspective (less than six months) enables organizations to minimize over-utilization and unnecessary multi-tasking, both of which increase the risk of failed project delivery. By protecting organizational capacity, projects are more likely to have key team members available when needed to accomplish project work. In addition, fewer projects usually means less multi-tasking which is a known killer of project success.

2) Managing dependencies at the portfolio level starts with identifying all the upstream and downstream relationships to each project in the portfolio. More dependencies means more complexity and increases the overall risk to portfolio success. This is not merely a program management function, but is part of portfolio planning because such dependencies can span across the entire portfolio. When organizations understand the dependencies between projects, the portfolio management team (PMT) can make better tactical decisions to ensure that upstream projects do not negatively impact downstream projects.

3) Project sequencing is another part of portfolio planning because it is related to managing dependencies. Some dependencies affect project schedules (finish-to-start, finish to finish, etc.) and in order for these projects to be successful, project sequencing needs to be managed. The PMT should understand these relationships in order to initiate projects at the right time otherwise projects could be launched too soon only to find out that other work needs to be completed first (resulting in delays and likely re-work).

Although project portfolio management (PPM) has been traditionally performed to support strategic execution, some organizations may use a sub-set of the portfolio processes and adopt a more tactical approach to portfolio management. While this may seem less than ideal to seasoned portfolio management practitioners, it still yields benefits for existing projects and programs, and can ensure greater success than if no portfolio processes were utilized.

Read More

Prioritization Matrix


In a recent LinkedIn discussion, questions were asked about the short-comings of prioritization matrices. I would like to highlight the strengths and weaknesses of using such a tool for portfolio management. Firstly, a prioritization matrix differs from a more traditional scoring approach in that it offers a limited number of priority selections. The most simplistic prioritization matrix has three choices, low, medium, and high. Of course, to be effective, every choice should have some predefined criteria. Otherwise, the matrix is of little value because decision makers can have wildly different views for what is of high importance versus low importance.

Strengths
Prioritization matrices have three primary strengths: simplicity, speed, and applicability to all types of work. Prioritization matrices are easy to understand and simple to use. Calculations are not required for determining the relative priority of a project. Basic criteria should be developed for each part of the matrix, but once complete, decision makers can apply the criteria to various types of work. Because of its simplicity, prioritization becomes a much faster exercise and allows decision makers to quickly distinguish important projects from less important projects. In addition, various kinds of work can be prioritized using a prioritization matrix. With a traditional scoring model, it is difficult to evaluate “keep the lights on” type of work, but with a prioritization matrix it is easier to compare priorities for project and non-project work.

Weaknesses
Prioritization matrices are unable to produce a rank ordered list of projects in a portfolio. At best, such a matrix can provide a categorical ranking of projects in the portfolio, but this won’t help prioritize projects within the same category. Prioritization matrices cannot do a good job of evaluating projects based on multiple criteria, and therefore cannot do a thorough job of distinguishing important projects from less important projects. When evaluating multiple large projects, a scoring system will provide a more accurate analysis over a prioritization matrix.

When Should a Prioritization Matrix Be Used?
Prioritization matrices are good for organizations new to the portfolio management process. Due to the simplicity, organizations can quickly get the benefit of prioritization without spending the time to do a thorough scoring of each project. Even in organizations where projects are scored and ranked, prioritization matrices can be used for “pre-screening” purposes to do a preliminary prioritization. This would be commonly used in a stage-gate process before a formal business case has been developed. A governance team could quickly determine a categorical priority for the project at an early gate review. Prioritization matrices can also be used to triage large volumes of project requests to focus the organization on the hottest projects. I have seen this approach used in an organization that received a high volume of small project requests. In this case, scoring would be an over-kill; the organization just needed to determine the most important work at that time.

Priority Matrix Sample

Read More

Highlights from Day 1 of the Gartner PPM Conference


I am attending my first Gartner conference and have included some of the highlights from day 1 below:

AM Keynote:
It’s about risk. Don’t apply process overhead to low risk efforts.
Today’s status has something for pleasing everyone, but the full truth for no one.
Don’t ask everyone to ‘run’ when walking is ok.
Business cases may be ‘adorable’ but emotions still drive executive decision making.
Take a holistic approach–focus on outcomes first, process second.

Power PMO (Matt Light – Gartner )
Defective business cases lead to defective portfolios.
“Only when you see value are you able to tell what is waste and then start to get rid of it”
Portfolio value at the beginning of the project lifecycle is not approving wasteful projects
Portfolio value at the middle of the project lifecycle is cancelling or fixing poorly performing projects
Portfolio value at the end of the project lifecycle is reviewing the project benefits and results

PPM Maturity Workshop (Donna Fitzgerald – Gartner )
Don’t throw process at a level 1 organziation
Slow down just enough for level 2 organizations
“Real” portfolio management begins at level 3.
No individual heroic effort will get you to level 4.  The enterprise must go with you.
Level 5 (if achieved) only lasts a few years and will fail after key senior leaders leave.

PPM Governance (Robert Tawry – Gartner )
Either get your process well established first OR buy a tool that is easily configurable.
You can optimize resources for speed or efficiency. If you optimize for speed, contributors should only work on 1 project. If you optimized for efficiency, you should do 3 or less projects simultaneously.

Read More

Phased Approach for Portfolio Software Implementations


In a previous blog post, I commented on doing portfolio management ‘by hand’ to learn the processes before adopting a robust portfolio tool. In a recent discussion on LinkedIn, one consultant commented that this most successful PPM software implementations occurred when companies took a phased approach to ease in the new solution. The first phase involved simpler tools to allow the organization to become familiar with portfolio management, followed by the full implementation with the advanced PPM capabilities.

After reading this I felt that there was a lot of wisdom in such an approach. Firstly, it gives the organization time to develop their own portfolio processes without the burden of learning a new tool upfront. Secondly, it allows stakeholders (ie. Project managers, steering team, etc) to understand portfolio processes and be comfortable using them. Third, based on the early experience with project portfolio management, the organization will better understand their own requirements for a full fledged tool.

In a great article on IT Project Portfolio Management, Jonathan Feldman asks organizations to consider the problem they are trying to solve and start with high level data rather than getting too detailed. “If you know what the end goal is, you can start to quantify how close you are to that goal”. Great advice as this too points to the need for a phased approach to implementing portfolio management.

What are your lessons learned with your portfolio management implementations?

Read More

The Need to Develop a Deep Understanding of PPM


Portfolio Management practitioners need to thoroughly understand the implications of various portfolio management practices and disciplines. I read an article last year discussing the misapplications of Lean principles. In contrast to other companies, Toyota’s success with the Toyota Production System is rooted in a deep understanding of the principles and theories so that they can adapt the principles in new situations. Unfortunately, wannabe Lean practitioners (or Six Sigma practitioners, or Theory of Constraints practitioners, etc.) may barely understand the basic theory and principles (but completely lack a deep understanding) and end up misapplying the methods or fixate on tools. The end result is that the methodology is criticized as not working well.

I think we could make a similar case for portfolio management. People commonly talk about various tools such as prioritization without fully realizing the cultural change and governance required or the breadth of influence portfolio management can have on an organization. When well executed, portfolio management can touch many sectors of business not limited to: finance, sales and marketing, engineering, information technology, and operations. Walking in sync with the various functions to make better decisions is a large part of what portfolio management is about. When people fixate on portfolio mechanics, or worse yet, on portfolio software, the whole organization may miss the boat.

With any kind of management discipline or quality improvement methodology, having a deep understanding of the principles and theories is very important in order to best apply the principles to a given situation. One person likened this to teaching someone how to drive a car; there are standards and rules to follow when driving a car under normal circumstances, but during unusual circumstances, an expert driver may adjust the way he/she drives in order to accommodate the conditions. A similar view could hold true with portfolio management—the application depends on a deeper understanding of the methodology. Unfortunately, people are often too quick to develop a deeper understanding and rush into applying the tools. Some time later without realizing the intended benefits, the methodology is blamed rather than the persons who improperly implemented it.

Read More

Bubble Charts and Normalization


Bubble charts are common place in portfolio management processes. Without a designated portfolio management tool, I have designed bubble charts by hand using Excel and PowerPoint. To determine a ‘value’, we use our prioritization value scores and compare that among projects. We have risk scores as part of our prioritization criteria that drive the ‘risk’ portion of our bubble charts. The challenge in the past was how to interpret a score. Is a score of 500 good or bad?  Since my organization was experimenting with a new prioritization process, we didn’t know what was good or bad. Therefore, I made the decision to normalize the scores so that we could fairly compare good or bad projects within the portfolio rather than try to determine a threshold for ‘good’ projects. This has been helpful in identifying which projects drive more overall value to the organization compared to other current projects in the portfolio. The downside of this however, is that you are always going to have a few projects that look bad. Until now, I had been normalizing only among current projects in the portfolio, yet it suddenly dawned on me this morning, that I should also normalize among all projects, past and current in order to understand whether we get more value now than in the past.

One advantage of a bubble chart is to locate those projects that are higher value and lower risk and ask the question, “how can we get more of these types of projects in the portfolio?” Likewise with the lower value higher risk projects, we should ask how to avoid those types of projects. By normalizing with respect to past and current projects, we will see whether or not the projects are moving toward the higher value lower risk quadrant.

Read More

Can we absorb all the changes?


In the book, Project Portfolio Management: A View from the Management Trenches, one of the questions posed is ‘can we absorb all the changes?’  At first glance I dismissed the question and instead focused on the four components of the portfolio lifecycle. However, after further reading, it became clearer to me that from a portfolio management perspective, it is very important to understand how much change is being pushed out to the respective organizations. If there is too much change going on, it is hard for employees to absorb it, adapt to it, and accept it. This leads to excessive churn in the organization which has negative implications such as burn out, lowered morale, inability to get work done, etc.

In my experience as a portfolio analyst, I have heard of other organizations complaining about the amount of change we were introducing to them, particularly at the wrong time. Individually, a system manager or project manager may communicate an individual change to an organization or group of users, yet have no idea about the magnitude of changes coming from other system managers and project managers. This is where portfolio management needs to understand both the amount and the timing of change to the company. As the book points out, it is possible to measure the amount of total change and the timing. Having such visibility give senior management a way to optimize the portfolio by adequately sequencing work so as not to overload the system with too much change at any given point in time.

Of course this is a communication issue, where both the project team needs to communicate implementation dates and the project beneficiary needs to communicate “black out” dates. However, without the portfolio level visibility, it is hard to maintain proper surveillance and protect organizations from receiving excessive change.

Read More

What is Strategic Execution?


Strategic execution must accompany strategic planning, otherwise the strategic objectives and goals simply becomes words on a page. In my experience, I have seen companies post their strategies on a wall without any method or approach for ensuring that those strategies are accomplished. About 30 years ago, a survey was conducted highlighting that about 90% of strategies were never fulfilled. Unfortunately, there is little indication that this figure has dropped much. Hence, there is a strong need for strategic execution.

While ‘strategic execution’ may come across as a mere buzz word, some explanation will help articulate what strategic execution is about. Execution-MIH, specialists in the field of execution management, would describe strategic execution as the ability to translate strategy into reality. It is one thing to develop a strategy, it is another thing to make it actionable and achievable. “[Execution management]  is not just accomplishing a task or a goal, but also to achieve the underlying business objectives…Good execution management will focus on the WHAT as well as the HOW of an achievement.“ Too often, executives focus on the what, but pay too little attention on the how.

Gary Cokins,  a strategist at software company SAS, has pointed out that decision makers need discipline to utilize a comprehensive performance management approach described as “a closed-loop, integrated system that spans the complete management planning and control cycle.” Project portfolio management (PPM) is the comprehensive performance management approach that Gary Cokins is referring to and is the bridge between strategic execution and operational excellence. Having articulated the strategic goals and objectives for an organization, projects and programs are launched that directly accomplish the goals and objectives. These projects and programs become the HOW referred to above. Although some strategic decisions are related to policy changes, most strategic goals require work to be done for its fulfillment. Projects and programs therefore help get this work done, and thus become the vehicles for strategic execution.

In summary, strategic execution is how companies accomplish their strategies. It begins with strategy development and continues with strategic planning. This information feeds a portfolio management system which identifies the best projects and programs (including priority and sequence) and optimizes against resource capacity. The completion of these projects and programs signals the transition of the project work into operations. Once all of the necessary projects and programs related to a particular strategy are complete, the organization should realize the benefits of its strategy.

Read More

Doing Portfolio Mechanics by Hand


In a recent discussion on LinkedIn regarding portfolio tool implementations, one consultant commented that the most successful deployments have been done in phases with an upgrade to a more sophisticated tool being done after improving process maturity.

Such an approach makes a lot of sense and could be likened to using a calculator after learning how to do math by hand. I think the analogy is appropriate. Educators encourage kids to learn the basic and important mathematical skills before using a calculator so that they understand foundational concepts.

The same could apply to project portfolio management in the sense that organizations are better off learning the portfolio mechanics and process disciplines ‘by hand’ before jumping into a dedicated portfolio tool. I believe that those organizations that learn to do PPM ‘by hand’ will end up maturing faster and/or utilizing a full fledged portfolio tool better than had they gone straight to the sophisticated software. The advantage is in learning the processes behind the tool. “A fool with a tool is still a fool”, but if the ‘fool’ can learn portfolio processes, the organization will not ‘toy’ around with portfolio software but will yield greater results due to the process maturity.

I personally have learned a lot by creating portfolio charts and calculating prioritization scores ‘by hand’. As a result, I have a much better understanding of what a dedicated portfolio tool should do based on the processes we have developed.

Read More

Project Portfolio Management (PPM) – Are we using the wrong Terminology?


I believe that clear terminology and efficient communication are important to have effective operations. I also believe that the term “project portfolio management” is an excellent term to describe the function because it explains what the managers should already be familiar with: maximizing value for the organization through optimizing human and financial resources.

When I explain the concepts of project portfolio management, I point out that our projects help accomplish our strategic objectives and that those projects represent investments by the company both in terms of financial resources and human resources. I go on to explain that our project portfolio is also analogous to a financial portfolio where we balance our investments (long-term and short-term, high risk and low risk) and have the same goal—to maximize value.

The key then is to drive maximum value out of those project investments and PPM helps us do that. I finish by discussing our portfolio management lifecycle which consists of four major steps:

1) Selecting the right projects (selected projects must align with the business strategy and meet other important criteria. The result: the portfolio will contain a higher percentage of winning projects)

2) Optimizing the portfolio (All the steps necessary to construct an optimal portfolio given current limitations and constraints)

3) Protecting the portfolio’s value (During the execution of an optimized portfolio, the aggregate project benefits (portfolio value) must be protected. This occurs by monitoring projects, assessing portfolio health, and managing portfolio risk)

4) Improving portfolio processes (Higher portfolio maturity translates into a greater realization of the benefits of project portfolio management)

I have not had any trouble presenting the concepts of PPM, but communicating concepts and getting increased participation are two different things.

I think the problem could be somewhere else however. In a classic portfolio management article by Rachel Ciliberti <http://www.ibm.com/developerworks/rational/library/apr05/ciliberti/index.html#N10094>, she points out that PPM is a blend of management disciplines that combines:

1) A business management focus to ensure that all projects and programs align with the portfolio strategy.
2) A general management focus for managing an organization’s resources and risks.
3) A project management focus for reviewing, assessing, and managing projects and programs to ensure they are meeting or exceeding their planned contribution to the portfolio.

Most good managers will not have any trouble with the first two points. However, a number of managers may not understand the project management language well enough and that may be a stumbling block.

Read More

Welcome to PPM Execution-A New PPM Knowledge Center


This website is a new knowledge center for portfolio management practices and tools. It is difficult to find a PPM knowledge center with a single source of good portfolio management information. There are a lot of good sites with good information, but no single site that could be considered a PPM knowledge center. I plan to post links to other websites with good information, active PPM blogs, good articles, white papers, and other information relevant to the PPM community. I would like to make this as useful as possible, and welcome any feedback.

Thank you.

Read More