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.

Dictating process without owning delivery accountability will always lead to fragmented implementation.

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.

Comparing top down process changes versus guerrilla improvements.

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.

Creating standardized processes in the middle of organizational chaos is self-defeating.

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.

5 Rules for Making #CRE Processes Work for You

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).