Questioning (the) Authority

As Mark K. Smith summarized in an article he wrote about Polyani:

Polanyi’s argument was that the informed guesses, hunches and imaginings that are part of exploratory acts are motivated by what he describes as ‘passions.’ They might well be aimed at discovering ‘truth,’ but they are not necessarily in a form that can be stated in propositional or formal terms.

I am a project manager at Happy Cog. I can draw quite a few parallels to Polanyi’s observations, which were based on the application of scientific knowledge. His philosophies are just as applicable to a project manager’s world of requirements discovery as they are to the philosophy of science.

A key objective I always try to achieve is to determine how a person develops, maintains, and assumes certain knowledge that may be extremely relevant during an act of discovery, but ultimately overlooks or discounts that information because of personal familiarity. This creates an interesting challenge in the first stage of managing any project. How do you get your client, the subject matter expert, to provide you with the crucial details needed to fulfill the project’s purpose?

The devil is in the details

To get a good idea of the impact of “tacit knowledge” on discovery, try this experiment out on a friend: ask them to describe the steps of operating a vehicle. Note their responses. Pay particular attention to the details.

• Did they describe getting into the vehicle without identifying that they opened the door first? Buckling their seat belt?
• Did they describe the act of driving without having described placing the key into the ignition? Turning the key?
• Did they overlook applying their foot to the break/clutch before engaging the gear shift?
• Did they talk about looking to see if the surroundings were clear before moving the vehicle?

The point is, don’t be surprised if there are small, important details that are blatantly omitted because they are assumed. Checking rear-view and side mirrors is extremely important, but also second nature. Drivers become so used to executing certain actions that those very actions have become involuntary. So, applying this exercise to project management, how could missing details like this alter the outcome of your project? Ask Judy, the head of accounting, what steps she follows to complete her quarterly audit. How will the new website or web application fulfill her needs? Chances are, during a high level Q&A she omits multiple steps from her explanation. Subconsciously, she may deem those steps unimportant, or she might not even realize she performs them at all. Regardless of why, if we leave the discussion too high-level, we’ve missed an opportunity to get what is truly needed to meet her expectations or those of the end-user.

I have been a part of a lot of meetings discussing business process with clients. During these sessions, the subject matter expert I am speaking with usually uncorks a fountain of knowledge so voluminous it’s like drinking from a fire hose. I can only nod my head and try to type or jot down notes as fast as I can. When the session ends, my head is spinning with new-found knowledge, and I’m trying to plan for what comes next while simultaneously trying to absorb what I just heard.

Is it any wonder details get missed? How do you get things back on track? The answer is to spark some bilateral communication with a bit of hand-holding.

Guide with structured questions

My suggestion is simple, yet effective: establish a core set of questions that you will deliver to your client on a writeboard in Basecamp or in a Word document. Before you unveil them, be sure you understand what you are asking, and why. Ask yourself the following questions before proceeding:

• What is the purpose of my discovery?
• How will the questions I ask help me more clearly define what can realistically be accomplished during the project?
• Do I understand my client’s business?
• Can I set expectations?

If you are confident you know the answers, you can feel confident in posing your questions to the client. The questions should start broad, like:

• “Will your site have a blog?”
• “Do you accept donations through your current site, or would you like to add that capability on the new website?”

Use your client’s responses to ask other, more detailed questions. With each response, you develop greater insight into your client’s needs, but you also create an opportunity to educate them. Each feature/function has an implicit or explicit cost, and as your client understands this, you’ll find scoping becomes easier. An example:

1. “Will blog posts have comments?” leads to
2. “Will the comments be moderated?” leads to
3. “Will the moderated comments be threaded” leads to
4. “How many threads will be presented?” and so on…

Through a series of structured questions, we’re able to map the expected interaction with each feature/function. This also qualifies the features/functions needed for the content management system (CMS) that drives the site. Some may be available with the CMS “out of the box,” others may be available via extensions or add-ons, and some may require from-scratch custom development. Each carries a cost. The more your clients understand the cost of features, the less likely they are to ask for things that don’t support their business objectives. Start big, end small.

Tacit knowledge dictates that you need to dig below the strong personal convictions and familiarities people have in order to get to information that is truly valuable. Providing a well-constructed question-based system is one way to cut to the quick. I haven’t been able to find a lot of stuff written about this topic, so I invite you to share your methods on your own blog, and link to it from Cognition.

Back to Top