“Technology” is not a valid substitution for “Process”

Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke

It can be very easy to think that a new technology is going to solve your process problems. This is a drastic mistake. Technology can do a lot of things, but it cannot remove the human element entirely from any problem it is being put toward.

Many systems have developed a reputation for solving process:

  • Slack solves the communication process.
  • Google solves the search process.
  • SAP solves the finance process (or just makes it worse?).
  • Oracle solves your database processes.

Slack can actually lead to new and more complex communications issues. Google still requires you to know what you are searching for and type in phrases that will give you the right results. Finance is not a process that can be solved by technology. And Lord knows, databases are not clean or easy.

Process involves everything before, during, and after the particular actions being performed by technology. Process includes the humans involved in clicking buttons, submitting data, or running reports. Process includes understanding the outputs and making sure things are happening as intended.

Technology can do a lot but it is always a mistake to believe that Technology is the same as process.

Advertisements

Oblivescence

Word of the day: Oblivescence.

Definition: The process of forgetting.

When I heard this word and read the definition, it sparked a highly visual response in my head. There is a process for forgetting and someone had coined a word for it. Brilliant!

“The system has detected no errors other than the type is was programmed to detect”

It is not uncommon for systems to return an “All Normal” status even while things are going down flames all around it. Just because a system reports 100% success for the things that it was taught to track doesn’t mean that the real success rate is anywhere near 100%.

This is because a system can only do what it was taught to do. If you build a system to count the number of lines of data submitted, it will count the number of lines of data that it receives. However, it cannot count the number of lines of data that it never receives. If the process fails due to an external cause, the system cannot report it. The system will believe that it has successfully processed all data but in reality, it has only processed the data which is actually received. Somewhere in a room far removed some poor user is screaming at their computer for not doing what it is supposed to do.

As a rule, I have limited trust for any automatically generated system reports. I’ve seen systems which don’t correctly log user log-ins because it had an incorrect handling of usernames. I’ve seen systems with audit reports that multi-counted everything because it tried to audit itself recursively. I’ve seen processes that were highly manual but the reporting only covered the system side of things.

(Most) Systems can only do what they are told to do. That doesn’t mean that we actually understand what the system is doing. Sometimes the code is incorrect. Sometimes the handling of a situation is executed differently than planned. Sometimes the process has evolved to no longer align with what the system was designed for.

Sometimes success is shining a light on what’s going on.

Last week I talked about sometimes success is not failing. Other times success is actively looking to break things – or at least shine a light into the dark places. Just because there isn’t noise today doesn’t mean that everything is working as it is supposed to.

Shining a light on what isn’t going right can feel wrong. You are essentially pointing out where things aren’t working as they are supposed to. The reality of it is that someone would catch on eventually in all likelihood. Usually, that happens when something really bad goes wrong.

Waiting for that really bad thing to happen is bad policy. The worst case scenario is invariably worse than uncovering and fixing the issues yourself. In the latter method, you control the noise and approach. You can control the message.

The secret behind 90 day transition windows

In many industries (definitely across CRE), you will find yourself needing to transition something. It may be an outsource provider, moving from one vendor to another, implementing a technology system or simply testing a new tool. If you are talking to a third party to assist you, you will likely come across the generic 90 day transition period.

It’s funny how often transitions of very different things always take exactly 90 days. It’s almost as if people got together to agree to 90 days as the perfect standard. In many ways, that is exactly what happened. (Not that people physically got together and defined this from the shadows, just that they came to the same conclusion through independent paths.)

90 days is the perfect amount of time to make it seem like real effort is being put in but it’s also quick enough to seem aggressive. If I were to say go today, 3 months to implement something feels like it could be realistic. Psychologically, a non-expert is unlikely to question this period of time. If you were to advertise 60 days people will immediately think of all the little things that can delay the solution by that long without batting an eye. If you say 120 days, it crosses that triple digit barrier and starts to look long.

The other variable in the equation is what “transition” really means. Many organizations take a very fuzzy definition of transition. Often it may be something along the lines of:

Transition: the sequence of activities that ends in 90 days that allows us to show how good we are at listing things on gantt charts.

That’s very tongue-in-cheek but not terribly far from the truth in many cases. The actual “transition” (defined as everything needed to actually reach a new Business-as-Usual state) is difficult, painful and can take a very long-term. Often you can’t even clearly define where the transition ends and BAU begins in larger projects.

The 90 day transition is just another marketing ploy but designed as an operational reality. Remember that marketing doesn’t stop just because the sales process has.

Don’t forget steps 1 through 3.

When working on something you feel comfortable with, it can be easy to look into the future at what you expect the final outcome to be. If you are simply trying to get through the process as quickly as possible it can be easy to just jump straight to what you think the final answer will be. There is danger here.

People are always a variable in a change process. People you aren’t familiar with will likely bring ideas with them you don’t have quick answers to. If you have a large team, you will have a large set of requirements and goals. If your team hasn’t worked together before, there will be a significant element around figuring out roles and responsibilities.

When projects go VERY wrong, it’s often because they forgot to do Steps 1 through 3 in the process plan.

  1. Figure out what you are really trying to achieve.
  2. Define the team, roles, and responsibilities for how you will get there and get buy-in from each.
  3. Define what success will look like at the end.

These may seem really basic (because they are) but the basics are what usually win the day. In sports, the players with the strongest fundamentals have the longest careers even if their upside isn’t the greatest. If you get the fundamentals right every time, your speed to a solution will go way up.

Note that this also applies even when working with teams you are familiar with on projects you’ve done a thousand times. People change and their goals change. At some point, people feel ready to take on more responsibility or have a life event which limits the time they can invest in this new one. Doing the blocking and tackling up front ensures you are focused on everyone you need to be.

Process drives Technology drives Controls drives Process

So much of the work that we all do is recursive. When you do Thing A, it causes you to do Action B. Action B dictates that you generate Report C which indicates that you need to do Thing A differently.

The trick to the entire process is to realize the truth in the above cycle. There is no process meant to remain the same forever. Processes are meant to change. Patterns in data start to shift. Growth curves eventually stop. Eventually, New York real estate will reach a peak (but who knows when?). Anytime we think that we have finally found a process that can just keep going we will find a surprise.

Once you understand the feedback nature of various tasks and outcomes, you can start to streamline and speed up the overall timeline.