Delegation is common across all types of organizations. You naturally end up with some experts in designing process and other experts at delivery within process. When trying to improve a process, it is not uncommon to bring in the first group of experts to develop something better to be handed off.
However, there is a serious risk in this type of delegation. It is not uncommon for a delivery team to feel a process that is forced on them which they didn’t have a role in developing. A process is only worthwhile if it is being used. Alienating the delivery team can quickly lead to a process not actually being adopted.
When a process is dictated to a team, there is a chance they ignore it and simply keep doing what they are doing. The common complaint is that the new process does not take into account all of the variables that need to be accounted for. This is actually fairly common as any process that exists for a period of time develops exceptions, reroutes and quality assurance steps that may not exist on paper.
Delegation is good but it cannot be at the cost of separating process design from delivery. The team that delivers on a process has the ultimate responsibility for its effectiveness and must, therefore, be a key stakeholder in its development. A process design team with no responsibility for long-term delivery is incentivized to develop a process they can sell and easily hand-off – they may not be as concerned with the exceptions and risks of their new design.
Process changes can come two primary ways: top-down direction on how things need to be done going forward or people on the ground deciding to do things better.
In the top-down bucket, changes may be driven by new technology, new reporting requirements or just a new way of thinking about things. Usually, these are accompanied by some level of controls to ensure the changes stick and are followed. The control may be as simple as a standing meeting with a standing agenda item. It may come in more strict forms of reviewing log-ins and update timestamps. Top-down ensures the new rules are followed (regardless of whether they are better or worse).
Guerrilla improvements usually are driven by need or laziness (not always a bad quality in employees). These changes happen because someone sees or experiences something that could be fixed. Maybe the solution lasts only as long as that person remains in the role, maybe it dies after a week because there is no support for it, maybe it becomes a core part of the business. The difference in lasting comes in part from an organization’s culture and desire to promote the new.
Both types can lead to real improvement or new-found inefficiency. Both could impact just a single individual or spread company-wide. Toyota decided long ago with their Toyota Production System that improvement could come from anywhere and was worth pushing both bottom-up and top-down as it is found.
There are still many cultures and managers out there scared of the new and willing to put down bottom-up change suggestions. The best managers will still be those that promote good ideas regardless of where they come from and work to improve poor ideas.
It’s fascinating to watch people try to create a calm spot in the middle of an ocean during a hurricane. They are standing there with their hat flying away, hair blowing around, wind drowning out their voice, boat tossing around – while trying to direct people that the solution to fixing the situation is to always step with your left foot first. You stand there trying to understand why they care about which foot you step off first with because the entire boat could go down any second.
Processes require other processes in order to work. Just because another well run company does something one way doesn’t mean that you can do the same. Your core processes and controls impact your ability to implement and control more detailed processes across the business. You can’t put a process in place to measure group profitability if you don’t have strong business financial controls. You can’t measure employee performance if you can’t measure project performance. You can’t hope to get firm approvals at the start of a project if you allow exceptions 6 months later regardless of what’s on paper.
It should go without saying that you can’t ask your people to fix problems that you yourself create and have no desire to change your own behavior. Sadly I come across scenarios way too often where bosses expect their employees to solve problems without actually allowing them to influence behavior up the ladder. You can’t solve a problem if the troublemakers aren’t going to be controlled – it should be common sense.
I haven’t done a list in awhile so let’s try one today to summarize down some topics I’ve been writing about recently. If you want to make your CRE processes work better keep these things in mind:
- Figure out what you are trying to solve for. A process that simplifies Lease Administration abstractions is not simply a lease admin process. It solves for data quality, resource availability, system capability trade-offs, time to data availability, etc. There are lots of ways to look at it. Know what you are trying to fix or improve before you start. Process for process’ sake is ineffective.
- Get the right people involved. Some people know and understand the problem more deeply than others. Often times those people that understand the problem aren’t even involved in the thing that is causing the issues. Do you really want to try and solve the problem without including the people impacted and just hope that you get it right without them? Similarly, don’t choose the same people over and over. You need to make sure you share accountability and responsibility across the team to give everyone a chance to grow.
- Implement but then iterate. It is unlikely that you will land on the perfect solution with your first attempt. Put something in place with the idea of adapting and changing as you go. Building in no room for flexibility is a recipe for creating even worse issues.
- Be open and transparent about what you are doing. There are few things worse for employees than changing a process and disrupting their workflows for what seems like no reason. If there are problems then the entire team should understand what is happening. Hiding issues from the ones causing them (even if they are not doing it on purpose) does not help anyone – it just delays the knowledge coming out once the problem gets even worse.
- DO NOT ASSUME TECHNOLOGY IS THE ANSWER. Finally, never assume that technology can magically solve your process problems. Technology is often a mask for issues or an easy scapegoat for what is really going wrong. If I had a dollar for every time someone blamed technology for their lack of performance I’d be quite a few dollars richer. Technology may or may not be part of an answer but don’t assume that it will be. Sometimes it does nothing but make things worse because it doesn’t address the root causes (i.e. PEOPLE).
If you deal with customers then you are involved in a User Experience. If your customers do anything more than just call or email you directly then you are involved in User Interface. UX and UI concepts are often thought of as software activities but they apply to any situation that involves customers.
I was in a meeting recently where the problem was presented that tenants in a building didn’t have a single way to communicate the problems they had onsite. They would email or call various people or hope to find someone involved in facilities while wandering around. This then led another group (IT) to say they had the same problem. Then another team popped in to say they had the same issue. Suddenly this wasn’t a limited client experience situation, it was the same clients having the same issues all over the place. And we only discovered it by talking openly about problems.
The teams were trying to put a solution in place and immediately jumped to thinking through software that could solve the problem. They had their first task to interview companies that provided systems sort of like this but they still hadn’t clearly defined the problem. I asked them to look at it from the customer perspective: what was the real problem? As they stepped back they realized the real issue was one of confusion. People didn’t know where to go for help.
In terms of UX they could now better start to approach the problem. If the problem is confusion and unclear information, the first step in a solution is communication and clarity. No software required. All they needed to do was figure out who should receive requests internally and then post/publish that to clear things up. After that they could begin to work through how to improve the process or track communications through different programs.
This also addresses the UI problem. The biggest issue in UI is confusion. If the UI is phone or email then there is no confusion because every customer of the process is familiar with these. Instead of jumping to something new at the beginning of the solution we can introduce change slowly and prevent confusion from creeping back in. UI can be a component to each part of the solution as we move forward.
UX and UI are really good ways of thinking through the problems we encounter. Everyone we deal with is a user/customer of our services whether they are internal or external. Thinking through their experience in dealing with us helps us to improve the process. Just as this can apply to just about anything else we do as well.
I sit in on a lot of calls where technology is a key focus. I’m always surprised at the number of people who believe that the word “technology” is magic. Just by saying “technology” it is as if they expect some wizard to walk in with a tool that does everything for them automatically and without input or effort on their part.
Technology solves nothing. Think of every piece of technology like a car – it doesn’t really do anything without you as the driver. But without that car you’d be lost without the ability to go far distances or short distances quickly. That car enables you to do many, many things but it does not do them for you. Talk is typically about “People, Process and Technology” but for some reason People and Process are treated differently.
My guess is that most people who didn’t grow up with computers in school never developed a comfort level with technology is a central part of their lives. Systems and applications need participation and discomfort with the very idea of them is self-defeating.
Part of this problem can be solved by UI/UX. Making the interactions with systems more natural and intuitive will increase adoption and better treat a system as part of a process as opposed to a standalone solution. Education is also a big part – educating people that technology is not a magic bullet and that without people using it right nothing will happen. I will continue to believe that Excel is a better solution than a million dollar ERP system if the people using it are just putting in whatever they want with no controls.
HBR has a post up all about a process for eliminating the scourge of email. Every year several publications dream longingly for a world where email doesn’t exist. Personally I receive about 75 emails on a slow day and my peak last year was about 275 in a single day. I’ve seen where others are above 1,000 emails a day and there is literally no way to keep up.
Different people use email differently. This brings us to the point that everyone now absorbs and communicate information differently. Information methods range from fixed on a PC, mobile on smart devices, analog with phone calls and a variety of other macro methods. Within each of these devices there are an exponentially increasing methods of actually keeping up with the deluge of tasks and data. Some use productivity tools such as Evernote or Wunderlist, others use Email to track what they are supposed to be doing, others use a paper day planner that they fill in each morning, others may go a bit rogue and just try to get done what is directly in front of them.
Some people like constant streams of information, others prefer fixed periods of intrusion into their work mode. Part of it comes down to how good some are at multi-tasking. Sometimes it is simply a method of communication their schedules and roles force on them. I know sales people on the road every day that cannot predict when their periods of availability will be and they simply brute force everything they need during short windows and nights. If you don’t catch them then you may not. Sometimes you are simply the victim of others’ communication patterns.
Trying to develop new mass methods of group communication is difficult. People now communicate through a variety of media based on the needs of a particular message.