Wednesday, May 24, 2017

LeSS explained in three minutes...

LeSS explained in three minutes...
Michael James (author of the ScrumMaster Checklist) created a 3 minute video that gives a good introduction to LeSS.  Large-Scale Scrum (LeSS) is Scrum applied to many teams working together on one product. For large product groups and projects, LeSS tries to hit a sweet-spot balance between defined concrete elements and empirical process control. And just like one-team Scrum, LeSS is lightweight, simple to understand, and difficult to master due to essential complexity. A big part of understanding LeSS are principles like Systems Thinking, Experiments, Lean Thinking etc, because that is the foundation of LeSS, and those need to be understood and used in order to implement LeSS succesfuly.


Read more…

Tuesday, May 16, 2017

Agile Project Portfolio Management? Alignment

This is the sixth article in our agile project portfolio management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The following articles discussed demand management, categorization, evaluation, and funding. This article is about portfolio alignment.

Portfolio alignment is the combination of selection, prioritization and balancing. As seen in the previous articles there is not much difference between PMI project portfolio management and Agile project portfolio management. At this stage in the process it is different. It is time to put the "Agile" in Agile project portfolio management.

Based on what we have learned and done in the previous articles we start with the following:

1. Project execution can be managed with any method you choose. It does not have to be an agile method (see Agile Portfolio Management?)

2. A Portfolio Owner (see Demand Management). In an upcoming article we will give a detailed description for this role.

3. A project backlog that contains: A) a number of projects that are currently being executed and B) a number of project proposals (see Demand Management). This list will be continuously updated by the Portfolio Owner based on decisions made in the portfolio alignment process.

4. A strategy that we have converted into strategic goals (see Categorization)

5. Categorized the backlog items on the project backlog based on the categories we have defined (see Categorization)

6. Have a set of evaluation methods implemented that we can use during the alignment process (see Evaluation)

7. Have funding on an initiative and/or strategic goal level (see Funding), so we are flexible in our decisions regarding starting and stopping projects.

The next step is creating the portfolio backlog.

The portfolio backlog

We already defined our project backlog an now we define our portfolio backlog. It contains the set of projects that are currently being executed and the ones that are selected to be executed. You can compare our two backlogs with the product backlog and the sprint backlog in a Scrum project. The project backlog is containing all ideas, proposals and unfinished projects, that can be prioritized at will based on the implemented evaluation process. The portfolio backlog contains only the set of projects that are currently being executed or are selected to be executed.

Both backlogs are owned by the Portfolio Owner. When he/she has a team supporting him/her you could give the ownership of the portfolio backlog also to the team. Similar as a Sprint backlog.

Before we start discussing how we are going to select our projects for our portfolio backlog we should have a look at how many we are going to select.

How big should a portfolio backlog be?

Of course the answer of this question is depending on the altitude of your portfolio (i.e. only IT, or your whole company), the size of your projects, and the size of your company. But there are a number of guidelines from the Agile and Lean world that we can use.

PMI project portfolio management is all about value optimization and optimizing resource allocation. Both are designed in such a way, that in my opinion it will result in the opposite. As we have seen in the article about funding, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of time spent on re-planning. And value is only created when it is delivered and not when it is planned. Hence we should focus on delivering value as quickly as possible with our given constraints.

This brings us to lean thinking. Lean is sometimes described as focusing on smaller batch (project) size, shorter queues, and faster cycle time. Focus on delivering value quickly. Lean is much more than this. The pillars are respect for people and continuous improvement resting on a foundation of manager-teachers in lean thinking. Queue management is just a tool far from the essence of lean thinking. But it is a very helpful tool that can have a very positive impact on your project portfolio management process.

Some example of queues in project and portfolio management?

- products or projects in a portfolio
- new features for one product
- detailed requirements specifications waiting for design
- design documents waiting to be coded
- code waiting to be tested
- the code of a single developer waiting to be integrated with other developers
- large components waiting to be integrated
- large components and systems waiting to be tested

In lean thinking, work in progress (WIP) queues are identified as waste, and hence to be removed or reduced, because:

- WIP queues (as most queues) increase average cycle time and reduce value delivery, and thus may lower lifetime profit.

- WIP queues are partially-done inventory (of projects in this case) with an investment of time and money for which there has been no return on investment.

- As with all inventory, WIP queues hide—and allow replication of—defects because the pile of inventory has not been consumed or tested by a downstream process to reveal hidden problems; for example, a pile of un-integrated code.

On a similar note, we typically have a lot shared resource queues in our portfolio. Especially the main know-how carriers in a business unit are shared by multiple parallel projects. These queues are getting bigger due to project re-planning when one of them is behind schedule.

Looking at all the above we, can learn three important things for our alignment process.

1. Keep your portfolio backlog size small (i.e. limit work in progress). Focus on limiting the number of concurrent projects in your organizational units. 

2. Keep your project size small (i.e. limit batch size).

3. Implement an agile delivery method for projects were it makes sense (i.e. reduce cycle time because you deliver value during the project, and not only at the end)

Portfolio alignment iterations

A core element of Agile is delivering in small iterations. As we have stated before we want to accommodate Agile and non-Agile projects in our process. One way to leverage the use of Agile projects in the portfolio management process is by using a monthly cadence to review the portfolio backlog. When you use Scrum as a delivery method you can give guidance that each project should have 1,2 or 4 week sprints. This makes alignment very easy. When continuous delivery models are used alignment is also given, and when waterfall models are used you will have alignment as well. So for the rest of the article I assume you have monthly portfolio backlog review Meetings.

Goals of these monthly review meeting are portfolio evaluation, selection, prioritization and balancing. The demand collection and categorization is something the Portfolio Owner should do before this meeting. This work can be compared with backlog refinement in the Scrum process.

Aligning projects and portfolio

The whole project backlog need to be reviewed. Proposals can be selected for the portfolio, more information could be requested, or just left on the project backlog with a remark. Already selected projects can be stopped, re-prioritized or accelerated.

The big difference between project proposals and already selected projects is that selected projects are part of the monitoring process. This process will be discussed in detail in a later article. In general, the monitoring process will provide you with information in order to help you decide on what to do with this project. Typical information areas are people, risk, costs, time, planned value (scope) and delivered value. These inputs can then be used in your evaluation strategy.

The selection (including balancing) itself is easy. Just execute your evaluation strategy on your project backlog. Since your evaluation strategy includes costs, risks and people information you do not separately have to look at these constraints. Based on the resulting information from the evaluation (like ranked lists, bubble charts, strategic buckets, etc) you decide on your portfolio for this alignment iteration with the three portfolio goals in mind:

1. Maximize the value of the portfolio;
2. Seek the right balance of projects, thus achieving a balanced portfolio;
3. Create a strong link to strategy, thus: the need to build strategy into the portfolio;

After this selecting and balancing you should prioritize your portfolio backlog. Similar to the product backlog in Scrum all your items on the portfolio backlog should be ordered according to priority. When we could do only one project from this list, what project would that be? Then answer the same question for the remaining list. This prioritization will help with future portfolio review meetings, and helps with the evaluation when it comes to allocation of money and people, planning, and solving conflicting interests.

Focus on early validation

Instead of selecting a whole project at once you should start each large project (whatever large would mean for your organization) with a PoC and Business Case validation phase. Rather fail early and learn then having massive sunk costs for something that does not live up to their promise. Proof of concepts are essential for high technology risk projects. There are many techniques for business case validation but the simplest one is talking to potential and existing customers.

Visualize your portfolio backlog

An ideal way to represent the existing portfolio backlog in such a meeting is using a Kanban board. A Kanban board is a work and workflow visualization tool that enables you to optimize the flow of your work. Physical Kanban boards typically use sticky notes on a whiteboard to communicate status, progress, and issues. Online Kanban boards draw upon the whiteboard metaphor in a software setting.

Agile Portfolio Kanban Board

For an agile portfolio as described in this article you could use the following swim lanes:

1. More information needed
2. New (selected, but not yet started)
3. Validation (PoC and/or business case validation)
4. In progress
5. Done
6. Stopped

The next article will be about authorization and roles. In order to be flexible with your project portfolio you should be able to decide on changes in a quick, easy and formalized way. In other words, not go through a month long delicate political dance to get approval for each small portfolio change. This has big implications for who has authority and responsibility for portfolio and strategy decisions. 

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment

Read more…

Sunday, May 14, 2017

Agile Project Portfolio Management? Funding

This is the fifth article in our agile project portfolio management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The second article discussed demand management, and the third was about categorization. The last article was about portfolio evaluation. Originally this article would be about portfolio alignment, but when I started writing it I felt that a piece of the puzzle was missing. Namely funding. That is why I decided to write this article first, and save alignment for the next.

We already established in the previous articles that you can only evaluate and select a meaningful project portfolio when you know the available funds and people for your portfolio. Since you do not know upfront which projects you are going to select, and you also want to have the flexibility to accelerate, kill or de-prioritize existing projects it is an essential part of Agile project portfolio management to implement funding on an initiative or strategic goal level, and NOT on a project level.

A company that has the size where project portfolio management adds the most value is typically organized into business units and/or cost centers; each cost center must contribute project spending or people (the primary cost element) to the new effort. This creates a number of problems, including:

1. The project budget process is slow and complicated; it takes many individual budgets (one per cost center) to create the project budget.

2. It drives teams to make detailed decisions far too early in the project. Teams are forced to come up with plans that are just guesses; if they can’t identify all the tasks, how can they estimate how many people are needed, what skills they should have, and for how long?

3. The assignment of people to a project team is a temporary thing; the organization assumes people will come back into the cost center for future assignments. If they don’t, other planned projects will suffer.

4. The model drives cost center managers to make sure everyone is fully allocated. However, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of time spent on re-planning.

5. The model prevents individuals and teams from working together for longer than the duration of just the one project. This has a negative effect on knowledge acquisition, team performance, and employee engagement.

Once the project is initiated, the challenges continue. The actual needs of the business change quickly, and the reality has not much to do anymore with the assumptions that the project made. However, the projects cannot adapt to the changing priorities, because their budgets and people are fixed for the project duration.

The result is that the organization is unable to adapt to the changing business needs without the overhead of re-budgeting and reallocating people. Overhead kicks in; economics suffer. The cost of delay (the cost of not doing the thing you should be doing) increases.

But we are not done. For example, software development projects cannot happen without takings risks. By its very nature, development is extremely difficult to estimate because it contains a large degree of technical uncertainty. And everyone knows that most things take longer than planned. Moreover, even when things go really well, stakeholders may want more of a specific feature. That takes longer, too.

Project-based funding hinders forward progress, culture, and transparency. 
When a schedule overrun occurs for any reason, it is necessary to analyze the variances, re-budget, and re-plan. Resources are scrambled, and reassignments of people occur. Other projects are negatively impacted.

The “blame game” sets in, pitting project managers and product owners against each other and financial analysts against the teams. Any project overrun has a budgetary impact. The casualties are transparency, productivity, and morale.

So ideally you would fund initiatives or strategic goals (see for example the Strategic Bucket Model in the previous article). You could fund larger programs as well, but I am not a big fan of programs on an execution level. Just do not fund single projects.

Unfortunately, the reality in most companies is that funding is on a project level. So when you are not able to change this have a look at my article Agile Project Budgeting to see how you could minimize the negative impact of project level funding. But be warned, as will be clear from the following articles, the added value and success of Agile project portfolio management is depending on implementing funding on strategic goal or initiative level, and not on a project level.

The next article in this series will be about portfolio alignment. In other words, selection, prioritization, and balancing of the set of projects that will be executed. We will also cover some queuing theory because a big issue in many companies is executing many projects in parallel. In other words, selecting too many projects.

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment

Read more…

Thursday, May 11, 2017

Agile Project Portfolio Management? Evaluation

This is the fourth article in our agile project portfolio management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The second article discussed demand management, and the third was about categorization. This article is about portfolio evaluation.

Within project portfolio management, new projects are categorized, evaluated, selected and prioritized; existing projects may be accelerated, killed or de-prioritized; and resources are allocated and reallocated based on maximizing productivity.

Project portfolio management does not involve making project-by-project choices based on fixed acceptance criteria. Instead, decisions to add or subtract projects from the portfolio are based on the three goals of project portfolio management:

1.
 Maximize the value of the portfolio;
2. Seek the right balance of projects, thus achieving a balanced portfolio;
3. Create a strong link to strategy, thus: the need to build strategy into the portfolio;

The reality about project portfolio management that most consultants and software vendors don't want to hear is that the necessary model for project evaluation needs to be different for different clients. That is because what clients need from their projects to be successful differs wildly, even for similar organizations within the same industry having an almost identical strategy.

We will describe a number of portfolio evaluation tools and methods in relation to the three major goals of portfolio management demonstrating how the tools could help in the evaluation, selection and prioritization process.

But before we can start with discussing these evaluation tools and methods we need to gather some additional attributes for our project backlog. In order to evaluate portfolio value, we should know risks and constraints. In order to balance we should know risks. The base for creating a strong link to the strategy we already build in our categorization process by linking each project backlog item to one or more strategic goals.

Portfolio constraints

Typically the two most important constraints are money and people. The first one is easy, the second one is harder to specify. You could argue that the only constraint here is money because you could hire specialist people with money when you have not enough people to execute a project. But in reality this is a) not economical, and b) it will cost a lot of time for them to understand the organization specific things.

One approach to constraint definition that I have taken with success is to take the headcount for each organizational unit and then take a percentage of the headcount that is available for project work. This percentage can be different for each organizational unit. Say for example a business unit has 20%, a software development unit has 80% (the rest is maintenance), and your PMO department has 100%. Now you have to identify for each item on your project backlog list which organizational units would be involved for how many person days (just rough estimations). These can then compared with how many days are already taken by existing and selected projects. It is far from perfect, but this will actually give you a pretty good idea if a certain unit could handle the volume of selected projects without new hires and external help.

Risks, issues, and interdependencies

Known risks and issues for all items on the project backlog list should available. This means that budget overruns, late delivery, resource shortage, skills mismatch, and others can be factored into the evaluation and decision-making process. Besides risk and issues, the interdependencies between projects should be known. As already discussed in the previous article you could group a set of projects into a program and evaluate this as a whole, or just identify the links between projects. You can imagine what happens when you killed a project and you were not aware that the software planned to be delivered in that project was essential for your flagship project to succeed.

Maximizing the value of the portfolio

The first goal of project portfolio management is maximizing the value of the portfolio. This means that each individual project should represent good value to the organization and the collection of projects must make efficient use of the resources available. Where projects compete for scarce resources it must be clear how the allocation between them is to be made based on value.

Below you will find a number of evaluations that can be made on your project backlog. In my opinion, you should select more than one for your own evaluation strategy and compare their value during the evaluation.

Net Present Value and  Return On Investment
Net Present Value (NPV) is the difference between the present value of cash inflows and the present value of cash outflows. NPV is used in capital budgeting to analyze the profitability of a projected investment or project. Basically, it represents the net result of a multiyear investment (expressed in $). The following is the formula for calculating NPV:

where

Ct = net cash inflow during the period t
Co = total initial investment costs
r = discount rate, and
t = number of time periods

With the NPV one must consider that this value is not used to ascertain levels of investment. It is simply a number by which the investor is aware of the amount of cash flow that he is receiving as a result of an investment. It is also used to measure (or predict) the amount of cash flow that is to come in the future; it does not look at profits and losses in a traditional sense, as it takes into consideration the discount percentage.

The Return on Investment (ROI) is a performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. ROI measures the amount of return on an investment relative to the investment’s cost. To calculate ROI, the benefit (or return) of an investment is divided by the cost of the investment, and the result is expressed as a percentage or a ratio.


As regards the ROI, one must consider that it has no real merit when trying to calculate future cash flow based on the cash flow that an investment is accumulating today. It is simply a way to measure the amount of profit (or return) an investment is making over time. However, it is a great indicator of where your investment stands. Because of its simplicity and versatility, it is one of the most commonly used values to measure the success of an investment. If an investment returns a negative ROI or there are more lucrative opportunities using a different ROI all together, then the investment should not be considered at all.

Both values do have their downsides. In terms of the NPV, this value does consider the discount rate of the dollar value at present and in the future; however, it doesn’t exactly calculate the initial investment that must be dedicated. If two investments have an NPV of $100.000, it may seem as if both were lucrative; however, if one has requires a dedicated investment of $10.000 and the other $1.000.000 it’s obvious the former is a much more promising investment. 

A big drawback of both methods is that they need estimations as input. When you look at the cone of uncertainty you understand that at the start of a project (project proposal) the estimations are typically way off from reality. They are the most certain when the project is finished and benefits have been measured, but then it is too late to be useful in the PPM evaluation process because the project is already finished. So what to do?

I have good experiences with using the range-based estimations we discussed in previous articles. Just take the following four pairs:

1. Upper bound for the discounted cash flows and lower bound for the investment
2. Upper bound for the discounted cash flows and upper bound for the investment
3. Lower bound for the discounted cash flows and lower bound for the investment
4. Lower bound for the discounted cash flows and lower bound for the investment

You then have four different NPVs/ROIs. When you give a probability for each outcome you have everything setup for running a Monte Carlo Simulation on this value. Monte Carlo simulation, or probability simulation, is a technique used to understand the impact of risk and uncertainty in financial, project management, cost, and other forecasting models.  See my article "Estimating with Wideband Delphi and Monte Carlo Simulation" for a detailed explanation on how to do such an analysis.

Expected Commercial Value (ECV)
ECV seeks to maximize the expected value, or expected commercial worth of the portfolio,
subject to certain budget constraints.

ECV= ((PV*Pcs –C)*Pts)*D

ECV = the expected commercial value
PV = the present value of cash flow, after launch (this is strictly income stream; none of the project costs – development, capital, and so on – have been subtracted from this stream)
Pcs = the probability of commercial success (a number from 0 to 1.0)
C = commercialization or launch cost remaining to be spent on the project
Pts = the probability of technical success (a number from 0 to 1.0)
D = development costs remaining to be spent

As with the NPV, a big drawback of this method is that it needs estimations as input.

The Productivity Index (PI)
PI is a variant of the ECV method that considers risks and probabilities of projects; it shares many strengths and weaknesses. The PI tries to maximize the financial and economic value of the portfolio for given resource constraints.

PI =(ECV * Pts – Development) / Development

ECV = the expected commercial value
Pts =the probability of technical success
Development = the Development costs remaining in the project

Options Pricing Theory (OPT)
OPT is a fairly new concept but some financial experts claim it to be the only correct valuation method because they consider that NPV and DCF are “misused” and sometimes unfairly penalizes certain types of projects, especially high-risk projects. When the project is a high-risk project, i.e. a project where the probability of technical or commercial success is low and the cost to undertake the project is high then NPV and DCF considerably understate the true value of the project.

Dynamic Rank-Ordered List
The advantage of this method is that it can rank-order projects according to several criteria concurrently, without being as complex and time-consuming as a full-fledged, multiple-criteria model. NPV, ROI, strategic importance of the project, probability of technical success can be some of the criteria.

Scoring Models
Some of the more important success factors that are correlated with the probability of the new product are the following:

- Having a unique, superior product
- Targeting an attractive market
- Leveraging internal company strength (products and projects, competencies, and experience in both marketing and technology).

These strong predictors of success as tools should be used for selecting projects. For more such predictors see my articles on "Why are we actually doing this project?" and "Questions to ask before you develop your new product".

Check Lists
Some firms use checklists instead of scoring models at their review or Go/Kill meetings. The questions are similar in both methods but the scoring procedure and end result are quite different. In a checklist method, the answers are yes/no. A single “no” answer is a knockout: It kills the project. The checklist is most effective at project review to weed out poor projects but they are not good for project prioritization since there is no 0-100 total project score that facilitates rank-ordering projects.

Paired Comparison
With this method, we compare project ideas against each other, one pair at a time. Here the question, “If you had a choice, which of the two projects would you do?” There is a discussion, and a consensus vote is reached on each pair. Projects are then rank-ordered according to the number of times they receive a “yes” vote in each paired comparison. This method is very useful at the very beginning of projects when almost no information is available.

Achieving a Balanced Portfolio

Bubble Diagram
The risk-value portfolio bubble chart represents a portfolio view of all (or selection of) projects and puts projects into one of four quadrants based on value and risk; this is important for identifying projects that drive overall greater value to the organization compared to other projects as well as highlight projects that should likely be screened out.

One of the key benefits to a portfolio bubble chart is to quickly show the balance of the current portfolio.  Using portfolio bubble charts with the Portfolio Owner can focus conversations to help better manage the portfolio. When reviewing projects that are in the higher-value/ lower-risk quadrant, the Portfolio Owner should ask the question, “how can we get more of these types of projects in the portfolio?” Likewise, with the lower-value/higher-risk projects, the Portfolio Owner should ask how to avoid those types of projects. These discussions will greatly enhance the management of the portfolio and enable the Portfolio Owner to “manage the tail” and ensure that only the best projects are selected and executed.

There are four primary data elements needed to build the risk-value bubble chart: value scores for each project, risk scores for each project, categorical data, and the project cost or financial benefits of the project (commonly used for bubble size). A prioritization scoring mechanism is typically required to build the best portfolio bubble charts (we will discuss prioritization in an upcoming article).


Build Strategy into the Portfolio

Strategic fit is the first and easiest to envision because it addresses the question: “Are your projects consistent with your articulated strategy?” How to link strategy with project backlog items we discussed in the previous article. You could score each strategy link with a value between 1 (weak) to 5 (very strong) for a scoring model as described above.

Strategic Buckets Model
Strategic Bucket Model focuses more on resource allocation. It answers the questions: “If this is our strategy, then how should we be spending our development funds?” It starts with strategic goals and then moves to setting aside funds or buckets of money destined for each strategic goals. The goal of the portfolio is to fill as many buckets as possible in order to create a strategically balanced portfolio.

Summary

- you can make your portfolio evaluation as simple or complicated as you want.
- the more you rely on estimations, the more you have to think about how wrong these typically are.
- each attribute you want to use for your evaluation somehow has to be captured. This can make your demand management and categorization very complex and create a high barrier for demand collection.
- you have to match your evaluation strategy with what is important for your company. Never just blindly follow consultants our vendor recommendations.

The next article in this series will be about portfolio funding. Originally that article would be about portfolio alignment, but when I started writing it I felt that a piece of the puzzle was missing. Namely funding. That is why I decided to write that article first, and save alignment for the next.

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment

Read more…

Sunday, May 07, 2017

Agile Project Portfolio Management? Categorization

This is the third article of a series around agile project portfolio management. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The second article discussed demand management. This article is about categorization.

The Project Management Institute (PMI) defines categorization as: "The process of grouping potential components into categories to facilitate further decision-making", and it defines a category as: "A predetermined key description used to group potential and authorized components to facilitate further decision-making. Categories usually link their components with a common set of strategic goals."

I disagree with the categorization process descriptions of PMI, but the actual definition of categorization holds up. Since we defined that all our existing projects and new proposals are captured in a project backlog (see demand management) I will be talking about project backlog items, and not about components. An item is or an existing project or a project proposal. A program will never be an item on the project backlog. You could group a set of projects or proposals in a program by categorizing them like this, but a program by itself is not an item.

There are a number of steps that we have to do in order to categorize our project backlog. The first is linking project backlog items with strategy goals. Many organizations have a well-defined and well-scoped strategic process. This can be augmented by better and broader idea capture to provide supportive tactics, but the execution of it is the critical challenge. Indeed, as is widely recognized, weakness in execution, not a weakness in strategy, is a primary reason for business failure. Knowing this, it is important to tie the strategic theory governing the business to the experience of project management. Without this linkage, either the project portfolio is blind to the needs of the business or the strategic goals are empty, with no support at the execution level. It is clear that this is an area that businesses must get right for long-term success.

The second step is mapping the projects and proposals on other categories that we would like to use for our decision-making process. In order to do so, we have to define attributes for our project backlog items and define categories within these attributes.

Linking project backlog items with strategy

Defining strategy needs to come before portfolio categorization. In order to select the right set of project proposals to execute, the strategic goals must be defined in advance. Furthermore, the strategic goals should ideally be relatively limited: three to seven goals are best so that project proposals can be consistently benchmarked across all of the strategic goals, and the effort of doing this is not overwhelming. It helps to think of it as a matrix, with 100 proposals and 7 strategic goals, creating 700 mappings between projects and goals that must take place. With 20 goals, the number of mappings required would be 2000. This is not the only reason to keep the number of strategic goals low, but it is a relevant factor.

Having a small number of goals also helps to keep the goals memorable and at the necessary high level, thus avoiding strategic goals blurring with the tactics from their implementation. Of course, the process of linking project proposals to strategic goals is critical. If the projects you execute don’t reflect your strategy, then what does? It is much less likely that operational work has a strategic impact relative to projects, which are more likely to create some level of change within the organization.

This process also entails that the strategic goals are reasonably broad—the sort of goals that are likely to remain valid for the next three years or longer, rather than the next three months. The duration of your strategic goals should be at least as long as the time required to implement projects and realize the benefits from the projects that support them. If strategic goals are narrowly defined and numerous, then they are unlikely to be applicable to a broad portfolio of projects and proposals.

It is also important that the strategy is at the same altitude as the backlog of projects being reviewed. If the project backlog items are from across the business, then the strategy, too, should apply to the entire business; but if the project backlog items are just a subset of all proposals and projects, such as only IT projects, then prioritizing them against IT’s strategic goals makes the most sense. The correct way to perform the prioritization is to have the project backlog and strategic goals defined at the same level.

A simple example. Let's take a company that has defined the following business strategy. I know it is a very boring one, but it will work for our purpose.

1. Expand globally. Existing markets are North America and Europe. Target market is Asia.
2. Be profitable.
3. Maintain our financial position.
4. Leverage success without leveraging assets.

You could translate this into the following strategy goals:

1. Market penetration
2. Return on Investment (ROI)
3. Low up-front investment
4. Use existing technology

Once strategic goals have been defined, which is itself a nontrivial process, linking them to project proposals and your existing projects is relatively straightforward. Each project can be examined to see the extent to which it supports each of the strategic goals. This will be a key step in the prioritization process. The goal is not to choose the 10 project proposals with the highest return on investment, but to ensure that the projects map to the strategic goals of the business. The actual linking can be done by the Portfolio Owner.

The linking process is the first step in aligning the project backlog items with the strategic goals of the business and, ultimately, determining the extent to which each project will advance the strategy.

Defining project proposal attributes

Besides the strategy goals discussed above, there are other attributes that can help you in your portfolio decision-making process. Especially when we create meaningful categories within these attributes. What we have to keep in mind here is that we have to make the proposal submission process as simple as possible. This means we should limit the number of attributes that the submitter has to fill in to the minimum that is necessary. But if the submitter wants to add meaningful additional information to the proposal we should make that possible.

So, in my opinion, a good proposal submission form has a number of mandatory and a number of optional attributes. The further we will come into the portfolio selection process the more information will be needed. Since we can request this when we need it, there is no need to burden the submission process with too many mandatory attributes.

Let's start with the mandatory attributes of a project proposal. In my opinion, three mandatory attributes are enough:

1. Name: A short name for the proposal.
2. What?: This is the description of the idea/proposal and is free text. You should offer the possibility to add an attachment to this field.
3. Why?: This is the reason why the submitter thinks it is a good idea/proposal.

When we use a simple online form application to capture this information we get the information about the proposal submitter and the date it was submitted for free.

So what could be some other meaningful attributes? Of course, what is meaningful or not depends on your organization and your portfolio altitude, so you should think about it thoroughly. A few examples:

Technological uncertainty: does the technology already exists in the organization? is it new technology? do we have the expertise in the organization?

Regulatory/Compliance: Is it forced upon us because of regulatory/compliance reasons?

Time criticality: should it be executed in a certain timeframe in order to give benefits?

Client impact: would there be a lot of change for our clients? Discontinuing a service could have a very high impact for some clients.

Employee impact: would there be a lot of change for our employees? For example, a new ERP system would have a very high impact.

Market Penetration: would this help us enter a new market, or sell more in an existing market?

Estimates: Estimations of costs, project team size, savings, additional revenue. In my opinion, all estimates at the proposal level should be range based estimates.

Range based estimates

We should assure in the project proposal process that contributors are not locked into specific but inaccurate estimates at an early stage. Keeping estimates range-based makes it more likely that estimates can converge toward their true value as more data are obtained. If a point estimate must be provided early in the process, it is less likely to converge on the true value. This is partly due to the psychological effect of anchoring (i.e., when an estimate that is introduced into the process gains some credibility), regardless of the accuracy of the underlying assumptions, and the estimate is then less likely to move than if no estimate existed.

Having no estimate whatsoever poses its own problems, so using a range-based estimation process is the best approach; the issue of anchoring doesn’t disappear but it is less acute with a range rather than a point estimate. An example for costs estimations:

< 500K
500K - 1M
1M - 5M
>5M

Defining meaningful attribute categories

After we have defined the attributes we would like to use for our proposals the next step would be to create meaningful categories for them. Meaningful in this context means that they can be used to group proposals and authorized backlog items in order to facilitate further decision-making. Let's have a look at the example attributes we discussed.

Technological uncertainty: A categorization that I have used many times is the following: 1) Technology exists in the organization, 2) Technology is easily acquired, 3) Technology is hard to acquire, 4) Technology needs to be created, 5) No technology needed

Regulatory/Compliance: A simple yes or no would work fine here.

Time criticality: A simple but effective categorization could be: 1) None, 2) Delivered within 3 months, 3) Delivered within 6 months, 4) Delivered within a year.

Client impact: A very effective categorization can be 1) No client impact, 2) High Impact for few Client, 3) High Impact for many clients, 4) Low impact for many clients, 5) Low impact for few clients.

Employee impact: A simple 1) None, 2) Low, 3) Medium, 4) High could do the trick. Always give four options with this kind of scales, else always the middle one will be chosen.

Market Penetration: A simple but effective categorization could be: 1) No new markets, 2) Growth in existing market(s), 3) Intro into target market(s), 4) Intro in non-target market(s)  

The Portfolio Owner can do a lot of the categorization him/her self. Also automation based on simple IF/ELSE rules can support the categorization process. When the proposal is lacking information and will be selected for further evaluation you can always request for additional information from the submitter. Of course, also the proposal submitter can already have categorized the proposal himself. But this categorization should be validated by the Portfolio Owner.

The next article in this series will be about portfolio evaluation. In other words, which criteria can be used to evaluate the project proposals. But evaluation will not be limited to the proposals. Since we plan to review or portfolio on a regular base we also need to evaluate projects that are currently executed.

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment

Read more…

Saturday, May 06, 2017

Agile Project Portfolio Management? Demand management

This is the second article of a series around agile project portfolio management. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods like Scrum, Kanban, LeSS etc. This article will discuss the first step of the project portfolio management process: demand management.

PMI calls this project identification, but I think this is not covering everything that is needed in this step and propose demand management as a better term.

Demand consolidation

The very first step of demand management is consolidating all existing demand. Typically this is stored in many different applications and files, and you should put them in one single place. If this is a fancy project portfolio management application or a spreadsheet does not matter for now. You just must have to make sure you have captured everything in one place. And with everything, I mean operational projects, strategic projects, upgrades, office moves, office closings, even the secret pet project of the CEO with that funny code name. As soon as you have done this, that list becomes the single truth. In other words, any project that is not on that list does not exist, and will not get any resources (people or money).

Demand collection

After you have consolidated all demands you have to set up a process for collecting new demands. Else you will find yourself very soon in the same situation as before you consolidated all existing demands. New project ideas and demands are often collected in the form of project proposals. The demand collection is known as the proposal submission process. Within organizations, this is frequently done ad hoc and lack formality. Besides not capturing all demands in a single place, the lack of a well-thought-out process will reduce the number of proposals, or inputs, into the portfolio selection process.

As with most processes, reducing the number of inputs can reduce the quality of the outputs. Having a limited list of ideas hinders any project portfolio. In the extreme, if the number of ideas you have matches the number of projects you can complete, then the portfolio selection process is obsolete. Without a list of ideas larger than you can do, you cannot make trade-offs between ideas. You would just implement all ideas, and the quality of the portfolio will suffer.

Although there is clearly no shortage of ideas within an organization, unfortunately, these ideas are seldom captured in most organizations, except in the few cases where a handful of employees are sufficiently entrepreneurial to drive their own ideas through to implementation. This can happen in spite of the organization, rather than because of it.

Organizations are effective at focusing employees on their daily tasks, roles, and responsibilities. Organizations are far less effective at capturing the other output of that process: the ideas and observations that result from it. It is important to remember that these ideas can be more valuable than an employee’s routine work. Putting in an effective process for capturing ideas provides an opportunity for organizations to leverage a resource they already have, already pay for, but fail to capture the full benefit of—namely, employee creativity.
To assume that the best ideas will somehow rise to the top, without formal means to capture them in the first place, is too optimistic.
Providing a simplified, streamlined process for idea submission can increase project proposals and result in a better portfolio of projects. Simplification is not about reducing the quality of ideas, but about reducing the bureaucracy associated with producing them. Simplification is not easy, as it involves defining what is really needed before further due diligence is conducted on the project. It also means making the submission process easy to follow and locate and driving awareness of it.

Necessary proposal information

In terms of a simplified proposal, a relatively brief description with broad estimates of key parameters, such as budget and headcount, is all that is needed. In fact, sometimes all that is needed is the idea, and the budgetary angle can be left until later in the process. Then as the proposal moves through the process and gets closer to implementation, more detail can be added—perhaps by introducing a step to develop a detailed business case into the process, assuming the idea is selected at an initial stage.

In this way, no proposal is more detailed than it needs to be. In addition, less effort is wasted on filling out what might be superfluous information because the proposal may not make it that far during the selection process.

Another benefit of a simplified project proposal process is that contributors are not locked into specific but inaccurate estimates at an early stage. Keeping estimates range-based makes it more likely that estimates can converge toward their true value as more data are obtained. If a point estimate must be provided early in the process, it is less likely to converge on the true value. This is partly due to the psychological effect of anchoring (i.e., when an estimate that is introduced into the process gains some credibility), regardless of the accuracy of the underlying assumptions, and the estimate is then less likely to move than if no estimate existed. Having no estimate whatsoever poses its own problems, so using a range-based estimation process is the best approach; the issue of anchoring doesn’t disappear but it is less acute with a range rather than a point estimate.

Create a project backlog

If you implemented the two steps discussed before, you now have an ever growing list with existing projects and new project proposals. Similar as the management of a product backlog you could manage this list as a project backlog. So what is the difference between the before mentioned list and a backlog?

The project backlog in agile PPM is a prioritized project list, containing short descriptions of all unfinished projects and ideas in the organization. When applying agile project portfolio management, it's not necessary to start with a lengthy, upfront effort to document all details. The project backlog is then allowed to grow and change as more is learned about the projects and its benefits.

Is this different from traditional PPM? For most companies it probably is, hence I would categorize this under an agile PPM technique.

The owner of the project backlog is the project portfolio owner. For most organizations, this would be a new role. The responsibilities belonging to this role will be defined in the upcoming articles. The project backlog needs to be an ordered list based on priority. So now is the question how can we prioritize the project backlog in a meaningful way? That is not so easy and will be covered in the upcoming articles.

The next article in this series will be about project categorization. The first step in linking your projects with your strategy.

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment

Read more…

Monday, May 01, 2017

Agile Project Portfolio Management?

This is the first in a series of articles on agile project portfolio management. In this article, we explore the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods like Scrum, Kanban, LeSS etc.

According to the Project Management Institute (PMI) project portfolio management (PPM) is the management of a collection of projects and programs in which a company invests to implement its strategy in order to maximize value.

So in order to use this as a start for our exploration, we have to define project, program, and portfolio as well. Here PMI uses the following definitions:

A project is a temporary endeavor undertaken to create a unique product, service, or result.

A program is a group of related projects managed in a coordinated way to obtain benefits and control not available for managing them individually. Programs may include elements of related work outside the scope of discrete projects in the program.

A portfolio is a collection of projects, programs and other work that is grouped together to facilitate the effective management of that work to meet strategic business objectives. The projects or programs of the portfolio may not necessarily be interdependent or directly related.

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. - Sun Tzu, the great Chinese general, The Art of War c. 500 B.C.

Personally, I really like the definition of Cooper et al in "Portfolio Management for new products" (2006). They define project portfolio management as a dynamic process, whereby a business’s list of active projects is constantly updated and revised. In this process, new projects are evaluated, selected and prioritized; existing projects may be accelerated, killed or de-prioritized; and resources are allocated and reallocated to the active projects.

They state that portfolio management is used to select a portfolio of projects to achieve the following goals:

- Maximize the value of the portfolio;
- Seek the right balance of projects, thus achieving a balanced portfolio;
- Create a strong link to strategy, thus: the need to build strategy into the portfolio;

Is agile PPM any different from traditional PPM?

When we define agile PPM as managing a portfolio of projects that are delivered/managed with an agile method the answer would be no. It does not matter how you manage your project, it is still a project, i.e. a temporary endeavor undertaken to create a unique product, service, or result. Hence all PMI definitions hold up. The same for the definitions of Cooper et al.

What we do have to ask ourselves is what we do with the outcome of such an agile project. Many times the outcome is actually a new product, and a product may need an initial ramp-up to get it started, but it does not end after it was built. There is a maintenance and upkeep element to products that often get ignored.  I see many projects deliver substandard products and then leave businesses in a world of pain.

Is there a distinction between a portfolio of projects delivered with agile methods and a portfolio delivered with traditional methods (Waterfall, SDLC)? Personally, I do not think so. A company-wide PPM should accommodate both kinds of delivery types since both have proven their value under certain conditions. So I will work with the assumption that a project portfolio will contain both kinds of projects.

So the difference between agile PPM and PPM (if there is one) can be only in how we manage a project portfolio.

Project Portfolio Management Process

PPM according to PMI basically exists out of the following nine processes.

1. Identification: this process creates an up-to-date list, with sufficient information, of ongoing and new components that will be managed.

2. Categorization: this process categorizes identified components into relevant business groups to which common decision filters can be applied for evaluation, selection, prioritization, and balancing.

3. Evaluation: this process identifies pertinent evaluation factors and then evaluates components.

4. Selection: evaluated components are formally rejected or selected for further consideration based primarily on their value.

5. Prioritization: this process ranks components within each strategic or funding category according to established criteria.

6. Portfolio Balancing: this process creates the portfolio component mix with the greatest potential to collectively support the organization's strategic initiatives and achieve strategic objectives.

7. Authorization: this process formally communicates portfolio-balancing decisions and formally allocates financial and people resources required for selected components.

8. Portfolio Review and Reporting: this process gathers performance indicators, provides periodic reporting on them, and reviews the portfolio periodically for continued alignment.

9. Strategic Change: this process enables the portfolio management process to respond to changes in strategy. Activities here are as many and varied as the organizations using portfolio management.

In the following articles, I will discuss each of them and will analyze if we could use the same, a similar of a different process for a portfolio containing projects that are delivered with agile methods without hindering the benefits of agile methods. The second thing I will look at in these articles is if we could make the overall process in such a way that it is (more) aligned with the agile values.

The next article will be about demand management, and will cover the first step of the process.

Other articles in this series:

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? Categorization
4. Agile Project Portfolio Management? Evaluation
5. Agile Project Portfolio Management? Funding
6. Agile Project Portfolio Management? Alignment

Read more…

Tuesday, April 25, 2017

The reverse triple constraint of troubled projects

Project Management Reversed Triple Constraint Triangle
Assuming you suspect or know that one of your projects is in trouble the first step is always an extensive project review. After such a review you hopefully have the necessary information for decision-making as well as the team’s support for the recovery of the project.

It may be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to the stakeholders. When the project first began, the triple constraints most likely looked like what you see in the figure below.

Project Management Triple Constraint Triangle

Time, cost and scope were the primary constraints and tradeoffs would have been made on the secondary constraints of quality, risk, value and image/reputation. When a project becomes distressed, stakeholders know that the original budget and schedule may no longer be valid. The project may take longer and may cost significantly more money than originally thought. As such, the primary concerns for the stakeholders as to whether or not to support the project further may change to value, quality and image/reputation as shown in the figure below.

Project Management Reversed Triple Constraint Triangle

This happens almost every time I join a troubled project. After focussing on these the project actually runs a lot smoother and high-value outcomes are prioritized and supported. So the big question is why don't we start projects with the reversed constraint triangle? Why put our image and reputation on the line by letting it come that far? Why work on things that obviously do not have such a high value because when it comes hard on hard they are not needed? Why make the quality first a priority when we already feel the pain of bad quality?

The funny thing is that agile methods like Scrum try to do exactly this. Focus on value and quality. This automatically helps your image/reputation. When the time in a Scrum project is fixed this automatically means that cost is fixed as well, but your scope is flexible. In other words, only the most valuable things are done in a good quality.  When the scope is fixed, your time and costs are flexible. Still, the team will start working on the most valuable things first and you can stop the project at any time, and have valuable results. No high-risk big bangs, valuable results are delivered every sprint.

The reason I say that agile methods try to do this, and not actually do this, is because they are hindered in most organizations. The acceptance and adoption of new ways of budgeting and planning for projects lay way behind of the acceptance and adoption of using agile methods in projects. And those agile projects are suffering because of it.

Read more…