Another Dan’s New Leaf Post

I want to write an article about Simplicity; but where do you start with such a complicated subject? 

—–

Maybe the reason I’m writing this article is because one way to learn about something is to write about it.  And we all need to learn about Simplicity.  Nothing has made that more clear to me than the new policy set we’re developing based on our work with one-person Insurance Trusts.  Meanwhile, we’re knee-deep in learning TRAC, and comparing their risk analysis approach to the “old spreadsheet method” has me thinking a lot about Simplicity and what makes things simple.

—–

So I decided to start my article by trying to define:  “What do we even mean by ‘simple?’”

And what the heck, let’s use a dictionary for this.  As many of you may already know, the dictionary I use is dictionary.com, so here’s another plug for them.  I wish I’d remember to buy some of their stock the next time I talk to my broker.

So here we see there are five definitions, all of which seem to be very good quality control considerations for anything, but especially for documentation of policies, procedures, standards, guidelines, and instructions.

——

You could say I’m highly motivated to make our next release,
the Social Media Guidance Response Kit, an example of Simplicity.
Maybe that’s why I’m writing this article . . .

——

I laugh at the first definition, (easy to understand), because to me Simplicity is one of the hardest things for an auditor to understand and therefore achieve.  We see things in terms of what we can check for . . . . lists . . . and lists simply do not lend themselves to simplicity.

 Unless they are very short!

—–

(But do short lists make for thorough audits?)

——

The subject of Simplicity has no beginning, because it also has no end.  Just like many other qualities of an excellent IT Governance Program, we’ll never finish simplifying it, and like Security we should always keep Simplicity in mind.  First iterations will start out too complex and become more simplified as we learn, and thus the iterative process of development leads to excellence.  We will go through the Capability Maturity Model levels zero through four, from initial iteration straight through to optimized iteration.

And those who know me understand that Simplicity is one of my own greatest struggles, that I’m probably in iteration 5 billion by now and still not optimized, because I apparently have a hard time not presenting everything.  So, of course, my program for simplifying things is simply to decide what to eliminate from the equation. 

But that can’t be the only approach.

 And since our customers want our deliverables . . . . not only our boilerplates but also our audit reports and our managed services reporting . . . . to be as simple as they can get, the question of how do we approach Simplicity is an important one for us!

Can we audit for Simplicity?

My initial thoughts are that maybe we can make a matrix out of the definitions of “simple.”

1) Easy to understand, deal with, use, etc.: a simple matter; simple tools.

2) Not elaborate or artificial; plain: a simple style.

3) Not ornate or luxurious; unadorned: a simple gown.

4) Unaffected; unassuming; modest: a simple manner.

5) Not complicated: a simple design.

So, now I have my list of five things we can check everything against to determine if it’s simple.

Let’s apply this to my article so far:

1)      Is it easy to understand?  Probably not, and my initial reaction is:  but wait, it’s supposed to inspire thought!  But I do hope our blog site is easy to read.  (If not, let us know!)

2)      Is it “not elaborate or artificial; plain?”   Hmmm.  I’ll have to leave that to you.  I guess as a writer I might adorn articles with humor.  But I try hard to be genuine.  And the nature of Dan’s New Leaf . . . . ah heck, I’m just making up excuses, aren’t I?

3)      Is it “not ornate or luxurious, unadorned?”   Well hey, isn’t this the same as #2?  I guess something can be adorned with genuine luxury.  So maybe adorning my articles with humor is okay on question #2, but is a deficiency for question #3?

4)      Is it “unaffected; unassuming; modest?”   Well now I’m starting to regret writing it!!

5)      Is it “not complicated?”  Gee, it was until I put this min-audit in here.

Okay, I either just flunked that audit, or I agree that using Dictionary.com as an audit framework does not work very well. 

Here’s my answer: 

Thank goodness for the FFIEC!

 ——

Hey wait, the Social Media Guidance Response Kit, geez . . . that’s
a long title for something we’re going to try to sell. 

Could we just call it the Social Media Guidance Kit?

——

Could it just be that some things are simply not simple? 

As an industry, we have tried to address the number one complaint with IT risk assessing since we first started hearing it, back in about 1999.

• “The process is too complicated.”
• “The documentation is too detailed.”
• “The complexity is too complex.”

And we ARE getting better.  We’ve really taken a leap in the right direction by replacing spreadsheets and databases with applications, and the benchmarking capabilities alone will improve the value in the deliverables.

But let’s face it, the reason there’s risk in information technology is indeed because of Complexity.  The many moving parts are why patch management procedures must be developed.  The permeation of technology in everything we do is the reason risk assessments must be continually conducted with multidisciplinary teams that think this is all way too complicated.  The constantly changing nature of technology gives birth to change management.  If you need a program for the management of change, it can’t be very simple. 

IT Governance is a response to this complexity, not a cause.  And though we must try to simplify, as much as possible, the way we control risk, we will never control the existence of risk.

For without risk, aren’t you dead?

Original article by Dan Hadaway CRISC CISA CISM.
Founder and Managing Partner, infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”