Tag Archives: Portfolio Management

Review: Manage your project portfolio

9781680501759-480x600Johanna Rothman wrote the book Manage your portfolio Second edition – Increase your capacity – Finish more projects. A book for the more professional portfolio manager or as mentioned on the back of the book: Expert skill level.

If you are facing too many projects, if firefighting and multitasking are keeping you from finishing any of them, this book will help you to manage your portfolio. It makes use of agile and lean ways of working and brings the biggest benefits when you are running your projects in an agile way too. Projects become to be delivered features and evaluation means prioritizing feature sets. In the quick reference card, I highlighted the way the author promotes the usage of Kanban boards to manage your portfolio and it visualizes some of the decisions to be taken.

Manage your portfolio (QRC, 171017) v1.0

To download: Manage your portfolio (QRC, 171017) v1.0

The author divided the book in fourteen chapters and these chapters gives you a step by step approach to build your portfolio. All chapters end with several situations and possible responses to try.

  1. Meet your project portfolio: It’s not your customer who cares about your portfolio. If you are facing issues to finish projects, if you want to deliver faster, more often and qualitative good products to your customer, you need a portfolio
  2. See your future: by managing your portfolio you make the organization’s choices transparent. It becomes clear what to work on first, second, third. It will help to avoid multitasking. What does it mean if you apply lean approaches to your project portfolio? You must think in terms of value, let teams work in small chunks that they can handle and complete
  3. Create the first draft of your portfolio: start collecting all the work before you attempt to evaluate and determine whether you need to do it now. When needed organize sets of projects into programs. Divide your projects in feature sets or Minimum Marketable Features. Not all feature sets are equally important.
  4. Evaluate your projects: the very first decision is about whether you want to commit to this project, kill the project, or transform the project in some way before continuing. If you don’t want to commit but you can’t kill it either put the project on a project parking lot (name, data, value discussion and notes) so you don’t lose track of it.
  5. Rank the portfolio: You can use many methods to rank. The author discusses the rank with Cost of Delay, business value points (divide a total number of points across your projects), by risk, organization’s context, by tour product’s position in the marketplace or by using pairwise comparison, single or double elimination.
  6. Collaborate on the portfolio: Making portfolio decisions is never a single person’s decision. Facilitate portfolio evaluation meetings.
  7. Iterate on the portfolio: Set an iteration length for your review cycles. This cycle length is affected by your project life cycle (agile delivery gives you the opportunity to have shorter review cycles), your product roadmap, and budgeting cycle.
  8. Make portfolio decisions: Conduct portfolio evaluation meetings at least quarterly to start with, decide how often to review the project parking lot. How are you going to cope with advanced R&D projects? Build a project portfolio Kanban (create backlog, evaluate, project work, assess/validate and maintain) to manage your portfolio.
  9. Visualize your project portfolio: Create a calendar view of your projects with predicted dates. Show not only your staffed projects but your unstaffed work too.
  10. Scaling portfolio management to an enterprise: What are the consequences of resource efficiency thinking (100% resource utilization is 0% flow)? How can you scale by starting bottom up or top down? You need both but scale with care. Do you know your enterprise’s mission or strategy otherwise it will be very difficult, if not impossible to make large decisions? Set up a corporate project portfolio meeting to answer the questions which projects help to implement our strategy and which project distract us from our strategy.
  11. Evolve your portfolio: Using lean can help you to evolve your portfolio approach. What does it mean if you stabilize the time-box or the number of work items in progress (see Naked planning video too).
  12. Measure the essentials: for a lean or agile approach consider the following measures: team’s velocity (current and historical), amount of work in progress (cycle and lead time, cumulative flow), obstacles preventing the team to move faster (how long in progress), product backlog burn-up chart, run rate. Never measure individual productivity.
  13. Define your mission: Brainstorm the essentials of a mission, refine the mission (specify strong verbs, eliminate adverbs, avoid jargon), iterate until you feel comfortable, test your mission, make the mission real for everyone.
  14. Start somewhere…but start!

Conclusion. Johanna Rothman wrote a must read for portfolio managers who are struggling with their role when their organization is moving towards more business agility, with more and more permanent agile teams in place but also for the traditional portfolio manager, facing too many projects and almost no delivery to get hands-on practical advice to start organizing their portfolios.

To order: Manage your portfolio Second edition – Increase your capacity – Finish more projects.

Naked Planning Overview by Arlo Belshee

Arlo was one of the first to lay-out the inspiration for Kanban systems for software development.
Advertisements

Portfolio Canvas

In one of my previous posts I discussed the Portfolio Canvas. I received several questions from my readers, triggered by the picture of the Portfolio Canvas, that they would like to see the post in English. I asked the developers if they were willing to create an English version. I just received the first draft.

The remainder of this post is the translation of the Dutch post: Portfolio Canvas.

I was triggered by a sneak preview of this portfolio Canvas during a seminar about business agility with an agile portfolio (28 June 2017). I thought this canvas was an answer for agile portfolio management, but now it is formally released, I have to conclude it’s not completely true.

In this post, I will briefly summarize this portfolio Canvas and I give my vision and some recommendations. Feel free to give feedback too.

Michael Sauerbier, Diederik Biesboer, Daniel van den Dries & John van Rouwendaal (all from Cratos Consulting) are the developers of the Portfolio Canvas®.

Portfolio Canvas ENOn their website ( http://cratosconsulting.nl/het-portfolio-canvas/, in Dutch only) we get the following summary:

The Portfolio Canvas is a tool for portfolio managers and (senior) management to:

  • Create a project portfolio overview and
  • To facilitate the priority discussion

The Portfolio Canvas supports organizations in answering the following questions:

  • Who, why, when, and which projects and programs
  • What are the overall portfolio cost (Euro) and benefits (revenues)
  • Biggest portfolio risks and dependencies

The Portfolio Canvas delivers added value in the development and monitoring of a project portfolio by:

  • Facilitating the creation of the project portfolio
  • Delivering a simple overview of the agreed portfolio
  • Communicating the agreed portfolio
  • Facilitates progress monitoring and control.

Remarks and recommendations:

  • Good initiative, which can become, in co-creation, a valuable add for organizations.
  • Replace revenues with benefits or value (financial & non-financial) and work force with people.
  • Nice layout. For me unclear why the arrow and the circle in the center is counter clockwise.
  • I have my doubts if the portfolio canvas offers enough information to control the portfolio progress (maybe by adding post-its on projects in the ‘DOING’-area with impediments (e.g. end date not feasible).
  • I would suggest extending the portfolio canvas with a timeline at the bottom with milestones (changes, benefits). And make the picture clockwise to show movement of the portfolio (and remove or shorten the rectangular extension)
  • The developers explain that the portfolio canvas is based, among other things, on Kanban (Lean). I would like to emphasize this by adding a WIP-limit in the ‘DOING’-area (as an answer to a common anti-pattern of too many parallel in-flight projects).
  • Best practices like Management of Portfolios (AXELOS) or the Standard for Portfolio Management (PMI) suggest dividing the portfolio into different buckets or categories and prioritize the initiatives within these buckets or categories.
  • This could be facilitated by giving each strategic objective its own color and use post-its with the same color for the corresponding projects and programs.

Looking forward to your remarks and recommendations.

Review: PPM! Manage Your Organization Masterfully with Project Portfolio Management

6524736_463577During The PMO Conference Chris Garibaldi presented Deloitte’s Project Portfolio Management framework. After the conference Chris sent me a copy of the book he wrote in 2015 together with Jason Magill, Matthew Ku, Michael Ravin and Christopher Martin. In this post you find a review of this book: PPM! Manage Your Organization Masterfully with Project Portfolio Management. The document is divided into seven chapters explaining the value, the PPM framework, PPM maturity, PPM transformation, PPM implementation, PPM technology and their view on PPM’s future.

Chapter 1 explains the value of PPM, why do we need to have PPM. The value can be found in the following areas: portfolio alignment (doing the right projects), in-flight portfolio health (will the projects deliver value), business partner culture, and the gift of time (efficient PPM processes, management oversight).

The second chapter explains Deloitte’s PPM framework in detail. In the model, the PPM “Racetrack”, you see four primary capabilities: Demand Management, Project/Program Management, Result Management and Portfolio Management (Resource Management, Financial Management and Governance). All four capabilities complement each other through a cyclical flow of information.

Chapter 3 puts the PPM Maturity in the spotlights by using Deloitte’s D.MAP PPM Assessment Steps and Roadmap Development. The model starts with a current state assessment followed by a gaps and future needs identification resulting in a future state incremental roadmap. In the assessment the five capabilities (resource management is now seen as a separate one in comparison with the four capabilities of the PPM framework) are being analyses. Like many maturity models we see five maturity levels (initial/ad hoc, defined, managed, measured and optimised).

The PPM transformation is explained in chapter 4. Without organisational adoption of the PPM framework you will not get the benefits. Key are the people.They are the users, suppliers and benefactors of PPM. In this chapter the authors give you an oversight of concerns and perceptions of project managers and project participants, concerns from program managers and resource managers as well as requirements and conditions to be understood and supported by executive leaders. The chapter ends with some scenarios encountered by frustrated clients: heeding the dashboard luring call, sending a less-seasoned to do a senior leader’s job, you can worry about organisational adoption tomorrow, you just want something that comes out of the box, and ignorance is a bliss.

Chapter 5 describes what a PPM implementation entails by using a case study. The following steps are explained:

  • Implementation project leadership and sponsoring team;
  • Implementation work plan;
  • Organisational change;
  • Process and functional thread (using conference room pilots);
  • Deep technical thread.

In chapter 6 we get an eight step approach for a long-patch PPM tool selection.

The final chapter elaborates a little bit on PPM’s future, being self-evident due to the value it brings.

Conclusion

The document gives a good overview of Deloitte’s Project Portfolio Management framework.What I miss is some advice how to cope with business agility, many organisations are implementing permanent agile trams using scrum, kanban, devops etc. How to give the work these self organising teams have to perform a place in this PPM framework. This is at this moment also lacking in industry best practices like Management of Portfolios (MoP, Axelos) and The Standard for Portfolio Management (PMI). A comparison with these methods could be valuable too.

A first comparison from my side:

Deloitte’s PPM Management of Portfolios (MoP) Standard for Portfolio Management
Demand Management Portfolio Definition Cycle

Principle / Strategy Alignment

Process Groups: defining, Aligning

Knowledge Area / Portfolio Strategic Management

Project/Program Management Portfolio Delivery Cycle / Management Control Process Groups: Authorizing / Controlling

Knowledge Area / Portfolio Performance Management

Result Management Portfolio Delivery Cycle / Benefits Management Process Groups: Authorizing / Controlling
Portfolio Management Resource Management Portfolio Delivery Cycle / Resource Management Process Groups: Authorizing / Controlling
Financial Management Portfolio Delivery Cycle / Financial Management Process Groups: Authorizing / Controlling
Governance Portfolio Delivery Cycle / Organizational Governance

Management Principle / Governance

Knowledge Area / Portfolio Governance Management
Unclear if it’s covered by Deloitte’s PPM Portfolio Delivery Cycle: Stakeholder Engagement / Risk Management

Principles: Senior Management Commitment / Energized Change Culture / Portfolio Office

Knowledge Area / Portfolio Communication Management / Risk Management

To order: PPM! Manage Your Organization Masterfully with Project Portfolio Management

Where run and change the business from a portfolio perspective meet and integrate

If we look at traditional portfolio management, like MoP or SfPfM, the focus is on doing the right projects and programmes in the right way and delivering business benefits. These are temporary set-ups to help the organization to change. I would say the traditional change in the perspective of change the business and run the business. See attached figure 1 which shows the position of portfolio management in this traditional world according tot he MoP framework.

Dia3We see, more and more, organisations benefit from the fact to keep multi disciplined teams together to deliver more often and faster changes to existing products, systems and processes to accommodate business agility. These teams become permanent and will have their position in the organizational structure. This means these teams become part of the Business as Usual / Run the business environment. In this case, the work to be done, the functional changes, additions, regulatory changes etc. will be brought to these teams. The teams can focus on the development or become DevOps like teams. And this is a complete mind shift if I compare this with the traditional projects and programmes where the people are brought to the work itself.

I expect that the number of projects and programmes will decline because much of needed changes will be handled by these permanent teams. I don’t believe projects and programmes will disappear completely. For transformations, developing new product/market combinations, organizational and/or behaviour changes etc. we still need these temporary projects and programmes but after delivering, and closing these projects/programmes, new permanent teams can be established to maintain and operate the results. In these situations, we can still benefit a lot from frameworks like PRINCE2 Agile, AgilePM, MSP, RPM, and AgilePgM.

We see an enormous increase in the usage of agile delivery frameworks like Scrum by these permanent delivery teams. We also see an explosion of the number of these teams and this asks for a certain level of coordination between these teams. Delivery of specific changes may ask for orchestration between these permanent delivery teams. The usage of Scrum of scrums is not enough and new frameworks to help with this coordination are needed. Frameworks like Nexus and SAFe are developed to support this orchestration.

Like we had in the past, also for these permanent teams we need to prioritize the work to be done. At the lowest level, the development team itself, a product owner can do the prioritization, and if there are a few teams a group of product owners can discuss and agree about the prioritization among the teams. But when we have more and more teams there is definitely a need for portfolio management at the highest level. The SAFe framework contains a portfolio level to divide budget between different value streams based on the alignment with strategic themes. Within the value streams epics are prioritized by using backlog and using simple business cases or mechanisms like Weighted Shortest Job First (preference for those epics with the shorter duration and higher Cost of Delay).

As a result, we will have two portfolio management mechanisms. One for the temporary bigger one-time changes in the Change the business organization and one for the changes managed by the permanent delivery teams in the Run the business organization.

I would suggest to integrate these two mechanisms into one portfolio office. In figure 2 I changed the original set-up based on MoP and suggest to integrate the portfolio part of SAFe with MoP.

Dia4It still starts with Strategic / Business Planning. The Portfolio Office needs to be closely aligned with this strategy team. Based on the strategy there will be the understanding of strategic themes (SAFe) or categories (MoP). Here we also need to understand which value streams in the organisation are supporting the strategy. As a result, one or more permanent teams can be dismantled or added. In the traditional set-up portfolio management was only looking at Change the business and prioritized the work to be done by the Programme and Project Management organization. Now we see that also the work to be done by the Development / DevOps teams as part of Run the business needs to be prioritized. During the Understand practice (MoP) we will look at all traditional changes and Epics and categorize them across buckets for the traditional (temporary) world as well as the Backlog for the (permanent) world. Following the SAFe framework these Epics can be assigned to the corresponding Value Streams and within the Value Streams (outside the portfolio Office) to the corresponding Agile Release Trains and from there, via the Program Increment Planning meetings to the delivery teams.

I am looking forward to your ideas regarding this set-up. Many people are looking for Agile Portfolio Management. Maybe this article can trigger a discussion and as a result an outline of Agile Portfolio Management can be co-created.

The litte book of Portfolio Management

Last time I reviewed a set of six little books from NineFeetTall. This week I received number seven. The little book of Portfolio Management and a I got sneak preview of their newest little book which is not being launched until next year: The little book of Project Methodologies. This last one got my special attention because I am the author of the Lost in standards QRC.

The little book of Portfolio Management

littleThis book starts with some definitions, followed by the organizational context: Business as usual, the management board, business planning, programme/project management, information technology, finance, human resources and performance management. The next chapter describes how to define a portfolio, by using the five practices of the MoP definition cycle (Understand, Prioritize, Balance, Plan and Understand).

The next chapter focuses on the portfolio delivery, looking at reporting via a portfolio dashboard, benefits management, financial, risk, dependencies and resource management. The following chapter explains the portfolio health check. The last chapter describes the implementation of portfolio management.

The little book of Project Methodologies.

lb9This book gives insight in several project methodologies starting with definitions of a methodology, project management and a project management methodology.

The next chapters introduces the waterfall methodology and agile explaining the fundamentals, the lifecycle, the principles and the agile manifesto, the why using it as well as the differences between Agile and the traditional approach.

The following chapter goes into the best of the rest explaining DSDM, Scrum, XP, Lean development, spiral and critical chain. The next chapter is all about mixing and matching. How to combine Agile + waterfall or waterfall + lean, Agile + XP and Waterfall + Scrum. For some in depth knowledge I can recommend PRINCE2 Agile which describes a great tailoring model using an agilometer to combine an incremental approach with Scrum and Lean start-up. See: PRINCE2 Agile.

What factors (project type, business sector, organizational structure, skills, maturity and culture) are there to consider if you want to choose the right methodology is the focus of the next chapter. When does agile suit your project, when should you avoid using agile and when is waterfall the right choice.

Again two easy to read little books, full of simple checklists and tips, quotes, fact and figures and some great graphics.

You can order The little book of Portfolio Management for free at http://www.ninefeettall.com (*UK addresses only).

DICE, a tool for executional certainty

Dia1I received a mail from the Boston Consulting Group. Among other topics they highlighted their DICE tool to access and set up change initiatives. The DICE framework is a tool originally developed by Perry Keenan, Kathleen Conlon, and Alan Jackson (all current or former Partners at The Boston Consulting Group). By using this DICE tool, BCG claims that you can dramatically improve the odds of success.

In one of my previous posts regarding MoP practices in practice I already made a reference to this tool.

It’s a very simple tool to position your project on the DICE chart. Based on five questions you get an indication if your project is positioned as win, worry or woe. A project in the woe area is structured or guaranteed to fail. The tool gives suggestions for improving your DICE score. And of course it’s much more important to have a conversation about the scores and what you can do about it than only look at the final score itself!

Schermafbeelding 2015-08-14 om 15.13.30The DICE score (D + 2I + 2C + C2 + E) is based on:

Duration (D): Either the total duration of short projects, or the time between two milestones on longer projects

Team Performance Integrity (I): The project team’s ability to execute successfully, with specific emphasis on the ability of the project leader

Commitment (C): Levels of support, composed of two factors:

  • C1 visible backing from the sponsor and senior executives for the change
  • C2 support from those who are impacted by the change

Effort (E): How much effort will it require to implement (above and beyond business as usual)

1: copied from Wikepedia

In the embedded video from Perry Keenan you get an intro to the DICE tool.

If you go to the BCG DICE website you can get access to the DICE calculator, DICE FAQs and a library with the original HBR article The hard side of change management.

You will also find a set of small videos explaining the assessment of the DICE score, Duration, Integrity, Commitment and Effort and the setup of a DICE workshop and the DICE portfolio.

You will also get access to some related documents like:

  • A way to access and prioritize your change efforts (new HBR article about the DICE tool)
  • Leading change in turbulent times (about emotional turmoil that can drastically undercut the change effort)
  • Transformation: The imperative to change (Case studies of transformation excellence)
  • Executing Change beyond the PMO (from PMO to SIO: Strategic Initiative Office)
  • Strategic initiative management: the PMO imperative (The role of the PMO).

Conclusion: a simple tool, be accompanied by many relevant documents and videos. It is shared by BCG and can be very helpful in assessing your own portfolio and to trigger conversations about the focus in your portfolio and individual interventions for your most important projects!

MoP: Organizational energy

Dia1 It’s a good start to have your processes in place to accommodate the practices of the portfolio definition and delivery cycles. But you need more. If there is no commitment of senior management it will be a mission impossible to accomplish the portfolio goals.

Your staff must show involvement, looking for new opportunities, new innovations, willing to take decisive actions to solve problems because they want to work for a successful organisation, or in other words they must show productive energy.

MoP describes the energized change culture as one of the principles and sees this organization energy as the linking pin between the two portfolio management cycles. The energy is the “fuel” for change and performance.

Being successful is all about people and in that sense it’s a pity the MoP manual spends just a few pages on this topic. Searching on the Internet gave some interesting presentations and articles from Vogel.

Henley Business School/Vogel defines organizational energy as ‘the extent to which an organization (or division or team) has mobilized its emotional, cognitive and behaviour potential to pursue its goals.’

Dia50This article is divided into the following paragraph:

  • Intro
  • Portfolio management principle 5: Energized change culture
  • Organizational energy matrix
  • What is the energy state of your company?

To download: MoP (practice Organizational energy, 150515) v0.1

This article will be used in a new book MoP practices in practice, for portfolio managers who want to embed the MoP theory in their organization. In the coming months several blog posts and articles will be published waiting for your feedback. To see all, select the tag MoP_practices_in_practice.