Implement Anything: A General Theory of Implementation (Part 2!)

While it might be good practice to make every post stand-alone... I like to throw good practice in the trashcan on a regular basis (in the pursuit of best practice, of course). As such, this post will only make partial sense if you haven't read Part 1, so for reasons that include self promotion, I encourage you to read it now!

If you didn't buy that... (or want a re-hash), essentially I make the argument that you can profile any implementation you can imagine by weighing it on three factors:

• Complexity - the complexity of knowledge and skills required to perform the particular task that your implementation is modifying or creating.
• Consistency - the importance or necessity for consistency of the deliverable instead of the consistency of how the task is done. 
• Freqency - the frequency in which the task you are modifying or creating is performed. 

Of course, life isn't THAT simple... so there's a bit more to talk about. While I believe those three things nicely wrap up the dynamics of the practice technology and how they integrate with workflows; there are these pesky environmental factors that can throw a wrench in things...

Organizational Resistance to Change

Of course, not all people and organizations are created equal. Some organizations are harder to change than others, and this cultural aspect is extremely relevant to how you approach an implementation. Identifying your company’s resistance to change isn’t as simple as understanding it’s organizational structure or how hierarchical it is when making decisions, though those are factors… How end users interpret change (opportunity or threat) and whether they trust their superiors also play in…

A lot of people assume that a deep hierarchical decision making structure inhibits change, but in cases where employees up and down the chain have a lot of trust for their managers and the people in power are effective decision makers – this can actually be the least resistant structure to change (assuming they agree with your assessment of the value of the change to the organization). Meanwhile, flat organizations with support for grassroots changes might seem like the most flexible, but without the right leaders in place these organizations can suffer from too many implementations all being under-resourced and getting no where fast.

Ultimately, this is a complex thing to measure objectively as there are just too many factors. The best metrics are looking at the success / failure of prior implementations. If you’ve got a lot of stalled or partially successful implementations on life support, that’s a likely sign of resistance. If you look back at the last decade and are pressed to find any substantial implementations at all – that’s a sign of outright oppression. No organization should go a decade without changing a core technology or process.

If you want to read about some experiential ways of measuring organization change, check out my post on the Physics of Change. Again, this is too complex to have a clear, objective measurement system. But, there are some things that you can anticipate will have positive or negative impacts on your company’s inertia, and use those to help predict just how tall the hill / mountain you’re about to climb might be.

Back to the Three C's, and other things that come in threes...

With all that out on the table, lets start talking about how you take all this information and start to craft an actual implementation strategy around what you want to do! Being able to classify your implementations and organizations isn't much use if you don't know how to apply it!

Finding your style

In Part 1 I mentioned that I though of BIM as a train and support style implementation, and Navisworks as a perform and approve style implementation. Well, those words define two of three “Role Triads” for those implementations. I call these “triads” because there are three possible roles or styles within each Role Triad, and definitely not because I'm plotting to build a criminal implementation enterprise...

...Muah hahahahaha hahah ah ah hah ha...

Ultimately, these roles define most of the important decisions you make managing an implementation. How do you support the implementation and the end users? How do you provide oversight so that you maintain or improve the quality of the outcomes your company is providing its clients. How does your company’s leadership need to engage to help motivate the workforce to adopt the change? Once you have clarity on how your company needs to support, oversee, and lead a process or technology change, you have all the major pieces for an implementation plan.

Now, these roles are not simple buckets where every implementation will fall clearly and cleanly into one or another. You may find changes that are borderline between a “training” style support role and a “perform” style (like I initially thought Navisworks was). You might also find certain sub-tasks within an implementation fall into a completely different bucket than the overall implementation (like standard content creation vs. project modelling in a BIM implementation).

And even within a “role” you will find varying levels of intensity will be appropriate. You might have a process that you’re perfectly fine with some kind of random checking process to manage quality, while another implementation that is also falls under a “check” style oversight role may require some automated tools to check every project or every deliverable on a regular basis. In both cases, you’re risking mistakes making it out the door to customers – but the check everything approach makes it much less likely! (That was my Verity Plug)

So, remember, these are conceptual types of approaches, not precisely defined methods. Honing in on the method by which you need to check your team’s work is up to you given your knowledge of the task and the various factors that characterize the task!

Support Role

The support role defines who is best suited to perform the task and what your company needs to do in order to support those people so they can be successful. The foundation for this role is the way that human beings learn and retain information. If that sounds like it references the three C's a bit - it does. You can figure out the right support role to take by going back to your quadrant charts... This role is most heavily influenced by the relationship between frequency and complexity, though consistency can certainly push you over the edge from training to one of the other roles…

• Delegate tasks that are infrequent, non-complex, and need some consistency – In other words, if the charts lead you to a delegate style support role you’re really passing a relatively simple and infrequent task on to an administrative assistant or outsourcing it to a less expensive labor market. Things like arranging travel or arranging for new employee’s drug screens tend to fall into this category.
• Train tasks that are frequent, somewhat complex, and don’t need consistency – Training is the preferred implementation method for most firms, sometimes to a fault. It is the best solution when something needs to be done all the time by most of the people on your staff and the complexity is aligned or less than the frequency. BIM was already mentioned as an example, timesheets or expense reports are other less exciting examples.
• Perform tasks that are infrequent, highly complex, and need high consistency – Like our Navisworks implementation above, creating specialists or teams of specialists to perform work is necessary when you can’t reasonable expect the professional staff to maintain the skillset necessary to perform a highly complex but generally infrequent task. Project financial reporting is one potential example of something that projects don’t do often enough to be really good at and could benefit from specialists.

While resistance to change doesn't have a huge impact on what support role you choose, it can exert a little influence. Training is particularly challenging in highly resistant organizations, so while this may be the default comfort zone for both experience and cost reasons, you may want to lean towards delegating or performing when you're fighting against a strong headwind.

As stated, these aren’t trinary choices. (If "trinary" isn't a word, it should be.) These exist on a scale and when you fine tune your implementation you may find yourself having an implementation that is mostly focused on training, but has a few super-users acting in more of a perform role when the going gets tough. Or, you may have most people filling out their own expense reports or time sheets, but a few people who can’t seem to handle it relying on admins. The goal isn’t to be dogmatic, just thematic. If you follow these closely you can at least be assured that you’re not fighting against how people learn and retain information.

Oversight Role

The oversight role defines who and how to best provide oversight to the practice technology implementation. As with any process, some level of oversight is necessary to ensure the quality of the output, and when you’re making a change to how people work this becomes more important, not less. So, this is a critical aspect of your implementation to consider and plan for. While the oversight role is influenced by complexity and frequency, it is most strongly influenced by -wait for it- consistency! -gasp! Surprising right? (Can someone PLEASE make a sarcasm font style already?)

• Monitor tasks that are very frequent, non-complex, and don’t need consistency – Tasks where failures do not have immediate and significant consequences, where there is ample opportunity to correct any mistakes, or where “mistakes” is more of an opinion than a fact. For these kinds of tasks, you can afford to simply watch what your users are doing and jump in to correct mistakes after they’ve been made. Timesheets or blog posts are great examples of a monitoring-type task.
• Check on tasks that are somewhat frequent, somewhat complex, and need need some consistency – For tasks where failures do have consequences, but not existential ones (for your company, client relationship, or the employee’s future employment), it is usually wise to have a supervisor check how the work is being done before it is turned over to the recipient. Spot checking is one mechanism to do this efficiently, while automated checks are a more robust way to accomplish the same thing. The goal is to find mistakes after they happen, but before the product is turned over and the consequences occur. You generally accept the risk that sometimes you’ll miss a mistake and have to deal with it. Most critical processes end up getting checked because it is the most cost effective way to deal with quality control.
• Approve tasks that are infrequent, highly complex, and need high consistency – Mission critical tasks with immediate or dramatic consequences are the kinds you should be approving. For tasks requiring approval, every outcome should be reviewed in detail by a specialist to ensure compliance with company policy. Hiring new employees or code compliance are great examples of this kind of task.

Your organization’s resistance to change also factors significantly into the oversight mechanism you choose. Why you ask? Well, resistant organizations look for excuses to kill implementations or put them on the back burner. So, the consequences of mistakes are higher for the implementation (and potentially you!) Thus, lean towards more oversight.

Again, a broad spanning implementation may have a mixture of these tasks, but the general theme should fall into one category or another. Within a BIM implementation, project modelling and documentation will probably be something that gets checked by the project manager and BIM manager, but creating company content will likely require approval by the BIM Manager.

Leadership Role

A company’s leadership has a critical role to play in any company change. Leadership is the de-facto flag bearer for change. The individuals that lead a company are ultimately the ones that will find budget and clear roadblocks for someone who is working in the trenches of change. The leadership role defines the expectation for how leadership needs to engage with the staff that are the end users of the new technology or process.

• Evangelize for tasks that are non-complex and don’t need consistency – For tasks that fit this profile within change-friendly organizations, you can get away with evangelizing for the change at company events, newsletters, etc... These kinds of tasks tend to have low implementation costs and a self-evident person ROI to the individual. So, leadership’s main job is just making sure everyone knows about it so that the adoption can be as broad and fast as possible.
• Measure tasks that are somewhat complex and need some consistency – For these kinds of tasks even in a change friendly organization, your leadership team will need to be a little more involved. These tasks take long enough to learn that the end user goes through a little pain getting up to speed. So, unless they’re early adopters, they are inclined to wait as long as possible to get on board the change train. Fortunately, things that get measured get done – so when company leadership establishes some targets and measures progress, that is usually enough to get people over the adoption hill.
• Incentivize tasks that are highly complex and need high consistency – When you’re talking about these kinds of tasks, even the most change-friendly organization is going to struggle with adoption. It will take months or even years for users to become fully proficient, and everyone from the end user to middle management will be resistant to making the switch. Targets aren’t even enough as the consequence of missing the measurement is usually perceived as lower than the costs of hitting the target. In these cases, you’ve got to have organizational incentives to drive the desired behaviour. Bonuses, promotions, team rewards, recognition, etc... If leadership sets the right balance of incentives and targets, cheers on the teams that are trying, and puts successful teams on display – you can overcome the natural resistance to whatever you’re trying to implement.

Your organizations resistance to change has a large impact on this scale, even more so than even the three C's. Any significant resistance to change should immediately bump you up this scale, and if major impediments exist then you can pretty much assume the highest level of engagement is needed regardless of the other factors. It should also be noted that leadership rarely acquiesces to more than just evangelizing for a change unless there is a clear business case for the change.

The Sub-Quadrants

Back in Part 1, when we looked at our four-square charts I told you to ignore the subdivision within each quadrant for a while… well, now it is time to talk about them again. As the discussion on each role shows, all of this stuff exists on a scale instead of cleanly in four simple buckets (or eight for the full cube). One easy way to provide some nuance is to divide each of those quadrants into four and weigh that on the scale of each decision you make about your implementation.

This provides a way to characterize nuances without having to try and keep them all in your head simultaneously. You basically make a mini four-square chart and think about the differences within the broader context of the relationship.

Taking a look at our BIM implementation charts again, let’s zoom in on the upper right quadrant of the Frequency vs. Complexity chart. Let’s think about what might be different if the smaller dark square was one spot lower due to lower overall complexity… With the decrease in complexity relative to frequency, it will take less time to get staff trained and productive. Also, we can expect a larger number of people to be able to do the work. This might lead us to finding less expensive staff, like drafters, to compliment the professionals performing the task.

If we instead consider what a decrease in frequency would cause holding complexity constant… We’d experience the staff having a harder time retaining their training as they didn’t perform the task often enough. This might lead us to create a specialized workforce within our firm to perform the task instead of the professional staff. So, we might still have drafters, but they might be the only ones performing the task.

We can play the same game with the other relationships. The same reduction in complexity that lead us to think we might be able to reduce our labor burden with less expensive employees also tells us that the training program won’t be quite so intense, though still critical to success…

A reduction in the consistency requirement might instead tell us that we just don’t need to worry about requiring training before people start working on real projects. Just throw them on it and train them as they go. It might also lead you to focusing on on-demand training instead of classroom style training.

The big breaks in sub-quadrant behavior tend to happen on the diagonals that divide the chart, or between the major quadrants. But any change at the sub-quadrant level should inform you that more or less attention will be required on particular aspects of your implementation plan.

This is particularly valuable for your implementation planning process when it comes to allocating resources and budgeting for those resources. If the sub-quadrant position tells you something is relatively less important than average for a particular type of implementation, then that is where you can look to do more with less in terms of resource allocation. If the position tells you that you need to focus more strongly than average, then you’d better not skimp on whatever that action is.

Of course, all of this has to be taken in the context of what your company can actually afford in terms of an implementation. You are likely to find yourself in a situation where your company cannot afford (or won’t choose to spend sufficiently) to properly implement a technology in the best way possible.

In that light, these same nuances can help guide you to less optimal but still achievable mechanisms to implement a technology or process change. In general, one should shift as little as possible from the “ideal” implementation techniques. But, as long as you stay close to the sub-quadrant you can probably still be reasonably successful (with more effort!) even when you step outside of where the major quadrant tells you that you should be.

My Navisworks example rings true here as we were moderately successful implementing it in a “Train and Check” style implementation rather than a “Perform and Check” style implementation. It was tough going, but we got a lot of projects working well and a lot of people trained to do 3D Coordination in Navisworks. Was it as easy as it would have been had we started it right from day 1? No. Even if we’d known this from the outset, was there any chance we’d have gone straight to a “Perform and Check” style implementation? No, we couldn't have afforded it. And, if you’re forced into a sub-optimal implementation, you can used this to know where you’re going to struggle and tell that to your leadership in advance – which will give you a lot more leverage come budgeting next year when you’re proven right.

Into the 3rd Dimension

Having mastered each individual relationship, we can now take a step back and look at the 3D versions of the chart as a whole:

Navisworks is on the left and Revit is on the right… Once you understand the 2D relationships these cubes start to say a lot about the kind of implementation you’ll need to pursue at a glance. There is no way (with this system) that I’d have made the mistake of trying to train 200+ project engineers to use Navisworks to run coordination meetings. Likewise, I might have relaxed my guard a bit on content and template standards from where I set it because of the relatively low importance of consistency.

Now, again, one can argue that these charts aren’t accurate representations of one of these implementations – and within their firm you might be right. Things like consistency are highly specific to each firm’s view of its value in the marketplace (is that consistency going to lead to lower prices at bid time, or winning more work). Frequency is dependent upon whether your staff works in multiple platforms (like a scan to BIM service provider that has only half of its projects in Revit). Complexity is dependent upon the requirements and liability that a company’s deliverables are subject to (an architect or engineer’s use of BIM is far more complex than someone documenting an existing building for instance).

It is absolutely critical that you define these factors based on your firm’s situation, proclivities, and resistance to change. What I believed them to be at one particular firm is irrelevant to what they are at your firm. Don’t fall victim to thinking every BIM or financial implementation is the same across companies, or even within your own company. Chart each one out individually and use it as a tool to inform what you should really do.

Applying this to your next implementation

So, the obvious way to apply this to your next implementation is to plot out the change you want to make in terms of frequency, complexity, consistency, and resistance to change and see what that tells you to do. Then, sit down and figure out at a high level how you want to approach it relative to your general staff. The same approach works to understand smaller portions of your implementation that may not adhere to the broader strategy (Revit content creation was an example of this I used earlier) by narrowing what qualifies as “general staff” for performing that task. Once you’ve got it all charted out, you need to encode that learning into your implementation plan so you can get down to the nitty gritty details and plan your route (not just your destination).

But, what happens if you don’t have a clear destination for whatever reason… Well, you can also use it to understand inconclusive or non-optimal implementation realities and figure out how to best implement these tasks as well…

Reverse Engineering

So, let’s say that you charted out an implementation with your general staff in mind and got something that wasn’t very conclusive, or you don’t have the resources implement in the way you want and are left with something less ideal and thus less clear…

Well, you can reverse engineer the changes in situation that you need in order to make what you’re planning on doing more successful… Take a look at the adjacent sub-quadrants to the less than optimal implementation you’ve been backed into for whatever reason. Are any of those more clear and easy to implement? Does one of those look like a better fit for your resources or structure? If so, try and classify what is different in terms of frequency, complexity, and consistency for that clear cut implementation than what you’re stuck with. Armed with that information, try and find a way to match your situation to that one instead of finding the best possible implementation for a company-wide implementation.

This usually comes in the form of limiting or isolating where the implementation starts. If you’ve got a studio that is more open to change than the others, and you can’t get buy in to incentivize change from your leadership yet – then modify your plans to implement only in that group where it isn’t needed. Once you can show success for the business, it will get a lot easier to get buy in to incentivize the rest of the company properly. Or, perhaps you’ve got a simpler project type in terms of complexity or consistency that can minimize your training burden up front.

Conclusion:

The beauty of a system like this isn’t that it is perfect – because it isn’t! But, it provides a consistent nomenclature for communication (which is pretty important!) and provides a way of temporarily simplifying what is otherwise a ridiculously complex system. For me it has provided a framework that allows me to quickly make sense of what might otherwise be overwhelming.

I end up on the receiving end of the “how should my company implement BIM” question quite a bit, and before I had this tool in my back pocket my answer was an equally vague: “Well it depends”. And, while true, that rarely got a positive reception. Now, I can come back with a couple of questions to hone in on how frequent, complex, and consistent the implementation needs to be; how resistant to change the organization is; and then come back with a relatively tailored and useful answer. The best part is that I can do that without having a truly deep understanding of the technology or process they’re asking about. As long as they have the understanding and can answer the questions well – we’re in business.

The best part is seeing the outcomes of correctly matching the technology and process change with an implementation style. At the end of the day it can dramatically reduce both the implementation costs and the schedule to get to fully implemented. I’ve seen companies that get it right push through a full transition from CAD to BIM in a year instead of three to five (the average). That comes with a lot of reduced costs (software licenses through overlap, hours in training – particularly repeat training, implementation management hours, etc…). It also comes with the ability to more rapidly take advantage of the benefits of the change (winning more work, ability to recruit better staff, productivity savings on projects, etc…) Those two benefits combine to achieve overall ROI much more quickly than possible with a less ideal implementation. And of course, ROI is the ultimate measure of any implementation.

Did you say there's a Part 3? Sheesh...

Well, I could write a book on nothing but implementation planning. It is something so few people take the time to do, even though we work in an industry where planning, scheduling, and budgeting are paramount to successful outcomes. This isn’t too surprising of course, most of the people who enter the industry as professionals tend to think of technology and process as being in support of project delivery, they rarely think of them as projects themselves. I mean, what client would start a project without a clear ROI? What company would agree to build a building without knowing they'd get paid enough to earn a profit on the work? Bankrupt ones, that's who.

But, that's what Part 3, Part 4, and Part 5 are all about! So, stay tuned. That should come out next week if I don't get any unexpected support burdens! Thanks for sticking with another long post!

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!