Time is not a
development system.

An executive announces a project to develop a new product. “You have six months,” he said abruptly. A seasoned yet naive engineer interrupted: “Sir, six months? That seems short.” The executive answered: “Well, that’s not really my problem. That’s what has been communicated to the board. We pay you to find shortcuts and solutions, not to bring problems.”

Six months later, the situation was bad. The project was five months behind schedule, and the core team had not even defined what they wanted. Meeting after meeting brought risks and promises, but no concepts had been presented. Marketing promised something that R&D could not achieve. Engineering and Operations were trying to get a finalized idea to move into production. And the icing on the cake: QARA was not even in the loop.

“The delivery is next month, and you haven’t done anything,” the executive said. Not really.

Executives often overcommit, but when faced with reality, they look for a guilty party. No one looks in the mirror to accept what went wrong. But we’re not going to bash on the executives today. Let’s explore more:

01 What do we want to achieve?

Even as a summary, the story lacks something: What was the project trying to achieve? It was not clear to the executive; it wasn’t going to be clear to the core team either. Whenever you’re asked to lead a project, raise a simple question: How does this look in your head? How do we know we have achieved something “good enough”?

02 Why “six months”?

For some reason, this looks like a magical number. But it isn’t. You can’t force a solution to appear within a set time. Saying a number will not solve any problem. In fact, it can put projects in trouble because some tasks, by their nature, will take more than six months. Whenever you’re given a set time, ask: Have we considered that this task will take at least six months? Be warned that it’ll create tension, but it’s worth it because it forces the team to go back to the first question.

03 “We pay you to find shortcuts and solutions”.

I’m on board with that. But both concepts create tension because they’re contradictory. Shortcuts imply that I will not take enough time to find all the possible solutions that can prevent an issue. Shortcuts are usually an easy way to create friction in all your projects. When faced with this, you can go back to the previous question: Are we aware of the risks that reducing time on these tasks introduces to the project?

A project is successful when it delivers a product and creates value. That’s something project managers like to say, yet it is missing something.

From my experience, projects create value only when people are aligned on what they are trying to create. More than that, projects create value when the people working in them understand what “good enough” means.

How do you do that? Questions.

How? For a moment, forget about products, forget about companies, forget about teams.

Let’s say you want to paint a wall.

Should it be black or white? White.
But what type of white? Oh… I hadn’t thought of that.

Then you go to a paint store and see a palette of white colors. You pick one. You paint your wall. And you end up being happy.

That’s it. You’ve created value.

You didn’t just choose a color. You aligned on what “a good-enough white color” meant before even picking up the brush.