Single Point of Failure

I keep revisiting old articles, not necessarily because I've run out of things to say, but because I often feel I did not state my case well enough. This mainly happened because I did not have enough practical experience outside of consulting to be able to be relevant. Here's for a second go at my article on process redundancies and why they can make sense.

Defining a single point of failure

A single point of failure is a point in a system (such as a (manual) process) which, if it fails, will bring the whole system down. Not all redundancies were created because people felt they could afford to add an additional, non value added layer. Rather, redundancy in systems were created to avoid single point of failure.

Of course, during crisis times, process efficiency reviews such as Process Impact Analyses (PIA's) are likely to identify redundant activities. The subsequent reengineering will lead to significant optimizations in process efficiency. However, while aiming to reduce the unnecessary redudancy in systems there are a lot of reengineering projects which overshoot.

The butcher's apprentice

Large scale reengineering projects sometimes cut indiscriminately through processes and systems. In my experience, especially projects which originate out of a dire need to reduce expenditure will have overall expenditure reduction targets that are most easily applied across the board. That this approach often makes no sense at all is never considered. These projects result in the creation of single points of failure in processes where prior to the reengineering effort a necessary redundancy existed. Indiscriminate cutting into a process is a bit like being a butcher's apprentice ... mistakes by cutting the wrong piece of the meat can be quite costly.

And let's face the hard truth we failed to face so often in the past: our people (who are responsible for doing the process work) are expensive to make mistakes with. Especially, but not only if these people are good in what they do.

It gets worse. Given these reengineering exercises are most often executed by external parties, those mistakes are mostly made by young, ambitious but necessarily inexperienced consultants with little to no real life process background.

Is there a way to avoid this? Can you detect and fix a single point of failure?

Detecting single points of failure

To detect a single point of failure, it's important to take the time and talk to the people that execute the process every single day. They're pretty much the only ones that are aware how the process actually functions. And talking, preceeded by gaining the trust of those people and earning that trust is essential. Not only because you may be surprised about the amount of process knowledge that was not captured in the process documentation. No, quite often these people are the only ones that are aware of the existence of the single point of failure and all possible implications that brings with it. Even better, they can quite likely help you avoid it. There are other ways, which I list below, but none as powerful as talking to people.

Alternative or additional actions

The following alternative but most often additional actions can help you in your search for single points of failure. Note that these require a significant investment in time and means to properly execute. In my opinion, only coupled with in depth discussion with process owners and operators will they yield the most relevant results. You can:

1. Map the process: understanding the process and the interactions in the process is a powerful way to understand what is actually going on. Again, do not base yourself on procedural descriptions. Rather, interview people, monitor process execution and look at what's really there. You may be able to identify your single points of failure in the process itself;
2. Identify choke points during a walk-through or based on process indicators: quite often, a choke point where backlog piles up is a good indicator of a single point of failure. Process indicators which are often indicative of a problem in a process will be a relevant factor as well.

After identification, you need to solve the issue

As I stated above, a significant number of reengineering projects stripped operations to the bare bones, only to find out that because of the existence of single points of failure the process completeness, timeliness and accuracy were largely jeopardized.

That's why I dare you to create or maintain the necessary redundancy in the process. This is often a cost benefit decision. In case the single point of failure risks risks collapsing or significantly disturbing the process, creating a redundancy in your process is not overspending. Rather, it makes good business sense if the cost of failure is significantly higher than the cost of the redundancy, over time.

How to make your tools work for you

It's you and your workflow, not the tool

Let's be clear. There are a lot of really cool tools out there. Both in the Mac App Store and outside of it, there are plenty of interesting tools that may add quite a punch to your workflow. If you get to know them. Intimately. And if you can integrate them in your workflow. Efficiently. So the challenge really isn't finding that one brand new tool that will make all the difference ... it's integrating that one tool with your current workflow and optimize that flow.

Getting it backwards

Most people get this backwards. I've been there, you've been there. We get so enthused by this new tool (let's call it toy, really) that we will find reasons to use it in our flow. This leads to situations where people have 5 or 10 different text editing tools on their laptops. And probably why toolboxes are oh so popular. Look at all the great tools you get for one low price. While really all you need is one hammer. The question is, will you fall for the flavor du jour, or will you act more reasonably and rationally?

Impulse buying

So how do you deal with that call of the tool? How do you avoid spending your money on items which capacity may exceed your needs by 99%? For me there are a couple of steps to go through to avoid those impulse decisions. Because today you may be spending 99 cents in the App Store, tomorrow you may be spending a couple of million USD or EUR of unwarranted expenses on a new IT system. And if you believe there is a significant difference in that spending decision, let me assure you that as a consultant I've seen more impulse buying decisions than I ever thought possible ... some of those decisions cost quite a lot of money and never even got plugged in.

Steps to consider

Let me take you through a couple of steps which may not be complete, but at least will take you through a process that requires you to do some thinking before buying. This is not the traditional "Wait 30 days before spending an amount" because at the end of the day, if you are really adamant about buying something without a considered decision, you will have a difficult 30 days and then still buy it. At that moment, you've not only spent money on something you don't need, but you've given yourself an additional frustrated 30 days as well. Here's what I think is a considered approach:

1. First, be very careful in the assessment of the specific need you want to acquire the tool for. Is there a need? What is that need, and is this a real need we have or just an argument we're using to acquire the tool? It is essential you clearly understand what you want to do with the tool. You need to identify all you want to do, and also what you don't want the tool to do for you. Then you need to clearly define how the tool will affect your workflow.
2. Second, you need to identify multiple objective sources of information on the tool. Stay away from commercial presentations, they are likely to try to convince you of the added value of the tool. You will only find confirmation of what you want to believe, i.e. that you need that tool. Check the competition. What do they offer? Interesting to consider for example is that public services are required to have multiple suppliers bid on most contracts they put out in the market. If you assess, assess using multiple sources of non-commercial information. Do call reference users if the supplier provided you with that information, but consider they will likely not provide you with the coordinates of their worst clients ...
3. Once you are clear and the total picture makes sense, also from a cost perspective, make the purchase. This really is about committing to your choice if it has been well considered.
4. Once you have made the acquisition of the tool, invest time in getting to know the tool. Get to know the tool. No, really, get to know it inside out. Make this an acquisition which will be worth its money. If it's a large acquisition, make sure your users get the most training possible. Make sure the supplier stays responsible for the training and make training acceptance count. If it is a small tool, train yourself. Get to know all of the functionality of the tools. Use them. Learn all the shortcuts that exist. When you learn those shortcuts and those special ways of getting more out of your tool, be it a hammer or an ERP system, learn them as if you were to have to teach them. It provides you with a whole new perspective on skills or knowledge acquisition. It helps you focus and slow down, which enhances your learning. Once you are clear on your usage and you master the tool, you need to start optimizing full integration into your workflows.
5. Once you know the tool and its use, start optimizing your workflows. The learning period for a tool should be long enough to achieve good knowledge of its use, not necessarily mastery. This will come with the integration in your workflows. Again, there is a process here. First, you will need to develop a workflow for the most optimal use of the tool in your process. The process really is key here. The process determines both the tool and the way the workflow is structured, not the other way around. Once you've done that, you need to work on integrating that workflow into the broader workflow of all of your tools. Again, your process and the desired end result should be the key factor here, not the tools or the workflows. Finally, if you get that right and you feel comfortable with it, you can look at possibilities of integrating the whole in an automation, where relevant and possible.

In conclusion

Tools are tools, but they also put bread on the plates for someone. Those developers will do their best to promote their tools, and so they should. However, you have a mission as well, which is usually not tool testing. Your mission is getting your work done. The best possible way to get your work done is very effectively and efficiently. Not just to do some more work, but also to find time to be able to focus on the essentials of life, such as spending time with loved ones. So don't go out and buy the next best thing. That's all the difference between right now and right, period.

Risk analysis in long term audit planning and audit preparation - part II

You can find part I of this article here.

Phase 2 - Analysis at the level of the area of responsibility (auditable area)

Internal audit’s responsibility for the proper application of risk based analysis in the preparation of its audit activities does not end with the multi-year audit planning or its actualisation. Each area of responsibility which has been selected for audit needs to go through a risk based analysis at the operational level as part of the specific audit planning phase.
This second phase assumes there is no structural risk management application present which outputs could be used as input for audit preparation purposes.

Executing the operational risk analysis

We survey all collaborators (“responsibles, accountable and consulted” in the context of the RACI matrix) within the selected auditable area. We use the 80 statements developed in the Risk Identification Model. Note this is not simply executing the initial entity wide risk analysis again. The scope of the assessment is both more narrow and deeper, as it only covers the auditable area but covers it in-depth. In addition, not all collaborators were (necessarily) involved in the execution of the entity wide risk analysis which was used for purposes of multi-year internal audit planning. Remember, the decision to involve them was at the discretion of the person accountable for the auditable area.

These collaborators are asked to judge each of the statements as to relevance and current risk exposure. Remember that risk exposure is a function of their assessment of impact, likelihood of occurrence and current level of risk management and leads to the development of a risk control matrix.

Risk analysis results

The risk analysis results, correctly represented in a risk control matrix, are but one input in the preparation of the audit approach. Of course internal audit remains independent in its assessment and can call on other information to complement the risk analysis. However, note that this, both from the point of view of the IIA’s standards and the effort of the organisation should be considered as a major specific audit planning input. What’s also interesting is that these results allow internal audit to make a comparison with the initial assessment of middle management.

The results also provide us with more information as to which aspects of the auditable area are considered to be important by the collaborators intimately involved with the process. In essence, it’s an appreciation of sorts of their understanding and knowledge of the problems they can be confronted with.

Perhaps counterintuitively, our priority audit areas are not those areas of high risk and low control. We want to ensure that these are subject to a risk mitigation or monitoring plan which is in the process of being implemented. These risks are actually the responsibility of the risk management function, if it exists. When auditee and auditor agree on the existence of a problem and the auditor has gathered enough audit evidence to confirm the existence and the scope of the problem, his audit activities need to end. He can then write this up in his audit report.

Internal audit’s responsibility is to provide assurance. Hence, we look at those areas which are considered to be high risk but under control. We assure the board, the audit committee and management that, based on our assessment, these risks are in effect under control.

Building the audit workprogram

Those areas which are considered to be those high risk high control areas constitute, together with the appreciation of the auditor based on prior experience, the basis for the development of the core of the audit workprogram. Note that the build of the audit workprogram consists of a significant change in the approach from risk to process.

During the risk analysis the auditor focuses on risks. Risks and their appreciation by collaborators in the process are central to the approach. However, once the auditor starts the development of the audit workprogram, all risks with an influence in an auditable area are gathered and covered in the audit workprogram. The process becomes the central aspect and the entire audit workprogram is structured according to the processes covered in the auditable area.

This has a very logical but sometimes difficult to accept consequence for auditors. If a certain process within an auditable area is not linked to one or more risks, if no indication other than the analysis exists that there are risks related to that process, it should no longer necessarily be covered by an audit activity.

Executing the audit

After the audit workprogram has been developed and validated by the CAE, the actual audit can start. The auditors execute all activities planned and described in the audit workprogram. Note that multiple risks can be evaluated at the same time, depending on the results from the audit activities which are executed. In case for example accuracy and completeness of a transaction are to be evaluated, running a test-batch of information through the process can be a test functional for both objectives.

Results

In addition to the standard audit dispositions which need to be reached at the end of an audit activity in the audit workprogram this approach allows us to assess the understanding of risks and relevance of the current risk management measures. Especially those situations where there is a significant discrepancy between the assessment of the accountable people and the assessment of the responsible people. This may be an indication of deeper underlying issues.

iOS & Mac - frictionless workflow with ubiquitous tools

I used to own an Android

Actually, I owned two. My first one was a HTC Magic, which I rooted after a week to see what I could do with it. These were the times of unlocked and unencrypted boot loaders, with Android operating systems being improved in the wild. I really enjoyed tinkering with it. My second Android was a HTC Desire. It looked great, and it was performance wise quite an improvement over the Magic. I never rooted it. I don’t know why, but the effort of rooting and maintaining my phone was prohibitive when compared to the value I derived from it. I loved to tinker, but my tinkering did not really bring me closer to real workflow improvements.

Remigrating to a Mac

And then I migrated back to a Mac, an 2010 iMac. I had worked on Macs before, all through my student days, in the early 1990’s. However, once entering the workforce I had to move to Windows. And while I held on for a little while, I even had a 1996 Powerbook, I soon migrated to Windows for home use as well. It was just easier that way. As an auditor, most of my work was done in Word and Excel anyway, and they were just easier to use on a Windows machine.

But returning to that Mac after more than 10 years really was like coming home to an old friend. The interface, while it had of course changed quite dramatically, was still very familiar. After an initial couple of days of hesitation, I quickly adapted to that very user centric and even user aware interface and felt more and more frustrated with my Windows machine.

Acquiring iOS devices and apps

I acquired my first iOS device with my original iPad on day one of the Belgian launch. And I started acquiring apps. For testing purposes, but at a relatively low per application price I soon built quite a library. Some of my most prized possessions in my app library were and still are the Omni Group set of applications for iOS. I soon acquired an iPhone 4 and a couple of months later my employer provided us with iPad 2’s. And my apps, most of which were both iPhone and iPad capable, just migrated with me.

The thing with the apps is that the best of them are just as customizable as required to optimize them for your own workflow, but not more. Not all choices are possible or even wanted. Quite a difference from Android. By limiting my app configuration choices but by making sure the apps all work according to the same usage principles, and leveraging first dropbox and now iCloud as a data exchange platform between devices and even apps, the apps and the device become ubiquitous. I no longer am aware of the tool I am using, because the tool is not the central point, my content is. And I can access and continue working on my content without breaking my stride. It just works.

The ubiquitous devices - iOS and Mac

This truly became apparent to me when I changed employers and had to give back my iPad 2. I had some fear that my workflow would be hampered on my original iPad. It wasn’t. Not at all. The couple of additional tenths of a second I need to wait longer for a webpage to render or for a process to finish is irrelevant to my workflow, and I honestly don’t even notice anymore.

Bizarre as it may seem, Apple succeeded in both binding me to their products and make me totally machine agnostic at the same time. I really don’t care what machine of mine I work on for most of my tasks, as long as it runs iOS or OSX, I’ll be fine. It may take a couple of minutes to restore my key software and apps from the app store, but I will have them available. My data is in the cloud, either on dropbox, iCloud or even some info on Google documents, but I can get that back.

The machine is no longer central to the equation. My content and my access to my content is. All the rest is really irrelevant. And that’s amazing, since the last truly ubiquitous tool for producing content was, in effect, pen and paper.

Developing SMARTER processes

Procedures are an integral part of business

The management of an organization depends for a significant part on established procedures which govern the way in which the organization confronts its challenges. Developing and writing procedures often comes as a afterthought, with either the quality department of a junior collaborator being charged with writing these procedures.

However, these procedures will govern how processes are executed in the organization for a long time to come, often long after the initial process designers have left. So it pays to make these procedures as SMART as possible. More SMART than SMART = SMARTER.

S stands for ‘Specific’

Duncan Haughey highlights that the established goals of a certain procedure need to be specific. They need to be well defined and clear to anyone that has a basic knowledge of the process which is being decribed. Hence, a procedure should not be considered SMARTER unless it is shown to have a clearly defined purpose which is understood by anyone implicated by that specific procedure.

Think about it. This makes sense. After all, if there is no purpose to the procedure, why are you executing it?

M stands for ‘Measurable’

A goal, a purpose needs to be measured, in order to assess where we are in the executing of our activities with respect to the specific goal set. We start from the premise that a procedure serves a specific purpose, as per our first point. However, how will we ever know whether or not the procedure achieves its intended target if there are no measurement elements provided? In order to be SMARTER, a procedure needs to contain adequate provisions for data collection which allows measurement of both its degree of implementation and its effect.

A stands for ‘Agreed upon’

Process goals are highly dependent on the buy-in which exists regarding the objective of the process. Introducing a process which is not at least discussed with those impacted by it and ideally agreed upon by them, will not easily be complied with. Compliance is a function of acceptance of the relevance of the process. A SMARTER process is a process which is carried by its constituency.

R stands for ‘Realistic’

If a process goal is unattainable, it is not realistic. I’ve encountered many processes or procedures which had been written in an ivory tower, not taking in account the situation on the ground. An attainable, achievable and adapted set of goals or purposes, taking in account the actual reality, is a cornerstone of SMARTER processes.

T stands for ‘Time Bound’

If a goal is specific, measurable, agreed upon and realistic, it can be time bound. A process can be bound in time. We tend to introduce processes without any restrictions on how long they will stay in force. A SMARTER process is a process which is bound in time, allowing for the achievement of its related objective after which it should extinguish.

This covers my interpretation of the SMART process. But wait, aren’t we talking about SMARTER processes? Indeed, some management literature introduces the SMARTER goals.

E stands for ‘Ethical’

Any process that is SMARTER needs to make sure that it in itself is ethical. This however is not enough. It also needs to ensure that it avoids inducing unethical behavior. This aligns with the “agreed upon” aim for SMARTER processes. The less collaborators are supporting a process, the more they will aim to avoid following it … which can lead to borderline ethical or even unethical behavior.

R stands for ‘Relevant’

Any author of a process needs to ask the question whether that specific process is the most relevant way of reaching the intended objective. If not, the process cannot be considered SMARTER.

I am convinced that the application of the SMARTER evaluation criterium on a process will result in processes more adapted to the reality of human beings.