Saturday, March 21, 2026

Computer Simulation: Pickleball Courts!!!


 

The Conversation Most Players Recognize

If you play pickleball, you’ve probably heard some version of this conversation before.

Someone says, “We need more courts.”

Someone else responds, “No, we just need to rotate faster,” or “Shorten the games.”

It usually turns into a debate about process versus capacity.

I recently got into pickleball myself and play at a very busy set of courts with a strong and thriving community known as the Encanto Pickleballers. It’s a group made up of players of all ages and abilities, working closely with the City of Phoenix to make pickleball more accessible and to help meet the growing demand for courts. It didn’t take long to start hearing these same conversations happening in real time.

Recently, I had a chance to explore that question more formally. After a conversation with the group that was considering adding a fourth court and discussing ideas like shorter games, I built a small discrete event simulation to evaluate what would actually happen under different scenarios.

The goal wasn’t to create a perfect model. It was to create something realistic enough to support a decision.


Starting From a Full System

The model doesn’t start with empty courts or light traffic. It starts at what most players would recognize as a typical busy period, like a Saturday morning. All courts are already in use, all paddle spots are filled, and everyone else is waiting to get on.

In other words, the system is already full when the analysis begins.


Modeling Real Game Variability

To represent game length, I used a triangular distribution. For standard scoring (games played to 11 points), having played and watched many games already, I assumed games could be as short as 8 minutes, most commonly around 13 minutes, and occasionally stretch out to about 22 minutes. For shorter 9-point games, I used a slightly tighter range of 7 to 18 minutes, with most games around 11 minutes.

These values reflect typical recreational play across all skill levels. Not tournament conditions, just what you would expect to see at a busy public park.

Results were averaged across 100 simulation replications to account for variability in game length.


What Happens With Three Courts

With three courts under those conditions, the results are not surprising, but they are useful to quantify. Average wait times come out to a little over 20 minutes, with the longest waits pushing into the mid-30 minute range. That lines up well with what players experience. Most waits feel manageable, but every so often, you end up waiting much longer than expected.


The Appeal (and Limitation) of Shorter Games

One option that often comes up is shortening games. When I tested a 9-point format, the model showed a noticeable improvement. Average waits dropped to around 17 minutes, and overall capacity increased by roughly 16 percent.

From a purely operational standpoint, that works.

But there’s a social reality that matters just as much as the math. In this case, that option had already been discussed within the group and was overwhelmingly unpopular. So while shorter games improve the system, they may not be a viable solution.


What Adding a Fourth Court Changes

That leaves the other option: adding capacity.

When I introduced a fourth court into the model, still using standard scoring, the change was much more significant. Average wait times dropped to around 15 to 16 minutes, and the longest waits came down as well. The system didn’t just get slightly better. It felt noticeably different.


When Process Improvements Hit a Limit

What’s happening here is something that shows up in a lot of operational systems. Early on, you can improve performance by tweaking the process. You can adjust rules, change behavior, or tighten up how things are managed. But once demand reaches a certain level, those improvements start to produce smaller and smaller gains.

Eventually, you run into a hard limit. At that point, the issue isn’t how the system is being run. It’s that the system is simply too small for the demand placed on it.

That’s when adding capacity starts to outperform process improvements.


A Simple Way to Quantify the Impact

A simple way to think about the impact is this: a fourth court creates roughly 17 additional player opportunities per hour during peak periods. Over the course of a typical four-hour busy window, that translates to around 65 to 70 additional players getting on the court.

That’s not just a marginal improvement. It’s a meaningful increase in access.

One important assumption in this analysis is that the number of players stays fixed. In reality, that may not hold. If wait times decrease, more players may show up. That’s a common pattern in many systems. Improvements can attract additional demand, which can offset some of the gains.

Even so, under current conditions, adding a fourth court provides a substantial improvement in both average wait times and the overall player experience.


A Familiar Pattern Across Systems

What I find interesting about this isn’t just the pickleball application. It’s how familiar the pattern is.

The same dynamics show up in hospitals, clinics, airports, and call centers. You have variability, shared resources, and queues forming under peak demand. The question is almost always the same: do we fix the process, or do we add capacity?

Simulation helps answer that question in a way that intuition alone usually can’t. It allows you to test scenarios, understand tradeoffs, and make decisions with a clearer picture of how the system actually behaves.


Beyond the Numbers

But there’s another side to this that doesn’t show up in the numbers.

Talking with players and seeing feedback from the Encanto Pickleballers community, it’s clear that this isn’t just about wait times. For many people, pickleball has become an important part of their daily lives, helping them stay active, improve their health, and build meaningful social connections.

Some players have shared stories of losing weight, or finding a much-needed outlet for stress. Others talk about the friendships they’ve built and the sense of community that keeps them coming back.

That context matters.

Because when you think about adding capacity, it’s not just about reducing a queue.

It’s about increasing access to something that is clearly providing real value to people.


Final Thought

Sometimes the answer is better process design, and sometimes, the system just needs to be bigger.


If you’re working through similar questions around wait times, capacity, or system flow, I’m always interested in exploring these types of problems.


This analysis was conducted using ExtendSim Discrete Event Simulation.

If interested in learning more, you can reach me at astrozuggs@gmail.com

This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.


Thursday, February 26, 2026

AI Won’t Replace Healthcare Simulation Engineers...But It Will Redefine Them






πŸ›‘ AI Won’t Replace Healthcare Simulation Engineers...But It Will Redefine Them

If you work in Discrete Event Simulation (DES) in healthcare, you’ve probably wondered:

AI can write code.

AI can analyze data.

AI can optimize schedules.

So… are we next?

Short answer: No.
Long answer: Only if we define our value too narrowly.


πŸ’‘ AI Replaces Tasks, Not Systems Thinkers

Yes, AI can:

  • Generate simulation logic
  • Clean data
  • Run scenarios
  • Automate documentation
  • But healthcare simulation is not just about building models.

It’s about:

  • Understanding messy hospital realities
  • Identifying system constraints
  • Framing the right operational question
  • Translating results into decisions

AI doesn’t walk the Emergency Department at 2pm on a Monday in late January (i.e. RSV/Flu season).

It analyzes documented workflow.

It doesn’t observe real workflow (And those are often not the same).

It doesn’t interview nurses.

It doesn’t navigate organizational politics.

Healthcare is a social system wrapped in operational complexity.


πŸ— Industrial Engineering Is the Foundation

Industrial engineering was built on systems thinking and operations research.

Long before AI, we were:

  • Modeling queues
  • Optimizing resources
  • Managing variability
  • Studying flow under uncertainty
  • Designing systems, not just processes

Discrete event simulation is simply one expression of that foundation.

AI can assist with calculations.

But systems thinking, understanding interdependencies, constraints, tradeoffs, and unintended consequences is the core of industrial engineering. That foundation is not being automated.

If anything, AI increases the need for people who understand operations deeply enough to ask the right questions.


πŸ“ˆ The Real Risk: Staying Technical

The professionals most at risk are those who:

  • Only know one software tool
  • Only build what they’re asked to build
  • Don’t influence decision-making
  • Avoid learning AI

If your value is “I build models,” automation competes with you.

If your value is:

  • Designing experiments
  • Interpreting tradeoffs
  • Communicating uncertainty
  • Driving strategy

Then AI becomes leverage, not a threat.


πŸ”„ The Shift: From Model Builder to Decision Architect

Healthcare systems are moving toward:

  • Digital twins
  • Predictive surge planning
  • Real-time capacity optimization

Simulation is foundational to all of this.

The future role isn’t:

“I build Emergency Department models.”

It’s:

“I design healthcare capacity strategy using Simulation and AI.”

That’s a higher level of impact and it’s rooted in industrial engineering principles.


🧠 Final Word

AI will change our field.

It will reduce low-level technical work.

It will raise expectations.

But it will also increase demand for professionals grounded in systems thinking and operations research.

Industrial engineering was never about software.

It was about designing better systems.

The question isn’t: “Will AI replace me?”

It’s: “Am I operating at the level of system designer or just tool operator?”


Ironically, this article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

Posted by Continuous Improvement Pal (Steven Suggs)

Wednesday, December 17, 2025

Computer Simulation Tip: Sometimes the Goal Isn’t to Change Minds

 


🧠 Sometimes the Goal Isn’t to Change Minds

During a project in an emergency department, a nursing supervisor made an offhand comment to me: 

“The quickest way to screw something up is to bring in an engineer.” 

This is definitely something I have heard before. No tension and no confrontation; it was just a comment, shaped by past experiences and said as a joke.

At the time, I was working on a computer simulation intended to support operational decision-making. 

The model was technically sound, but as anyone who works in simulation knows, correctness alone does not guarantee impact.


🧩 Champions, Neutrals, and Blockers

I’m no expert in change management, but over the years I’ve had formal training and have completed organization-specific certifications. One idea that shows up again and again is that people involved in change tend to fall into three groups: champions, neutrals, and blockers.

Champions support the work.
Neutrals sit on the fence.
Blockers don’t need authority to slow things down; they just need influence.

In this situation, my goal was never to turn that supervisor into a champion of simulation. My only objective was to make sure he stayed firmly in the neutral group and didn’t become a blocker for others. 


🀝 The Lowest-Effort Intervention

I didn’t manage change, explain modeling assumptions, or try to persuade him of anything. I was simply very pleasant and consistently positive.

I made sure every interaction we had, no matter how brief, ended on a good note. It was easy to do, took very little time, and didn’t distract from the actual technical work.

For simulation practitioners, this is an important point: technical correctness doesn’t guarantee adoption.


πŸ“‰ When a “Correct” Simulation Still Loses

The main takeaway for me is this: not every comment deserves engagement, and not every person needs to be converted. In complex environments like healthcare, sometimes the smartest move is not to spend extra time and energy trying to drive adoption of a model or its results.

A technically correct simulation that people choose not to trust or act on can still feel like a loss. 

If stakeholders decide not to take your recommendations, the system doesn’t change, regardless of how strong the analysis is.


✅ Final Word

Simulation doesn’t change systems. People do.

Keeping someone comfortably on the fence can be just as valuable as winning a champion. Sometimes success looks like this: when your name or your simulation comes up, someone says, “Yeah, I like them. They are cool, they’re easy to be around, and they really care about what happens here.”

For engineers and simulation professionals, leadership and soft skills aren’t separate from technical work. They’re what allow good models to actually make a difference.

This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

Tuesday, July 1, 2025

Computer Simulation Tip: Stop Modeling the ED Like a Clinic, It Doesn’t End at Bed Placement








πŸ›‘Stop Modeling the ED Like a Clinic: It Doesn’t End at Bed Placement

When modeling an emergency department (ED) using discrete event simulation, it’s tempting to treat “bed placement” as the final step for admitted patients. After all, once a bed is assigned, isn’t the job done? Not quite. Bed placement is just a decision point — not the end of the patient’s ED journey.

What comes next — boarding delays, inpatient bed unavailability, transport lags — has a massive impact on ED crowding, length of stay, and even patient outcomes. Ignoring that final stretch means your model is skipping over the part where the system often breaks down.


πŸ’‘ The Biggest Opportunities Are Often After “Admit”

Across many hospitals and real-world models, the most valuable improvement opportunities emerge after the admit decision. Why? Because that’s when the ED starts feeling the weight of the inpatient system’s inefficiencies.

Patients board for hours while inpatient beds are cleaned, staffed, or simply opened up. Observation units run near full, and delays in inpatient discharges cause ripple effects that choke ED flow. The result? Bottlenecks that can't be fixed no matter how efficient the front-end ED processes become.


πŸ“ˆ Planning for Growth? You Need to Model What’s Next

Even if boarding times are low, that doesn’t mean your system is in the clear. If you're using simulation to test future volumes, expansions, or surge scenarios, you’re going to stress the system and inpatient and observation capacity will likely become the new limiting factors.

It might be tempting to model the ED alone, just as you might model a clinic because a clinic is a closed system. In a clinic, patients are seen, treated, and discharged all within the same setting. But the ED isn't like that. It’s tightly coupled to the rest of the hospital. Simulating it like a clinic is a category error that can lead to dangerously incomplete results.

Without modeling what happens after admission, you risk generating false positives: results that look promising in simulation, but fall apart in the real world. That could lead to misplaced investments, ineffective policies, and frustrated teams wondering why nothing improved.


πŸ€” But What If You’re Just Improving Fast-Track or Discharge-Eligible Patients?

A common question is: “If our focus is on patients who are likely to be discharged, like fast-track, low-acuity, or rapid assessment areas, do we really need to model the inpatient side?”

It’s tempting to think you can skip it, but here’s why that can backfire.

Your ED is a shared system. Even patients who are quick to discharge still rely on the same beds, staff, and physical space as patients who are boarding. When admitted patients get stuck waiting for inpatient beds, they tie up resources and create downstream congestion that impacts everyone — including the fast-track population.

So you can build the best triage or rapid treatment process in the world, but if hallway beds are full of boarders or your nurses are tied up managing admitted patients waiting hours for an inpatient bed, those low-acuity patients will still get stuck.

Boarding delays hurt everyone. They slow down throughput, create backups in triage, and extend wait times. If your simulation doesn’t account for that reality, your projected gains from front-end improvements will likely be overly optimistic.

When might it be okay to skip it? If you’re modeling a truly separate, dedicated unit with its own space and staff — with guaranteed capacity not shared with boarded patients — you might get away with it. But for most real-world EDs, the flow is interconnected. If you’re testing future volume or surge scenarios, ignoring the inpatient side is almost always a mistake.

🀦‍♂️ The Common Pitfall: Modeling Only the ED

I can’t tell you how many times I’ve gone to simulation conferences and seen detailed, impressive ED models — that stop cold at the admit decision. It’s common, especially for newer modelers or academic projects. The ED feels bounded. The data is accessible. And yes, the inpatient side can feel messy and hard to model.

But here’s the deal:

You can’t fix the ED without fixing how patients get out of it.

A model that ends at bed placement may look clean, but it won’t reflect reality. It risks misleading leadership and producing recommendations that don’t solve the actual constraint.


🧠 Yes, It Takes More Time — But It’s Worth It

Sure, including inpatient and observation logic takes more effort. It adds complexity. And stakeholders unfamiliar with simulation might not immediately understand why it's necessary. But that’s where your role as a modeler becomes strategic, not just technical.

If your goal is real-world impact, the extra time is worth it. A more complete model, even a simplified inpatient abstraction helps ensure your insights are valid, your scenarios realistic, and your decisions aligned with how hospitals actually operate.


✅ Final Word

Simulation isn’t just about visualizing the present. It’s about pressure-testing the future. And that only works if you model the full story — not just the clean parts. So, if you're serious about change, whether it’s fixing today's ED bottlenecks or preparing for tomorrow’s demand, don’t stop at bed placement. Model what happens next. That’s where the system really starts to speak.


This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

Wednesday, December 6, 2023

Optimizing Hospital Size: Discrete Event Simulation vs. Traditional Architectural Approaches in Healthcare Planning

 


Discrete Event Simulation (DES) plays a crucial role in healthcare planning, focusing on the optimization of hospital size. Contrasting traditional static architectural blueprints with the dynamic, data-driven lens of simulation. 


Strategic Decision-Making: 

Traditional architectural plans provide static blueprints, analogous to snapshots frozen in time. In contrast, discrete event simulation serves as a dynamic, data-driven lens that anticipates and navigates the complexities of operational challenges. The integration of simulation isn't just a strategic addition; it represents a departure from the rigidity of conventional approaches, enabling the creation of operational ecosystems that dynamically evolve and adapt to achieve excellence.

Financial Responsibility: 

Architects bring an artistic touch to hospital design, but discrete event simulation introduces a financial savvy that goes beyond the aesthetic. This presents health systems with a solution that goes beyond space design—creating hospitals that are not just visually appealing but also financially sound and operationally efficient. Simulation provides the means to precisely match the hospital's size with the community's needs, achieving budgetary efficiency, and responsible resource allocation.


Interested in learning more, you can reach me at Astrozuggs@gmail.com


Challenges of Oversizing and Undersizing: 

In the realm of healthcare planning, the unintended consequences of architectural designs often manifest in hospitals that are either too large or too small. Here, discrete event simulation becomes the guiding force. Those well-versed in its dynamic intricacies aren't just advisors; they serve as navigators, steering away from the risks tied to ill-fitted hospitals. The goal isn't merely to provide solutions but to transcend the limitations of conventional architectural finesse, dynamically adapting to the ever-changing operational landscape. By doing so, it aims to alleviate the need for endless, costly process improvement initiatives that may become necessary when the hospital is not initially built to meet the community's precise needs.

Long-Term Impact and Feedback: 

In the ongoing process of healthcare planning, being well-versed in discrete event simulation means more than a fleeting role in the early planning stages. It positions you as a vital player in establishing lasting success. By introducing the concept of continual evaluation and improvement, you guarantee that your insights have a lasting impact well beyond the hospital's beginning. Simulation transcends building design; it is about shaping a legacy of operational excellence, rooted in an enduring dedication to learning and adaptability.

Conclusion:

Simulation transcends conventional building design, becoming a driving force behind a perpetual commitment to learning and adaptability, ultimately reshaping the landscape of healthcare infrastructure.


This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

 

Friday, April 1, 2022

Computer Simulation can be affordable: You can get enormous benefits with Small Computer Simulations using only a few pieces of information and not break the bank with gigantic consulting fees!!!







Often when performing Discrete Event Computer Simulations for clients, it is because they need to make "What if" decisions on their complex operations that could be costly to get wrong. 


Frequently, you will need a large complex Computer Simulation, which can be a pricey endeavor (most organizations will hire Simulation Engineers/Consultants), which is still worth it because of a 10:1 ROI very common with Computer Simulation. 


BUT


Sometimes all you need is a quick tiny model (in a well-scoped project) to give you answers using some limited data and with some underlying assumptions using simulation, which can be somewhat affordable (even affordable for a small business). 


What is a Tiny Model?

I am defining a "Tiny Model" as any Custom Discrete Event Computer Simulation where the entire project timeline can fit under 1 week. 

Typically, these models have 5 or less processes associated with them and use Subject Matter Expert assumptions rather than historical data to provide the variability for these models.  

However, if historical data is already available, found to be reliable, and analysis of this data can be performed in a few hours, you can use a mix of Subject Matter Expert assumptions AND data.

For my models I use ExtendSim software.

It's also typical to have someone experienced in Industrial Engineering or Operations Research build these models for you. 

If interested in learning more about how I can help, you can reach me at Astrozuggs@gmail.com


Why you need Computer Simulation 


Making decisions by "gut" or "feel" is very risky because of the complexity and variability in most operations (it's virtually impossible to get it exactly right) and even if the "gut" decision panned out somewhat…. how do you know it was an optimal decision? How do you know that you didn't leave money on the table? 


Example Simulation Video below


Need Tiny Computer Simulation? Contact me at Astrozuggs@gmail.com 


A great example of how you can create a small Discrete Event Computer Simulation can be found in the book "Healthcare Management Engineering: What Does This Fancy Term Really Mean? The Use of Operations Management Methodology for Quantitative Decision-Making in Healthcare Settings". 

It discusses how traditional management approaches to problem-solving and decision-making might not be the best way to go….and often point you to do the wrong thing, which can be costly or can impact revenue. 


Instead…why not use Computer Simulation! In the book, there is example 2.3.1 "Flu Clinic: Centralized or Separate Locations Example", which uses a walk-in clinic that provides Flu Vaccinations during flu season, which was receiving complaints from patients about the wait time. 


Traditional management approach

A traditional management approach is to have a brainstorming session, at which point, it was decided to split the clinic into 2 smaller clinics and place them in more convenient locations. 


Discrete Event Computer Simulation Setup 


Well…let's make a quick Computer Simulation to test out this change with some basic information that we already know. 


Simulate Patients arriving randomly 


It is explained that for the current large clinic there would be the following:


• 28 patients arrive per hour (i.e., On average, a patient every 2 minutes and 8 seconds) 

• It takes on average 8 minutes to register and give the flu vaccine to the patient 

• There are 4 exam rooms that can be used 

• Clinic is open for 12 hours (7a – 7p) 


And for the future 2 smaller clinics, it was decided to split everything evenly, specifically,


• 14 patients arrive at each clinic per hour 

• It takes on average 8 minutes to register and give the flu vaccine to the patient 

• There are now only 2 exam rooms for each clinic 

• Clinic is open for 12 hours (7a – 7p) 


To simulate 28 patients arriving randomly each hour, the authors use an exponential inter-arrival time of 2.143 minutes between arrivals for the Large Clinic scenario and 14 patients arriving randomly each hour at each small clinic with an inter-arrival time of 4.2857 minutes between arrivals, which I will use as well. 


Simulate how long it takes to get a patient vaccinated


To simulate the registration and administration of the flu vaccine, the authors use an exponential distribution with a mean of 8 minutes, which I will use as well. 


Results 


The results are as follows: 


As expected, (because of the patient complaints), with 1 large clinic the average time in the waiting room was 15 minutes with the longest wait up to 61 minutes AND at the end of the day, there were 11 patients still waiting to be seen…. Ouch!!!! 


How much more efficient were the 2 smaller clinics?


With 2 smaller clinics, the average time in the waiting room increased to 26 minutes with the longest wait up to 98 minutes AND at the end of the day, there were 39 patients still waiting to be seen. 


Wait! Did you catch that? Their decision to make 2 smaller clinics made things worse for their patients!!! How can this be? This doesn't make sense! Why did things get worse? 


Here is why: 


Basically, if you split up resources in a process whose duration times are random, with no other changes, your performance will decrease. 


Because patients arrive randomly, there will be times, for example, at one of the small clinics where both exam rooms are being used and a 3rd patient arrives. This patient will be forced to wait. If this happened at the larger clinic (with 4 exam rooms), they could have been helped in one of the other 2 available rooms. 


So, you see, there was an unintended consequence by splitting up the rooms that made things worse. 


Could you imagine being the decision-maker for these 2 clinics and spending hundreds of thousands if not millions of dollars to build out these 2 clinics only to realize that you made things worse?


Wouldn't it have been better for you to hire someone to build a computer simulation at a fraction of the cost and get it right? 


Run your Simulation multiple times to account for real-world variability


It should be noted that each simulation run will be different than another and as such, you will want to run multiple simulation runs to see the effect of your scenarios over long periods of time. 


I happened to run the above-mentioned scenario 100 times to see how different each run was from the other. 


Some run's results were not as bad as the first one, and a few runs were somewhat close to each other, however, over time, having 2 smaller clinics made things almost 30% worse. 


So, you can see not every Computer Simulation Project needs to be a 3-5 month-long complex project with hundreds of observations and gigabytes worth of data. 


Sometimes you can get enormous benefits from building a Computer Simulation around a small, but well-scoped process with a few pieces of information and not "break the bank" with enormous consulting fees or long project run times.





Saturday, April 24, 2021

COVID-19 Discrete Event Computer Simulation example




How Many COVID-19 Patients Can My Hospital Handle?

Computer Simulation can tell you!!!

Back in 2020 I did a Discrete Event Computer Simulation for HonorHealth to help them understand at what point each of their 6 Hospitals would "Max Out" of COVID-19 patients, why that was, and tell them when each hospital would have to start transferring patients to other hospitals. 

Despite popular belief....ICU's were not always the reason (Although for most Hospitals it is true, but this isn't true for all Hospitals)!!!

This is what makes Discrete Event Computer Simulation so much more powerful than doing an analysis using spreadsheets, or making your best guess.

This Presentation (below) was included in a webinar for Catalysis in March of 2021.



The link to the entire webinar is  https://vimeo.com/525723742