Distinguishing Specified from Important

When issues arise at the workplace, it can sometimes seem like a scene right out of an Abbott and Costello bit, as one misunderstanding begets another until we and our clients are confused and unproductive. Situations like this often arise due to a lack of specificity.

Just because someone doesn’t specify something doesn’t mean that it’s not important.

In the famous routine “Who’s on First,” Abbott attempts to tell Costello the names of the players on a baseball team. The first baseman happens to be named “Who.” The failure to use specific language results in a hilarious comedic skit, as Costello thinks Abbott is obstinately refusing to address his questions. In real life, this would be extremely frustrating and result in a huge waste of resources. With any request, whether for information, or for a product or service, the specificity of language is crucial if we are going to be able to address people’s concerns.

A multitude of problems can arise when people assume that something is unimportant simply because it’s not specified. If you asked a roofer to repair damage caused by storm, for example, and you come home to find rainbow-colored shingles where there used to be black ones, you might have an issue with that. However, the contract only specified that he should tear off the ruined shingles and replace them with new ones. There’s no language referring to color. The contractor would be correct in arguing that he did what you told him to do, even though you’d also be correct in replying that he should have known that rainbow shingles on a six-bedroom Colonial is highly inappropriate. And, of course, a heated debate about specificity would ensue.

Employing Specificity
The fact is, it’s not useful to bicker about who’s wrong or who’s right, or who’s on first, for that matter. It’s much more effective to figure out the appropriate level of specificity for any given situation. We would expect the roofer, as a professional, to ask questions about details that he knows will matter to his clients. Homeowners usually care about color. Only if someone specifically stated that he wanted the cheapest price possible to ensure that the roof doesn’t cave in would it be reasonable to install rainbow- colored shingles. The professional roofer would need to ask the correct questions to determine what is important to the client to get it right the first time.

In the software business, clients often ask us for a specific feature, but the request is devoid of detail. They count on us to ask them the right questions. If we don’t, are we responsible? Sometimes. But it really doesn’t matter who is to blame, unless we’re determining who is going to pay to redo the work when it’s done all wrong. Plus, it’s hard to build a great relationship with someone when you are arguing over blame. It’s far more workable to avoid that situation at the outset. If a client wants a website, we ask questions and get the responses needed to figure out what they expect the website to do, what it should look like and contain, and any other factors that we know will matter to them in the end, even if the client doesn’t yet know precisely what they want. We lay out all the options and ask pointed questions to help them, and us, reach an understanding of what will be important in the completed project.

In any industry, an organization should have a set of questions for its clients prior to commencing a project. If the client is silent about something, it doesn’t mean that it’s not important, and it’s up to the service provider to consider the specificity that will be required to arrive at a workable outcome.

Precise Instructions Benefit Everyone
With a better understanding of what needs to be accomplished, we have both a more workable scope for the project and a more workable relationship with the client. People always speak with assumptions. The person who is making the request will assume that certain specifications are inherent, and the person who is receiving the request will assume certain specifications, as well, but they may not be the same ones. These differences can lead to issues that could definitely be avoided if the parties realized that just because something was not specified did not mean it was unimportant.

Specificity drives alignment.

The overall effect of a lack of in-depth communication is often a lot of wasted work. The roofer will have to tear off the rainbow shingles and install black ones. The website designer will have to start from scratch. Abbott will be stuck in an endless loop with Costello until either the questions or the answers are more specific. All of it is wasted time that could easily be prevented by understanding that which is important from the beginning so that the expectations of the person making the request are not overlooked. Wasted effort costs time and money, and if we want to avoid those costs, we need to pursue strategies to identify what is important, even when it’s not specified.

Strategies to Identify Important but Absent Specificity

  • 1) Pay attention to assumptions when receiving requests. Listen to what is being said, as well as for unspoken expectations. Respond carefully, rooting out any built-in assumptions and ensuring that there is alignment between both parties’ goals. Deal with any discrepancies immediately.
  • 2) Use your past experience. Consider similar projects you’ve worked on as a reference point. A service provider should have much more knowledge of common concerns than someone requesting the service for the first time. That’s why we’re the experts. We can glean expectations from standard questions based on comments and complaints we received on past projects. In software, we learn that people don’t automatically ask for certain things but will get upset about them later, so we add those items to our list of questions. We can better fulfill our clients’ needs and wants when we hold ourselves responsible for discovering their expectations before we start.
  • 3) Utilize an applicable standard. In most cases, there are industry standards that we can use to outline our specifications. For our organization, if we’re building a Web form to collect information from people who want to sign up for a newsletter, we can use an existing standard for the basics. We can then customize those standards to our own needs and styles, and add our own details. If a client wants us to write a program to transfer funds, we can use financial transaction standards so we don’t have to delineate the same items in excruciating detail. This gives us built-in completeness that we should absolutely utilize. We can also create our own standards. In either case, we must declare the standards that we will be using to our clients in advance.
  • 4) Consider what can go wrong. In fulfilling requests, think about how you could end up disappointing the client. Whether it’s rainbow shingles or an ineffective website, use the strategies outlined to make sure there are no unpleasant surprises. A good test is to ask yourself, “What could cause a reasonable person to object?” If you look at your specifications and find a potential point of contention, get more specific about it with the client.

Following these strategies drastically reduces the likelihood of failing to address something important just because it wasn’t specified, and it will increase speed and efficiency. Instead of simply jumping in and responding to a request, we can do a better job by helping our clients refine their request so we can fulfill their expectations the first time around.

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” – Albert Einstein

“A problem well stated is a problem half solved.” – Charles F. Kettering

We can create a highly workable environment by finding ways to make something right before we make a mistake. Too often, someone will say, “Well, the customer didn’t tell us they wanted that.” When we’re arguing about fault, it’s just about who’s going to suffer the waste. Yet, that really doesn’t matter, because even if we manage to be right, the client who is deemed wrong doesn’t want to deal with us anymore. A winning organization is not going to lose a client relationship over pettiness. Its team members will instead have the vision to foresee problems and solve them for the client before the project has even begun.

 

© 2012 Ralph Dandrea. All rights reserved.

Tagged with: , , , ,
Posted in Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

*