Designing GRC – Asking better questions
Technical challenges can be difficult to solve, but the
hardest part of any design exercise isn’t technical at all. It’s understanding what the business is truly asking for, beyond a checklist of features.
When I ask “What is your dream house?” people rarely know exactly what they’re
looking for. If I show somebody pictures
of a house, they can quickly tell me what they like or dislike about the house.
Often when people don’t know what
they want for their house, they substitute my first question with another: “What features do I want in a
house?” All kinds of answers come back: a swimming pool, big windows, a
kitchen island, a two-car garage…
Designing for a GRC solution has
the same challenges. Focusing on the features will of- ten result in an
overwhelming list of processes, complex and restricted workflows, and a complicated user interface. The hardest
part of design is to uncover what will truly make a positive impact for the user. So how do we do that?
Start at the top
Every project needs approval from
a sponsor, typically somebody from
the executive team. Given the significant investment and
strategic impact a GRC program can have, under- standing what your sponsor is
looking for is absolutely critical to the project success.
When you are buying
a new vehicle, the look of the car and the loudness
of the engine may not be as
important to you as comfortable seats and safety for your family on road trips.
Likewise, when it comes to GRC,
focusing on what the executive expects as an outcome will help you to stay away
from designing a complex system with, say, 100 system logic checks to prevent a
workflow scenario that will break every 1 out of 100 times!
Understanding the key objective in
mind for the GRC program executive sponsor is
critical, but how can you be sure that you know precisely what the executive
Starting with half of the answer
Asking the right questions is half
of the answer. The reality is that
you may not be able to talk to the executive sponsor to get a clear sense of the vision,
and not every executive has a
clear vision in mind, or can articulate the vision for you. Here we will review some ways to initiate the conversation, ask
questions to engage thinking, and get answers to help shape the design.
Get the conversation going
When the party you are engaging with has a clear sense of
what is needed, use “why” and “what” questions to elaborate and
further gather information for your design purpose.
GRC Solution Consultant
Understanding what your sponsor is
looking for is absolutely critical to the project success
These questions help to develop
a deeper understanding of the request,
and to discover the core reason
behind a request. These types of questions can often define
the direction of the conversation.
A car salesperson might ask: “Why do you want an all-wheel drive
car?” The buyer might reply: “I
want a vehicle with great traction control to help stabilize the vehicle during
the tough winter seasons.” There’s
a good example
of how you can shift
from a feature-specific conversation to an outcome-driven conversation.
These questions can help generate
more specific answers about requirements and out- comes. They are great for
identifying gaps in a program, because they demand that more context be
Sometimes “why” and “what”
questions can be used interchangeably, based on the con- text. Here are a few
examples to get you started:
is your program objective for the end of this year?
- Do you have a deadline
for the release
date? And what drives the date?
information is the executive looking
for from this program?
- Are there any regulatory and compliance deadlines with
- What are the top three things you want to change in your
- What are the top three improvements your team is looking for?
- Why is the ability to have this automated important?
- What is the reason that you want to notify
every user of every change?
One particularly effective question that you
can always ask is “What
is the problem that we are trying to
solve here?” When a clear outcome is missing, you may
be able to start with the problem (or problems!) at hand.
To automate a GRC solution, we are often
asked to improve
process efficiency, ensure
data quality, gather
more data for better decision
making, and so on. Understanding the specific
problem to solve will help to define
the objective for the design.
as this sounds, analogies and examples are great ways to get people thinking. When a question is receiving very little response,
it is often helpful to elaborate on what
you are looking for, and then
add an example
of what you
have seen from
past experience. This gives people a starting point to begin elaborating on what they want.
Think back to when you bought your
first car. Did you know exactly what
you wanted from the start? Or did you first go around to see and test drive a few cars? In the GRC world, we can often start with the industry
standard model, which shows how most people do
Understanding the specific problem
to solve will help to define the objective for the design
“What is the problem that we are trying to solve here?”
in the industry,
and if you are an experienced SME, you could
offer specific advice
to guide the design.
Some examples of how this conversation can go:
“The new AML act is going to be in
effect this year, and many financial institutions have added this set of
questions to prove compliance. Would this be important for you as well?”
“Typically a test is performed after the plan has been created,
reviewed and ap- proved. Is this also how your tests are being conducted?”
“An issue is assigned
to an owner to follow-up. The issue can be accepted
which requires an exception request to be submitted; or it can be remediated which re- quires a
planning and remediation execution process. Does this align with your process as well?”
“I’ve seen other organizations
struggling with building a real-time dashboard showing the high-risk vendors
and their statuses. Is this an issue that you are also concerned with?”
Keep your objective in mind
Depending on your audience
(strategic vs. tactical), your focus (outcomes
vs. features), you will be able to draw a list of what
are your “must-haves” and your “nice-to-haves”, as well as what are your current objectives and your future
objectives for the design.
rule of thumb
is to focus on the outcome, and re-frame the
way you ask
questions to reinforce the outcome, the end-goal, or the objective. Features and the specifics at de- sign
level often leads to great effort but minimal impact.
Business executives often look at the
strategic direction and are outcome-focused. Their “asks” typically translate
to must-have requirements.
- Strategic questions seek to paint a
picture of the future, and the path to the
- Tactical questions
zoom in to a particular concern, and often involve technical details
- Outcome-driven questions
focus on the objectives of the program
questions focus on the appearance and behaviour of a specific design task
- “Must-haves” are requests that will
make the project fail if not delivered
- “Nice-to-haves” are features that may please
users or certain
stakeholders, but are
not critical for project success
Re-frame the way you ask questions to reinforce the outcome,
the end-goal, or the objective
design delivers on the key
objective, balanced with
attention to the
details. Keep- ing your
objective in mind will shape the questions you ask, and in turn will shape the
answers you get.
Lastly, let’s keep your questions simple! Use analogies when
discussing complicated topics, and use active listening skills, and paraphrase
answers back to ensure clarity and prevent mis-communication.
Wrapping it all up
The hardest part of design is
understanding what really matters. This often starts with the vision of the
top executives, and is then completed by the features the team want. A design should focus on the outcome, while
making it easy for the user by implementing user-friendly features when appropriate.
With a good design, we look to
improve organizational effectiveness, increase the value of your GRC
investment, and set the stage for future growth of the GRC program and the