When gathering requirements for a new software application, a good consultant never really says “No.”
Really? So the client gets everything they want?
Yes!
What?!
Let me explain.
The same question comes up over and over in the requirements meetings:
“Can the system do this?” The answer is almost always “yes” from a technical/mechanical perspective. That is, what the customer wants is nearly always possible. The question that the customer is really asking, however, is this: “Can the system do that – or something similar to that – in a way that we can afford in a timeframe that we can accept?”
Oh, so we have to qualify the question within budget and time constraints! I see. But won’t that get annoying – trying to quantify every feature with cost and time frame?
Yes, so don’t try it. Here’s how a seasoned requirements analyst handles what could be a scope explosion.
First, clarity must be achieved on what the real need is. For example, if the feature being discussed is “Select a Customer,” the analyst must determine how many customers there are to choose from. If the answer is, say, 50 or less, a simple drop-down list makes sense. If the answer is 5000, obviously some form of search or filter is required. This is especially true in web applications when we don’t want to haul hundreds of records over the network/Internet so that the user can pick just one. A sizeable project will contain dozens, or maybe hundreds of these little decisions. Each one shapes the solution and impacts time and cost.
Second, the experienced analyst knows that not every feature request carries the same weight. Some features – like “Add a Customer” – will be part of the core solution. Other items – like “Copy Contact to Outlook” – will be perceived as desirable but not critical. The analyst records everything and then helps the customer prioritize functions so that the most important items top the list.
When the study is over and it’s time to decide on what Phase 1 will contain, we need two things: a feature list in priority order and a relative effort assigned to each task. Armed with this prioritized, effort-loaded list, we are now ready for Priority Day. Once the customer sees the relative cost associated with the list of items, they can draw a line that defines the end of Phase 1. That line is guaranteed to include all core functions and exclude at least some of the bells and whistles – the nice-to-have items recorded during the study.
What has happened? When did the analyst say “No?”
Never.
So how did some items get removed from scope? The customer did it. When the customer draws the Phase 1 line, they essentially mark all items below the line as “Later.” Even the customer hasn’t said “No.” They said, “Not yet.”
As you might expect, some of the features below the line are never built. This is a good thing. The budget changes, priorities change, the company or industry changes and the customer decides not to implement these features. Scope is reduced. Money is saved.
Experienced requirements analysts move swiftly through feature extraction by avoiding arguments over cost and implementation details. They let the customer control scope, budget and schedule by giving them the power to make decisions – to prioritize – when they have enough information.