Requirement vs. Project Manager

A lot of times especially in Malaysia, BA and PM work can somehow overlaped, a BA is responsible for analyzing the business needs of clients to help identify business problems and propose solutions; a PM is responsible of the planning, execution, and closing of any project. Let's put this into another angle, what does project means here? In a SDLC, a proper objectives and scopes need to be identified, in which these scopes and objectives draw the content of a project, therefore BA should be handling the requirement phase and PM should be handling and monitoring all activities of all stages until the the closure of the project. However, a lot of times, BA has more knowledge of an organization and the business needs and the system requirements, with this a lot of times, the BA will normally has the whole plan on who the system will work, integrate and to be UAT, and most of all, the BA also dealing with the business users most of the times and knowing the needs and expectations are no doubts much better and i would say they will see a bigger picture in this manner.

It always come to frustration on this matter and worst when miscommunications happen between PM and BA and not to mention when the ambiguous messages delivered to the technical team later. A lot of times an argument raise "DO we need a PM? ", or "When will we need a PM?" and this could be an interesting topic to talk about again.

Requirement Elicitation

The toughest part of the whole SDLC i would say is the requirement gathering stage, whereby you as a Business Analyst should be able to collect the right information on the processes that are currently handling and not to mention that you may be challenging some of the consultants who are working on their process quality and at the same time suggesting some sky high requirements on how a system should be implemented in order to help them in the so called "off-loading" their work, improve creativity and eventually bring profit to the whole organizations.Then later you as a System Analyst to start analysing for the processes that can be automated. Why BA and then SA ? what about iterations? what about misunderstanding or lacking information during Business Modeling phase?

I would really much like to comment on this "WHY", which the reason being:
1. You are expected to do all if possible all the work, so the company could even maximize more on the profit
2. You yourself doing the requirement then later system functional and best still do the QA and UAT to make sure every requirement that you gather is fulfilled. Who know the best if not you?
3. Iterative process is too time consuming and this create more change request from the customer, and hence, FIX the scope quickly, then implement it, then only consider on CHARGEABLE CR.
4. People resisting of changes made to their comfort way of implementation, SO you follow!
5. RUP just having too much, and i mean SO MUCH artifacts to deliver, and all i have is 2 days to come out with all the documents. .... alrite... 2 days is a bit exagerating, or may 2 weeks to come out with all documents for all the modules?
6. Worst still, your technical team told you, it's simply NOT doable!
7. Project Manager asks you to handle the customer expectations, make sure requirement plan and test plan is correctly deliver within the project time line, make sure all requirements are captured and documented, then come out with the right use cases or functional specs, then test cases and UAT plan, make sure all milestones meet so that he can start invoicing the client and get the money.
..... am i getting out of topic ? oopps .... get back to requirment elicitation again .... and i suppose to be a BA for now... so... this is how it goes:

1. Understand the whole project scope (if you can find anyway in the emails, or CVS or sharepoint folders)
2. Roughly identify some of the business process by ? --> your best friend - GOOGLE
3. Start getting some information on the organization structure and people you are going to meet, in RUP this is call Accessing the Organization
4. Start planning on workshop and MAKE SURE you have the right sets AND relevant questions to bring together with you, always make sure you show confidence (even you are not), and smile :)
5. Always state the context of each of the workshop, co;z you don't want to end up talking other things and wasting time collecting information that you don't even need (or not even in your scope or extending scope that may possibly increase your cost)
6. During the workshop, open your ears and start capturing some of this keyword:

• Who do this
• What is needed
• How this is ended up with
• What will be the result of doing this
  
• What are the problems doing this
• What are the problems if not doing this
  

7. Then start accessing on:

• Benefits vs. Challenges
  
• Business Values - by doing Z, can solve A, B and C
  
• Performance Index - by having Z, need to do E, F, G and H

8. After the workshop, always revise what you NEED to put into your User requirement specs. This would be the base of the business rules which will be used again later.
9. Start to link whatever you have gathered, what is more challenging here is when there always having more BAs doing the requirement with other group of users, so the puzzle must be matched to the same picture in the very beginning. I like to use mind mapping here.
10. Always go back, if linkages are broken
11. Golden rule no. 1 - NEVER ASSUME (I bet you know what assume means)
12. Start drawing the storyboard to understand the user interaction flow and identify the input and output of each processes.
13. GO BACK to the client to confirm your understanding ALWAYS!
14. Then START DOCUMENTING...

What do i do?

I was updating my resume the other day, not that i want to look for a job now but rather updating some information in the jobstreet web for more recent information. Then i was looking into the resume that i attached together previously and was thinking what have I done for the last 10 YEARS!!

It wasn't too long ago that i got to learn RUP for the requirement analysis and unified process and the tracking tools, learning the "art" of questioning since then and of course the most tedious and massive documentation; and i still remember what my CTO said to me previously, "people can earn a living by doing JUST documentation these days." I have given this comment a big thought, and frankly at first i thought documentation was just simple and easy job to do and i have actually thought of it whether should i take it as my career path back then, it was almost 8 years ago!

IT industry was a blooming industry since the 90's and then I bought my first desktop (it was an Acer brand), when i was paying about RM5k for just that 286 RAM and Windows 3x, which i use to do some college assignment (Pascal) and some windows gaming with it, thinking of it, i don't really need it, i thought i was just copy my course mate program, beutify some of the sequence and messages and voila!

So, what do i do now? They called it System Analyst previously and now they have another name for it, that is Business Analyst. So this is a common question asked during any of my interviews previously, ok ... basically, i involve in the very beginning of a SDLC, that is requirement elicitation, the requirement could be business needs, and then later exploring any system automation requirement which the end user wants, hmm ... basically Documenting Requirements ! easy ?!