There are a number of reasons for this to happen such as
- the business priorities might change
- the world might change
- new knowledge might become available
Don't be afraid to change your plans part way through a project. Ensure that there are provisions for change from the start. If the supplier is quoting a fixed price for a known piece of work, it will be difficult to change focus part way through without tearing up initial agreements and starting again. If you engage on the basis of effort rather than a fixed deliverable, you are more free to pivot and change your focus along the way with less negative impact.
The way ahead is full of unknowns. Nobody has done exactly what you're trying to do before - this is the first time this has ever happened! Similar things have happened before - the same destination maybe, but different people, and different starting point. So this is brand new, so let's remove as many of the unknowns as possible. (As they say in flying circles, change one thing at a time and your risk of having an accident is small. Change more than one thing at a time and the risk massively increases.)
Choosing a supplier and a team that has done similar things before minimises the risk as the way ahead becomes less of a surprise and more of a known quantity.
Block out the steps needed to get from here to there in as much detail as you can. The BA can do this with your guidance. This might be a list of deliverables, and once complete, the work is finished (in truth we find products are never 'finished', there's always the desire to add more features or make UI/UX changes to improve the existing experience).
Once these steps are known, you will be able to gauge whether you're on track or way off course.
Check progress as you travel towards your destination. Verify whether your product meets the acceptance criteria you have set before you mark it as complete and move on to other things.
If you want a Mercedes, it's much simpler to build something that looks like a Mercedes without all the engineering under the bonnet - i.e. a model. If you can look at the car, walk around it, sit in it even, you'll get a great feel for what the actual product would be like to own. Same with software - if you can walk through a mock-up that looks and behaves exactly like the finished product, you'll be much more able to evaluate whether the current design is fit for purpose. Developers (myself included) are also notoriously poor at making good UI/UX decisions so let's not leave it to them!
Build a model of the software, before building the actual software.
Get feedback from whoever is expected to use the product. Its all too easy to make huge assumptions about how Users will behave, especially if you know a system inside out. Users who are fresh to a new platform look for visual cues about how to use the software and also based on their experience with other systems. If you put your target users in front of your new system and they don't know what to do, you're in trouble.
Get feedback as early as possible, listen to it and make changes where necessary.