I heard about a concept this week that I like, which is the phrase, “Dealing With Ambiguity”. Now, this is a pretty straightforward phrase, but the context in which I heard was very interesting. It was the idea of this being a very specific skill that can be practiced and trained.

In the area of software and systems development, dealing with ambiguity is pretty foundational to the entire process. Let’s look at the following example, which is a scenario that I was discussing with something this week and has also occurred to me in the past. A customer comes up to you and hands you a paper form and says that people fill out this form with a pen and mail it in and then that data needs to be entered into a database. So the simple request is to create a website where the user can enter the data instead of mailing in a paper form.

That’s it. That’s all the information you get.

There are a lot of unknowns here and a lot of ambiguity. How do you deal with it? There are a couple of ways forward.

Ask for more requirements

A first step that I have seen people do in this situation is to proclaim, “I need more requirements. The customer needs to give me more requirements.” And they don’t move forward at all. Instead, they halt all progress and insist that the customer needs to provide more requirements.

I have a saying I like to use in response to this specific scenario, which is, “If you are waiting for the customer to deliver to you a set of well-written, complete requirements, you’ll just be waiting forever.” I’m sure there are extreme edge cases but in my experience, the customer will never deliver you all the requirements you need. Part of your job is to figure out the requirements.

(I will concede that there are certain times where this is the required way forward. Some situations have specific legalities around the work, in terms of contracting and expending effort, and the necessary approach is for the customer to provide a specific set of requirements and you are just building exactly to the specifications. I do understand that this situation exists, but I will still emphatically state that there is a large amount of risk involved, and there is almost always a lot of rework that will need to be done.)

Ask good questions to elicit the requirements

In formal engineering or project management training, the recommended next step is more advanced than just asking generically for more requirements. Instead, it’s leading the customer through a conversation of questions designed to draw the requirements out of them. For our example above, of putting a paper form into a web app, there are a lot of questions that can be asked that come from experience:

Are your users on web browsers, or mobile devices?
Is there an existing database to put the data into?
What kind of reporting do you want to see, of the data?
Are your users worldwide, or within some geographic region or even a specific corporate network?
How many users are we talking about here?
Are there any requirements or constraints on operating systems? Security and compliance? Language or framework to use?

And so forth.

Leading the customer through a whiteboarding session or two can help define a lot of these requirements and get your development team the information they need to move forward.

Start iterating forward

There’s another option here, on how to handle this scenario. And that is to go ahead and build a working demo. To be honest, having a copy of the paper form is enough for a developer to put together a web-based form matching the fields, and pushing that data into a simple database. It’s also fairly straightforward to have some table or grid-based reporting, some simple search functions, and so on. I suspect many web frameworks have this exact scenario as a demo or sample project, and all you would need to do is change the fields. This entire demo could be created and deployed in literally just a couple of hours.

Imagine, if instead of having a meeting with the customer where you show up with a blank piece of paper, asking for more requirements, you instead show up with this working demo. And now, in a very Agile-based way, the conversation is how to iterate forward. You can talk through the app, start adjusting things like authentication and reporting and data validation and start talking about deployment scenarios.

Now granted, this approach requires someone with experience to be able to whip up the demo application. But I love this approach because right out of the gate you are showing your customer that you are willing to get going on the project as opposed to “just scheduling another meeting”.

…

As you can see, there are several options you can take for dealing with ambiguity, but they each require progressively more experience in your domain and technology. If you don’t know anything about your customer or the problem domain, then you don’t even know what questions to ask and you will just need to generically ask more questions. As you learn more and more about your customer you can ask better questions, but the goal is to be experienced and knowledgeable enough that you can accurately predict what your customer needs and deliver them something that is already partway there, even if they didn’t explicitly ask for it.