Requirement vs. Presales

Being involve in the presales is not a work that i really enjoy and probably i still can''t catch the essence of presales of the preliminary activity for sales. Doing presales, one needs knowledge of the product or at least the domain knowledge on the business itself, it's also a story hook up time or if you like to call it - BS.


I have watched this movie called "Thank you for Smoking", in which i like the way the messages is being conveyed, famous line, "It is not a negotiation, it's an argument", there's lot of art of "negotiation" so to speak in this movie. Being in the dilemna having a job as the vice president of Academy of Tobacco, selling cigarrettes and knowing it is causing cancer, and having all the bad health results, however he has turning each argument to a winning cards, wow ....

Anyways, my point is being in presales is tough for me, a lot of softskills is needed, a lot of general knowledge is needed and a lot of integrity is needed, why integrity ? ha! I feel we should have certain honesty to the customer when a certain level of message is delivered, especially when you say, "Yes, it can be done for sure", or should be rephrase a little, "By having such condition, i'm sure it could be done"? Well i guess it's the art of how we convey messages, probably i should start looking into the speech methodolgy in this case huh.

Requirement vs. QA / Tester

What is QA? What is Tester? I was being asked to deliver test cases, UAT and perform integration tests on the system. The reason is , I was the BA, a SA and so the best candidate to make sure the developed system maps the requirement being designed accordingly.

eehmmm ... i have been struggling of what's been said above. It does make sense theoritically. The best way to test the system is to identify the possible scenarios from the business process and test the situation with the system. Then i thought, what could possibly happen on the scope of work for a BA?

After each requirement workshop or session, I will start preparing for documents like business processes, requirement list, business rules and sometime scenarios and most of the time these information is being verified by the customer themselves and then this information will start to translate into the use case specs or functional specs (i don't like to work on functional specs and i always think the more appropriate person to work in should be the solution architect) but anyways, during the analysis and translation process, i thought, there should have a certain level of QA be inplaced, to check on standards, logic, etc and it should be not be done by the BA/SA alone, simple reason behind, when oneself is too into a certain work, they are tendencies of overlooking other aspect and also some important details that may be needed during the development cycle and therefore a QA is needed in here.

Not sure if it's a good or bad situation to bring in QA during documentatations, which ended up spending more time explaining the situation to the QA why certain work is being done accordingly and most of all the expectation is rather different when they start asking after this screen, where the cancel button will be leading to ? ...... The idea was, to let the QA check on the flow and i mean the business flow and how this is carry into the system, but so detail until how eash screen flow would be, if i would want to look into such details then i could be the solution architect and start designing each button, or link actions? .... hmmm is there a QA for business processes then ?

What about testers? the conflict starts during the interation testing. A lot of time, the tester or it could be the programmer himself doing testing in the development environement, test goes out well, when it comes into integration test, it always got haywired, so now the question comes back, who should do integration testing? the tester? the BAs? ...

Requirement vs. Solution Architect

From most of the projects that i have involved, there's always conflict of interest between a BA, SA or a Solution Architect. A lot of times, there's thin line between each role and if the expectation is not being managed correctly, job responsibilities, the so called "ideal" solution architecture may varies, and i mean WAY different from what is captured from the business point of view.

HOWEVER, i enjoy working with them, in which people from different background see requirements in different angle, in which this can further empower how a requirement should be written and support with other necessary documents, i.e reports, chart,draft flows, etc. How bad could it go? Let's see the famous chart that portaying how requirement is being captured, "ASSUME" and documented below, which i think is really appropriate.


and of course, what customer really wants is:

I have learned something over the years, there's a couple of scenarios may occur when a requirement gathering, or analysis went too wrong:
1. A new feature evolve!!
2. A feature the customer will NEVER use!
3. A Bug that would never SOLVED! and the customer needs to work around it.

I also learn to accept and "negotiate" for what the idea and concept is presented. A lot of times, I will try to iterate the requirements by draft out the high level screen flows (Which may not be same like what SA will draw), but just to keep a common understanding between the team members, and the customer ... and how the document should be written (hey i won't want to write something that we can't even deliver!). So then i found some hot approaches are pretty useful, i.e RUP!

note: i know the artifacts are crazy! and time always the issue in SDLC!

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 ?!