Have you ever considered why a lot of stuff just doesn’t get done on time in your business?
Many and varied reasons get cited for this:
A few of these reasons are unavoidable (such as illnesses, peaky workloads, etc.) particularly in small businesses where little resource redundancy exists, but many are completely avoidable if you consistently apply some simple management practices.
The first practice is to ensure a full understanding of the problem, i.e. the ‘What’. I’m sure many of you have witnessed the “macho manager” approach to fixing things: trying to push through a myriad of problems during a short meeting with the result being that many important issues are given very little time or consideration before being assigned an owner and a fix-it time frame. The action is oft recorded in the meeting log as a one-liner with an owner (sometimes) and a due date (less frequently).
Actions with this data missing tend to be those that return to the management team time and time again, often months apart. The cause is that the assigned owner is given the issue, but applies his/her own interpretation as to what the problem is and what needs to be done to fix it. The owner may find the easiest/shortest route to fix something which may be quite different to what was intended.The result could be a partial or temporary fix, or just plain wrong.
How often have you heard the retort “but wasn’t that supposed to have been fixed by so-and-so a couple of months ago?” Then, when you check the notes of the meeting you find that the action wasn’t written in a way that you could be sure what it was about.
As any Six Sigma black-belt will tell you, this is a cause of re-work and is one of the most expensive activities for an organisation to undertake.
So how much detail needs to be included to ensure a problem statement or action is well defined? Saying that it depends on what the action is, is true, but not so helpful. Typically a well defined action would have the one-liner as its title but would also have a paragraph or two on what the issue is and importantly, some context. That context will allow you to refer back to the action in the future, perhaps even years later, and give you detail on what the problem was.
The second practice is around ‘Who’, i.e. Ownership. This doesn’t mean that an owner is not defined (more often than not an action list will be quite clear who this is), but it is the concept of “ownership” that can be poorly understood. Understanding the difference between having “Responsibility” for an action vs. having “Accountability” is rarely well-practiced. Actions often get “delegated” or “handed over” to someone else but lose the linkages to the original owner.
Have you ever heard “Oh, that action wasn’t in my department so I handed it over to the John’s team in Jacky’s dept”. Of course, Jacky is completely unaware that this has happened and the action slowly gets lost deep in the organisation.
The fundamental difference between Accountability and Responsibility is that the latter can be delegated but Accountability remains with the person who first accepted the problem. The only way to change accountability is with formal agreement of the person that gave you the problem in the first place. Tools like the ‘RACI’ model are excellent at helping to define Ownership.
Poor accountability in the team is one of the primary causes of lost actions in organisations.
Very often these first two items - the ‘What’ and the ‘Who’ - are the only records made of an action.Yes, they are better than nothing, but they completely miss out the next three critical practices: How the action is to be dealt with, by When should it (or an interim step) be completed and most importantly Why this action needs to be handled.
If the action doesn’t address 'How', then it is not addressing the resources, tools, approvals, costs, etc., needed to complete the task. It depends on the action ofcourse, and often such detail will not be known at inception or may not be required if it is just a simple to-do. But if it is a larger issue, that involves some complexity, it is important that proper consideration of options and methods are given. This may be reported back as an interim step and will help to clarify ownership, resources, budget and timeframe for the action’s completion.
Specifying 'When' is often done with little consideration of what is needed to complete the task. This doesn’t cause non-delivery per-se, but can cause a continued perception of late delivery. Sometimes the setting of a big audacious goal really works well - like President John F. Kennedy sending men to the moon - but it comes with an assumption about the unconstrained availability of resources (NASA’s budget increased 4 fold in the following years). You can demand the formation of special work-groups to resolve issues more quickly, but don’t forget the impact that this will have on the other work those people might now have to delay as a result.
So yes, the setting of an aggressive date can help teams get some things done, but can also set them up for failure if the details of what needs to be done are not well understood. Kennedy already knew that sending men to the moon was quite attainable, before he made the announcement.
The fifth practice, rarely included in any action definition, is understanding Why? It may sound strange, but not answering this question can be one of the biggest causes of action overload and back-log in organisations. If action items and priorities are not in synchronisation across the team then, in Lean/Six Sigma terms, there is variability, which is another of the major causes of poor performance.
The answer to 'Why' is important because it helps you to determine the priority this action has over the myriad of other actions in your organisation. That helps your organisation get the focus it needs to ensure that actions are delivered in a timely fashion. Prioritisation and focus is critical for an action oriented culture and will be addressed another time.
In my next entry, I will take a look at the “Action Manager’s High Five”© - a simple mnemonic to help better definition of actions.
“Actio” and the Actio logo are registered trademarks of iThought LLC.
"PhotoFiler" and the PhotoFiler logo are trademarks of iThought LLC.
This website and its contents are copyright of iThought LLC, 2021.