Are you the first and only Business Analyst in your company? If so, you know how hard it is to survive while doing your job and bringing about organizational change. If not, you may be frantically thinking "How do I get out?!".
This post is to share my experience in how to not only survive but thrive!
I joined a mid-size company where there was no Business Analysts or Project Managers. On top of this, the IT team was new with little knowledge of the system. There was an SDLC (sort of) that was being followed but the requirements gathering went something like this:
-
Business user wants something but he's not so sure what
-
He pops by the IT department and blurts it out to an unsuspecting developer
-
Developer codes something the developer is sure the business user wants
-
QA talks to the business user and developer to figure out what they really want to test (no test plan or testcases)
-
Go live date and the next few days - chaos as bugs appear and no one quite knows how this happened (again and again)
So by now you're thinking I was marching off to the SVP of the company with a copy of BABOK in hand in a self righteous indignation, right? WRONG.
Open confrontation would only create resentment on the part of the entrenched business and developer community. Instead I laid low for a while, observing taking notes and thinking where I would make corrections.
I made changes slowly following the steps below in order:
- Developed relationships with influential stakeholders. Relationships go a long, long, way towards acceptance.
- Started writing down requirements and showing them to the business stakeholders. Reactions were "Wow, you really got it" or "This is not what I meant at all, here's what I really meant....". That's the idea, get them to acknowledge what they really want.
- Learned the database structure so that my requirements could refer to tables and even specific fields. I know, I know this is not what a BA should do but... with a new IT team it was best.
- Produced a detailed spec which was the sole document used for development and QA. All stakeholders were now on one page.
The above was done on a small project. This way I didn't "rock the boat". Since the results were much better than the status quo, my perceived value to the business and IT went up a notch. Since I could now speak a little businessese and ITese I also got some respect.
There was much more to do of course and the four steps above are just general highlights. More details on how to implement them in further posts.....