I recently attended the SPC14 conference in Las Vegas. Filled with bright lights of the big city and many brighter people at the conference. It was full of learning, getting to know others to work like a network and a little fun thrown in. Of course, nowadays, what you do in Vegas usually finds it’s way to being posted on social networks throughout the community and are spread quicker than wildfire so I just wanted to share my thoughts on the conference and make some things clear that I discovered during the event.
I was at the conference to learn more about creating a social strategy for my company and I completely immersed myself in doing as many real social things as well as the social things that are only done behind a computer. I learned a lot about Yammer as I worked with it the entire week and made quite a few connections. One of the things that really interested me, other than the social “research” I was conducting, was that of a requirements session that took place while I was at the conference.
I didn’t get to attend the session for a couple of reasons. #1. I should know about requirements, I’m a BA after all. #2. There were so many sessions that picking 2 or 3 in a time period was normal. Since I can’t be in 2 or 3 places at once, I had to pick one and hence, reminded of #1 reason for not going to the session. I have reviewed the deck that was delivered and even met the speaker. I thought it was a great presentation, but there seemed to be quite the discussion of a requirements template on Yammer after the session.
I’m not sure what was shown, but the Yammer community seemed to be looking for something that was all inclusive of the requirements. Collect requirements by documenting them on the template and doing a prioritization all at the same time. Really?? HMMM. I felt my BA skills suddenly taking over and creeping along my skin like a bad infestation of insects crawling around.
From my perspective, there’s a lot of steps you need to take when it comes to requirements. While some steps are taken in a more formal approach than others, the steps are still there and shouldn’t be glossed over. This is true for any requirements, whether working with SharePoint or some other software…you’re doing requirements or you’re doing rework.
Requirements need to be elicited and can be done in a number of ways or variety of techniques, but drawing out the requirements is the first step. Once that’s done, requirements go thru an analysis process, is it valid, is it duplicated, are there conflicts with two or more requirements and how are those requirements prioritized in terms of your solution. Finally requirements are traced back to the business. Why? Well, how do you know if a requirement can provide business value or not if you haven’t bridged the gap from business need to the requirement? Otherwise, your requirement may be to provide world peace. Maybe a great requirement, but does it add value to the business or conflict with other things?
So, there’s a little more to requirements than initially thought and a lot more than just putting requirements on a template that “does it all” at once. So, please be wary of getting templates that do just that and think you’re done. If nothing else, ask a business analyst that is trained or certified to help you with the requirements processes and you will find that there’s a lot more to it, but going thru the process will lead to more success in your projects as well.
Sweet water and light laughter until the next!
IT Social Butterfly 