Monday, June 21, 2010

ISO - Requirements Training

Over the past couple of months, I have been attempting to collect requirements for our LMS project. Should be simple, right?

The stakeholders put together a document listing what they needed the system to do.

It was a pretty straightforward list.
- Managers should be able to report on their teams
- HR should be able to report by job type.

That sort of thing.

Apparently, not what the technicians were looking for.

So the primary stakeholders and I went back to the drawing board in an attempt to clarify our needs.

I got so mad at one point - I created a PowerPoint presentation with happy smiley faces. (Oh yeah - THAT was productive).

Meanwhile - I went to the practitioners that I thought would know about requirements collection.

We're not trained to do that.

WTF!?! Not even to facilitate?!?!? (I am hoping that I said something a little more tactful than this. I probably didn't)

No - it's actually not part of our discipline

So who actually collects the requirements?

Well, it just kinda happens. We think it's the business analysts. But it varies. We don't get involved until after the requirements are collected.

Isn't there a preferred format? Some standard document you all use?

No - but we have a pilot document. Try this out.

So I stick the requirements the stakeholders and I collected (again) into the pilot document. Three drafts later, I submit the new requirements document to all parties.

Stakeholders: This doesn't make any sense

Technicians: This doesn't make any sense

Me (to the group at large...)All I want is ONE set of requirements that everyone understands so that we are all on the same page. I don't care if I have to show up to meetings in feathers performing interpretive dance.

ANYTHING so that we are all on the same page.

At this point, my manager slipped me a note telling me to not act so frustrated.

Thankfully - one of the senior business analysts for our enterprise system took me under wing; before I showed up to work looking like a Vegas showgirl for our next requirements meeting.

After chatting with her, I realized my difficulty collecting and communicating requirements was a result of never having collected requirements for this type of project.

I know how to collect requirements and do a needs assessment for a training project. I know the questions to ask. I know how to guide the client. I am ultimately the one doing the work, so I know what I am looking for. I know when I need to go back for clarification.

This time, I am collecting requirements for implementing a feature of a pre-existing system.
- I am only doing a very small part of the work, not all of it.

- The system has already been purchased, so we are working within a much tighter set of restrictions than is optimal. Especially since we have no control of the code.

- And this has been out of my realm of expertise. I've always been the stakeholder, not the business analyst (at least, not formally). As a result, I am not entirely certain of the questions to ask.

After much back and forth (and probably fearing the spectre of a crazed trainer dancing and shrieking on the conference room table), everyone went back to the initial document. The one without the bells, whistles and complicated formatting. Just a list. "Here's what we need it to do."

The final is with the steering committee now.

I am stitching up my costume and brushing up on my Fosse.... just in case.....

1 comment:

Unknown said...

Currently going through an LMS implementation
We had an exhaustive list of requirements- 300+, broken down by process type and all mapped to our process map.
We are going to do a few minor custimizations
Now that we are getting close to the end, I wonder what would have happened had we gone a different way in the beginning. Turn the thing on , work with it for six months, then decide what to change in code, or process and adjust at that point.
Rob Bartlett