Implement Anything: A General Theory of Implementation (Part 1)

I’ve been very lucky in my career to have implemented a lot of big and small changes into practice. This spans the gamut from implementing Revit into our design practice to getting an automated export from our accounting platform into our departmental projections spreadsheets to more quickly incorporate personnel changes into our quarterly forecasts. I know, sexy!

All in all, I have been directly responsible for or in a leadership position on a whopping 8 major practice technology implementations in that time and a whole boatload of smaller ones.

So, let me say with all due pride – I’ve messed up about every way conceivable in those 10 years, had to grind it out anyway, and have learned a lot in the process. Given the differences between each of those implementations I think I’ve experienced a fairly broad spectrum of process and technology integrations, at least within the AECO space. While that is by no means an exhaustive or complete gamut, I have been able to recognize some high-level consistencies that I want to share today. So, here goes the grandiose statement:

 I can tell you what kind of implementation you should pursue within your company on any implementation given just three bits of information.

With that said, time to start bailing water… What I can’t do with just three bits of information is give you a detailed implementation plan, but I can tell you whether you should head North, South, East, or West – which is actually pretty darn valuable all in all. With that direction set you still have to layer in things like your organization’s physics of change, weighing sharks vs. lightning as a potential threat, your own tendencies to get stick in a mental rut, etc… But, you’ll at least know if you’re heading for cooler weather or a sultry beach – and you’ll know what to pack.

 Let me prove it to you…

Boom. ‘Nuf said, right? Wait, that’s not self explanatory? Darn. Well, here are the details.

The Three “C’s” of Implementations

1.  Complexity

2.  Consistency

3.  Frequency

(Hey, the US educational system’s foundation misrepresented wRiting” and “aRythmatic” as starting with “R” to make the “three R’s”, I only had to stretch one of the three in my trifecta. #winning)

Complexity

This factor is really representing the complexity of knowledge and skills required to perform the particular task that your implementation is modifying or creating. It is ranked in terms of how long it takes the average person to master the skills and knowledge needed to perform the task professionally at a high level of quality. If it takes your staff a few months of dedicated training and practice to master, it is pretty complex. If they figure it out in an hour, not so much.

Consistency

Here we are really talking about the importance or necessity for consistency of the deliverable instead of the consistency of how the task is done. While the latter can be of import, usually it is to create a higher likelihood of the former. So, focus on the end goal. This isn’t whether you’d like consistency, but rather whether it is needed for the deliverable to be successful. This is ranked in terms of the span within your company or industry that consistency matters. If consistency only matters across one project, then it isn’t very important. If it matters across the entire company, then it is really important.

Frequency

This refers to the frequency in which the task you are modifying or creating is performed. This is ranked as you’d expect, by how often the task is performed. There is one tweak to mention though, since not all tasks are consistent over a project’s duration or a person’s role there is an adjustment down you need to make for intermittent tasks. If you do that task once a day, then it is pretty frequent. If you only do it a few times per month then it is very infrequent. And, if you do it daily, but only for half the project, then it isn’t particularly frequent as a result.

Perspective, perspective, perspective…

Keep in mind these evaluations are all from the frame of reference of your production teams. They are ultimately your customers in any implementation and their perspective defines how implementations are viewed. In other words, just because YOU find something trivial and easy to learn doesn’t make it so for the rest of the population. You need to understand your “customers” well enough to see things from their perspective. Besides, without a little empathy you’re doomed anyway.

Now, before we dive into the 3D Cube and the Borg jokes ensue (resistance is futile), let’s start by looking at the simple 2D relationships we see on each side…

Four Square

At a high level, each of these 2D comparisons can be thought of as a simple 4-square graph with the two factors as the X and Y axes. This is a very typical chart type people are familiar with, and most of the rules apply as expected. You’ll see there is a further subdivision within each 4-square. The overall quadrant will tell you your cardinal direction, the sub-quadrants will tell you what to put in your suitcase. We’ll come back to that in a bit, let’s focus on the larger quadrants first.

 You will probably see the key value of the relationships very quickly. Using two of the factors above, you establish what quadrant your implementation falls into. Let’s take a look at the first side…

 Frequency vs. Complexity

So, if frequency is all about how often you perform a given task and complexity all about how long it takes to learn a given task, you can probably start to draw some interesting relationships between these two factors already. The more complex, the harder it is to learn and retain expertise. The more frequent the more often you use the skills so you can master and retain your capabilities. Ultimately, this relationship helps us figure out what individuals or roles within our companies can be expected to perform the task in question…

So, if you have a simple task people do every day, then theoretically anyone can do it. If you have a highly complex task that is performed every single day (or a simple task that is performed occasionally), you can expect most professionals to be able to learn and retain how to do it. But if it is a highly complex once-a-month kind of task, all bets are off for training and retention for most of your staff. It’s time to call in the specialists for that kind of work.

Simple examples: Professional photo retouching vs e-mail. While anyone can, with enough training and practice, make Kim Kardashian’s butt impossibly bigger in such a way that it is almost undetectable (Cue “My Butt” audio clip from SNL), it isn’t like falling off a log. And, it isn’t like she needs the service once every few months. This is a regular occurrence for the Kardashians. So, as soon as you’re done with one Instagram selfie, you’re going to get a call for a Versace photo shoot. Meanwhile, e-mail has gotten so simple your grandmother can do it with minimal time required from you for basic training and creating some shortcuts on her desktop. Account set up and getting her e-mail client connected doesn’t count, that’s behind the scenes the user doesn’t need to do or see so it doesn’t factor into the complexity of the task. (Complexity of the task does not equal complexity of the implementation!)

Now imagine your job is to create that capability within your company. I’m pretty confident you’ll need a different set of tools to create an in-house photo re-touching shop than you will to get people using e-mail. If your implementation is both frequently performed and highly complex you will be going down a different road than if your frequency is high and complexity low.

Frequency vs. Consistency

Consistency is all about how the end product needs to look. Pair that against frequency, and you’ve got a way to figure out how many people you can have performing a task so you can manage the quality of the output...

So, if no one really cares about consistency of a particular task’s output, pretty much anyone and their dog can do it. If both the frequency and consistency are high, you’re probably looking at a specialized department with some QA responsibility for whomever is managing that team. If consistency is high but the frequency is low, that department might just be one person who QAs themselves. In other words, if it has to be consistent you probably don’t want everyone doing it.

Let’s go back to our brand new photo re-touching business. Kim is probably pretty picky about her image, so she most likely doesn’t want just anyone staring at her profile for hours with the clone stamp and color blending tools. So, she’d prefer have just one or two people dedicated to making her look consistent in all her photo shoots and TV shows. Then there are the millions of people who sit by their TVs with their eyes taped open watching any one of 10 E! shows that have the Kardashians in them, and they are all just waiting for the tiniest little evidence of photoshopping to raise a ruckus. The tweetstorm would be ginormous, Instagram stock would crash, and Snapchat might gain some of that lost valuation back…

Now, if Kim was only on one show it isn’t like it would be a full time job, so you could probably just have Justin take care of her image when it was needed. But, she’s on 10 shows… and probably has her Instagram photos touched up too. So, the frequency is high enough to far surpass one person’s 40 hours a week. That means a department so we can meet the demand but still make sure that Justin and the rest of his team are the only ones that “get” to do that job. They’re specialists after all.

Meanwhile, no one cares whether John likes to use hanging prepositions or I like to use passive voice when writing e-mails. As long as our signature doesn’t contain something inflammatory it’s pretty much ok. It isn’t like you’re going to hire a team of retired English teachers to write everyone’s e-mails just because they use proper grammar and spell good… Oops, I mean spell well.

Complexity vs. Consistency

When we pair up complexity and consistency we gain insight into the training and support burden we’re taking on from implementing the change…

So, if the complexity and consistency are both low, you might even get away with letting people wing it. For more complex tasks with low consistency, you’ll need strong initial training but the long term training and support isn’t going to be too intense as people can more or less do what they want once they know how to do it. For highly consistent but easy to master tasks, your training regime isn’t going to be about the technology as much as it is about the standards and templates that people need to use to deliver consistent output. And, for highly complex and highly consistent tasks, get ready to spend a lot of time maintaining training, templates, standards, etc… You’ll probably end up with multiple staff dedicated to those tasks long term.

In Justin’s photo re-touching department we set up for our Kardashian clientele, we’ve already specialized the functionality so we can probably rely on Justin to provide that training, any templates or standards he expects his team to use, and to manage the quality of the output through some review or approval process. So, that’s good… Of course, if Kim loves the work she might brag to all her friends about the amazing work we do for her, and once we have a whole business line with multiple clients driving a majority of our work, the “specialized department” grows to a business unit and all of a sudden you’ll need a robust training and quality infrastructure to make sure all your model / actor clients are getting the same consistent and high quality results that brought them to your doorstep in the first place.

Meanwhile, your grandmother is cranking out a couple of e-mails a day just fine. You might want to keep her in the loop on phishing schemes and make sure you’ve got an antivirus checking her computer regularly so she doesn’t get into trouble by clicking on links in weird e-mails. But, after making it as easy as possible for her to get in, read, write, and get out you probably just need to give her an on-demand refresher course every once in a while. She is your granny after all…

 All together now…

If we look at all three comparisons side by side (which together make up the cube) we get a picture of the overall implementation right away.

This particular set of charts represents a Revit implementation. Frequency is high since the end users typically are in the product most of the day. Complexity is high because it takes 6 months minimum before someone is truly proficient documenting a project in Revit. (And years to be proficient as an Architect.) The consistency is in the lower quadrant because consistency is only required within a given project (that is firm specific of course, some place higher / lower values on consistency).

These three relationships tell me what I need to know to craft an implementation strategy at the 50,000 foot level.

Because the frequency and complexity are similar, we can realistically demand that the professional staff become proficient using the tool. It will take time for people to get up to speed of course, but they will retain that skillset since they’re in the application most of the time. Because the consistency is low the implementation doesn’t really require having a limited number of people perform the task or building up a substantial oversight staff to check/modify the work output. Because the frequency is high that can be done at the project level by the project management reasonably well. Also, standards will primarily be focused on aiding efficiency rather than focused on compliance, which leave some room for project-level ingenuity.

In this case, I would focus on what I call a “train and check” style implementation. In this case, the professional staff will be the primary user and the implementation resources (you) will be focused on initial training and then long term support through templates and some continuing education for new features or additions/changes to standards and templates.

Now, let’s take a look at another similar implementation…

This set of charts represents a Navisworks implementation. The obvious differences are a decrease in frequency and an increase in the importance of consistency. That is driven by the intermittent nature of 3D coordination on a jobsite. It runs hot and heavy on the jobsite with use several days of the week (but not all) for about a third of the job duration. But, the other two thirds of the job it is used significantly less often. Meanwhile, most construction companies work with a consistent stable of subcontractors in a given region, and subs love having consistent processes and obligations when it comes to coordination. So, where does this little set of charts lead us?

All fingers point to a “perform and check” style of implementation. This means a team of specialists performing this task on every job so that the general staff’s interaction is mainly participatory (meetings) and receiving the output of the 3D coordination process. They may take that output and create the RFIs or submittal markups that come from the discoveries in the process. However, they won’t be running clash detection or running the coordination meetings themselves. This specialist staff creates the environment for consistency across projects as well as avoids the pitfalls of the general staff losing their skills over the 2/3 of the job they don’t use the tools regularly.

Mismatches and mixed messages

Now, if your BIM or Navisworks implementation doesn’t follow those guidelines, don’t stress. You might have a different approach for very good reason (your firm is obsessed with consistency across the company for documentation standards, etc…). Or, it might be because you didn’t have the resources or time to do it in an ideal way, etc…

At Beck, I was responsible for the 3D coordination implementation off and on for several years before I came up with this little system, and I did not approach it the ideal way. We had tried for a “train and support” style of implementation for this just like we did with our Revit implementation. Let me tell you, it was a beating.

We had our reasons (good ones) for approaching it the way we did of course. We had limitations on corporate staff headcount and a tight budget. Building up a dedicated team of coordinators was going to be a tough sell. Also, we believed that having the general staff trained in Navisworks would lead to some other follow-on benefits like them using it for things like quantity take off or pay application backup. Unfortunately, none of those things panned out because very few people really maintained a sufficient level of comfort within the tools to do these things through the life of the project. Finally, our new coordination implementation leader (Thanks Mason!) came in and argued for a dedicated staff of coordination managers. In our discussions he hit upon the intermittent nature of the task for the general staff, and it clicked for me. Duh.

All of a sudden I understood why it was such a difficult implementation all those years: we were fighting human nature.

You can do it (we did for 6 years) and you can even be successful (we were arguably successful at it), but it will be a lot more effort and stress than necessary and it will limit how successful you can ultimately be. By the time I left Beck things were going much better under Mason’s leadership as a result of aligning our strategy with how people actually behave (which is, of course, what is behind this system).

Now, not all implementations are as clear cut as BIM and Coordination on the chart. Sometimes you’ll have one that leans towards “support and train” on one chart and towards “perform and approve” on another. Those are a little tougher, but most of the time two of the three charts agree, so go that route. Ultimately, the frequency and complexity relationship is the most important of the three, so the only time it gets really dicey is if that is the outlier…

Hey, no system is perfect. You’ll at least know you’re headed into murky waters!

Part Deux...

So, that's not the whole system (hence the "Part 1" in the title). But, I think this is long enough for one LinkedIn post. Spoiler alert - in Part 2 I'll talk about the Role Triads (not a criminal organization), how your organization's resistance to change (Physics of Change) fit into this system. Super secret spoiler alert - in Part 3, Part 4, and Part 5 I'll talk about ROI. Your eyes will pop out of your head (hopefully not from boredom).

And, if you want to play with the materials discussed above and in future parts you can download them all:

Implement Anything Materials

ROI Materials

Have fun!