Ask forgiveness, not permission

In a recent interview, this question was posed to me: “What is your approach to gathering and writing requirements?”

It seems like a simple question and many people would respond, almost blithely, about “use cases” or “blue sky sessions” or whatever buzzword or methodology that they feel that is their approach. In reality, those are all tools – they have merit and are valuable, yes, but they are not your approach.

So on the surface, the question was simple. In reality, the interviewer was trying to suss out my guiding principles, my communication skills, my relationship-building (or destroying!) skills… she wanted to know not the steps to how I dance but the style of it.

So, this was my answer:

  1. Ask for forgiveness, not permission
  2. Where and when possible, work from “back-to-front”
  3. Make it fit-for-purpose

During the interview, of course I only gave a few more words around each, but here, I am going to give quite a bit more than that because it is worth putting it into context. Today, I’ll start with the first one, asking for forgiveness and not permission.

Never forget we are all different people. I, myself, am a career “change” person. I like to do projects, see the benefit of said projects, and do something else. It allows me to learn something new every few months, to meet new people and do different work, and that all forces me to stay on my toes. A line job, on the other hand, is reliant on being able to do the same thing, day after day, on a schedule, conformed to a process, as cleanly and efficiently as possible. People like me make up those processes; line, or operational folks, execute them. Put me in a line job and I would rather you just pull my teeth out, sans novocaine. Put a dedicated line person in a change role, and you’ll see the same reaction. Therefore…

We do not think the same way and that means the entire process of gathering, writing, reviewing, and approving requirements can be an entirely alien concept to someone on a line job, and that is perfectly fine. The first time someone is put on a project from a line role, even to work as a subject matter expert (SME) or “project advisor,” the terminology can be bewildering, the personalities likewise, and the activities almost nonsensical. I believe one of my jobs as a business analyst is to smooth that process: make it work for them because the reality is I have all day to sit around and just think about “how to make it better”; they do not, and rightfully so, they resent the additional pressure it takes to now deal with us ‘eggheads’ who are messing up their system. A friend who made the shift from line to change explained it to me this way once:

“It’s not that we don’t want our jobs to be easier and faster. It’s just that our daily requirements never disappear; our deadlines are always the same. We literally don’t have the time to teach you what we do, to learn the new way you want us to do it, and risk missing our deadlines until we adjust to the new, better process. We know it’s better, but you are messing up our lives. We get that after the initial period, we’ll have relief, but in that moment, you are nothing but one more headache, one new obstacle, to us succeeding at our jobs. You. Are. The. Problem.”

Therefore, how to be less of a problem is something I have learned to keep in the back of mind. My way to mitigate the problem that I represent is to do as much leg work on my own before I even approach my assigned SME.
+  I read everything I can get my hands on.
+  If there are videos, I watch them
+  If there is a book I need to buy, I buy it and absorb it
+  If my peers have worked with a group or a function before, I will interview them first

Only after I feel like I won’t walk into a session and ask questions like “what’s a variance swap?” when the entire project is to fix the variance swap valuation process, is when I do the initial interview with the SME. If I need to do more than three sessions with an SME, something is broken, because my model is:

  1. Research the business need and broaden my understanding
  2. Produce the document and capture the “big ah-hahs”
  3. Refine the document and capture the “meaningful nuances”

Is this perhaps a shade too much of hubris and self-reliance? I would not call it a completely unfair charge to lay at my feet (and at the feet of a number of my older colleagues who originally approached requirements/design in this fashion), but at least in my industry, it is a good way to

a) not get yelled at,
b) not get kicked out of an office,
c) earn the respect of the people you are trying to do something for, and
d) when you inevitably disappoint, screw-up, mess it all up, ensure that they still take your phone calls and give you a second chance

Some people would say that I am applying the idea of “they don’t really know what they want until you put it in front of them”, but…they don’t, not in the sense of lacking intelligence or ability, but in the sense of lacking time and space to focus on it! Remember what my friend said above? Someone who is always on the move, always with the feet to the fire, may have time to jot down some ideas, some guidelines and basic directions, but they are not going to have the time to draft a whole set of documents and thought papers and all the things we need to execute on the change. It is ridiculous to ask them to do so!

However, let’s talk real results. I want to share with you some of the feedback I have gotten and the meaningful conversations that have come out:

  1. “Are you insane?! That makes no sense!” [I personally love this one – it is incredibly valuable feedback because that question, full of disgust and disdain, is often followed by the why it’s so wrong; it’s most often the quietest person in the room who loses it and that quiet person has a wealth of knowledge that was incredibly hard to coax out]
  2. “Oh, I’ve never thought of that, that’s good, but could we make this one tweak?” [It is never “just” a tweak but it almost always captures a nuance that you, as a change person who has not done this job day-in/day-out for 10 years, could ever possibly have figured out]
  3. “Why are we doing this? Wouldn’t it be better if…” [Projects get dreamt up sometimes in the sky, but when you get to the ground someone is now able to articulate why that dream should have been left up there; killing a project is often times hard, but it helps if you have valid reasons to stop it or to adjust what’s being done]
  4. “This is great, but can we slim it down so that…” [Great way to a stop an over-bloated, million dollar solution to a hundred dollar problem]

I could give you many more examples but while over the years I have had a hiccup or two, it’s never missed the mark completely. As a change person, you are supposed to be helping your organization, you are supposed to be adding value and you can start that from Day 1.

Lastly, can we talk about documentation? There are more sides to this argument than I care to explore, but I will say this: write documentation that speaks to the right audience, and please, make it a limited audience. Many projects do require handshakes between business folks and technical folks, or business folks who speak Blah and marketing folks who speak Boo and process folks who speak Alien.

You can’t serve them all in one document and the expectation that you should is unreasonable and results in more goobleydook and mess than it does in successful projects; that’s the camp I’m in, document to a specific audience. By all means, collaborate across those walls throughout, but please, please, can we document in a directed fashion and translate thereafter? Everybody wins in this, and here’s why:

Despite the potential “upfront costs” you have from what are considered ‘extraneous’ or ‘duplicative’ documents, and the time to draft/approve them with limited, appropriate audiences – and the reliance on ‘translators’ in the middle – you save later on in the project. You can get clear transparency from scope to delivery, from proposed benefits to realized ones, visibility into defects versus changes and the ability to make valid choices around those, and you control late-stage cost spinouts and create trust by being able to enforce accountability.

So, all in all, that’s why I ask for forgiveness and not permission. I get in front of things, I do my own research, I document what I think it should be, and toss it in front of the audience and stand back for feedback. If I get it wrong, then someone is able to tell me why, and I have done my job. And if I get it right the first time around, then I have still done my job. I only see upsides here – what about you?

In the next post, I am going to talk about why I believe that where and when possible, it’s best to work back-to-front in a project. It sounds perverse, but I have some solid reasons behind it. Stay tuned!

Please share this to a friend or colleague who would benefit from it by using the buttons below.

You may also follow me on this blog and follow me on LinkedIn where I post other items similar to this. Or catch up with me on Twitter @cabigail2.

If you prefer a one-to-one conversation, you can always e-mail me at


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s