29 May 2003

by Michael Mah, Senior Consultant, Cutter Consortium

Recently, fellow Cutter Senior Consultant David Herron and I were privileged to be the featured speakers at a chapter meeting of the New York City SPIN (Software Process Improvement Network, http://www.nycspin.org). It was billed as a CNN Crossfire debate, and the topic of the session was “Why Size Matters.” (Luckily, the e-mail announcement didn’t include that in the subject line, otherwise the message undoubtedly would have been blocked by SPAM filters.)

In this case, we were talking about software size metrics. Here we were, two industry consultants debating subjects such as function points — and we drew a very large crowd. Perhaps arguing these things a la Buchanan and Press is what people want to see. CNN has a proven formula, so why not emulate it?

Regardless, the event was great fun. The forum allowed for lively debate followed by a town meeting of sorts to discuss challenges such as productivity measurement, project estimation, long-term IT trends, project governance, outsourcing, and other related issues. But right off the bat, it became clear that we had to address the tongue-in- cheek question “Why does size matter?”

My approach to this was to quote my friend and colleague Ed Yourdon, who once wrote, “If you underestimate the size of your project, it doesn’t matter which methodology you use, what tools you buy, or even what programmers you assign to a job.” In other words, if you think a project is the equivalent of a little league ballpark, and it turns out to be more like Yankee Stadium, your goose is cooked. Forget about making the deadline or finishing within budget — the sheer volume of the project can guarantee that the team won’t make it. Size risk, scope growth, feature creep — whatever you’d like to call it — has doomed the project.

In a Cutter Consortium study conducted last year on the state of software estimation (the “struggle with the beast,” in the words of Rob Austin and E.M. Bennatan), 72% of the respondents reported that they resort to overtime to resolve problems from underestimation; 69% of the time, the date is slipped; and 48% of the time, product features are removed. In sum, underestimation results in burned-out IT professionals, late projects, and reduced functionality for the customer or end user most of the time.

Part of the problem lies in the fact that many IT professionals don’t perform size estimates on their projects because they mistakenly equate size with effort. “What was the size of your last project?” I once asked a project manager. “Big,” she replied. It was more than 8,000 person-hours. “And how large do you think the next project will be?” I continued. “Really big,” she replied, “we’ll probably staff it with more than 20 people.” At first, this might seem to make sense. When we think of size, it’s not surprising that a common reflex is to give an answer in effort-hours (which correlates with dollars spent) or head count. These two things are perceived as tangibles that you can see, feel, and touch.

But as a consultant in software measurement and estimation, I find it vital to think of size in terms of the scope of a project. That’s the issue that people negotiate. It can include the amount of features the client wants, the number of work requests, the quantity of the requirements, or the number of use cases. In agile development, size might be expressed as the number of user stories. In essence, we’re talking about the degree of functionality. To implement this functionality, a team might design and build a number of programs, objects, or classes, representing a certain amount of function points or lines of code. All these ways of expressing size can be valid. Sometimes the code is entirely new. Other times, the strategy may involve purchasing a package and writing additional code as bolt-ons and interfaces. Another scenario may involve writing new software and modifying a subset of an existing application, then integrating and testing the entire package to make sure it all hangs together.

To me, confusing the size of the project with effort and cost has serious consequences. It neglects the conversations about project scope and the negotiations that set up resultant expectations on the ultimate product.

Project size is also a major component of risk management. It’s a fact that, all other factors being equal, as projects get larger, they take longer and cost more. So when a project grows in size because of underestimation or increased demands in functionality while the deadlines and staffing budgets are held fixed, a Death March Project is born.

Henry Kissinger once said, “Competing pressures tempt one to believe that an issue deferred is a problem avoided; more often it is a crisis invented.” I’m sure Dr. Kissinger wasn’t referring to software and IT projects, but the adage truly applies. In my opinion, if you don’t address sizing and the negotiations that have to take place around project commitment early and repeatedly — at crucial milestones of a project — statistics show that you ultimately will pay dearly in the form of overtime, missed dates, and cuts in functionality. Worst of all, these impacts will occur late in the project, when it hurts the most. There are no winners on either the developer or the client side. This is the crisis invented.

But being the eternal optimist (because I’ve seen the flip side), organizations can be successful when they proactively address sizing questions, practice risk management, use win-win negotiation techniques, keep good records to assess historical precedent, and implement more reliable cost and schedule estimation methods. These groups experience better-negotiated outcomes, reduced conflict, and achieve higher levels of project success.

— Michael Mah, Senior Consultant, Cutter Consortium

© 2003 Cutter Consortium. All rights reserved.