Dear Friends,
There is a tendency in business when something is taking too long to immediately look for more resources. Add another person, buy another piece of software, bring in a consultant, and recently Use AI. Sometimes one of those things is the answer, but before you add anything to a process, I believe you need to understand the process itself.
The Lesson
This article goes through the lesson that I learned during my time at Citrix Managed Services, when the team and I helped reduce our customer onboarding process from 14 weeks to 10 weeks.
We didn’t do it by telling people to work harder.
We didn’t add a massive team.
We didn’t discover some magical AI sauce that solved our problem.
We started asking the right questions.
What Was Taking 14 Weeks
When a customer signed a contract with Citrix Managed Services, there was a significant amount of work required before we could fully manage their environment.
We needed to establish ticketing systems and monitoring.
We needed accounts for our team inside the customer environment.
We needed to understand historical ticketing trends and reoccurring problems the clients were already experiencing.
We needed SOPs around Change Management, Device Monitoring, Patch Management, Image Management, Server Reboots, and Maintenance Windows.
We needed to agreements on RACI matrix and escalations.
We needed communication plans and escalation matrices.
We needed internal resources assigned and customer points of contact established.
Fourteen weeks had become the accepted timeline, but leadership knew it was too long. The Director of Citrix Managed Services challenged us to improve it. I was a Service Delivery Manager at the time, but process improvement was something I had always been interested in. I had Six Sigma certification, project management training, and years of experience doing similar work at Forthright Technology Partners.
Map What is Actually Happening
We started meeting with different service owners.
What did their team need?
How long did their portion of the onboarding take?
What information did they depend on?
When were they currently receiving that information?
We also reviewed previous onboardings.
What had gone well?
What had gone badly?
Where had things broken down?
Then we started questioning everything.
Does this step really have to happen here?
What happens downstream if we move it?
What dependencies would break?
Could this work happen at the same time as something else?
Could we gather this information earlier?
That exercise uncovered something that seems obvious now. It wasn’t obvious when everyone was living inside the process.
We Found the Bottleneck
Monitoring was one of the longest components of the entire onboarding process. It could take four to six weeks to complete. Yet, under the existing process, we weren’t seriously addressing monitoring requirements until approximately week eight.
Think about that → One of the longest lead time activities in the entire process was being started late in the process.
We also found that we were waiting until the customer kickoff before requesting information we already knew we were going to need.
That meant we were often two weeks into an onboarding before meaningful pre-work had ever begun.
So, We Changed the Sequence
One of the biggest changes was getting permission to begin gathering requirements before the final contract was signed. That initially made leadership uncomfortable, and understandably so. Their concern was simple: What if we do all this work and the customer never signs? Rather than arguing that the risk did not matter, I asked a different question.
Of all the deals that had made it through legal and were in the redlining process, how many had ultimately failed to close? The answer was → None
Historical risk was extremely low. We also established a boundary. We would gather information and prepare, but we would not install anything or make changes to either environment until the contract was executed.
That allowed us to start asking questions one or two weeks earlier. Things like:
Who would the customer contacts be?
Who needed access to our ticketing environment?
What ticketing platform did they use?
How would integration work?
Could they provide their SOPs?
How many devices did they have?
Could they provide the device list that would eventually need monitoring?
Internally, we could begin assigning the account team and preparing resources.
Now, instead of signing the contract and then beginning to figure out what we needed, we could arrive at Day 1 ready to work.
Eventually, we were entering customer kickoff with roughly 90% of what we needed to begin onboarding already identified or collected.
We Stopped Treating Everything as Sequential
The second major change was parallelization. Many businesses unintentionally build workflows that say:
Finish A.
Then start B.
Finish B.
Then start C.
But A, B, and C may not actually depend on one another. We started grouping workstreams that could happen simultaneously.
For example, discussions around change management could happen in parallel with work on the communication and RACI matrices.
We began asking:
What really has to wait?
That question alone can expose enormous amounts of wasted time.
Fourteen Became Twelve. Then Ten.
The first couple of onboardings under the redesigned process came down from roughly 14 weeks to around 12.
That was progress. We kept learning. We kept adjusting.
By approximately the fourth onboarding, we had the process down to around 10 weeks.
Monitoring, which had sometimes taken as long as six weeks, was routinely being installed and configured in approximately two or three weeks because we had gathered the information earlier.
Grouping process agreements and addressing them earlier helped remove roughly another week.
But the real benefit wasn’t simply four weeks on a calendar.
It was time to value.
Customers began realizing the benefit of the service earlier.
Citrix could begin realizing revenue sooner.
The organization had greater capacity to bring additional clients onboard.
Customer satisfaction improved.
And internally, morale improved because there was less rework and less chaos.
Process Improvement Is Also a People Problem
Of course, not everyone immediately embraced changing the process.
People rarely do. Whenever you change the way, someone works, you are asking them to give up something familiar.
My approach with the service owners was to explain what was in it for them. This is going to reduce your rework. It is going to make your part of the process easier. It is going to take less time and that means you will have more capacity for the other things you need to accomplish.
I have learned that people need to understand why you are changing something, but they also need to understand how the change benefits them.
That is how you get people on your side.
What Business Owners Can Take from This
The first mistake I see business owners make when a process is slow is assuming that more people equal more speed.
It doesn’t.
You can add five people to a bad workflow and simply create a more expensive form of chaos. The same thing is beginning to happen with AI. There is a belief that AI is some type of plug-and-play efficiency pill. Connect AI to the business and suddenly everything gets faster.
It doesn’t work that way.
If you automate a bad process, you may simply make the bad process happen faster. Before you add people, technology, or AI, take the time to understand the workflow. If I were looking at a slow process inside a business today, I would start here.
1. Identify what you believe is slow.
Then confirm it with the people actually doing the work.
Leadership perception and operational reality are not always the same thing.
2. Map every step.
Build the flowchart.
Include decision points.
Include handoffs.
Include dependencies.
And especially include the time gaps between steps.
Often, the biggest problem isn’t how long people spend doing the work.
It is how long the work sits waiting for something else to happen.
3. Talk to the people doing the job.
This may be the most important step.
The people doing the work every day usually know where the problems are.
Listen to them.
4. Find the bottleneck.
Once you find it, don’t immediately try to fix it.
First ask why it is the bottleneck.
Then ask:
What happens if we do this earlier?
Does this step need to exist?
Could we do it differently?
Should it be moved forward?
Should it move backward?
Can it happen in parallel with another activity?
Is there duplication elsewhere in the process?
And finally:
Is the real constraint the process, the available resources, or a legacy system? Those are very different problems, and they require very different solutions.
Always Ask Why
Citrix was eventually purchased by private equity, and our department was ultimately laid off. I obviously did not control that outcome but this project became an important point in my career because it reinforced something I still practice today, personally and professionally.
Ask why.
Why are we doing it this way?
Is this actually the best way to do it?
What would happen if we changed it?
What are we waiting for?
What do the people doing the work think?
Over my 25-year career in IT, I have learned that continuous improvement isn’t usually about having some enormous breakthrough. Very often, it starts by being willing to question something everyone else has accepted as normal.
It also reinforced something else for me.
The people matter.
Getting onboarding from 14 weeks to 10 wasn’t something I accomplished alone.
It was something a team accomplished.
It was validation that, through hard work and partnerships with the right people, we could accomplish something that hadn’t been done before.
Challenges are challenges. What matters is how you approach them and who you surround yourself with to execute against them.
My business philosophy has always been:
Do What You Say You Are Going To Do.
I made promises to leadership.
I made promises to clients.
I made promises to my peers.
And we delivered together.
Because business is a team sport. You are only as good as the people you surround yourself with and when it comes to improving time to value, I keep coming back to the same lesson:
Ask the right questions and understand the workflow.
Before you add more people. Before you buy more technology and definitely before you throw AI at the problem.
If you found this of any value, I humbly ask that you subscribe and share to let others know. Thank You.
Contact Information
Who am I?
I have been in Information Technology for over 25 years at various roles from Systems Engineering to Director level positions. I have also been in real estate since 2019 focusing on fix and flips and in 2023 we shifted our focus to commercial real estate investing. I have acquired 246 units and continue to pursue real estate investments. I also have a Technology Firm helping companies incorporate technology, build systems integrations, and solve complex business problems. An example of this was our Multifamily Deal Evaluator application that was built with an operator, syndicator, and investor perspective so that anyone can learn to underwrite, analyze, and evaluate deals. If you are interested in the tool, you can check it out at KeptDo MFA PRO. If you like to learn more about what we do for small and mid-size business and our approach to processes and incorporation of technology, please visit our site Del Val Investment Group.
Outside of my family, my dog, and my Miami Hurricanes my passion is business, technology, and real estate. We are always looking to purchase businesses that have a unique niche and serve our vision of solving real world business problems with technology and we are always looking for JV real estate opportunities we can operate or invest in as joint partners.
If you would like to reach out or learn more about my background, feel free to connect with me on the following platforms.
Manny Del Val | CEO and Founder Del Val Investment Group