the budgeting black hole: predicting the ... - agile alliance · the budgeting black hole:...

The Budgeting Black Hole: Predicting the Unknowable

Session Handout Agile 2011

Johanna Rothman William Rowden Rothman Consulting Group, Inc. SolutionsIQ

[email protected] [email protected]

www.jrothman.com www.solutionsiq.com

781-641-4046 206.551.9908

© 2011 Johanna Rothman jrothman.com of 12

Table of Contents Table of Contents.........................................................................................................2

Are You New to Agile? .................................................................................................3

Ideas Behind Incremental Budgeting............................................................................3

Project Portfolio Flow ..................................................................................................4

Programs vs. The Project Portfolio ...............................................................................4

A New LinkedIn Group .................................................................................................4

Johanna’s Thoughts About Iterative and Incremental Budgeting ..................................5 The Original Point of the Simulation .................................................................................................................5 Alternatives for Iterative and Incremental Budgeting...............................................................................5 Tips for incremental budgeting ...........................................................................................................................6 Traps of incremental budgeting ..........................................................................................................................7 Issues I’ll write more about in the coming weeks and months..............................................................7 Issues covered in the project portfolio book..................................................................................................7 Issues I’m not touching with a 10-‐foot pole, but other people are welcome to do so..................7 How Often Should You Review the Project Portfolio? ..................................................8 Project Cycles Depend On When The Project Can Finish..........................................................................9 Planning Cycles Depend on Your Product Roadmap Planning...............................................................9 Budget the Least Amount in a Budget Cycle................................................................................................10 Quarterly Cycles Can Challenge Some Organizations..............................................................................10 Rewind the Conversation ....................................................................................................................................10 Summary.....................................................................................................................................................................11 Acknowledgments ..................................................................................................................................................11 General Bibliography .................................................................................................12


Are You New to Agile? Although this session is for those folks who have been practicing agile for a while, it is the first day of the conference. If you are here and are wondering what the heck we are talking about, here is a picture that might help.

Figure 1:A General Picture of How Agile Works

Ideas come in through anywhere in the organization. A responsible person, sometimes known as a product owner, takes those ideas and creates a ranked backlog. A cross-functional team works on that backlog and regularly produces shippable product.

Ideas Behind Incremental Budgeting Attempting to budget for an entire year in advance is crazy, not because we can’t be trusted with the money, but because life—the business, the market, the projects—everything changes too quickly. Being able to react to change for money is just as valuable as being able to react to change for features or the schedule. That’s the point of this session.


Project Portfolio Flow Once you have the project portfolio, you can see how the budget can flow from the project portfolio. Here is a picture of the project portfolio:

Figure 2: The Project Portfolio Flow

Programs vs. The Project Portfolio I did not write much about incremental budgeting in the project portfolio book for two reasons: I hadn’t figured much out then about incremental budgeting and I was seeing incremental budgeting much more from the program (collections of projects) perspective.

A New LinkedIn Group I started a new LinkedIn group to move the discussion along: Please do join:

Agile Project and program portfolio management, http://www.linkedin.com/groups/Agile-Project-program-portfolio-management-4039946?

I am the owner. I will be sending the invitation to many agile groups, and to my contacts later this week. If you are interested, please join. Yes, incremental funding is a big piece of the discussion here.


Johannaʼs Thoughts About Iterative and Incremental Budgeting © 2011 Johanna Rothman

Too many of you are stuck with yearly budgeting. I was hoping we could explore iterating on the budget in this session. Ok, forget the exploration!

The Original Point of the Simulation Here’s what I thought/hoped would happen. You would try to predict something. How can you? It’s a new project. You can’t predict anything. You need experience. So you do one iteration. Based on your iteration/experience, you choose what to do with the project portfolio, including the budget. Now you do one more iteration, again assessing the progress you made. You make another prediction, based on your now two iterations worth of experience and your ability to re-jigger the project portfolio. Do the final iteration, count the money and see where you stand. Since we had multiple companies, we had a way to compare. You don’t get this at work. It was a laboratory experiment. Oh well. It’s too bad the simulation failed.

Alternatives for Iterative and Incremental Budgeting Here’s what I know right now about iterative and incremental budgeting.

Rolling Wave Budgeting. Try using rolling wave budgeting on your project/program: budget for an initial quarter. Based on your first month’s worth of iterations (if you use two-week iterations, that’s two iterations), predict your now fourth month’s budget using the data from your first month. Continue to refine the budget using the rolling wave.

If you think an initial quarter is too long, that’s fine. Start with a month, and extend by an iteration every time you finish an iteration. The key is to keep a rolling wave of budget, using the previous iteration as feedback. Quarterly Budgeting. Based on your first month’s iterations, (if you use two-week iterations, that’s two iterations), predict a quarter’s worth of budget. This differs from rolling wave because you are predicting an entire quarter in advance, without the frequent feedback.

Cone of Uncertainty. Start an initial budget with a cone of uncertainty, and every iteration, reduce the uncertainty. You’ve seen a cone of uncertainty budget with a waterfall—it looks just like the schedule cone of uncertainty, as in Figure 3. None of my clients has actually used an agile cone of uncertainty, so I don’t have one to share with you yet. All of them have either used a rolling wave or quarterly budget. So even though I offer you four options, I have only seen two used. (That’s why I wanted to explore the wisdom of the room!)


Figure 3:Budget or Schedule Waterfall Cone of Uncertainty

Three-point initial estimate plus one of the above alternatives. If you have done an initial project like this one before, consider using a three-point budget estimate like you would a schedule estimate: optimistic, likely, and if Murphy comes to sit on your project. Update your estimate every iteration or two, or update the cone of uncertainty or use rolling wave or quarterly budgeting.

Tips for incremental budgeting If you think of the budget like the schedule, you can substitute what you already know about schedules and plug budget into anything you already know about schedules/ 1. You cannot predict a budget when you have no data. That means that if you want a budget at the beginning of Sprint 0, you can want it all you want, but you can’t get it. You can’t get it at the end of Sprint 0 either, unless you use Sprint 0 to deliver running tested features. If you do use Sprint 0 to deliver running tested features, then you have a shot of using Sprint 0 as a predictor sprint. Otherwise, forget it.

2. You can ask your CFO/manager/whomever how early he/she wants to know when you know the budget will need to change.


Traps of incremental budgeting 1. An estimate is a guess and everyone should treat it that way. If everyone wants to treat the budget as a commitment, then don’t guess. Or, do what I used to do. “JR, what’s your budget?”

“5.” “5 with how many zeros after it?”

“How closely are you holding me to the budget? Are you going to base my performance review on the budget or do I have wiggle room? The more wiggle room, the fewer zeros.”

Maybe you can’t have that honest a discussion with your manager (why not?), but that’s the level of discussion you need to have. 2. If the managers don’t want to know the answers, they should not ask the questions. Sometimes, managers, CFOs, executives want a project to come in at a specific budget number that’s not possible to make. And, they still want the project. Look, you folks, if that project is that important, forget the budget.

Issues Iʼll write more about in the coming weeks and months When William and I asked you about your issues, these issues arose: How do I sell agile to finance?

How do I compete with traditional projects that provide an entire budget all at once? How do I help finance understand agile mindset and practices and how agile can help them? How do we budget large projects?

How do we budget early? How to influence management re points vs. money (the issue of what does relative sizing and money mean) Estimates are guesses and not predictions

Mixing financial models

Issues covered in the project portfolio book Capacity vs. wish planning

How to manage the project portfolio

Issues Iʼm not touching with a 10-foot pole, but other people are welcome to do so Tools for agile budgets and what-if scenarios


How Often Should You Review the Project Portfolio? © 2008 Johanna Rothman

You’ve got a ton of projects. You can’t do them all at once because you don’t have the people to do them. You know better than to ask people to multitask on more than one project—no one will get anything done. One tactic is to organize the projects into a portfolio and rank them by priority.

When most people slot their projects into a portfolio, they easily have 12-18 months worth of work. At some point—way before the 12 months is over—something happens and you’ll need to readjust the portfolio. You plan for the adjustment in a portfolio review, but how often should you review the portfolio? Too often, and you aggravate everyone involved, because nothing has changed. Not often enough and what’s actually happening has no relationship to the portfolio. Is there a just-right amount of time? Yes, and it depends.

You might need to review the portfolio when release dates change, when your customers want something new, when your competitors announce or release new products, or when new technology is possible. Because you can't control most of these events, you'll need to choose a flexible review cycle. But you do have ways to decide when is the right time to review the portfolio. The ideal time to review the portfolio is:

• When a project finishes (the project cycles) • When you have enough information about the next version of a product (the

planning cycles) • When it’s time to allocate budget and people to a new project (the business

cycles) These cycles are interdependent. Here’s a true story about how one group recognized the interdependencies. Leah, a product manager at ALargeCompany was talking with Alex, another product manager. “Alex, I need the development team to work on my product upgrade. When are they going to be done with your product?”

“Not for another three months.” “Wait a minute. You’ve had them for six months already. My product needs another release sooner than that. I have requests from our customers, and the corporate roadmap says I need to release in just three months. If they can’t work on my project, how can I get a release out in three months? What’s the delay from?” “Well, we had trouble getting the requirements done, so that was a delay. Then we had trouble with the functional specs. It turns out the requirements were still a bit vague, so we had to revisit everything during the spec stage. I insisted that they work on all the features at the same time, so the testers can’t start because nothing is done enough for them to test.”


Leah told me later she felt like bopping Alex on the head. Alex made several classic mistakes:

1. Thinking that his project was alone—not considering the rest of the portfolio in his planning.

2. Insisting on a serial lifecycle when there was a known time constraint for his project.

3. Not allowing the project team to implement and test by feature, so they could stop at some time, even if that time was not when the project would complete all the requirements.

If Leah and Alex had reviewed the portfolio more often, Alex would have avoided the first mistake, and would have had a chance to revisit the other mistakes earlier in the project.

Project Cycles Depend On When The Project Can Finish If your project takes longer than six months to complete, the project team can’t start work on another project until the first project is done. You’ll need to help the project team choose a lifecycle that fits your business requirements of when the project needs to finish. If you use a serial lifecycle, such as a waterfall or phase-gate, the project cycle is the entire duration of the project. If you contain the requirements, and the team is familiar with the product, and they don’t run into technical difficulties, and the schedule is short enough, you can make this lifecycle work for you. But too often, I see time-bound projects with high technical risk try to fit everything into a serial lifecycle for a project that’s more than three months long. That’s not a recipe for success. Instead, consider another lifecycle.

If you use an iterative lifecycle and integrate the product as you proceed, leaving only final testing for the end, your project cycle can be as short as the time it takes to implement one feature, integrate it and test it. If you use an incremental lifecycle, such as staged delivery, your project cycle can be as short as the time it takes to finish one feature. If you’re using an agile lifecycle, your project cycle is the duration of one timebox, not more than four weeks long.

So the more immature your product is, the more you want to consider an agile or incremental lifecycle, because you have the most flexibility in replanning the project portfolio. You might not care what kind of a lifecycle you use for a relatively mature product, assuming you don’t want to release it more often than once a year or so, and you don’t need that project team for other work.

Planning Cycles Depend on Your Product Roadmap Planning It makes sense to make your planning cycle, the readjustment of the product roadmap (which features you want in which quarter) be every quarter, especially for less mature products or for a market in flux. If you’re using an agile lifecycle, you can readjust the roadmap every timebox, fine-tuning which features the project team will finish when, and when you can release the product.


With an incremental lifecycle, you have almost the same flexibility as with an agile lifecycle, but you’ll have the project startup time, plus the varying time to complete a feature. For an iterative lifecycle, you’ll have to add in the time to add in all the prototypes for a given feature and test it. For a serial lifecycle, you’ll have to restrict the number of requirements you can address in one project.

Budget the Least Amount in a Budget Cycle In my work, I meet many companies who budget once a year. Everyone is supposed to pull out their magic wands and crystal balls and see the future perfectly.

Well, I don’t understand how to predict the future when I can’t tell what the competitors are going to do—and neither do my clients. The result is the managers and project managers spend crazy amounts of time forecasting the budget, and by the third month into the fiscal year, the budgets are all wrong. Since the budget is off in three months, it makes sense to use a budget cycle of three months—and only budget for three months at a time. If you’re using an agile lifecycle with a shorter timebox than three months, you can have a budget cycle as short as the timebox. A side benefit of re-budgeting more often is that you don’t have to budget everything—you just have to budget for the foreseeable future. You’ll spend less time budgeting and more time seeing just what you need.

An additional benefit is that for a non-agile lifecycle, the project team has to re-estimate how much longer they will need to finish the project. Too often, project teams have no idea how much time they need. If their estimates are off, they will gain feedback on their estimates and become better estimators.

Quarterly Cycles Can Challenge Some Organizations The problem with setting a quarterly planning and budgeting cycle is that you need your projects to deliver some finished set of features by the time you get to the review. Many organizations spend more than three months getting started on a project, which is quite common in waterfall or iterative lifecycles. Only agile lifecycles, with their short timeboxes and emphasis on finishing pieces inside the timebox can work with quarterly planning and budget cycles reliably. If you’re careful with an incremental lifecycle, you can make a quarterly planning and budget cycle work.

Rewind the Conversation After Leah and Alex learned about the different lifecycles, they replanned how they approached product management. First, they created quarterly product roadmaps, with a list of features for their products by quarter. They drafted requirements statements for each item in the list, updating the requirement as they learned more about the requirement.

They worked with senior management to define when senior management wanted to release the products, and developed a “desired” project portfolio. They also created an “as-is” portfolio, to show the current reality.


And, they worked with the project managers to make sure the project managers understood when they were time constrained and when they were not. Here’s a conversation from their monthly review meeting with the project managers: Leah started, “I emailed all of you our current portfolio and product roadmaps from Alex’s and my products. Let’s look at the second quarter. Senior management wants us both to release products in that quarter, but that’s not going to happen given our current portfolio. Senior management also said Alex’s product is a higher priority than mine.” Leah made a face.

“How do we resolve this?” Alex suggested, “If you two move to shorter timeboxes—certainly no longer than four weeks, and maybe two weeks—you can work on my product for the first part of the quarter, release it, and then go on to Leah’s product. If we run into trouble, we’ll know early because we’ll know what we finished and didn’t. We can update the portfolio and see what else we can do. How will that work for you?”

At the end of the conversation, the project managers had committed to three-week timeboxes and re-evaluation of both he roadmap and the portfolio at the end of each timebox.

Summary You’ve probably noticed two issues about the project portfolio. The first is that the portfolio provides a way to see the organization’s strategy. Making a portfolio, deciding which projects need to be completed when makes the strategy visible to everyone. The second issue is that each project’s choice of lifecycle has a huge impact on how often you can review the portfolio. I lean towards agile, or at the least, incremental lifecycles because they allow the organization the most flexibility. But those two issues are fodder for other columns.

Thinking about all these cycles bring us back to the original question: How often should you review the portfolio?

Review as often as you can and no more often. Consider working with the other project managers, the product managers, and the senior managers to organize your projects so you could release something at least once a quarter. You don’t have to actually release, but if your project is in a release-able state, you have the option of moving a project team to another project, satisfying the needs of the project portfolio. Then you’ll be able to review the portfolio and know you can make new choices about the work the organization is doing.

Acknowledgments I thank Dwayne Phillips and Gerald M. Weinberg for their review.


General Bibliography Hope, Jeremy and Robin Fraser. Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap. Harvard Business Press, 2003. Pfeffer, Jeffrey. The Human Equation: Building Profits by Putting People First. Harvard Business School Press, Boston, MA. 1998 Pfeffer, Jeffrey. What Were They Thinking? Unconventional Wisdom About Management. Harvard Business School Press, Boston, MA, 2007 Pfeffer, Jeffrey and Robert I. Sutton. Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management. Harvard Business Press, 2006. Rothman, Johanna. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Dallas and Raleigh, Pragmatic Bookshelf. 2009.

Rothman, Johanna. Manage It! Your Guide to Modern, Pragmatic Project Management. Dallas and Raleigh. Pragmatic Bookshelf. 2007.

the budgeting black hole: predicting the ... - agile alliance · the budgeting black hole:...

Documents