The first step in any significant software procurement is to assure there is a clear definition of the business problem being solved. If you don’t know what you want, you aren’t prepared to negotiate for it, so you'll end up with a system or tool that isn't what you need—and you'll likely be disappointed at delivery.

Negotiation occurs on a spectrum, and different tactics apply in different situations. For instance, you’d treat a one-time transaction differently from an ongoing client relationship you want to nurture. Have you developed effective negotiating skills? Are you applying negotiating skills appropriate for the context?

There are people who will use "being agile" to justify software engineering practices that could be perceived as lazy or even bad. The specifications are going to change, they say, so it would be a waste to engineer more to begin with than the minimum viable product. What's expediency and what's just poor practice?