Ivanti Project

Ivanti Developer, or Consultant?

This is a very common question I get. There is actually a very important distinction between job titles and skillsets such as “Ivanti Developer“ and “Ivanti Consultant“. And of course, these keywords have nothing to do with employment. When you search for the keyphrase “Ivanti Consultant” or “Ivanti Developer”, you’re not looking for someone employed by Ivanti but rather someone that has knowledge of Ivanti’s products and is available on a contract basis.

Disclaimer:  Not endorsed by, affiliated with, or sponsored by Ivanti
“Ivanti Consultant”, “Ivanti Developer”, refer to job description, experience, and skill set with Ivanti’s product line and are merely descriptive.

Developers are coders and typically focus on software development, coding, and Ivanti HEAT configuration. Whereas Consultants may be functional, technical, or both, bringing years of industry experience to the table and using their knowledge & experience to advise management in areas such as but not limited to SOPs, standard industry practices, workflows, business processes.

Nowadays most “Consultants” are either A) “Developers” with a hefty daily “consulting” rate that far exceeds a developer’s typical rate. or B) “Consultants” with little hands-on development or Ivanti Implementation experience. By “little experience” I mean less than 10 years and less than 25 Implementations.

It really comes down to competence vs skill. Sure, Ivanti HEAT is “configurable” however the Ivanti ITSM tool has come a long way and does tend to require someone with Development AND Consulting experience to consultant with clients to make informed configuration, architectural, business, functional, and technical decisions.

Experience plays an important factor too, as does the the number of Ivanti HEAT ITSM Implementations. After all, there are many freelancers, and developers disguised as consultants with 5 or 10 years experience however more often than not it’s the same 1 year repeated 5 or 10 times, working on 1 Ivanti HEAT Implementation.

Last but not least you need to consider industry experiencecustomer revenue & location. You want to find a developer/consultant/freelancer that has experience in many industries. Why many industries and not your industry exclusively? There’s a saying, “What’s as common as dirt in one industry, is an atomic bomb in another!”, that is, you want to leverage best practices & ideas from other industries. Customer Revenue (i.e. Fortune 500 or Global 500) play an important role as well, after all an Ivanti HEAT ITSM Implementation with thousands of employees and dozens of Service Desk staff has different sets of challenges and solutions than a service desk team of 5 supporting hundreds of employees. And this is where location plays an important role as well, multi-national, versus international, vs domestic operations. If you have offices in the UK, EU, Middle East, Africa, Australia, Canada, and the US for example then you likely have another set of challenges, reporting requirements, and solutions that apply to you versus someone based in a city/municipality for example.

Make no mistake about it, combined, experience, and number of implementations as well as solid Testimonials are key when searching for a competent Ivanti HEAT ITSM “Developer” or “Consultant” or perhaps you just need an “Ivanti Freelancer” that can do it all with competitive rates without the red-tape and huge overhead of a big sales organization, ahem, I mean professional services provider…


6 Reasons you shouldn’t hire me

  1. I am overqualified. 27+ years ITSM experience and 100+ ITSM implementations in the UK, Europe, Australia, New Zealand, South Korea, Singapore, Canada, and USA. That’s way too much experience. You’re probably used to junior developers or consultants and don’t want to change.
  2. under promise and over deliver. You probably want a team of junior developers to overpromise, under deliver, and spend all your time in status calls and meetings to get little done.
  3. My rates are far too competitive. You likely want to pay double the price for half the results and love to pay invoice after invoice with little results.
  4. deliver the latest solutions and best practices. You probably want to stay with the same old cumbersome system and don’t want to improve what you’re doing. Why change anything right?
  5. I’m results oriented. You probably prefer invoice oriented and don’t care about results. You’d rather spend time on status calls, in meetings, and paying invoices with little to show.
  6. Not an Ivanti Consultant, nor Ivanti Developer, nor a member of the Ivanti Professional Services group (which btw is outsourced to Ivanti Business Parnters). I’m independent. Unbiased. Simply Better! I have never been employed by Ivanti, although I have subcontracted for Ivanti Business Partners to provide Ivanti Professional Services due to my extensive experience with products such as but not limited to Ivanti Neurons, Ivanti Service Manager, ServiceNow, Saleslogix, SageCRM, Remedy, HEAT.

    DISCLAIMER: Not endorsed by, affiliated with, or sponsored by Ivanti, ServiceNow, Remedy, Infor, or Sage. Any use of the software product names is descriptive of the fact that I have experience with the above-mentioned ITSM and CRM products

Not convinced? My customers can give you more reasons, see what they have to say here.


ChatGPT and ITSM

Spoiler alert. This blog post was created by ChatGPT!

ChatGPT by definition is a large language model trained by OpenAI based on the GPT (Generative Pre-trained Transformer) architecture, designed to understand and generate human-like language, which allows ChatGPT to have conversations with people and answer their questions on a wide range of topics. The purpose of ChatGPT is to assist and provide helpful responses to users.

On the surface it looks very promising, but as you dig deeper you will find there are still quite a few glitches and it’s more of a glorified search engine, not unlike using Google Voice, Alexa, or Siri to search for information.

Before ChatGPT, there was actually another way to produce similar results. That is with keywords, full-text indexing, and some crafty design & development to produce the correct Knowledge Articles and FAQs. Sure the interface is different but the result is the same, and arguably better because you can target specific keywords to specific results.

AI certainly has come a long way, particularly the AI Voice, which if you’re listening to this ITSM blog post as a podcast, you’ll find it’s pretty good. Still a little robot like for my liking and not very good at acronyms but certainly has potential.

Best Practice System Best Practices Ivanti Ivanti Administrator

Don’t make this newbie HEAT Request Offering Configuration mistake!

Best Practice for designing Request Offerings is to always set a Unique ID for your Request Offering form controls.

Unique ID plays a critical Design & Architecture Role

Unique ID is the Parameter Name which in turn is used for searches, filters, and reporting for Service Requests.

Don’t Do This!

What if you don’t set unique id? You will be in a world of pain when you try to search, filter, or report on Service Request Parameters. In the example above you can see the unique id for the Approving Manager for example is combo_10. That’s not meaningful now is it.

You always want to set a your Unique ID to a meaningful name.

Do That!

But that’s not all… You have many request offerings which have many service request parameters. So you need to use consistent unique id’s across all your request offerings.

Use a Data Dictionary for your Service Request Parameters and use it whenever you’re defining Unique IDs to look up existing Unique IDs and to add new ones.

Data Dictionary

Contact me for a copy of my Data Dictionary!


ITSM Implementation Poll


You aren’t. Until you contact usGuaranteed!

Best Practice System Best Practices Ivanti Ivanti Best Practices Ivanti Service Manager SDLC UAT

Common UAT Pitfalls

I can tell you that User Acceptance Testing (UAT) is where many ITSM Projects tends to fall apart.

I have been providing ITSM Best Practices, Latest Solutions, Development, Consulting, Architecture, and Design since 1996, that’s 27+ years, 100+ ITSM implementations, worldwide, in the UK, Europe, Australia, Singapore, Canada, USA with products such as but not limited to Ivanti Neurons, Ivanti Service Manager, Saleslogix CRM, and HEAT ITSM. I also have ServiceNow, Remedy, and Sage CRM experience.

Disclaimer: Not endorsed by, affiliated with, or sponsored by Ivanti, ServiceNow, Remedy, or Infor. Any use of the software product names is descriptive of product experience/skillset with the above-mentioned ITSM and CRM products.

Today I will cover the most common UAT Pitfalls, recommendations, and best practices to put your ITSM Project back on track!


First and foremost you want to do a review of where the ITSM 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 ITSM 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 ITSM 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 (Product relatedHow-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. ITSM products are no different. Moving from Excel to a new ITSM product, even upgrading to a newer version, has a learning curve, as do major functionality enhancements. 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 ITSM 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 ITSM System or new ITSM 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.

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 ITSM 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 ITSM Consultant, and workshop recordings of all ITSM Project Sessions to date, then a best practice is to have the customer’s training lead or knowledge manager to work with the ITSM Admin to clarify and if needed, work with the ITSM 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 ITSM specific functionality question from the ITSM 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!

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.

HEAT ISM Ivanti Service Manager Asset Manager UAT User Acceptance Testing
Graphic Courtesy of Test Lodge

In summary, the best practice for your ITSM system 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.

Cherwell Ivanti

My thoughts on Ivanti acquisition of Cherwell

This is exciting news! Looking forward to reconnect with former Bendata/Frontrage HEAT Consultants that went to the dark side and joined Cherwell! IMHO the acquisition will make Ivanti Neurons (formerly Ivanti Service Manger powered by HEAT) stronger than ever!

Mobile Application

Mobile Applications

Be sure to check out our Mobile Applications for iOS and Android

The goal of the a19 Mobile Applications is to share Best Practices, Latest Solutions, and Tips & Tricks, for HEAT IT Service Management (Ivanti ITSM), Ivanti Service Manager and Ivanti Asset Manager

Ivanti Android Mobile App | Ivanti Best Practices
Ivanti iOS Mobile App | Ivanti Best Practices

Press Releases for Android and iOS Mobile Apps can be found here

Contact us with suggestions or if you would would us to build an iOS or Android mobile application for you!

Best Practices Ivanti

Implementation Milestones

Over the last 2+ decades implementing HEAT IT Service Management and Ivanti Service & Asset Manager, the following implementation milestones, aka rollout milestones, or roadmap have been deeply ingrained and proven to be the ultimate success factor and project structure.

From Scope of Work to Go-Live (Rollout) there are many steps that need to be carefully planned, communicated, and enforced.

Ivanti Best Practices

ITSM Best Practices: UAT

When it comes to ITSM Best Practices there is no better source than that of a seasoned Consultant with the voice of experience of years Implementation experience.

One of the most crucial steps in System Development Life Cycle (SDLC) is User Acceptance Testing (UAT), a type of system and business objective validation, performed by the end users, and business objective sign-off by the project owner; not to be confused with System Testing which is performed by the Developer and/or Administrator

Many ITSM Implementations fall short when it comes to proper UAT Testing, be it due to a lack of resources, time, or budget, but more often than not due to a shortcoming of proper UAT Action Plan, UAT Test Cases and Scripts, and a lack of Best Practices, Strategy, Coordination, and Planning.

Today we shall focus on ITSM Best Practices for UAT.

UAT Best Practices

  • Daily Stand-Up Calls coordinated by the decision maker and UAT Test Lead with the UAT Test Team
    • Review of UAT Decision Tree
    • Review Test Results, questions, unexpected behaviour, workarounds, tester comments
    • Review Reference Data to-do list for PROD
    • Identify key areas for training (bullet points) 
    • Test Case Maintenance – identify new test cases or changes needed to existing test cases
    • Daily Email Summary to the Consultant, bullet points, of areas that need to be addressed, identifying “show-stoppers” and “must-haves”, “questions”
  • Scribe – Appoint a person to take meeting notes, and keep track of any “nice-to-haves”, “parking lot items”, “knowledge articles” needed.  Typically this function falls on the Knowledge Manager/Trainer.
  • Weekly Calls with ITSM Consultant to review the progress, test results, and discuss UAT remediation scope.
  • Focus on Job Functions, not features, not enhancements, not future phases. 
  • No Bug Hunts – The point of UAT is not to find bugs.  It’s to ensure day-to-day functions can be carried out and the steps for those job functions are documented for training purposes.   Any unexpected behaviour can be recorded in tester comments.
  • Keep it Simple – Focus on test cases at hand.  If there are any issues, make sure to record the reference #, 1 or 2 screenshots, bullet point tester comments, no need for long novels with pages of screenshots.  

For more information be sure to contact us!