Rocket science, by any other name, would be just as hard

Unfortunately, the reality of a project doesn’t get easier just because it’s called something else

I’ve been in this scenario more than a few times in my career:

Product owner: Hey, we wanna do this Really Hard Thing™, how hard will it be?

Me: It will be really hard, but it can be done

Product owner: What if we call it Really Easy?

Me: Sadly, calling it something else won’t change what you’re doing

Product owner: Okay, what about if we paint it blue?

Me: Unfortunately, the color of the paint isn’t what makes it difficult

Product owner: I think I understand where you’re coming from. We won’t paint it at all, that will make it easier

Me: …..

There’s a phrase I’ve heard that encapsulates this whole problem – “if your project requires building a launch vehicle, then by definition your project is rocket science”. It means that, no matter how you dance around it, if your project requires a thing, you gotta get that thing, even if it’s really difficult. I’ve seen and heard many attempts to dress a project up to get away from core requirements that were really difficult. None of the tweaks or semantic games changed the core requirements. That didn’t stop a lot of time being spent trying to “negotiate” the difficulty.

The worst example was a single-page web app. Of course, it wasn’t called a web app - it was called “landing pages”. These landing pages needed the same functionality of a web app. They needed to handle routing, authentication, API calls, fancy javascript widgets, etc - it was a single-page web app. But by calling the project “several landing pages”, the product owner insisted it had to be easier – and less expensive – than a single-page web app.

Unfortunately, projects don’t work that way. The difficulty is determined by what must be done, not by the language used to describe it. If you need to get a payload into orbit, you need rocket science - even if you call it “forgetting to hit the ground”.