Devil in the Details

  Governance   Requirements Management   ProjectsAtWork  

When gathering requirements, many participants will be eager to dive into very specific user needs. But what is the right level of detail when it comes to business requirements? What are the risks of too much or too little information?

Project sponsors are not measured as successful based on the quality of their project charters, nor the number of requirements. They are deemed successful on the implementation of their effort and their positive contribution to the company within a particular timeframe. Therefore, they are focused on getting results fast, and sometimes they lose sight of the greater responsibility to make sure the effort aligns with company objectives and other projects across the enterprise.

That, of course, is where business requirements come into play. Business requirements are used as an input meant to help key stakeholders assess the objectives, risks and costs for a project in order to deem its worthiness against others.

But what is the right level of detail when it comes to business requirements? This question is one of the most common issues that arise with my team’s business analysts. They know that there is a price to pay for capturing too much detail, but often times feel pressure from project sponsors to take the analysis deeper.

I am a collaborative person. ”The more, the merrier” is a favorite phrase — but not…

Please log in or sign up below to read the rest of the article.