Most software development projects have specifications; thinking about specifications in terms of scope can be more difficult. Briefly, it’s hard to describe the scope of a software project in ways every stakeholder can understand.
Here’s a metaphor. If I’m talking to an architect, and I mention the size of an office (say 10×12), the architect likely has a good idea of the look of that office. He knows what will fit in the space. He can categorize it as large, medium, small, or very small. I can’t. I can compare it to the size of a house. I have a sense that 3,000 square feet is average in certain neighborhoods, and 20,000 square feet is huge. Some people, though, might think that 20,000 square feet is a bit constricted. The architect has better visualization ability than I do.
So it is with business end users and programmers. When we say web application, we understand the environment as well as its strengths and limitations. Most of our clients don’t. We know that adding a piece of information or two to a screen and the file associated isn’t much trouble, but having the computer understand speech is a lot of trouble. More importantly, a piece of software with 1000 hours of work in it may look similar to a product with 10,000 hours of work. A 20,000 square foot home will be noticeably bigger than a 2,000 square foot home. Not so for software.
So how do we establish scope? There’s really no magic. The key is communication. Programmer to business user. Business user to programmer. “If we add this, it will take this much effort.” “That’s no big deal.” “That’s a major project.”
The biggest thing we’ve learned in the past few years since we got rid of hourly rates and time sheets is the importance of communication about scope. Scope creep extends the project. It raises cost. Constantly evaluating scope is the way to make sure business requirements are met and projects stay on time and on budget.
Here’s more information about our software development services.