Archive for the 'Business analyst' Category

I’m A BA, don’t put me “in a box”

Published by
Maria Murphy
at 14 February, 2008 in Accreditation, Business analyst and business analysis. 6 Comments

 

As a BA community we need to come together and start promoting our frameworks, our methodologies, our approaches in order to shape the future of the profession rather than worrying about defining our role. We should define the scope of what is business analysis as a discipline. Once we achieve this end, this will empower us to look at what the discipline offers in the way of frameworks and tools to interested practitioners, as the specialists in this field.

Organizations representing Business Analysts are looking to certification or accreditation as a way of defining the role and bringing in some level of standardization in order to decrease ambiguity in the marketplace. There has also been a lot of debate about the role vs the discipline of business analysis. Garrett cautions that if we go down the track of defining the role we inevitably threaten someone’s sense of identity. If the Business Analyst’s role differs from the organization’s job description, then does it follow that they are not Business Analysts?

Alternatively, we could argue that whatever the discipline of business analysis is, it follows that those who are specialists in this field are Business Analysts. Although this has the potential for the BA to be “boxed in” may result in Business Analysts having little influence or control over important aspects of projects, where Business Analyst competencies and capabilities are of great value and adding strategic value to organization goals and objectives for process improvement.

As a Business Analyst I’m more often involved at a strategic level. Rather than my involvement with projects ending with the delivery of requirements, I’m utilized throughout the project: I bridge the gap between the business and the technology team; review processes and operations; as well as investigating and advising on the project’s impact and dependencies on other systems and programs initiatives across the enterprise.

All this activity means my role is not easily defined. This is not because I’m trying to be all things to all people (the Project Manager, the Business Analyst and the Systems Architect) or take over another project team member’s role, its more a reflection of the discipline of analysis being increasingly seen as a core capability and that the frameworks and tools used for analysis can be drawn upon for expertise throughout the life of the project and through all the programs across the enterprise.

In short, as a Business Analyst I do lots of things. Don’t put me in a box or label me and don’t predefine what I do … it limits the possibilities for my involvement to add value within projects, between projects, across programs and across the enterprise.

Ultimately, the definition, role, responsibility, and the future of Business Analysis will be determined not by us but by organizations that will base their decisions on their resourcing needs. It is therefore up to us as a Business Analysis Community to continue to promote what we do and how we do it and share our knowledge, understanding and expertise within the community. By doing this as a community we can go out to organizations and showcase the capabilities and competencies of business analysis. This will show the value of the discipline regardless of the role within the organization. Instead of prescribing what a Business Analyst is or isn’t, let’s talk about our frameworks, our theories and what tools are out there to get the job done.

User benefits of Conceptual Design and Prototypying

Published by
Maria Murphy
at 9 December, 2007 in Conceptual Design, User centred, Prototyping and Business analyst. 0 Comments

On the 4th of Dec Canberra hosted the Australian Business Analysis Association (ABAA) User Group Meeting and Christmas Drinks. It was an excellent opportunity for those interested in business and system analysis to get together and discuss the development of the profession. Matthew Hodgson from SMS Management and Technology presented on user-centred design and prototyping. Matt delivered a very inspirational and passionate presentation and I’m sure we now have new BA converts to prototyping.

In his presentation, Matt suggested that “as business analysts, we’re often focused on eliciting business requirements for systems, managing the relationships between the business owners and the vendors and developers of the technology. Unfortunately, we sometimes forget that what we’re doing is delivering a system that is for users. This results in us delivering the ‘what’ in terms of requirements, but forgetting that there’s a very strong need to find out from the people who will use systems the ‘how’ it will work for them”.

Matt works as an Information Architect and this is exactly the head-space that drives IA activities. In his presentation Matt suggests that IA and concept design can help “to determine navigation paradigms that are truly usable and accessible and systems that are designed to meet people’s needs in an intuitive way, rather than systems by developers that you have to ‘learn’ how to use”. Matt also stressed that “User-centred design seeks to change all that by putting the user as the focus of all project activities, from scoping, to analysis and requirements gathering, all the way through design and delivery”.

I think Matt makes raises some really interesting points about the focus on User Centred design, that as BAs we should consider. I believe it is really important to remember when you are developing requirements that as Business Analysts, we are NOT the Users. It’s not about us, it’s about the Users and what they need and how they will interact with this system. By using iterative prototyping, you can uncover the User’s need in consultation with them and use prototyping as a means of communication and eliciting and refining requirements. This will ultimately save a lot of development time and money.

Struggling to define Business Analysis and the BA role

Published by
MariaMurphy
at 22 October, 2007 in Business analyst and business analysis. 4 Comments

There is still a lot of debate in BA circles around what our role is and what is offered by the various organisation representing and supporting BAs. Is the role all about requirements analysis? Are we just interested in IT and systems analysis or are our practitioners focused on the broader business and processes?

I came across an interesting article forwarded to me by some information architecture friends, Matt and Andrew. The article on the discipline and role of IAs was written by Jesse James Garrett in 2002 and the issue of defining the roles of IAs that they were struggling with back then, are very familiar issues that we are now facing as BAs.

Garrett argued that there is a discipline known as information architecture as well as a role known as information architect and that they evolved hand in hand but the time had come for change. Thus, just as there is the discipline of Business Analysis, there is the role of a Business Analyst. If we define the discipline based on the role then we may potentially be too broad as the role of as business Analyst varies from organisation to organisation an em-compasses BAs working as commercial, process, financial, technical and systems analysts. If we define the role based on the discipline, then whatever the field of business analysis is, those who are specialists in this field are business analysts. This definition however could, in practice, become too narrow.

As suggested by Garrett we seem to be at an impasse “Any definition broad enough to encompass the role is too broad to foster useful discussion of the discipline; any definition narrow enough for the discipline is too narrow for the role” and “Basing either definition on the other means one is going to be insufficient. Trying to do both at once isn’t working, producing a classic chicken-and-egg problem”.

We really need to define the scope of what is business analysis and then can look at what that discipline offers in the way of frameworks and tools to its members, as the specialists in this field. If we decouple the definition of the discipline from the definition of the role entirely then we have the opportunity to concentrate on more precisely defining the discipline of business analysis.

To BA or not to BA

Published by
MariaMurphy
at 9 June, 2007 in Business analyst. 0 Comments

 

I have recently found myself promoted to the Regional Lead role for Business Analysis within my organisation. In an effort to develop this as a core capability within the organisation, I have recently been asked to mentor other BAs and develop templates and documents to assist my fellow consultants.

I find myself disillusioned with my fellow Business Analyst as there is so much confusion about the role of a Business Analyst and I find that a lot of my colleagues are happy to delegate a lot of the core Business Analysis domain to other speciality groups.

So, I started this Blog in an effort to put my thoughts on Business Analysis out there and try to navigate through the volumes of conflicting advice and opinions out there.