Need to know what a team does? Build a conceptual model
The best place to start when defining the current state of an existing operation is to build out a conceptual model for the target department or organization. If the specific initiative that you are engaged in does not have an organizational development component, this can still be a useful exercise in that it can help you define requirements for stakeholder management and reduce risk for dependent processes that could be downstream from you.
A strong conceptual model, even if initially inaccurate, will be the mechanism that spawns conversations about a functional area. It will spur discussion. When defining the current state, it is important to understand human nature to a degree. Many staff members fear change. It will be unlikely that they will volunteer much information or that the information they do volunteer will be complete.
First and foremost a good operational manager is a good listener. But how does he or she extract information from existing staff to paint a complete picture of the current state of affairs? Especially if that staff is uncertain and awaiting the best way to react to a new management team, for example. Again, back to human nature. People are drawn to the negative. It is natural, instinctive even, for people to see things that do not look proper. People are afraid of dark places and voids of all sorts. This probably evolved from some long-ago time when people were not on the top of the food chain. When something did not look right, our ancestors ran the other way. If a cave seemed dark and scary, it was because in their experience dark and scary places were where things with sharp teeth and claws were more likely to pounce out and devour you. This is a learned behavior. Our ancestors feared dark places because they all knew someone who was eaten. Your colleagues fear giving up too much information because they have friends who have been made redundant. A good operational manager will use this human trait to his or her advantage by writing down, preferably including a diagram, their understanding of a current operation and then seeking commentary from others.
There is no better way to solicit information from others than to start by providing information first. If your understanding of the current state of affairs is inaccurate in any way, it is likely that your staff will be keen to point out the failures. In their mind, this allows them to demonstrate their own prowess and value. In addition to giving you some insight into their level of personal insecurity, this will serve to validate your assumptions and fill any gaps that were left out. In short, this will help you gain a proper understanding of the current operating environment and what is working and what is not working. So put your ego aside and allow your “wrongness” to guide your conversations with staff to the single truth of the matter.
Let’s look at a typical client services organization. There will be a front-line team that handles incoming calls. They are responsible for registering all client inquiries, responding to trouble tickets and escalating as required. Second level support staff members are specialists. They would be responsible for resolving the more difficult queries, working on client specific projects and similar activities. Third level support gets involved if there is an issue that cannot be resolved by the specialists. Depending on the industry, third level support could be program managers, network engineers, software developers, product managers or departmental managers or even more senior management.
The client services team might have ancillary or non-core functions that tend not to interact with the customers directly, but who play a pivotal role in the overall quality of service being provided. These people operate behind the scenes. This includes data analysts with responsibility for productivity tracking, “know your customer” specialists who focus on patterning customer behavior and providing intelligence that can be used either to supplement Sales or provide pro-active service levels, process analysts to ensure that the overarching workflow is tightly managed and controlled and relationship managers responsible for the overall client experience of major or key accounts.
All of these functional areas interact with each other in one capacity or another. All of this interconnectivity needs to be documented in a conceptual model. The conceptual model consists of three parts. First, there is a placeholder for each group in a department with some indication of how they relate to other internal departmental parties. Though there are untold methods and personalized style for doing this, the simple “box diagram” can be the most straightforward.
In this kind of model, one of the best ways to document the relationship between functional areas of a department is by thinking about the direction that information flows between teams. This lets you know who is core to the team operation and who plays a more specialist role. That can be reflected by drawing arrows that reflect the primary flow of information. The emphasis here is on the primary nature of the flow. For example, the primary flow of communications between front line client services and second level support is the escalation of an issue. That is not to say that second level people do not also initiate communication with the front line, it is just to say that the triggering interaction is from front line to secondary.
The second part of an operational conceptual model is a layer that reflects a high-level inventory of key work streams or categories of work that are performed by each group. These work streams represent an area of operation that is dependent on the successful maintenance of one or more processes. In that regard, this is a key step in the process. Each one of these work streams can take the form of text or as boxes inside the main boxes at the team level.
Lastly, the conceptual model should provide an indication of how the group relates to other internal and external stakeholders. This expanded model will help the operations manager begin to identify the various inputs into his or her world that his team is dependent on as well as the outputs that he or she is responsible for.
Understanding information flows in this manner is highly valuable. It also creates an opportunity to define those flows. For example, in the above model the operations manager learns that productivity reports are delivered to management. This is an opportunity to create an inventory of those reports and who is responsible. It allows the operations managers to understand what his or her stakeholders are interested in and by reviewing past reports the operations manager can gain insight into how their team and its output is perceived by others. Similarly, the operations managers can diagnose which issues are escalated and under what conditions. As the operations manager asks questions and builds a detailed inventory of inputs and outputs in this manner, they will gain a more complete understanding not just of the scale and scope of the operation they are managing but of the entire ecosystem in which they are operating.
This model can be used as a means to perform a high-level gap analysis as well. A gap in a conceptual model like this can help operational managers determine where to focus their energies as they work towards an improved operating environment.
Gap analysis is really the beginning of diagnosing problems within an operating environment. It begins typically by socializing the model to make sure that the team has the opportunity to provide commentary on anything that might be missing. For example, when describing the above model to the front-line support team they might respond by indicating that your model is incomplete because certain aspects of their job are not represented. These aspects of their job are probably also not documented. So, in this way that conversation has identified a gap to be explored. The team might also identify a problem with a process at this point by indicating that you have captured a category of work, but they might comment that the work would be more efficient if they had better tools, more staff, better training, etc.
In this way the gap analysis will produce two kinds of output: first, gaps in the process itself that are resulting in inefficiencies or additional risk; and second, specific hardships or challenges that if overcome would result in an improved overall process. In order to really understand the impact of these gaps, you need to explore the ecosystem in more detail. This includes trying to create a specific inventory of processes that exist, or that should exist, within the business operations. We can do that through the development of use cases.
For more information about this topic or to learn more about our services please contact us at info@coeurderoy.com.