Why Your Productivity Tools Are Lying to You

One

In a project management class, the instructor explained Gantt charts.

"The horizontal axis is time, the vertical axis lists tasks. The length of each bar represents duration. Dependencies between tasks are shown with arrows."

Twenty‑eight of the thirty students in the room took photos of the screen. On it was a flawless, multicolored Gantt chart with no rough edges.

The homework was to use a Gantt chart to plan the project they were currently working on.

In the assignment Li Ming submitted, the first task was labeled "Requirements Confirmation," with a duration of three days.

The instructor gave it a checkmark.

In reality, requirements confirmation for his project took seven meetings. At the first meeting, the client said, "We need a system that automatically generates reports." At the second, "The reports should have ten templates." At the third, "The template colors must match our brand identity." At the fourth, the brand color changed from blue to green. At the fifth, the green was too dark. At the sixth, they decided ten templates weren't needed—three would do. At the seventh, for half the fields in those three templates, the client wasn't even sure they wanted them.

During those three days, Li Ming did only one thing: revise PowerPoint slides.

On the evening after the seventh meeting, he shut down his computer. As the screen went dark, he saw his own face reflected in it. No expression. He stared at that face for a few seconds, then closed the laptop.

On his Gantt chart, the "Requirements Confirmation" bar still showed three days. He couldn't be bothered to change it.

Over the course of the semester, the skill Li Ming mastered most thoroughly was turning completed task bars gray. Green meant in progress, red meant delayed. On his chart, there were twelve green bars—eternally in progress, eternally never turning gray.

Two

At a post‑mortem meeting, Li Ming's manager said, "This project had too many requirement changes. We need to establish a change‑control process."

Everyone nodded.

The following month, the process was set up. Changes now required a form, a sign‑off from the business side, a man‑hour estimate from the technical lead, and a reschedule by the project manager.

Li Ming's new project soon ran into another change request. The client said, "We'd like to add a push‑notification feature."

Li Ming spent forty minutes filling out the change‑control form. Getting the business side to sign off took two days. The technical lead estimated eight working days. The project manager scheduled it for six weeks out.

The client waited two days and then said, "Never mind, forget it."

Li Ming deleted that form. The recycle bin icon on his desktop showed "1 item." He wasn't sure if that counted as a project.

Another post‑mortem was held. Someone said, "The change‑approval process is too slow—it kills innovation."

The manager said, "Then let's shorten it and respond faster."

Li Ming said nothing. There was a thought in his head, but he kept it to himself.

That thought was: The problem isn't the length of the process. The problem is that the client doesn't know what they want in the first place. No process can fix "not knowing what you want."

He didn't say it, because saying it wouldn't have helped. The post‑mortem was forty minutes long: review goals, analyze gaps, make improvement plans. "Do nothing" wasn't on the agenda.

Three

Li Ming later developed a habit.

Whenever he received a new request, instead of asking "What do you want?" he asked, "What's currently giving you the biggest headache?"

A client said, "We have to produce a monthly business analysis report, and every time we manually export the data, it takes three hours."

Li Ming said, "Okay."

He didn't draw a Gantt chart. He didn't set up a change‑control process. He spent one day writing a script to automate the data export.

The next day, he showed the script to the client's operations specialist—a young woman. She stared at the screen for ten seconds, then clicked run. Three hours of work became fifteen seconds.

She looked up at Li Ming and said, "That's… it?"

Li Ming said, "That's it."

That project never had a post‑mortem. The client didn't write a thank‑you letter. On Li Ming's quarterly review, the task was recorded as "Completed automated data‑retrieval request," followed by a "satisfactory" rating.

But that afternoon, as Li Ming walked out of the client's office, he paused in the hallway. At the end of the corridor was a window, and outside it stood a Chinese parasol tree. Its leaves were flipping over and back in the wind. Sunlight filtered through the gaps, scattering on the floor tiles in patches.

He stood there for a few seconds, then walked on.

He didn't take a photo. He didn't post it on social media.

Four

Li Ming never really "solved" the problem—he just shifted it.

A Gantt chart can't fix changing requirements: it predicts everything, but in reality you only come to understand things as you go along.

A change‑control process can't fix drifting requirements, because it tries to make the client certain rather than accepting that the client is inherently uncertain—and designing a way to work with that.

What Li Ming actually solved was the operational specialist's specific pain: manually exporting data for three hours. That problem was small enough, concrete enough, and could be fixed with an afternoon of scripting. He didn't try to resolve the client's strategic ambiguity. He didn't try to fix the company's project‑management maturity. He simply addressed the physical toll of a young woman clicking repeatedly for three hours.

He did the right thing, but he probably didn't realize it himself.

Five

That script later spread.

People from other departments came and asked, "Can you write one for us too?" Li Ming said, "Send me your table structure." That took another afternoon.

He didn't get a promotion for it. On his timesheets, those two afternoons were logged as "requirement discussion" and "solution design"—because the company's time‑tracking system didn't have a category for "helping others save time."

But one thing did change.

One afternoon two months later, Li Ming was revising a PowerPoint at his desk. It was a big project—this was the seventeenth revision. He stared at the screen, the cursor blinking on a single line for twenty seconds. He didn't know how to rephrase it.

Then his phone lit up. It was a message from that operations specialist:

"Mr. Li, my colleague used that script you wrote—he said it works great. Our department is launching a new report next week, and the data source is still the same database. Would you have time to take a look when it comes up?"

Li Ming read the message and typed two characters in reply:

"Sure."

He put down the phone. The cursor was still blinking on that line. He stared at it for a moment, then deleted the entire line and retyped something much simpler.

The seventeenth revision of the PowerPoint was finally done.

When he shut down his computer, the leaves on the parasol tree outside the window had mostly fallen. Autumn had arrived.