A reader asks:

How much is too much information to go over with the users? Would you go over technical details with users in a requirements meeting? Such as, if there were additional requirements pertaining to a technical implementation of updating mail server, changing AD roles/groups retrieved etc…

I would think this would be overkill, but at the same time would not want them to later say, "We were not told about the new server migrations."

Warren’s answer:

Largely, in a requirements meeting, you won't have the details you are concerned about the stakeholders’ understanding. The common purposes of a requirements meeting are: to elicit requirements, to confirm requirements, to resolve any conflicts between requirements, and to acquire requirements sign-off.

To further clarify types of requirements, you generally have 2 overall buckets or requirements:

  • Functional Requirements – these are requirements of how a solution should behave when completed, they identify necessary capabilities, and qualities the solution must have to provide value to the stakeholder.
  • Non-Functional Requirements – These requirements describe stakeholder needs that do not relate to the primary function of the solution. For example: in a software solution security, needs would generally be a non-functional requirement because it doesn’t contribute to the primary purpose of the solution, but is still required.

On occasion, you may require a 3rd bucket of data requirements if you are dealing with large amounts or particularly sensitive data.  Lots of analysts also choose to break the non-functional requirements into smaller more manageable sections like security, and storage requirements sections.

There are a couple of general rules to keep in mind when determining the level of detail you should discuss with any audience.

  • The audience's potential understanding of the detail you are providing - If the audience does not have an in-depth understanding of the technology that you are describing, then trying to teach the details during a meeting will derail your meeting and cause your audience to lose sight of the point you are trying to make.
  • The purpose of the meeting - If you have gathered your audience together to present a solution or design, with the purpose of gaining their support, then, getting into too much detail could cause you to run out of time without you having gained the necessary approval for your solution or design.

In a previous technical project I worked on where the goal was to upgrade the clients operating systems from MS Windows XP to MS Windows 7, the a very technical stakeholder had specific points that they felt were right for the requirements discussion, but were much too detailed.  One particular point was how the group security policies needed to change and the details of how the policies would change.

If we, as a group, had let this discussion get down into the level of detail this particular stakeholder was looking for, we could have been in that room for days.  Instead we had a 5 minute focused discussion about the top level points the stakeholder wanted to address regarding the group security policies, and agreed that the actual details of implementing the changes and its potential effects were much better suited for a further analysis meeting where we could bring in the neccesary subject matter experts.  The 5 minute focused disscusion ended with the group documenting a high-level non-functional security requirement which would drive the detailed discussion about solution design later.

Similarly to the situation I found myself in above, in your example of upgrading a mail server, activities like changing Active Directory roles or groups would fit better as part of the solution design with the project team and technical specialists.  It is ok to briefly address the stakeholders concern if they bring it up, but keep the discussion high level and out of the minute details.

In an effort to provide full disclosure to the project stakeholders, it may be the right decision, when presenting the solution, to list the detail of having to change the Active Directory roles or groups, but it should be presented as a single line item without getting into the detailed discussion about it.

 Any additional thoughts for our reader? How do you draw the line between not enough and too much detail?

Related posts:

  1. STOP! You are being too detail-oriented! I know you have shared this experience with me. You...
  2. How to align stakeholders around project scope without a requirements review and sign-off process A few months ago I posted about how requirements walk-throughs...
  3. How I take meeting notes and facilitate the discussion without driving myself crazy We all know that meeting notes are important. Some of...