ARE YOU GETTING THE MOST OUT OF YOUR IVANTI SERVICE MANAGER IMPLEMENTATION?
You aren’t. Until you contact me. Guaranteed!
ARE YOU GETTING THE MOST OUT OF YOUR IVANTI SERVICE MANAGER IMPLEMENTATION?
You aren’t. Until you contact me. Guaranteed!
My podcasts cover popular Ivanti Service Manager (HEAT ISM), SDLC, ITSM, ITAM, and ESM Topics.
Why Podcasts? Sometimes 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.
You can find my Podcast on
It is no secret that I strongly believe Email is a productivity tool from the last century and recommend against enabling one-off email notifications unless absolutely necessary.
A much better way and extremely advanced configuration is to create email summaries.
Some popular examples of email summaries are:
Why would you opt out of one-off emails and implement email summaries? Email notifications become counter productive when there is a flood of email notifications for just 1 incident, service request, or task. Back in the day (last century) when ticket volumes were much lower, email made sense. In today’s fast paced Service Desk world, ticket volumes have gone up and turnaround times have gone down, requiring targeted emails, just-in-time (JIT), meaningful, precise and concise emails.
What happens when HEAT ISM End Users get overwhelmed with emails?
Balance, just-in-time emails, with precise, concise information, and email summaries.
When should emails be one-off and when should emails be summarized?
One-off email candidates are any time-sensitive emails, typically high priority. P1 and P2 Incidents Updates, P1/2 Tasks Creations and Escalations, Urgent Service Request for example.
Email Summaries should be employed whenever to expect frequent email notifications on the same subject (think business object) throughout the day. For example summaries of new tasks assigned and outstanding, every morning, or daily incident SLA/Escalation breach warnings and breaches.
What information should be in the email? Email notifications should be precise and concise and contain minimal information, less is more for sure, especially for one-off emails as the information can change quickly. Symptoms for example may get updated and journal notes are added frequently for high priority incidents, so it’s best to redirect the user to a link to open the incident in the HEAT ISM Application.
How do you implement email summaries? This is an extremely advanced configuration topic that requires scheduled workflows, saved searches, quick actions, and use of the ChildFold and ForEachChild functions to create a custom email summary business object that is used to trigger and manage HTML emails as well as provide the user with a link to the email summary within the HEAT ISM Application, and Email Summary Dashboard for a better overview for executives, managers, service desk analysts, and end users alike.
The simple answer is that if you are still unsure how to implement Ivanti Email Notification Summaries, then seek a seasoned Ivanti Consultant that can get it done.
The estimated effort for a simple email summary is anywhere from 5 to 10 days depending on criteria. Please be sure to contact me or set up a discovery session to take your Ivanti implementation to the next level!
PS: If you’re still reading this, here is another tip: Consider Targeted Mobile App Notifications and SMS Notifications as well!
PPS: Ask a19 Consulting about their a19 Email Summary Module for Ivanti Service Manager! The first 3 customers that mention my blog, get a special bonus.
While obvious to the most seasoned Quality Assurance Analysts and HEAT ISM Consultants, the gathering of UAT Sample Data can be confusing to some and is often poorly documented and executed.
Having the right sample data is key to successful User Acceptance Testing (UAT).
The worst thing you can do is test milli-vanilli and only make up input data without using real data. Using made-up sample data can be confusing to UAT Testers, difficult to follow, and lead to false test results.
UAT is all about validating business requirements and confirming that you can perform your day to day job functions. So why would you want to use some made up data? You don’t. You want to use real live actual data to verify that the new system or feature behaves exactly like your old system, whether HEAT Classic, another software system, Excel, manual forms, legacy application, and so on. In my 25+ years of Ivanti HEAT ISM Implementations I have not come across an implementation that didn’t have some sort of tracking tool or method, spreadsheet, or other artifact that can be used as sample data. Even handwritten logs could make up sample data, and I don’t remember the last time I have seen one of those.
Sample input data should be real data, from your existing system, whether it’s a database, excel sheet, paper forms, or another system or artifact. For example tickets from your old HEAT Classic system, Paper Forms from a manual system (Invoices, Logs, etc), if you’re going digital, or sample rows from an Excel sheet if that’s what you’re replacing. These are just some examples.
Tip: Create a “complete workflow” artifacts of examples from start to finish in the process. One of my clients recently added procurement workflows to the Ivanti HEAT System and created a PDF of sample data for the relevant process, from inception of the procurement request, approval, quote, shipment, receipt, asset tagging, stock administration, invoice, and payment. The artifact was through and included sample data from every step. Some digital, others print outs, and even handwritten notes on the invoices. All of which were important sample data for User Acceptance Testing. It was a one time effort by the Subject Matter Expert (SME) and was invaluable throughout UAT, Training, and overall for discussion purposes. Intangibles were positive user morale, adoption, and a clear understanding of UAT Testers as to what data to use and how the new system would benefit them relating back to how they were doing things before and how that was going to change in the new way of doing things. In other words, the sample data artifacts were valuable Training Knowledge and used for review and discussion purposes, and during ongoing UAT Status Calls and meetings.
Bottom line, use real data that represents the typical type of data to expect and the UAT Team members can relate to. Tip: Ask yourself if the data could be used for training purposes. If it can, then include it as an artifact for training documentation. If it can’t, then ask yourself if the sample data is a good representation of a typical day in the life of the end user.
Furthermore, keep in mind that when there are changes, upgrades, or issues, you will want to have sample UAT Test Data to fall back to.
Recently a customer asked me if 2 tests per User Acceptance Test (UAT) Script are enough.
How many UAT Tests should be performed per Test Case?
As many as it takes for you and your team to feel comfortable that you can perform your day-to-day job function.
Recommendation and Best Practice is a minimum of 5 tests per UAT Test Script. Anything less is a risk that the client need to evaluate. Some detailed, complex, and high impact UAT Test Scripts may require at least a dozen of tests for the various scenarios that you have identified. It is better to test more than less, that’s for sure. Perform as many tests as it takes for you and your team to feel comfortable that you can perform your day-to-day job function.
Experience dictates that if UAT (validation of business requirements) isn’t thorough then the likelihood of post-implementation issues, gaps, and problems is much much higher, and can take more time and effort to address than during UAT.
Intangibles like morale and perception of the new Ivanti HEAT Service Manager system/features can also be negatively impacted.
Also note that you are not bug hunting, so you don’t need to test every single feature and menu item, however you are testing that you can perform your daily job function, so test all the features related to the use case (business process) that apply.
It’s not unlike ordering a fleet of vehicles simply by kicking tires and doing a lap around the parking lot versus more extensive test-drives tailored to the company wide business needs. Sure, everything “might” appear fine, and “might” go fine upon delivery. But those are huge risks to take for a high dollar, high impact, high exposure item that ultimately could lead to work slow down or stoppage.
No matter how detailed your UAT Test Scripts, you need to have a good range of test case scenarios (sample input data) for every test script. Sample input data should be real data, from your existing system, whether it’s a database, excel sheet, or paper forms. For example tickets from your old HEAT Classic system, Paper Forms from a manual system, if you’re going digital, sample rows from an Excel sheet if that’s what you’re replacing. Bottom line, use real data that represents the typical type of data to expect and the UAT Team members can relate to. Tip: Ask yourself if the data could be used for training purposes. If it can, then include it as an artifact for training documentation. If it can’t, then ask yourself if the sample data is a good representation of a typical day in the life of the end user.
The time and effort required is usually negligible. Minutes per test.
A great amount of time and effort has gone into the Ivanti HEAT project, and UAT is a critical milestone in the Software Development Life Cycle (SDLC). So make it count and be thorough on your validation of business requirements, UAT that is.
User Acceptance Testing (UAT) is without a doubt the most critical stage of the SDLC. This is where “the rubber hits the road”, and the customer and subject matter experts (SMEs) validate the business requirements.
This is also where typically some customers and SMEs tend to panic, get confused, worry, or simply get overwhelmed by the project at hand. Rightfully so, there is usually a lot at stake and the customer wants to make sure their business requirements are met, as does the consultant.
On one side, the customer and SMEs look up to the consultant for guidance drawn from years of experience, on the other hand, customers and SMEs also tend to think they know better.
So who is right?
Over 2 decades with HEAT Consulting, Business Analysis, and Project Management have taught me and reinforced, is that the customer isn’t always right and neither is the consultant. Looking at who is right is wrong! Instead of building a law case and looking to disprove one another, everyone needs to TRUST THE PROCESS.
If you have made it to UAT so far. Best Practice is to always review the steps taken (process) to-date.
…and the steps (milestones) ahead:
In Summary, using the analogy of purchasing a car, the buyer (customer) has done their research and made a list of must-haves, and nice-to-haves (business requirements), identified the car type, model, and budget (scope) with the help of the dealership (Ivanti HEAT Consultant), and now it’s time to take the car (system) for a road test (UAT). This is where “rubber hits the pavement”.
UAT. This is where some customers tend to experience a little anxiety and suddenly question their very own requirements and the very system they helped build, see Common UAT Pitfalls for more details, while other customers shine and jump into the drivers seat and master the road test (UAT).
Acquiring a new car (System/Major Functionality Changes/Upgrades) can be overwhelming for many reasons, covered in the Common UAT Pitfalls Ivanti HEAT ITSM Blog Post. But like anything else in life, you need to do a self check and trust the process.
You’ve made it this far, sure the new car can be overwhelming, but once you hop into the driver seat (take responsibility) and go on that road-test (UAT), familiarize yourself with the new vehicle, adjust the mirrors, seat, study the controls (learning curve) and see how the vehicle handles (learning curve), you soon start parallel parking, emergency breaking tests, city driving, highway driving, and so on.
The road-test (UAT) is the time to stop kicking tires and take action. Trust the process and go for that test-drive. The goal is to report back any issues (UAT Test Scripts), collaborate with the family, (UAT Meetings with UAT Lead to review UAT Test Script Results), and ask questions (UAT Test Script Module has comments for the consultant), and not only CONTINUE with the road test (UAT Test Scripts), but go on several road tests (many tests per UAT Test Script), and before you know it, you master the new car (system).
The last thing you want to do is stop the road-test every time you are unsure (learning curve), have a question (Learning Curve / UAT Meeting), or feel something is not right (UAT Test Script Result). You keep driving and report back your findings (UAT Test Script results) and collaborate with the family (UAT Team) to see if your findings are issues or just a learning curve (new controls, new way of doing things), or terminology (gas tank versus fuel tank), or it’s a major change, like driving on the right side of the road to the left side (major system upgrade), which requires more test drives. Or maybe you’ve never driven a car before and you are upgrading from a motorbike, bicycle, or walking on foot (legacy systems, Excel, Word, handwritten notes). Assumption is that you’ve taken your driving test and have a valid license of course (experience in the business, and have used Windows and web-apps before). Nowadays web applications are intuitive, as is learning to drive a different type of car (sports car, SUV, mini-van, luxury car). The days of long thick training manuals and days of classroom training are in the past although training videos can be provided as needed to fill any major training gaps. In other words, a learner’s license and some time with an experienced driver are just as efficient as a 2 week intensive course. At this stage of the implementation all SMEs are typically well versed with handling a car (Windows, Web Applications).
The learning curve will vary and you must TRUST THE PROCESS. You’ve made it this far, and should feel confident you have the support of the internal teams and external Ivanti HEAT Consultant, however ultimately you need to do the test-drive. The Ivanti HEAT Consultant has already done his. Now is the time to roll-up-your-sleeves-get-to-work-test-test-test with the goal of testing and providing concise precise results back to identify any gaps and more importantly, CELEBRATE THE WINS, mark test results as passed. So focus on the EASY TESTS FIRST, you know the parallel parking, driving in the parking lot, city driving on a slow day, before you go on a multi-lane highway or off-road in the Rocky Mountains on one of the toughest terrains.
You will get there, just keep testing, and know that the combination of your planning of must-haves (business requirements), intimate knowledge of your business processes, and the extensive experience and guidance by the Ivanti HEAT Consultant will get you there!
Incidents are Break/Fixes for issues where something was working but stopped working, a single unplanned event that causes a service disruption.
Service Requests are for requesting new Services or changes to existing Services, for example for new access requests, change of access requests, New Hardware Requests, Repair Requests.
Note that many Service Desks are transitioning to this ITIL and Industry Best Practice, which can take time, hence there may be some “Service Request” and “Problem” tickets that are presently logged as Incidents.
Problem Records are used when a cause or potential cause of one or more incidents are identified whereas an incident is a single unplanned event that causes a service disruption. A problem can cause a single incident, or it can cause multiple incidents. And an incident may be traced back to a single problem or—sometimes—multiple problems.
For example, if Wifi goes down in the board room once, that is an Incident. If we need to install Wifi or make changes to the Wifi configuration, that is a Service Request. If Wifi in the boardroom goes down every Friday at lunch time, that is a Problem Record. Problems can also be “potential causes”, in other words “preventative”, where you spot an issue, for example you notice that staff unplug the router when they need an extra power outlet.
It’s all the same isn’t it? No. Reporting and Metrics are perceived and interpreted by Senior Management and Executives that weigh Incidents negatively as Incidents are typically viewed as problems that negatively impact IT (IT screwed up) whereas Service Requests are perceived as adding-value (all hail IT).
Tip: Incident Cause Codes are also imperative for management and executive metrics and reports to identify the root cause of negatively viewed break/fixes. Some great examples of cause codes are “User Error”, “Knowledge/Training”, “Hardware”, “Software”, “Configuration”, “Vendor Configuration”, “Business Process”.
Incident Cause Codes and other additional metrics are vital to measure KPIs, root-cause analysis, management and executive reporting.
One of the HEAT Classic Features that is frequently requested is to bring back the customer history. There are several implementations for this, yesterday covered how to implement Incident Customer History for Related Items, aka Object Matching, today we will cover how to show Customer History using a Quick Action.
Save and add to the Incident Layout Form View Toolbar with disabled expression:
$(nvl(ProfileLink_RecID, “”) == “”)
One of the HEAT Classic Features that is frequently requested is to bring back the customer history. There are several implementations for this, today we will cover how to implement Incident Customer History for Related Items, aka Object Matching.
Tips & Best Practices:
You can add additional filters or edit existing filters to show:
Email was a great productivity tool, back in the 1990s! In the HEAT Classic Days.
Nowadays managing your inbox can be a full time job, and those notifications that you thought were great at scope of work or solution design workshops, quickly become annoying, forgotten, and filtered to some folder you’re quite frankly just going to purge when your mail account runs out of storage space.
Notifications are good but Dashboards, Targeted Emails, and Email Summaries are better.
Here are some quick tips and a19 Best Practices to reclaim your email inbox and use email as it was intended to, as a communication tool. Effective communication that is!
Email was great back in the day. It’s time to face the news and re-evaluate when and how to use Ivanti ISM (HEAT) email notifications to communicate more efficiently and implement the latest best practices.