Most analysts can do analysis...but very few can really be proactive in helping customers figure out their needs. Executives routinely complain about analysts being passive on projects, not proactive, or inconsistent in their execution. I think this is a real challenge that needs to be addressed.
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.

written by Declan Chellar, May 04, 2010
written by Countman Knight, May 04, 2010
I would say that, in a lot of cases, standard organizational project management processes do not allow for this. When an analyst is given a project with a clearly constrained scope, and PM processes exist to maintain that scope, it suppresses significant needs analysis and encourages simple requirements analysis.
What really makes things bad is that the original scope definition is often based on a 5-minute needs analysis by some manager or executive who is "just filling in a template" themselves, without devoting sufficient attention to understanding the interaction of scope and value to be delivered by the project.
The combination of the above two factors means the analyst is left analyzing the wrong scope and has no recourse to getting the deviation corrected, unless they have experience in navigating the politics of the organization and enough nerve to not worry about being slammed back into the box they are trying to climb out of.
written by Ganesh Ram Anand, May 05, 2010
Let me not try to reinvent the wheel again! As pointed out your article, it is agreed that BA should play a leadership role and be a leader rather being a Scriber! But, however, this again depends upon the project and the project owner/manager. The BA's should not be given complete power combined with authority to act as a leader.
As rightly pointed by my someone here, analyst should be given freehands right from day 1 discussion with the clients or the so called customers. From there on, it is the BA who should drive the business and not the project managers.
At least guess in India, the opportunity a BA gets in any project is just more than a scriber and not the driver of a project. It's the PM's who decide what needs to be developed,scoped and implemented.
I welcome some thoughts from other BA's specifically from India.
Thanks,
Ganesh
written by Ganesh Ram Anand, May 05, 2010
Please read as ..........The BA's should be given complete power combined with authority to act as a leader. ............
typo error..err..!
written by laith, May 05, 2010
in that case the analyst will be able to be proactive to give the right solution within the clarifiied and clear scope that he/she has been involved from the begining.
finally being a project leader will creates a tension between the BA and the PM, to avoid this the analyst should lead the project from business side to work in parallel with the PM to have a successful project.
written by Balamurugan, May 05, 2010
written by Rita Mockeviciute, May 05, 2010
written by A Kaseno, May 05, 2010
Baby steps to encourage a project to be thought through prior to moving forward is a start. Instead we have too many management teams that have a narrow solution already mapped out and an agenda that it needs to be implemented in a completely unrealistic time line. Call me cynical but I work for a company whose products support other companies and work with BAs from enough firms to know that the short-term profit margin mentality is more the norm than the faction that values long-term planning and goals.
written by Holly Martin, May 07, 2010
Keith Ellis is the Vice President, Marketing at IAG Consulting (
