Key takeaways
|
The book Diving For Hidden Treasures - Uncovering the Cost of Delay in Your Project Portfolio by Johanna Rothman and Jutta Eckstein explores how projects become delayed and provides tools and methods to analyze and limit the costs of delay in projects.
InfoQ interviewed Rothman and Eckstein about why estimating value is so difficult and what's the alternative, if there is still room for solving defect or refactoring code when we focus on delivering value, the concept of cost of delay and an example of cost of delay due to indecision, and techniques that can be used to rank projects on value. InfoQ also asked for advice when organizations want to shift from being focused on costs and effort to focusing on value that can be delivered.
InfoQ: Why did you write a book about the cost of delay in project portfolios?
Eckstein: At Agile 2013 in Nashville I ran into Johanna in the hallway. Unfortunately we had been scheduled against each other, so she asked me about the session I just delivered. It was on ‘Complex Projects aren’t Plannable but Controllable’ (compare to: Planning and Controlling Complex Projects). I explained her very passionately how we keep asking the wrong questions to the wrong people – how long does it take (and/or how much does it cost). Even planning poker asks the same thing, just in a different way. We both rapidly agreed that these questions don’t help at all and we decided on the spot to present a session jointly on that topic in the year after.
Rothman: We had both been talking about project portfolio management for several years. We were dismayed that so many people wanted to try to use estimation of duration/cost or ROI to evaluate projects. We had decided to work together on a session for Agile 2014.
To do that session well, we needed to write essays/posts about the Cost of Delay. Once we had all of them, we realized we had a short book that would help people understand what CoD might mean to them.
InfoQ: Who should read this book?
Rothman: If you are trying to value something: a backlog, a product roadmap, and especially the project portfolio, you should read this book. If you are trying to articulate why you should flow work through teams, you should read this book.
Cost of Delay explains so much about why we don’t get the right product out at the right time.
Eckstein: Continuous delivery and DevOps seems to be the topic of the day - which is great! We have put so much energy in getting better in delivering and by doing so overlook that we lose most of the time at other points during development. So everyone who wants to know how to find out where the time is lost should read this book.
InfoQ: Why is estimating value so difficult?
Eckstein: Estimating value is also harder than focusing on cost only, because a system provides a different value from different perspectives. Let me give you two examples.
When talking about value, we typically look at what value it provides to the customer. Now if you have a product in the market, different customers might value different things. And moreover, sometimes these different values contradict each other.
Now the second example expands on that – when looking at value we typically look at what value it provides to the known customers. Yet, maybe we found out via A/B testing that we could increase our market share if we develop completely different features.
So different perspectives – from this versus that customer’s point of view, or from existing to potential customers’ point of view provide a different estimate of a feature’s value. And be assured, these were only two examples of different perspectives on value.
Rothman: In my experience, people think the value is the cost. That’s why people use project estimates. For software, that’s project cost.
The problem is that value is so much more than cost. Sure, if you can release a short project and get revenue in a month, that might be worth it. But what if you worked on a different project for three months, and got a 10x revenue from it? What if that first project had no revenue expectation after an additional three months? Which project makes more sense? To me, it’s the second project.
You see this in the games and taxes industry all the time. The games companies have to have their product in the stores by October, or they don’t get enough reviews/word of mouth for them to sell enough for the holidays. And, if they miss that date, there might not be any point in releasing that game this year. The holidays are so important for revenue, the companies have to hit their release dates.
In the US, we see this same behavior for tax packages. If you don’t release by Jan 1, you lose the market for this year. That’s a huge problem.
When you think in terms like these, you can see the cost of a project is not the same as its value.
InfoQ: What's the alternative, should we stop estimating projects?
Rothman: Estimation can be helpful if you want an order-of-magnitude guess. I wrote a book about estimation (Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule) where I provided several approaches for how to estimate. The problem is that most managers want the One Right Date, not the range—which is what good estimators should provide.
Eckstein: Well, estimating the value of a project is still estimating projects. And once you know the value it is often also helpful to know the cost in order to make up your decision if you want to do the project or not. However, the difficult (and as well the nice) part here is that especially in software we are very flexible in adjusting the cost to the value by coming up with a cheap or more expensive solution.
And just to be clear on that one --, I’m still a fan of planning poker. However, for me planning poker was never so much on estimation but on creating a joint understanding about what to build. So planning poker (or something the like) is more a vehicle for shared knowledge creation and as such I think it is still important.
InfoQ: Please elaborate why it's important to differentiate between a target and a goal when estimating costs or effort?
Rothman: When project teams have a target, they realize they need to finish features to make that target. When they have a goal, they might “wander” around features. In my experience, goals can expand. Targets keep teams grounded.
InfoQ: If we start to focus on value delivered, how about solving defect or refactoring code, is there still room for that?
Rothman: Of course. Will that problem solving or refactoring help you release future features faster? That’s an excellent way to use CoD. I see this a lot in teams new to agile. They have tremendous test automation debt. New Product Owners want features, features, features! When you explain in terms of CoD that they can get more features when the team has a support system of automated tests, they can make better decisions.
Eckstein: Yes, I certainly agree – technical debt can create a huge cost of delay and so refactoring for many teams mean that they reduce their cost of delay (although it might not look like that at first glance).
InfoQ: Can you briefly explain cost of delay?
Eckstein: I always like to give the definition Johanna came up with: “It‘s the way to think about the revenue you can lose plus the cost of continued development.”
Rothman: The cost of delay is the cost you incur from not releasing at the time you want. You move the release date out in time. One consequence is that you not only delay incoming revenue, you incur the cost of less revenue. The back-of-the-napkin cost of delay is to estimate your revenue curve over the product’s lifetime. Now, take the delay you have. Remove the revenue from that period of time from the maximum revenue. That’s your Cost of Delay
InfoQ: In the book you explored cost of delay due to indecision. Can you give some examples of this?
Rothman: My favorite is this one. One of my clients had a senior management team who had trouble deciding which projects to fund. They waited too long to decide. Then, they would ask the teams to deliver in much less time than the project required. The teams always started feeling behind. When people feel behind, they might incur technical debt (by design or by default). These teams took intentional shortcuts. That made their next project in this area take longer.
I explained to the management team about the effects of their actions. Instead of waiting until six months before they wanted a nine-month project, I suggested they either decide earlier or decide on shorter projects. That allowed the teams to deliver a quality product and not incur technical debt, release faster, and not incur management debt (the lack of decision-making).
InfoQ: Which techniques can be used to rank projects on value, and decide on which ones to do now, later, or never?
Eckstein: I have used a variation of planning poker where all people involved sat together. Like in regular planning poker, we “voted” for one project after the other yet, whenever one number was assigned to a project it wasn’t allowed to reuse that number for another project.
Rothman: I like the approach I suggest in Manage Your Project Portfolio Decide on the principle behind your decision (the why), discuss the what (which projects when), visualize the work so you can see what’s happening, and move projects to a parking lot if you don’t want to discuss them anymore.
I like the Commit/Kill/Transform approach to the project portfolio. Commit to a project and flow projects through standing teams. Kill the projects that no longer fit. Transform those projects you want in some form, but not their current form.
InfoQ: Can you give advice when organizations want to shift from being focused on costs and effort to focusing on value that can be delivered?
Rothman: Ask questions about the value you will receive from this project. You might expect a quick win in the market from a particular project. You might get lucky and get that with very little effort, that project might make some sense to do. In my experience, luck rarely occurs.
Especially with agile, we do valuable work first. Why not do that with the project portfolio?
Eckstein: As Johanna says asking questions is important. So “just” asking the involved parties what value they think this project/feature will provide works. Because, sometimes the term ‘value’ is strong enough in order to change the discussion. Yet, sometimes it isn’t enough. Then I shift the discussion by looking at different elements of the value which are i.e. the expected ROI and savings, the risks implied, the benefits for the user and our own business, then of course the existing CoD (e.g. technical debt) which might reduce the value, and last but not least our willingness for the investment. And although this makes value crisper it implies the risk the discussion is then focusing too much on the details. That’s why I prefer to ask about value without giving a definition what value exactly is.
About the Book Authors
Jutta Eckstein works as an independent coach, consultant, and trainer. She focuses her work enabling agile development on the organizational level. She has helped many teams and organizations worldwide to make an agile transition. She has published her experience in her books 'Agile Software Development in the Large', 'Agile Software Development with Distributed Teams', 'Retrospectives for Organizational Change' (see http://www.infoq.com/articles/retrospectives-organizational-change), and together with Johanna Rothman 'Diving for Hidden Treasures: Finding the Real Value in your Project Portfolio'. She is a member of the Agile Alliance and a member of the program committee of many different European and American conferences.
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna is the author of more than ten books, including: Agile and Lean Program Management: Scaling Collaboration Across the Organization, Project Portfolio Tips: Twelve Ideas for Focusing on the Work You Need to Start & Finish, Diving for Hidden Treasures: Finding the Value in Your Project Portfolio (with Jutta Eckstein), Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost See more of Johanna’s writing here.