Please login or join to subscribe to this thread
You better find a common ground by applying negotiation and communication skills. Having said that the problem should be clarified and understood by all interested parties. Making them to sign, does not necessarily mean that you will not face the same issues in future.
If the context is software or knowledge-based solution development then the best answer is certainly NOT to ask the customer to sign anything. What matters for a successful outcome is that you maximise customer collaboration and you have an effective way of adapting to changes throughout the entire engagement.
Sign-off can too easily become an obstacle to collaboration and being adaptive because of course it's so often impossible to anticipate every detail in advance. If you really must do it then make sure you also agree with the customer how to manage future changes after the sign-off. If you have an agile way of responding to future changes then the sign-off itself should become a less significant problem and you will have a much easier conversation with your customer.
Any realistic approach to a complex problem ought to be responsive to changing needs and unexpected developments. This is true for building construction, manufacturing, software, business process or pretty much anything else.
If by "waterfall" you mean "we will not allow any changes no matter how incorrect the starting assumptions or estimates turn out to be" then you are surely setting yourself up for a very difficult and short-lived relationship with your customer.
You say you want to add other requirements gradually in future so I suggest you will need to rethink your operating model.
It sounds like the root of the problem is in change management. Traditional "waterfall" delivery does not preclude changes. The customer may learn more about what they need as the project evolves. That happens all the time. Before accepting changes, you need to understand the impact to the project particularly with respect to cost and flow.
Sometimes changes are nearly invisible to cost and flow, such as where features A and B are interchangeable and you just need to incorporate them before you've already invested in one. Sometimes the change needs to go through a rigorous pricing and offerability process or you're just giving expensive things away for free.
If you have already incorporated many customer driven changes into your plan, one approach to getting them to approve of the work order is to clearly differentiate what was part of the original agreement, what changes were required your own team learned more about the detailed work statement, and what changes were directed by the client. Then you can explain how their change requests significantly altered the project outcome.
Why would this be an concern if the BRD is not signed off yet? Until you have an approved BRD, the scope baseline is still "open" so changes should be fine so long as the customer is aware of the implications to product/service/result delivery re: cost/quality/schedule/resources.
Once the BRD has been signed off, then subsequent changes would be handled through change control.
The only value in having an incomplete BRD signed off is to capture historical decisions. Make sure to identify the as of date in the BRD.
Signed off to be taken with mentioning date and in future for extra assignment/requirement take revised BRD.
Please login or join to reply