Adopting a modeling tool is a project like any other; and like any project, you run into unforeseen problems. Having seen umpteen tool adoptions over a long period of time, I've come to notice that there are a few that happen again, and again, and again. So in the interests of helping future tool adoptees avoid them, here they are:
Summary: There are a number of classic problems that you can run into when rolling out a tool, all of which act to weaken the value of the tool - being aware of these issues ahead of time lets you take actions to mitigate them. The five most common are:
- Importing existing models that are too old to be useful
- Integrating to data sources with unreliable data
- Failure to consider objections regarding the handling of sensitive information
- Failure to set a policy on who will be required to adopt the standard tool implemented
- Failure to consider how operational processes will be affected
The first common mistake is importing existing models that are simply too old to be useful. It’s a natural reaction; “we’ve got a tool now, better start putting things in it.” - but to load in a datacenter diagram that is 5 years out of date, or an organizational chart where 30% of the people listed have left the company, is worse than useless. Would you expect to perform analysis on this data? I’m guessing that the answer is no.
A related mistake that I often see is to import outdated information from other sources. Most tools have some facility to bulk import data from external sources; an architecture tool might import from a CMDB for example. The issue exists when the CMDB is plain wrong.
It brings to mind the quote from the British TV series “Yes, Prime Minister”
Sir Humphrey: If local authorities don't send us statistics, Government figures will be a nonsense.
PM James Hacker: Why?
Sir Humphrey: They'll be incomplete.
PM James Hacker: Government figures are a nonsense, anyway.
Bernard: I think Sir Humphrey wants to ensure they're a complete nonsense.
So, while the impetus to import from other tools is a good one, it is important to check if the information is of a good enough quality to use in the first place.
A different area of tool adoption (particularly with modeling tools) that can often trip people up is with sensitive information. Common examples are that network specialists usually don’t want full details of their network exposed to everyone – but there can be others. For example, the police department of a transport organization objected to loading their process maps into a process management tool during a particular project, because they felt this compromised security.
The major issue with this objection is that if you allow a group to simply be exempt from using the tool, you’ve now established the precedent. It’s therefore worth exploring with vendors (before purchase), or the vendor (after purchase), the options for permissions-based restrictions to have an answer ready for those who object.
Just as some communities may object to visibility of their work, others may object to using a specific modeling standard. It’s the nature of modeling tools that you use a specific set of types. This is necessary for reporting; unless you have a standard set of types, it becomes impossible to pose questions such as ‘show me all applications that support processes in the Sales and Marketing function’. The very question implies that you track applications, processes and functions, and make a distinction between them. So, requiring teams to adopt a standard set of types is the price that you have to pay to get integrated analysis.
The last common way that tool implementers can end up tripping up when it comes to implementation is when they neglect to consider what operational processes might be affected by the tool (whether these processes are explicitly stated or unofficial). At worst, this can delay rollout of the tool itself while the organization works to get buying from the process owners. More often than not, failure to integrate the tool into operational processes risks making use of the tool an optional affair.