Thursday, July 30, 2009
Resolving Conflicts
Thursday, July 23, 2009
The Art Of Negotiation
While doing my Business Analysis I have found that negotiation skills are very important and very crucial part of your role. As a BA you need to master the art of negotiation, you will have to use that skill at various stage of the project, you negotiate with the sponsor with the scope and delivery dates of the project, you negotiate with the project manager to get appropriate resource and on time, you negotiate with the development team with the features to be development and if you are lucky to get this far, you now negotiate with the QA team to ship software with least number of defects.
One thing you have to learn and believe as a BA is that nothing is set in rock, you can and you should negotiate at every possible stage of the project to achieve the best outcome possible.
Some people are natural at negotiation whereas other people need to improve on it, most people see negotiation as negative and tend to avoid it, but it is not about doing the least possible or being difficult, it is about making sure all the party involve are happy, and everyone gets something out of it.
You should be very careful when negotiating, your body language, your tone and your approach is very important. Try to put yourself in other person's shoe that will help you to understand the other person's view, treat everyone as you would like to be treated.
Before you start negotiation sit down and list of following things
- Make a list of every single topic to be negotiated.
- Make a list of topics which should be avoided during the negotiation.
- What are your needs (and not your wants)?
- What is the minimum you want to settle for?
- How far are you prepared to go?
- What is available or possible?
Knowledge is power so make sure you know as much as possible about the thing you are about to negotiate, ask around if anyone else has done it before and what was the outcome, don’t let the other party blind you with technical details, stay focused.
Always remember 'Relationship before task', spend some time with other party to understand their need, always empathise with their problem, avoid and deal with conflict as soon as possible. Always explain to other party why and what are you negotiation for.
Negotiation is not about 'YOU' or 'ME', it is about 'US', be flexible, do not try to drive too hard, make everyone involved feel like a winner.
How do you know that your negotiation was successful?
Well there is no great answer for this but if both parties seem happy with the outcome, which fits into the project goals, I will say that’s good.
In the end don’t forget, negotiation is truly an art and not science, negotiation skill can be improved even in your day to day life activity (some time you are doing it without realising it) like negotiating for a mortgage, car or even insurance. All the best.
Thursday, July 16, 2009
Being ScrumMaster (Daily Scrum)
As a ScrumMaster make sure that the venue where Scrum meeting are held is consistent, changing venue can cause unnecessary delay, also do not change the time of daily Scrum, no matter what happens around in the company, daily scrum should happen at the same place, same time (it is ScrumMaster's job to ensure that everyone attends the daily scrum).
Ensure each scrum member answers the following questions in the daily scrum
- What did they work on since last scrum meeting?
- What are they planning to work until next scrum meeting?
- Are there any issues they would like to highlight?
To be a successful ScrumMaster please ensure the following
- Resolve conflict between team members as soon as possible.
- Ensure everyone is heard and has opportunity to respond.
- Ensure people do not get too much in to the details.
- Daily scrum is to report progress and raise problem (not to solve them in the meeting).
- If the sponsor is attending the meeting they are only listening (they are not allowed to talk).
- The only people allowed to talk are the one who are working in the sprint.
- Normal meeting etiquette is observed.
Some of things you should watch out and address during daily scrum
- Team member are providing status to the ScrumMaster rather than team.
- Team member don’t look motivated.
Thursday, July 9, 2009
Technical details in a requirements document
I come from a technical background, but not all business analysts comes from programming or technical background, I feel both categories of BA have advantages and disadvantages, especially when you are working for a software company.
Let me stick to the topic and focus on BA with technical background, I feel when you start the requirements document it should be entirely based on business outcome and you should not think about the solution or any other technical details, this ensures that your document covers all the business needs and is not compromised by technical limitations.
If your company promotes and allows JAD (Joint Application Development), then you will have to talk to the technical team, I found it very handy if you are able to talk the technical language, but getting too much technical could risk the business focus. On the other hand based on my experience technical team are a bit reluctant to document technical details in that case documenting technical information can be very handy (QA team will thank you for that).
Personally I would rather focus on defining requirements clearly and free from ambiguity then worry about technical details, but BA needs to understand the design concept, in past I have experimented with semi technical document by adding Workflows, UI, Data Modelling and sometime ERD diagrams, that has worked in some cases some and some cases it did not, you will have to use your judgement as to how far you need to go on the technical side, it may also depend upon your audience, too much technical details makes it difficult for a business user to review,understand and verify the requirements.
There is also some overlapping between functional and technical, what is technical to BA is functional to the development team, BA usually have to write functional and non functional requirements so sometime there is no way out but to write technical details.
So in short depending on the willingness, skills and experience, BAs can choose to be more on the technical side or stay focused on the business side, a balance of both side is what I will recommend.