Archive for the 'Business analyst' Category

What makes a good business analyst

Published by
Maria (Murphy) Horrigan
at 24 August, 2009 in ABAA, Business analyst, communication and business analysis. 3 Comments

At our recent ABAA meeting here in Canberra, Phil Rich, a Senior BA, discussed what makes a good business analyst (presentation is now on slideshare). Phil’s presentation was particularly interesting given his journalism back ground. His key points on journalism and business anlaysis were that:

  • if you can’t interview you can’t get information
  • if you can’t write you can’t communicate
  • if you can’t write quickly, you are already in trouble……

When interviewing, it is important to know who you are interviewing. This is critical and as I discussed in a previous blog on social networking analysis, often we can become unstuck when we work into an interview without doing some background only to find that the this person was the key influencer and you find that you didn’t make teh most of teh  session as you didn’t know “who was who in the zoo”.I recently spoke at BAWorld in Sydney and Melbourne on Communication and Connectedness in our Networked World. I stressed that it is important to know who you are interviewing, not just by their formal position on the organisational chart, but also by style, personality and group role on the project. This helps you identify who are the influencers, gatekeepers, blockers and supporters.

Ultimately one of the keys to successful requirements gathering and interviewing, is to know your audience.

Communicating requirements to different stakeholders

Published by
Maria (Murphy) Horrigan
at 15 November, 2008 in Business analyst, communication and requirements. 0 Comments

We have all worked in project teams with vastly different stakeholders. This is challenging as we all think, act, make decisions, listen and want information differently. We therefore need to understand how our stakeholders want to communicate in order to ensure our requirements analysis is effective. This means that as BAs we need to recognise the different styles of behaviour and adapt our style to the audience we are communicating with.

There are many behavioural styles models and most stem from a sales focus to help salespeople better understand customer needs. Most of these types of behavioural models are very generalised and try to explain a very complex thing (behaviour) in an easily digestible form .

I have been using Ron Willingham’s Integrity Selling Behaviour Style Model recently as it is an easy way for me to remember to adjust my style to suit my stakeholder and by knowing my own style or behavioural preference, i can make sure that i compliment rather than clash with my audience or team members.

Like all of these types of models are very generalised and try to explain a very complex thing (behaviour) in an easily digestible form. Essentially this behavioural style model looks at a person’s orientation towards process vs results and their need for recognition vs need for security. This divides behaviour into four main styles:

  • Talker - outgoing, friendly and easy to approach. They are process orientated and need recognition therefore may find making decisions difficult as they don’t want to disappoint anyone.
  • Doer - people who get it done, are action orientated and decisive. They are often pressed for time and make quick decision once they have a grasp of the key facts as they are achievement orientated.
  • Supporter - easygoing, steady and dependable. They are often slow to make decisions as they are detailed minded and want predictability and security. They are risk adverse
  • Controller - Very logical and may appear reserved. They crave facts and information and are very analytical and organised. They will make decisions only after careful consideration as need to get it right is more important than the need to be quick.

Many of my stakeholders have a very different style to me.  I am a “Doer” and a “Controller” so I can be very analytical and results focused so I need to be mindful of bring people along with me rather than trying to push to hard as this is not going to work with my largely “Supporter” risk adverse audience.

It is important to know your own style and use the strengths of this style to communicate to your audience and adapt your style to the different stakeholders you will encounter on a project. When I am working with other Doers, it is great, however it is important to have a mix on a project team so diversity ensures we don’t end up with “group think“. There is no particular style that is better than the other nor one that as BAs we need to adopt in order to be successful. The style to adopt will be contextual and situational so be flexible and think about your audience so that your communication will be effective.

Agile is “so hot right now”

Published by
Maria (Murphy) Horrigan
at 6 November, 2008 in Agile, User centred, Business needs, Business analyst and requirements. 0 Comments

To paraphrase a Zoolander quote, Agile is “so hot right now”. When you ask business areas and IT managers what they are interested in, they respond that they want to be more agile in order to adapt in a changing environment. What is it that everyone wants to be agile? Agile is not new, but it has had a resurgence of late and this is probably due to the fact that in a fast paced world where change is a constant, the word agile seems reassuring and positive, but are we all talking about the same thing?

I asked a BA user group meeting recently what they thought agile meant and they proposed it was about “flexibility”, “adaptability”, “iterations”, “prototyping”,”light weight documentation”, “adapting to change” and “saving time and money”.

There are many Agile Methodologies (AM) including Extreme programming (XP), Feature Driven Development (FDD) and Scrum. Each has its basis in the engineering or project management disciplines and lean more towards one or the other.

XP has its basis from the engineering discipline and focuses on the critical activities required to build the software and requires with developers to be directly involved with project stakeholders who need to actively participate in the process. Scrum tends to come from more a project management focus and it was originally intended for management of software development projects but is now used as a way to run software teams and break the development into sprint cycles to development increments of the software. FDD sits some where between the two and includes explicit modelling activities that is driven from a client valued functionality (feature) perspective. The common themes and threads across all three seem to be user orientation, need for user involvement and the need to resolve uncertainty regarding requirements.

What these AMs have in common is that these agile methods can help streamline your modelling and documentation efforts as they are an enabling technique for evolutionary development. There is a danger that  some may use “agile” as an excuse to having no requirements or no documentation and to just go ahead an build whatever they want without thought to the user or system purpose. This is not in the true spirit of agile.

Agile has become more a philosophy rather than a methodology in the strict sense of the word and that may explain why agile means different things to different people. So whilst it is not easy to tell what agile is, agile is now what we all should subscribe to be.

Communicating requirements is vital

Published by
Maria (Murphy) Horrigan
at 3 November, 2008 in Business Process Modeling, Business analyst and communication. 0 Comments

As BAs, our requirements analysis is not done by simply sitting down at our desk and developing requirements based on a template we used previously. It can only be done by getting out and talking to users about what they require the system to do and then building systems that satisfy these requirements.

Ultimately our requirements analysis results in a specification which clearly describes what needs to be built. The communication of this specification to users and developers is where it gets tricky as there are many different ways that requirements can be specified. There are models, business process maps, use cases, prototypes and simulations. There is no one right path and we need to use the tools and techniques most appropriate to our audience and context.

If the users or the business do not understand what we are specifying in the requirements, then how can they sign off on the specification? Equally, our developers need to use the requirements specification to build the system  and need to be able to understand what the implemented system will look like.

Whilst I like Use Cases, as this was the foundation for me when first learning how to do requirements specifications, I have found more recently, that business process modelling notation (BPMN) is perhaps a better way to communicate to my business user audience. So its not about me and how I like to write requirements, its about my audience (business users and developers) and finding a tool or technique that communicates the requirements in a clear manner and decreases ambiguity.

The communication of the requirements specification in this BPMN visual form is suited to the business user as it is business orientated. Whilst this notation is readily understandable by business users, it also speaks to the technical developers and can help to bridge the gap between business process design and process implementation.

As a communication tool, BPMN clearly shows the end to end process, where the user interacts with the system and how the process may change from the current “as is” process. More and more, the business area is being asked to take an active interest in the development of their business systems so we as BAs need to ensure our tools facilitate communication about requirements.

The Role of a BA in an agile environment

Published by
Maria (Murphy) Horrigan
at 25 October, 2008 in Agile, ABAA and Business analyst. 0 Comments

I have been doing agile software development projects for awhile now, so i asked a business analysis colleague, Mark Foley to come and talk to the User group meeting I organize bimonthly for the ABAA in Canberra.

The role of the BA in an agile environment is a hot topic at the moment so we had over 30 Business Analyst attend the User Group Meeting on the 23rd of October. Mark Foley is a principal consultant from Borland, and he shared his insights into the emergence of agile as a methodology over the last ten years from the Chrysler motor car 3Cs beginnings of XP to today’s scrum sprints. Mark’s presentation is below as he kindly has allowed me to put it up on the ABAA site and slideshare.

Mark Foley Agile Methods And The Business Analystc

View SlideShare presentation or Upload your own.

Everyone it seems wants to be agile but it is not a magic formula and not suited to all projects.

We discussed the key elements of agile and how this can help our projects be more flexible, adaptive as through sprints we can develop and evolve the requirements with the business and users. Mark discussed that agile can be used across large geographically dispersed teams and in the government setting, agile is still relevant as documentation of the sprints as used in scrum, can help stakeholder understand the system and be more involved as the customer representative.

Regards

BA World Symposium

Published by
Maria (Murphy) Horrigan
at 26 July, 2008 in Business analyst and business analysis. 0 Comments

Have just returned from the BA World Symposium held last week in Sydney and Melbourne. It was great to catch up with so many BA practitioners and share our ideas, tools and methodologies. The conference attendance was around 200 in each city (double the attendance of last year) so it was great to see our BA “community of practice: is thriving :)

I presented at the conference on the changing role of a BA and uploaded my slides to slideshare. My colleague Matt Hodgson also presented user centered design tools and  BAs langauage and legos, so don’t forget to check out his slides as well.

Maria Spotting - Conference presentations till September

Published by
Maria (Murphy) Horrigan
at 13 July, 2008 in presentation, Business analyst and business analysis. 1 Comment

Recently I have been asked to present at a number of conferences so here are my speaker engagements for the next three months.

1. First up is BA World Symposium Melbourne 21-22 July in Melbourne.

My topic is “Struggling to define Business Analysis and the Role of a BA“. In this presentation I will explore:

  • The Role of a BA vs. the Discipline of Business Analysis – which are very different.
  • Suggest that we need to come together as a community of practice to define the discipline and the role of a BA.
  • Opportunity to more precisely define the discipline and then we can work on developing a competency framework to define the role.

I will also be joining the panel to discuss “The role of the BA in an Agile environment?”. In this session the panel will discuss the benefits and challenges of transitioning your Requirements approach from more traditional methodologies to an Agile environment. The Panel will focus on what’s different, what’s the same, and how to apply the Agile principles to Requirements; as well as understanding what to do differently for the Requirements approach in an Agile environment to work effectively.

2. BA World Symposium Series 24-25 July 2008 Sydney

My topic will be “The Changing role of a BA- from requirements elicitation to Change Manager and Trusted Advisor”. In this session I hope to discuss how the role of BA can not be easily defined as we utilise a number of frameworks and methodologies that are similar in other disciplines such as project Management and Information Architecture. I will discuss how analysis skills are valued throughout the life of a project and therefore our role should not end once requirements have been delivered as our business savvy skills makes us an important part of the change process and a trusted advisor to the business area.

This will be the essentially same talk in both cities since there’s no one I can think of who will go to both these events (except maybe me and Matt who is also presenting)

3. ABAA User Group Meeting Aug 2008 (date TBC)

I will be presenting to the group on Business Analsyis Lifecycle and BA Frameworks. Capitialising on the body of knowledge out there from various organistions and individuals in order to develop our frameworks through our community of practice.

4. Attracting, Retaining and Advancing Women In IT Conference 4 Sept 2008

I will be discussing how to “Capitalise on Female Strengths in an IT environment”. The key areas explored include:

  • Identifying areas where women excel and capitalise in these
  • How to use corporate relationships for networking
  • Gaining an edge through customer liaison and interaction
  • Communication and people skills
  • Understanding the importance of knowing the business

So a busy couple of months ahead. Hope to see some of you at these events :)

We all need heroes

Published by
Maria (Murphy) Horrigan
at 10 June, 2008 in Business analyst and business analysis. 0 Comments

We have had a lot of new starters at work recently and I was asked to give an overview of business analysis. It is one of many core capabilities and service offerings competing for recognition within our organisation. Project Management and ITIL are the most popular communities of practice. I think this is because consultants in these areas tend to be highly paid in comparison to BAs as these roles often have an element of strategic project coordination and communication with the executive or project governance board.

I thought I would show how the capabilities of a BA are wide ranging and can add value and support throughout the life of a project.  We all need heores is not about BAs being Superman and “coming in to save the day” but rather, we are the support and quiet strenght within the project team - the “reluctant heroes” that have a lot of skills and capabilities to offer. We all need heroes ………

SlideShare | View | Upload your own

As BAs we often use differing abilities in order to deliver what is required for our client area.  We support projects and our analysis skills can be utilised during the various phases of system development and delivery of a project and the discipline of Business Analysis has much to offer with proven methodologies, frameworks and tools to help you get the job done.

 

Business Analysis Life Cycle

Published by
Maria (Murphy) Horrigan
at 6 June, 2008 in framework, Business analyst and business analysis. 7 Comments

Those performing Business Analysis are typically known as Business Analysts (BAs) and often work in dynamic environments where change is not only anticipated, but is expected and embraced. I was recently asked to look at developing a Business Analysis Life Cycle to help frame an approach to BA work. I started with the broad definition of Business Analysis -  as a vehicle to generate and present unambiguous information to help facilitate the decision making process and deliver business outcomes and stressed that the and involves a portfolio of techniques that focus on demonstrating an understanding of the client’s needs and identifying how best to meet those needs.

I believe Business Analysis is increasingly encompassing broader organisational challenges (e.g. strategic planning and business health checks) and solutions to business problems, which may include systems, processes, organisational change or a combination of these.  Whetehr you are a Systems BA, Process BA or Finacial BA, the discipline of Busienss Analsysis is a core caspability. As a consultant this core capability, Business Analysis, is achieved through developing effective relationships with the business and technology Subject Matter Experts (SMEs), extracting, analysing and presenting relevant information to ensure key stakeholders have a common expectation of the quality, scope, cost and benefits of the preferred solution. It very much about facilitation and communication of requirements to meet needs of stakeholders.

To develop the Business Analysis Life Cycle (BALC) I reviewed the framework of the key BA professional bodies:

·         IIBA - International Institute of Business Analysis

 ·         ABAA – Australian Business Analysis Association

and found that the key concepts of any BA life cycle are: 

·         Establish and define the purpose of business analysis;

·         Establish and define the core activities an BA may be required to undertake in achieving the business purpose; and

·         Establish and define the key facilitating processes and resources that will support an BA in achieving analysis objectives.

It is important that the BALC reflects the iterative facilitation and co-ordination processes undertaken in dynamic environments  and therefore the following skills/governance actions of  Communication,  Planning and  Control are central to the approach and support the core elements/activities of the BA role and reflects the analytical process from initiation/definition through to conclusion. I see these six phases as:

1.       Initiation and Scoping

2.       Research and Analysis

3.       Requirements Specification

4.       Design

5.       Development and Implementation

6.       Evaluation and Conclusion

Enterprise Architecture and Business Analysts - companions or competitors?

Published by
Maria (Murphy) Horrigan
at 22 May, 2008 in enterprise architecture and Business analyst. 0 Comments

I asked my friend “billy” to speak at the recent ABAA user group meeting in Canberra. He is an Enterprise Architect and we often discuss BA vs EA approaches to client problems. In discussing this presentation, it promoted Billy to pose the question - “Enterprise Architects and Business Analysts, Companions or Competitors”.

Often we think Business Analysts are not working in a strategic space, but it was interesting to see from Billy’s presentation, that there is lot more crossover of BA skills and capabilities into this area than he had first realised.

or career progression, often BAs fell they need to look to project management to get a piece of the strategic action. However, I feel that more and more, BAs can look at complimentary areas such as Enterprise Architecture and Information Architecture. Exposure to these areas can expand their experiences and help them to develop a portfolio of skills that are highly valued in the IT strategic planning sphere.