Yes I know i have been quite lately but in recent months. However i have been active again thsi year, I have changed jobs and started a new blog with my BFF and project partner, Matt Hodgson. Our blog is called - ZenAgile.
We started the blog as we found ourselves on a difficult project and started to intuitively use our IA user centred design methodologies to cope with a dynamic and changing requirements environment. We discovered later this was called “Agile”.
So what is ZenAgile? WellZen Agile is a philosophical approach to leading projects and embracing the ever-present flow of changes to project environment.
I am finding that increasingly as an enterprise BA I am often working on large scale projects and because of my PM and business background, am often called upon to be the “Scrum Master” or “Product Champion” for my business client. Agile is a way for me to help manage the changing requirements and juggle the ever present tension between budgets and functionality. Agile helps me to prioritise features and work more closely with the business to achieve their strategic intent and obtain a win/win for all.
So BA rocks might be a bit quite for awhile, but check out my posts on ZenAgile
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.
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.
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.
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”.
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.
Well I’ve been a bit quite of late as I have been on some much needed rest and relaxation so I have sadly neglected my blog.
I have had a number of comments with suggested tools to consider and comments wanting to know which requirements management tool we choose. After a couple of months of assessing different requirements management applications we did propose Holocentric to the management team. We liked its requirements management flexibility, business process mapping, ability to map relationship and traceability.
We hit a wall though when it can to implementation and unfortunately have had to go back to our previous tools. There were two main barriers.
1. Cost: Set up costs of initial training and licences required to to use the product (these costs were not part of the original project budget so would require new funding).
2. Downtime: We had invested so much time already using the current tools that to convert our current work to the new software would mean a lot of rework to get to the same point and extend the project time-lines.
So, whilst it was too late for this particular project, we now are aware of other tools out there and can captilise on these for our next project.
Scope creep is annoying, but what is more annoying is doing all the business process maps and documentation in visio and word. The changes and flow-on affects of these changes then need to be manually changed in the documents.
I am currently looking at some software tools to support my current project so that I can have enhanced traceability and be able to quickly work out what requirements are impacted when a certain element changes (eg cannot now be delivered in this current release).
I am working in an agile environment where there is rapid change and the business needs are evolving and this needs to be manged. Requirements are never really complete until the project is finished as the needs of the business will inevitably change over the life of the project development. Telling the business “it is not in the spec” doesn’t solve the issue that they need this change.
In this type of environment it important to know the “ripple” effects of a change to a particular requirement (eg architecture, design, code, tests and deployment). What a first may be a minor change, can indeed be very costly.
Requirements management done well can help your project to deliver the benefits the business is looking for, without you having to get frustrated by the process. I am hoping that the tools we evaluate may help to support our requirements process and help to ensure we can adapt to the rapid changes required in this agile environment.
Recently I attended a session on the “7 Pillars of Wisdom-Requirements” by Suzanne and James Robertson. It was a great session and reinforced what I have been thinking for some time about why some BAs succeed and others do not.
The fourth pillar that they spoke about was that “requirements come from people”. This I believe is the key message for BAs. Yes business analysis is about the business and the system, but it is also about the “people”, the “users”.
My background before the BA life was business management and communication. My technical expertise has been learnt from experience at both the client and technology group end. I really agree with Suzanne and James that gathering requirements is a “sociotechnical” business. You do indeed need to find out who all the stakeholders are to find out all the requirements. You also need to keep them interested and motivated throughout the process and that’s about communication.
People love to talk about their business. If you take the time to really listen you will uncover what they like and don’t like about a process and what opportunities they see for improvement. Getting initial interaction to get some high level requirements is the first step, but not the only step. The systems that are developed right, are the ones where there has been stakeholder engagement from start to finish.
Unlike some of my collegaues, as a BA, I don’t think the process finishes when I have delivered the requirements document. I believe it is only the start. Keeping the stakeholder engaged through the development and testing process means maintaining a level of enthusiasm and passion for the project. OK, I admit that sometimes this role may be filled by the project manager, but I find, that if as a BA you have developed a great working relationship with the client, your passion and enthusiasm for the project will help ensure you get requirements that are not only sound from a technical perspective (as you have uncovered all the needs for the system) but you also have a system that works from a useablity perspective. Happy User = Happy Client
Recent Comments