About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , customer experience , customer service , customer satisfaction
No Result Found
In my last article, I explored my personal discovery of internal customer experience and touched on how I got there. Part of that discovery was learning that assumptions (both my own and my internal customers’) can be tricky! Here’s how I handled them during a recent large project.
Today, routinely identifying and challenging my assumptions has proven to be one of my more powerful tools in customer experience. Although I wouldn’t recommend that anyone stake their results on assumptions, I believe it can be a good place to start if you have a plan to manage them.
My company was preparing a big-bang upgrade of operating system and local productivity applications along with a move to cloud storage. This was no small change, even for those of us comfortable “working with computers,” and I knew we had a challenge ahead of us to keep our customers productive and confident as they entered the new waters. I wanted them to feel like they’d jumped in, rather than having been thrown!
From experience and ticket review, I knew where my customers often struggled. I also knew that my end-users were a real mix: Gen Z to Boomers, corporate office executives to field laborers. The hardware they worked on was just as varied, with phones, tablets, and desktops found in offices, trailers, and trucks.
For my initial planning, I made a list of factors affecting my part of the project (people, job roles, location, hardware types, etc.). And then I got on the phone, and I got on a plane, and I tested my assumptions in the real world.
It’s a good thing I did. I knew I had a “corporate office” bias. But even when you’re aware of it, you can’t really know when it’s going to rear its head.
My company had multiple branch offices across the US and Canada, and while some offices worked in several of the company’s core disciplines, others were mainly focused on only one. This also played out on a project level, where larger projects contained multiple disciplines, and others did not.
My strategy for training was based on a “how you work today vs. how you will work tomorrow,” and the “today” included some assumptions about significant areas like document sharing, email usage, and how to connect to shared services. These pre-training meetings with managers and key user groups proved to be crucial as they allowed me to present an overview and then listen to what each branch or user groups cared about and how they really were working.
In my case, I had underestimated the extent to which teams worked differently from each other, not only in a specific discipline, but across the different branches as well. For example, I had assumed that people would want to learn more about document sharing from a collaborative editing perspective. I wasn’t wholly wrong. But some groups needed a process-focus more than a technical how-to, because their clients had specific needs for document management, while another wanted only the how-to because they only shared internally and weren’t concerned about an overarching process.
I had also underestimated the project’s understanding of the impact of network connectivity in the other offices and project sites. I had identified connectivity as a problem area based on our infrastructure capacity map, of course, but also our ticket history of “network is slow” or “connection keeps dropping.” However, when I went to these offices and sites, I saw the discrepancy between the corporate office where IT was working from and some of the other locations, which looked satisfactory on paper but were not in reality.
This realization impacted the project in a few ways, but mainly because we had to rethink how we delivered the updates to the computers. In fact, we ended up with three different delivery strategies. We also changed some of our training content to highlight workarounds to these challenges, like hot spotting their devices from a job site in order to download the latest set of drawings when the physical network was dropping.
This exploratory phase not only revealed to me where I was off-track, but I learned a lot about what my customers assumed about our services and our direction. Whether a formal meeting, or conversations over coffee or dinner, these direct interactions with the teams were paramount to my designing the overall experience I wanted them to have. And I’ll be honest…it taught me I hadn’t fully appreciated how their assumptions might affect the project. I discovered preconceptions about “Corporate” and IT being slow to change, which highlighted that we needed to communicate more frequently about “works-in-progress,” instead of presenting a “finished” solution. We discovered cases where people received a solution that “didn’t work,” so why bother asking again? This let us get specific examples from the groups. We discovered that, in some cases, it was true that we hadn’t interpreted their needs correctly (more learning about the “finished solution” again!), and this had eroded some trust between branches and IT.
On the flip side, we also found opportunity to educate where their assumptions were incorrect. During one of our first meetings a group was convinced that “The network is always slow, so it will still take forever to save a document stored in the cloud.” But, this assumption was based on the previous infrastructure where all apps were accessed via the network and terminal services. Once we’d explained how the new environment took advantage of local applications and took load off of their network, we could move forward again and look at how it applied to their branch directly.
If we hadn’t identified these assumptions, the project would surely have had mediocre results at best, and we would have lost staff buy-in to the changes. Armed with reality from those conversations, we shifted the content of the training from location to location, aligning with our customer’s requirements for ideas, innovation, and education.
Here are some of the lessons I learned along the way:
These checks provide the opportunity to uncover more assumptions or realities that are impacting your plan, and you’ll find you can head back to your map to address the detour, before something becomes a costly pothole. Chances are you’ll improve the relationship between IT, your stakeholders, and your customers along the way, and that is priceless.
Kristin Jones is a passionate customer support advocate with a focus on people and process, and has been leading IT teams with delight for over a decade. A lifelong learner who seeks to inspire others with fresh ideas, she is an active member of the HDI community and holds certifications in ITIL v3., HDI Support Center Manager and KCS Foundations. She strives to end each day having smiled more than frowned and having helped someone (or something!) work better. Follow Kristin on Twitter @kitonjones.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: email@example.com W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
Apollo 13 Insignia image by 'NASA Johnson' (copyright-free) June 2017 via https://www.hq.nasa.gov/alsj/a13/images13.html
WEB DEVELOPMENT PARTNER