Innovating Requirements in the Office
This post originally appeared July 19, 2011 on BetterProjects.net.
Today we are going to discuss the work of a business analyst. Having been doing this for a decade now, I have to say, in most ways, the job really hasn’t changed. People have problems or have recognized opportunities, they bring these to me and expect miracles to be done, all before lunchtime. Sure, the last decade has seen my accuracy in requirements elicitation and analysis increase dramatically (I still shudder at some of those early requirements) along with my ability to document those requirements and relate them back to my stakeholders.
But that, frankly, isn’t innovation. That’s process improvement. This isn’t a bad thing in and of itself, but it has its limits. If it takes me 2 weeks to elicit requirements for a medium sized project, with enough business and technical knowledge, I could maybe shave a few days off that timeframe, but its not likely I could decrease it to mere hours. There are just too many things outside my own control to make that happen.
Similarly, given enough knowledge and forethought, I could probably increase my accuracy in requirements analysis several percentage points. This suffers from the law of diminishing returns; the more accurate I want to get, the longer its likely to take me to get there. At some point, its probably better to go with what we know now and adjust later than it is to hold up resources who are waiting on work.
So how do I innovate in my job as a business analyst?
First, you have to realize that you do need to innovate. Staying the same really isn’t an option. I’m not suggesting you go out and create a whole new methodology, but maybe its time to add into the mix segments from other methodologies into your own personal work. For example, even though you may work in an organization that is purely waterfall, maybe your run your tasks in an agile manner. Maybe you pick a backlog of tasks for the next 2 weeks, create a stack of those and then have your own, personal stand-up at your desk every morning. Work through the items, see what you’ve accomplished, decide on what you’ll do today and figure out if you need to escalate anything.
On the surface, that probably sounds like looking at your to-do list as soon as you sit down in the morning. Truth be told, you’re probably right in that assessment. The difference is that you’re doing it deliberately now instead of just because you have to. You are adding an element of planning and forethought to a process that was formerly ad-hoc. Doing this may help you flush out ways in which you were previously unproductive, just because you took a little time to organize what you did naturally.
Next, add something totally new to the mix. Have you been focused on large requirements documents with lengthy implementation details included in them? Grab Visio and create a process flow instead. How about creating some wireframes and using them to help your stakeholders visualize requirements before they attempt to put them into words.
Now get rid of something; the more painful the better. The best thing to get rid of is email. I’m not an email hater, but its so convenient that sometimes we lose ourselves in it. Declare an email bankruptcy, wipe the inbox clean and start again. Let your stakeholders know that you’re doing this and that if they need you to respond to something they sent within the last week, they need to do so again. Stop replying to every email just so they all know you’re out here working for them.
Lastly, produce something. Do it early and often. Don’t wait till its perfect to put it out there. Create a rough draft, something that has all the right ideas (and maybe a few wrong ones) and push it out for review in hopes that it creates at least one new spark of information in your reviewers. That one great idea may come out of being utterly disgusted with all the bad ones that rough draft contained.
There is a lot of risk in what I’m outlining here. I don’t deny that; in fact, I’m glad of it. Many of us (myself included) work for organizations that have well established processes in place for good reasons, but we often (myself included) forget why the processes are there. They were put in place to fix a problem in the past, not in order to create a better future. Sometimes the world changes, and that rule that worked so well 10 years ago is hampering our ability to grow.
Embrace innovation in your job. Do it today.