Paul Sausville is no bean counter. Although he has a master's degree in finance, spent years at NCR and AT&T as a consultant for the banking and financial services industries, and went to work as a financial analyst at Microsoft, Sausville soon discovered the connection between numbers and marketing and shifted roles to focus less on managing the books and more on revenue growth activities. After stints in the browser business at Microsoft, he moved into the Developer Tools group, and eventually became finance director for Microsoft Office.

After 13 years with the Redmond company, Sausville left to go into private consulting. He currently serves on the board of Pcubed.

In this interview, Sausville explains three approaches to revenue growth initiatives, shares the metric he most favors in determining the feasibility of a project, and lays out why he believes project management teams should absolutely include an accountant.

At Microsoft you were heavily involved in revenue-growth projects. How do you advise approaching these?

Paul Sausville: Look at the entire market and see where you're positioned vs. where your competitors are positioned. Lay out all the markets like a map. What are your approximate marketshares? Are you familiar with the game of Risk -- where you build up armies and attack different countries and try to conquer the world? You have a certain percent of a market. Others have other markets. And you look at different markets -- which ones are fast growing, which ones are growing faster that you have a lower share in, which ones are easy to penetrate in your current position?

From there, you have several options: edge-out, step-out, and break-out.

In the edge-out approach, you edge out into markets closest to you. That's a relatively conservative strategy. Step-out takes you beyond that market. There could be good reasons-- such as a fast growing market size -- that make you want to step outside your boundaries. And with break-out, you skip a bunch of steps.

If you were to look at SAP, for instance, it started in one area, accounting, then branched out into adjacent squares, then eventually took over most of competing markets around the enterprise.

Microsoft was involved in Office applications, word processing and spreadsheets. If you look at those markets, there are adjacent markets. For example, a large market evolved for business intelligence. Until recently, there were several half-billion-dollar companies -- SAP's Business Objects, Cognos -- in that market developing business intelligence [businesses]. Having access to SQL and Excel, it was logical for Microsoft to get into the data intelligence market. That was a simple edge-out strategy.

Then there are markets evolving that we got into with a step-out strategy. We tried to develop the e-book market -- that was not one that was successful. We definitely went in and spent quite a lot of money. But to get into that market, we needed not only reading technology, but also digital rights management technology. We had developed enabling technologies to really look at that. The market never materialized in the timeframe we set. So we eventually left the business. We were partnered with Amazon, which later, with the Kindle, has gotten traction.

The Xbox was a breakout strategy to get us into the living room.

Was there a threshold with Microsoft for it to say yay or nay?

Definitely, there are threshold numbers. A $10 million business is not very interesting to Microsoft. If you run a $10 billion business and you want to continue getting 10 percent growth, you've got to find another billion every year. That's not easy to do. So trying to get a lot of opportunities at $10 million or $15 million isn't interesting. You need to make sure the market is large enough if you want to think about it that way.

Sounds like the project manager or program manager needs to be fairly savvy about the financial aspects of their projects.

The very best ones are savvy. In the growth days, people were willing to invest. As long as there was money floating around, projects could be a little behind and over budget. If there's value at the end, people seem to understand that projects sometimes get delayed or over budget. What you don't want is to have your projects late and over budget and then not very good.

When a company is flush with cash, they're looking at all the things to fund. When companies are in an economic downturn, they have to know where to cut and why. If your project is late and over budget, it's very likely you're going to end up on the list that they'll want to delay or even cut.

In a cost-cutting environment, that's a recipe for having a project shut down or having the project killed in order to save money. This project is late, in trouble, and isn't going to make the goals. Given the financial constraints, are you going to shut down a project that's on time, on budget and looks like it's going to come in?

Tell a story about a project you had to cut.

I was working on a data warehousing solution that would give visibility into the revenue streams and marketing programs of the business. This program would let you drill down and see marketing budgets and returns for the products. We had in the neighborhood of 1,300 to 1,400 marketing programs going on at once. And each marketing program was like a little project. Rather than going to several different systems and piecing together the ROI for a project, you'd be able to drill down into how a project was doing as far as the marketing program and what revenue it was actually generating over what period of time.

We had problems with a combination of delivery in terms of time and quality of work with the vendor we were working with.

We then went into the economic downturn, where we had to cut out over $150 million of spend. So which project are you going to cut? Are you going to spend money on a system that's not directly generating revenue to help you analyze the business or will you spend money on telemarketing and keep a few extra sales people?

The data warehousing project was behind schedule, over budget. Even though it was needed, it was a relatively easy decision.

Any advice for tying the schedule to the money in a project or program?

You have to know the environment you're working in. At Microsoft you wanted the schedule and dollars to tie as closely as possible. Why? If you're under budget, the company wanted to keep that savings. The finance guy is saying, "I didn't spend this $10 million, so I'm going to bank it." Suddenly, your project with a $100 million budget has $90 million because you didn't spend it in the quarter when you had it.

Most companies do not have a good project accounting system. A good project accounting system would say, "I have a $100 million budget regardless of where the fiscal boundaries are. But companies operate on quarterly profits.

So you have a thing where the finance guy's goal is on saving money and how the P&L looks. The project manager's goal is on delivering it. There's conflict there. If you're ever in doubt, budget more conservatively in the rear end. If you're ahead in the budget, someone else might be under budget, and you can cover it. Most likely, you want to be on budget. Most variances might get swept away.

There are a lot of tactics and formulas for determining financial feasibility of projects. Any advice for sorting those out and knowing which ones to apply in a given situation?

Typically, net present value (NPV) is usually one of the best. It's set up to maximize shareholder value.

ROI can give you the wrong answer sometimes. Typically, you could have two projects -- one that's a million dollar project with 10 percent return, the other a $200,000 project with a 15% return. If you can only afford one, based on ROI, you might choose the 15 percent one. That won't give you the most bang in terms of total dollars.

Option value -- the likelihood of an option actually finishing -- people don't often look at this in terms of projects. Very often you do a project, for example, exploring for oil. You obviously need enough money to tap the grounds, and the project may require drilling five wells; but you may be able to stop after two wells. Amazon got into the book market but they had infrastructure to get into other markets. Sometimes building infrastructure will allow you that option value. You want to make sure that when you do this budgeting, you have to look at it realistically, because it's all estimates and you want to make sure you're maximizing picking the right projects that are going to give you the most bang for the buck and have the most value long term.

All those thing are not necessarily bad gauges. You just want to make sure you're looking at it in a holistic way to maximize the value of the shareholders.

Each organization very often has its own metrics. You want to make sure politically that you acknowledge those metrics, whatever they are.

Do you advise having a strong numbers person on the project team to bring that finance and accounting perspective to the table?

I think it's good to have financial background or have some financial support on the project team. Ultimately, a project is judged based not only on whether it's delivered on time but also whether it's delivered on budget. And you want to make sure you're on top of things.

Very often what happens is that the project manager doesn't know all the costs or how the budgeting system works. Things are done year to year. A project is budgeted for $5 million and rather than taking two years takes two and a half years. In people costs alone, there's an extra couple of million dollars of spend -- even though on an adjusted run rate, it might not have gone up that much, because it was on a steady run rate for the number of people working on it.

If you think about a project being behind schedule, that can have time-to-market implications for a revenue-generating project. If you're planning a new software project and that comes out two months late, no big deal. Well, it's a huge deal if you're trying to hit the back-to-school or Christmas market.

That's why having an idea about how the financial system works, knowing whether or not you have budget, making sure you have cut-off dates for the fiscal year... Very often projects cross fiscal boundaries. If you have expenses that were supposed to hit in one year and they hit in another year, you end up one year under budget, then the next year over budget. You didn't perform an accrual. Then it makes your project look bad or makes your manager have to explain what happened. When these things happen, it makes you look like you're not on top of project details.

Can you suggest an antidote to being in that position?

There's this old story about the construction of the Empire State Building. The guy in charge walks in and says, "What's the color of the tiles on the 58th floor men's room?" The other guy looks it up and tells him. So the first guy approved the whole project.

So the story is about knowing your details. If somebody says, "You're working on this huge data management warehouse project. How much has been spent on software, how much on development, how much on testing?" and you can talk about those numbers in an articulate way, that makes the project manager seem that much more competent and on top of the project.

Typically, there will be a lot of people who don't understand the project or the value of the project -- simple accountants. They'll give you the most trouble. They'll cut you off: "You've had budget. There's no more money." Then you won't be able to finish the project or get additional POs. And if vendors don't get paid or employees don't get paid, people stop working. You never want to get into a situation where you're 90 percent of the way there and all of a sudden you're out of the budget.

The other thing I want to add is, if you don't keep track of the budget, you could wake up with a pretty big mess on your hands.

At Microsoft we were working on a project in one of those new emerging markets, where we had to keep investing in incremental things. We thought it was going to cost $10 million to $15 million. By the time we got it done, it cost a lot more because we had to ask for things we didn't know about.

So we tried very hard to have strong financial people involved. If you think about a project, you want a team of people with complementary skills. Having a strong finance person can help you out. Very often they can help you figure out alternative avenues for getting funding or take business into a different direction. If you had to cut something, what would it be? That's not just a matter of constraints in scheduling. How can we move money from one quarter to another? How can we make trade-offs? You don't want to make finance decisions -- you want to make overall business decisions.

I'll give you an example of a short-sighted decision that I was involved in, that was -- on reflection -- poor. We had a project where we were told we had a certain budget. We had several projects going on at once. One of the areas where we thought we could save money was on testing. Rather than using full-time employees, we went out and hired temporary employees. They were cheaper than full-time. But they weren't at the same quality level. So while on an hourly basis we were saving some good amount of dollars, we really should have canceled the project or waited until the project was ready because we didn't have quality testers to do it. And because the product quality was poor, we ended up paying a lot more -- by shipping a product out there that had issues.

If you don't have somebody who balances those decisions, if you just have someone who says, "We can save so much more an hour by shipping that overseas or doing it outside the company," you may not get what you expect. You can very often make those wrong decisions.

That's interesting. People traditionally think of accounting folks as being focused on the nickels and dimes. So accountants can bring a broader perspective to the decisions?

Companies don't suddenly go bankrupt. Over time they lose their navigation points and their controls. Having a financial person on the team can keep you from ending up in a bad place.

This article was first published by Pcubed, which holds the copyright.

Published with permission from

 

Contact Paul Sausville at paul.sausville@pcubed.com.