Thursday, June 22, 2017

Agile Project Portfolio Management? Conclusion

This is the last 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, funding, alignment, authorization, and monitoring.

Whilst writing of these articles I read a lot of books and other articles about (Agile) project portfolio management. I have seen a number of different ideas and approaches and a number of Agile frameworks that touch the subject of portfolio management. For example SAFe and DAD.  

The Disciplined Agile Consortium (creators of DAD) have defined a number of principles of Agile Portfolio Management where I can fully agree with.

Simplicity: Keep your approach lightweight and streamlined.

Value: Focus on value over cost.

Reduce Delay: Reduce the cost of delay [link].

Improve: Invest in streamling the creation of value.

Stable Teams: Prefer stable teams over project teams.

Align to Value: Align teams to value streams.

Rolling Wave: Prefer rolling wave plans and budgets to annual ones [link].

Choice is Good: Support and enable diversity of approach.

Trust: Trust but verify.

Risk Driven: Govern by risk, not by artifacts.

Small is Good: Prefer small endeavors over large ones.

Quality: Invest in Quality.

Enterprise Aware: Optimize the whole.

But what I was missing was a simple blueprint that could be used as a base for implementing Agile project portfolio management. That is why I decided to write my own. This resulted in the Agile Project Portfolio Management Framework Guide.

The Agile Project Portfolio Management Framework Guide.

The Agile Project Portfolio Management Framework (APPMF) is a framework within which people can address complex portfolio management problems, while productively and creatively delivering projects of the highest possible value. APPMF works well with any project delivery method. From Scrum to Waterfall, and anything in between.

APPMF 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 APPMF:

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;

Defining strategy needs to come before APPMF. In order to select the right set of projects to execute, the strategic goals must be defined in advance.

APPMF is an adaption of the Scrum framework, and shares many of the principles it was build upon. APPMF, like Scrum, is:

- Lightweight
- Simple to understand
- Difficult to master

The APPMF consists of Portfolio Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose.

The Agile Project Portfolio Management Framework
The rules of APPMF bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of APPMF are described throughout the guide. You can find the online version of the guide here. Or you can download the PDF version.


Get your Agile Project Portfolio Management Framework Guide

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
7. Agile Project Portfolio Management? Authorization
8. Agile Project Portfolio Management? Monitoring
9. Agile Project Portfolio Management? Conclusion
10. The Agile Project Portfolio Management Framework Guide

Read more…

Saturday, June 17, 2017

Scaling Agile: Conclusion

This is the concluding article of our series on scaling Agile. In the previous articles we discussed the popular Agile scaling frameworks Nexus, DAD, LeSS, SAFe and Scrum at Scale. They all have many good ideas and parts that I like. Some are very prescriptive like SAFe, and others are the complete opposite, like DAD.

Personally, I am the opinion that the best strategy for scaling Agile is very depending on context like:

- How important is speed of delivery?
- How important is innovation?
- How important is team empowerment?
- Where are teams located?
- How agile is the organization already?
- How complex and/or tightly integrated is the product?
- What is the driving timeframe for becoming agile?
- How severe are the repercussions of a product defect?

We should recognize the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the 'what' and 'how' should be suited to client context and to a wider strategic vision.

Currently, the only scaling approach that really supports this kind of thinking is Scrum at Scale from Jeff Sutherland. His modular approach forces you to think about the different aspects of scaling Agile, and helps you creating your own scaling strategy that suits you best.

Based on my experiences with scaling Agile at different companies and in wildly different contexts I am the opinion that the following guiding rules serve me well.

1. Do not scale, in most cases it is not necessary. Create well-defined product boundaries with interfaces and most scaling efforts are futile.

2. Do not multi-site. It makes simple things complex, and hard things even harder.

3. You cannot scale what you do not have, i.e. when you have no well-functioning Scrum teams in your organization you should not talk about scaling Scrum.

4. Think products, not projects. This shift in thinking will help organizations a lot in making better decisions.

5. Continuous improvement. Never stop learning, and do not be afraid to stop what is not working.

6. Technical excellence is important for agile teams, but for scaling it is essential.

7. Take a modular approach, there is no one size fits all framework.

8. You need top-down support, i.e. management wants to change their own way of working too.

9. Change the system, then culture and people's behavior will follow.

10. Tackle one product(group) at a time.

11. Feature teams, not component teams.

12. Empower your Product Owner (or similar role) to take the decisions he/she needs to be taking in that role.

13. Building is the easy part. You should think about operating your products as well. DevOps is the way to go.

Other articles in this series:

1. Scaling Agile: Nexus Framework
2. Scaling Agile: DAD 
3. Scaling Agile: LeSS
4. Scaling Agile: SAFe
5. Scaling Agile: Scrum at Scale
6. Scaling Agile: Conclusion

Workshop Scaling Agile in an Enterprise Environment

When you want to learn more about the different scaling approaches then join our Scaling Agile in an Enterprise Environment workshop. In this intensive one-day workshop you will pursue three goals:

1. Create an understanding of the common challenges with scaling scrum and formulating your company-specific challenges.

2. Create a basic understanding of the four popular Agile scaling frameworks Nexus, DAD, SAFe, LeSS and Scrum at Scale. We will discuss their common grounds, their differences and how they want to tackle scaling challenges.

3. Create a toolset to help you make the right decisions for your organization by breaking down the scaling challenge into building blocks and asking yourself some important questions regarding the context in which you want to use Scrum.

There is no one-size-fits-all solution so you will have to create one yourself. That is what being Agile is all about!

Read more…

Thursday, June 15, 2017

Agnostic Agile

As experienced agile practitioners and as people responsible for agile change and transformation, we should recognize the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the 'what' and 'how' should be suited to client context and to a wider strategic vision.

We should take this very seriously. Our work is to help our clients attain the right level of agility that meets their needs, our work is not to create framework lock-ins nor to limit how agility can be applied to the organization, whether at team levels or at scale.

This means we as agile practitioners must strive to be masters of our craft, understand and practice at least two formally established frameworks or methods, uphold good conduct between ourselves and others, and help to nurture and grow our community of agile practitioners.

Sam Zawadi created an initiative to spread this important message. The Agnostic Agile Oath. This oath is a manifestation of these intentions, distilled succinctly into a simple list of agreements. Go check it out, and sign when you agree.

Read more…

Saturday, June 10, 2017

Agile Project Portfolio Management? Monitoring

Project Portfolio Monitoring
This is the eighth 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, funding, and alignment. The previous article was about portfolio authorization and the role of the Portfolio Owner. This article is about monitoring your portfolio.

We already discussed the need for some information at the project proposal phase in our article about demand management, but at the latest in the evaluation and alignment phase of the portfolio management process it becomes clear that we need information about ongoing projects in our portfolio in order to make informed decisions about these projects and the portfolio as a whole.
Anything that can be measured can be improved. However, organizations don’t always do sufficient monitoring. Few organizations actually track project and portfolio performance against benchmarks. Worse, strategic multiyear initiatives are the least likely to be tracked in a quantitative, objective manner. For smaller organizations, the absence of such a process might be understandable, but for a large organization, this is a must.

Not monitoring project results create a vicious circle: If results are not tracked, then how can the portfolio management and strategic planning process have credibility? It is likely that it doesn’t, and over time, the risk is that estimates are used more as a means of making a project appear worthy of funding than as a mechanism for robust estimation of future results. Without tracking, there is no mechanism to make sure initial estimates of costs and benefits are realistic. 

This is crucial because there can be a tendency to provide cost estimates that are artificially low in order to gain project approval, especially where there is no monitoring process in place to capture this. What’s to stop the winner’s curse of the most inflated projections getting funded based on elaborate but dubious projections, rather than the best project with credible and realizable, if more modest, strategic benefit? If you are not monitoring performance, then not only will execution performance inevitably deteriorate but your selection process will lose legitimacy and will ultimately become a time-consuming charade. 

Project Metrics

In my opinion, the minimal set of metrics that should be monitored for each project in execution are:

- Estimated end date (for resource allocation)
- Costs till date (exact umber)
- Expected costs till finish (rough estimation)
- Remaining budget (exact number)
- Delivered value since last status update (YES/NO question)
- Expected gain on investment
- Risks
- Issues
- Allocated resources 

Depending on your company and project you can use additional metrics like:

- Employee / Project Member satisfaction
- Stakeholder satisfaction
- Customer satisfaction
- Quality delivered to customer
- Time to market
- Return on Investment
- Meeting business case objectives
- Customer adoption
- Meeting governance criteria
- Benefits realization

When you look at this list of metrics you will notice that none of the typical Scrum project metrics like Technical Debt, Retrospective Items or Velocity are listed. This is because those metrics measure the quality of the Scrum process and are focused on improving Scrum teams. They do not say anything about the success of the project itself. When defining your own organization's metrics it very important to make this difference. What you can also see is that none of the metrics is Scrum specific. Nor specific for Waterfall or any other method. 

Monitoring needs to be balanced. Not monitoring project success can cause sloppy execution, which is costly. However, monitoring too much can cause a project to drown under the weight of its own status updates. Collect data frequently, but only at the level required to make a decision. 

Budgeting is one example. It is important to define what constitutes a meaningful budget overrun and measure to that level. If you only care about the aggregate budget, then breaking out the full budget by line item on a monthly basis is overkill and can distract from the decision and monitoring process that you’re trying to follow. Where data collection is not automated, track only what you intend to act on; more detail can always be captured subsequently should an issue arise (see Exception Based Reviewing)

Reporting

Reporting is critical to an effective project portfolio management system. Whereas collecting up-to-date and accurate data is a challenge, building an effective reporting system is relatively easy. Reports should answer specific questions and be tied to specific processes. Reports that simply look appealing or provide a host of data without underlying meaning are ineffective. Therefore, reports should be the outcome of your project portfolio management processes. It is important to consider the following key report types: 

Single-page project report: Using a consistent format for project status reports is important. Doing so means less time can be spent on the layout and more attention can be paid to the data within the report. Each project summary should be contained on a single page or screen, with top-level details and the contact information for the project manager and project owner provided should questions arise. The data should also be time-stamped. 

Financial information: This provides aggregate roll-up on budget and costs across projects with the ability to drill-down into individual projects. 

Project dashboard: One-line summaries of the projects currently in execution, filterable by important grouping such as division or project sponsor (see Categorization). Often these lists can run to thousands of projects, so by default, filter on the poorly performing projects (such as no value delivered on the status indicator) first, as it is likely those projects are of most interest and require the most attention. 

Resource allocation view: This is a view of current resource availability and utilization for the coming 12 months. This means people, machines, money, and anything else that could be a bottleneck in realizing your projects. 

Strategic alignment: This provides a view of the strategic goals of the business and how the current projects contribute to them. 

Flexible pivot table capabilities: No project report or set of reports will capture everything that is needed, even where drill-down capabilities are available. Using a drag-and-drop pivot table-style analysis on the inventory of projects or proposals can help executives and others find the information that they need to answer a particular question and also lead to creative analysis to produce new report types to further support decision making.

Creating an effective dashboard

Once you know what you are looking to measure, it helps to create a on-screen dashboard that captures the relevant information. The term dashboard uses an automotive analogy to convey the ideas of getting all relevant information simply summarized in one place. This gives an opportunity to effectively summarize project data in an attractive and transparent fashion. Usage of color and graphical indicators can highlight areas of importance, and the best dashboards combine current and trend information to identify patterns. 

Online dashboards can also be created to enable drilling down so that the summary data are presented but if more information is needed, the user can double-click on a project to see full detail on risks, issues, budget, the project manager, team, and current tasks. This type of drill-down setup helps ensure that the initial dashboard is concise but the information is all easily accessible when needed. See for example the Office 365 Project Portfolio Dashboard below.

Project Portfolio Monitoring Dashboard

Not all dashboard metrics need to be quantitative. Team morale is often hard to define and cannot easily be pulled from a reporting system like the most recent cost data, but it is important and can be very useful in monitoring how the portfolio is progressing. Ensuring that the right data are captured on a dashboard is critical, regardless of whether that data can be pulled out of a database. 

Also, with broad survey technology, it does become easier to leverage the wisdom of crowds across the project team. No one individual or data point may be the single source of truth on the morale of project team, but by anonymously surveying the project team and aggregating the results, team morale can be tracked on an ongoing basis. Technology makes the collecting of this sort of data increasingly simple.

Transparency

Often, organizations lock down the permissions or access rights that are given to their employees too finely. Security is based on minimizing the negative consequences of information leakage, rather than maximizing the positive benefits of information sharing within the organization among employees. Consider making various project key performance indicators (KPIs) public to a broad set of employees within the organization. This will help foster new ideas for projects and improve project collaboration. 

Ideally, disclosure at the KPI level should not reveal confidential information and more granular permissions can be set on drill-down financials (like individual wages and rates for external consultants). Generally, providing more information on project performance and processes can help with the goal of avoiding duplication of effort, and provide a further opportunity to emphasize the goals of the organization. 

Portfolio Review Meetings

The Portfolio Owner will schedule regular (I recommend monthly) 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).

This monthly portfolio review meeting helps make the collection of data actionable. The meeting can review the dashboard, and particularly any significant changes related to the dashboard, and help address them. Knowing that the dashboard will be used in this way makes the dashboard meaningful. Simply creating a well-designed dashboard in the hope that someone will find and act on it is wishful thinking if there is no process to support it. 

Ahead of creating the dashboard, consider decision thresholds and the resulting actions. If an indicator turns red for a particular project, what would be the result? If no action would be taken, then why is that piece of information on the dashboard? If the resulting decision is ambiguous, then clarifying the course of action ahead of time can be enormously helpful, given that making decisions in the moment can become a lot more heated. It is also important to consider what other information could result in portfolio actions being taken. If the information is material, consider adding it to the dashboard, even if the data in question are not quantitative. For example, the project management might have a perception of project performance. 

Ideally, the dashboard should capture all aspects of project status. If a project could be killed despite having a completely positive dashboard performance, then either the dashboard or the organization is not working effectively.

Exception-based reviewing

It may not be necessary to go into detail on all projects, but ensure that those projects in the portfolio that are not delivering the expected value are followed up on. A process that includes all projects but only invests significant time in those projects that are off target is exception-based reviewing. Exception-based reviewing means that only projects that pass a certain threshold are reviewed. For example, projects that are more than 10 percent over budget, or are not delivering value for over two months, are highlighted and require a decision as to whether corrective action is needed. This saves time in not having to review all projects in a detailed manner, as the projects that are on track are not analyzed to the same level of detail. It also means that attention can be drawn to projects when problems occur, not necessarily when the review meeting happens. 

Having alerts set up should a project go off target means that stakeholders can be notified in real-time, rather than having to check the dashboard or waiting to receive the data within a particular review meeting. This can improve the speed of response, which can help drive more agility in portfolio management. It also creates a feedback loop, which can help drive improvement. Driving the process by alerts rather than by scheduled meetings can be helpful, even if the review meeting is monthly, if a project starts to go off target the day after the review meeting. By the time of the next review meeting, it might be a month behind schedule, which for a six-month project likely means the project has severe issues. 

Alerts also work well for the late stages of projects—as delivery is close, more monitoring attention is often needed, and alerts can be configured to support that, without requiring the need to scrutinize all projects in detail as they approach delivery. An efficient system of alerts ensures that management focuses on the right issues systematically, rather than spreading themselves too thinly across the whole portfolio.

Read more…

Friday, June 09, 2017

SAFe explained in five minutes ...

SAFe 4.0 Similar to the LeSS introduction video of Michael James there is an introduction video of SAFe. Inbar Oren, SAFe fellow, created a 5-minute video explaining the basics of SAFe 4.0. Agree or disagree with the approach of SAFe, the video is very well done, and I highly recommend watching it. When you want to have a more practical review of SAFe have a look at the videos about Scaling Agile at LEGO.

Read more…

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? Authorization

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.

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
7. Agile Project Portfolio Management? Authorization
8. Agile Project Portfolio Management? Monitoring
9. Agile Project Portfolio Management? Conclusion
10. The Agile Project Portfolio Management Framework Guide

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…