In every project I work on, there is an initial discussion on scope. In the almost decade of working on tech projects, I have never had a client who had a perfect scope in mind. There is a process of discovery where you delve into the goals, needs, desires of the client. Even when that process is smooth and everything is documented to a tee, as the project moves forward the client begins to see how things can be made better here or there.

A good example might be discovering that sorting a list by last name might achieve one business requirement, that requirement could be enhanced by allowing sorting by date.

In other words, there isn't ever fixed scope. This is the case because we, as vendors, really want to please our clients. We want them to have what they want. Eduard Liebenberger wrote a great article on the tensions of scope.

So how do you combat scope creep? How do you control it, master it, and squash it?

You can't.

So the solution is to embrace scope creep. That is central to the Agile method of development. Essentially, you need to be able estimate the time it will take to develop the site. If the client has a limited budget (and nonprofits often do), there needs to be a frank conversation at the beginning of the development process that discusses the need that if a new element is inserted, something equal needs to be removed from the scope. This, of course is very difficult.

So it becomes a game of identifying priorities and including the client in all aspects of this hard decision making process.

So create a plan. Carefully architect your project. Document all the functional needs. Then, be ready to be agile and adapt as the understood needs change....just not so much that the project fails.

Powered by Qumana