Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: portfolio management

Portfolio Management: Role of Autonomy

I’m a huge fan of Real Options. Along with Cynefin, it is one of the models that can be very universally applied in different domains. No wonder that some time ago I proposed application of Real Options as a sense making mechanism that connects different levels of work being done in an organization.

Simply put, potential work, be it projects or products, are options. We rarely, if ever, can effectively work on all the potential initiatives we have on our plates. That’s why we end up picking, a.k.a. committing to, only a subset of options we have.

Each commitment to start an initiative instantly generates a set of options on a lower level of work. Once we commit to run a project there are so many ways we can structure the work and so many possible feature sets that we can end up building. We again have a set of options available and again eventually commit to execute some of them. That in turn generates the options on a layer or finer granularity work items, say individual features. It goes all the way down to the most atomic work items we have.

We need an accompanying mechanism to close a full feedback loop between the layers of work. We simply need to provide information back to the higher level of work. Think of situations like a project taking longer than expected. We obviously want that information to be taken into account when we are making commitments on a portfolio level. Ultimately, it means that available capabilities have changed and thus it influences the set of options we have on a portfolio level.

Again, the similar dynamics will be seen between any of the two neighboring layers of work. Specific technical choices for features will influence how other features are built or how much time we’d need to make changes in a product.

The model can be easily scaled up to reflect all the layers of work that are present in an organization. In big companies there will be multiple layers of work even in the area of portfolio management only.

The underlying observation is that we very, very rarely need information to be escalated farther than between neighboring levels of work. In other words a single feature that is late will not affect decision-making process on portfolio level. By the same token commitment to start a new project, as long as it takes into account available capabilities, will be of little interest to a feature team involved in an ongoing initiative.

There is, however, one basic assumption that I subconsciously made when proposing this model. The assumption is about autonomy.

Work flows down to the finer-granularity level is through a commitment at a coarser-granularity level. The commitment, however, is not only expressing good will that we want to build something. If we make a commitment to run a project we need to fund and staff it. The part of the commitment is providing people, skills and resources required to accomplish that project within expected constraints, be it time, budget, scope, etc.

If there are other constraints that are important they need to be explicitly described once the commitment is being made. One example that comes to my mind would be around the ultimate goals for a product or a project. It can be about technical constraints – for whatever reasons technologies that a product will be built in may be fixed. Another common case would be about high level dependencies, e.g. between two interconnected systems.

Such constraints need to be explicit and need to be expressed when the commitment is being made simply because they influence what options we will have in the lower level of work.

There’s also another important reason why we want explicit constraints. When we move our perspective to a different level of work we also change the team that is involved in work. In the most common scenario the team context will change from PMO, through a project team to a feature team as we go down through the picture.

And that’s exactly when autonomy kicks in. Commitment on a higher level of work generates options on a lower level. What kind of options we get depends on the constraints we set. These are all prerogatives of a team making decisions on a higher level.

The specific choice among the available options, on the other hand, is responsibility of a team that operates on a lower level.

Obviously, we don’t want PMO leader to tell developers how to write unit tests. That’s the extreme example though and I see violation of autonomy all over the place.

Let’s start from the top. The role of PMO in such a scenario would be to pick initiatives that we want to run, a.k.a. make project- or product-level commitments. The part of the process would be defining relevant constraints for each commitment. These would be things like manning and funding the new initiative, sharing expectations deadlines, etc. This is supposed to provide fair amount of predictability and safety to the team that will be doing the actual work.

One crucial part of defining constraints is making the goals of the initiative explicit. What we are trying to achieve with this product or project. In other words why we decided to invest time of that many people and that much money and we believe it was a good idea.

And now the final part. Then PMO should get out of the way. Options are there in a product team or a project team. That team should have autonomy to pick the ones they believe are the best. Interference from the top will disable autonomy and as such will be a source of demotivation and disengagement. It is very likely that such interference would yield suboptimal choice of options too.

The pattern remains the same when we look at any two neighboring layers of work. For example, we will see similar dynamics between a product team and a feature team.

The influence on which options get executed happens through definition of constraints and not by enforcing a specific choice of options. Those different levels of work are, in a way, isolated between each other by the mechanism of commitment that yields options on a lower level, feedback loops going up and finally by distributing authority and maintaining autonomy to make decisions within own sphere of influence.

Unsurprisingly the latter gets abused fairly commonly, which is exactly why we need to be more aware and mindful about the issue.

May 4, 2016
Portfolio Kanban Board

One thing that I learned quickly when I started experimenting with Portfolio Kanban is that a classic, flow-driven board design isn’t particularly good in vast majority of cases.

Board Designs

Long story short, I ended up redesigning the board structure completely and it worked much better. In fact, it worked so well that I started proposing such a design as a starting point whenever working with portfolio Kanban.

Interestingly enough, as Kanban adoption of portfolio level progressed I started seeing completely different approaches to visualization. Not that they were worse. They just focused on different aspects of work.

One that popped up early was two-tier board that addresses different granularity of tasks at the same board. We can track the roots of this design to David Anderson’s time at Corbis. Since then it was picked up to manage portfolios.

Another example came from Zsolt Fabok, who was inspired by Chris Matts. What he proposed was a board that stresses expected delivery dates and how an organization is doing against these dates. Again the board design is completely different from the ones we’ve seen so far.

Another interesting example that I like is a portfolio board that visualized non-homogenous flow of work. This still is one of the most unusual board designs I’ve seen and yet it makes a perfect sense given the context.

By that time it was perfectly clear that there is no such thing as a standard design of Portfolio Kanban board. Each of these designs was fairly optimal if we considered the context. At the same time each of the boards was designed to stress a different aspect of work.

The design I ended up with in my Portfolio Kanban story revolved around available capabilities and commitments. The two-tiered board design focused on flow of coarse-grained items and breaking work down to fine grained items. The deadline driven board based on an assumption that the most critical aspect of work are delivery dates and monitoring delays. Finally, non-homogenous flow board design addressed the issue of different flows of work in each of the projects.

Which design is most useful then? It depends. To address that question we first need to answer which aspect of our work is the most important to track on a regular basis. To get that answer we need to discuss risks.

Risk Management

Obviously, risk management is a multi-dimensional issue. Some dimensions would be more interesting than others. The word “interesting” typically translates to the fact that we are more vulnerable to a specific class of risks or that we are doing especially badly against managing that class of risks.

A typical example in the context of portfolio management would be overburdening. We commit to more projects or products than we can chew. We end up having our teams juggling all the concurrent endeavors. As a result we see a lot multitasking, context switching, and huge inefficiencies.

In such a case the most interesting dimension of risks would be one related to managing available capabilities and ongoing commitments. And that would exactly be information that we’d like to focus on most when designing Portfolio Kanban board.

That’s by the way almost exactly the process I went through when I proposed capability-focused board design. Of course, back then the thought process wasn’t that structured and it was more trial and error.

There are some additional aspects of the story, like the huge variability of size of the projects that we typically see. This would affect the details of the board design as well. In this case relative size is visualized as well.

The most important bit is that we start with the most important risk dimension. This should define the whole structure of Portfolio Kanban board.

Coming back to different visualizations I mentioned we can easily figure out what was the key class of risks in each design.

In two-tiered board the biggest concern was smooth flow of coarse-grained items (feature sets). We can also figure out that variability in size of feature sets wasn’t that much of a problem. Given that we’re talking about product development organization and that they are in full control of how they define feature sets, it does make a lot of sense.

Delivery date driven board stressed how important risks related deadlines and timeliness of delivery were. We may also notice that there isn’t much stress on flow of work and not that much focus on addressing potential overburdening either.

The design with non-homogenous flow, as its name suggests, pinpoints that most important risk dimension was managing flow. On the other hand risks related to capability management and overburdening don’t seem so important.

Optimal Design

The structure of Portfolio Kanban board can show only that much. We can’t visualize all the risk dimensions using the board structure alone. David Anderson in his Enterprise Service Planning talk points that it is common that organizations track 4-8 different dimensions of risks. The board design can address one or two.

Make it the two that matter most.

Where would others go? Fortunately we still have items on our board, whatever we decide them to be. We can track information relevant for other risk dimensions using information on index cards. The design of the items on the board is no less important than the design of the board itself.

Designing Portfolio Kanban board is not an obvious task. We don’t even have a standard approach – something similar to a flow-based design we commonly use on a team level. Understanding how we manage risks is the best guidance that can lead to fairly optimal board design quickly.

Of course one alternative is to go through a trial and error process. Eventually you’d land with similar outcomes. A quicker way though is to start with understanding risks.

April 21, 2015
The Cost of Too Many Projects in Portfolio

I argued against multitasking a number of times. In fact, not that long ago I argued against it in the context of portfolio management too. Let me have another take on this from a different perspective.

Let’s talk about how much we pay for introducing too many concurrent initiatives in our portfolios. I won’t differentiate here between product and project portfolios because for the sake of this discussion it doesn’t matter that much.

Let’s imagine that the same team is involved in four concurrent initiatives. Our gut feel would suggest that this is rather pessimistic assumption, but when we check what organizations do it is typically much worse than that. For the sake of that discussion and to have nice pictures let’s assume that all initiatives are similarly sized and start at the same time. The team’s effort would be distributed roughly like that.

The white space between the bars representing project work would be cost of multitasking. Jerry Weinberg suggests that for each concurrent task we work on we pay the tax of 20% of the time wasted on context switching. Obviously, in the context of concurrent projects and not concurrent tasks the dynamics will be somewhat different so let me be optimistic with what the cost in such scenario would be.

If we reorganize the work so that we limit the number of concurrent initiatives to two we’d see slightly different picture.

Suddenly we finished faster. Where’s the difference? Well, we wasted much less time on context switching. I assumed some time required for transition from one project to another yet still, it shouldn’t be close to what we waste on context switching.

In fact, we can move it even further than that and limit the work to a single project or product at the same time.

We improved efficiency even more. That’s the first win, and not the most important one.

Another thing that happened is we started each project with the exception of the first one in presence of new information. We could have, and should have, learned more about our business so that we are better equipped to run another initiative.

Not only that. It is likely that technology itself or our understanding of technology advanced over the course of running the first project and thus we will be more effective building another one. These effects stack up with each consecutive project we run.

The total effect will be further improvement of the total time of building our projects or products. This is the second win.

Don Reinertsen argues that the longer the project is the longer the budget and schedule overrun. In other words, if we decided to go with all the concurrent initiatives we’d likely to go longer that we assumed.

In short it means that we do end up doing more work that we would do otherwise. Projects are, in fact, bigger than we initially assumed.

The rationale for that is that the longer the project lasts the bigger the incentive to cram more stuff into it as the business environment keeps evolving and we realize that we have new market expectations to address.

Of course there’s also an argument that with bigger initiatives we have more uncertainty so we tend to make bigger mistakes estimating the effort. While I don’t directly refer to estimates here, there’s an amplification effect for scope creep which is driven by overrunning a schedule. When we are late the market doesn’t stand still. To make up for that we add new requirements, which by the way make the project even later so we add even more features, which again hit the schedule…

A bottom line is that with bigger projects scope creep can get really nasty. With fewer concurrent initiatives and shorter lead times we get the third win.

Let’s assume that we’ve had deadlines for our projects.

What happens when we’re late? Well, we pull more people from other teams. Well, maybe there was one guy who said that adding people to the late project makes it later but, come on, who reads such old books?

Since in this case all our projects are late we’d pull people from another part of an organization. That would make their life more miserable and their project more likely to be late and eventually they will reciprocate taking our people from our future projects in a futile attempt to save theirs. That would introduce more problems in our future projects. No worries, there will be payback time when we steal their people again, right?

It’s a kind of reinforcement loop that we can avoid with fewer concurrent initiatives. That’s a fourth win.

Finally, we can focus on economies of delivering our products or projects. A common sense argument would be to bring time to market as an argument in a discussion. Would we prefer shorter or longer time to market? The answer is pretty much obvious.

To have a meaningful discussion on that we may want to discuss Cost of Delay. How much it costs us to delay each of these projects. It may translate to the situation when we don’t generate revenues or the one when we lose the existing ones. It may translate to the situation when we won’t optimize cost or fail to avoid new costs.

In either case there’s an economic value of delivering the initiative later. In fact knowing the Cost of Delay will likely change the order of delivering projects. If we assume that the last project had the biggest Cost of Delay, the first the smallest (4 times smaller) and the middle ones the same in the middle of the spectrum (a half) we’ll end up building our stuff in another order.

The efficiency of using the teams is the same. The economic effect though is vastly different. This is the biggest win of all. Including all other effects we roughly cut down the total delay cost by two thirds.

The important bit of course is understanding the idea of Cost of Delay. However, this couldn’t have been enabled if we’d kept running everything in parallel. In such a situation everything would be finished at the same time – at the latest possible moment. In fact, if we avoid concurrent work even the ultimately wrong choice of the order of the projects would yield significantly better economic results than building everything at the same time.

What we look at is a dramatic improvement in the bottom line of the business we run. The effects of limiting a number of concurrent initiatives stack up and reinforce one another.

Of course, it is not always possible to delay start of specific batch of work or limit the number of concurrent projects to very low number. The point is though that this isn’t a binary choice: all or nothing. It is a scale and typically the closer we can move toward the healthy end of it the bigger the benefits are.

March 4, 2015
Portfolio Kanban and Doing the Right Thing

There’s an ongoing discussion that I occasionally refresh with Markus Andrezak on usefulness of applying Kanban to manage portfolio and generally to the process of figuring out which products should be built.

What is Portfolio

One obvious thing that we can start with is focusing on a specific context. After all portfolio is a pretty loaded word and it is used in all sorts of situations. While my goal isn’t to boil down portfolio discussion to only few available options I see at least three distinctively different cases.

There are organizations that ore focused on project work. A typical gig they run would be a distinct initiative that is different form all the other initiatives they run. What’s even more important the revenue from that work would be connected to delivering work. This would be a project portfolio case. A classic example would be an offshore web software shop.

Then we have organizations that, similarly to the previous example, focus on building multiple concurrent and independent initiatives yet they would operate them as products by themselves. In other words they earn money by directly selling their software, or services provided by that software, to the end users. There’s no simple definition when the work is done. This would be a product portfolio case. A classic example would be a game development studio.

Then there is an alternative version of product portfolio where the whole company is focused on building a single product. In such a case the overarching initiative that everyone contributes to is obvious as there is only a single one. The discussion would happen between either specific goals to achieve or specific big scale functionalities to build. This would frequently be labeled a product portfolio too although for the sake of this discussion I’d go with a feature portfolio label, even if it isn’t precise especially for big organizations. A classic example would be a startup building what they believe is the next world-changing product.

Of course we can think of a mix of any of these scenarios and rarely only one of them will be pursued by an organization exclusively. What’s more we could go further with a differentiation within these scenarios. We’d see a completely different dynamics of project portfolio in a company that works under time and material terms than from one that build fixed price projects. A very different feature portfolio will be in a startup at an early phase which is still figuring out product-market fit that in an established company focusing on leveraging their user base or staying ahead of competition.

Where is the Problem

The discussion about applicability of Portfolio Kanban boils down to defining what is the most painful problem on a portfolio level in a given context. From that perspective there is a clear distinction between project portfolios and the other two scenarios. The difference is in the way revenues are generated.

In project work the more projects we finish the more revenues we can expect. With product or feature portfolio building software is only an intermediate step in order to generate revenues. In other words we know much more up front about return on investment in project portfolio scenario than we do in other two.

That doesn’t completely change the bottom line. In each case the choice on endeavors an organization works on is crucial for its long-term health. In each case overcommitment and too much work in progress on portfolio level can decimate the value of any ongoing work, no matter how carefully chosen. There are commonly mentioned reasons for that: long lead times mean long feedback loops and a lot of work in progress results in inefficient work.

There’s one more dimension that from my experience is at least equally, if not more, important. The constraints provided by work in progress limits change the dynamics of the discussion about starting new stuff, be it projects, products or major features.

Typically the discussion about economic feasibility of starting a new product or a project happens in isolation. If the ultimate problem that we are trying to solve is choosing the right initiatives to work on it should never happen in isolation. After all most of ideas we come up with make sense… in some context. An interesting question would be whether we are in such a context.

We may have a bunch of projects that we expect to be profitable. But which of them provide us most monetary and non-monetary value? How starting another one affects the ones that are already ongoing? Given a business hypothesis which we want to validate, which out of all possible experiments would generate most valuable information? Would starting another concurrent experiment obfuscate the outcomes of ongoing ones?

Of course we can say that each project will provide some value and each experiment will provide some learning opportunities. We don’t have infinite capabilities thus we need to choose.

Role of Portfolio Kanban

The way I look at Portfolio Kanban is that is addresses a very common issue of overburden at portfolio level and as a result it drives the discussion about what are the right endeavors to pursue. The latter starts happening when, thanks to WIP limits, we start saying no to new initiatives. What WIP limits create is they underscore available capabilities as a scarce resource. The next step typically is more careful consideration how these capabilities are put in the best use, which ultimately means a discussion about what is the right thing to build.

Obviously this dynamics is not true in all environments. Startups, especially at the early stages, will likely focus on figuring out what is the right thing to build without any external incentive. Organizations built around a single product, at least to a certain size, will naturally maintain discipline in strategy planning that will provide an answer what are the crucial product goals for them.

Beyond that it all gets fuzzy. If an organization gets big enough it has capacity to build multiple initiatives concurrently. Each product that grew far enough has a number of potential development paths it can follow and each of them can be promising on its own. If we talk about multiple product organization a temptation to follow a bunch of new goals at the same time is even stronger. And with projects it’s like an everyday issue.

Of course I don’t say that it’s not possible to start the other way around: nailing down the ultimate purpose, which may mean answering the Spice Girls question, and following up with defining what are the right features, products or projects that serve the purpose. This would likely mean that the number of concurrent initiatives will be limited as majority of activities would be optimized toward pursuing the purpose.

The problem is few organizations are ready to make this step just like that. And even when they are, there are still a lot of risks along the way. First, depending on how the ultimate goal is defined it doesn’t have to limit the options for what constitutes an attractive endeavor and we’re back to the square one. Second, even if the purpose provides enough focus there’s typically still plenty of options how to pursue the goal and thus overburdening portfolio is still a viable option. Third, and most importantly, in bigger organizations defining a single purpose may be impossible because office politics kicks in or there isn’t enough strategic leadership present.

In either of these cases as well as in the most common situation where there isn’t enough awareness to even start the discussion about the purpose Portfolio Kanban may serve as a facilitation tool. On the top of efficiency gains, similar to those seen in other applications of Kanban, it would catalyze the discussion about what is the right thing.

This is, in fact, the most important outcome of introducing Portfolio Kanban that I’ve seen.

What Portfolio Kanban Is Not

An argument I’ve heard a couple of times is that Portfolio Kanban doesn’t help to define what is the right thing to build or what is the ultimate purpose. I completely agree with this one. That answer simply isn’t there. Portfolio Kanban, pretty much alike any Kanban application, is a meta method. One shouldn’t expect to get context-specific answers.

If an organization is ready to look for these answers that’s great. Depending on specific context Lean Startup, Lean UX or other modern product management approaches may be relevant. That’s where awesome guys like Will Evans or Markus Andrezak kicks in with their expertise. That’s where Stephen Bungay’s work will prove invaluable, which Jimdo guys will happily confirm. That’s where Don Reinertsen would provide outstanding guidance for decision making.

In such cases, usefulness of Portfolio Kanban will indeed be limited. It will be mostly process improvement and efficiency stuff.

A common case wouldn’t be even remotely as rosy though. That’s why value provided by Portfolio Kanban typically go beyond the process stuff. It would still stop at introducing pressure to start important and difficult discussions. It wouldn’t provide guidance for that conversation. A good thing is that there would be more pressure the more screwed up the situation is. We can expect this catalyzing mechanism to exist continuously till we either solve the problem or give up on limiting work in progress on portfolio level.

If someone claims that Portfolio Kanban is supposed to provide more than that in terms of defining what is the right thing, well, we may be talking about different things.

November 2, 2014
Portfolio Management: Stop Starting, Start Finishing

Whenever I end up discussing project portfolios with people representing or knowing specific organizations out of curiosity I ask a couple of questions. How many projects? How many people running those projects?

Note, most of the time I don’t ask these questions in the context of completely random organizations. The most common case would be asking people who are a part of Agile and Lean community. People who understand the concept of limiting work in progress and its implications.

Disturbing news is that, even among the most mindful people, the answers I would get are pretty much shocking.

Kanban Leadership Retreat is an occasion to meet people advancing thinking for a community that painted limiting work in progress prominently on their banners. One would expect that these people, if not anyone else, would be ahead of the rest of the crowd in addressing the issue of too many concurrent projects.

Well, maybe we are. At the same time the ratio of a number of projects run by an organization to a number of people who work on those projects reported at the last Kanban Leadership Retreat in Cascais is terrifying.

1.0, 2.1, 4.5 and 6.0. Let me rephrase what this number is. This is how many projects per person an organization runs on average. In fact, it does mean that some people are in a situation that is much worse than that.

I didn’t gather that data in any consistent manner. I just asked my question any time the context would pop up in a discussion. It isn’t by any means proper research. It shows, however, a very interesting trend. The best result is a project per person, and we are talking here about an organization with a hundred engineers in this case. Few of those projects, if any, require attention of a single person only.

From that point though we go downhill. I can’t imagine any situation where a single person runs concurrently a few projects and they are at least a tiny bit effective. This means heavy multitasking for those initiatives that get any progress and lots of others where progress is nil. Effectively, they are parked even if management believes that they are active.

Let me repeat. It wasn’t reported by a random community. It is the community that calls their user group meetings Limited WIP Society. Not Visualization Society or Flow Society. Limited WIP Society. We do care. We do pay attention. Yet still, we do suck at that. Big time.

Larry Maccherone in his talk at Lean Kanban North America reported that teams that work on a single project are significantly better in terms of defect density. We can use that as a proxy for quality of work. It’s not anecdotal evidence. Larry bases his research on raw data from almost ten thousand agile teams.

By the way, Larry also reported that team size of 5-9 people is by far the most popular one. In other words, ideally, we should be looking as projects to people ratio of 0.2 and below. Of course it is contextual and shouldn’t be treated as the true north. In organizations that typically run tiny projects that require attention of 2-3 people such ratio may be unachievable. At the same time we do have companies that typically run huge initiatives that involve dozens of people.

In either case anything above 1 is obviously crazy. In fact 1 is crazy already.

We can’t make this possibly work.

The easiest way out is obviously reviewing the portfolio and putting on hold or abandoning a big chunk of ongoing initiatives. This would mean that the active remainder would get more, hopefully enough, attention so that these projects can be completed in reasonable time.

Sad truth is that I know such an expectation is unrealistic.

If we understand that potential projects are options that we can execute and once we decide to start them it means commitment we should also understand the consequences. Commitment means that there’s a price to be paid for abandoning an initiative. What’s more that cost isn’t easy to assess. How much would reputation of a company suffer for letting a client down? How much bad word of mouth would be triggered?

Another way is to go with the theme of Lean Kanban Central Europe conferences: stop starting, start finishing.

In other words make it hard to start new stuff. Discuss the cost and risks attached to adding one more thing to your plate. I don’t expect an explicit WIP limit. On portfolio level it is rarely a feasible option anyway. The strategy that you can use is WIP limits by conversation.

There’s not much guidance needed to shift these conversations to a broader context that is frequently ignored. It’s not only how much a new project would cost and how much we are going to get in revenues. It is also about available capabilities: can we staff a project appropriately for its whole lifecycle? What is the cost of delaying the project? What risks are we going to introduce by starting a new initiative both to that initiative and to all ongoing ones? And what is ultimately value of completing the project?

The value question goes way beyond simple financial outcome. In fact, it is a very deep discussion as one needs to understand the goals of an organization. Otherwise discussion about value is pretty much irrelevant. Also discussion about value doesn’t happen in isolation. Remember how hard it was to let down current clients breaking our commitments to them? Well, that’s clearly negative value for the company. If that’s the cost you pay you better have a damn good reason to do so.

I do admit that WIP limits by conversation is a concept that seems vague and fuzzy. However, given that people understand what is effect of too much of work in progress I find it a surprisingly powerful tool. It simply shift the focus of a discussion and thus influences how decision making process looks like. It is like a facilitation tool that helps us to use knowledge that we already have.

Then we stop starting and start finishing.

If we do that in a continuous manner we evolve toward more effective way of working. Not only does it mean fewer emergencies or better reliability but also choosing the right initiatives to run. It would be a nice situation to be in, wouldn’t it?

June 22, 2014
Evolutionary Change of Portfolio Management

There’s a fundamental flaw in how we manage project portfolios. What typically happens is we focus on estimated cost of work and expected profit. After all these are parameters that decide whether a project is successful or not.

Estimated Cost and Expected Profit

There’s whole ongoing discussion on how to estimate, when estimates give us value and whether we should estimate at all. A bottom line is that getting estimates right is extremely hard.

A problem is that, even if we got our estimate right, the scope of a project will change anyway thus it will affect the original estimate. Few companies would bother to change the estimates but even for these few there already are some numbers in contracts and budgets that won’t change anyway.

It seems that one of the critical numbers we use to make decisions about our portfolios is vague.

By the way if we are in the context of fixed price contracts it automatically means that the other number—expected profit—has changed as well.

It’s not a rare case to see these values changing drastically. I can come up with examples from my experience when, because of misestimate or increasing costs instead of margin of 30-60% the project ended up costing a few times more than the revenue a company got for doing it. Not only wasn’t it even close to breakeven but the company paid a huge toll in terms of both direct costs and lost opportunities.

A partial solution to that is transiting to time and material contracts where the revenue is a derivative of effort invested in building a project. While that definitely helps to avoid direct loses it doesn’t really fix the variables. The time span of a project can be changed thus the absolute numbers will be altered.

What You See Is All There Is

Even if we potentially could get our number right it wouldn’t really help. A root cause for that is a concept described by Dan Kahneman: What You See Is All There Is (WYSIATI). Human brain doesn’t look for data points other than those readily available. In other words if we define existing and potential projects from a perspective of estimated cost and expected profit these will be the main, or even the only, inputs for decisions on starting new projects.

This has very sad consequences. In neither case we assume that in normal circumstances we will be working on unprofitable ventures. If we are in the world of fixed price contracts the final price will directly depend on an initial estimate.

We’ve already discovered one painful dependency between an estimate and a profit. While costs are changing the contract terms remain the same affecting profits. It is even worse than that. The price was calculated based on the same estimate most likely by multiplying it be a factor of expected margin. Unfortunately humans are crappy at estimation.

And don’t even get me started about all those dysfunctional situations when there’s a pressure to reduce an estimate because a client has a limited budget or something.

In either case, a picture of all the potential projects will be rosy. We won’t allow it to be different than that. We will tweak the numbers back and forth until they fit the rosiness of the picture.

The ultimate issue of this is that, because WYSIATI kicks in, our decisions about starting new projects will be overly optimistic and heavily biased toward perceived attractiveness of our endeavors. A simple fact that it has very little to do with the real outcomes of projects or our appalling track record with assessing attractiveness doesn’t change it. What you see is all there is.

Overcommitment and Multitasking

The end result of this bias is easy to predict. Since all things seem to be overly attractive we tend to start too many projects. Eventually, and pretty soon, we are overcommitted beyond the point where we can comfortably finish everything before agreed deadlines.

Even in the cases when a flash of sanity keeps us from jumping off the cliff and stop one step before there’s usually not nearly enough slack in the system to account for any emergency that would happen.

Of course there’s no plan whatsoever in case our initial estimate was wrong and we need more effort to finish a project, because we’ve proven to be perfect estimators in the past and never got anything wrong. Oh, wait…

What does happen next? Expediting of course. When heroics within a team is not enough we pull people from other teams just like there was no tomorrow and they weren’t doing meaningful work on other committed projects. Anyone wants to guess what happens in the projects that we cannibalized to save the other one?

More of the same vicious cycle.

Not only such work is ultimately inefficient but it also hits sustainability of the business as it damages relationships with clients.

Informed Decisions

To reverse that cycle we need to go to the first place, the point of commitment, and change the drivers that influence our decisions. Bearing WYSIATI in mind, what we need is access to meaningful bits of information.

We need to know how our current commitments affect our capabilities over time. In other words we want to know which teams are working on which projects. Not only now but also in reasonable future. What reasonable future means will of course vary depending on a context.

How would a new project fit available capabilities? Do we have people with the right skills and knowledge available? When are they available? How much slack do we need to be able to respond to uncertainty in existing endeavors?

We need to know, at least roughly, what is Cost of Delay for new projects. Is it possible to delay start of this project for a month? How about longer? What kind of costs, or lost future gains will it incur?

What is value of a new endeavor? Is it money that earn only? How about long-term relationships with a client or bringing more financial safety thanks to a steady flow of work?

By the way, when we are talking about value, it is crucial to remember that value for our organization doesn’t equal value for a client. Of course, the more aligned these two are the better, but it’s almost never an ideal fit.

What are the risks attached to a project? How sure can we be about all the assumptions we make?

These are all crucial factors that we should be taking into consideration when making a decisions about starting any new project. If we don’t have them at hand, as a result of WYSIATI, they will be ignored and we’ll be back to our rosy, overly optimistic and utterly harmful view of portfolio.

Bad news is that to do better we need pretty broad understanding of the mechanisms that drive us sideways. Good news is that once we know that the change isn’t that painful. Focusing on different kind of data will alter decision making process on a portfolio level.

May 28, 2014
Portfolio Management: The Search for Value

I am talking about the cost of multitasking pretty frequently. This discussion gets even more interesting when we are in portfolio management context. Why? It is so because we are dealing with extremes more frequently on that level.

Cost of Multitasking

Let’s imagine a situation when a software developer is dealing with three tasks concurrently. We know that it isn’t efficient. It may be based on our knowledge how multitasking affects our work but it may as well be our intuition.

Now, would we have the same intuition if we changed the context and we were discussing a team working concurrently on three different projects? Interestingly enough, we’d be looking for arguments why in such a context it isn’t that much of a problem. Stuff like: part of the team would work on one project and another part on another project. Sounds familiar, doesn’t it?

Thing we typically forget about is how team members would interact with each other. They wouldn’t think of themselves as of isolated sub-teams. They will be frequently looking for colleagues’ help thus they will make other people switch projects for a while every now and then. Finally, we have the coordination effort that has to done. Who is working on what, what is the status of everything, etc.

This gets even worse when the distribution of people across the projects isn’t fixed. Then people would be thrown to one or the other initiative depending on the current situation. Why is it costly? Zeigarnik Effect describes that we, as humans, have intrusive thoughts about stuff that we left unfinished.

In other words, if I change a project but I haven’t wrapped up my part in the current initiative I will likely be interrupting myself thinking about the old tasks. In fact, I don’t need any external factors to incur the context switching cost to my work.

There’s more than just efficiency penalty though. The teams that are working on more than one project deliver lower quality results, as Larry Maccherone points in the results of the research run across thousands of agile teams.

Cluttered Portfolios

Things get even more interesting when look at the big picture – not a single team but all the teams within one organization. It’s enough to ask two questions. How many teams are there? How many active projects or initiatives are run concurrently?

The answers with the ratio in a range about 10:1 (ten projects per team on average) aren’t uncommon. It means that our forces are spread very thin, the coordination effort is significant and the frequency of people switching projects is fairly high.

Another question may be: what is the percentage of people assigned to more than a single project?

Either way, in some cases we’d find that not only do we have more projects than teams but also we have more projects than people working on them. Some extreme examples I know of would show that there are 4 times more ongoing projects than there are people available to work on these projects.

How efficient is that?

No reasonable person would do such a thing on purpose. Yet, this is happening pretty often.

Project Attractiveness

If we assume the goodwill of people managing project or product portfolio, there must be something wrong with the approach we typically use to manage the portfolio. Let’s think for a while data we use to inform our decisions on starting new initiatives.

Obviously we know the client and, at least roughly, the scope of the project. On that basis we come up with the idea how much the project would cost and what revenue we can get out of it. How do we do this? Well, we estimate.

One problem is that, as Daniel Kahneman points, we are biased toward the most optimistic scenarios. Another one is when we do these estimates. Johanna Rothman phrases it:

If you fall for estimation as your way of valuing projects in the portfolio, you are doomed to fail. Why? Because you are trying to predict the cost or the date when you know the least about the project.

Typically, we base on insufficient data and use our flawed estimation skills to come up with the measures that are supposed to help us assess value of projects. That doesn’t sound like an extremely useful approach if you ask me.

The problem is that pretty frequently that’s all we have in our toolboxes: an unreliable total cost estimate and expected income based on that very estimate. If we are really lucky we can say a bit about high-level risks too. However, if nothing else is in place the only application of risks assessment on this stage would be tweaking the income expectations so it includes potential screw ups.

All in all we end up looking at projects through attractiveness glasses. It’s all about how much profit we can potentially earn doing this or that project. Given that we model income on expected total cost almost all of the projects will look reasonably profitable, thus all of them will be considered attractive.

There’s a pattern our brain follows, called What You See Is All There Is (WYSIATI). It basically says that whenever we are judging something we take into consideration only evidence that we have at hand and omit data that we could potentially gather to inform our decisions better. In other words, if what we see is cost and profit we won’t automatically be looking for other data points that can tell us something about value of the project. We will just do our judgment on information we have at hand.

If we put WYSIATI on the top of our limited and unreliable data almost every initiative would look appealing. It is no surprise that we end up with heavily overloaded portfolios.

Where Value Is

The question we should be addressing is not the one about expected profit, but about expected value. The problem is that the latter is more difficult to answer. On different occasions, during my presentations, I’ve had a chance to ask audiences whether they know what the value of features they build for their clients is. Few people do.

We simply don’t think about our products and projects in such terms. Even when we do though, it solves only a part of the puzzle. One oversimplification I often notice is that we boil down the discussion about value to the users or clients only. The problem is that both parties will define value differently. Let me give you an example.

At Lunar Logic we build web applications for our clients. We can build a product for a client that delivers valuable features in a predictable fashion. We can even help the client shape the product so we avoid the non-value adding functionality. The client would be happy – they’d got what they define as value. At the same time though, the client may simply be a toxic person who would make the team’s life miserable. Now, on our end, depending on a situation, it means that overall value of such a project may as well be negative: we would have gotten the money (one aspect of value) but lose a part of the team (another aspect of value). It is likely that the former wouldn’t compensate for the latter.

I don’t have all the answers for the questions about value. The cases when I’d disagree with how our clients define value aren’t rare. On my end, while I can say what we value as the company, sometimes it is very difficult to assess value for initiatives we undertake. It’s not as bad as it looks though.

We don’t need to define value in absolute numbers. If the goal is to improve the way manage portfolio most of the time we will need to answer only relative questions, e.g. which project is more valuable given the criteria that are important in a given context?

In fact, the most valuable outcome of the discussion will not be the exact assessment. It will be a discussion itself as it will likely cover the areas we typically ignore, thus will yield in the better understanding of the situation.

It won’t happen though unless we understand the limitations of our decision-making process on a portfolio level. Otherwise we will keep doing even more of the same thing make our teams even more inefficient and miserable.

December 13, 2013
Multitasking Teams

There’s one question I ask pretty frequently during my presentations or trainings: do you think that context switching comes for free? I’m yet to see a single hand up after the question.

Not that I believe that this is universally accepted point of view. In fact, there is a follow-up question which is: who has a boss who thinks that context switching comes for free? I do get positives for the latter.

I’d also assume that some people, even if they believe in free context switching simply wouldn’t raise their hands. Peer pressure, you know.

I’m happy with the assumption that awareness of costliness of context switching isn’t ubiquitous and definitely there are different assessments of how costly it is exactly. Still, I’d say that basic understanding that we pay a context switching tax is pretty common.

After all, it oh so obvious to predict how texting on the mobile while walking through a crowded street is going to end. Or playing Angry Birds while driving. Or driving, having a call, lighting a cigarette, overtaking another car and shifting gears, all at the same time (a true story; I’m glad that the passengers made it alive).

It gets a bit less obvious when it comes to our workplaces. On occasions you’d hear things like “do it in the meantime” or “can’t you work on both of these things concurrently?” (Sure, I can. As long as you want both of them to be late, that is.)

The real fun starts on yet another level though. Concurrent projects. When we aren’t discussing individuals but teams and not atomic tasks but projects, suddenly the assumptions that concurrent work on them doesn’t hurt becomes surprisingly common.

The reasoning is that one team member will be working on one project and another team member on the other project. I’m always astonished that this thinking pattern is there even when there are more projects than team members… Anyway, let’s assume the situation is not that dramatically bad.

There is still a problem of multitasking on a few different levels. First, there’s planning and coordination. Who should do what for how long? Even if team members typically do have comfort of being able to focus on a single thing there are people on the team who constantly switch context between all the projects that are run.

Then, there’s regular communication. Typically ad-hoc communication can be a distraction. We willing pay the price for the distractions because we get value of those discussions. They are relevant for people because they touch the matter of the project they run. Well, as long as it is about the project they run. That isn’t necessarily true if a team run a few projects.

Finally, there are situations when people would change the context of the project even if we don’t plan they would. What happens when someone is stuck? They’d ask for help. Whom? The person who is likely to help them. Does it mean only people from the same project? Not really.

Obviously we’d get some of that even if a team works on a single endeavor, but such cross-team interactions are usually way less frequent, thus way less costly, than those within the team.

This is sort of a gray area that is often forgotten even in organizations that are aware of the cost of multitasking. This is one of the reasons why visualization of project portfolio is so important. Each case where a team is coping with a few different projects or products at the same time should at least spring a discussion, as this is an obvious inefficiency.

Multitasking on a team level is no less painful than on any other.

November 12, 2013
Options, Options, Options

I think the first time I’ve heard that we should consider that a project backlog is simply a set of (unexercised) options it’s been from Ellen Gottesdiener It took me some time though to translate this, otherwise attractive, concept to something more down-to-earth in my own context. The catalyst in this case was one of Kanban Leadership Retreat sessions that covered portfolio management.

Let’s imagine a company working on multiple projects. The organization size may vary, but let’s make it at least a couple hundred people strong. Such a company would have a bunch of project in progress but will also continuously work on selling more work to keep the business running.

Every now and then, one of ongoing projects will get finished. What typically happens then is the company has some free capabilities. At the same time sales department is busy closing the deals. If the organization is extremely lucky and we are living in a fairy tale the pace of project completion will be exactly equal to the pace of new project arrivals.

I have bad news though. We don’t live in a fairly tell. It’s even worse – most of the time we are not extremely lucky either.

What typically happens is one of two things: there either are some free capabilities and no work that can fill this gap or the opposite – there is more work that should be started than can be handled with available capabilities. In fact, the situation dynamically changes from one to the other and back again.

I want to focus here on a scenario with more incoming work that can naturally be absorbed by the org.

One, sadly very common, approach is taking whatever comes from sales funnel and then pushing hard to make it fit, no matter what available capabilities are. Guess what – wishful thinking that people would handle more concurrent work doesn’t work at all. Conversely it only makes the problem worse as it forces teams to multitask which never comes for free.

We can do better, can’t we?

The opposite approach would be taking available capabilities into account and committing only to whatever the organization can handle. In other words it means saying no to some of available projects.

It is like treating every incoming project not as a commitment by default but as an option. Well, it seems we have options again.

So let’s picture our portfolio backlog as a bunch of options.

Now, what happens when we start a project? Let’s keep it consistent with the Ellen’s concept. We fill the project backlog with a number of options. Except this time the options are more fine-grained. We may build these features or those features. Well, odds are we will build them all eventually, but the order is kind of important here.

By the way, I’m yet to see a project where the scope doesn’t change. This basically means that every time we decide to build a feature we exercise an option of building this very feature while keeping the options of building other features still open.

The option backlog will get replenished on occasions while we discover more and more details of the project. It will live and evolve the same way as our portfolio option backlog is alive and changing.

The interesting part here is that commitment on one level (launching a project) springs a bunch of new options on another level (features or stories).

In fact we can take this model even further. Once we as a team commit to build a feature we generate a bunch of options to build the feature in this or that way. We have an option to write tests. We have an option to write tests before the code. We have an option to write acceptance tests. We have an option to review code and so on. At the same we also have options to implement the feature in a few different ways functionality-wise. Some of them will be mutually exclusive, some of them won’t.

Basically, starting work on a feature springs a handful of options on yet another level of granularity.

If you imagine that building stuff in the company is happening on a few different levels – each of them dealing with more fine-grained stuff – this model will work throughout the board. Commitment on a higher level generates options on a lower level.

In fact, you can take the model way beyond the three levels I proposed here. For organizations that deal with product lines, programs and stuff it will be the same. There always is a commitment to more high-level stuff before we choose how to do low-level items. There simply will be more layers to take into account.

That’s why considering backlog as a set of options seems so attractive to me. It’s not only about a project or an iteration backlog. It’s about any backlog on any organizational level.

What’s more, having the Real Options theory at hand we may use the model to manage the stuff we build wiser. Again, it doesn’t matter whether we think about managing portfolio, prioritizing features or deciding on implementation details.

“Don’t commit early unless you know why” may as well apply to launching a new project or getting more work in progress than we really need to have. And knowing why should include understanding of all the costs attached. The bit that is too often forgotten.

September 23, 2013
Portfolio Visualization

I’ve been lucky enough that throughout my career I’ve had occasions to work on different levels: from personal (that’s pretty much everyone’s experience, isn’t it?), though team and project to program / PMO / portfolio level. Not only that. In most of my jobs I’ve been involved in all levels of work concurrently. This means I’m schizophrenic.

Um, actually this means that I’ve been pursuing goals that require focusing on different granularity of work.

Granularity of Work

Let me give you an example from my company – Lunar Logic. If I have to complete a task to close a new deal for the company, e.g. to have a call with a potential client, that’s a personal level. It is something that has to be done by myself and it involves only my work. Most of such stuff would be rather straightforward.

At the same time I run a project where I’m supposed to know what’s happening and for example share my estimates when the work is supposed to be finished with the client. That’s a different kind of work. I mean it’s not only me anymore – there’s a team. Also there are a lot of dependencies. Unless bugs are fixed we don’t ask a client for acceptance, this task has to be finished before the other, etc. Of course, tasks will be bigger – we don’t want to run 30-minute long tasks through our task or Kanban board. At least not as default.

Then there is whole effort of coordinating different projects run in the company. It is about understanding which are about to be finished making people available to work on something new, how we can cover for unexpected tasks, what kind of free capabilities we have, etc. At this level a user story or a feature is meaningless. We’re talking about big stuff here, like a project here and a project there.

Depending on what I do I may be interested in small personal tasks, user stories or whole projects.

Actually, there may be more than just three levels of stuff. It is a pretty frequent case. Imagine an org that employs a few thousand people. They will have teams, divisions, projects, programs and product lines. On any level beyond personal there will be a few different granularities of work.

There may be a user story as the smallest bit of work that a team gets done. It would be a part of an epic. The epic would be a part of one of these huge thingies – let’s call them saga stories. Sagas would build up a project. A set of projects would make a program. The program will be developed within a product line… Complicated, isn’t it? Well, I guess it’s still far from what Microsoft or Oracle has.

Focus

Now, the interesting part. On every level leaders are likely to be interested in understanding of what’s going on. They will want to visualize stuff that’s happening. Wait, what that “stuff” is exactly? I mean, haven’t I mentioned at the beginning that work items that interest me may be very different?

Um, yes. However, in each context, and at any given moment, there’s only one granularity of work that will get my attention. When I wear a hat of a company leader I don’t give a damn about a user story in a project XYZ. I just want to know whether that project is progressing well, what are the major risks attached to it and how it can impact other projects and our available capabilities.

When I go down to wear a hat of a project leader, I’m no longer interested in timelines of other projects. I have project tasks to be finished and this is my focus. Scope of risk management would be limited to only a single project too. This means that I will be paying attention to a different class of risks.

Then I go even further down to wear a hat of a leader of my own desk (not even a real one) and granularity of stuff changes once more.

Good news is that vast majority of people don’t have this switching dilemma – since they’re always working on the same class of stuff there’s always the same level of work that they pay attention to. Always a single level.

Well, almost…

Second Level

One level of stuff will always be a primary focus. In many cases there will be a secondary focus as well. It will be either one level up or one level down. For example, when I was a team leader my primary focus was the features we were building. However, on occasions I was going down to development tasks and bugs to understand better the progress we were making. Not that I needed the view on all the development tasks and all the bugs all the time – it would make information cluttered and less accessible. Sometimes I needed that data though.

Another example. In my previous job I led more than a dozen development teams. Obviously user stories or features were far beyond my focus. My primary area of interest was projects on PMO level. I was expected to juggle projects and teams so we build everything on time, on budget and on scope (yeah, right). Anyway, the atomic unit of work for me was a project. Occasionally I was going a level up though, to program management if you will. After all, we weren’t building random projects. Teams had business knowledge specialization. I had to take it all into account when planning work.

You can think of any role out there and it’s very likely that this pattern will be true: main focus of one level of work and possibly secondary focus on work that is either happening a level up or a level down. The secondary focus is likely to be sometimes on but sometimes off as well.

Why is this so important?

Visualizing Work

My work around Portfolio Kanban and discussion on the topic made me thinking of what we should be visualizing. Of course it is contextual. But then, again, in any given context there is this temptation to see more. After all, given that we visualize what’s happening with the projects, it’s not that hard to visualize the status of the epics within these projects. And of course we definitely want to see what’s happening on program level too…

No, we don’t.

Again, in any given role (or hat) you have only one primary area of interest. If these are projects, focus on them and not on programs or epics.

Otherwise the important bits of data will be flooded in all the rest of information that is needed only incidentally, if ever.

Portfolio Visualization

For whatever reasons we get that intuitively most of the when we manage work on a team level. I rarely see task or Kanban boards that attempt to map the whole universe (and more). Maybe it is because we typically have some sort of common understanding what an atomic task on a team level is.

At the same time we go on a project level and things get ugly. I mean, what is a project anyway? For one person it will be a Minimal Viable Product (MVP), which is smallest increment that allows verification of a product hypothesis and enables learning. For the other it would be defined by a monolithic scope that is worth 200 man months of work. And anything in between of course.

Unless we remember the rule of focusing on only one level of work, any meaningful visualization of that work would be impossible. This is one of the reasons why visualization in Portfolio Kanban is so tricky.

Instead of creating one huge wall of information and throw all the different bits of data there, think about your primary focus and deal only with this. And if you keep switching between different roles no one forces you to stick to a single board.

Right now I’m using portfolio board, personal one and a bunch of different project boards. For each of them, there is just one level of work visualized. So far I never needed to combine any two of them or put stuff from one at the other. It seems that even for such a schizophrenic guy as me the single focus rule applies as well.

August 28, 2013