Blogs

I am publishing this due to a lack of vendor communication regarding this topic. If it does not directly apply to you, please get it into the hands of the appropriate person.

Consider this a Public Service Announcement that represents the viewpoint of Mark S. Ditko of Zen Engineering, regarding continued use of InRoads SS2. What follows is based on my experience, recent dialogs with the user-base, and relationships with many, many users in the Public and Private Civil Engineering Industry, as well as being involved in numerous discussions with Bentley Systems spanning many months.

I know this rant will likely come across as harshly critical due to the sympathetic frustration that I feel for the user-base, and the lack of answers emanating from Bentley. With that said, I do not attest to know or understand all of the moving parts that are involved here, especially as to what or who is driving Bentley’s actions, but I can judge this situation by the ‘disconnect’ that I am witnessing between the user-base and the vendor.

I also understand that this rant does not apply to 100% of the user-base, as some are in a better position than others; however it is my assessment that the percentage of prepared ‘early adopters’ is significantly smaller than the audience that this is written for.

Freely forward this to anyone that you feel should have it. If anyone wants to personally speak to me about this, email me at This email address is being protected from spambots. You need JavaScript enabled to view it. and schedule a time to chat.

The Situation:

InRoads SS2 is the dominant, and most stable version of InRoads currently being used by both the Public and Private Civil Engineering sectors, and it needs to be operational for at least the next several years. Yet, Bentley is planning to alter the current licensing scheme making it impossible to operate in ‘business as usual’. And currently (as of early July 2020) Bentley does not have any definitive answers as to the details behind the continuing usage of InRoads SS2; however, their intent is clear.

Notice Given:

This is the extent of the notice that I received on the 23rd of June, 2020:

Hi Mark,

As of January 1, 2021, your Bentley V8i* desktop application support and licensing services will expire.

Are you ready?

If you have any questions regarding this email please contact This email address is being protected from spambots. You need JavaScript enabled to view it..

*(pre-SELECTseries 10)

Main User-centric Issues in Play:

  • At some agencies, all (or the vast majority of) projects are currently still being built on InRoads SS2. These projects have been in the design phase for varying amounts of time and can go for several years through construction and change orders. During that time, InRoads SS2 is needed to either complete these projects in design or may be required to make ongoing changes throughout the life of the project as it moves through the construction stage.
  • At this time some agencies have not even begun working on their OpenRoads Standards and are not yet prepared to start new projects on ORD, let alone migrate current SS2 projects to OpenRoads. Again, this reinforces the reality that InRoads SS2 will be needed for several more years at a minimum.
  • The DOTs and larger agencies are clearly a strong driving force behind the private consultant community’s migration to OpenRoads, and to a degree are “at the mercy” of the DOTs rollout schedule, technical & administrative readiness, and internal adoption of OpenRoads.
  • Migration of InRoads SS2 projects to OpenRoads is not automatic, and beyond a certain point in the development of the project data on SS2, can be time consuming and will not come without schedule and cost implications. And further, if brand new OpenRoads standards are developed, then that InRoads SS2 project data migration process has an even higher impact associated with it.
  • Training is also a necessity before OpenRoads is rolled out. If this is not taken into account, you can be assured that the learning curve will further impact the project schedule and budget.
  • Cost-wise, everyone that had InRoads SS2 were ‘upgraded’ to OpenRoads in 2017 and charged more for that license upgrade, whether they were actually using OpenRoads or not. This cost increase included licensing for the new OpenRoads software as well as for all ‘legacy’ products, allowing users to continue using InRoads SS2. (Legacy products refer to all past versions of InRoads or GEOPAK or MX, including SS2)
  • Moving to SS4 (SS10) from SS2 is not recommended. The amount of effort that it would take to do that would be better invested in moving to OpenRoads. (This has even by mentioned by Bentley.) If anyone is interested in discussing this please contact me.
  • The Public or Private sectors should not have to bear the burden of schedule or financial impacts to their projects due to Bentley’s decisions regarding the SS2 product line, its maintenance or licensing system.
  • The transition to OpenRoads should not and cannot be done hurriedly.
  • This InRoads to OpenRoads transition is a very dramatic one. I have used InRoads since the first version was released in 1989, and have experienced, firsthand, every InRoads software evolution. This jump to OpenRoads is the most significant change I have ever experienced by far.
  • I’ve said this in my Zen Dude blog article OpenRoads Designer CE Planning found here: http://thezendude.com/blogs/82-ord-ce-planning.html This “quantum leap in software technology warrants a review of your existing workflows”. And rightfully, I see that some are taking advantage of this opportunity. This makes the transition from InRoads SS2 to OpenRoads even more significant, and warrants the extra time involved.

FYI – The Software Timeline:

InRoads V8i

  • February 2010, Initial Release
  • May 2013, Last “SS2” Release

InRoads SS3 -> SS4, Aka FrankenRoads

  • 2013 -> 2016, The technology “Experimental Age” moving toward OpenRoads

OpenRoads

  • November 2015, Bentley officially announces the future OpenRoads software replacement for InRoads, GEOPAK and MX
  • April 2017, OpenRoads first release (but did not include Survey)
  • December 2017, Initial OpenRoads Survey Release
  • May 2020, Latest OpenRoads Release (this is the 12th release of OpenRoads)
  • Another release is due out any time now

The Bentley Stance… and a Rebuttal:

  • Bentley is observably currently working with the DOT’s regarding SS2 licensing.
    • ZEN: But rarely have I heard any mention regarding how their negotiated licensing agreements and arrangements with the DOT’s will ripple down to the consultants.
  • Bentley has stated that “the DOT’s are critical to Bentley moving forward”.
    • ZEN: Actually, all InRoads users are critical, including those in the private sector, and in some cases even more so relative to some projects.
  • It is my understanding that the current Bentley Select Server mechanism used to manage InRoads SS2 licensing is being ‘retired’. Whether that is due to antiquated and retired Operating System technology, or an internal Bentley decision not to apply resources to a solution is unknown to me at this time.
    • ZEN: Regardless as to the ‘why’, Bentley is not releasing any satisfactory information as to how InRoads SS2 users (Public and Private) will continue to run the software, uninterrupted, beyond the end of 2020.
  • Bentley wants the Select Server gone and have stated that they “are trying to find a solution that works for the DOTs …. And Bentley.”
  • Bentley’s main ‘solution’ to Bentley’s license maintenance problem is to convert all InRoads SS2 projects to OpenRoads
    • ZEN: This is not feasible for so many reasons, namely:
      • Project cost impacts – It will take $ to move projects to OpenRoads
      • Project schedule impacts – It will take time to move projects
      • Internal manpower – It will take internal resources to move projects
      • Lack of a functionally tested and vetted OpenRoads configuration
      • Lack of trained staff – It takes time and money to train users
      • A proven reproducible SS2 to OpenRoads migration processes
      • There will be many other technical, administrative and contractual tasks that need to be done in order to migrate ongoing projects to OpenRoads
      • All to be done before December 2020 in our current lock-down condition is extremely unrealistic
  • Another “solution” being discussed by Bentley is to ‘Node Lock’ or ‘Machine Register’ an InRoads SS2 license to a specific computer. This is done by taking one of the available licenses and assigning that license to a specific computer. This activity removes that license from the available pool of licenses, and permanently ‘checks it out’ to that computer. If a company had 5 InRoads licenses, they would choose which specific computers would need InRoads SS2 and then lock a license to that computer and reduce their available licenses by that amount.
    • ZEN: This ‘Node Lock’ or ‘Machine Register’ licensing model has been mentioned as the alternative to Bentley’s intent to drop their Select Server system that is currently handling the licensing for SS2. This was put out in an email notice on December 31st, 2019; however, to date, no actual details of this process have been presented as to how this will be accomplished or implemented.
    • ZEN: The major problem with this occurs with smaller firms (or anyone that has more users than licenses) that pool, say, 10 licenses between 20 users. After Node Locking 5 InRoads SS2 licenses to 5 specific computers, there are only 5 licenses left in the pool to run OpenRoads. Additionally, InRoads SS2 can only be run on those 5 node locked machines. And even though there are still 5 available licenses, they cannot be used to run InRoads SS2. Now, if a user starts a new project (probably on OpenRoads) but also has a machine that has an SS2 Machine Lock on it, he is in essence tying up two licenses – the OpenRoads license that he’s using to work on his new project, and the InRoads SS2 license that is machine locked to his computer that cannot be used anywhere else. This is an unworkable system. But it gets worse.
  • The buzz on the street is that Bentley intends to charge ‘more’ to ‘allow’ users to run SS2 under this machine lock scenario. Regarding this, I was sent this statement (source not identified): “If they want to continue using the MicroStation-InRoads SS2 combination using a node-locked license there will be an extra charge for each seat, about $3,500 (depending on discounts).”
    • ZEN: The obvious issue here is that in 2017 everyone was automatically upgraded to OpenRoads with an increase in invoicing cost from Bentley. This increase came with the agreement that all legacy products could be run with that upgraded license, which included InRoads SS2. And now Bentley is discussing charging even more to run a less expensive product that should be covered under the earlier increased cost of OpenRoads. And in most cases since 2017, the more expensive OpenRoads product was not even being used. So, in essence, InRoads SS2 has been being run by everyone since 2017 at an increased cost, and now the intent is to increase it even further as a ‘courtesy’ to ‘allow’ it to continue to be used.
    • ZEN: Additionally, those that have purchased InRoads SS2, and have a perpetual license, may have to be charged extra to continue to use it; however this is unknown since Bentley has not issued any definitive statements regarding this.
  • Bentley has stated “We are really listening, finally ”.
    • ZEN: From my observation, not only are they not “really listening”, but they are not even talking to the broad user-base. All I see is their continued drive forward pushing their own agenda with the DOT’s in mind and not the smaller consulting firms who will be hit the hardest by this.

The Flaws:

  1. SS3 / SS4
    1. Bentley believed that InRoads SS2 users should have migrated from SS2 to SS3 and then to SS4 as these experimental versions were being released.
    2. These experimental versions were only used by the ‘early adopters’ not the broad user-base that were focused on the usual daily demands.
    3. These experimental versions were not appropriate for active / live projects due to their convoluted workflows, replicated ‘synchronized’ InRoads / OpenRoads project data, and piecemeal toolsets. Bentley’s own OpenRoads Community is saturated with posts of problems from users attempting to work on and complete active projects in SS3 and SS4. I know, I’ve read ever one of those posts along with the responses.
    4. SS3 and SS4 were always a dead-end road forever destined to be replaced by OpenRoads
  2. SS2 vs OpenRoads
    1. InRoads SS2, was the culmination of many years of software development and practical use and had become a solid piece of software capable of doing most everything that was needed.
    2. An “If it’s not broke, don’t fix it” attitude was being used by most people when it came to the OpenRoads migration
    3. By 2017, most everyone was trained in InRoads SS2, or could be easily trained and supported by a knowledgeable support structure that exists
    4. It has been said by others that the larger government agencies are like steering a battleship. It takes a long time to turn it another direction. And so it is with OpenRoads. And we’re still just starting that turn.
    5. It wasn’t until just two years ago, in the Summer of 2018, that OpenRoads was released with mostly complete Survey functionality, and only 6 months ago in January 2020 where much needed CAD Management functionality was added.
    6. OpenRoads has only very recently reached a stage where it has evolved into a more usable package. And yet it still has its outstanding Service Requests and needed improvements.
    7. The true era of OpenRoads has just begun.

What’s Needed:

InRoads SS2 needs to run for the next several years without additional cost, and without interrupting or affecting any potential ORD usage or licensing.

More specifically:

  • The Public and Private sectors need to use InRoads SS2 beyond 2020
  • SS10 is not a solution unless their environment is currently running and configured for SS4
  • SS2 needs to run for at least the next 5 years to accommodate active projects nearing completion as well as ongoing construction projects
  • There should be no additional financial impact on the Public or Private sector for using InRoads SS2 beyond 2020 other than the current OpenRoads license fees
  • There cannot be a license usage impact for anyone choosing to use either SS2 or ORD and current licensing flexibility to use SS2 or ORD should be maintained as it currently exists today and in recent years.
  • Bentley needs to develop a solution that works for everyone, small and large government agencies and small and large private companies. Bentley should be addressing this issue globally with the entire user-base.

It is highly recommended that someone in your organization read and understand the Bentley EULA (End-User Licensing Agreement) and existing contract between your organization and Bentley with regards to SS2. The Terms and Conditions might require a ‘Contracts’ individual in order to properly understand and interpret it, but this needs to be done by someone. Any future agreements should only be considered after you understand your current agreement as a starting point.

These days, Bentley users are in a perfect storm so to speak. Windows Operating System changes, retiring Windows Server OS’s, Bentley’s technology race against Civil 3D, InRoads SS2 in such heavy broad use yet uncertified for Windows 10, OpenRoads being pushed as a replacement that carries such a heavy migration workload, and Bentley decision to start the SS2 doomsday clock ticking. Add to that the current state of the Country and World and you’ve got a cocktail that will set you on your arse.

Feel free to contact us as needed. We’re here for you.

Civilly yours,

- mark

This post was in response to someone asking us about OpenRoads, and it was then subsequently issued as a “Footsteps”. I felt the content was worthy of posting here to increase the odds of someone finding it.

First, I’ll say that this is the topic of the day for anyone running the Bentley Civil software (InRoads, GEOPAK or MX) and is exactly what ‘someone’ has to be thinking about. And I guess that’s you.

Okay, where do I start? …and I wish that it was a quick easy answer, but unfortunately it’s not (due to the dramatic nature of the changes in the software).

Relative to OpenRoads in general – you really need to be considering a larger master plan to roll out OpenRoads, and training is only one piece of it before we feel that you can move into any level of production.

In a nutshell, before I get into where Zen is, here are the key stages or areas that we feel you should be thinking about:

  • Why?: First you need to ask yourselves (internally) “Why should we move to OpenRoads?” And there should be a very good reason with specifics, not a general “because it was just released.” …or “everyone is doing it.” I wrote a general response to an article From the Editor in the magazine called Informed Infrastructure related to this subject. The original editorial and my response are posted here on my personal blog: http://thezendude.com/blogs/74-old-habits-die-hard-a-zen-retort.html  
  • Client Requirements: Who are your clients, and will they be using OpenRoads? Right now, full backward compatibility between OpenRoads and InRoads doesn’t exist. The two software versions are just too different. So if your clients aren’t using OpenRoads, I would not recommend that you use it in production and expect to deliver InRoads files to either your clients or other offices.
  • Standards: If your clients are requiring OpenRoads, or are moving to OpenRoads, then they may be developing the standards to be used within the software. This configuration is significantly more than just the simple XIN that InRoads used. And, configuration-wise, there is no easy migration path from InRoads to OpenRoads regardless of what anyone else tells you. If your clients are not driving your move toward OpenRoads, and it is internally driven, then you need to factor in how your software standards will be developed. Again, this is no small task, and although Bentley delivers some standards “out-of-the-box”, I have personally found those standards ‘wanting’. Aside from the quality of those standards, they are most assuredly not your standards (Survey alpha / numeric coding, Levels, Line Styles, or Cells / Symbols for example). Prepare yourself to invest some time and / or money into developing a good set of OpenRoads standards.
  • Workflows: OpenRoads is a quantum leap in software technology and warrants a review of your existing workflows. Be prepared; moving to this software will not be ‘business-as-usual’ so don’t expect it to be. This includes how you post-process survey data, how you create terrains (surfaces) from various sources, how you layout your Geometry, how you approach a complex modeling project, how you construct your final drawing package and individual sheets, and how you annotate those sheets, just to name a few areas. This will include ‘who’ does ‘what’ and who is using OpenRoads versus simply just using MicroStation. This can affect the number of software licenses that you have, or will need. You will have to adjust your workflows and how you accomplish your work as it relates to your interaction with this software. And I can tell that you are already aware of some of this since you mention the fact that you will now be managing DGNs instead of the traditional InRoads data files. And that is just the tip of the iceberg.
  • Documentation: This is the formal extension of the Workflow piece. The reason that this is so important with OpenRoads Designer, and wasn’t as critical with InRoads, is because of the “Rule-based” nature of the new software. Gone are the days when you can just haphazardly throw out construction lines in MicroStation and delete them when you don’t need them anymore. With the OpenRoads rules and “Design Intent” the software is remembering everything that you do so it can recreate the design should something change. That means that if you delete something that has established a “parent-child” relationship (that would be done after having placed a construction line and then removing it later) the software won’t know how to dynamically update the design due to the ‘broken’ relationship. The bottom line here is that your users will need to know what they can and cannot do relative to this new “Rule-based” design mentality.
  • Training: This will be critical to anyone who wants to get up on the learning curve quickly. This is obvious to some people, and I feel sorry for the users that work in an environment where the value of training is unacknowledged. And one final point on this is that all training is not created equal. Our training classes are being developed with OpenRoads in mind, not a regurgitation of an older model of training that fit InRoads. With OpenRoads, there are areas of the software that are much more important than others and our training will reflect that. And lucky for the trained InRoads user, our training will leverage that legacy InRoads knowledge and use it to anchor the new OpenRoads concepts and functionality to the various design tasks.
  • Pilot: Before putting the software on an actual project where the schedule and budget will be adversely impacted if something breaks down, it is highly recommended that you do a pilot project (or 2) on the software. There is no better way to know that you can actually use the software to get a project completed. In the past several years I’ve known too many places that had to abort a project on the software due to the fact that they could not accomplish what they ‘assumed’ that it could do. Don’t make that mistake, this is not InRoads anymore. For instance, the current version of OpenRoads cannot do End Area Volumes. In many cases that method of producing quantities goes back for decades and decades. Not having that functionality directly available in the software could blind-side you if you didn’t find out until it was too late. And then you’ll find yourself frantic and scrambling for a work-around. But a pilot project will reveal things like that and provide you an opportunity to have a well thought out contingency plan, or opt out of using the software until it was more developed in those areas.
  • Support: OpenRoads places a heavy requirement on the need for a CADD Manager, and CADD Support staff for a number of reasons. 1) Not only will there be more questions and issues due to using different software, but there will be less available answers simply because the software is so new, world-wide. 2) The way that the software is designed, many of the commonly accessible settings from InRoads (like the Project Options and Survey Options) are now located in either DGNLIBs or Configuration Variables or Design File Seed standards. These locations are historically not available in a Read-Write location for the average user, nor are they generally familiar with those Workspace level settings. This will need to be addressed before moving this software into production. And 3) the software is still evolving, and in some cases dramatically. For instance, Annotation set up in Update 2 doesn’t work quite right in Update 3. But Update 3 provides needed fixes that users need and want. That means that your configuration and standards will have to be revisited every time a new update is released. And be prepared for a new update every 3 months. Yes, 4 times a year.

And a few other things to consider:

  1. There are aspects of the software that are incomplete, like the Survey piece. Right now you cannot use OpenRoads to replicate what was possible in InRoads. OpenRoads Survey just isn’t fully developed yet. For example, the capability of Custom Operations to use Attributes in InRoads Survey does not yet exist in OpenRoads Survey.
  2. There are tools within OpenRoads that aren’t fully developed yet. These tools present themselves as “Technology Previews” and may or may not be fully functional yet.
  3. The tools that you may have become accustom to, like the Check Integrity tool for Geometry within InRoads, don’t all exist in OpenRoads. This is a primary reason to make sure you are very familiar with the capabilities of the software before your roll it out on a live project with a defined schedule and budget.

Now, as far as Zen goes – We have been buried in OpenRoads for some time now and are just finishing up our internal “Configuration Phase”. Starting next month we’ll move into the “Workflow and Documentation Phase”. We expect that we will be working on this next phase until at least the end of the year. We’ve already started to build some training around some of the OpenRoads topics, like Terrains, but we don’t have a full OpenRoads class ready yet. And it’s likely that we won’t until closer to the end of the year. We’ll probably start releasing material for public consumption in the Fall, and it will continue from here on out until we’ve completed our material line up. Our plans are to initially create smaller booklets on the various topics, and then in the future, package them into a more complete volume if it makes sense. But we’ll make that final decision after we see how our smaller books are accepted.

I know this is a lot to digest, but here we are, more or less at the mercy of the software developers who drive our tools. All I can say is don’t make this particular move unprepared.

I hope this helps you understand what you’re up against, and if you need or want any additional clarification on anything I said above, just let me know. You know we exist to help folks like you address areas like this that are sometime outside of your wheelhouse.

Feel free to contact us as needed. We’re here for you.

Civilly yours,

- mark

I was reading the March / April 2018 issue of an industry magazine called Informed Infrastructure and felt compelled to respond to something on page 8, in the From the Editor piece, titled Old Habits Die Hard.

Here’s a link to the magazine website: https://informedinfrastructure.com/

Here’s a link to the digital online copy of that issue: http://read.informedinfrastructure.com/publication/?i=485588#{%22issue_id%22:485588,%22page%22:8}

My response was published in the May / June 2018 issue that can be found here: http://read.informedinfrastructure.com/publication/?i=499933#{%22issue_id%22:499933,%22page%22:10}

This is the contents of the From the Editor piece by Mark J. Scacco, P.E., (with my reply following after it):

I have a theory, and I wonder what you think about it. It has to do with ancient pyramids, spaceships, artificial intelligence, robots and self-driving cars. No, this doesn’t have anything to do with “ancient astronauts” or Chariots of the Gods; it’s a bit more mundane and a lot more serious.

The Other 1%

Without getting bogged down in the numbers, many studies have found that since the 1950s, manufacturing (which includes automobiles, aerospace and electronics/microchips, along with nearly everything else) has enjoyed a nearly 8% productivity increase, and the overall U.S. economy has seen increases of about 4%. In the same time period, the construction industry has increased by only 1% and has actually decreased since the mid 1990s. What’s going on here?

The Blame Game

There are a number of reasons frequently tossed about for why construction lags so far behind manufacturing. These include shortages in skilled labor and lack of adequate training; incomplete or inadequate designs resulting in rework, extras and delays; and an overall resistance to change or adopting new technologies. Although each is a valid reason—and discussions of them could and do fill many pages of journals and magazines—I want to use the next couple paragraphs looking at the last one: resistance to change.

Babies and Old Timers

The industries that experienced such dramatic increases in productivity all have existed for less than 200 years. In the long history of commerce and industry, cars, computers, rockets and robots are all babies, relatively new to society and civilization. Construction, however, stretches back nearly 200,000(!) years, with the earliest structures found in France dating back about 176,000 years. “Newer” construction such as Adam’s Calendar (also referred to as the “African Stonehenge”) is at least 75,000 years old, and the pyramids in Giza, Egypt, are 5,000 years old. Anatomically modern humans, Homo sapiens, arrived on the scene about 200,000 years ago and, based on the sites in France, began construction shortly thereafter.

Building things such as shelter is as natural as our drive for food and reproduction. Just look at kids: from their earliest years, they build forts out of anything they can find, and then crawl inside and eat snacks! Everyone—without any engineering schooling or a construction background—knows how to build a bridge: chop down a tree and lay it across whatever obstacle you need to traverse. Of course, these are very basic construction examples, but what basic airplanes or electrical circuits can nearly every human build as a child?

So here’s my theory: construction is so old, it’s in our DNA, making the industry’s habits very old and very difficult to break, resulting in the incredible resistance to change.

An Engineer, Not an Anthropologist

As an engineer, I’m licensed to do a lot of complicated tasks, but one of them is not to analyze culture, society and genetics. In other words, I’m not an anthropologist, and these are simply my musing on the topic. However, to solve the 1% productivity problem, we need different ways of looking at the issue, and I’d love to hear your thoughts. Please comment or drop me an email.

===================================

Hi Mark!

I receive the hard copy of your magazine and read your ‘From the Editor’ article a while back. As I was reading it I had some thoughts running through my head that prompted me to reply, albeit late. So, onto my thoughts:

Okay, I’ve read Chariots of the Gods (and many other similar books) and in fact, did my “graduate thesis” on the subject in 8th grade, so I think that’s a valid hypothesis that warrants further investigation. I would expand more on that here but I left my copy at my parents’ home in Pennsylvania and will have to get it first.

As to your statistics on productivity increases, I’ve never investigated those numbers so won’t comment on their validity, but I have heard similar statements and commentary by others.

Now, onto the meat of this. Personally, I think “lack of training”, “inadequate designs”, and “extras and delays” hits the productivity mark more squarely, but let’s take up this “resistance to change” item that you focused on.

Have you considered that your premise that ‘newer’ industries have experienced greater productivity increases than the ‘older’ construction industry actually points to the root answer of your “productivity” quandary? If something has been done for eons, successfully, why change? We have all heard “if it ain’t broke, don’t fix it.” So, you better give me a pretty darn good reason to change what I’m doing.

As you state, there seems to be an innate construction skill ingrained in us. But I disagree with your supposition that it’s the “hard to break old habits” that generate resistance. I believe our intelligence can overcome that (especially as engineers), and my experience has disproved the classical suggestion that you submitted for this resistance. And forget about the complexities of anthropology, just look at it logically …which is the only way to analyze man, a rational being.

Now, my suppositions include nothing about the potential for irrationality to rear its ugly head, and we all know that it does with some individuals, but you can’t form a premise with an assumption of total chaos and random behavior. So let’s assume that we can maintain our wits about us. With that said, I believe that ‘resistance’ is not inbred, but consciously determined based on one thing – added value. Added value as determined by the individual from where he stands (or sits).

So how do we look at this topic of “change” and “resistance”?

By finding the added value in anything that attempts to change what I’m doing. The yardstick is what I’m currently doing, and any ‘change’ is benchmarked against that. For example, should I move to the latest version of any software? The questions that need to be asked are “What value does it offer me?” and “Is any ‘added value’ worth the effort?”.

Why do people upgrade their phone? Their TV set? Their car? Early-adopters aside …it’s done because there is an added value. That value is more often than not, an ‘individually’ perceived value, not a societal one.

Let’s take Civil software for example. Just because something new hits the streets, does it automatically mean that everyone should dump their old software and immediately upgrade. Everyone needs to be asking themselves the question, “Why?”. This question requires a good, meaningful, applicable, honest, technically complete answer. Not a superficial, financially driven, mandate from someone who isn’t qualified to make that call (like is often done).

Resistance to change? Why would anyone keep changing their calculator every 3 months just because a new one came out? Every decision needs to be properly assessed and the positives as well as the negatives need to be cataloged. Then, and only then, can the true value be determined.

Resistance to change? I don’t think people are really resistant to change, they are resistant to poor, inappropriate, improper decisions that adversely affect their ability to get their jobs done.

Resistance to change? Expect resistance if you ram something down someone’s throat without consulting them, or providing proper training, while expecting them to just ‘make it work’.

Resistance to change? Show these ‘resistant’ individuals (or industries) something that makes sense (and prove the added value) and I’ll bet you’ll find the agreement, acceptance and adoption that’s desirable.

And lastly, as an engineer, surveyor, or construction practitioner, we can all benefit from a greater interpersonal understanding of society and the people that we are constantly engaged with on a day-to-day basis. And I believe that if we did, we would see those elusive productivity gains.

Civilly yours,

- Mark “Zen” Ditko

I saw a question on the Bentley Forum the other day where someone was asking how a complex Component / Template worked. Their post went something like this:

Just when I got InRoads SS3 under control I'm looking at OpenRoads Designer... Wow. My question is that we're using the delivered template library.

First let me say, “Welcome to my world …enter cautiously”.

The question is “do I know what I’m doing?” …Not when it comes to writing a blog, I’ll tell you that much. But these days I’m not necessarily one to run from new things either, so here it goes.

I found myself saying that “I’m old-school” quite a bit lately.

Is that good or bad?

I hadn’t really thought about it much until this moment. I think what makes Zen Engineering strong is that we ‘are’ old school in many ways, with ‘new school’ methods and objectives. Some things really do have to change with the times.

Excuse me for being too direct at times but this goes out to all the managerial dinosaurs; those stuck in the ‘old school’ ways; those wondering how to ‘force’ their staff to follow standards; all new college grads; those looking for advancement in this technologically driven world but are just generally confused about it; and to those simply wanting to be more productive but are unable.

To be successful in the survey, engineering, and construction business thirty years ago all it took were some ‘smarts’ and a good calculator. Those ‘smarts’ could have come from a good education, experience in the industry, or working closely with someone who had racked up a winning combination of either of those two elements.

Fast forward to present time.

Okay mom, I don’t suggest that you read this blog entry :)

I seem to be talking about this subject a lot these days so I figured that it would be a good topic for my blog.

Now where do I begin?

Some may believe this is a very trivial topic.

Some may say that it’s not really even an issue worthy of mention.

Some may not even be aware that this problem exists.

Some simply don’t care and therefore make it someone else’s problem.

Well, I’m here to say that this IS a problem. …and it’s simple math … Geometry actually.

Quotes

  • "Many of life’s failures are people who did not realize how close they were to success when they gave up."

    – Thomas Edison