Take Every Opportunity to Document

by | February 26, 2013

I am always surprised (and I really shouldn’t be) that we do a great job of responding to critical incidents but almost always fail to document what we did so it can be referenced in the future.

As IT leaders we need to proactively document the impacts of planned and unplanned changes.  Whethere it is a planned power outage or an unplanned one, wouldn’t it be great if you knew (from some documentation) all the service impacts to your customers?  This is one of the roles I wrote about that an Enterprise Architect needs to carry out in a post I wrote in July 2007 – Enterprise Architecture Roles or “What do You do?” 

Instead of trying to define what “Enterprise Architect” meant, I found it much easier to explain the roles I play and the responsibilities I have. First I tested it on my wife, who has the best common sense of anyone I know. She got it! Next, I tried it with my colleagues and again it registered. These three roles are by no means the only things I do as an Enterprise Architect. Constantly reading, model creation, leadership, presenting (internally and externally) all are important too.

I was in a meeting recently where we knew of a planned annual power shutdown for parts of our AUS campus.   As this was an annual event,  I asked where  last year’s plan was.  All I got was blank looks and uncomfortable laughs.

What a huge risk to the organization and to our credibility with our customers!

As we implement a Service Management culture with our team, we will be taking every opportunity to document the interconnectivity of the technical platforms we use to deliver services.  Ideally, we will have a way to determine what the impact to our customers will be when we have planned and unplanned service interruptions.

One approach to consider is Design Structure Matrix approach.  My BCIT colleague Hoby Chou introduced me to this technique to analyze and manage complex systems.  The approach uses a square matrix to capture the relationship between components of  a system.  I will be investigating this approach as a possible technique for us to help us with Change Management.

Are there other techniques you use that you can share with me?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.