Software

Resource estimation tips for the development manager

When the CIO stops by to chat about a project, how do you explain why you need so many developers and other resources to do the job? Read advice from three project managers who have their own systems.

How much will it cost, and how long will it take? You must answer those questions for your customer before you get the purchase order signed for your next project. The challenge for the project manager is how to determine the right price for a project. We asked three veteran project managers to share their secrets by answering this question: How do you know how many people you need, and how many hours they need to work, in order to complete a project?

To recycle or not?
Scott Kopp, a senior programmer for a Fortune 500 healthcare provider, routinely writes resource estimates on which his contractor budget is based. He says his time estimates "depend a lot on how much existing code can be reused. If the project is similar to one that's been done in the past, I'll look at what resources we used and how much time it took us the last time, and I'll base the estimate on how similar the projects are."

Tim Boone, an e-business consultant who writes project development cost estimates and management plans for Kizan Technologies, has a different take on reusing code. "I've tried to base estimates for new work on old projects," Boone says, "but I don't like to do it any more. We spent too much time trying to reuse what we'd done. You lose creativity trying to build around [the old design].

"There was also the expectation everything could be done in the same amount of time it took for the last project. That isn't always the case.

"Now," Boone says, "I encourage my teams to design the project, and estimate it, from a fresh perspective. We do still raid the old code. When we need to build a shopping cart for a Web store, we borrow the existing tools for that."

Tools of the trade
When it comes to software tools for estimating project costs, Kopp says, "absolutely the best product is Alexsys. It blows Project away. I used it at my last employer, and we put every box, every software project, everything in it. It worked so well, I lost my job because of it. When I started, I was looking at managing like 500 projects, and my boss said, 'you'll never do it; you'll have to be Superman.’

“I put everything into Alexsys, and six months later, all the projects were assigned and were rolling along, and my boss said, ‘Guess what? We don't need you any more.’" (Follow this link to CNET's Download.com to read about Alexsys Team 2 2.02 and download a demo version that allows 100 work requests. Shareware price is $155 from Alexsys Corp.)

Boone recommends Microsoft Project. "When I interview a new client to get the scope of the project, the first thing I do is put all of the high-level tasks into Project,” he says. “Then I use Project to balance their resources and my resources for those tasks. I go back to my client with this big road map. We agree on the high-level goals before we start [defining the particular details]. But I use Project for it all."

Over the years, Boone has developed Project-based templates fine-tuned for tasks such as intranet design, Web site design, Web stores, and others. "Within those templates,” he says, “I've set up generic tasks that I know will be particular [to] the process. Then I customize those tasks for each new client."

Creating perceived value
Once you've put together the best, most accurate estimate for your project, how do you explain that estimate to your customer, whether it be your manager, your CIO, or your consulting client?

"The level of detail you need to go into depends on your audience," says Peter Schickler, president of Button Systems, a provider of custom programming solutions. "If you're pitching a project estimate to someone in a big company like AT&T, you figure the person has seen 10 quotes like yours in the last week. That person knows what to expect from a contractor. The more details, the better.

"When you're talking to someone who isn't as technical, you can be less detailed. You can say, 'That's 25 screens at four hours per screen, so you're looking at about 100 hours.’

"Then you create perceived value with that nontechnical customer, in order to convince him or her that you really did spend some time making this [product]. You point out how much you can do on any given screen—lookups, edits. You're not the technical person explaining the program now. You're the marketing rep."

How do I price thee? Let me count the databases
Schickler uses a deliberate method for estimating the hours it will take his team to do a job. "I count the number of databases. For each database, there's going to be an update screen, where you can add, change, or delete records, right? So that's 10 'edit' screens."

"For each edit screen, I look at the number of fields. It might take me an hour to code a screen with two fields, but if I have to build one with 10 fields, or 15 fields, that might take four hours.”

Schickler bases his pricing on the design specification document, wherein all the databases and screens are well defined. "I put the number of hours I estimate to complete the work right on every page, and I make the customer initial every page."

Getting the customer's sign-off on the design specification makes it easier to bill for additions and changes as the project progresses.

"Every user looks at the design document and says, ‘that's exactly what I need,’ Schickler says. “Then you build the thing, and the client says, 'You only left room for two customer e-mail addresses. What about the third e-mail address?'

"So you go to page 24 of your design document and show the customer that the third e-mail address wasn't part of the original design, and you get to say, 'That's more money, dude.'"

Estimating high or low
The goal of every project manager is to get the work done in less time and for less money than originally budgeted. Boone recommends a more realistic rule of thumb: "Never go more than 10 percent over your estimate, and try to come in 10 percent under."

When Boone is estimating the number of hours for each task he enters into Project, he pads the estimates with some extra time for what he calls high-risk clients. "I have a good idea how long it should take my team to finish a job under ideal circumstances,” Boone says. “With some clients, there are issues right up front. The data is scattered among different groups or locations, the company isn't well staffed or organized. I'll increase my time estimates by 10 percent for those kinds of clients."

How accurate are your estimates?
Kopp, Schickler, and Boone have developed methods for estimating the resources needed to complete a job. To comment on their approaches, or to share your own advice on the art of project estimation, please post a comment or drop us a note.

 
0 comments