A dialogue is a conversation between to or more people. A conversation implies that more than one person (or parties) can do some talking. If it were just one person talking it would simply be a lecture.
When dealing with projects it’s been often said “You can have it done fast, you can have it done cheap, you can have it done right. Pick two.” In software this holds true as well. In more concrete terms in programming “You can time-box the solution, you can add or remove people working on it, or you can have a viable long-term design that can grow to meet future needs. Pick two.”
For the business to try to control all three aspects of the solution is a losing proposition. Which is the thing you want to give up? And you must decide. Are you going to give up quality? Time to market? Delay other projects? It’s a hard decision, but in a world where you’re not Google or Microsoft, it’s one that must be made. (Even those giants need to make these choices too believe it or not)
Fortunately there is something that can be done. If you are on the business side of the equation, you can change where the goalpost stands. By engaging in a productive dialogue with the folks on the tech side you can come to a common understanding of what can be built with the time alloted. Coming to the table not willing to budge on your original position isn’t productive. “I already told you what I want, now make it happen” isn’t a good way to win.
Something to keep in mind — and this goes for everyone involved — is that everyone sitting at the table is on the same team. Everyone wants things to succeed. Lets all work together as a team and make the choices that have the best choice of winning.