Vous êtes confronté à des promesses logicielles irréalistes de la part des fournisseurs. Comment gérer efficacement les attentes ?

Best is to do a Proof of Concept and apply the software product to an internal use case. It’s a step back but two steps forward later on based on actual evaluation of all the features.

In my experience, a combination of clear communication and proper due diligence is essential. It’s necessary to evaluate the promises made by the vendor against your team’s knowledge, industry standards, and the specifics of the project. Ideally, the vendor should provide case studies, references, or proof of concepts to validate its claims. Finally, the customer must ensure that the vendor fully understands the project’s requirements/needs. Unrealistic promises often stem from a lack of understanding or inaccurate assumptions made by the vendor.

Well, "unrealistic software promises" is a phrase that begins the internal conversations in our heads as essentially adversarial, which will undoubtedly become a self-fulfilling prophecy of a strained relationship. If the delivery of features and/or the timeline of delivery truly appear to be unrealistic, then each story/requirement needs to be addressed with the vendor to determine which of the requirements are already met by core product features, and for those requirements that are not, map out a timeline for delivery of each. This exercise will clarify what really needs to be done and steer the conversation away from impending doubt and consequent friction.

Instead of making assumptions about what "software can fill" from those who don't know what the software or potential automation can do, I would recommend identifying any and all pain points that may be optimized. This could be done before bringing in a 3rd party to start more pointed discussions. This would be an excellent basis for those conversations and potentially reduce discovery calls.

Assessing needs is the most important part to find the perfect fit for your business requirements , but it's also essential to have a forward-looking approach when identifying these needs. In simple terms, you should focus on managing both your current and future business operations with the selected software. However, this doesn't mean using an excavator to prepare a flower pot—it's about finding the right tool for the job. Once you've identified your exact business needs, it's beneficial to develop them into business scenarios or cases. You can then ask the vendor to walk through these scenarios using their software. Based on the results of this walkthrough, you can evaluate the suitability of both the software and the vendor.

I come from a different area where functional and technical requirements are handled differently. It may be beneficial to include an experienced developer in the conversations or even a more techno-functional individual who can pick up on nuances missed by others. This can also lend to composing more pointed questions that may identify overstated promises.

"Always question bold claims from software vendors—request demos, case studies, or proof of concept to ensure their promises are backed by real evidence, keeping your focus on what's realistically achievable."

"Seek references from current customers to verify a vendor’s claims—real-world experiences provide crucial insights into whether their promises hold true."

"Define clear SLAs to ensure vendor accountability—set expectations for performance, support, and remedies to protect your organization if service levels aren't met."

Defining clear SLAs would mean the expectations are clear from either side. Companies can explain to the vendors the expected SLAs like categorization of issues, response levels, availability and so on. It also provides an opportunity for the vendors to clearly set boundaries on what the company can expect. So, both the parties are on the same page on what to expect.

"Plan for scale by understanding how the software will support your business growth—clarify costs, capacity, and performance to ensure it can grow with you without becoming obsolete."

Depending on the complexity and the duration of the project, I have seen various options to de-risk. 1) Parallel run of the old and new software during testing to compare results 2) Parallel run in Production environment for a few months 3) Phased go live with MVP in phase 1

"Manage risk by preparing contingency plans—consider phased implementation or retaining legacy systems to safeguard against potential software shortcomings."