Steve Player

I'm Steve Player. I'm the director of the Beyond Budgeting Round Table here in North America. My company: Live Future Ready.

My cohort is Nevine White. Nevine is our executive in residence. Nevine came to us from TW Telecom, where she was the head of FP&A for 20 years, the last 10 of which she ran a public company's planning function without any budgets. So those of you who say you can't run a company without budgets, stay out of the way of the people that have already done it, okay?

And Nevine's one of those people. So I'm very excited to have her here with us, and she's able to answer any of your questions about what it was really like. That's the reason I'm happy to have her here.

She's going to jump in and talk about the TW Telecom case study. This is a company that, in 2004, eliminated their budgets, and she'll talk to you all about that. We'll come back later on, and I'll talk about the Beyond Budgeting principles, and we'll talk about cost reduction and some of those things.

So, Nevine, you want to take it away?

Nevine White

TW Telecom was a publicly held, fiber optic-based, business-to-business telecom provider, a niche provider. And at $1.6 billion, probably a gnat in that industry in terms of the sheer size and scale of some of our competition.

But we prided ourselves on our customer experience, and we were extremely foresightful in terms of some of the things we did, and also some of the things we chose not to do, because there are certain things that sank many, many companies along the way, especially in the early 2000s, that we avoided because of some of our very forward-looking and innovative strategies that our executive team put together.

As Steve mentioned, in 2004, we eliminated our budget process primarily because we found two big problems with it.

One, it really didn't help do any kind of risk mitigation for the firm, because it was all made-up numbers. Most budgets consist of basically negotiated, made-up numbers. And so it really did nothing for our executives in terms of giving them any kind of good roadmap in terms of what was really out there, opportunities we could take advantage of, risks that we should avoid.

So much so that the frustration culminated in the CFO taking our lovely, beautiful, telephone-sized budget book that we created and chucking it in the trash can in front of me, going, "Figure out a different way to do this."

So I came up with the, "Ugh, we're just not going to do them anymore."

Instead, we moved to a very dynamic rolling forecast process, and it really drove business agility into our entire organization long before Agile was cool, in terms of at least the rest of the business. Because while our IT department was starting to go there for all kinds of other reasons, the rest of the organization really didn't have that mindset.

The two things we knew pretty well were that our budgeting process sucked, and our change management sucked worse. But from those things, we learned, and we adapted, and we moved on.

And we were at an interesting time that we were coming up on, because telecom and where we started as a business was really a hard-infrastructure process. So we dug up streets, we laid down fiber optic cables, we connected buildings. We had customers, everything from Mary Jo's Flower Shop over here, which basically had very simple telephone service, to very sophisticated high-end customers who had IT departments bigger than our entire company. So we ran the gamut in terms of the services we provided, but it was all still based very much so on hard assets.

In the mid-2000s, telecom started... Our CIO called it Telecom 2.0. That's where that term came from. But it really started becoming very software-centric, and the marketplace really shifted from having that asset, that fiber in the ground that reached the network, the mileage to go with it, which we still had and could leverage, but it was moving up in the stack in terms of the capability.

And so our IT department was becoming a much more critical part, not just for providing our ordering, billing, back-office systems, but really providing very much so customer-facing systems.

The company and our technologists actually developed a platform that was called Dynamic Capacity, where from an IT director's cell phone, they could upscale the capacity of their pipes just by pushing some buttons, to two and three times the capacity instantaneously. It was really cool. Even I, as a finance nerd, could appreciate the coolness of this technology they were building.

But what that looked like from a company perspective was that we had to figure out how we didn't become an obstacle in all this cool innovation and technology that was going on.

So part of this was really for us as a finance organization to understand what our friends in IT were doing, and that was a very difficult process, because I didn't speak IT no more than they spoke finance. It took a while and a lot of collaboration and a lot of very sincere conversations to really get us talking to each other.

But the nice thing that came out of that is that we aligned our planning process, not exclusively because of their needs, but it so happened that it meshed together really well.

We moved to a true quarterly rolling forecast where we actually did our planning every 90 days, a two-week cycle. We gave people two weeks, but I know from our system log that the vast majority of people did it in two hours. And we significantly reduced... You see, I know something about system logs because I would go spy on people.

But we significantly reduced the level of detail that was required to really just the most relevant things. We shifted from doing everything on a pure project basis that was approved and sort of locked in on January 1st for the entire year to very dynamic funding approval. We actually approved capital projects on a weekly basis.

But for our IT organization, we aligned our capital approval process with the way they were structured. So they had development teams that basically had the ordering system, the billing system, our production systems, our telemetry and monitoring, our trouble ticketing systems. And so we aligned our capital funding process with those systems on a quarterly basis.

It gave them a lot of flexibility in terms of if they had to move teams around because there was more stuff going on in billing this month than there was in ordering, and they had to move testers or whatever were there, we would close one project short and just let the other one run over. But at the end of the day, they had a finite capacity of how many developers they had, so it still worked, and it still met the requirements that we had as a finance accounting organization to close those projects to assets.

Even though we had a weekly approval process for capital projects, so if something happened, like a server blew up or whatever, they could come and request replacement on a weekly basis. We typically funded the IT processes for about a quarter at a time, so they had that flexibility to move their sprints and their teams and everything around within those constructs that we had set up and established. So that worked really well.

The thing that got really interesting is when they started doing this really cool Telecom 2.0 development, because it was like, "Okay, great. We've been doing this for 10 years. Let's figure out how we get together and do a business case."

"This is something nobody's ever done before."

"Okay. Well, what's the closest thing we can think of that looks like it?"

"This is something that nobody has ever done before."

"Okay. So how much time do you think it's going to take you to figure this out?"

"Nevine, this is something nobody has ever done before."

So after a couple of those kinds of conversations, we then figured out how we could effectively create what we call a skunk works. I know that's not an original term, but that's what they called it, to really do some of this very interesting development.

And the conversations we were having were around this idea of how much money is the organization willing to invest in this testing, experimentation, R&D-type stuff, that if we know if it doesn't turn into anything, this is basically a write-off. How much money are we willing to put over there?

And we managed that in the context of the entire capital portfolio. So as we were looking at our resource allocation, we managed a certain amount of our capital for our customer deployments, because we were still building fiber optic cables and putting on networks because all this cool whiz-bang stuff, you have to have that infrastructure to layer it on top of.

So we were still doing some of that. So we had that. We had technology obsolescence that had to be dealt with. And then we had our investments in the IT infrastructure and keeping-the-lights-on stuff, and then we had all this new cool stuff.

So we managed as a portfolio. We figured out how much of this we could carve out for them to have that sandbox to play with, relative to everything else that was happening. Now, those were prioritization conversations, and they were painful because my friends over in IT still wanted all their toys and everything else.

It's like, "No, we can't do that. We can afford this much. If you want to have the sandbox, figure out whatever else."

I know sandbox means something else to you guys than it does to me. That's where my kids play, but I get it.

And so if you guys want to have this, we have to figure out how else we're going to shift some things, because we have a financial capacity constraint.

The nice thing was, because we'd been having a lot of collaborative conversations, and they were starting to understand what I was saying, and I was starting to understand what they were saying, that we were able to get to this conversation about constraints, and one of them was the financial constraint.

You have this many people working for 90 days. That's this much money. That's all we can afford. So you can't add 10 more people, and you can't do X, Y, or Z. And in this quarter, you have to live within these constraints.

And it became a very positive, not punitive, a very collaborative conversation. And everybody, because we're all working for the same business trying to do really cool stuff, everybody understood that. And so it started to become very much so a conversation of give and take.

We also grew up very quickly as an organization and learned this idea that you don't hoard money. Just because you've been given it, if you know you're not going to use it, give it back so we can put it towards something else.

And the more everybody saw the benefit of doing that, as in being able to do some other things and do some experimentation, play with it, we grew up as an organization around these ideas of constantly being able to bring funding back so we can redeploy it for other things that were a priority.

So that is the overview of what we did at TW Telecom. I can tell you from a success perspective that what they did, what they developed, ultimately led to the acquisition of the company, because we were a very successful, cash-rich company. And so the intellectual property they created actually ultimately resulted in the acquisition. And so that company is no more, sad to say.

But it was extremely successful. The fact that we changed our planning processes to be that dynamic resulted in the last 10 years of our existence in us delivering 40 consecutive quarters of top-line revenue growth, in an industry that's extremely tough. And if you do the math, that includes 2008, 2009, when everybody was just having a terrible time. We had revenue growth throughout all those years.

That gave us an incredible amount of benefit, and a lot of it is because we gave people the flexibility and the ability to really do their jobs. So this can be done. This is not just an academic concept. We really did this, and it was extremely successful.

And so, funny story, I'm sitting in the hotel room yesterday, working on thinking about how I'm going to talk to you, and my phone rings. So I'm like, "I wonder who this could be?" And it so happens, it's the guy who ran our IT department.

Because I'd reached out to him and said, "Hey, guess where I'm going to be going? I'd like to talk to you a little bit about your perspective of our Agile initiatives and my finance lens on it, and just make sure what I'm telling is the way you'd see it."

And he was just like, "God, I wish we could have that back." He's like, "Where I work now, it's not that it's bad, but the budget is killing me."

I was like, "I'm really sorry. I get it, but I'm really sorry."

So it was a very fun conversation just because I hadn't connected with him in a while, but it just kind of reminded me about some of the very incredibly cool things that can be done if you kind of start breaking those silos down and engaging those organizations beyond just the ones that are in your immediate purview.

I thought it was interesting yesterday at the opening keynote how they were talking about how many developers there are and how many sort of ancillary, like QA and other kind of people around that. Well, think about that in broader terms. How many other people really help support your initiatives?

And I would argue that finance can be a really valuable partner in that conversation, but you have to make the effort to bring them to the table. You have to make that effort to really engage with them and help them understand what you're talking about.

We're actually pretty smart. It's just we don't understand the language you're speaking.

As I said in the last session, swarming to us is something bees do. Scrum is a rugby thing. You guys got to understand that we don't speak your language no more than you speak ours. So it's the coming together. It's really reaching out and spending some time teaching a partner in the business how they can help you be better, because actually, that's what we like doing.

My team was probably the most engaged, most innovative finance team I've ever had the privilege to work with because they learned so much. They knew all about IT and telecom and products and technology and services and customer-facing stuff and sales processes.

They were such subject matter experts because we pushed them out in the organization and let them learn, and they loved it. And so it's not that the finance people don't want to talk to you. They just don't speak your language.

So I would encourage you to take some time to do that and make that effort. Now, we have a bunch more slides in this deck, and it's really kind of at your discretion about where you want to go with this conversation, so we're willing to take questions.

And I see a bunch of hands jumping up, so why don't we do that? And then if we need to reference some of the other slides, we can absolutely do that. So go ahead.

Q&A

Q: Would you describe that breakthrough moment between finance and IT? How did that conversation sound like? What are the things that IT professionals can bring to that conversation to foster or to urge that moment to happen?

A: So we found common ground in the sense that there's a lot of things we actually want to achieve in the same way. It's just we go at it from different angles. And so for us, we found a lot of common ground around understanding metrics.

As we moved to forecasting, we got less and less hung up on the actual financial aspects and really much more interested in the operational metrics that were driving the financial results. Because you can't change the dollars, but you can change what causes the dollar to happen.

And we figured out that if we could be friends with you, you could show us where in the system that data resides and actually help us make sure the data is clean and accurate. And so we connected in a couple of different places where we found common grounds of things we were actually trying to achieve together, but were coming at it from different ways.

So we got very collaborative. One of my favorite stories to tell is, after we kind of got over ourselves and broke those walls down and started talking to our friends in IT, I had our operations, the woman that was in charge of our IT operations, call me one afternoon. She goes, "You need to come over here. I need to show you something."

I went, "Okay, fine."

So she was in another building where our data center was, and it was not very far away, so I drove over there.

She's like, "Come with me." She walks me into a room, and it was just like a nondescript room. She opens this door in the back, and there's literally... This was in the early 2000s, so the flat screen wasn't a thing yet, right? So there were literally floor-to-ceiling, these massive boxes of monitors standing there.

I'm like, "Okay. So tell me."

She's like, "So this is what happens when you force me to spend my budget."

Oh.

"Because it was December and I had money left, and I knew if I didn't spend it, you were going to take it away from me. And so now I have 47 monitors sitting here that I'm hoping enough people will break theirs so I can actually deploy them because they're sitting here, unsecured inventory. It's basically in a room with a key that I have, but anybody could get in there if they want."

And so it was breaking down those kind of walls and having those kind of conversations and being able to trust each other that that isn't going to turn into something punitive. It becomes a very important part of that whole conversation.

It's really about speaking each other's language. She suddenly understood that was unsecured inventory. Before, that would not have even come to pass.

You had another question there.

Q: Were you publicly traded at this?

A: Yes.

Q: And was this all of your budget or just like an R&D?

A: Everything. We eliminated budgets for the entire organization.

Q: So the follow-up, sorry. So my limited understanding is you need to be able to forecast and kind of telegraph what you're doing for the next--

A: You actually don't legally have to.

Q: Okay.

A: As most organizations do, but our management team chose to not give guidance. The only thing we would tell the Street was, on an annual basis, roughly how much capital we would invest, and it was a range. It was like, we were going to invest between $300 and $400 million in capital.

We didn't give them quarterly earning guidance, because our management team believed that that really narrowed the scope of what they were able to do, because they were very forward-looking people and they didn't have an exit strategy. And so they, from the very beginning, decided they were just going to irritate Wall Street and not tell them.

Q: I'm getting that.

A: They all run their own models anyway. It's not like they really need us to tell them what's coming.

Q: Does that impact your stock price?

A: Nope.

Steve Player

This is a good area, though, for when you hear something and somebody says, "Oh, we have to give earnings guidance."

Well, show me. Show me where in the regulations. Show me in the SEC about it. It's not there. It doesn't.

Now, slightly more companies give earnings guidance than don't give earnings guidance. The trend is away from giving guidance, and if you give guidance, you just give annual guidance or quarterly guidance, not both.

Now, the one argument I've heard, because I've tested this, the one argument I've heard for giving guidance came from Walt Galvin, the CFO of Emerson Electric. And he said, if you're a thinly traded stock and giving guidance keeps analysts tracking your stock, analysts tracking stock is worth 500 basis points in your cost of capital. That's the only logical argument I've heard for giving guidance.

The downside on giving guidance is when your management team gives guidance, they're making an earnings projection. And I ask any of you, how good are you at predicting the future?

I've spent the last 20 years looking for somebody that's really good at predicting the future. I was real excited the day Tiffany's planning department was coming to one of our meetings. I thought if anybody would have a crystal ball to predict the future, it's Tiffany who'd have it. They'd have a crystal ball.

So it's not about predicting the future, and the trap of earnings guidance is your management team predicting the future. And so if they're doing it, make sure they understand the real peril they run, because what happens is, if you don't give earnings guidance, the analysts are still going to predict what your stock's going to do. They're all making their own predictions.

So you'll still have a number to hit out there, what the analyst average composite estimate, what they think you should do. Okay? But if you miss it, they were wrong. You weren't. Okay? Yeah, you'll have to deal with it, but if your management team gives guidance and you miss it, who's at fault?

The management team. So there's a real peril in giving guidance. So the people that have got away from it don't want to go back in terms of what's out there. But it's not legally required by the SEC or anybody like that.

Q: What brought your CFO to that aha moment?

Nevine White

I think he was really tired of dealing with budgets.

In the fall of 2003, we were in telecom, right? So we had gone through the dot, "I'm an ISP in my garage" recession where everything kind of imploded, and the whole telecom industry had way overbuilt capacity. So we had just lived through that, and our management team, being very foresightful, had also skirted the entire DSL conversation and didn't get into that market.

But they decided we needed to build some runway and move forward. So their burning platform was we need to generate organic growth, right? So that's what we need to do.

So they put that out as a message, sort of as a cover message for the budget in the fall of 2003, and it came back with a budget that was so incredibly bloated with wish-list items. It was ridiculous. It was absolutely ridiculous.

Three iterations later, we still weren't anywhere near reality. And as a matter of fact, it was the IT meeting that he got so frustrated in that he finally just said, "I'm not going to any more of these. You figure it out, put the budget together for the board, and we'll just go from there."

When he came back from the board meeting, he had had this epiphany, probably on the plane coming back. It's like, "This is a piece of crap. Find me something better." And he threw it in the trash can.

So I was like, "Okay. I think I can find something better. Google, what do you do when you're not supposed to do budgets?"

And up popped the Beyond Budgeting book. Right? And then I figured from there how we could transition. And it was me doing a lot of this because I didn't know exactly what was going to happen. All I knew is my mission was not to do any more budgets. And so I kind of figured this out.

Steve Player

But Nevine did that in 2004. Okay? The Round Table was new to North America. We only launched here in 2002 after it started in the UK in '98.

Okay? Since 2004, we've got a lot more implementations, a lot more case studies, a lot more material that we can share with you. We previously, in the previous presentation, had the books that we've written and the discussion. We can cover.

So there's a lot more evidence, if you will, of people who are doing this, a lot more conversations, a lot more folks you can see, a lot more CFO Magazine cover stories. So the word is out in the finance community that there are some people doing it an alternative way.

Finance people, if you haven't figured it out yet, are extremely conservative. Okay? When you say a rock and a hard place, they're usually hiding under the rock. Okay? So it will take them a while to get comfortable.

But let us help you show them the language and show... The CFOs know, in most cases, the budget's full of fiction. It's full of assumptions, and assumptions that you're going to get wrong both ways. You're going to be too high or too low, depending on what's going to happen to the economy.

The CFO can't predict any more than anybody else can. So in that kind of world, is there a better way? And that's what we've been able to find, is a better way to plan, to set targets, to do all the different things budgets try to do. We can pull that budget apart and find different ways to tackle each one.

Q: So if you come from an organization that is really the antithesis of what you're describing, where there's yearly planning cycles, everybody freezes the budget. It's really counter DevOps, it's counter Agile. And in the absence of an epiphany moment like you described, are there any baby steps from a finance perspective you might suggest?

Nevine White

Well, I still think a conversation with your fin--

Audience: Can you repeat it?

Sure. He was asking about if you don't have an insightful CFO or an epiphany moment like I described, how can you still move forward in terms of starting even with some baby steps.

And I would say having a conversation with your finance counterparts and helping them understand what you're trying to accomplish, which is actually really cool, I think. But helping them understand that and what it is that are your constraints in terms of how you're running into the wall all the time because of some of the budgeting.

I think that starts opening a dialogue, and there might be some constructs you can create even within the framework of a budget that'll allow you to do some things that are better aligned with how you're trying to fund your teams and move your processes forward.

Steve Player

But you're trying to fund those teams and move them forward to respond to what the business needs is, right? You're trying to move the business forward.

The business doesn't run on an annual cycle. It runs incrementally. And opportunities pop up, and you have to respond to them and so forth. So you're trying to free up to be able to support the business, who wants to free up. Well, the finance needs to free up, too, to be able to have a planning model that follows that.

So begin to look for different ways. The poor man's way in is forecasting. All CFOs will tell you, even if they won't believe in budgets, they all think they should be doing a better job of forecasting. So the forecasting is the Trojan horse.

The reason Steve Morlidge and I wrote Future Ready: How to Master Business Forecasting is how do we get to do a better forecast? Well, most forecasts are done very poorly. And most forecasts look like mini budgets because they always have this bend back to the target.

If you're forecasting and you're just going to the end of the year... When I say rolling forecast, a lot of people say, "Yeah, we do that."

And I say, "How far?"

And they say, "Well, it depends on where we are during the year."

And I say, "Okay. Does that mean nine months out? In the first quarter, you forecast nine months. Second quarter, you forecast six. Third quarter, you forecast three months."

That's forecasting to the wall. All that's doing is not really forecasting about visibility. It's just revalidating the budget target.

When you only ask at the end of the year, what you're really saying is, "Are you going to hit your target? Are you going to hit your target?" And everybody knows what the answer to that needs to be. Because if you say no, I'm going to give you some help from corporate. Okay? So people won't even tell you the truth.

So move to a rolling forecast. Go out at least more than a year. Go 15 months, five quarters, six quarters. Put a rolling forecast in, and then that begins to show you.

And make it a light-touch, driver-based rolling forecast. Not something that automatically comes back to the target, which is where you want to go, but something that just says, if we don't change anything, this is where the ship's going to go. It's going to be high. It's going to be low.

And based on where it's going to go, what do we do about it? If it's low, what countermeasures do we need to be thinking about to bring it up? If it's too high, what investment opportunities does it give us that we could be redeploying?

So put that in easily, start that, and get the rolling forecast going. If you get the rolling forecast going, you get ready to do that big, laborious, onerous budget part, it just says, "Well, couldn't we just use that third quarter forecast? It tells us where we're going. It goes all the way through the end of next year. Why don't we just grab the..."

So the Trojan horse is do forecasting, get it up and rolling, and then you'll come around and you say, "Do I really need to do the budget?" And let that work just fall away.

And lots of times, we've seen that kind of change by stealth mode be an interesting one to approach, because you're trying to find out why they were doing budgets, and then you give them a better way to do each one, and you let that thing just disappear. And you come around, and you just leave it behind. You just, "Well, we didn't need to do that this year." And away you go.

Q: Thank you.

A: Yes.

Q: So one of the so-called benefits of waterfall is that go-live, asset introduction, and then capitalization is easy for finance. In Agile, I'm assuming you guys went to Agile with your IT department then?

Nevine White

Yes.

Q: How did you solve for that when they're delivering stuff every day or every two weeks?

We funded them on a quarterly basis. Like I said, they had work streams. So they had an ordering, billing, trouble ticket, whatever all that system infrastructure was, and we funded that labor force for that team for a quarter.

And then however many releases they did, however much labor was actually incurred, we closed that off at the end of the quarter. So it wasn't at the end of the project completely in production. It was every quarter we closed it.

Q: So you would service every quarter?

Yes.

Q: Would be that little piece of scope then that is a capital.

A: What do you capitalize? How do you qualify it?

Q: It's basically the labor hours associated with building the software?

A: Okay.

Nevine White

And so however many labor hours are booked to that project, which was somewhat predetermined. You have X many people times X much time. And so whatever that looked like is what we would close to assets every quarter.

So that asset became the ordering system, and next quarter we'd add another little piece to it next quarter. The accounting function from that perspective was pretty much automated. It would close the project to assets. They reconciled the numbers, and off it went into depreciation.

So it didn't have to be at the 100%, like everything was beautiful. It was version 2.0 with a bow on top. Whatever got released is what those labor hours we closed to assets.

Q: So each quarter's work depreciated separately? I mean...

Nevine White

They created an account. It was in the system. It was an automated roll for... It was also called a waterfall, depreciation waterfall. They rolled that forward every quarter. And so, yeah, they had different levels of assets.

I'll be honest with you, I didn't do that kind of accounting, so I don't know exactly the mechanics, but it was automated.

Steve Player

If you've got that and you've got the functionality, you can qualify. You can say, "Okay, I've closed it because we're actually using it."

If you don't have it because they haven't turned it on yet, you could hold it as an asset on the balance sheet till you put the asset in service, and then trip the depreciation to start whenever you officially put the asset in service.

Nevine White

So we had--

Steve Player

The point is you can automate that very quickly and get past that path.

Nevine White

We had a hyper-conservative chief accounting officer. I guarantee you whatever she did was totally on the up and up.

Yes, sir.

Q: So just following that to its logical conclusion, do you think you could capitalize an individual service, like a microservice? If I roll something new, a new version of a microservice into production, and I do it today, and then tomorrow I'll do another one, could I figure out what the labor is and then just basically, since it's in production, capitalize it and be done with it?

I think that totally depends on what infrastructure capabilities you have on your accounting systems, what they can and can't do. And that's where the conversation--

Q: From a concept perspective.

Nevine White

Conceptually, I don't know why you couldn't, even though accounting tends to quote--

Q: What you're saying is doing it easier. Because you're just saying every quarter they're fixing the value.

Steve Player

Yeah. From a purely talking concept, everything's possible. In theory, everything works. In practice, theory rarely works. Okay?

The reality is accounting tends to close the books monthly, right? They tend to not do stuff in between. So they tend to close the books monthly. So for us, doing it quarterly in terms of closing the projects made sense.

So you know we want to do continuous delivery, but what you're talking about is granularity. If it's monthly, you just gather up all the things.

Nevine White

Gather them up.

Steve Player

Monthly, there you go.

Nevine White

Yeah. Great. Like I said, we found a common ground between what our IT organization needed to do and what we needed to do for meeting the compliance on the financial side, and we found a place where we could make it work.

Would they have preferred infinite projects to do? Sure. That wasn't something we could do in the constraints of our accounting system. But we found a way that worked.

Steve Player

If you'd like a white paper on our 12 Beyond Budgeting principles we showed earlier, if you'll just give me a card up here, we have a 20-page white paper that's a summary of The Leader's Dilemma book that'll take you through the 12 principles. Be happy to send that to you to help you get started on the process.

Nevine and I will be here afterwards. I think we're headed to a break or discussion now, so we'll be happy to keep answering your questions and talk as long as you want to.

If you want to take cards or just give us a call when you have a problem with finance or you want to have a conversation with finance, we'll be happy to get on the phone with you and see what we can do to help you move forward.

Thank you very much.