Posts Tagged 'Skills'

5 Key Skills to look for in a Business Analyst by Patrick Bowe

“Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it” – Samuel Johnson

Happy 2010! It’s my first post of 2010 and I’d like to use it to address the question of what it takes to be a Business Analyst and what skills should you expect a BA to exhibit?

This is a question that I imagine vexes employers, particularly those, that understand what a BA does and now want to employ one of the best. The question is also relevant for those looking to pursue a career as a BA.

Below I’ve compiled a list of the 5 key skills that I look for in a Business Analyst, I’m sure the list is not exhaustive and that you can add to the list, in fact, feel free to leave your suggestions below. Continue reading ’5 Key Skills to look for in a Business Analyst by Patrick Bowe’

Creating a Change Request by Patrick Bowe

“It is not necessary to change. Survival is not mandatory”~ W. Edwards Deming

I’ve discussed in a previous post how it’s the role of the business analyst to seek out and embrace change. However change is often chaotic, expensive and unless you happen to be the stakeholder sponsoring the change, it’s usually about as popular as a tester at a developer’s convention.

As enthusiastic proponents of change, our challenge as Business Analysts is to sell the need for change to sceptical stakeholders and budget holders alike and also to point out when a change is neither desirable nor in the best interests of a project.

Enter then, the humble Change Request, a BA’s most trusted tool in the change process. A tool that allows the Business analyst to detail what the specific business problem is that caused the need for a change, what can be done to resolve the business problem and what impact those changes will have on a business or project. Continue reading ‘Creating a Change Request by Patrick Bowe’

5 Ways to Improve your Requirements by Patrick Bowe

“Deficient requirements are the single biggest cause of software project failure.”

(Hofmann and Lehner, 2001)

We’ve probably all been on a project where the requirements have been deficient or where the business has articulated a solution instead of a need. As an example, a requirement that I’ve often heard articulated on projects in the past has been; “The solution must be delivered via the Intranet”. This appears to the business to be a very clear requirement and, if left unchecked, it’s what the development team will eventually deliver.

However, is it what the business actually needs? Why did they request a web site? Did they want to avoid the need to install software on client machines or was it to reduce the processing that has to be done on the end user’s laptops. If so the project will either fail or become much more expensive if all the computers in an organisation need to have the flash player installed for the Intranet site to run or if all the processing is done on the client machine to reduce the stress on the web server.

Projects with requirements that are clearly deficient, such as the one above, are doomed to failure as Hofmann and Lehner stated, so it’s important that the person gathering the requirements, the Business Analyst, ensures that they are accurate and clearly articulate a business need. The following five tips cover areas where requirements usually fail and offer advice on how you might improve your requirements:

1. Improve the Clarity of your Requirements

Defining requirements is a tricky business. In my experience the business owner will either not read them or go through them word by word looking for ambiguous requirements, hoping that they will give them a get-out clause or room to negotiate change at a later stage of the project. Continue reading ’5 Ways to Improve your Requirements by Patrick Bowe’

What does a Business Analyst do? – by Patrick Bowe

Something that I’ve actually been asked while pitching for work is “What does a Business Analyst actually do?”. While I won the work in that instance, I was never happy with the answer that I gave at the time. I managed to babble something out about how a BA was the bridge between IT and the business and while this is true, it hardly demonstrates what I could do to impact the bottom line of a project.

Since then I’ve relayed this story many times, only to discover that it wasn’t just my erstwhile interviewer that was unsure of what a Business Analyst actually does. Very often it’s not until a BA has delivered on a piece of work that the business that they are working for appreciates exactly what it was that the BA did for them, even then I suspect they would find it difficult to define exactly what it was that the BA did. Continue reading ‘What does a Business Analyst do? – by Patrick Bowe’