After a long silence, here I start my first blogging…
Even though the blog heading is QA Heaven, never discussed the QA issues on this forum…
Most of the local vendors utilizing the term QA in wrong way…
Who ever test an application gets the two letters in front of their designation and becoming QA Engineers…
And the selection criteria for the QA Engineering position also got degrade throughout the years…
If you lack the coding standards but can test the applications to catch visible errors, then you can become a QA Engineer in this country… That is easy as that…
Those ridiculous practices lead to many of the organizations from good to bad and bad to worst and created chaos…
As a direct result of these practices, customers came up with 1001 defects even after the UAT (user acceptance testing)…
I am not going to talk much about those issues here… but taking my time to criticise some of the practices at a process savvy IT company in Sri Lanka…
I am not going to reveal the name over here since it might be the practice and the cost cutting mechanism at most of the local vendors…
Not only local vendors, there can be hundreds of thousands of companies around the globe doing the same mistake…
Yet again a something which is outside from the QA but this is the right time to build a constructive criticism on so called best practice at that organization…
This company tends to hire resources to undertake both the Business Analyst and the Project Management role in parallel…
Hmm… two one has to show the two sides of the coin at the same time…
While I was browsing through the web, found this interesting interview and sharing the same for your informational purposes…
Here the author Michelle Davidson presenting a summary of interview with the Barbara Carkenord, who is the author of "Seven Steps to Mastering Business Analysis”.
Business analysts must have certain skills and must understand the many software requirements techniques out there, says Barbara Carkenord, author of "Seven Steps to Mastering Business Analysis."
What made you decide to write your book, "Seven Steps to Mastering Business Analysis"?
Barbara Carkenord: The reason from a business analysis perspective is that there really haven't been any books written specifically for people doing that type of work. There are a lot of books on techniques and analysis techniques, but not anything that says here's everything you need to do analysis work. There are people just coming into the role who really don't know what they need to do, and this book is for them.
If someone is considering becoming a business analyst, what skills are considered necessary?
Carkenord: I would say the number one thing is communication skills -- both verbal skills and written skills -- documentation -- because the main job is to be a liaison between two groups who don't communicate well.
They also need skills around understanding how technology can solve business problems, which means they need to know about the business and what's technologically possible.
They have to be people who can logically break down problems and think things through -- just very analytical.
What challenges should new business analysts be prepared to face?
Carkenord: I think the biggest challenge when you're assigned to a project is really trying to figure out how to get started. There's a lot available to you and a lot you need to find. You need to figure out whom to talk to in order to get the information you need.
When it comes to software requirements elicitation, elaboration, and validation, what are the biggest problems business analysts have?
Carkenord: The biggest challenge is business people don't always recognize what they need or what is capable for them. So they have trouble communicating with IT. And IT doesn't understand the business side, so they give them an elegant solution that doesn't do what they need.
Business analysts need to help business people figure out what they really want. The BAs really need to sit down and talk with them.
I think the development environments continue to be more and more productive. Developers can build things very fast, but we don't know what we want them to build. They can build a lot of things, but are they meeting business needs?
What techniques and strategies serve business analysts best when it comes to working with stakeholders?
Carkenord: We have a lot of techniques. There are actually hundreds of analysis techniques. Part of the challenge is learning which works, because each project might necessitate a different way.
For a new BA starting out, we encourage using a real structured scoping technique to get the business people to agree what the objectives are. You can determine what are we doing and what are we trying to accomplish.
Data requirements are also very important. And we encourage new BAs to use Entity Relationship Diagramming (ERD) to structure data. It's a really good way to elicit requirements of what the needs are of the business.
Use cases are a very popular requirements technique right now. We also do prototyping and storyboarding.
In your book you talk about business analysis certification. Do you think that type of certification is necessary?
Carkenord: It's become popular because the role of the BA is very challenging to define, and companies don't have good job descriptions. So, they're looking to certification to help them figure out if this person really knows how to do this work.
Certifications are very popular. So I suspect this will be as popular as, say, the PMP [Project Management Professional] certification.
Certification in many IT industries, such as testing and project management, is a controversial topic with many saying certifications don't guarantee a level of expertise. Does this controversy seep into the business analysis realm?
Carkenord: I do think there's always going to be that challenge of whether the certification really means something. The IIBA [International Institute of Business Analysis], which certifies business analysts, is aware of those kinds of issues and has worked really hard to design a program that would assess people's ability to do the work rather than just pass a test. The work experience aspect is very high, and the questions are very analytically based. You need to think analytically to answer the question.
What's the difference between a project manager and a business analyst, as a lot of project managers have been responsible for requirements?
Carkenord: We see them as two completely separate roles, at least on large projects. I think the personality traits for project managers are different than BAs. PMs are managers; they push things forward, and they get things done. BAs are analytical and like to explore, but they can get stuck. They'll get all the details up front to make sure they don't miss anything.
If you have both on your team you're covering all your bases. If you have that team, your likelihood of success is much higher.
Many organizations trying to combine these two practices in to one and trying to utilize a single resource to cover both these aspects.
They never understand the importance of both these practices and neglecting a one. Pressure comes from the top management on cost cutting might be the direct reason for this.
As a direct outcome of this they never understand the value of BA and adding extra effort on project management and expect the resources to add higher effort on project management and controlling practices.
The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. At the same time, allotted resources failed to capture proper and accurate resources due to management pressure and the extra workload from the project management practices. This leads to failures in projects in the long run and generated frustration on both the customer’s end and the in house.
That doesn’t sounds that project manager should not carry any BA expertise but the roles has to be separated from one person and assigned to two or more resources based on the requirement.
That will improve the productivity as well as the efficiency and increase the correctness of the data or the requirements as well.
Thursday, November 13, 2008
Subscribe to:
Post Comments
(
Atom
)
5 comments :
Ah.. the topic I've been talking for years now.
Let me talk about BAs a bit, very very briefly, to warm up a bit.
BA is a practice - speaking English and ability to write what ever is heard is not the only qualification one need to become a BA - although the company you mentioned (which I think you did) seems to think that way.
A BA has to have the ability to clearly understand without doubts, by asking wit-full questions and studying/observing, business domains and requirements; and more importantly document/communicate that knowledge to a technical audience unambiguously and thoroughly.
I have come across such BAs; but unfortunately, not in my work place.
What's worse than having an immature and incompetent BA community is that same community selecting the next generation.
PMs playing BA roles or BAs playing PM roles have a background to it. Some time ago, a certain company recruited non-IT professionals who were working in banks, insurance companies, airliners - you name it - into managerial/BA roles.
Now the idea behind this recruitment drive was to get business domain knowledge in to the company. But as we both know, if someone knows his/her domain well, more often than not they love what they do and wouldn’t want to change professions. Due to the same reason, almost all the people recruited in that drive were failures. So that company ended up with a bunch of lower management level resources, who practically doesn’t fit anywhere. Their age, past experience and designations require them be given a leadership role. But the expectation from them is mostly BA work. But unfortunately both of which they are not really competent in. So they ended up being BA/PMs for not so important projects.
Ah.. we could talk about this for days man… maybe we could invite Yasas to talk about BA practice.
Hey Mahasen,
Thanks dude.
Here are my comments.
As you said, some companies using an immature selection practice of hiring people with good command of English in to this position (BA).
Having good command of English is one mandatory requirement but it should not be the only reason to hire he/she as a BA.
Another fault is hiring people with the relevant industry background. As an example, person worked for a garment factory for years might know the A-Z of the workflow at his/her premise. But they do not know the meaning of the term “Generic Practices” and they might not having the required set of technical expertise to educate their end customers and the stake holders.
When we are talking about the software industry, needs people with technical background + some sort of domain knowledge on the relevant area. This person should be able to collect the requirements from the customer and should be able to communicate the things we can do and not. I’ve seen a BA, whom comes up with a requirement spec telling we should be able to upload files with unlimited size limit.
The tricky part is, identifying the resources with both the technical and domain expertise.
As you said, we’ll invite Yasas and get his opinion too.
This might be the start of an interesting conversation.
Thanks for the invitation guys!
Barbara Carkenord's interview is spot on. I've read her writings before as well. My opnions are very close to what she has said.
Yes, communication is very very important, no question about that. We always have said that BAs are the bridge between 2 groups,,business (client) and develpment (SEs), so a BA should be good enough to be able to work with 2 groups seamlessly. Understand both languages ..one tech orented, the other business oriented. I think its a skill on its own, I have seen people coming from business (eg: banking) failing as an IT BA. Why? They dont know how to speak the IT language.
I should stress, we talk about IT BAs here. There are BAs in banks, who analyse finacial situaltion etc for business,,,but we are talking about IT BAs, and they need to know IT. They need to have a passion for IT, a craving to learn and read it. True, you dont/cant develop those amazing systems, but you love them! You read about them! You like to know how they are designed and developed! Those are the traits of a good BA.
A BA should have a good understanding about business in generel. I repeat..'in general'. An IT BA does not have to be an expert in one particular domain. BAs are differnt to SMEs (Subject Matter Experts). A BA should know basics, but able to understand if he has to, be able to talk to users and SMEs and understand the requirements. Its different. This is the thing that people got wrong when they thought experts from domains could do wonders as IT BAs. Those experts knew traditional banking (for example) but didnt know anything about IT, couldnt think out of the box and come up with good/new solutions. This where an IT BA is different, he should be able to talk to right people and understnad the problem, but come up with a new solution. If he has a mind thats locked into one domain, a few systems and a decade at one domain, he does not have that flexibility of moving his head around and finding an innovative solution. To be honest, I've seen domain experts (eg: banking) who were given BA jobs, and couldnt draw a ER diagram for a slightly different case. (Their head goes back to the X system they used for 10 years at Y bank, which actually was highly user unfriendly inefective system with a million work arounds to cover up its bugs!)
The other aspect spoken about here is BA Vs PM (I think I wrote about this sometime ago somewhere) Again, Barbara Carkenord is spot on, and I fully agree. They are different skills, but goes very very closely because of the business/managment oriented base skills used in both roles. For a small project, I am ok with using the same person to play two roles, but whereever possible, I would avoid that though. They have different focuses, if you have the same person doing both, there will be a compromise somehwere. However, I have seen some BAs doing a good job when they are given a PM role but usually not both at once though. My observation is that that good BAs know how to remove themselves from the unwanted detail and focus on the problem and manage them effectively, so most of them can do a good PM job as well.
THe IIBA certification is good, it will kind of teach people what BA is, because there are too many myths. However, many succesful BAs came into existence and prevails even today, without having these certifications, and usually those succesful ones read their role well, they had a passion for IT and business, but werent too expertised in one domain, hadnt spent decades working on the same domain, hadnt been a business user on the same appication for decades and importantly knew what to ask from whom/when and then had the patience and skill to design something new to solve the problem he analysed/clarified and also present/explain it in a simple box diagram and a few words that could be understood by someone who had a basic level of inteligence...!
Hi Yasas, Mahasen,
Thank you very much for the contributions. You too added lots of spices to the posting and all of them are valid quotes.
As Yasas commented, IT BAs can become good PMs. No issue with that. As he said, we can not assign a single resource to cover both the aspects, especially when there is a large scale enterprise application development. Mixed interests will harm the final outcomes as well as burn down the resources unnecessarily.
Thanks guys!!!
There will be few more on the queue...
I hope that you two can contribute a lot on those discussions as well!!!
Very informative. Keep going!
Post a Comment