[Work-in-Progress – Updates to Come] 

After nearly a year’s worth of effort, I’m finally about to begin a new enterprise application implementation for my department. The general solution category is an “Integrated Workplace Management System” (IWMS). In short, IWMS are an assemblage of generalized and specific applications, processes, workflows, and communications components to centralize an area’s work, improve data quality, and to support management (e.g., generate metrics). For example, in the IT-sphere these are referred to as “Information Technology Service Management” (ITSM) solutions. In an ITSM you commonly provide a ticketing system to track events (e.g., requests and issues), time tracking (e.g., work hours and time spent on tickets), knowledge bases (e.g., help articles, systems documentation, etc.), and service catalogs (i.e., menu of common services and needs). 

While I’ve done a number of IWMS/ITSM-type implementations over the years, as well as even more enterprise application projects, I’m looking out at the rocky terrain ahead with a feeling of knowing trepidation. In my own experience leading successful projects and being hamstrung on others, there are some essential preparations to take and challenges to prepare for:

• Ownership & Buy-In 
• Communication 
• Configuration 

Configuration  

How do you define something as properly configured? A “by-the-number” approach would look at the common or accepted practice. A “best practices” methodology will point to what industry research says is the optimal approach. In my opinion, you need to take an iterative design approach to configuration. 

You build out your system as best you can. First, focused on covering the essential and unique aspects of your organization – these are the quirks, annoyances, and suboptimal setups that are necessitated by other aspects of the operations. Second, focusing on the standard procedures that need to be in-place for your regular day-to-day work. Third, you build in changes, based on what the new solution can do or supports to improve your business. Finally, after you’ve had experience working with these three things, you iterate your configuration based on what you’ve learned over the past six, nine, and twelve months. I’ll use my first major ITSM implementation as an example.

The key components of the platform we wanted at launch were a well-defined ticketing system, a comprehensive service catalog, a foundational knowledge base, and time tracking. Leadership wanted to see better organized tickets, a push for easier self-service for our users, and the ability to generate quality metrics about our work (i.e., where was time spent, on what, for who, etc.).  

Myself and leadership discussed how granular we wanted the configuration to be, with leadership pushing the idea that the more detailed we define our metrics, the better our insights will be. You have a Helpdesk Technician taking calls and fixing issues. Someone calls in with a problem with Microsoft Outlook, did we want the system to record that as “Application Support” or more detailed as “Microsoft Office Support”? You may be thinking that’s silly to focus that narrowly, but consider the true complexity of a modern medium and larger organization, where you have all different generations of computers, types of devices, software, services, and so on. Too broad, recording just “Application Support” and you miss out on trends or problems with a specific device, software, or service. Too detailed, and you can strain your people trying to properly record the details, while also creating data that is too refined to be meaningful. This is why you need to iterate your configurations.

With that ITSM, we got some things right and some things wrong, but we didn’t always know precisely which. When myself and the head of our helpdesk went through our ticket types (the categories for the types of work being performed), the helpdesk said there were “clearly” too many, that we were probably only using half of them. So, I pulled the data, generated reports, and went over the facts with the manager. Lo and behold, we discovered that over the course of a year, we actually used every single type multiple times, even after accounting for errors (e.g., a technician marking a ticket as type A when it’s type B). However, conversely, we though our Service Catalog was excellently defined, but it turned out that we had too many offerings a number of which were rarely being used either because users could not find them, or because they didn’t know the distinction IT had drawn between certain offerings.

The keys to improving your configuration is the willingness, time, and integrity to identify the things that work, things that don’t, and determining where improvements can be made. In the case of my previous ITSM project, we did cut back on some of the ticket types, but not nearly as many as we expected, but we also briefed the technicians on what we found, so they would know we didn’t brush aside their feelings about there being too many “unused” choices. We also simplified our Service Catalog and re-trained both our technicians and key users, to learn how to better use and navigate the catalog.

Communication 

Share, communicate, and be reasonably open. By sharing, I mean give people a chance to be involved or at least “see” what’s going on with the project. If you can, create a semi-open-door policy to receive questions, even if no one comes to ask, making it clear you’re willing to be open can foster a positive view of the project, and, more importantly, help avoid creating negative views.

Communicate with the users and leadership. This is a trickier step, despite nearly everyone saying at some point in an interview how they’re a “good communicator,” you need to figure out the line of how much to share without causing fatigue or inviting too critical eyes. Fatigue is from over or inefficiently communicating, sending out too much information that is not meaningful to the people receiving it – think of the various newsletters that you receive that you never take a second glance at, beyond marking them as read or deleting them. Also avoid being “too honest” or “too open,” where you share all the problems you’re having on a project, with the vendor, etc. In IT especially, people forget that we often deal with new systems, specialized solutions, and changing devices on a regular basis. Internally, we know that there’s always a learning curve, but not everyone understand this. On more than on occasion I’ve seen colleagues catch flak for “not knowing” or “struggling” with something reasonable, because they overshared about common issues. Among their peers, we knew they were having normal difficulties and were handling things well, but to people outside IT, some viewed this as lacking ability or competency.

I remember a former director receiving an angry call from a VP complaining about how our help desk manager was worryingly incompetent because they didn’t know how to fix a “simple problem.” The manager was asked to do some support for a senior leadership office and while there, asked for a moment to pull up a device manual on his phone, which the VP took as gross incompetence. In reality, the device had to be reset using a special sequence of button presses and the manager simply had to check if it was buttons A,B, and C on this model or B,C, and D. The manager knew what the issue was, knew what he needed to do to fix it, but simply did not remember the arcane process by which to do it.

Ownership & Buy-In 

These are terms so overused and abused that it’s not unusual for someone to view them as pure lip service. You want users to see it as “their” solution, not “the” solution. To achieve this, you must ensure that users feel that they have agency in the selection and configuration, that their voice is heard. This does not mean that you need to cater to every one of their wants and whims, but that they believe you listen and have reasonable explanations for why some asks were met and others were not.

The easiest way to achieve this is the obvious one: Solicit feedback and actually listen. 

This can lead into a whole other article on the feedback process, but for now we’ll keep it simple. If you have a small team or set of stakeholders, then requesting their input should be straightforward. However, for larger groups ask them to contribute their thoughts, ideas, needs, wants, but do so in a structured and bounded way. When you ask for feedback, be specific about what you’re looking for, but also give them a simple open-ended option in case you missed something. For example, a simple survey to ask about features they want in a new solution, with a final “Additional Feedback” or “Comments” prompt at the end. This ensures you collect the input you need for your project, but also gives the users a chance to provide input that they see as pressing. 

If you have a larger group, another method is to work with knowledge leadership in their areas to help select representatives. Users that know the operations, are open to change, and are open to providing feedback with you. Conversely, avoid picking those at either end of the employee spectrum, the most senior and most junior. The most senior employees, while they may have the most knowledge, are more likely to be change adverse and fixed on older processes. The most junior employees will likely not have enough of a sense of the organization or processes to know what’s important versus irrelevant.  

[…]