Creating a successful and efficient IT service management (ITSM) model is key to any modern business.
ITSM began with the Information Technology Infrastructure Library (ITIL), which provides best practice guidance and an extensive set of processes and policies for improving IT service delivery and customer satisfaction.
However, there have been many advances in ITSM since the emergence of ITIL. Ivanti is one of the leading ITSM solutions that has been popular not just in recent years, but for almost 3 decades. Bendata brought us HEAT (Helpdesk Expert Automation Tool) with it’s Call Logging application for DOS and then HEAT for Windows. Later on the company went through name changes from Bendata to HEAT Software, and finally Frontrange Solutions (FRS), plus there was a spin-off company, Cherwell, before finally both were acquired by Ivanti, bringing us Ivanti Neurons for ITSM (formerly Ivanti Service Manager).
Ivanti integrates multiple best-in-class tools into a single unified platform and allows organizations to customize the tools to meet their specific business needs. With Ivanti, organizations can reduce their total cost of ownership, simplify IT service management processes, and reduce manual effort. This platform also helps organizations better manage their IT assets and more efficiently manage their IT service delivery processes. Ivanti also provides a secure, compliant environment for storing sensitive data and provides built-in reporting tools to easily track IT performance goals.
In summary, Ivanti is an innovative ITSM solution that can help organizations to improve the quality of their IT services, reduce operational costs, and maximize operational efficiency. It is the perfect solution for organizations looking to optimized IT service delivery and ensure customer satisfaction.
Next time you’re considering an Ivanti Consultant or Developer, it’s helpful to remember the history as there are too many junior Ivanti Developers/Consultants/Project Managers that give themselves the title “senior” with only a few years experience and only a few implementations. Even 15+ year veterans are often junior. How do I know this? After 100+ Ivanti Implementations and consulting and developing for over 27+ years with Ivanti/Frontrange/HEAT around the world, I have encountered too many “senior” consultants/developers that just don’t measure up to what you’d expect. So if you’re serious about getting the most out of your Ivanti Implementations be sure to talk to me first.
Q: If needed are we able to create a separate instance for AP Ticketing?
So by “Ticketing” the Service Desk Manager is referring to incident management and service requests that Accounts Payable is currently handling with eMail and want to replace with Ivanti Service Manager which is already used by their IT Service Desk.
Funny enough I had a similar question from a client in the UK that wants to onboard other divisions and groups using email and other systems in Asia.
A. You could but a better way would be to configure your existing tenant (instance) with a new role specific for AP with record level access rights for AP to have access to only their “tickets” and no access to IT and vice versa. You can also customize the Self Service portal with “extended roles” so that Vendors and AP Customers have a Self Service portal separate from the IT Self Service portal.
In other words, if you have a big enough property and house, then why buy another property and house when you can turn your house into a duplex or multi-family dwelling by adding entrances, dividing walls, and restricting access with joining doors and common areas. Think HR, HSE, Supply Chain, Sales, Marketing, etc.
With the release of Ivanti Neurons for ITSM 2022.1 the Self Service Home Page now has more configuration options for the widgets.
The latest solution Ivanti clients are now re-evaluating the homepage configuration, including the two buttons for “Report an Incident” and “Request an Item”
Home Page buttons for Report an incident and Make a request
This may seem like a very simple solution but it is actually a huge improvement for end users and analysts. Differentiating between Incidents and Service Requests is simple for seasoned consultants however end users struggle with this concept (and so do some analysts). After all, to an end users (the customer), they just want to fill out a “ticket”.
That’s exactly what you can do now, with the latest solution by Ivanti to allow home page configuration.
You can now combine the two buttons into one button and call it “Service Catalog” for example.
That’s exactly what clients on the Ivanti Service Manager 2022.1 release in Australia, UK, and Europe have started doing. If you’re in Canada, the US, or South America, then you’ll need to wait until your scheduled upgrade. Check the latest Ivanti System notifications here.
Ivanti Clients are also choosing user-friendly Category/Subcategories such as “I have an issue with…” and “I need…” to differentiate between “Report an Incident” and “Request Offering” Templates. Client culture dictates the exact wording that users can relate to and easily pick the correct template, whether Incident or Service Request.
In addition to the above, the latest solutions for Self Service are improved load time, custom icons, improved widget controls.
ARE YOU leveraging the Latest Solutions for YOUR IVANTI IMPLEMENTATION?
I have run into an interesting scenario and discussion with a Service Owner that insists that the SLA clock should Run when Waiting for Approval, more specifically waiting for the requester’s manager’s approval.
So in other words, a SR is submitted, waiting for approval, more specifically for the customer’s manager, and the clock is running for the service request, counting towards completion. If it takes the manager 5 days to approve, the time waiting is considered part of the Resolution Time / Compliance metric.
This is a first for me. The Service Desk Industry standard (norm) that I’ve always encountered is to pause the Service Request clock when Waiting for Approval, similar to how Waiting for Customer behaves, as typically any events outside of the Service Request owning team are paused, when the “wait” is for an external event/action, Versus an internal team action/approval/event with a “Waiting for Internal Team” status or similar status.
The argument made was that the Service Level Agreement Resolution Time and Contract with the End User, should be the total time from Submission to Completion, and using OLAs at the Task Level to measure the Team’s Resolution Time and Compliance.
What are your thoughts/experiences?
Here is what an Ivanti Business Partner had to say in the Ivanti Forums:
If it’s the customer’s manager i,e, someone external to the business then controlling the approval becomes harder and 2 weeks is a really long window for approval on a new mailbox. I would flag that for discussion with my customer to see if there are alternative ways to reduce the approval time. Also if it’s an external approval I would pause the clock as you can only measure and be targeted on the elements you control
It’s just as important to define where an SLA does not apply as where it does apply. Your SLA should define any usual and unusual situations that will hinder or prevent IT service processing.
Some SLA exceptions might include:
New users will be added to the system within one day of receipt of a completed new user form, provided management has approved adding the user. It will not be considered a service level miss if a new user request has been received but management is slow in approving the new user.
I started watching Dragons’ Den in Canada and then the US version of Shark Tank. When I ran out of episodes to watch I tuned in to Dragons’ Den UK (The Original) as well as the Shark Tank Australia Spin Off. Another German Spin Off that I tend to watch is “Die Höhle der Löwen” (The Lions’ Den)
What does all this have to do with Ivanti, HEAT, and ITSM? More than you think!
When it comes to proper business analysis and requirements gathering, key is asking the right questions (eliciting requirements), focusing on the topic at hand (Scope), targeting the audience (Decision Maker, Subject Matter Experts), laying down the rules of the Den, and setting expectations. (Project Management).
All too often businesses struggle in the den, whether it’s their evaluation, skill set, lack of business planning, thinking too big (unrealistic expectations) or too small (lack of vision or saleability).
The same applies to Ivanti HEAT Neurons ITSM Implementations. All too often:
Developers lack consulting experience, and vice versa, Consultants lack development experience
Implementation plans are cookie cutter, blue sky, or virtually non-existent
Business requirements have more gaps than solutions
Technical requirements are flawed
Architecture and Solution Design are afterthought
Best Practices are a foreign word
Business Process Documentation is non-existent
Training is old school and lacks a modern approach
In Summary, I highly recommend you watch a few episodes of Dragons’ Den UK, Canada, and Shark Tank US & Australia, and think about how you can apply the questioning and process of the format to your Ivanti HEAT Neurons Implementation. Better yet. Find yourself a Dragon 😉 and ask yourself…
ARE YOU GETTING THE MOST OUT OF YOUR IVANTI HEAT ITSM IMPLEMENTATION?
You are NOT. Not until you talk to me. Guaranteed!
I started watching Dragons' Den in Canada and then the US version of Shark Tank. When I ran out of episodes to watch I tuned in to Dragons' Den UK (The Original) as well as the Shark Tank Australia Spin Off. Another German Spin Off that I tend to watch is "Die Höhle der Löwen" (The Lions' Den)
What does all this have to do with Ivanti, HEAT, and ITSM? More than you think!
blog.a19consulting.com
Over the last 25 years I have seen a lot of changes for Ivanti HEAT ITSM. One change is Reporting.
Back in the HEAT for Windows and early HEAT ITSM days, Crystal Reports was king. In 2014, HEAT switched to Microsoft SSRS Reports with its ITSM platform. That was 7 years ago and SSRS hasn’t changed much. Back in 2014, SSRS was a great tool, but the downside has been and continues to be that it is third-party (Microsoft) product with the designer tooldesktop-based requiring hours and days of software development(translation: you need a SRRS Developer).
But before I digress further (Edit: see my PS Note!!)
The Biggest Reporting Mistake that Ivanti HEAT Consultants, business partners, and Customers make is…
Using Reports! Dashboard Reporting is far superior and optimal for every-day on-demand analytics & reporting. Especially in today’s fast-paced high-tech environments. Traditional old school (SSRS) Reports are a thing of the past. Who really shows up to a meeting nowadays with a hardcopy report, or a softcopy for that matter! If you know a HEAT customer that does, then please contact me!!
The world has changed, and so has Reporting!
Software is intuitive and users want less and less clicks. The industry is shifting left and so is Reporting. A shift-left towards Interactive On-Demand Dashboard Reporting that you can bring up in a Team, Managerial, or Executive Meeting to slice-and-dice the data, and drill right down to the ticket level, not days after submitting a development change request butlive in the meeting!
Traditional (SSRS) Reports An eyesore!!!
Why Dashboards? Dashboards can be configured easily and quickly, for various user-roles (Executive, Manager, Analyst, etc.), based on Saved Searches, with Filters, Drill-Downs, and best of all with an Agile Approach and Shift-Left Methodology in mind. Enabling the customer (analyst, manager) to report against the KPIs that are top-of-mind now and best of all without the need for a developer, additional software, or long development cycles.
Dashboards are quick and simple configurations that take from just a few minutes to a couple hours for a complex dashboard part. Best of all dashboards are native to Ivanti!
But wait there is more…
Rapid Reports entered the stage in 2017 and is a hybrid of reports and dashboards in that Rapid Reports are native to Ivanti, no additional software is required, are somewhat easy to configure, based on Saved Searches, and ideal for traditional detailed reporting needs & ticket details (List & Form View).
What about Xtraction?
If anyone recommends Xtraction to you. RUN!!! Analytic Metrics are far better and mature compared to the buggy and costly Xtractionadd-on, a LANDesk product, that just like (SSRS) Reporting will cost you time, money, and effort, and leave you disappointed.
In Summary, as much as I like billable consulting time, I would NEVER recommend report development over dashboards.
Not convinced? Here is a comparison. Before you waste another cent on HEAT Reporting that is guaranteed to disappoint, be sure to contact me!
Ivanti HEAT Reporting 101
PS: Some history for Crystal Reports (CRW) was originally developed for the Accounting Software package Accpac. Sound familiar? Accpac was acquired from Computer Associates in 2004 by Sage and as of 2012 Accpac is better known as Sage 300 ERP. In any event, the reporting tool became so popular that it was launched as a separate product. Personally I miss the CRW with HEAT.
PPS: Rapid Reports was introduced to Ivanti Service Manager in 2017, adding native reporting capabilities, just around that time the discussion of phasing out SSRS Reports started. No verdict on roadmap yet but that’s okay, there are much better solutions than (SSRS) Reports!
Also with the Cherwell acquisition there is a high likelihood that Cherwell’s Report Writer will be considered as a future replacement.
With Ivanti’s new momentum and roadmap commitment to making searches more “google-like” for 2022, and Cherwell’s Acquisition in early 2021 we are bound to see some exciting dashboard reporting improvements! And hopefully finally SSRS Reports will be replaced!!
On-Premise (Self hosted) and Cloud Ivanti Neurons, Ivanti Service Manager (ITSM), and Ivanti Asset Manager (ITAM) customers have 3 tenants (environments) that I like to call the “Holy Trinity”.
STG – Stage Environment for Development and System Testing by the Ivanti Consultant / Administrator only
UAT – User Acceptance Testing Environment for End User validation of business requirements by the UAT Test Team
PROD – Production Environment
Any configuration changes to Ivanti Neurons ITSM/ITAM should always follow the SDLC (System Development Life Cycle), that is development & system testing in Stage, then push to UAT for End User Acceptance Testing, and finally upon UAT Sign-Off push the changes to PRODUCTION.
Ivanti HEAT ISM Podcastcovers popular Ivanti Service Manager (HEAT ISM), SDLC, ITSM, ITAM, and ESM Topics, latest solutions, best practices, and is available on Anchor, Spotify, Google Podcasts, Apple iTunes, Breaker Audio, Castbox, Pocket Casts, Radio Public, Listen Notes, and of course via RSS Feed
your Ivanti Podcast Host
LONDON – April 27, 2021 – PRLog — “Podcasts are a great medium to share information. Podcasts are quick and easy to create, powerful, and also convenient to listen to on the morning commute, lunch break, or while travelling. Plus you can download Podcasts for offline listening.
Personally I like to download a few hours worth of Podcasts whenever I’m travelling or stuck somewhere and want a break from reading or watching videos.
I decided to create the Ivanti HEAT ISM Podcast as an extension to my Ivanti HEAT ITSM Blog as podcasts are more powerful than a blog entry and allow me to quickly share relevant Ivanti HEAT ISM Information,” says Gregor Anton, a former Kifinti Solutions Consultant.
Gregor is a unique and distinctive authority in the Enterprise Service Management space with his consulting and development experience and extensive insight to best practices going back to 1996 with the HEAT and now Ivanti Service Manager (ISM) and Ivanti Asset Manager (IAM) products.
Providing HEAT ITSM Best Practices and now Ivanti Best Practices, with his tried, tested, and true implementations, and upgrades, Gregor now focuses on his company, a19 Consulting, his a19 Ivanti Best Practices System, a19 Ivanti Mobile Applications (Android, iOS), Ivanti ITSM Blog, and now Ivanti HEAT ISM Podcast.
Gregor has been developing, streamlining, and implementing best practices and latest solutions for fortune 500 companies and Frontrange Business Partners (Change Control, Avante Solutions, Kifinti Solutions) and Ivanti Business Partners (Kifinti Solutions, DDS IT), worldwide. The testimonials speak for themselves.
The ITxM Space (ITSM, IT Service Management, ITAM, IT Asset Management) has never been more exciting, as is the transformation to ESM (Enterprise Service Management).
Are you getting the most out of your Ivanti Implementation? You are NOT. GUARANTEED. Not until you contact a19 Consulting to take your Ivanti Implementation to the next level!
The UAT Test Scripts are owned by the Customer, this is a best practice as the intended use for the UAT Test Scripts is to validate business requirements, which should be aligned to the customer’s operating procedures. The consultant is external and does not own the business process, operating procedures, or business requirements.
The HEAT Consultant owns the Solution DesignDocumentation and System Test Scripts.
Keep in mind that the UAT Test Scripts are not training guides to the system, but rather steps to validate the business requirements by the owning team. It is up to the owners of the scripts, to maintain the scripts and word the steps in a way that is meaningful to their users.
Are UAT Test Scripts considered Training Material? No. UAT Test Scripts could form a basis for Training Material, however Software has come a long way and the old ways of creating extensive training materials with step by step instructions and days of classroom training are in the past. Web applications nowadays are intuitive and require very little training. Albeit there is always a learning curve for any new application. If more detailed training materials are needed, over and above the training videos and workshop recordings provided by the HEAT Consultant, then a best practice is to have the customer’s training lead or knowledge manager to work with the consultant to tailor customer specific training materials.
Going back to the Analogy used in my blog post “Common UAT Pitfalls“, that of test-driving a car. You as the customer are ultimately responsible for determining the best vehicle make, type, and test driving (UAT Testing) it with your set of criteria. You never want to rely on the, potentially biased, dealership (Consultancy) to tell you what to test-drive. The dealership may give you some tips as to what road to use, just as the HEAT Consultant provides you with some sample UAT Test Scripts, but ultimately the customer is the decision maker and responsible for making the purchases and test-driving before you sign on the dotted line. So be sure to take the system for more than just 1 test-drive and test thoroughly with all conditions and criteria you require.
User Acceptance Testing (UAT) is where some Ivanti HEAT ISM Projects tends to fall apart. Today I will cover the most common UAT Pitfalls, recommendations, and best practices to put your Ivanti HEAT Project back on track!
Thank you to Test Lodge for allowing us to use their Image on Slide 3
Perspective
First and foremost you want to do a review of where the HEAT Implementation Project is at. The typical implementation milestones such as Scope of Work, Requirements Gathering, Solution Design, Prototype, and Business Requirements Sign-Off and/or Prototype Sign-Off have been met. That alone should give the customer confidence. And if it doesn’t, then now is a good time to re-iterate all the successes and milestones met.
Drawing from and relating to previous implementations at the same customer site also gives perspective, for example, if several UAT Test Teams have completed their UAT Test Scripts within 5 days and one team is struggling and taking weeks on in, then that is worth sharing to the struggling team and having other UAT Teams share their experiences and successes.
Try to use analogies wherever possible to explain and clarify where things are at. I like using the analogy of purchasing a car. The customer has requirements, such as family of 4, active life style, living in a 4 season climate, with a medium size budget. The UAT Test Scripts are the test drive. The family is the UAT Team. The consultant wears hats of the sales person and mechanic. Ultimately the family needs to go for a test drive , mom or dad are the ultimate decision makers and lead (UAT Lead) the family, perhaps with their oldest child (the UAT Lead), and all aspects of the requirements are discussed with the sales person and perhaps the mechanic (consultant). The sales person (Consultant) gives some advice on what route to take (sample UAT Test Scripts), and helpful advice as to how the car handles and what features the car has. Ultimately though the Customer needs to test drive the vehicle. Get in, familiarize yourself with the control, adjust the mirrors, seat, and so on. Not unlike familiarizing yourself with the new HEAT System and/or features. And then you take the vehicle for a spin, on the highway, on a city road, on rough terrain, in a parking lot to practice emergency braking, parallel parking, check the trunk, storage space, and all aspects of the day-to-day use of the vehicle (the UAT Test Scripts) and then comes back to the Salesperson with questions. It is very seldom that after carefully studying the market and available vehicles that the customer will come back saying the car is undriveable. So why is it that some User Acceptance Testing sessions go haywire? Keep Reading!
Not having UAT Test Scripts This by far is the biggest issue that can de-rail HEAT Projects. Validation of Business Requirements is essential, as is a proper UAT Test Plan. UAT Test Scripts are a must have to achieve Implementation Success! Who owns the UAT Test Scripts? The customer. The consultant owns the System Test Scripts and Solution Design. Business Processes, Standard Operating Procedures, Business Requirements, and validation of business requirements (UAT) are owned by the customer. Hence that’s why the consultant does not own the test scripts. Simply put, if you are purchasing a car, you typically have a checklist of requirements that you came up with, not the sales person. You don’t walk unprepared into a car dealership and then sign-off after reading the pamphlet. Do your due diligence!
Not following UAT Test Scripts Having UAT Test Scripts is a step in the right direction, however execution is key. UAT scripts must be followed to ensure you’re validating business requirements, and the UAT Lead must work closely with the UAT Test team to ensure team members understand what is expected and asking them why they aren’t following a proven process? When you walk into the car dealership, you don’t just start up the car and say ok I’ll take it. You go for a test drive.
Not following the UAT Support Structure As with any process or procedure, it is important to understand the support structure. The UAT Team Members must know who to turn to when there are questions or issues. The UAT Lead is responsible for coordinating UAT Test Scripts with the Team and ensuring Team Members know what is expected. In the event of questions, the UAT Lead should channel that question to the correct individual, if the UAT lead is unable to answer. Note that T.ogether E.veryone A.chieves M.ore, so be sure to have regular UAT Team Meetings where the UAT Team Members can review their finding s and ask for support (HEAT How-To, Procedural, etc) amongst the TEAM and with the UAT Lead and getting direction from the Decision Maker.
When you purchase a car as a family, then everyone gets a chance to participate in the test-drive, unless of course the kids are toddlers, but even then you need to include them in the test-drive, and strap them into the baby-seat to see if it is up to your requirements. So when family members identify an issue, it goes to the parent. Ultimately it’s the parents that sign off, make and own the decision.
No Collaboration Some UAT Testers tend to work in silos, creating a list of all the problems the find whereas the best practice is to encourage collaboration, as per the above support structure, and emphasize solutions, not problems.
If your team insists of creating a separate list of problems in outdated tools such as Word, Excel, Notepad, or handwritten, then it’s time to re-emphasize the importance of collaboration and discussing the issues at the next UAT Team Meeting rather than letting the frustrating build up.
When the family members decide to raise problems at every turn of the test-drive, then it’s time to have a family meeting and address the concerns. Is it really a problem with the vehicle? Is there something else going on? Is there some confusion around an aspect of the vehicle?
No Internal Meetings One of the best practices for UAT is to ensure you have regular standup UAT meetings, daily at first, until you have momentum and are able to move to weekly. These meetings are essential for collaboration and ensuring everyone is working together to find solutions, not problems. Not unlike family meetings, the parents need to be on the same page and the family deserves to know what’s going on and have some input on the decision and test drive results.
Learning Curve Any new software product or major feature has a learning curve. HEAT is no different. Moving from Excel to HEAT ISM, even moving from HEAT Classic to HEAT ISM has a learning curve, as do major functionality enhancements to HEAT. Without the support structure, collaboration, internal meetings, that that learning curve can be detrimental. It is important that any issues, no matter how big or small or channeled to the UAT Lead and/or Training Lead. If needed, the UAT/Training Lead should make a list of questions for the HEAT Consultant so that areas requiring assistance are addressed. Tip: This is where the a19 UAT Test Scripts Module comes in, by entering Comments for the consultant.
When you’re test-driving a vehicle, there is a leaning curve too, so what do you do, first you do a visual inspection around the car, then inside inspection, check the side mirrors, rear view mirror, familiarize yourself with the control, adjust the seat, and then get familiar with how the car handles. Just like with any new HEAT System or new Ivanti Service/Asset Manager features. It’s quite intuitive. Of course unless you’ve never driven a car or never even used a PC or Google. Then the learning curve will be harder and you need some basic training.
Terminology When implementing a new system, there often is new terminology or a change in terminology, be it technical or business related. You’ve made it this far, so any new terminology has without a doubt been covered in the many workshops, design sessions, prototype reviews, and at sign-off.
Any questions about terminology should be logged by the UAT Lead, reviewed with the Decision Maker, and if needed, reviewed with the HEAT ISM Consultant. Often it’s just simple changes in terminology, like gas tank or fuel tank. Trunk or boot of the car. If you haven’t heard one term before well then you don’t raise that as a flag and stop driving the car and say it’s unusable. You just ask for clarification and keep on plugging away. It’s not the end of the world, but if you’re confused then raise your hand and talk to the UAT Lead.
Resistance to Change Change is inevitable. The only constant is change. Yet it’s human instinct to resist change. Change needs to be enforced by the Decision Maker and supported by the UAT Lead. Sometimes the best answer is to re-emphasize “the new way of doing things” and gradually over the time, users will adapt. Like when you purchase an SUV because it fits all the business requirements but many family members really had their heart set on a Sports Car or family members were used to the old gas guzzling family car that had lots of good memories, was no longer economical and the family had outgrown.
Not following or understanding business process/procedure The key to remember is that the Business drives Technology, and not the other way around. Focus needs to be on the business requirements and operating procedures. Be sure to seek guidance from the Decision Maker if any business operating procedures are unclear. When you’re test driving a car, then you test various aspects of your day-to-day use of the car. Highway driving, city driving, off-road, parking, etc. Everyone on the UAT Test Team (participants) should be well acquainted with their role. New drivers will need more help than others.
Not understanding the UAT Test Script Some UAT Testers might find UAT Test Scripts hard to follow. Remember these scripts are built by the decision maker and/or UAT Lead, so be sure to raise any questions and make note of any improvements to the UAT Test Scripts. UAT Test Scripts aren’t written in stone and can be updated as needed. Some UAT Test Scripts need no explanation at all, while others may require explanation of a standard operating procedure, steps to take, and input date. If you take a car for a test drive and milli-vanilli decide to do emergency braking on the highway, well that’s going to shock and confuse everyone. So make sure you are clear on what and why you’re testing.
Not having UAT Test Data While you may get away with using milli-vanilli data (arbitrary data), the best practice is to always use real data and examples from your existing system, whether that system is a sophisticated computer system, excel, or hand written artifacts. You will want to have real life data available that accurately reflects the type of input the tester will be using in day-to-day operations. Simple put, if you’re replacing your Helpdesk Ticket System, use ticket data. If you’re replacing sales order, use sample sales orders. Similar to regression testing, put your old system on the left hand side and the new system on the right hand side and then go through the motions in your old system and replicate in the new system. When you’re test-driving a car, your test data is your current way of doing things, plus some artifacts such as the oversized golf clubs or family bikes or skis that need you need to make sure fit.
Focusing on nice-to-haves versus MUST-HAVES The key intention of UAT is to validate business requirements (must-have-requirements), not to minimize the number of clicks, or nit-pick UI Design. There is always room for UI Improvement (nice-to-have requests) and that time is after UAT is complete and business requirements have been signed off. This tends to be where some UAT Testers get stuck, focusing on the window dressing instead of the architecture and foundation. When you purchase a car, the accessories are just that. Sure the super expensive surround sound is nice, but is it needed? Are the fuzzy dice, bumper stickers, upgraded paint job, and fancy wheel covers really imperative when conducting road test?
Training Material Keep in mind that the UAT Test Scripts are not training guides to the system, but rather steps to validate the business requirements by the owning team. It is up to the owners of the scripts, to maintain the scripts and word the steps in a way that is meaningful to their users.
Software has come a long way and the old ways of creating extensive training materials with step by step instructions and days of classroom training are in the past. Web applications nowadays are intuitive and require very little training. Albeit there is always a learning curve for any new application.
If more detailed training materials are needed, over and above the training videos provided by the HEAT Consultant, and workshop recordings of all HEAT Project Sessions to date, then a best practice is to have the customer’s training lead or knowledge manager to work with the HEAT Admin to clarify and if needed, work with the HEAT consultant to tailor customer specific training videos.
However, that shouldn’t stop UAT testing. As always keep moving forward and test what you can, collaborate with your team, and ask for help from the UAT Lead, who can always get help with HEAT specific functionality question from the HEAT Admin.
More often then not, it’s just a matter of getting used to the new way of doing things, reading between the lines, and trust that the most important interface, the chair to keyboard interface, will figure it out.
It’s not unlike getting used to a new card that you’re test driving, it will handle differently then what you’re used to, the gas tank may be called fuel tank and placed on the opposite side of what you’re used to, but doesn’t stop you from the road test. You continue as needed and trust that you will figure out the changes. Owner manuals are time consuming to read, hardly every read, and just collect dust in the glove compartment. A few questions, some help from others, from the experienced drivers, and voila you are mastering the road test in no time.
Waiting until the final hour to ask for help Some implementations tend to go very smooth while others tend to stagnate with the UAT Team either not testing, focusing on nice-to-haves versus validating must-have requirements, and any combination of the above pitfalls, and then ultimately raising a red flag out of the blue with a long list of issues, that could have been easily addressed as per the above recommendations and best practices.
You don’t wait until the day of the paper signing to mention that rattling noise or performance issue during the test-drive, you mention it right here and then. But it can happen, and if it does, then you go for another test drive and move forward!
Gaps Although technically not a pitfall the UAT Team might stop testing all together or raise flags when gaps are identified. Ironically Gap Analysis is the intention of UAT, to validate the Business Requirements and identify any show stoppers (gaps). When a gap is identified, it should be raised to the UAT Lead to verify, and if confirmed, reviewed with the decision maker, to prioritize. Showstopper versus implement-later versus nice-to-have. For example, that ski-rack that you need, and isn’t available. Is that a show stopper? If it’s the middle of summer and you can wait until December? Not having 4 wheel drive for country roads in winter conditions for a work truck could be a major gap. And you know what we do with gaps right, we address them, and fill them. Such as ask for the 4 wheel drive model. However make sure you adequately prioritize gaps and just focus on needs, not wants.
In summary, the best practice for Ivanti HEAT ISM UAT is to ensure that UAT Support Structure is followed, UAT Test Scripts are actively used and maintained, real test data is used from your existing system, and the team looks for solutions, not problems, collaborates regularly, and focuses on must-have versus nice to haves, and moving forward with the new way of doing things, realizing there is a learning curve, and the decision makers have signed-off after many workshops, prototypes, and discussions to move ahead and need you to validate that the day-to-day requirements have been met.
It’s not unlike test-driving a new car you want to purchase. You take it for a spin, and take it through the motions of your day-to-day activities. Parking, driving on the highway, check the storage space, handling, ask your significant others opinion, collaborate on your findings, and then focus on must-haves. The nice-to-haves like the fuzzy dice on the rear-view mirror aren’t important. Those you can get to later, after you did some emergency braking, speed tests, and the likes and find the new car is up to snuff. Sure, you need to get used to how it drives, there is a learning curve to any new car. And if the ski rack you want isn’t available now, in mid-summer, well no biggie, not the end of the world. Also rest assured that the decision makers have done their research, kicked the tires, and had many discussions with the dealership to make sure it’s the right fit. And of course the dealership is committed to address any reasonable concerns or issues.
ITSM/ITAM/ESM Blog 
You must be logged in to post a comment.