Comments on: How Do I Get Feedback on a Requirements Document Without Sounding Too Demanding?

By: Charu

Charu — Wed, 14 Mar 2012 23:43:49 +0000

Great article Laura, as you have always done!

My preference is always to:

First start with a summary – a bullet points list in an email after the first one or two rounds of requirements discussion to give the confidence to stakeholders that I am on the right track and if I am not, it gets highlighted upfront and ASAP.

Then to circulate the same summary to the technical team to ensure the feasibility of a functional solution so we know upfront of architectural limitations that may or may not exist and so the requirements can also be prioritised properly (considering technical feasibility and complexity).

Then when I am ready with the full requirements document, I usually fix at least a 2 hour session with all the stakeholders, use a datashow and walk through the requirements document. At this session, I ensure that I am not focussed on wording corections but the actual requirements.

Implement the changes that may come out of the walkthrough and then circulate the document for review and approval. By this time, the stake holders will be by far familar with the vast majority (if not full) of the contents and will feel like reading it since it shoudl nto take too long.

Also, a functional detailed requirement has 2 sets of audiences – the business stakeholders and the technical team implementing the solution. If we ensure that the document first caters to the business stakeholders (after ensuring technical feasibility), other extra notes that may be required specifically for the technical team may be added when circulating to the technical team.

Well, my 2cents worth …..and again, it all depends on the organisation culture, the nature and priority of the project. If it is a large project, splitting the document to address specific parts will also reduce the size and ensure that everyone reads it. With agile methodologies, describing as you go will ensure that parts of the requirements are approved as we move forward.

By: Tonya Smith

Tonya Smith — Sat, 10 Mar 2012 18:02:49 +0000

I have always found that providing a clear DUE DATE of when the approval or requested changes are needed is an extremely effective way to get timely feedback. People work off of deadlines and due dates and plan their days accordingly. SO if they see a due date on their calendar they are more likely to focus on that task in a more timely fashion or dedicate the time to it that day if not before.

By: Abdemanaf

Abdemanaf — Wed, 07 Mar 2012 21:00:51 +0000

Laura – This article is a blessing in disguise for BA’s like me! How many times do we face this situation. Thanks.

By: Tony Heap

Tony Heap — Wed, 07 Mar 2012 07:24:15 +0000

In reply to Laura Brandenburg.

We were proceeding at risk, much to the nervousness of the project manager, but he was pursuaded by me because I felt that the stakeholder relationship was good and the risk was therefore low.

As others have said, getting feedback on requirements off-line is, in my experience, really not the best way to proceed – much better to have a face-to-face and use the off-line review/sign-off as a double-check.

By: Laura Brandenburg

Laura Brandenburg — Tue, 06 Mar 2012 20:43:34 +0000

In reply to Tony Heap. OK, Tony, I have to ask. Was sign-off really important if you could proceed anyway?