The Fundamental Framework That Grew My Career

Starting anything new can be a tough and scary experience. What if, you had a framework to help you navigate? The most successful training programs not only give you a plan of what to do, but also guidelines within which to operate. Here are the guidelines that have helped me progress my career so far.

As you gain experience in your working career, what comes to the fore is not just your ability to answer questions and come up with solutions, but rather the types of questions you ask.

When you start out in a job (and to some extent in life), all we ever look to do is come up with solutions to our problems. Answers that shall lead you down the “right” path. And in a way, make sure that we do not suffer any discomfort.

At work, especially in a new role, people often go about trying to understand what they can fix. But it is always prefixed with the question, “why” is it that this thing needs fixing. Yes, you are hired to “do” a job and knowing “b” you need to do comes first, make sure that you also understand the “why” you are doing it.

In my professional career, I have been asked to undertake a piece of automation work.

Most of the time, this is usually done with Microsoft Excel using VBA. The challenge with VBA, is that everyone writes it differently and there are no standards set out – either globally or within a company. This often means, that once something is automated, the creator is left with the responsibility of maintaining the new application. And whenever amendments are requested (and you’re almost guaranteed of this), what started off as a simple automated task grows into a complex behemoth that potentially requires a team to manage. The last thing any company needs is a bespoke solution that suddenly becomes business critical. I am guilty of creating such solutions plenty of times in my own career. But thanks to a few good mentors, I have learned how questions can reveal assumed or overlooked items.

From years of heartbreak and hard work (and often lots and lots of frustration from both developer and requestor), I have developed a mental framework that helps tease out and identify any niggling or unspoken ideas.

It takes the best of two worlds and combines it. Part System Development Life Cycle, Part Kaizén.

CRUD (Create | Read | Update | Delete) is the basic building block of how users interact with your system. By overlaying this with the 5Ws and 1H questions within these different scenarios, you are helping to build use cases.

Thus giving you:

Who     (C) | Who     (R) | Who    (U) | Who     (D)
What   (C) | What    (R) | What   (U) | What   (D)
When  (C) | When   (R) | When  (U) | When  (D)
Why     (C) | Why     (R) | Why     (U) | Why     (D)
Where (C) | Where (R) | Where (U) | Where (D)
How     (C) | How     (R) | How     (U) | How     (D)

Depending on the level of experience of your stakeholder, I choose to start with the What or the Why. “What” always gets the conversation going. This is the most exciting part of any project as you’re asking them to imagine their end scenario. What they see success looking like. I like to pay close attention at this phase because often there are underlying assumptions being made that even you might not be aware of.

Once this is locked away, you need to ask them “How” they intend on measuring this success. This will give you the metrics that will stand as the yardstick of your progress.

After this, I tend to ask “Why”. During my time, it’s always been “because we have to”. On the rare occasions when this is not defined, you open up another world to their eyes. The why helps drive your messaging, how you communicate those changes to the people in the operations world or how you deliver it to your end customers.

I know some people say to start with the Why. And I appreciate it too – I love Simon Sinek’s TED talk as much as the next person, and what I have found from personal experience is that this is the model that works best for me. If you are going to give it a shot, try it and make it work for yourself.

Now comes the fun part of any development work: design!

You have the end goal in mind. You know what the stakeholder wants.

You are ready to unleash your programming/drawing/reporting skills to the world! You will achieve wondrous things!

Hold up.

We still need to work through the CRUD module of this framework.

Using an imaginary conversation between a stakeholder (SH) and myself (ND), here’s how it transpires.

ND: Who should be creating entries/records? [WHO]

SH: The analyst (or role/or name of a person)

ND: Ok, and what should they be entering? [WHAT]

SH: Date, Reference ID, Location, Items and Quantity.

ND: Should the Reference ID be automatically generated? [HOW]

SH: Yeah! Great idea – it will be an automatic increment to show how many items we have. But what if they make a mistake and have to discard it?

ND: Easy, we can make the system save at various intervals or an inbuilt function that allows the user to either complete this entry later or discard it and start over. [HOW]

SH: No no, we should definitely save it as a draft.

ND: That means, we would need a status of the entry too? [WHAT]

SH: Yeah, I guess so.

ND: Should we be validating these entries? [WHAT][HOW]

SH: In what way?

ND: Well can we backdate or future date things? Do we want quantities to be whole numbers or are we allowing for decimals and if so, to how many places? When we add more items, would you want this entry to keep expanding? [HOW][WHAT]

SH:…well the Manager will need to validate the entry before sending it out.

ND: Will the Manager have different rights in comparison to the Analyst? [WHO][WHAT]

SH: Absolutely – one can only create and read whilst the other can amend. Though, when I think about it, I don’t want the Managers amending something once it’s passed a certain stage.

ND: There are a different stages to this entry? [WHAT]

SH: Yes, of course.

As you can see, it is a whole raft of questions that can unravel the assumptions being made. And we haven’t even left the “Create” scenario.

After Create, I move into the Read menu as it makes the conversation seem easier to comprehend. The headiness of the Create is masked by the simplicity of the Read – but what it does, is set up the conversation perfectly for the Update and Delete scenarios.

Now, you have your entire set of rules to define your next masterpiece. Still, I wouldn’t even touch the build phase. Outline these requirements, send it back to your Stakeholder to verify it and then once they are satisfied with not only “What” the system will deliver but also the “How”, you will then be able to move on to the build phase.

This matrix has never failed me for the last 5 years. My recent roles (in Risk or in Funds Management) have shown me the need to ask better questions – and I now include questions around backups, access to the overall system, reliability, accuracy and storage. All of these will go a long way in helping you to come up with a new solution.

Feel free to try this framework out for yourself. When you do, I would love to hear how you went with it. Please leave a comment below and I will respond to each and every single one.

To your gained knowledge dear reader – apply your learnings well!