One of the struggles with working as a consultant is clients that want everything in the world (and are willing to pay for it), yet don’t focus on the features or items of their implementation that they really need, and sometimes that is written directly in the statement of work. This happens in the corporate world, time after time. Clients are just like everyone else where the features that sometimes come from the CEO but have no return on investment associated with it.

Here’s how I work with clients to help define what they need instead of they want, and I’ve included an  Use Case Prioritization Excel Template to start with. It’s simple, and meant to be that way, because long documents aren’t read.

Make a list of use cases that are relevant to the implementation

This is where I always start — what are all the percieved use cases the client needs for system success? When you develop requirements, there will always be additional use cases that will come out of disccusions,  the client’s going to have a pretty good idea of what they need to start with, because they called you, right?

Keep the assembly of this list simple, like an Excel document, and that document would have such fields as the use case, who the use case sponsor is, the opportunity, the cost (do a rough swag on this, and more often than not you are going to be 50 percent off because of unstated requirements), the priority (high, medium, low, or an agreed on numbering system as in the example document), and other notes. The sponsor’s important because like it or not, a CEO’s much more important to the project than a QA lackey.

Rank use cases based on importance

Some of the use cases will be absolutely necessary (i.e. if you are working on SharePoint, editing of pages and user permissions would be an absolute requirement). Some requirements, however, may not be as important, such as  localization.

Even if that is a requirement, you can have two stages of implementation, planning for localization as a stub and setting up URLs for this versus a full implementation. Because of this, I would list this as two separate use cases, judging this as the simple versus complex implementation.

The importance should be judged on the opportunity, cost, and whether or not it’s an important feature for launch. One of the things to remember when developing use cases is that some can be accomplished through manual processes, like having the database administrator change data through raw SQL if the task doesn’t happen very often. No feature that has only an impact of making or saving $500 a year should be implemented, period.

Develop the system based on that list

The list is your bible for development, and if you stray from it, the development process goes awry. This list can also change; if you get a few iterations down the path, you can reorder items based on changing priorities of the client (or your project sponsor). Remember, this idea is to keep the features light and iterative so changing requirements don’t mean reordering the whole list or building a completely new system.

Keep track of progress with the list

Sometimes with software development, progress is the invisible path that no one sees. If you use the use case prioritzation list of keep track of where you are at (hopefully with honest developers giving you feedback), both the development team and the client will get a true nature of where they are at. In some situations, several use cases might be co-dependent on the same development components, and that should be noted.