Implementing Enterprise Software
Implementing Enterprise Software – D M Goldstein, September 2025
Have you ever been on a cruise ship? At the dock they verify your boarding pass, take your luggage, and direct you to your room. Before the ship sails, they gather the passengers on deck for a brief safety demonstration, and an introduction to your crew. They review the itinerary of planned stops, available on- and off-ship activities, and other onboard information such as food and entertainment options. Welcome aboard.
Some companies view onboarding enterprise software users in the same way. As with personal software, they think it is as simple as, “Here is your software; here is your license key; here are your login credentials; here is your documentation and training; here is your bill. Welcome aboard.” If you think it is really that simple, ask your IT team, and they will tell you about an amazing journey filled with danger and wonder. It usually involves a large project: identifying the need and getting budget, comparing competitors and acquiring the software (including negotiating contracts and price), designing and implementing your instance of it, testing, and finally user onboarding, training, and enablement as part of rollout. And then there are ongoing updates, maintenance, and administration. The first couple of steps are not relevant to this article; let’s get into Implementation.
Implementation Models
The basic kinds of software implementation differ mainly in the level of complexity. The simplest, “plug and play”, is as straightforward as the discussion above. When my son was four years old, we bought “Putt-Putt Saves the Zoo” (Humongous Entertainment, Ref 1). He inserted the disk into the computer and, with no set-up steps at all, proceeded to understand and play the game with zero adult intervention. Everything in life should be this easy.
Next in complexity is software that can be configured. This allows the user or administrator to enable and disable features, configure options and behaviors, and set up usage parameters. Most personal software on your phone or desktop is like this; you enter “Settings”, check the boxes for your desired behavior, and fill out a few fields for personalization. Straightforward business applications, such as service-based offerings, could fall into this category.
Requiring more time and planning are systems which must be customized. Going beyond simple “Settings” menus or configuration files, implementation of these systems may require design work, creation of custom screens, rules, and workflows, changes to the data model, and integration with external systems. Much of the Enterprise software used in business fits into this model.
At the top of the complexity scale is software that must be built. More than configuration or customization, these applications are like a big toolbox. “Here are your lumber, hardware, and tools, and some cool gadgets we built to help you; now go assemble what you need with it.” Of course, there are “home-grown” systems as well, which are built without the benefit of a packaged toolkit. “No Code” AI application generators claim these kinds of results without the effort; I think they are closer to customized applications as you are choosing and modifying templates in many of them.
Implementation Details
The questions which must be answered before spending time and money include, “What business problem(s) are we trying to solve?” Without that guidance, how will you know whether you are doing it right? Suppose you are about to implement something complex, like a CRM system (Ref 2). Which aspects of CRM are you rolling out - Marketing, Sales, Case Management, Entitlements, etc.? Which existing systems are being kept or replaced? Which other systems will this one need to “talk” to? Where will the “Master” data live for things like Customer information, which can exist in multiple systems? Which internal organizations will be affected, and what is their level of participation on this project? Who is on your Implementation team: in-house staff, vendor staff, or a third-party implementation partner?
While the team usually includes in-house IT or Operations staff and external professional services (vendor or third-party), I have found that successful implementations also require participation from future end-users. They can advise on workflows, screen layouts, data fields and associated rules, and how this tool interacts with others in your ecosystem. Introducing any business system without this input is bound to meet with resistance and often requires some rework to get user buy-in. This is where much of the customization and build-out happens. Thus, they must be included on the team early in the process; this is not something you can postpone until the eve of rollout. (I discuss this more during a podcast interview, Ref 3, starting around timestamp 16:50.)
The data can be particularly problematic. Are you trying to import legacy information from a system that is being replaced? If so, which data is important and what is your migration strategy? Are you going to integrate and share data with another business system? As mentioned above, if multiple systems are sharing data, which is to be the master “source of truth” and how will the systems stay synchronized? A colleague of mine wrote an article on using AI to help with data migration, potentially significantly reducing the amount of time spent on this step (Ref 4).
Those who know me or my articles know that I like analogies. I am reminded of building projects with Lego™ bricks. You can buy a model of just about anything. Take it home, open the box, take inventory of the parts, follow the excellent step-by-step instructions, and voila, here is your [whatever]. Not quite “plug and play”, since it requires manual effort to assemble, but close. Some sets may have sections which are multi-functional depending on which way you build or play with them. That is getting into Configuration territory. Models may be part of a series where each component involves the same location, activity, characters, or theme. You can mix and match and display them as a group. You can even add bricks or replace bricks from the set with ones you happen to own. That feels like Customization and Integration. And for those who are very talented at it, you can use your loose bricks to build your own additions to the set. You are now deep into the Build and Home-Grown experience.
Remember that end-user participation? Make sure they are getting the product exposure and training they need to make informed decisions and recommendations. They should be seeing screen mock-ups, playing with hands-on prototypes, and contributing to design decisions. “Hey, what do you think of this cool thing I just built with the spare Legos?” “Wonderful, it fits right into our collection!”
Recommended by LinkedIn
User Acceptance Testing (UAT)
The next critical step before going into production is User Acceptance Testing (UAT). This is where specific future users get hands-on experience with the application. There are typically some scripted tests, where they are instructed to perform specific tasks, but users are also encouraged to explore beyond the scripts. They are performing quality assurance (QA) to make sure it works as designed, but they are also testing whether the design matches their needs and expectations. Their input and feedback are critical to tune the application and correct any behavior which would disrupt their normal workflows. As with the Implementation team members, these users are trained in advance, and their experience with that training and UAT can help tune the training for the broader user community.
Training and Enablement
“I hear the train a-comin', it's rolling 'round the bend” (Johnny Cash, Ref 5). I’ve already mentioned the need to train members of the Implementation and UAT teams. Shortly before rolling out the new tool, you need to train the broader user community. While the earlier folks may benefit from deeper training to help with implementation and testing, the broader community needs to understand, at minimum, the tool’s Functions, Features, and Benefits. “What does the tool do, how do I do it, and why would I want to?” Between the vendor and the Implementation team, role-specific tutorials may need to be created. To aid with rapid team acceptance, “gamification” sometimes helps - creating contests and rewarding individuals or teams for reaching certain milestones in their training and usage. Displaying their status on a “Leaderboard” often enhances the competitive spirit and drives progress.
During training, it helps to include a discussion of the decisions and customizations made, with an explanation as to why. Having the users who participated in Implementation and UAT participate as “evangelists” also helps get acceptance and adoption from the broader base. This is also the time to ensure users have proper login credentials and anything else required to access and use the system. That could include access to other integrated systems, proper software on their devices (computer, desktop, phone), and addressing any security concerns. I wrote an article on “Support Readiness” (Ref 6); while aimed at preparing Support for a new or updated release of their own product, many of the concepts apply to an in-house tool as well.
Go-Live and Rollout
This is your moment of truth. If you’ve done the previous steps well, this event is something to celebrate. Otherwise, it may be a moment to run, duck, and cover. There are some important considerations here. First, if this is replacing an older system, do not decommission it until you are sure the new system is working. Users should not be allowed access to the old system, but keeping it ready is a great insurance policy if you need to either fall back to it or verify legacy behavior or data.
Next, you should have members of the Implementation and UAT teams available “real time” to the users to address concerns and questions. In the days when staff were all in the same office, this was “Walking the Floor”; these days they may be hosting a Chat room or a channel on a messaging service like Slack. A “Tiger Team” should be ready to quickly implement any critical changes for problems that are discovered. And either a timeline or well-defined “exit criteria” should be adhered to defining whether and when it is safe to retire the old system. This should be obvious, but timing matters; if possible, don’t do major system implementations during high-volume or business-critical periods.
Your captain and crew have done their pre-launch maintenance and safety checks. The hospitality teams have ensured the rooms are ready and the supplies are onboard. Your passengers are all aboard and know the emergency drills. Your ship has adequate supplies of food and fuel, an itinerary, navigation aids and plans, and everybody is excited about what lies ahead. Welcome aboard and have a safe and enjoyable journey.
References
7. Photo credit: ChatGPT
End-user training is so critical.. although I might be biased because it's my favorite kind of CSM work to do. I really like this and will keep it in mind: "Having the users who participated in Implementation and UAT participate as “evangelists” also helps get acceptance and adoption from the broader base."