The phone rings, and soon you’re racing to complete another project. The client has briefly outlined what you’re supposed to build. This phase of a project is exciting; it’s a whole new world, and you haven’t had a chance to wear yourself out finding the latest bug or making the next deadline. You also haven’t had to deal yet with feature creep: the endless string of requests for new features and functionality as a completion date looms on the horizon.

Stop it before it starts
The requirements-gathering phase is your only chance to ensure that feature creep never rears its ugly head—or at least that, if it does, it’s on your terms. You need to know which people to interview to learn what they’re trying to accomplish, what budget you have to work within, who you must consult before proceeding to each new project phase, and—most important for protecting your hide—which people have the authority to sign off and say that the company is committing to the item presented.

Identify a single point of contact. This person will help ensure that things run smoothly between yourself and the client, and save everyone from miscommunications and lost time in trying to track down the appropriate people throughout the project.

Don’t let anyone rush you through the spec-building process. On the flipside, don’t let anyone drag it out. This is imperative, both for your sake and for the company’s. After all, getting sidetracked by talking to the wrong people makes the company wait longer for its solution, and the bad blood generated can poison the whole project. Set a reasonable time limit for building the specs and a fixed number of times to show the client a draft for comments before you start charging extra. Generally speaking, you’ll want to give the client at least one opportunity to comment (or two times for a complex project).

Lock down the sign-off authority
In the document, clearly define who must sign off on the functional specification and provide business-side feedback to the development team. This action puts the burden on the client to make sure they gather their people rather than making you chase them down; if they wind up with a full committee, you’re protected from their trying to make you go back and forth for months. Present this policy as a win/win. The client gets the project specs done efficiently, meaning that you get to the project as quickly as possible, and they know exactly what to expect.

After the spec is complete
Once you’ve got it laid out how to build the spec, it’s time to get to work. Make sure every aspect of the deliverable is covered, from what the user should be able to accomplish with the software to what data must be stored in the database. Don’t overlook little issues such as graphics limitations; what user level(s) you’re building for; online vs. bound and printed documentation; and what architecture(s), operating system(s), and hardware limitations the package must accommodate.

Get sign-off after each milestone
If you’re dealing with a large project, divide it into logical phases. Not only does each phase involve a sign-off point, but you also build in perfect spots to get paid! Good places for phase endings include completion of a demonstration version (if required), reaching specific feature milestones, completing a first draft of the product documentation, completing alpha testing, completing beta testing, and of course finishing the project. Work out the phase milestones with the client.

Review costs at every milestone
You now need to estimate the costs before moving on. There are many different approaches available to emulate, and I typically suggest studying as many as you can find and then mixing and matching. For some items, you’ll need to know how much you’ll have to pay a third party, such as for hardware. With others, you need to estimate how much of your and others’ time must be spent, and on what kinds of tasks. You then have to block out how much you need to pay the contractor or employee for each type of work, and then build in your mark up. It’s a long and complex number-crunching process, but it’s absolutely necessary. If you don’t like working with these kinds of details, pay someone else to assist you. It’s worth it.

The final spec
Once the requirements document is finished, add a section that details the costs of expanding the requirements in terms of both time and money, and make it clear that such expansion includes the client’s wanting to make any changes after the final sign-off for a particular phase.

Finally, with your complete specifications document in hand, arrange a meeting with the client—including all the people who need to sign off on the initial version—and send it off. Be sure you give the client enough time to thoroughly go over the specifications when scheduling a meeting: Depending on the length of the document, you shouldn’t expect a group of people to have fully absorbed the material in a mere 24 hours, or even a week.

Fighting feature creep

How do you lock down a spec? Tell us or post a comment below.