Social Networking Analysis

Published by
Maria (Murphy) Horrigan
at 11 December, 2008 in social computing, communication, requirements and business analysis. 0 Comments

We now live in a networked world and relationships are important to do business and do business well. In order for projects to be successful we must understand:

  • Stakeholder relationships 
  • How people are connected
  • How they communicate
  • Why they are connected

 BAs often need to identify stakeholders and entities, but often it is the social connectedness  and centrality of these stakeholders that is crucial as the relationship between stakeholders often reveals much about the organisations culture, politics and climate. Knowing these social networks can help you to identify who to involve and when to involve them during project activities.

I recently presented to the Australian Business Analysis Association and discussed social networking analysis and how this analysis can be used to help understand the degree, closeness and betweeness of users and stakeholders in order to elicit requirements and enhance project communication.

Social Networking Analysis

View SlideShare presentation or Upload your own. (tags: social media)

By knowing social network position and reltionships I can leverage champions and understand who may be the blockers or gatekeepers. This analysis can also reveal who is the “go to” person for a particular piece of the puzzle and who has great influence within the group and who is the one that others go to for advice and expertise. It also allows me to know who is the person who has the access to others and can help me to quickly disseminate information about the project.——

——

Are BA skills in demand and recession proof?

Published by
Maria (Murphy) Horrigan
at 29 November, 2008 in Uncategorized. 2 Comments

With the economic downturn of recent months, the release of the Gershon Review into ICT and a general slowdown in government spending as part of the normal election and budget cycle, I started to think about what skills and capabilities will be needed in teh future and what does this mean for the BA professional.

Lawrence Shatkin recently published “150 Recession Proof Jobs” and suggested that “the best recession-proof jobs are those that are least sensitive to economic downturn, and which have the highest combined scores for pay, projected workforce growth, and number of openings”.

Health-care has traditionally been as a recession proof career and in recent times IT has been seen the same way - that is until there is a large scale burst of the bubble (i.e. the last dotcom crash). So it was a good sign that in this US based analysis, IT jobs take the first three spots. The good news for BAs is that system analyst was the highest ranked job in the list of 150, with data communications analyst  a close second. Shatkin’s top 10 jobs are listed below:

Job Category                                                                       % Growth

1. Computer Systems Analyst                                                      29 %

2. Network System and Data Communications Analyst             53%

3. Network and Computer System Administrators                     27%

4. Registered Nurse                                                                    23%

5. Teachers                                                                                 22%

6. Physical therapist                                                                    27%

7. Physicians and Surgeons                                                        14%

8. Dental Hygienists                                                                   30%

9. Pharmacists                                                                             21%

10. Medical and health Services Management                          16%

So why is it that System Analysts rank so high on the list?

Shatkin suggests that it is  really a question about how collaborative the work is. Business Systems Analysts and Business need to work with the people who produce the information and with the people who are going to use it. BAs need to work in a collaborative fashion, preferably be on-site with the team or  be someone who can communicate very easily with the people on-site. This communication and bridging skills is very pivotal in the project team and has a big impact on the overall success or failure of a project.

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.

Gershon Review into ICT

Published by
Maria (Murphy) Horrigan
at 10 November, 2008 in Gershon Review, ICT and Impact of technology. 1 Comment

Canberra has been abuzz in ICT circles ever since the Gerson Report into ICT in the federal government arena was announced.  Sir Peter Gershon in 2003 conducted a review into teh UK Public Sector so many in Australia eagerly awaited his review of ICT.

The perception going into the review was that there is massive decentralisation of ICT in government, poor ICT outcomes and the need to strengthen whole of government management of ICT to improve efficiencies and services. However it is important to note that the review was conducted prior to the current economic and financial crisis and the ICT market in Canberra is in the midst of a slow cyclical period. As reported by Intermedium:

“Even before the economy slowed, Government ICT spending slowed as agencies took a conservative approach to procurement in the lead-up to the Federal election. Earlier this year, the impact of a number of Government measures, especially the blunt application of a 2% efficiency dividend on agency spending, began to bite in the ICT market.

The current downturn in ICT spending by the Federal Government does not reflect the economic downturn, but rather the coincidence of three cycles that uniquely affect the public sector: a change of Government (the political cycle); the first year after an election (the electoral cycle); and seasonal spending patterns (the budget cycle). However, what is worrying is that this has occurred as Australia begins to face the full force of the global financial crisis”.

The Gershon Report has been released (Oct 2008) prior to formal comment or acceptance by Cabinet. Many in the industry are trying to unpack the implications of these recommendations for their business to work out whether this is good or bad news. Has the Grinch just stolen Christmas or are there many opportunities to be found under the ICT tree in the post Gershon Review phase?

Here is a snapshot of the recommendations:

  1. Strengthen Pan-Government Governance - establishment of a ministerial committee on ICT
  2. Strengthen Agency Governance - improve agency capability
  3. Tighten Management of ICT Business as Usual (BAU)  Funding - increase development funding compared to BAU
  4. Enhance Management of Australian Public Service (APS) ICT skills base - create career structure including training and development
  5. Develop Data Centre Strategy
  6. Improve Efficiency and Effectiveness of ICT Market place
  7. Develop Whole of Government Sustainability Plan

So is this good news or bad news for the ICT industry? Well it depends. All change is good change so the focus on streamlining process and a whole of government approach may be viewed as a positive step towards making it easier to do business with government. Also the funding of development projects and building capability in ICT is certainly welcome. The question is, how long will it take to have approval for these recommendations and what will be the priorities of the federal government? •

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

Agile driven requirements

Published by
Maria (Murphy) Horrigan
at 14 October, 2008 in Agile, User centred, agile anlayst, Business Process Modeling and business analysis. 0 Comments

 One of the biggest challenges for me when developing requirements specifications, is that requirements can and do change and I’ve often struggled with the prescriptive “waterfall life-cycle” approach to software development. This sequential process does not guarantee success of the project nor does it decrease risk, in fact it is often the opposite as this process does not support change or vital feedback from users and the business.

I wrote about the BA life-cycle awhile back when I embarked on a project that was stalled and despite extensive analysis, the project had not yet begun development and we could not get sign-off or agreement on the requirements for this complex system. We had hundreds of Use Cases, lots of Architecture design documents, User scenarios and volumes of analysis and feedback gained over two years of review of the problem to be addressed, in short, the bureaucrats had taken over and we were in analysis paralysis.It was “groundhog day” as neither the business nor the development team had a clear idea of how to move forward. To jump start the process we adopted an agile approach.

The Agile Alliance Manifesto defines four values of encouraging better ways to develop software:

  1. Individuals and interactions over processes and tools - the most important factors to consider are people and how they work together. User and Stakeholder engagement is vital
  2. Working software over comprehensive development - we are there to create a system, not documents (although it is noted that documentation is important for our understanding of the system and some documentation is required to understand how and why a system was built). As Jonathan recently asked in his blog does paperwork really add any value?
  3. Customer collaboration over contract negotiation - customers are unlikely to be able to fully specify the system they want, they will not get it right at first and they are likely to change their minds, therefore communication  and collaboration is vital.
  4. Respond to change over following a plan - I know all the project managers who cling to their Gannt charts will cringe at this but change is a reality and the software development process must reflect this.  You need a project plan approach that is flexible

The key trigger to our move to agile was that the Change Manager took over responsibility for Project Lead. Myself and my colleague Matt in the design and analysis team, were charged with the task to  think differently, be innovative and just make it happen. Given the User Centred Design focus of me and Matt and our colleagues, its not surprising that we focused on the people orientated issues, the Users understanding of the business processes and followed analysis techniques that readily supported change and flexibility. We used storyboards, iterative prototyping and business process mapping notation (BPMN) to convey and confirm the requirements and before long we had a working prototype that the business had approved and sign-offed.

We have embarked on three new projects since this original foray into agile, and are refining our documents and processes. It’s quite exciting as many of the developers and business teams we are working in, were at first a little nervous about the “agile” approach as they are traditionally quite risk adverse, however they are now seeing real benefits. Matt recently blogged about the tools we are using to specifiy design and requirements. These tools and techniques are easy for the business to understand, flexible enough to meet their changing needs and allowing greater collaboration. To the bottom line - this is saving them time, they understand what they are signing off on  and its also giving them a more useable end product.

Capitalising on female archetype strenghts in IT

Published by
Maria (Murphy) Horrigan
at 9 October, 2008 in social computing, Women in ICT, communication and Uncategorized. 2 Comments

I recently was asked to speak at a conference on attracting and retaining women in the IT industry. This was mainly aimed at IT managers, HR managers and project managers.The topic I was asked to present was capitalising on female strengths in IT.

I stuggled at first as I wanted to ensure my presentation was positive and personal (tell my story). I really didn’t want the topic to focus on what women are good at and be seen as inferring that male colleagues necessarily lack these qualities (as they don’t). WE are all a mix of our background and experience and we use our strengths within the context of the situation we are facing.

What I discussed is that the typical female archetypes

Capitialising On Female Strenghts 4 Sept 2008 V5
View SlideShare presentation or Upload your own. (tags: women in)

These archetypes have both strenghts and weaknesses and the key is knowing when to capitilise on these.

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.