Business Analysts’ Attention to Detail

Posted by Rich Crowley in Project Management, Requirements

An old song says that a poker player needs to “know when to hold ‘em and know when to fold ‘em”. A similar maxim for a business analyst might be that you’ve got to “know when to drill down and know when to abstract to a higher level”. Not as poetic or lyrical but true nonetheless. A good business analyst is able to balance between the need for drilling down deeper when they perceive their customer is providing input to business requirements at too high a level and conversely, the analyst also needs to be able to aggregate very granular requirements into something more abstract or generic so that the requirement can be met in as broad as way as possible.

An analyst that is very detail oriented may produce requirements that are very detailed but lack cohesion. Such detailed requirements will often have redundancies in them that are not apparent to the software development team. This will lead to projects that are more expensive than they need to be because the project team will end up building and testing system components that may not be needed. Warning signs for this are analysts that are never quite complete their analysis or documentation and are constantly looking to break scenarios down into further detail or are continually looking for exceptions to rules.

An analyst that is not detail oriented will too often be satisfied to describe a requirement a very high level. This approach will often result in missed requirements because the high level view often ignores exceptional situations that require different treatment than the standard high level scenario requires. This will lead to projects with requirements churn since requirements reviews will result in such details coming out later than they should and then further churn when design / development and testing also produce further questions about the details behind the high level requirement. Warning signs for this are analysts that produce analysis / documentation that has obvious omissions in terms of detail that are visible even to those without detailed understanding of the problem domain. Another warning sign is a that such Analysts will get frustrated with iterations of questions from the stakeholders providing input to the requirements. This level of iteration is often necessary and valuable and if the analyst is frustrated by this, it may imply they don’t see the benefits in it.

If you are PM with analysts on your team exhibiting these attributes, my experience tells me that the detail oriented analyst will produce better results but it is harder to get to those results without providing some form of mentorship. Project stakeholders charged with reviewing requirements from this type of analyst can be your key asset in getting the analyst to stop further analysis on the basis that the current level of detail “good enough”. If your analyst is not detailed oriented, your results will be poor requirements unless you guide/nudge this analyst into more iterations of requirements definition than they might do on their own and use the affected project stakeholders as your means of exerting influence on the analyst to get to a deeper level of detail.