Elias is a commercial HVAC technician who specializes in industrial ventilation systems. Last month, he finished a contract for a three-story medical clinic in a suburb of Chicago. He installed four massive rooftop units, miles of galvanized ductwork, and a sophisticated control panel that looked like the stickpit of a jet.

On the final day of the contract, Elias ran his pressure tests. The gauges held steady. He checked the airflow at each vent with a digital anemometer. The numbers matched the blueprints exactly. He presented his final report to the clinic’s board of directors, they signed his completion certificate, and a small reception was held with coffee and donuts. The project was officially logged as a 100% success. It finished on time and $4,000 under budget.

The Blueprints Were Perfect

Three weeks later, the head of oncology called. The air was moving, but it was moving in a way that created a localized low-frequency hum in the consultation rooms. It was a sound at the very edge of human hearing, a rhythmic throb that caused headaches and nausea in patients within thirty minutes.

The blueprints were perfect. The installation was flawless. The project was finished. But the building was, for its intended purpose, broken.

This is the fundamental deception of the modern project. In corporate environments, we have become experts at the “closure ceremony.” We celebrate the milestone because the milestone is visible, punchable into a spreadsheet, and tied to a bonus structure.

We celebrate the fact that we stopped working on the thing. We rarely stop to ask if the thing we stopped working on actually does what we promised it would do during the pitch meeting.

In my work as a researcher of dark patterns, I have noticed that this behavior mirrors the way we interact with software. We are conditioned to value the “Check” more than the “Effect.” We want the progress bar to reach the end. Once it reaches 100%, our brains release a small hit of dopamine, and we move to the next task. We have been trained to treat completion as a synonym for competence.

The August Disaster

This is a dangerous habit in the world of IT infrastructure. Consider a standard “Remote Work Enablement” project. A medium-sized firm decides it needs to modernize its server environment to allow eighty employees to work from home.

The project plan is drafted. It involves hardware procurement, firewall configuration, and the acquisition of Remote Desktop Services licenses. The project manager tracks the days. The engineers install the Windows Server 2022 instances. The licenses are “accounted for” in a budget line item. On the final day of the fiscal quarter, the project manager sends an email to the entire company. He announces that the remote portal is live. There is a “Go-Live” party with pizza.

The project is considered a success because the date on the calendar was met. However, no one actually checked if the licensing server was properly communicating with the active directory. No one verified if the grace period-that 120-day window Microsoft gives you before the server starts kicking users off-was actually replaced by permanent keys.

The project “finished” in April. The disaster happens in August.

We spend millions of dollars to build staircases that people trip on, or ventilation systems that give patients headaches, or server environments that are one Tuesday morning away from a total lockout.

The problem is that effectiveness is diffuse. It is quiet. It is late. If you install a new licensing system, the “success” of that system is the total lack of phone calls to the help desk four months from now. You cannot celebrate a lack of phone calls with a cake in the boardroom. You cannot put “Nobody complained in October” as a headline on your LinkedIn profile.

So, we celebrate the delivery of the box instead of the utility of the contents.

Transaction vs. Ceremony

I recently spent an afternoon comparing prices of identical items across four different enterprise software vendors. I wasn’t looking for the cheapest price; I was looking for the most honest one. Most of the vendors wanted me to enter a “consultation phase.” They wanted to wrap the simple act of buying a license in a “deployment project.”

They wanted to turn a transaction into a ceremony. They do this because ceremonies are billable. If they can turn a 15-minute task into a three-week project, they can claim a “successful delivery” at the end.

In the specific realm of Windows Server environments, the gap between “Project Success” and “Operational Reality” is often found in the Remote Desktop Services Client Access Licenses (RDS CALs). A project team might “finish” a server migration, but they often leave the licensing as a “day-two” task.

They rely on the grace period. They assume someone else will handle the activation. They treat the license as a clerical detail rather than the literal fuel the server requires to run. When that grace period finally expires, the project team is usually long gone. The project manager is working on a new “success” in a different department.

The engineer who set up the server has moved to a different firm. The business is left with a “successful” project that no longer functions. This is where the friction of the traditional corporate procurement model fails.

The Affront to Project Management

The actual solution to a problem should not be a months-long ceremony. It should be a precise intervention. If you need eighty people to have remote access, the success isn’t the meeting about the access; it’s the 214-character key that makes the access permanent.

This is why a specialized outlet like the

RDS CAL Store

is an affront to the traditional project manager. It removes the need for the ceremony. It provides the license keys in roughly 15 minutes. It turns a “Project Milestone” into a simple, verifiable transaction.

By the time the project manager would have scheduled the first “Licensing Strategy Meeting,” a technician using a dedicated store would have already activated the server, backed up the keys, and moved on to actual work.

The “Project” is an institutional mask. It hides the fact that we often don’t know what we are doing, so we focus on the schedule to prove we are doing something. Institutions measure the events they control. They control the date of the meeting. They control the budget of the pizza. They control the wording of the final report.

They do not control the way a user feels when the server denies their connection at 8:00 AM on a Monday. Because they do not control that outcome, they choose not to measure it. They define success as the moment they are allowed to stop caring.

We are sealing the tomb. If the ventilation hums, if the stairs are uneven, if the licenses were never actually installed-that is now an “operational issue.” It is no longer a “project failure.” By shifting the nomenclature, we protect the reputation of the people who finished the work, while abandoning the people who have to live with it.

“I had finished the project, but I had not solved the problem.”

– The Researcher’s Reflection

I have made this mistake myself. I once spent six months designing a data collection system for a non-profit. I was so focused on the data architecture and the user interface that I never checked if the field workers had reliable internet access to upload the data. At the end of the six months, I presented a beautiful, functional dashboard.

The board was thrilled. They gave me a glowing recommendation. The project was a “success.” Two months later, I found out that not a single record had been uploaded because the rural offices were still using 3G hotspots that timed out during the sync process.

Success is Boring

We need to become more comfortable with the “unfinished” feeling. We need to stop equating a date on a calendar with a victory for the business. A project shouldn’t be considered successful when it terminates. It should be considered successful when it has been running, unnoticed and uncomplained about, for a full year.

True success is boring. It is the silence in the oncology ward because the air is moving correctly. It is the employee logging into their remote desktop in August without even knowing that a “project” ever took place in April.

If you are an IT lead, look at your “completed” list from the last year. How many of those successes are currently generating “operational issues”? How many of those “finished” servers are still running on a countdown timer? We have to stop celebrating the act of walking away. We have to start celebrating the act of staying functional.

The next time someone offers you a donut to celebrate a project closure, ask to see the license activation screen first. Ask to hear the silence in the room. If they can’t show you the utility, the cake is just a distraction from the fact that the work isn’t actually done.

It’s just stopped. And in the world of infrastructure, stopping is often the beginning of the real failure.