Requirements Management Reality Check

OK, so here’s the thing. The other day my grade school-aged daughter asked, “Mommy, what is your job?” My response, “Wwweellll….. um, see, I help, I mean, I work with, I mean, I translate, well, oh none of this going to make sense… OK, Mommy works with computers.”  It’s true, isn’t it?  As difficult as it is to explain the role of the Analyst to grown-ups, try explaining it to a 1st grader!   Officially, this is how I describe the job of the Analyst:

Responsible for developing requirements management strategy, process and plan, eliciting and documenting system requirements, driving issues and change management, participating in software testing support, end-user training, and deployment.

My short form of this is:

Responsible for translating from Human to Geek and then Geek back to Human.

Ultimately, at the core of what we do is to help our projects solve problems. What makes our role different than say an architect or developer is that we don’t usually do that in a “ta-da-here-is-your-solution” way. We listen. We observe. We facilitate. We restate. We organize. We ask questions—the obvious ones that everyone else is afraid to ask. We draw the conversation out of the team so we can all problem solve collectively and creatively.

So what does this have to do with requirements management anyway?  As we all know, the work that goes into what becomes a recorded software requirement is more than simply listening and typing. The reason I use the word “artifact” when I talk about requirements is because what we produce is the result of a process. (No, it isn’t an “artifact”  because it is an object that will be later unearthed and speculated about as to its true value.) The process is what counts. If the process isn’t good, the artifact certainly won’t be. One of the things I appreciate most about Fusion’s flexible Quality Management System is that we give our projects the opportunity to innovate and apply ingenuity, not just in the delivered solution but also in the planning process. Planning your requirements management effort involves understanding the problems you are trying to solve, and allowing the planning team to use creativity and collaboration will give the project the boost it needs to get to solutions.

Let’s be real though—we all have worked with project team members who want to do things “the-way-they-always-do-it”. My advice—pull them into the requirements management planning process.  Seek to understand what is it about “the-way-they-always-do-it” that helps them get their jobs done.  Really, isn’t this just another problem to solve, another opportunity to collaborate and innovate on a solution?

I know what you’re thinking: “But you still haven’t answered your daughter’s question!”  I was getting to that. If you are a regular Nick Jr. viewer, these song lyrics should sound familiar: “There’s no problem we can’t solve, when we put our heads together and get involved.” See, if I just put it in the same context as Kiki, Marina, Twist and Shout, she’ll get it:  “Just like The Fresh Beat Band, Mommy works with people to help them solve problems.”

SOUND OFF:  Do you have an innovation in requirements management that you want to share?  We’d love to hear how creativity and collaboration in requirements management has had an impact on your projects.