Interviewee:       Scott Madden, Project Manager
In attendance:    Steve Bean, Mizuho Llewellyn, Kim Nguyen, Ha Su
Date and Time:  March 13. 2001 6:30pm
Location:            New Energy Associates, 400 Interstate North Pkwy , Atlanta, GA

Steve: I’ll get us started. We’re with Scott Madden of New Energy Associates. Scott, please tell us about your job?
1 Scott: I manage the financial planning practice area, which encompasses two products that are financial planning products. One was just developed and completed last year and one that has been around for about twenty years. I have managed the product consultants who go out on the field and help implement the products at our client sites. I also manage the software development team that builds the models and maintains them.

Steve: Give us some idea of how many people you normally have working under you or on a project?
2 Scott: There are sixteen people on my staff and it’s broken up pretty much evenly between product consultants and software developers.

Steve: Tell us a little bit about New Energy the company and the type of products and clients that you have?
3 Scott: New Energy is an electric and gas utilities software development and consulting related firm. We work with electric and gas utilities around the world and help them in niches, things like financial forecasting, forecasting for production costs, the costs that it takes them to produce energy, gas planning, retail planning, demand site management, a lot of different niches, but it’s all based on forecasting, predicting the future. We have a suite of software models that help our clients predict what’s going to happen tomorrow, next month, five years from now and to make decisions based on those model results.

Steve: Does that mean that in addition to software people you also have a lot of financial experts?
4 Scott: We have experts in different niches of the market place. Some are financial experts, others are what we would consider more engineering or economics type experts. A lot of them that have very extensive amounts of related industry expertise. They either worked at a utility or worked at a regulatory agency. So, they know the ins and outs of the energy industry and can help the clients make those decisions with and without our tools. Hopefully, they’ll use our tools so they’ll license our software, that’s were we make the highest margins. But about half and half you know half of our revenues come from consulting, half comes from license sales.

Steve: We were looking at your website and it lists various products. Do you deal with a particular product?
5 Scott: I work with the financial planning products, Impact is, if you look at our website, New Energy Impact is the new one that came out last August. It is geared not only toward the electric and gas utilities industries but to any financial forecasting need that a company might have. It could be, we’ve been marketing this to telecommunications companies, banking and really it’s one of our first products that can go outside of the industry. It’s not a regulatory tool like a lot of the other ones. The other tool or application that is in my practice area is called Acumen. It has been around forever, since the mid-80’s. It is a very detailed financial forecasting tool. Monthly it can handle tax planning, cash planning, use it for your one year budget or your five year forecast. We have eighteen clients right now that us it. In it’s heyday I believe it had around forty or fifty.

Steve: We will be writing requirements to help you with job estimation, we would like to get a sense of what factors you look at when you are estimating a job. And how you measure the complexity of a job and that sort of thing.
6 Scott: There are two types of jobs. One would be a software development agenda and the other would be a client’s implementation of our software. So the software development teams will focus on the features, the enhancements that they want to get into the next version of the software and the product consultants would look at client X who is interested in implementing one of our software packages. How integrated do they want it to be? How many other systems they need it to integrate with? How much customization do they want done? So, which one would you rather focus on, would you rather focus on the software, or the consulting engagement?

Steve: Software, that’s what our assignment is geared toward.
7 Scott: The things that we look at obviously what our clients needs are, what areas we feel need to be addressed by the software that hasn’t been. For the product, Impact, it’s relatively easy to find things that need to be upgraded and addressed because as with any new software product you try to get the main thrust of your product out in the first version. The main application and then you add on additional functionality as clients start buying into it and expand the spectrum of what you can do with the tool. So we look at what the critical needs are what our competitors have that we don’t have and also what current clients are looking for that we don’t handle well or can’t handle at all.

Steve: Specifically, how would you estimate the cost on a job going in? I’m sure that varies over the time of the project.
8 Scott: For our staff, we’ve got a limited number of resources that are available for working on the software, we basically estimate how much revenue the product plans to bring in and determine how many software developers that will buy us. Then we know how many hours a software engineer (SE) can work and so that basically gives us our budget for how much work we can do. Then we have a list of things that we want to accomplish and we prioritize that list. We also have to look at when we want to delivery the next version. Say we want a six month version schedule, so we look at the things we want to do, the resources and the time frame and with the three of those we come up with an agenda for the next version.

Steve: Do you use a particular software program to help you with that?
9 Scott: We do use Microsoft Project to, once we’ve somewhat narrowed down our scope to determine how long it’s going to take to do that with the resources we have and then if we’re way off we’ll trim some more items off the list. Or, if we come in and say well we’ve got more time, we’ll add another task and push out to the six month window that we have so that we’re fully allocating our resources.

Steve: How would you rate your system as far as being on budget and on time?
10 Scott: It’s gotten better over time. When we were first developing this product it was slated to be a one-year to a eighteen month development project. It went on for closer to two and a half years. We were having trouble estimating, definitely. We found that it’s a lot harder to estimate a product that is being developed than it is to estimate for a product that already exists. Once it’s a known quantity you have some code base to work with. You could say with more certainty what it’s going to take to add that incremental feature. But when you’re going from the blackboard or the whiteboard, as it would be, to creating something in code, there’s a lot more uncertainty.

Steve: It’s almost impossible to get a perfect estimation. So the historical data is really critical to estimating, right?
11 Scott: Now we can hit our targets for the last two point versions within a month and you know you go from within a year to within a month you feel like that’s some pretty good progress.

Steve: Are there any features that you can think of that would make your system better or ideal?
12 Scott: Well, we don’t really have a good way to take into account the relative skill level of our SE’s. We estimate tasks, either they’re easy, medium difficulty or difficult. We don’t have an easy way to also say OK this resource is beginner, rookie, novice or an expert. The map is just too much for a project to handle to map those things. The expertise of the person who is doing the task with the scope of the task.

Steve: So, it could take two novices the same amount of time as an experienced or seasoned pro?
13 Scott: It’s also hard with a project to split a task among multiple people. I don’t know if you’ve tried that but it’s really a nightmare because basically you have to set up precedences. This task waits till that task is done before it starts and if you get more complicated than that with a project you can really get into some soup so we tend to either break the tasks down to such a level so that everybody is working on their own tasks and in reality they aren’t. Or, we’ll put three people on all the same tasks, we’ll have a Java team and a VB team and even though they’re going to be sharing, you know, some are going to be working on some tasks and some are going to be working on other tasks. We tend to put them all on every task and it’s hard to get too detailed and see what the one resource is working better or worse than planned because your plan is at a high level.

Steve: When you are developing a project, how much time and resources do you put into the estimation process upfront?
14 Scott: We’ve gotten more rigorous in that area lately. As we were developing the product we weren’t really under scrutiny from upper management. WE had a carte blanche, if you will, we’ve got ten SE’s, get something out there that we can sell. So, if we were late or whatever, it didn’t really matter because until we had the first version there is nothing for them to review, there is no looking at how long it’s going to take, it was just get whatever you can done by this time. Now, we find that every feature that we want to add, every enhancement has to be justified. Some management group is saying, I think you have to put in feature X before you put in feature Y and so we have to do a better job of estimating how long each one is going to take. It helps us a little bit politically too, if we can make the ones that we want to get in as close to reality as possible rather than putting some padding like you might do if you’re not certain, if you have that uncertainty. I don’t know if that answers your question.

Steve: No, you have given us a good sense of the development process and what you go through. I just want to get a sense of how much time is spent on the estimating?
15 Scott: I would say for some features or enhancements we will spend a week going back and forth with the developers who are going to do the work, questioning them and making sure that they have an estimate that we all agree with before we present it to management. How much time the developers actually spend I guess that varies, some will spend on the estimates than others. Our vice president of architecture tends to be the back of the envelope, high, medium, low for each task just listing the tasks out. Others will get into more detail, they will actually go into and look at the code that exists and see how many routines are going to need to be changed and that type of thing. Between a few hours and maybe a day, or a day and a half to get an estimate together. And then there’s the negotiation process that goes on, well, that’s not really in the scope that we were thinking about, let’s cut that task, or hey, did you remember this piece of the interface that we need, oh no, I’ve got to go back and add that to my scope.

Steve: During product development, do you use rapid application development? Or, do you have a certain model that you follow?
16 Scott: We don’t do probably as good at the rads as we could. We tend to, our developers tend to think they know what the customers want, and because we don’t have an individual customer we’re selling shrink wrapped software, which the head of this faceless group of people that are eventually going to buy it or not buy it we tend to be autonomous in putting together the enhancement of the feature so, there’s not a lot of iterating. In fact, we’ve got a development agenda that’s a six month agenda, and this Friday, we will be six weeks away from shipping. It will be the first that I get to play with the user interface, the alpha version if you will, this Friday. And this past week was the first time that we actually saw the interface.

Steve: Will you provider a critique of the interface?
17 Scott: Right, but we don’t sit there and iterate and iterate on the design of the interface. We pretty much have a requirements phase, we say, OK this is what we need. The developers will go off and write up a document that says, this is what we heard you say, and this is what we’re going to code. So, we review that. And, they go off, they code it. There’s obviously the object engine piece they have to build and the user interface and then you get into the user acceptance part, which is where we’re going to now, where they present what they’ve done. Hopefully they’re on track, if not it’s very expensive to go back and change. It’s kind of like the waterfall methods where you go through each phase and the further you go the more expensive it is to go back.

Steve: I assume you have sales people out there that are trying to sell this package product?
18 Scott: Yes. The practice area has one dedicated sales person and we’re looking to hire a second one to go outside the energy industry and he’s very involved in the development process as far as being vocal about what the clients want and what they need. Especially in the early development of a product, there’s things where we get hammered by our competitors because our product doesn’t have a feature that they do, or we can’t do one thing better than they can. So, we try to offset that with the strengths of our product.

Steve: Talking about timelines, we’ve heard the term “internet speed”. Are you experiencing pressure to get things out as quickly as possible?
19 Scott: Absolutely. And, what we did with Impact was open up the box. You’ve heard of the black box where you enter your data and the black box processing happens and then you get your output. Well, in Impact all the business rules, all the logic that makes an application useful for one individual is open. It’s more like Excel, so that you can see all the formulas that are firing and all the calculations and you can modify them inside the package. So, that opens it up, the customization can be done at the clients site rather than by SE’s. The SE’s are responsible for the underpinnings for the rules of how objects interact with one another, how accounts interact and how companies interact. But our product consultants and our clients can handle how their companies can do financial forecasting. Know at what level of detail they do it, what specific business rules they have for modeling different things. They can customize that on the road, which makes it more flexible and speeds up the delivery of that type of code. We have, for the past decade provided a semi-annual version delivery of our software. We found that’s pretty good because as long as a client has a need, you can say it’ll be there in four months they can usually live without it for four months. If it’s above then we obviously patch the product and get them a release much quicker than that. But if you get a version of software updated twice a year. That’s typically going to meet your needs.

Steve: Do you provide follow up support and maintenance for the products?
20 Scott: Yes, with this product, both of them actually, you can buy licenses that are annual or perpetual. And with either one you get maintenance which involves customer support, five days a week, forty hours a week, basically we’re here to provide phone support, it also involves training buckets so that if they have new folks come in, they can go and we’ll go to their site and train them on the use of the software or do advanced training so they can get new uses out of the models.

Steve: Those are services that they purchase in addition to the software, so that’s how you cover the cost?
21 Scott: Right.

Steve: I’m not sure how well I’m adhering to our guide and I just want to be sure that we cover everything. Let’s talk about security, is security a concern for your clients?
22 Scott: Yes. For a lot of clients, especially financial data, they’re very concerned about. And that’s one of the things where we’ve been beaten up a bit by our competition and by potential clients, is that the product is not multi user and does not have security password protection. But it is as secure as your operating system. If you’re using NT and you have a password to get into your computer then it’s at least that secure, it is a stand-alone application.

Steve: Because it’s not something played over the Internet you don’t have those concern, right? Are there any particular pressures that you are feeling or any problems or challenges? We sort of touched on this before, features that we would be able to provide in a software program to help you with the estimation process? Should it interface with a tracking program like Microsoft Project or something maybe a little more tailored made towards you? So, is there anything you’d like to add?
23 Scott: Just the fact that resources tend to be of different skill levels and tasks tend to be of different lengths, we also tend to not break tasks down to the right level of detail. I know that the rule you should use is, you don’t want to break something down below eight hours a day and you don’t want a task that lasts more than like a week. Because you can hide away too much way too much slop in a week and if you’re modeling down below what it’s going to take you in a day you’re going to have too many line items to look at on a project plan. Especially for a six-month project. But we do tend to model or plan at too high a level and if it were easier to get down to the tasks between eight hours and forty hours without causing such a problem with the number of rows that you have to look at and the number of connections you have to make to resources, it would be more beneficial to us. Obviously, if we could also tie our resource plan or our estimation to individual resources rather than groups of resources there would be a big benefit to us and that and being able to do a better job just of estimating in general I don’t know how you could get a software package to help you estimate what it’s going to take. You really rely on the experts that you have developed for that product to provide a raw estimate and you have to augment that estimate by the person who’s going to be performing the work and their skill level.

Steve: And the unforeseen that happens during a project...
24 Scott: Sure, there’s always that.

Kim: Is the estimation information gathered by your company usually accurate?
25 Scott: No, we, even though we were always off, we always, my boss has instilled in us the principal that it takes twice as long as your SE’s estimate. So, we’ve always been prepared for that and we’ve recently gotten better at our estimates, and I think that has to do with the maturity of our software. But, whenever we were developing software from scratch whenever we got an estimate, my boss would say, OK you guys are saying it’s six months, I’ll be surprised if it’s done in less than a year. And, by and large he was right, because of all the uncertainties, because of all the things that you can’t predict. The technological hurdles, the human factor, people leaving in the middle of a project. Coming up with new ways of doing something, where you have to backtrack to get where you wanted to be and the fact that it is iterative sometimes where you don’t want it to be. We had a situation with Impact where we thought we were making progress, thought we were making progress, but we were coding on a house of cards and eventually we got to a point where our code couldn’t handle what we wanted to do and we had to retrench and really start over learning the lessons that we had. We always say the first castle fell into the swamp.

Steve: And not knowing that going in...
26 Scott: Right.

Kim: Do you guys actually do the estimation in-house or contract outside experts?
27 Scott: The product consultants.

Ha: Who else?
28 Scott: The salesmen? And believe it or not the SE’s have some ideas of things they want to put in. And usually they have to do their stuff under the covers. They want to put in things that make the code more efficient that clean up code cause they’re purists. And, whenever they put those things on the Gantt chart they get axed right away because client don’t see it and they’ll tend to pad estimates so they can get their work done in that time frame as well. You want to let them do a little bit of that ‘cause it’s always good for their morale to be able to have code that makes them look good.

Steve: Ultimately it’s going to be a better product.
29 Scott: Sure, down the road it’s more maintainable. But you don’t want to let them pad so much that they’re disrupting your sales cycle or potentially help you lose sales because you’re not getting your software out fast enough.

Mizuho: How about cost, do you usually go under budget or over budget?
30 Scott: We don’t perform cost estimates per project or per version even. Where we get our cost basically is in the staff that I’m allocated. So, each year I have a budget that I’ll present before the leadership committee and say I need 6 SE’s or I need 4 ‘SE’s and here’s the list of things that I want them to do over the course of the year. You always make sure you have huge lists. And hopefully you get those people and whatever group of staff you have you just do the amount of work you can with that staff. And you set your scope according to your staffing level as opposed to saying I have to do this, this, and here’s how much I have to do it so I’d better hire people who will do it for that amount. We have SE’s who are career SE’s or system engineers. So, what we pay them is what we pay them and our head count, our per head count cost is the same for everybody. The lowest guy on the payroll vs. the highest guy in the budget, everybody is the same.

Steve: Do you ever use temporary workers for programming?
31 Scott: Very rarely, maybe once every five years.

Steve: Well, thank you very much Scott.
33 Scott: Sure, any time, good luck on your project.