Prioritization Is the Compass

Prioritizing Projects With A Scoring Model


EVALUATE YOUR PROJECTS

In the previous post, we covered the detailed steps for building a prioritization scoring model. In this post we will cover the steps for prioritizing projects with a scoring model.

Step 4 – determine scoring values

The last part of the scoring model is to determine the scoring values. For each criterion in the scoring model, there needs to be some evaluation of a low, medium, or high score to drive a numerical score for that criterion. In practice we can expand this to “none”, “low”, “medium”, and “high” to give the decision makers a slightly wider range of options. We do not want too many options as this can slow down the scoring process, but we want enough options to help distinguish project evaluations. A common scoring paradigm would include 0 for none, 1 for low, 2 for medium, and 4 for high. If companies want to put even more emphasis on high value, they could use a 0, 1, 3, 9 scoring paradigm.

In the example below, each of the four qualitative values has a corresponding quantitative value. For each value, there is a definition to help determine to which value the project best aligns. If the governance team determined that a particular project has a medium alignment to strategic objective #1, it would score a 2. We will explore all of the calculations at the end of this post.

Scoring Model - Anchor Scores for Strategic Criteria
Scoring Model – Anchor Scores for Strategic Criteria

The definitions alone can significantly improve the quality of the project scores. The example below is relatively generic and requires the governance team to possess enough knowledge about the project and the strategic objective to properly determine the degree of strategic alignment. This can be problematic if the governance team “feels” that a given project has moderate to high alignment and therefore warrants a higher score. The scoring process is intended to make the prioritization process as objective as possible. This can be accomplished by more specifically defining the underlying criteria of “none”, “low”, “medium”, and “high”. In example #2, an IT department of a large Fortune 500 firm has a specific strategic objective to reduce the number of legacy computing systems. The criteria for each of the four options is far clearer with little need for interpretation. If the project actually decommissions a system, it scores “high”. As companies mature their evaluation process, the specific criteria for none through high can be enhanced.

Scoring Model - Detailed Strategic Scoring
Scoring Model – Detailed Strategic Scoring

For financial evaluations, it is important to set financial thresholds that will really set the winners apart. If the bar is set too low, too many projects will get “high” scores and the scoring model won’t be of much help to distinguish the highest value work.

For the riskiness evaluations, we need to flip the quantitative values so that the highest number corresponds to the lowest risk qualitative value. By doing so, we are giving more value to less risky projects. This makes sense especially if we have two projects which may be nearly identical in value but one is far riskier than the other; under normal circumstances if we could only choose one over the other we should choose the less risky option (i.e. better risk-adjusted value).

Scoring Model - Risk Scores
Scoring Model – Risk Scores

 

Step 5 – collect all necessary information

In order to evaluate projects or new proposals, some amount of information is needed to understand the scope, importance, alignment, cost, benefit, and risks of the project. Based on the actual scoring model you built and your current organizational processes, you may already have all the information you need to use the scoring model. In other cases, new information needs to be collected. Let’s break it out in further detail.

Strategic information: at some point during the intake/proposal phase, the project initiator for each proposal should have provided some rationale for how the proposed project aligns with one or more strategic objectives. Simply stating that alignment exists is not useful; there should be an explanation of how the project supports the organization’s strategic objectives. This information should be captured in a document for each governance team member to review. If this information does not exist (or does not exist for all current projects), the Project Sponsor can help explain strategic alignment when the governance team evaluates the projects. If most current projects are missing this information, the Project Management Office (or other team facilitating the prioritization process) should update organizational processes to include this information going forward.

Financial information: assuming that your scoring model utilizes quantitative financial information, it is very important to ensure that this information is available for all projects (a common challenge for many organizations). The best approach is to work with the Finance department to do some level of financial analysis to determine financial benefits for each project. This will lead to consistent financial information across the portfolio. Without Finance’s help, most organizations struggle to get meaningful financial benefits. The best alternative to getting Finance’s help is to provide spreadsheet templates to each project team to assist with calculating the financial metrics used in the scoring model.

Riskiness information: information about the inherent riskiness of the project is useful for conducting this evaluation. It is important to keep in mind that this assessment is not about the specific project risks (although this could be useful), but about the inherent risk nature of the project. Answering questions such as: “how much organizational disruption will this project cause?” “How much experience do we have with this type of project?” “Do we have a sufficient skill set internally to deliver this project?” are important to evaluate the riskiness of the project. Ideally, some of this information is contained in the business case, project proposal form, or even in a project charter.

Step 6 – Educate

Everyone involved with evaluating and scoring projects must understand the relevant details of all projects in the portfolio. If your scoring model includes a strategic component, financial component, and riskiness component, we recommend the following roles for scoring projects:

  • Strategy: The Governance Team, representing the senior leaders of the organization is best equipped to evaluate the strategic value of each project
  • Financials: this is easily derived from the financial analysis and no additional evaluation is needed. A Portfolio Analyst or PMO Administrator should be available to compile this information and capture it in a single data repository.
  • Riskiness: The Project Manager or PMO Director will be in the best position to evaluate the riskiness of a project. The PMO Director could be the singular person to evaluate riskiness across all projects in the portfolio, which streamlines this evaluation. Alternatively, each Project Manager could evaluate and score individual and share the results with the Portfolio Analyst or PMO Administrator. A group of Project Managers could come together and work together to score their projects as individual Project Managers may interpret criteria a little differently.

In most cases, this requires a certain level of education so each project is fairly evaluated. This is not a small effort. Although the Governance Team may be sponsoring some of the current projects in the portfolio, they won’t be familiar with all of them. That will affect the team’s ability to evaluate and score the projects. Therefore, some level of education is needed to bring everyone up to speed. There are a few ways to accomplish this:

  1. Prepare summary information of each project for the Governance Team to read on their own before the meeting (examples include: business case, charter, etc.). The advantage of this approach is to expedite the scoring exercise.
  2. Prepare summary information of each project for the Governance Team to review during the meeting. Using this approach, the Governance Team would likely review a batch of projects and score them in the same session. The advantage of using this approach is that everyone will have dedicated time to review project information and discuss as a group. This option also takes longer than option 1.
  3. Conduct mini project reviews in a team meeting with the Project Managers in attendance to present and answer questions. The advantage of this approach is that it gives the Governance Team an opportunity to ask important follow-up questions as well as get to know the Project Managers better. This option takes longer than the previous two options.

Step 7 – Evaluate and Score

Tips for handling the evaluation and scoring:

  • Pilot the scoring with a handful of projects: pick a few representative projects (projects known to be high priority and lower priority, across various strategic objectives)
  • Conduct the pilot with the governance team in person: even after prioritizing criteria and discussing it as a team, there will still be questions about specific projects and how they align to the strategic objectives.
  • Build in adequate time for discussion: there will be different degrees of understanding of the projects and some projects will require more discussion than others. The value is in the discussion, so build in adequate time for discussion so participants do not feel rushed.
  • After the pilot, get agreement on how the governance team wants to finish scoring projects. Some teams will want to continue scoring as a group; others may want to do their scoring in advance and come prepared to discuss.
  • Take time to review and validate consistency of scores: some governance team members may be surprised about the scores of certain projects. It is not unusual for some medium and high scoring to be inconsistently applied. The group may have determined that a project was a “high” in one case but after review, it should really be a “medium” or vice versa.

In the next post we will cover the relationship between priorities and resources and the need to reinforce over-communicating priorities and how this affects resource allocation.

Know The Difference Between Work Intake Versus Stage-Gate


What is the difference between a work intake process and a Stage-Gate process? This is important to distinguish, especially for newer PMO’s that are setting up portfolio management processes.

Work Intake

The work intake process refers to the steps of developing a project proposal and bringing it to the governance board (or PMO) for a go/no-go decision. This process works in conjunction with Stage-Gate, but can also be a standalone process. When PMO’s are first established, an intake process needs to be defined so that the PMO can manage incoming project requests. Once the portfolio governance team is established and familiar with the intake process, a full Stage-Gate process should be developed.

The work in-take process is important so that all project proposals are created in a consistent manner with common tools and processes.

The unintended consequences of not having a work in-take process include:

  • Organizational confusion—employees will be unclear on how project proposals get brought forward, resulting in fewer project proposals from within the organization
  • Time delays—without a clear understanding of the process, project proposals may be unnecessarily delayed from being reviewed
  • Quality erosion—the quality of the proposals may erode and further delay the process since participants may not be aware of the information needed for project reviews.

In order to have a successful work in-take process, all of the roles and responsibilities of each participant in the process needs to be documented and communicated. Some questions that need to be answered include: who will write the proposal (project manager, business analyst, executive sponsor)? What information is needed? What templates need to be filled out? What format must the information be presented? Are there any IT systems that need to be utilized (e.g. SharePoint, portal, portfolio management system)? Are there any time constraints for submitting proposals? Is a presentation needed? Who will make the presentation?

Another important reason to establish a work in-take process is to help control the work in progress (WIP) within the organization. At one Fortune 500 company I worked with there was no “single entry” to the organization. Rather, requests came in through system managers, process engineers, subject matter experts, and other employees. It was nearly impossible to track all of the work being done because there was no “single source of truth”. A lot of shadow work was being done in the organization and it was very difficult to stop it because there was no established or enforced work in-take process. This shadow work eroded portfolio value, took valuable resources away from key projects, and was ‘death by 1000 cuts”.

Work in-take success factors:

  1. Having a single “front door to the organization”
  2. Clear roles and responsibilities of all participants in the work in-take process
  3. Clear understanding of what information needs to be submitted
  4. Clear communication about the templates and systems need to be used (if applicable)
  5. Clear timetables for submitting requests and making presentations

 

Work Intake and Stage-Gate
Work Intake with Stage-Gate

Stage-Gate

Stage-Gates are a governance structure to evaluate, authorize, and monitor projects as they pass through the project lifecycle. Each gate represents a proceed/modify/hold/stop work decision on the part of the portfolio governance team. Although the Stage-Gate process parallels the project life cycle, the two are not exactly the same. For more information on the project lifecycle please see the Project Management Body of Knowledge Guide 6th Edition (PMBOK) by the Project Management Institute (PMI).

Stage-Gates are a critical component of project selection. A winning portfolio must contain winning projects, therefore the portfolio governance team must be able to discriminate between good projects and great projects. The decision gate process enables the project governance board to review these projects based on predetermined strategic criteria at each gate review of the Stage-Gate process. At each of those gates, important project information is provided to the project governance board to make a go/no-go decision related to the project. Without this mechanism, unnecessary or poorly planned projects can enter the portfolio and bog down the work load of the organization, hampering the benefits realized from truly important and strategic projects.

 

 

Conclusion

New PMO’s should start by establishing a work intake process to ensure there is one clear path for project requests to reach the PMO. Later, as the organization adopts the work intake process, a full Stage-Gate process can be added on to increase the quality of project proposals and help ensure the portfolio contains winning projects.

Portfolio Reporting Part 1


In a previous post, I wrote that from a very pragmatic point of view, getting the right data to leadership at the right time is at the heart of good project portfolio management. If the right data is not available for decision makers to use, the issue will be mediocre results at best. In actuality, the right data needs to be used to create the right reports to support strategic decision making. Hence, strong portfolio reporting must be a core capability for any organization utilizing portfolio processes. If you are not creating the right reports, then how well is your portfolio process actually working?

In the next few blog posts we will look at various types of portfolio reports, starting with basic reporting and concluding with advanced reporting.

In this first example, we will look at basic bar charts, which can represent subsets of projects in multiple dimensions:

  1. By Strategic Goal
  2. By Project Type
  3. By Sponsoring Business Group
  4. By Sponsor

The intention is to provide a quick visual overview of a certain category of projects (e.g. that align to a strategic goal or which belong to a certain sponsor). These charts provide a quick glance of projects sliced in different ways. There may not be much insight, but simple charts like this could highlight possible gaps in the portfolio and are useful for focused discussions around certain types of projects.

Basic Portfolio Report 1

The next set of basic portfolio reports focus on portfolio metrics. Pie charts of portfolio data are very easy to pull together and can be viewed categorically in different ways:

  • Projects By Category (Count, %)
  • Projects by Category (Cost)
  • Projects by Category (Value generated)

Some categorical examples include: health status, project type, strategic goal, sponsor, organization

Pie charts are really just a snapshot in time, but when data is collected over time, we can also graphically depict trends, which can uncover portfolio gaps. Such gaps highlight areas that need more governance attention and help facilitate focused discussions around managing the portfolio.

Organizations need to collect the following data in order to create these reports: categorical data, financial metric (cost, value, etc.), resource hours, etc.

Basic Portfolio Report 2

In the next post we will look at more intermediate portfolio reports.  In the meantime, what are your favorite portfolio reports? What has worked well for your organization?

Communicate Portfolio Value


I recently finished a project helping a CPG organization within a large retail company implement a product portfolio management process. The company as a whole tends to avoid developing business processes, but this CPG organization recognized the need for greater process discipline around its product pipeline and work in-take. Any endeavor to implement portfolio management can be difficult due to the organizational change component, but one factor that makes it easier is to communicate portfolio value.

Portfolio communication is a significant component of good portfolio management and often requires communicating along the four PPM lifecycle steps shown below:

Communicate portfolio value
Communicate portfolio value

However, as it relates to managing organization change, to communicate portfolio value is to communicate how the portfolio process benefits the organization. Success stories must be shared to reinforce how new changes should be welcomed and adopted.

Communicate Portfolio Value Through Success Stories

Within the first few weeks of the new process, a project manager told his peers that the work in-take processes actually helped him determine that a new product he was about to propose was not a good project after all. He elaborated by saying that the extra rigor required him to ask tough questions about the value of the project, which led him to the conclusion that his proposed product was not worth bringing to market! Prior to a product portfolio approach, numerous project managers would have brought forth new product ideas with little governance or oversight. Now, with greater scrutiny over new product proposals, it was easier to determine early on whether a product idea was worth going after or not. This kind of testimony should be widely circulated throughout the organization to help communicate the value of the portfolio process.

Another project manager approached me recently to share another success story about how his project team believed that making a change to a single product would result in a one-time costs saving of $100,000. However, as a result of the increased cross-functional collaboration required by the new Stage-Gate process, the project team discovered that these changes could be applied to an entire product line resulting in an annual savings of $1,000,000. This was a huge win for the team and is another success story to help the entire organization adopt the Stage-Gate/product portfolio process.

Summary

To communicate portfolio value is not just about communicating the value of the portfolio, or of the individual project components in the portfolio, it also involves communicating the value of the entire portfolio process. This creates positive momentum for helping organizations adopt new processes, resulting in greater success in the future.

Who in your organization manages portfolio communication? How effective is the portfolio communication at your company?

Portfolio Review Meetings


Portfolio Review Meetings

Portfolio review meetings are a great way to review and assess the entire project portfolio with the governance team. Unfortunately in practice, these meetings can be overwhelming, time consuming, and unproductive. There are many ways to conduct a portfolio review meeting, but one of the key questions of the governance team is “what do they want to accomplish at the end of the portfolio review”? For some organizations, portfolio review meetings are about getting project status of every project in the portfolio. For other organizations, portfolio review meetings are designed to evaluate each project in the portfolio with the intention of updating priorities.

Options for Portfolio Review Meetings

With this background in mind, we can look at four options for conducting portfolio review meetings:

  • OPTION 1: A review of all in-flight projects, current status, relative priority, business value, etc. Some projects may be cancelled, but the primary purpose is to inform the LT of the current in-flight projects.
  • OPTION 2: A partial review of projects in the portfolio consisting of high-value/high-risk projects. This provides more in-depth information of critical initiatives and may result in a possible change of priority of certain projects.
  • OPTION 3: A high-level review of all projects in the portfolio with the intention of updating project priorities for every project in the portfolio.
  • OPTION 4: A review of portfolio scenarios that meet current business needs followed by a selection of a recommended portfolio

Option 4 comes courtesy of Jac Gourden of FLIGHTMAP in a 2012 blog post and is the best approach I have seen for conducting portfolio review meetings. I also have sat through long sessions (although not all-day sessions) of reviewing all the projects in the portfolio and it can be painstakingly tiring. Moreover, these types of portfolio review meetings wear out governance team members and do not yield much value.  While there is certainly a time and a place for review the status of all projects or conducting a lengthy review for the purpose of re-prioritizing projects in the portfolio, taking a strategic view is the way to go. Rather than merely focusing on individual projects, a portfolio team can compile a few portfolio scenarios that should be reviewed by the governance team. In many instances, there is significant overlap between the portfolio scenarios, but the emphasis is on the business goals of the portfolio and how a portfolio scenario supports a certain goal. Some examples of portfolio scenarios include:

  • Revenue Growth Scenario
  • Customer Growth Scenario
  • Market Growth Scenario
  • Reduced R&D Spend Scenario
  • Balanced Portfolio Scenario

These scenarios are easier to produce when efficient frontier analysis is applied. Even after a portfolio recommendation is accepted, there is further work to screen out the projects not included in the portfolio, and in some cases to make worthy exceptions for some projects that would have otherwise been removed from the portfolio.

 

 

What do you think? Have you tried this approach before? How successful was it? Let me know.

 

Gate Review Filters


Phase-gate reviews improve project selection. If an organization wants a winning portfolio then the governance team must select winning projects. Therefore the project governance board must be able to discriminate between good projects and great projects. The phase-gate process enables the project governance board to review these projects based on preselected strategic criteria at the gate reviews of the decision gate process. At each of those gates, important project information is provided to the project governance board to make a go/no-go decision related to the project. Without this mechanism, unnecessary or poorly planned projects can enter the portfolio and bog down the work load of the organization, hampering the benefits realized from truly important and strategic projects.

The ability to screen out misaligned projects is based on the types of decision making criteria used for gate reviews. Another way to look at the criteria is that they act as gate review filters.  For instance, some companies may have no filters and approve every project; another company may only judge projects based on financial contribution and screen out very fewer projects; whereas other companies will makes gate decisions based on financial contribution, investment risk, and resource availability. We can see this by the image below.

Gate Review Filters

Types of Gate Review Filters

There are many types of decision making filters available for companies to use, the key is to apply the filters that match the organization’s current maturity and culture. Let’s take a look at a few gate review filters (not an exhaustive list):

1)      Financial filter: this gate criteria requires some sort of financial analysis to determine the profitability (or value) of the project. Applying financial hurdle rates may be one way of screening out lower value projects. Using financial benefit (e.g. net present value) is one approach to rank ordering projects.

2)      Strategic filter: most companies implementing PPM recognize the need to evaluate projects in light of strategic goals and objectives. However, if the criteria is not detailed enough, most projects can be shown to align to strategy to a certain extent.

3)      Risk filters: risk criteria at gate reviews should really be thought of as investment risk. Detailed project risks may or may not be known, but based on the type of project being proposed and the initial analysis the riskiness (or risk nature) can be understood. Depending on the risk tolerance of the organization, more projects may be screened out based on the riskiness of the project.

4)      Resource filters: a more advanced criteria is resource availability or the utilization of key resources who are currently unavailable. Since many organizations do an inadequate job of measuring resource utilization, this filter may not be used as often.

5)      Portfolio filter: for simplicity, a portfolio filter takes an aggregate portfolio view when reviewing individual projects. It measures what the impact to the portfolio is rather than only evaluating the individual merits of the project. It also relates to the balance of the portfolio (short-term versus long-term, risky versus safe, good distribution among business units, etc.).

As organizations mature their project selection process, more gate review filters (criteria) should be used to ensure that right projects get included in the portfolio. More criteria often means fewer projects get approved which means that the project pipeline more closely resembles a “funnel” rather than a “tunnel” (see this post for details).

Book Review – IT Governance


Book review of IT Governance by Peter Weill and Jeanne Ross (Harvard Business School Publishing, 2004)

IT Governance

Synopsis

“IT governance is the most important factor in generating business value from IT.”

“Good governance design allows enterprises to deliver superior results on their IT investments.”

“Effective IT governance is the single most important predictor of the value an organization generates from IT”

The quotes above should draw attention to the importance of well defined and well communicated IT governance. Although not exciting, IT governance helps generate greater value from IT. The authors define governance as “specifying the decision rights and accountability framework to encourage desirable behavior in using IT.” “Governance determines who makes the decisions. Management is the process of making and implementing the decisions.”

Much of the book is spent developing two questions. The first question focuses on the types of decisions that must be made to ensure effective management and use of IT. The authors answer this question by describing five key areas of IT governance that require decision making:

IT Principles—a related set of high level statements about how IT is used in the business.

IT Architecture—the organizing logic for data, applications, and infrastructure, captured in a set of policies, relationships, and technical choices to achieve desired business and technical standardization and integration.

IT infrastructure—determining shared and enabling services.

Business Application needs—specifying the business need for purchased or intentionally developed IT applications.

IT Investment and Prioritization—choosing which initiatives to fund and how much to spend.

The second question addressed in the book focuses on who makes these decisions. The authors address this question by describing six archetypes (decision-making styles) used by enterprises in IT decision making:

Business Monarchy—top managers

IT Monarchy—IT specialists

Feudal—each business unit making independent decisions

Federal—combination of the corporate center and the business units with or without IT people involved

IT Duopoly—IT group and one other group (for example, top management or business unit leaders)

Anarchy—isolated individual or small group decision making

Much research and analysis was made by the authors in connecting the decisions being made with the right decision makers. They conducted an extensive survey of over 250 companies across 23 counties. Based on the results, they concluded that the best performers conducted IT governance differently from the low performers and drew conclusions of what distinguished the two groups.

Commentary

IT Governance was very useful to me personally as it is the most thorough work on the topic that I have read and provided a lot of good insight into how to make governance work. Project portfolio management (PPM) is tightly linked with IT governance, “Portfolio management without governance is an empty concept” (Datz). In order to make portfolio management processes successful a proper governance structure must be in place. Project governance is very much about the types of decisions being made and the people who participate in the decision making. The Project Management Institute’s Standard for Portfolio Management 2nd Edition briefly discussed governance but did not go into the same level of detail as this book. Another well respected PPM expert, James Pennypacker, developed a portfolio management maturity model which identifies governance as a key criteria. This book strongly supplements that maturity model.

This book enlarged my view of IT governance particularly with the five key areas of: IT Principles, IT Architecture, IT infrastructure, Business Application Needs, IT Investment and Prioritization. PPM is very focused on the last area of investment and prioritization, but the four preceding areas lead up to the point of making the investment decisions. It was very clear that a governance structure needs to be set up to account for all five areas.

This book also strengthened my view concerning the people involved with governance. I liked the quote stating, “IT governance is a senior management responsibility. If IT is not generating value, senior management should first examine its IT governance practices—who makes decisions and how the decision makers are accountable.” Governance cannot be delegated to someone else. The authors made it very clear that one of the critical success factors of IT governance is the involvement with senior/executive leadership. Without the adequate leadership, solid governance is likely to fail. In addition, “If business leaders do not assume responsibility for converting [IT capabilities] into value, the risk of failure is high. With high risk comes the likelihood of frustrated business leaders who often respond by replacing the IT leadership or abdicating further by outsourcing the whole ‘IT problem’”. Here the point was made that outsourcing IT may come out of a frustration by the business leaders with IT. Yet, the source of the frustration may very well lie in the poor governance structures established.

Another striking point that affects my current work is the need for improved communication with senior management. Governance communication cannot happen too much. The authors found that “the best predictor of IT governance performance is the percentage of managers in leadership positions who can accurately describe IT governance.” They found that most senior managers could not explain their own governance processes, which would explain why their IT governance doesn’t work properly. These points reinforce my need to continually educate senior management and communicate both the process and the results of our governance procedures so that we have greater project success.

The book was reasonably well written. Although the content was great, I felt that the case studies and diagrams were really lacking. I normally like case studies, but I do not feel that the cases used in this book added any value to me. Many of the diagrams could have also been explained better. As far as improvements, the topic of project portfolio management was barely discussed and is quite important in terms of executing strategic change within an organization. I overlooked it because of the book’s value to the topic of governance, but I definitely feel the authors should have spent more time on this topic. Otherwise, this is a great book for a topic that is overlooked but very necessary. I would definitely recommend it to anyone that is involved with portfolio management or any part of IT governance.

Portfolio Management V-Model Part 1


I recently constructed a portfolio management-oriented V-model. The traditional V-model has been used in software and product development, but this PPM variant differs in that the end result comes together at the point of the V. This is not an exhaustive list of PPM components, but does represent critical components and how they come together to drive better decision making resulting in optimal strategic execution. The model also makes a big assumption that the organization has sufficient strategy development capabilities in place.

Let’s work backwards (from the point back to the tips of the V) to understand how components on the left side supports the model.

 PPM V-Model

One of the primary goals (if not the foremost goal) of portfolio management is to execute strategy. There is an important distinction between strategy creation and strategic execution. Possessing a strategy (and spending the energy to create one) is meaningless if the organization cannot accomplish the strategic goals. Although many people acknowledge that strategic projects are vehicles for a accomplishing a strategy, senior leadership needs to make the right project decisions at the right time to advance the goals of the company. Hence, making smarter and better decisions is a precursor for solid strategic execution.

In order to make smarter and better decisions, the right data needs to be available at the right time. I have written about this in the past. Senior leaders should know what data is important and valuable for making the right decisions at the right time. Data collection costs money as does data analysis. Organizations should be mindful of the amount of effort needed to collect data and only collect data that is most important to the company. In another post, I wrote about a virtuous data cycle by which senior leaders need to actually use the data collected, communicate that the data is being used, and explain how the data is being used. This will encourage higher quality data collection resulting in better decision making. However, in order for the right data to be collected at the right time, processes need to be in place to facilitate the data collection process. Processes for work in-take, business case development, status updates, and resource management help provide the right data in the portfolio management lifecycle to promote better decision making.

The next post will explore the right side of the model and tie all the points together.