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 often 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, understanding 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 cares about?

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. Understanding what your sponsor is looking for is absolutely critical to the project success

“Why” questions

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.

“What” questions

These questions can help generate more specific answers about requirements and out comes. They are great for identifying gaps in a orogram, because they demand that more context be provided.

Sometimes “why” and “what” questions can be used interchangeably, based on the context. Here are a few examples to get you started:

What is your program objective for the end of this year?

Do you have a deadline for the release date? And what drives the date?

What information is the executive looking for from this program?

Are there any regulatory and compliance deadlines with this program?

What are the top three things you want to change in your old program?

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.

Give an example

As simple 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 if 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 things 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 approved. 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 requires 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. A good 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 design 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 vs. tactical

• Strategic questions seek to paint a picture of the future, and the path to the future
• Tactical questions zoom in to a particular concern, and often involve technical details

Outcomes vs. features

• Outcome-driven questions focus on the objectives of the program
• Feature-driven questions focus on the appearance and behavior of a specific design task

Must-have vs. nice-to-have

• “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
• A good design delivers on the key objective, balanced with attention to the details.

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 miscommunication.

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 taking 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 organization.

‍