Monday, May 29, 2017

Systems Thinking

Sytems Thinking
A silo mentality is the biggest single impediment to achieving true business agility. Everyone involved in the creation and delivery of business solutions needs to collaborate across the breadth and depth of the organizational structure. Team-level agility in the delivery space alone will not deliver on the promise of the Lean enterprise; nor is DevOps enough. Business, IT and operations all need to break out of their silos and embrace Systems Thinking.

When you read about scaling agile you will notice that popular frameworks are using Systems Thinking. For example, one of the principles of LeSS is Systems Thinking (see here) and also SAFe says it is based on a number of newer paradigms in systems and software engineering, including Lean and Systems Thinking (see here).

So what is Systems Thinking? Here's a definition from Barry Richmond, who coined the term in 1987:

Systems Thinking is the art and science of making reliable inferences about behavior by developing an increasingly deep understanding of underlying structure.

Cultivating this "art and science" leads to routine use of correct mental models that see the world as a complex system whose behavior is controlled by its dynamic structure, which is the way its feedback loops interact to drive the system's behavior. The term Systems Thinking is preferred to holistic or whole systems, which have looser and more intuitive meanings, and emphasize understanding the whole rather than the dynamic structure of the system.

Systems Thinking is not stepping back to look at the whole, the big picture, or a higher level. Nor is it realizing that when a butterfly flaps its wings in one place, that could cause a hurricane far away. This helps, but does not lead to the major insights that emerge when the feedback loop structure of the system becomes visible. When this happens night becomes day. Systems Thinking is the first step to an even higher level: System Dynamics, where instead of just thinking in terms of system structure you model it. See for example this system model from the LeSS website.

Sytem Dynamics Model
 Here is a definition from Peter Senge's highly influential The Fifth Discipline Fieldbook:

Systems Thinking is a way of thinking about, and a language for describing and understanding, the forces and interrelationships that shape the behavior of systems. This discipline helps us to see how to change systems more effectively, and to act more in tune with the natural processes of the natural and economic world.

Event oriented thinkers and systems thinkers

Everyone in the world can be divided into two groups based on how they see the world around them: event oriented thinkers and system thinkers.

Most people are event oriented. They see the world as a big collection of parts and events. Each event has a cause and if you want to solve a problem, find the cause and fix that. How many root cause analysis you allready have been part of? So for example, when applying this mind set to the global environmental sustainability problem, they see people’s misbehavior as the cause of the problem. The solution, then, is to get them to stop behaving so irresponsibly. This can be done with laws stating what to do and not to do, plus emotional appeals to be nice to the environment. When that solution fails, as it has for over 40 years, they just throw up their hands and call it a hard problem.

Systems thinkers see the problem entirely differently. They see immense positive feedback loops causing swarms of agents to exploit the earth for their own benefit and population growth. This mode becomes unsustainable when negative feedback loops finally start to push back as environmental limits are approached. They don’t see people’s misbehavior as the problem. Instead, they see the structure of the system as causing that misbehavior. To solve the problem, system structure must be understood and changed, so that feedback loops can be redesigned to cause people to behave sustainably as a natural part of their everyday existence. This takes far more work than writing a few quick new laws and pleading to save the world.

Defining a system

When defining a system you have to keep in mind the following:
- a system is composed of parts
- a system is other than the sum of its parts
- all the parts of a system must be related (directly or indirectly), else there are really two or more distinct systems
- a system is encapsulated (has a boundary)
- a system can be nested inside another system
- a system can overlap with another system
- a system is bounded in time, but may be intermittently operational
- a system is bounded in space, though the parts are not necessarily co-located
- a system receives input from, and sends output into, the wider Environment
- a system consists of processes that transform inputs into outputs
- a system is autonomous in fulfilling its purpose (a car is not a system. A car with a driver is a system)

Concepts of Systems Thinking

Systems thinking revolves around only a handful of concepts. The key concepts are:

1. All systems are composed of inter-connected parts. The connections cause behavior of one part to affect another. All parts are connected. A change to any part or connection affects the entire system.

2. The structure of a system determines its behavior. Structure is the pattern of part connections, which is how the system is organized. System behavior is at least a thousand times more dependent on connections than parts because that’s what determines how the parts work together. To understand a system’s gross behavior, understand its structure. To change a system’s gross behavior, change its structure.

3. System behavior is an emergent phenomenon. How a system behaves cannot be determined by inspection of its parts and structure. This is because parts are tightly coupled, the parts and structure are constantly changing, feedback loops are present, nonlinear relationships exist, behavior paths are history dependent, the system is self-organizing and adaptive, emergent behavior is counterintuitive, time delays exist, the human mind has very limited calculation abilities, etc. Once you realize how complex the behavior dynamics of even a simple system really is, you will never again assume you can look at a system and predict how it will behave.

4. Feedback loops control a system’s major dynamic behavior. A feedback loop is a series of connections causing output from one part to eventually influence input to that same part. This circular flow results in large amplification, delay, and dampening effects, which is what causes the gross behavior of the system. Every part is involved in one or more feedback loops. Systems have more feedback loops than parts, which causes unimaginable complexity. Feedback loops are the main reason a system’s behavior is emergent.

5. Complex social systems exhibit counter intuitive behavior. The problems of such systems therefore cannot be solved using intuition and our everyday problem solving methods. The use of intuitive methods to solve difficult complex social system problems is a common trap, so common the entire environmental movement has fallen into it. Only analytical methods using tools that fit the problem will solve difficult complex social system problems. The first such tool to adopt is true systems thinking. The second one is a process that fits the problem. The third one, unless it is an easy
problem, is system dynamics.

Laws of The Fifth Disicpline

The Fifth Discipline: The Art and Practice of the Learning Organization is a book by Peter Senge (a senior lecturer at MIT) focusing on group problem solving using the systems thinking method in order to convert companies into learning organizations. The five disciplines represent approaches (theories and methods) for developing three core learning capabilities: fostering aspiration, developing reflective conversation, and understanding complexity. His 11 laws of the fifth discipline are a nice summary of insights provided by Systems Thinking.

1. Today’s problems come from yesterday’s ‘solutions.’
2. The harder you push, the harder the system pushes back.
3. Behavior will grow worse before it grows better.
4. The easy way out usually leads back in.
5. The cure can be worse than the disease.
6. Faster is slower.
7. Cause and effect are not closely related in time and space.
8. Small changes can produce big results…but the areas of highest leverage are often the least obvious.
9. You can have your cake and eat it too—but not all at once.
10. Dividing an elephant in half does not produce two small elephants.
11. There is no blame.

Further Reading

If you would like to read more about Systems Thinking I would start with the book The Fifth Discipline: The Art and Practice of the Learning Organization, by Peter Senge. Work through to the fifth chapter, titled A Shift of Mind. There Peter does indeed shift the mind with a great introduction to Systems Thinking, one so good the book turned much of the American business world onto systems thinking in the 1990s, when it was first published. In this chapter Peter defines systems thinking as "a discipline for seeing the 'structures' that underlie complex situations, and for discerning high from low leverage points."

And then, if you also want to read about System Dynamics, try John Sterman's Business Dynamics: Systems Thinking and Modeling for a Complex World. As the title suggests, this will not only turn you into a systems thinker. It will also turn you into a modeler, using system dynamics.

Read more…

Sunday, May 28, 2017

Agile Project Portfolio Management? How to authorize your portfolio

This is the seventh 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 managementcategorizationevaluation, funding, and alignment. This article is about portfolio authorization and the role of the Portfolio Owner. Let's start with the latter.

Portfolio Owner

The Portfolio Owner is responsible for maximizing the value of the portfolio, seeking the right balance of projects and creating a strong link to strategy. How this is done may vary widely across organizations (see portfolio alignment).

The Portfolio Owner is the sole person responsible for managing the Project Backlog (see demand management) and the Portfolio Backlog (see portfolio alignment). Management of these backlogs includes:

- Clearly expressing Backlog items;
- Ordering the items in the Backlogs to the aforementioned goals;
- Ensuring that the Portfolio Backlog is visible, transparent, and clear to all, and shows what the organization will work on next; and,
- Ensuring the organization understands items in the Backlogs to the level needed.

The Portfolio Owner may do the above work, or have the Portfolio Team do it. However, the Portfolio Owner remains accountable.

The Portfolio Owner is one person, not a committee. The Portfolio Owner typically represents the desires of a Portfolio Committee in the Project and Portfolio Backlog, but those wanting to change a Backlog item’s priority must address the Portfolio Owner.

The reason for having a Portfolio Committee is that the decisions that need to be made usually cannot be made by a single person. For the Portfolio Owner and Committee to succeed, the entire organization must respect their decisions.

A Portfolio Owner should understand and monitor changes in the organizational strategy and objectives and be aware of how the portfolio supports them. Both financial and nonfinancial benefits and risks to the organization need to be taken into account. The Portfolio Owner typically does not create organizational strategy and objectives, but may participate in the process depending on the specific organization. However, the Portfolio Owner does play a key role in creating the portfolio strategic plan and implementing the strategy by monitoring the execution of initiatives in support of the plan and by communicating progress and results.

Portfolio Owners are responsible for the execution of the portfolio management process as defined in this article series. This includes demand managementcategorizationevaluationfunding, alignment, authorization, and monitoring.

Portfolio Owners receive information on portfolio project performance and progress, and they convey to the Portfolio Committee how the Portfolio Backlog items as a whole are aligned with the strategic goals, then provide appropriate recommendations or options for action.

They also ensure that timetables for portfolio management processes are maintained and followed and that the managers/owners of the Portfolio Backlog items (projects, programs, and operations) receive and provide the information required under the portfolio management processes.

The Portfolio Owner will schedule regular (monthly for example) portfolio review meetings. Participants in these meeting are the Portfolio Owner, Portfolio Committee and invited guests (for example the Product Owner of a large initiative to give a detailed update).

Other responsibilities of the Portfolio Owner include:

- Establishing and maintaining a framework (a conceptual and communicable structure of ideas) and methodology for portfolio management within the organization;
- Establishing and maintaining relevant portfolio management processes (strategic management, governance management, communication management, performance management, and risk management);
- Guiding the categorization, evaluation, selection, prioritization, balancing, and termination of Portfolio Backlog items to ensure the alignment with strategic goals and organizational priorities;
- Establishing and maintaining appropriate infrastructure and systems to support portfolio management processes;
- Continuously reviewing, reallocating, reprioritizing, and optimizing the portfolio to ensure ongoing alignment with evolving organizational goals and market opportunities and threats;
- Providing key stakeholders with timely assessment of Portfolio Backlog items selection, prioritization, and performance, as well as early identification of (and intervention in) portfolio-level issues and risks that are impacting performance;
- Measuring and monitoring the value to the organization through portfolio performance metrics and targets, such as benefit ratios, return on investment (ROI), net present value (NPV), payback period (PP), internal rate of return (IRR), and scorecards.
- Meeting legal and regulatory requirements;
- Achieving the information needs of current or future stakeholders;
- Supporting senior-level decision making by ensuring timely and consistent communication to stakeholders on progress, changes, and impact on Portfolio Backlog items;
- Influencing active executive sponsorship engagement for the portfolio and each Portfolio Backlog item as it is initiated;
- Participating in program and project reviews to reflect senior-level support, leadership, and involvement in key decisions.

Portfolio Committee

Portfolio governance is established by a Portfolio Committee to make decisions about investments and priorities for the portfolio and ensures the portfolio management processes are followed to sustain the organization. The Portfolio Committee is made up of one or more individuals with the requisite authority, knowledge, and experience to ensure the alignment of Portfolio Backlog items with organizational strategy. The Portfolio Committee has the authority to evaluate the portfolio performance (see portfolio evaluation) and to make resourcing, investment (see portfolio funding), and priority decisions (see portfolio alignment) as needed.

Recommendations may include new Portfolio Backlog items, the suspension or change of existing Portfolio Backlog items, and the reallocation of resources among Portfolio Backlog items. The recommendations may be complex with significant organizational constraints especially concerning reallocation of resources.

Portfolio review meetings

Portfolio review meetings are held by the Portfolio Owner and the Portfolio Committee in order to review the current status of the portfolio and to determine if any decisions need to be made regarding the portfolio and its backlog items. These meetings are typically recurring, formal in nature, scheduled around significant portfolio milestones, or triggered by external events such as financial drivers, regulatory changes, and completion of significant portfolio backlog items or deliverables.

The portfolio is updated as a result of decisions made by the Portfolio Committee during their formal or informal portfolio review meetings. For example, when the Portfolio Committee decides that a Portfolio Backlog item needs to be added, terminated, or changed in some fashion, the portfolio is updated. Once the Portfolio Committee makes a decision that changes the current portfolio in some way, the decision is communicated to stakeholders, sponsors, and portfolio backlog item owner (Product Owner, Project Manager or Program Manager). The method for documenting and communicating the governance decisions may be a spreadsheet, a text document, or found within the portfolio management information.  The decisions made in the portfolio review meeting are called portfolio authorization.

The danger of slow decision making

Slow decision making, even with a well-defined and robust project portfolio, can dramatically impact performance. On top of slow decisions, organizational inertia can make it much easier to continue projects than to kill them. The larger the project in terms of budget, people, or strategic aspirations, the harder it can be psychological to say that you were wrong, or at least that forecasts weren’t accurate. This problem is particularly acute for external projects.

If the CEO has stood on a podium and listed the praises of a key multimillion-dollar project to customers, partners, suppliers, and the media, then reversing course becomes harder. Ironically, these can be the projects when changing course is most valuable. This is not to say that big projects are any better or worse than smaller projects. The point is that big projects can be harder to kill than small ones, given the reluctance to accept large-scale failures when there is always the hope that things might turn around next year.

When managing your portfolio, pay particular attention to projects that are ongoing, relative to new projects. If anything, you should be more rigorous on existing projects, because you have actual data rather than mere projections on your hand, so you should be able to form a better view on whether continual funding is merited. It shouldn’t be a foregone conclusion. No one enjoys failure. However, spotting failure early can be much less expensive than another year of unjustified optimism, especially when you understand the trade-off you are making in funding your low-performing projects at the expense of the others.

Better management of your portfolio makes the whole portfolio more efficient. The risk of funding an underperforming project is lower if you know you can identify compelling opportunities elsewhere, rather than just replacing an underperforming project with a similarly underperforming one.

So, as stated before, for the Portfolio Owner and Committee to succeed, the entire organization must respect their decisions, and they have to decide quickly and regularly.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

Read more…

Saturday, May 27, 2017

Business Agility

Business Agility
In a business context, agility is the ability of an organization to rapidly adapt to market and environmental changes in productive and cost-effective ways. The agile enterprise is an extension of this concept, referring to an organization that uses key principles of complex adaptive systems and complexity science to achieve success. One can say that business agility is the outcome of organizational intelligence.

Evan Leybourn has written extensively on the topic of business agility on his blog. One of his articles is the "Theory of Agile Constraints" which can be summarized as follows:

An organisation can only be as agile as it's least agile division!





Many companies I know start their road to agility with the development teams of their IT department. And there it stays. Typically they are not very successful in their journey because the rest of the organization is still keeping the status quo. Ken Rubin visualized this situation very nicely.

Business Agility

Recently Evan has decided to create a domain model for business agility. Via LinkedIn he asked for input and feedback on his first version of it, and I and many others did. The result of his work and this process you can find on his website in an article called "Domains of Business Agility". Check it out, it is a good model to use for planning and evaluating your own journey to an agile business.

Business Agility Domains

Read more…

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? How to align your portfolio

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 and 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.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

Read more…

Sunday, May 14, 2017

Agile Project Portfolio Management? How to fund your projects

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 categorizing your project backlog. The last article was about evaluating your portfolio. 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.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

Read more…

Thursday, May 11, 2017

Agile Project Portfolio Management? How to evaluate your portfolio

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 categorizing your project backlog. This article is about evaluating your portfolio.

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 funding your portfolio. 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.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

Read more…

Sunday, May 07, 2017

Agile Project Portfolio Management? How to categorize your project backlog

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 project backlog 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 strategic 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.

"Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." - Sun Tzu

The second step is mapping the projects and proposals in 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. The 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 strategic 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 into 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 of 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 evaluating your portfolio. 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 our portfolio on a regular base we also need to evaluate projects that are currently executed.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

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 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.

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide, I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Other articles in this series

1. Agile Project Portfolio Management?
2. Agile Project Portfolio Management? Demand Management
3. Agile Project Portfolio Management? How to categorize your project backlog
4. Agile Project Portfolio Management? How to evaluate your portfolio
5. Agile Project Portfolio Management? How to fund your projects
6. Agile Project Portfolio Management? How to align your portfolio
7. Agile Project Portfolio Management? How to authorize your portfolio
8. Agile Project Portfolio Management? How to monitor your portfolio
9. Agile Project Portfolio Management? Conclusion

Read more…