Many IT tender begin in a very traditional way: requirements are gathered, coordinated, and then documented in a requirements specification or service catalog. Bidders prepare their proposals based on this foundation.  During the hearing, the vendors present how they plan to organize the implementation. In my experience, many vendors present an agile implementation concept: with sprints, a backlog, and the usual Scrum rituals. In regular reviews or so-called “show-and-tell” sessions, they present what was implemented in the previous sprint.  At first glance, this sounds like a sensible combination. The client receives a binding price and a defined scope of work. The vendor can still organize the implementation in an agile manner and deliver results on a regular basis.  In practice, however, this gives rise to two paradoxes.  The first concerns the relationship between new requests and the agreed-upon fixed price. The second goes even further: If the scope of work changes significantly during implementation, the question eventually arises as to whether the project being implemented is actually the one for which the competitive bidding took place.  Paradox 1: The more the client learns, the more pressure is put on the fixed price  During a show-and-tell session, features, processes, and user interfaces become clearly visible. This almost inevitably leads to new insights:  That’s exactly what these meetings are for. The client is supposed to provide feedback, and the solution is supposed to improve as a result.  However, a misunderstanding often arises.  The client says, “We could still add that. After all, we’re working in… Continue Reading Requirements Specifications, Fixed Price, Fixed Deadline—and Please, Agile: Two Paradoxes in IT RFP Processes