In my new role as a Director of Project Management at Legal Science, I have the responsibility of setting up our project management practices and helping our customers manage their litigation support projects.  A few pain points that I hear often from our customers are the ambiguity of requirements, the short duration of projects, and the fast pace of litigation support projects.  In fact, many have given up on requirements gathering and accept the fact that 50% of their projects will be over budget, low quality, or over schedule.

However, all is not lost.  Proper requirements gathering can set a project in the right course from the very beginning.  Unfortunately, requirements gathering is a tricky process fraught with red herrings.  Sometimes you interview a stakeholder and write down exactly what is said only to find out that is not what they intended.

The trick here is to find out what the client "intends to do with the product" not how they think the project should be done.  This is sometimes called the "business requirements."  Many vendors in  the litigation support space jump right into checklists with options for stapling papers this way or that way.  But in doing so, they miss the more important point of what the customer intends to do with the end result of the project.  They are trying to find out the "technical requirements" before they even understand why they are undertaking a project.

Here is my list of best practices for gathering requirements for small projects:

• Use the following techniques to solicit requirements as fully as possible:
  • Interviews - Solicit requirements from project stakeholders.  However, take into account each person's bias and background.  Use context-free questions, ones that do not favor one answer over another, to avoid bias
  • Document Analysis - Any documentation generated at the beginning of a project is a treasure trove for requirements gathering.  These will give you a good foundation on which to build upon
  • Brainstorming - Sometimes the stakeholder is not exactly sure what the requirements should be.  In this case, a brainstorming session will help flesh out ideas and potential uses of the end product
• Establish a process for evaluating and controlling changes to requirements.  This is not to discourage changes, but to fully understand the impact of a change and notify all of the appropriate parties of changes in scope
• Prioritize!  Some requirements are more important than others, if this is so, state it explicitly.  Nothing is worse than getting a project late because a minor requirement was slowing down important work
• Consider an incremental approach when requirements are volatile.  You don't have to do the entire project at once
• Distribute requirements to all parties of the project.  This way everyone knows what needs to be done and why.  This is especially important so that the stakeholders see and verify your understanding of the project
• Check your final deliverables against the requirements

If you have any horror stories or best practices regarding requirements gathering, leave a comment!

Good follow up post by Harrison Flakker at Select Notes From Caselawg entitled "How to gather requirements from an attorney walking backwards"