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
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.
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”.
Steven Allen is a software developer with over ten years of experience.
He's seen many companies fail. Don't be one of them.