Done well, business analysis is a leadership role; one that actively impacts the speed and outcomes of IT development activity. In this leadership role, analysts have the skills to proactively lead stakeholder discussion and create information in a format that communicates well to both business and technology about business needs. Analysts are playing the role of bridging the gap between business and technology.
Without the right processes, techniques, skills, organization, technology and deliverables, analysts default to small 'a' analysis. This is a reactive role, taking in projects and generating activity without momentum. The clarity of need and outcome is simply not emerging rapidly enough, or with sufficient consensus, or with the right usability of deliverables. Projects are more difficult with small 'a' analysts on your team. Work may be getting done, stuff is happening, but how much momentum is really being generated? How much do you need to rework the deliverables of those people? How many times are you getting the right blocks of content filled in on templates, but very little being said? Know people like this?
Am I really being too harsh? To me it comes back to the role and expectations, and I believe analysts provide LEADERSHIP. Part of this leadership value is that analysts be a strong source of momentum. This means you can't have situations like the above.
OK, so you're looking around your organization seeing lots of what I've coined small 'a' analysts. What do you do?
There are a few short term tactics you can employ to refocus the value delivered by analysts, and one long term tactic. In both cases YOU, the manager, need to own the situation you've created for yourself.
The short term fix is to focus on 'elicitation skills. They're the methods and practices (like facilitation) of engaging stakeholders and asking the right questions at the right time to extract the information needed to determine business need. This has immediate benefits in the focus of analysts and their abilities to engage stakeholders.
You can also implement a short term fix about quality standards: getting away from defining the completion of the template as the standard, and going toward setting clear guidelines on the fidelity of information in the template.
Finally the short term fix could be to look at the services that your analysts provide to the organization and change the intake process for new projects that want to use these services. It can have a profound effect if the requirements management team knows how to quickly understand the status of a project, and create more clearly defined work packages for their analyst teams from this understanding.
In the longer term, the management group has to assess requirements definition and management maturity, and set out a plan for improving this maturity level. It's the only way to get stickiness on change. An organization cannot hope to make substantive improvement by focusing only on one capability: skills (continuously training), process (continuously redesigning or enforcing a process), techniques (being militant about the use of certain standards), deliverables (getting people yet another template), organization (going from a requirements center of excellence to a center of practice), and technology (roll out something else... again!).
Business analyst management needs to look across all capability areas and systematically improve the consistency of the organization across these areas. The value of making this improvement is also extreme, doubling most performance metrics on projects.
Why do I get passionate about this? Seventy five percent of organizations last surveyed were poor at doing requirements...
To really meet business need, analysts need to be leaders.