As others have commented, but not directly answered, you can say it is a case of moving goalposts.
move the goalposts
To change the rules while someone is trying to do something in order to make it more difficult for them.
In addition to another answer of will-o-the-wisp, there is also a pipe dream, which while not directly giving the exact connotations you're asking for, does give the idea of endless pursuit of something that can never be realized.
pipe dream, noun
a hope, wish, or dream that is impossible to achieve or not practical
Putting them together, you could say something like:
"Because you keep moving the goalposts every time we make any progress, I'm afraid that getting this project done has become nothing more than a pipe dream."
In the case where there is no identifiable source intentionally moving the goalposts, you can say it in a more passive voice to indicate that, despite no person actively doing it, the effective results are tantamount to the same thing:
"This situation is no different from one where the goalposts keep moving, and I'm afraid that getting this project done has become nothing more than a pipe dream."
or
"It feels like the goalposts keep moving, and … ."
Addendum
I re-read your question and have some off-topic-for-English-Language-but-on-topic-for-your-situation comments for you:
Disruptive technologies are more disruptive the earlier they're introduced. They're successful not because they beat their predecessors in all areas, nor because they're perfectly polished, but because they fill an unrealized need. An unreleased software product can't meet any needs.
The process of delivering incremental improvements in software is absolutely crucial to saving money and making the best product possible. Without people actually using it and being in a position to find out in the real world whether it meets needs correctly, what parts are missing, and what parts aren't even needed, you're almost guaranteed to build the wrong thing. Study the agile software development lifecycle and its philosophies; you will find that the primary benefit of iterative improvement is early feedback.
Speaking of early feedback, it's your users who give the best feedback—never in-house resources. There's always someone who doesn't need all the features, and is willing to try a new product that does certain things better without having all the bells and whistles. Get users involved in the development process and you've got, for free, what would normally cost big bucks to pay for in-house as a focus group or something! You want people to bang on your product as early as possible to reduce the cost of fixing stuff that's wrong with it or could be done better--especially if the change is to key architectural aspects that permeate the entire product and would be more painful to change later than earlier.
No comments:
Post a Comment