{"id":6167,"date":"2020-02-26T21:25:55","date_gmt":"2020-02-26T20:25:55","guid":{"rendered":"https:\/\/spiritinprojects.com\/blog\/"},"modified":"2022-07-28T20:09:04","modified_gmt":"2022-07-28T20:09:04","slug":"blog","status":"publish","type":"page","link":"https:\/\/spiritinprojects.com\/en\/blog\/","title":{"rendered":"Blog"},"content":{"rendered":"
\"\"<\/a><\/div>
<\/div>

Requirements\u00a0Specifications, Fixed Price, Fixed Deadline\u2014and\u00a0Please, Agile: Two Paradoxes in IT RFP\u00a0Processes\u00a0<\/span><\/a><\/h2>

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 \u201cshow-and-tell\u201d 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\u2019s 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, \u201cWe could still add that. After all, we\u2019re working in… Continue Reading Requirements\u00a0Specifications, Fixed Price, Fixed Deadline\u2014and\u00a0Please, Agile: Two Paradoxes in IT RFP\u00a0Processes\u00a0<\/span><\/a><\/p>\n

Read more\n<\/path>\n<\/svg><\/span><\/a><\/div>\n<\/div>
<\/footer>
<\/div><\/div>
<\/div>
\"\"<\/a><\/div>
<\/div>

Confusing Features with Benefits Often Leads to Buying the Wrong Software<\/span><\/a><\/h2>

A few years ago, I found myself in a workshop preparing for a major IT procurement process. Within minutes, the flip chart was filling up with requirements: “The software must have an Excel export,”“We need a dashboard,”“The solution must work on mobile devices,”“AI support would also be important,”“We need a mobile app.” After about an… Continue Reading Confusing Features with Benefits Often Leads to Buying the Wrong Software<\/span><\/a><\/p>\n

Read more\n<\/path>\n<\/svg><\/span><\/a><\/div>\n<\/div>
<\/footer>
<\/div><\/div>
<\/div>
\"\"<\/a><\/div>
<\/div>

Agent-Ready: Why AI is the Least of Your Problems \u2013 and Infrastructure is the Biggest Challenge<\/span><\/a><\/h2>

A company wants to introduce a customer service agent. The AI has been selected, the prompt is written, and initial tests with demo data look promising. Then comes the sobering reality: The agent cannot access the ticketing system because there\u2019s no suitable API. The required customer data is scattered across systems that don\u2019t communicate with… Continue Reading Agent-Ready: Why AI is the Least of Your Problems \u2013 and Infrastructure is the Biggest Challenge<\/span><\/a><\/p>\n

Read more\n<\/path>\n<\/svg><\/span><\/a><\/div>\n<\/div>
<\/footer>
<\/div><\/div>
<\/div>