Things you can do to prepare for Tool Adoption


One of the techniques I used to use when explaining Orbus Software’s iServer to a new user was to establish myself as an expert and trusted advisor in regards to tool adoption. It was usually a cheap, easy way to establish authority, simply by asking a few questions about tool rollout that seem obvious when you've seen it done dozens of times, but which can often blindside an organization that is implementing a tool for the first time. There are some decisions that always need to be made when rolling out a modeling tool.

Summary: when you’re planning to adopt a modeling tool, there are a few things that you can do to prepare. They’ll help you in the adoption, but they’ll also help you in the evaluation. They are: check what formats other tools might have to allow import or export of data, decide how you will treat legacy data, identify what skillsets you’ll need to acquire, identify the roles around the tool, decide what style guidelines you’ll adopt, and decide how your operating processes will change to use the tool.

I'm identifying import from, and exports to, other tools as the first question because in my experience it's often the area that seems the simplest, but turns out not to be. Most tools have some ability to import data, and to export data. All well and good... but in what format? XML, you say? Um, great, but how is the XML structured? Do you have a Schema (it can be surprising how often the answer is no). In practice, identifying what precise data is available, and more importantly, in what precise format. It can be a case of booking time with one single expert (from the vendor, or some guru within the IT department), who like most specialist SMEs is often extremely hard to get time from.

Given that import and export capabilities are often part of the pitch of a modeling tool, failing to get this information ahead of time leads to the following conversation:

Organization: Can you import from {other tool}?

Vendor 1: Sure, we can import from XML and Excel

Vendor 2: Sure we have an API.

Vendor 3: Sure we have a connector for {other tool} (and the vendor rep has no idea what that connector allows and how hard amending it would be).

And the problem with these three responses is that an estimate of costs without precise formats is going to be an educated guess. Any vendor representative who gives a firm estimate without an interface format is basically guessing – not a good recipe for precise project estimation.

So, import of data. But a related question is whether to import existing information. Prior to tool adoption most work will have been done in the classic EVP triad – Excel, Visio and Powerpoint. Recognizing this, most tools will import from Visio or Excel. The question is, is it even worth it? If you have an excellent diagram of which datastores are in which datacenters, but the diagram is 3 years out of date and 30% incorrect, the value of importing it and making it available becomes dubious.