If you can,  involve  your tech lead and/or your architect and QA leads formally in the requirements elicitation and documentation process once you have your high level requirements. If you can’t involve them formally find a way to get their inputs informally.   With most companies  using waterfall, you will notice that technical input is seldom sought in the initial stages. The technical resources are often busy working on other releases / projects and are not anticipating any involvement in the analysis stage.  Involving them early gives you some big advantages…a) they begin to think about design pretty early and will often tell you what your options are as you write requirements. b) they will be able to think of edge cases and scenarios that you won’t be able to think of. c) you will begin to learn more about the existing system which means you will be looking at your requirements more critically and closely to identify potential issues.

Make sure your requirements truly address the “what” and stay away from the how. As BA’s we have the tendency to stray from the “what” to the “how” in our documentation. This can cause unnecessary technical complications and also leaves less room for technical design.

Set up requirements review sessions more frequently than normal. Plan for them ahead of time and jot down a list of questions that you identify. Importantly dont be afraid to ask them!

Level set expectations of your project team. When you are working with something large and complex…it is inevitable that you will miss requirements especially those edgy ones. Grab every opportunity you get to let both business and technical team know that things may change based on design / technical feedback. This will not only help the PM plan some lag time into the project plan and come up with a mitigation strategy, it will get  attention from technology and importantly the business side will be better prepared for potential changes .

In this post, I wanted to chat about Waterfall as an SDLC and what it means to the BA. As ancient as Waterfall is, it is still actively practiced in several companies including the one I currently work for. Over the years, I have learnt not to underestimate waterfall.  It works extremely well for certain specific types of projects. For example Waterfall would be my preferred methodology for projects where small scale enhancements are being made to an existing system. The key word here is small scale enhancements. In these kinds of projects, the product managers know exactly what they want and the developers know exactly what to build. The requirements are straightforward uncomplicated and every one is a happy camper.

 On the other hand I find Waterfall as a methodology to be extremely limiting for the following types of projects

• Projects that are entirely backend infrastructure related or projects that require a change to the backend infrastructure. (By backend infrastructure I mean database repositories, data warehouses, stored procedures, batch jobs and all the good stuff that store and manage the flow of your company’s information.)
• Projects that involve User Interface design
• Projects that are web based.
• Projects that involve multiple systems internal or external to the organization. 
• Any other kind that I missed if it is large and complex

Now that I mentioned Waterfall is limiting its only fair I explain why.  You will notice, all the projects I indicated above involve a fair amount of design. If you are a seasoned BA, you know that requirements influence design and design influences requirements. Granted, a few of us are fortunate to work with Architects or Tech Leads or sometimes a just a systems analyst while documenting requirements. What we produce ultimately as a deliverable is a document that captures all the requirements we were able to come up with the help of all the technical and business resources that were available to us. But guess what, when the project progresses to development stage (let’s face it…for most of us design cycle within the SDLC is limited or non-existent) within the SDLC…you get that much dreaded call from the tech lead…

“We are coding ABC and what should we do in the case “XYZ” scenario? We notice there are no requirements addressing the “XYZ” scenario……” Depending on the scenario which can be small or big…as BA’s we are either back to the drawing board or scurrying to backfill requirements. Does that sound familiar?

Waterfall projects also tend to be more quantity driven (usually time) as opposed to quality driven which does not work well for the kinds of projects I described above. IMHO all projects should be quality driven but especially those that are large and complex such as the ones described above.  So how does one overcome these challenges as a BA given the fact that more often than not…the methodology that is adopted for a project is thrust upon us? That’s a topic for a whole another post which I hope you will come back to read.

Before I end, I want to leave you with a disclaimer….that call from the tech lead I was describing…can occur when your company practices Agile, RUP or for that matter any other methodology. The point I am really trying to make is that the consequences in terms of time money and resources tend to be more severe when it comes to Waterfall!

 I look forward to hearing your thoughts and comments!

If you were a business / systems analyst in the nineties, there were  limited opportunities  for you to self-learn and grow your skill sets. Today, we have the opposite problem – Information overload! For every challenge you face as a BA, you can literally find millions of ideas and perspectives from  business analysts across the globe! What becomes challenging is sifting through all of this  limitless information to find what works for YOU and YOUR UNIQUE needs!

The internet being the great leveler that it is,  forces all of us to up the ante!. There is a need more than ever to get better at what we do everyday, so we can find those jobs we want and importantly keep them! It is this need of not wanting to be left behind that drives a lot of us to connect with groups and associations and subscribe to blogs  – just to keep abreast.  I am no exception, I spend a fair amount of time every week on the web and when I find an organization or a  group or a blog that can help me excel  -  I promptly subscribe!

The next thing I know,  my mailbox is flooded with several useful articles and resources. With some articles…. I have a huge problem implementing o even retaining what I read.  I struggle especially when it comes to structured lists, techniques, definitions or metrics that claim to make my life simpler! When I think long and hard about it, I know why!

Personally I believe that business analysis is more of an art and less of a science. In fact when it comes to business analysis, I strongly believe  there are several right answers to every challenge. Most of us BA’s tend to be creative and often work very intuitively. And to a lot of us, that room we have to use our instinct and intuition is one of the best things about the job. If you can relate,  read on! 

This blog is an attempt to go back to basics.  I hope to discuss broad topics in layman’s terms. I hope to keep it simple and importantly get you thinking!  I also hope to focus on simple things that you can do to stand out and importantly address them one concise idea at a time!  Not all topics will be on business analysis,  I hope to focus on the soft skill aspects a little bit as well. It is afterall a big part of our role and often the deal breaker!

I have been fairly successful at what I do, but I don’t claim to be an expert.  I want to share what’s worked for me along the way and hear from you on what’s worked for you!

I am hoping we can learn and grow together and that this blog will be worthy of your time!