Sham,
You can add a lot of value! It's great that your company is getting key users involved with the vendors consultants. But not all consultant or business analysts are equal. There are several big risks that seems to occur in the majority of projects. These risks are what you should focus on avoiding. I will start with one of them here. Others can jump in for some of the other risks.
One of the biggest risks to a project has to do with how users communicate requirements to analysts, consultants, or developers. The users start giving a bunch of so called requirements. They should be stating the business needs (what), but what they are really communicating is how they think the system will work. If the analyst or consultant is not paying attention, they will document this how as the business requirement. This is NOT the business requirement. Projects that go down the path of developing a system that the user thinks they want, instead of solutioning and designing a system based on basic business needs end up developing a working system that the user is unsatisfied with at best. The developers say, "but that's what you asked for". The users say, "No, what I meant was this other thing. This system isn't doing this or that which I need". At this point the business requirements start to come out. And now the cost to implement that feature will be as much as 100 times more than if it was done right the first time.
To avoid this, everytime the user mentions what they think they need ask youself "WHY". If their initial statement doesn't answer "WHY", then they didn't give you the business requirement.
If you ask them "WHY"and they give you a different answer, you now need to ask "WHY" again. You still may not have the business requirements. The rule of thumb is ask "WHY" 3-5 times for each perceived requirement. By then you have probably undercovered the true need.