How do BAs make meaningful differences?

But as a business analyst, how do we make a difference? When we get up in the morning, how much of the reason why is because we want to get out there and make a positive impact? It’s a bit more difficult to see straight away as compared to say, a nurse or a doctor, but if we peel away some of the layers and really think about it, we do put people in better positions than what they were before we came around. It’s more subtle than saving a life (and I’m not going to argue that it’s more valuable!), but it is important and it does make a difference.

If we do our work right, people will have a happier work environment. If we make project interactions pleasant and fun, people will enjoy themselves more. If we really listen to what people have to say and take their suggestions to heart and incorporate it into the project change, they will know that they are making a difference. They will get out of bed with a stronger sense of purpose, a clearer validation of why they didn’t remain under the sheets.

This is one of the things that gives me purpose, one of the reasons why I get out of bed. If I’ve helped individuals be happier at work, I’ve helped them be happier at home, in their families, in their communities, with themselves. Roughly 33% of our life is spent at work so if you’re not happy at work, that is going to impact your happiness away from work.

The above thinking really does motivate me. But it may be a bit too abstract for some people. So how about a more tangible difference?

A more concrete difference

As we are all too well aware, the current financial turmoil in the world is partly due to individual greed. While I do not buy into the whole “witch-hunt” for bankers, no one can argue that a few self-centred individuals helped get us into this situation. And the man-on-the-street taxpayer has had to fork out plenty of cash to keep the system afloat.

Here in the UK, in an attempt to make the system more stable, regulators created the Independent Commission on Banking. This was headed by a man called Sir John Vickers, and the final recommendation report (a.k.a. the Vickers Report) was published in September 2011.

The report focuses on creating stability in the banking sector, as well as making the banking sector more competitive. Both are driven out of the need to protect consumers. In terms of stability, one of the suggestions is to separate retail banking from investment banking, to insulate the taxpayer from risky bets made by investment bankers.

While I have no problem with investment banks, I support the principle of insulation of core banking services that normal individuals require. I don’t think that banks should be too big to fail, and I see merit in protecting the taxpayer. Investment banks should be allowed to take risks, to grow, but when that risk backfires, they should be allowed to fail, to go insolvent. And this must not impact regular Joes like you and me on the street.

As BAs we have the potential to really make a difference to people’s lives. We’re not yet sure how this particular legislation will actually take shape, but whatever the final outcome, BAs will be required to understand the changes and then implement them. Systems will require decoupling, processes will need to be re-engineered, new technology will need to be designed. It will give BAs a real, concrete chance to make a difference to millions of people; to put people in a better position when the next financial crash occurs.

Not convinced?

Are you happy at work? I know a lot of BAs who love what they do, and if you explore the reasons with them it tends to boil down to having meaningful relationships with people. BAs love creating strong networks, we love bridging that gap. We don’t understand when IT and business don’t get along, and drag the project into the mud.

We want to move forward, to put the project in a better place than where it was before we arrived, to put the company in a better place than where it was before the project started. We want to understand people, and reflect that understanding in our work. Through this understanding we create strong relationships that break down silos, which inevitably make people happier.

We often need the concrete evidence to feel like we are making a difference. These examples are such as the Vickers Report – you can see a real difference being made to customers. But the softer things are just as real, a happier employee will contribute more at work, at home, in the community. We do make a difference; remember that next time you hit the snooze button!

The Vickers Report is just one example of how BAs can make a difference. There are others – which have you come across?

This article originally appeared on Bridging the Gap on 24 February 2012. Click here to view the original article.

The post BAs make the world a better place – Ryan Knapton appeared first on BSG (UK).

Over the past few years I have come to realise that business stakeholders are growing in their understanding of technology. Does this understanding carry an advantage, a risk, or aspects of both within the project world?

In my early years as an analyst, I remember working on a particular project and jotting down business requirements that were delivered from a strategic perspective. It was blatantly clear that these requirements were carefully derived to support an organisation’s strategic mission. I discussed these with the technical stakeholder before committing to the business what could or could not be delivered.

In these discussions, I realised that many of the requirements were either a) technologically impossible within the current landscape or b) going to take much longer to complete than what the project allowed. In order to ensure that all avenues had been explored, I held workshops with the technical stakeholders to uncover alternative options or workarounds.

Challenging the challenges

My next step was to sit down with the business stakeholders and explain to them why some of the proposed requirements were not as feasible as was originally anticipated. They accepted some of the workaround suggestions, but didn’t think twice about those that would in any way compromise the ultimate, organisational strategic objective. The short of it was that I needed to sit down with the technical stakeholders again and thrash out workarounds for the ‘non-negotiable’ requirements. These would need to provide the same result – within the original timeline and budgetary constraints of course. Needless to say, long hours and vast amounts of effort ensued.

What was important here was that the business knew what they wanted and compromises to the strategic objective were not in question. Whenever requirement negotiations went on, the business stakeholders would keep that ultimate objective in mind. Everybody in the discussions knew what they wanted and more importantly, they knew why they wanted it.

We can meet objectives, or we can meet objectives

In contrast to the above and on a more recent project, I worked with a particular stakeholder who picked up information very quickly. He took the time to sit down, learn about the technologies in question and ultimately deliver better formulated requirements. I say ‘better’ in a very loose manner as these requirements were only better if seen from a specific perspective. The developers for example, enjoyed discussing requirements with the stakeholder, as they were never far reaching or difficult to understand.

What resulted was functionality that was designed around the limitations of a system, rather than requirements that were aligned to a strategic objective. The difficulty here was managing the stakeholder and asking him to take a step back and consider whether the requirements he had provided were in line with the original strategic objective of the system implementation.

If this is not managed correctly, a danger exists that a compromised system is delivered, that meets the revised business objectives, but no longer aligns to the original strategic objective of the organisation. It’s an imperative step to move out of the detail every so often and ask that all important question – Why? Why are we implementing this? Why is this project taking place? Having a business stakeholder step into the technological realm is a bit like having Darth Vader step over to the light side. You lose the story. In this case, you lose your user story.

Is the meaning of ‘requirement’ getting lost?

The role that I needed to play on this project was very different to the one I played on the project where the stakeholders took no interest in the technicalities of delivering the system. My view is that the role of the business analyst is to implement benefits driven change. To achieve this, it is necessary for the BA to understand how stakeholders approach the requirements conversation and to stand up for the benefits appropriately.

Sometimes requirements need to be challenged, even when they’re easily implemented. I understand that this approach might expose a more complex requirement, which could in turn impact delivery timelines. However, this ensures that a strategically aligned system is delivered, and not just an easily implemented system. To answer the opening question, I believe that having business stakeholders with technological knowledge holds both advantages and disadvantages. In order to make the most of it though, somebody needs to ‘keep an eye on the game’. That somebody is the analyst.

Having said this, I’m left curious to understand if this observation is unique to the projects that I have worked on, or if this is something that other analysts have also experienced? Are stakeholders becoming more technologically aware?

Do you believe that business stakeholders should focus on the business requirements and ensure that they’re delivered regardless of the technological challenges?

This article originally appeared on the Bridging the gap. Click here to view the original article.

The post To technology or not to technology – Nik Gebhard appeared first on BSG (UK).

Nik Gebhard recently spoke about vendors who “seem to be inordinately skilled at pulling the wool over business’ eyes”. These vendors have great sales pitches and get companies to invest vast sums of money in technologies that may not be the right fit for their organisation. The vendor throws in some golf days, a few logo-emblazoned t-shirts and some fancy lunches and the next thing you know, the sales pitch has worked.

Why the board should not make the decision

I appreciate that the above view is fairly cynical, but I’ve seen it happen enough times to not naively believe that all vendors are saints. They target the people in the business who can sign off costs. So the angle I want to explore is around when the decision to go with a specific vendor is made at a board level. Boards do not work in the detail; they are not “at the coal face”. When vendors are pitching their products to senior management, they are selling a concept, one which people in the detail will have to make work (which in principle is not a bad thing). But where a board is not accustomed to consulting downwards within their organisation, big problems are likely to occur; projects fail when the detailed truth is incompatible with the vendor’s version of reality.

Make it about the journey

The board would have been told that the new system will solve all their problems. But if no consideration is given to the people using the system, then the same issues may still occur in the future; they will just manifest themselves in a different shape. We all know that garbage in gives us garbage out. No matter what technology is used, if it’s not used properly by the users the system will be deemed a failure.

In my experiences people are willing to change, as long as they are taken along for the journey. If employees have to change the way they work, they want to feel like they contributed to the change, that they were heard. If the board approves a vendor without proper engagement and the employees see the CIO, CFO and CEO all walking around in shiny new golf shirts on casual Friday, they will feel bitter. They will feel that the new system was thrust upon them because Joe Soap knew Frank Black at school and, invariably, the rumours around the corridor will be about how much kick-back was paid out.

A few years ago, Susan Penny Brown said in an interview with Laura Brandenburg that a project team can eliminate the majority of vendors based on the top 5 needs of the business and “begin to talk to the vendors that are a potential fit specifically about the more detailed requirements”. All too often the decision around which vendor to go with is decided in the boardroom based on a high level sales pitch. Vendor assessments cannot happen at this level – detailed analysis is required and employee buy-in needs to be created.

So what should BAs do?

A BA’s role is to ensure that the vendors’ sales pitches are evaluated thoroughly against the detailed truth. We need to guide the board (or whoever has their ear) to understand that what vendors say and show during their pitches has been carefully crafted to win the business, not to actually implement the system. And once the vendor has been selected based on sound reasoning, one of the BA’s roles is to take the users along for the journey. Once a board approves a vendor’s IT system, the board starts to think about the next journey, the next big strategic initiative. They forget that the rest of their employees are only just climbing on board, or have even refused to buy a ticket.

This article originally appeared on Bridging the Gap on 14 December 2011. Click here to view the original article.

The post Why board members are the wrong people to decide IT vendors – Ryan Knapton appeared first on BSG (UK).

No question, no gain

From the onset it’s evident that the project is about replacing the CDS with the QLT. Before long a seemingly uninterested attendee enters the room. It’s Gary from RGM. You remember that RGM is the department that is strongly opposing the project. It’s ok though, because if the system can adapt to the existing LGM and then bypass whatever it is that’s stopping it in GDR, the benefits will greatly outweigh the resistance put up by RGM. Obviously it’s all down to the timing though, because project Wolf is underway and creates a major dependency for this project. The session draws to a close. You look around the room and the stakeholders seem satisfied. It looks like they got exactly what they wanted from the session.

You look down at your notepad and there are a bunch of acronyms, question marks and additional names that were picked up in conversation. Right, it’s up to you. Go forth and do the analysis and deliver something awesome by Friday. Thanks.

This is unfortunately, a position that many analysts find themselves in too often. I know this, because I have had this conversation many times before.

Question all, assume nothing

Let’s replay this scenario. The conversation kicks off and acronym one rears its ugly head. You interrupt the conversation and sheepishly question: “CDS?”  You receive the anticipated ‘idiot’ glare from across the room, followed by: “Yes, Customer Data System. You know, where we keep the customer data stuff…” That’ll teach you to ask stupid questions.

After the fall, you get up, brush yourself off, and brave the next question. “What type of customer data?” “Well, it stores names, addresses, telephone numbers…” There’s a brief hesitation – “And relationship information” shouts a voice from across the room. “Does it?” questions the original attacker. “Of course it does; that’s where we get all the information we provide Marketing.”

Hmm… the attacker needed help this time round. Perhaps they don’t know everything. “What type of relationship information?” you ask. The original attacker cautiously answers, “We store information related to the type of products customers are interested in, so that Marketing can target them specifically.” You quickly fire in the next question, “Is that information collated into specific groups, or is it a free text field?”  There’s a moment of silence. You look around the room in anticipation for an answer. Nothing.

Questions can be more powerful than statements

The question is parked and the conversation swiftly picks up again. Acronym number two comes up and you ascertain that QLT stands for ‘Quick Leasing Tool’. It’s the name of the project after all. The meeting room door opens and a seemingly uninterested attendee sneaks in. There’s a pause and the facilitator points out that this is Gary from RGM. Notice how easily the next acronym snuck in there? You guessed the second one and it’s time to confirm this one. “RGM… Marketing? “Yes, Retail Group Marketing” Gary confirms.

Excellent, we’re making progress. You remember that he’s from the department that is strongly opposing the project. “Can Gary answer the question we parked earlier?” you ask. Gary wraps his mind around the question and immediately expresses his frustration. “It’s a free text field. It’s amazing how many ways there are of writing the same thing!” “How do you target specific customer groups from this information?” you ask. Gary shows more frustration as he passionately explains how a single employee spends their time sifting through the information to identify potential target groups. This is why the communications to customers are always late.

“Why don’t we collate this information into specific groups asks the facilitator?”  Excellent, they’ve asked the question that you couldn’t, because you don’t want to make promises on functionality this early on. Gary explains that this wasn’t thought about when the system was originally designed in 1992. “You mean we can change the way this is captured in the future?” he asks. Gary’s interest in the project has suddenly increased – and so has your value add. “Yes” answers the facilitator. “It’s why we’re implementing this project, to improve the quality of data we get from the system.” Have we just changed Gary’s position from ‘strongly opposed’ to ‘mild interest’?

Stupid questions are only as stupid as the assumptions that support them

So what does this story demonstrate? Part of an analyst’s job is to bring previous project experience and innovative thinking to the table. By asking the ‘stupid’ questions, they break down assumptions and demonstrate to stakeholders why obvious questions aren’t as instinctive as they seem at face value. Stupid questions are only as stupid as the assumptions that support them.

As an analyst you need to challenge what you hear. You need to seek clarity when you’re unsure and most importantly – never assume. Never ever assume. You’d be surprised how often I have asked a question, only to hear someone say, “Thank goodness someone else doesn’t know,” or “I was about to ask the same thing.”  If you don’t know something, it’s quite likely that someone else around the table doesn’t either. And if you are the only one that’s learning from the question, then at the very least you’ll be able to follow the rest of the conversation.

Never be afraid to question, never be afraid to challenge assumptions and never be afraid to analyse. Ultimately, the analyst needs to understand – that’s why they’re there. The only stupid question left to ask is… Why aren’t you doing this already?

What ‘stupid’ questions do you wish you had asked on your last project? Share your experiences below in the comments.

This article originally appeared on Bridging the Gap on 3 November 2011. Click here to view the original article.

The post The stupid analyst – Nik Gebhard appeared first on BSG (UK).

Innovation requires support

In response to my last post, “The best methodology is freedom“, I have had a number of questions around how a culture of freedom and innovation can be established. There is little merit in compiling a rulebook for promoting such behaviour. I don’t want to get into the dos and don’ts for embedding it. That would be counter-productive. I’d be advocating freedom and innovation and then prescribing a one best way to achieve it.

I believe that a guideline for creating a culture of creativity and innovation is less important than the outcome. What’s important is how an analyst is supported in being innovative. In this way, a unique structure can be tailored to underpin a culture of innovation, rather than having the structure dictated.

An environment that lends itself to innovation is one where analysts not only feel comfortable putting forward creative suggestions, but are encouraged to do so. New ideas should never be frowned upon or laughed at; no matter how trivial or how extreme. In fact, they should be celebrated and rewarded.

It is also important that analysts receive appropriate feedback from colleagues. If an idea is not going to fly the analyst needs to understand why. Our organisation has recently introduced ‘innovation boards’ where new ideas can be noted and become visible to all. This opens the door for questions and feedback from colleagues.

The natural tension between prescription and innovation

My previous post talked about methodology and freedom and how innovation is key to an analyst’s job. I strongly believe that fewer constraints bring greater innovation. This may seem obvious, but how often is it considered when guidelines are being compiled? Do the guidelines at your workplace offer leeway? If my project’s office wasn’t flexible in its project governance, there would be no room for innovation. If it were mandatory to complete documents x, y and z for each project and the sections within these documents were inflexible, not only would I struggle to keep the content relevant, but there’d also be no encouragement to innovate.

I’m not advocating lawlessness, but I am saying that too much structure has the ability to cripple innovation. There is a happy medium where structure and innovation can live together peacefully – even support each other. I believe that a good, flexible structure helps guide the direction of innovative thinking. If I know that risk mitigation method A, which forms part of the project structure, has proven to reduce the likelihood of project failure, I may want to consider incorporating this, or a similar, method into my thinking.

With great innovation comes risk

Our company has recently agreed to trial an ‘incubator’ approach. This is an idea (I believe first introduced by Atlassian), where an analyst, or a group of analysts, set aside time to come up with innovative concepts. These ideas don’t necessarily need to relate to analysis, but could be geared towards improving the work environment or simplifying existing processes.

An incubator idea is proposed to management who approve the concept. At this point extensive detail is not required. The analyst takes this concept away and spends time working out the detail. Ultimately, the proposal is presented back to colleagues at a team meeting for peer review. If the findings show that the idea will add value, it is implemented. Our company understands that while this approach can bring great innovation, it also bears an element of risk. Not all concepts will provide a benefit, costing the company valuable analyst time.

If you want innovation, you need to accept that it goes hand in hand with a level of risk. To an extent, this risk can be reduced by allowing senior analysts to cast their eyes over the innovative ideas. Due to past learnings, senior analysts may be in a better position to spot potential risks by applying some ‘seen before‘ logic. I accept that this is not a fool proof technique. In fact, it has a potential to damage the process, but it does provide a simple gateway for eliminating ideas where likely failure is obvious from the onset.

Another method is to ensure that analysts are not afraid to verbalise their thinking to as many people as possible. Sharing ideas with numerous people before committing to a design can reduce the risk of investing copious amounts of time in an idea that is likely to fail. The more people that challenge a solution, the more robust it is likely to become. Peer-reviews, wireframes, user group testing or process walkthroughs are some suggestions as to how these ideas might be presented to potential audiences.

The best approach to innovation is an innovative one

Creating a culture of innovation is an innovation in itself. We’ve worked hard recently to improve our ability to innovate within my organisation – incubators, innovation boards and the like are relatively new and we’re beginning to reap the rewards. I am given the time, space and support to drive innovation at my workplace.

Are you?

This article originally appeared on Bridging the Gap on 21 July 2011. Click here to view the original article.

The post Fostering a culture of innovation – Nik Gebhard appeared first on BSG (UK).

Do you innovate for the recognition, or do you innovate to innovate?

Nine out of ten change initiatives that BAs get involved in did not originate with the BA. It was someone else’s idea. Yes, every now and again you will kick-start a project, or have an idea that wins you additional work. But in reality BAs are normally called in to help out, to help evolve ideas and to manage and implement change. The core of the idea already happened. It was originated by business or technical stakeholders (just recognising the need for a BA is often the core idea!). You’re there to make it happen, to make the whole team look good. That is your responsibility to the team – to act selflessly and still ensure that you are a critical cog. In fact, it may even endear you to your team, strengthening your relationships. It’s not an easy thing to do, because as a BA part of your job is to come up with new ideas. Innovation is an important aspect of the job description. And when one innovates, one wants to share the innovation with others, to spread the good news. I think that this should still happen, as long as the BA remembers that at the end of the day it’s really about the other stakeholders, the ones who came up with the core idea. If the project sponsor is not made to look good, they might not get budget approval for the next project. If the developers are not made to look good, the business may start to outsource the coding. Of course if the project is a success, then none of this may happen, but perceptions make or break careers.

Avoiding recognition, is easier said than done

The real difficulty is when you just don’t get along with a certain stakeholder. We have all worked with people who have rubbed us the wrong way, stakeholders who for whatever reason cause us sleepless nights. This is when you really need to swallow your pride. I’m not advocating blindly toeing the line and meekly submitting to the situation, rather certain conflict within teams can be healthy. I am however advocating that the conflict remains within the team and is resolved professionally, while the outward impression of the team remains one of unity and cohesion. This makes everyone look good.

Are you in it for the tips?

For contract BAs or consultants it’s easier to deflect praise as the client is paying your bills. For internal BAs it’s harder as one wants to climb the corporate ladder. However I think that the same still applies – you’re there to serve. BAs are the waiters of projects. We provide insight, assisting the customer in making the right ‘order’, we then ensure that the order is correctly interpreted by the ‘kitchen’, then ensure that the ‘dish’ meets the customer’s expectations and is of the right level of quality, and then we deliver it to the customer. Praise is reserved for the chef. Or for the dinner guest who suggested the restaurant in the first place. Praise can be given to the waiter, but normally good service is just expected. The waiter needs to make the restaurant, the chef and the guests all look good, and it’s often a thankless task, but someone has to do it. And you know what, I love it!

This article originally appeared on Bridging the Gap on 8 June 2011. Click here to view the original article.

The post Recognition is important, but it’s not everything – Ryan Knapton appeared first on BSG (UK).

I wouldn’t expect much “umming and ahhing” if I alleged that there was considerable value to be gained in building strong relationships with stakeholders. It seems almost logical that building robust connections brings with it not only commercial benefit, but also project benefit. It instills a sense of teamwork as opposed to the typical “us and them” scenario. Strengthening relationships inadvertently means building an understanding of a person’s background.

Some facets of a person’s background can be researched, interpreted and assumed. I’m not attempting to create a foundation for über-prejudice, but it’s fair to say that when working with team members from other countries, a simple Google search or picking up a decent guidebook / travel book affords you valuable pointers on general customs and beliefs of a population. I appreciate that some of these facts may not apply, and that members working in a particular country are not necessarily originally from that country. However, having this information at hand does not hurt.

Researched characteristics can equip you for better planning

With the rise of global organisations, it is becoming more and more common to be part of a cross-border, and specifically cross-timezone, team. To give one example of cultural difference, I worked with a team where members from one country believed that working long hours in order to get the job done made you a better employee. Members from another country argued that having a good work-life balance enhanced productivity and reduced long-term fatigue.

In my experience, this often becomes a point of contention when things don’t go according to plan. This isn’t a debate about which is correct or more effective, but rather a discussion around understanding, appreciating and embracing cultural differences and using this to the advantage of project planning. Having an understanding of these working habits early on, means that better resource allocation can take place. Tasks assigned to employees who work a stringent 7 hour day may take longer than tasks assigned to employees working an 8 hour day.

Some characteristics – similar to the example on cultural difference above – can be researched. I recently read a guidebook on the United Arab Emirates (UAE) and was intrigued to learn that this type of information was readily available. I believe that, as far as possible, such characteristics should be taken into account during project planning. How and to what extent they are taken into account is up to the planner.

Going beyond skin-deep takes time, but enables you to fully leverage team member skills

Building rapport with stakeholders is about occasionally flaring from regular project tête-à-tête to associated personal experiences and stories. This opens the door for understanding similarities or dissimilarities between ourselves and others. It gives us an opportunity to learn about those attributes which cannot be researched, such as previous experiences, personal skillsets or even individual strengths and weaknesses.

I have been privileged to work with teams that have not only been culturally diverse, but also experientially diverse. An individual’s experience is clearly something that cannot be researched, but can be learned through the building of a strong relationship.

The benefit of having greater insight into an individual’s experience or skills is that these factors can be considered during project planning. Knowing that an individual is familiar with a specific aspect of a project means that their experience and skill can be leveraged. This does not only allow for better resource allocation, but also means that the individual can be consulted to provide recommendations on timeline estimations.

Something to consider here is the time ‘cost’ of getting to know an individual, versus the benefit of improved project planning.

Characteristics of newly promoted leaders may require additional schedule buffers

On one project, during a scoping and planning session, I was informed who my stakeholders were and covered the pertinent bases around level of seniority and experience. Regrettably, something that wasn’t as widely covered was the duration that some of them had spent in their current roles as leaders. While I realise there are numerous other areas that may be explored, this is a particular one that struck me.

It quickly became apparent that some of the members had recently been promoted to their current positions and had no previous leadership experience. This meant that behavioural attributes, such as slow rate of decision making, inability to delegate and difficulty in managing underperforming employees came to the fore. While this is not an exhaustive list, these characteristics noticeably impacted our project delivery timeline.

Identifying that stakeholders are new to a leadership role means that ‘typical’ characteristics of newly promoted leaders can be taken into account during project planning. Obviously an understanding of what these characteristics are needs to be obtained first.

Relationship building informs planning, but how much is enough?

It seems somewhat intuitive to perform a certain level of research on stakeholders or team members prior to project engagement. My experience has shown me that doing more homework on stakeholders can help with timeline estimations. In addition, there is considerable value to be gained in building relationships with stakeholders to understand their backgrounds and skill sets.

There are some questions though:

• To what extent can this research be performed?
• How much time do we realistically have to get to know stakeholders before the business demands estimated project timelines?
• Do you believe there is a link between getting to know stakeholders and project planning?

This article originally appeared on Bridging the Gap on 23 May 2011. Click here to view the original article.

The post The link between stakeholder relationships and project planning – Nik Gebhard appeared first on BSG (UK).

Do you:

1. panic and hyperventilate, black spots start to appear in your peripheral vision,
2. head straight to the kitchen, coffee will be your only saviour,
3. knuckle down, and start going through the emails in the order you received them, or
4. wish you lived in the 60’s when life was carefree?

Avoid this overwhelming email situation

Firstly, if you have that many unread emails as a BA, you are not managing your client or project team’s expectations very well. Everyone on the team should be aware that you have taken some time off (as everyone is entitled to) and therefore would not send you emails (other than a few CC’s). All too often I send emails to team mates, only to receive an out of office. This can sometimes be for leave for an entire week, and no one had any idea! It is extremely important to make sure that everyone knows when you will not be in the office; there is no shame in going on leave.

But regardless of who you inform, there will inevitably be a number of emails that you will have to work through. How you handle these will probably come down to your personality. But I think that there is something to explore here, because how stakeholders manage their emails could help you in managing them.

Decide whether to speak or to email

We all know people who prefer a 5 minute chat over sending an email. Some people are just wired that way – a short conversation suits them. We also all know other people who prefer to send a short email, allowing you to respond in your own time rather than being constrained by the immediacy that a telephone call requires.

The thing is, in my experience, the majority of people who prefer email over calls are younger people. This may be because the younger generation grew up with technology such as text messages and email as the norm, while the older generation grew up making calls. Or it might be because generally, the older generation have more responsibilities and require more immediate responses – they spin a lot of plates and when they have a thought that requires feedback, they require it now, and not sometime tomorrow.

Regardless of the reason, it is important to realise that these differences occur (between generations or between personalities) when working as a BA. In my experience, BAs tend to be younger than the subject matter experts from whom they work with on projects, and therefore inherently work differently. The BA may prefer to send a short email, whereas the business representative may prefer it if you popped round to their desk for a quick chat, or had a 5 minute call. It’s very important to pick up on the subtle (or not so subtle!) cues that you will get from various stakeholders as to their preferences, because then you can harness these preferences to get the most out of the stakeholders for the project.

Choose to make valuable use of tools

Email has revolutionised the workplace. It’s hard to remember organisations without it. But it has only been commercially used for the last 20 years. And while everyone can use email, don’t underestimate the impact that it plays on one’s formative years. Individuals who grow up with email as their primary communication method will think differently to people who have had to adjust. Not everyone is the same. But the good BA knows this, and adapts to suit their stakeholders.

As with all tools, one needs to best utilise the right tool at the right time. Email is merely a communication tool, and its successful use depends on the situation in which it is utilised. Use email too often and its effect may wear off. Write long, lengthy emails constantly, and you will find people will stop reading them. However if you intersperse conversations with email, choosing the right time to send a written question, delicately deciding who would prefer an email over a phone call, using email for agreement at key stages, I think that you will find email to be your biggest friend as a BA. That’s until you next go on leave…

This article originally appeared on Bridging the Gap on 22 December 2011. Click here to view the original article.

The post Is email the business analyst’s friend or foe? – Ryan Knapton appeared first on BSG (UK).

Human nature inherently means that we want to be heard and have our opinions counted. If our thoughts are not listened to, we tend to feign interest regardless of the outcome. Politicians need to listen to a wide, diverse range of individuals when they want to pass new laws or make amendments to bills and the way that they track these conversations is by writing things down. They write lengthy documents in order to ensure that their point of view is clearly understood, which in turns facilitates a process of analysing and commenting which makes the law more widely palatable.

Now while I am not saying that documenting system requirements is as important as passing legislation, I have worked in enough large organisations to know that politicking occurs as much in the boardroom as it does in Westminster or on Capitol Hill. On software development projects there is a regular need for business analysts to play the role of ‘cowboy’ in order to obtain project success. And the only way to successfully ‘herd’ humans is to listen to them and to let them know that they have been heard.

Herding cattle is all about communication

I’ve yet to see a more effective way of sharing ideas and obtaining input from across an organisation than the BA practices of holding workshops, documenting the outcomes and reviewing the documents. If documented correctly, the ideas and requirements of the system can be objectively seeded across the company (there needs to be a culture within the organisation of reading documents, but that is a topic for another day).

A clear specification is a lot less open to interpretation than subjective word-of-mouth conversations – something that is written down cannot easily be changed to cater for the whims of different audiences. A clear specification proves that you heard what someone was saying, internalised it and then articulated it back to them. As enterprise social features become more prevalent in the workplace requirements may move out of offline documents into online forums, but they will still be written down and documented.

Communicating with larger groups of stakeholders is difficult

In documenting requirements one opens up the project to comment and analysis. In small teams, commenting can be done through conversations, and Agile comes into its own because the team would not twist words to mean something different. Business stakeholders and the development team are co-located and the focus is on discussion, resolution and implementation. Documentation becomes less important.

In large, complex political organisations ideas need to be seeded widely throughout the organisation in order to obtain buy-in. Often many different business units need to provide input into the changes so that their future work is not adversely affected and so that they have the opportunity to benefit from the project. It is not practical, nor feasible, for one or two business stakeholders to represent requirements across such a large community. It shouldn’t be a question of whether documentation is required or not, it becomes a question of how the documentation should be represented to best suit the project.

Agile vs. comprehensive documentation – a standoff?

In my experience working across many large organisations, people are listened to in the workplace – flat organisational structures allow for everyone to have their say. Because of this, large companies are susceptible to internal politics. Wherever there are lots of people vying for prioritised requirements, politicking will occur. A BA should be objective, and the best way to remain objective in multi-party projects is to write things down.

The Agile Manifesto states that working software should be the focus over comprehensive documentation. While I wholeheartedly believe in working software, I also believe that while roaming the dusty plains of requirements gathering in large organisations, comprehensive documentation is vital to appease all political parties.

This article originally appeared on Bridging the Gap on 30 March 2011. Click here to view the original article.

The post Do workplace politics destroy Agile principles on documentation? – Ryan Knapton appeared first on BSG (UK).