As business analysts, we’re trained to help business stakeholders prioritize projects and requirements within projects to help ensure that the right things are done in the right order to optimize the return on their investment. I think it’s important that we take our own advice when it comes to our analysis efforts and keep ROI (Return on Investment) at front of mind.
Assuming our raison d’être as BA’s is to help stakeholders reach a shared understanding of what is required for a successful product, what are the things we can do to create that understanding at the lowest cost in time and effort?
And I’m not suggesting we skimp or not take proper time to do the analysis, only that we be smart about it. One of the reasons traditional delivery methodologies get a bad rap is that they are so regimented and template/checklist-bound. Or, maybe it’s that analysts (and other project team members) interpret them as requiring the regimentation and checklists – but I digress.
In any case, you do have to do the analysis. You just have to be expert enough to understand what models and methods – among those available to you – give you the best return on your investment for a particular project and its accompanying set of circumstances.
A few examples:
If we are producing a document that no one reads, the return is probably not worth the investment of time and effort.
Further, if we are producing a document that everyone reads and approves, but that doesn’t contribute directly to helping get product out the door, not only is our time and effort wasted, but so is that of everyone who takes the time to review it.
If we are spending extra time on paperwork just to make sure that every section of a document has at least “something” in it, the return is probably not worth the investment of time and effort.
There are just so many types of requirements, so many types of models, so many tools at an analyst’s disposal that one can easily get caught up in doing things to be doing them – as part of a process/template, because they worked well enough another time, or because “that’s what we’ve always done.”
When focusing on “the process” or “the checklist”, one can easily forget that the value we provide is not in producing documents, but in clearing the path that leads to stakeholder alignment through shared understanding.
There are lots of “good things” that we could do, that may be helpful to someone, somewhere, sometime. The trick is to learn to identify and focus on the “best things” – the things that will move this particular effort furthest forward with an acceptable level of risk for the time and effort invested.
I say “at an acceptable level of risk,” because analysis paralysis almost always results from well-intentioned project teams doing “good things” well past the point of diminishing returns in a futile attempt to entirely remove risk of the unknown from the equation.
Before diving right in and “doing,” I find that it’s a good idea to assess the available tools in my BA toolbox – by that, I mean the collection of documents, models, methods, tips and tricks – basically the things that I can contribute that could help sharpen that shared vision of product/project success for my stakeholders.
It isn’t practical to use them all for every project, so I have to decide which tools will get me the farthest toward that shared understanding at the smallest cost. Once I have a pretty good idea on how I think I can add value, I work with my project team members to make sure they understand and are comfortable with those tools/models/etc. Once the team is on board, off we go – readjusting as needed when circumstances change.
So, here are a few questions for your consideration. An answer of “yes” MAY indicate an opportunity for you to modify your activities to improve your allocation of time and effort to improve ROI.
Are you doing tasks/work just to fill out a template, or a generic project plan?
Do you use the very same modeling techniques, with no variance, for every project?
Do you get the sense that your documents aren’t being fully read or used to drive downstream activity?
Do your analysis efforts seem to take longer than you think they should?
Does what you’re working on contribute directly to creating a shared vision among stakeholders of what is required for success on the given project/product?
So, when is the last time you considered the ROI for your analysis efforts? And what are you doing to improve it?
Comments