Thinking About Getting Naked on New Business Analysis Projects

Share This Post

A few months ago, I was in between projects and looking for ways to improve as an analyst/consultant, so I decided to read a book from the ArgonDigital Leadership Development Program’s recommended reading list, called Getting Naked.

In case you aren’t familiar with the story, it’s about a large consulting firm that gets the opportunity to learn how a much smaller, competing firm has been winning clients.  The smaller firm uses a “naked” approach to consulting, and one of the principles of this approach is asking what may seem like obvious questions.  They believe it is good to be vulnerable and admit when there are things you don’t know, but also that there are bad questions. I’m paraphrasing of course, but the idea is that there is a difference between not knowing and being incompetent.

For a senior consultant, it is often easy to distinguish necessary questions from bad ones. However, as you can imagine, this could put a new consultant in a confusing space.  How does a new consultant know what they should know or what it is okay not to know?  I am not new to consulting, but I am new to software development, so as I read the book it reminded me of questions that I’ve had but that I was unsure if I should ask.  Even though the book encourages bravery and suggests that others probably have the same question, the book is also about very experienced consultants.

ask questions

So for the newer consultants or consultants that are new to their respective industry, I recommend not asking the client all of your questions.  Instead you should start by “getting naked” with your team.  Write down your questions and then ask a more senior member of your team.  It may be an awful question that you regret the moment you say it aloud, or it can be a great question from a perspective that hadn’t occurred to them.  But at least you can do it in what should be a safe space without damaging your credibility with the client or the client’s perception of the team.

More To Explore

Defining requirements and specifications

Defining Requirements and Specifications

Why Defining Requirements and Specifications is Important I have been asked this question, or some variation of it, many times. This question is akin to