Project Estimation Does Not Have to Be Softwares Black Art

Author Steve McConnell demystifies

By Alex Handy

May 15, 2006 —

“It was a heck of a topic to write about,” said author Steve McConnell of his latest book: “Project Estimation: Demystifying the Black Art.” The subject was conceived eight years ago.

McConnell is no stranger to writing about software development; his previous tomes—such as “Rapid Development” and “Code Complete”—have been referred to as required reading for all developers.

Now chief software engineer at Construx Software Builders, the software consultancy he founded in 1996, McConnell was once named by Software Development Magazine as one of the world’s three most influential people in the software industry, along with Bill Gates and Linus Torvalds.

For his latest project, McConnell had to take a step back from building software to write about a topic that some consider to be akin to fortunetelling. At the end of March, SD Times sat down with McConnell and chatted about his new book and how best to predict the future.

SD Times: What two or three tips would you offer project managers who are about to estimate a new software development project?

Steve McConnell: Tip No. 1 is read my book [laughs], but that’s a difficult question to answer. The estimation challenge is significant enough; it’s really not possible to distill it into a pithy tip. My book has 118 tips. If I had to pick some, one would be base your estimate on historical data. Look at how you performed before and make your estimate based on how you’ve performed in the past. Try to break the estimate into multiple pieces. Divide feature areas and subsystems into different development teams. If you can decompose and estimate, you’re going to compose a more accurate result. Tip No. 3 is make sure you’re differentiating between your target estimates and your commitments. An estimate tells you how long and how much. A target is a description of what’s desirable. A commitment is the merging of those two.

Is there an easy equation for how many people you’ll need on any given project or how long it will take?

It really depends on the size and nature of the project. The simple answer is no. You really need to understand what’s going on in the formulas, but coming up with a simple formula, those formulas depend on the size of the project, number of requirements, number of function points, the lines of codes and type of software.

Can you name some commercial estimation tools, and are such tools accurate and reliable?

There are quite a number of commercial tools available, and a lot have been around for 20 years. Our company offers Constructs Estimate, a free tool for this. I think our tool is far and away the best free tool. If you’re willing to pay, you can take steps up. In particular, there’s a nice tool from QSM called Estimate Express, based on the Putnam estimation model. In that price category, I think that’s the tool I’d look at.

More powerful tools cost [US]$20,000 per seat per year. In a large organization, it is worth it. An accurate estimate forms the foundation for good planning. If you’re running an organization with a budget of $10 million a year, it’s pretty easy to justify the purchase of these tools. An accurate estimate could end up resulting in plans that are that much more successful. These tools are very complicated and require expert users, though.

How do you go about estimating the needs of a project?

I think where you start kind of depends on how well-developed your estimation capabilities are. If you haven’t developed at the organizational level, you should start by figuring out what the thing is you’re estimating. People often try to estimate before they know what they’re estimating. The second thing is to document assumptions. Document the questions you have about what you’re estimating. You should be trying to look up documented facts about the effort and schedule of some kind of similar project in the same organization. It’s as much a function of the organization as it is of people on the project. Once you get beyond five or six people, the attributes of the organization are really going to have a major influence on the project’s outcome. Info on past projects is incredibly useful.

In your experience, what sorts of estimation techniques produce inaccurate results?

Unfortunately, I think the most commonly used techniques are the ones that produce inaccurate results: gut instincts, off-the-cuff guesses and any kind of estimation where you don’t sit down and assess what you’re estimating. A lot of the numbers floating around that people call estimates I wouldn’t call estimates. Business targets and desirable objectives for business aren’t, as there’s never been any analytical assessment. I tend to think that the substitution of business targets for estimates is worse [than gut instincts]. We find that at the business level, there will often be an incredibly strong need to meet a particular target, but the fact that there’s a strong need for that doesn’t mean that is necessarily achievable.

What do you do when a project begins to bloat out of control? How do you stop “featureitis,” the constant creep of features?

Whether it is out of control or on track, it’s good practice to plan from the beginning to re-estimate over the course of the project. That’s just natural. You’re going to discover things about the project and the project team, and you can collect data on the project and team and it becomes historical data. Many projects re-estimate only in response to a schedule slip. Then there’s a heavy bias on the estimate because you hope that the estimate comes out low. If you plan ahead to re-estimate at several points, the focus is more on the accuracy of the estimates.

How do you estimate for maintenance releases?

Maintenance work does require some different approaches. There’s no one right way to estimate maintenance. There’s so many different kinds: Certain kinds might be fairly wholesale revisions of an existing system, and in that case the focus on estimation is going to be more similar to regular estimation. Others are like bug fixes, which means you’ve got lots of open issues—these tend to be closed with a small amount of effort. That’s a great time to use historical effort to estimate. Then there’s the middle ground that calls for a hybrid approach where you’re looking separately at major enhancements and minor enhancements.

How do you predict QA needs ahead of time?

We see ratios of three developers per tester, 10 developers per tester, and it’s not uncommon to have no testers at all. With e-commerce or shrink-wrap software, you might see one tester per developer, or with highly critical systems you may see 10 testers per developer. The real answer is that historical data is as useful for estimating QA as it is for anything else. In the long run, you want to capture data on QA and use that on future projects.

Share this link: http://www.sdtimes.com/link/29331

Not a Cease-Fire, Not a Truce Sun wants to expand the penetration of Java within the enterprise, and more tightly couple the well-known Java brand around...

Does Windows cost Microsoft opportunities? Microsoft's decision to focus .NET on Windows is stifling innovation due to the specter of intellectual property lawsuits

VersionOne extends agile project management solution VersionOne Ultimate Edition offers a trio of components that push agile functionality out to a client's customers

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST