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).

Now naturally we both believe in the benefits of teamwork, however sometimes I find that I can get things done faster if I do it on my own. In this article I don’t want to explore how delegation should occur on BA teams (that is for another day, and requires a different skill set).

Instead I want to pose the question:

When is coaching fellow BA’s a hindrance to the overall success of a project?

In the majority of instances, coaching is important

Coaching is an important aspect of growing team members. We all learn from each other, and different experiences make us better analysts. Coaching benefits both parties, the coachee learns more efficient skills, while the coach receives a number of softer, qualitative benefits and also learns skills around communication, expectation management, delegation etc.

The coaching process improves the organisation too. It creates better BA’s within the company, whether those BA’s are part of permanent or virtual teams. Future projects will be better managed and analysed because the overall skills within the organisation have increased. But what about a current project?

What about the minority of instances?

Coaching takes time and unfortunately not many people have the luxury of learning outside of the job. Of course there are examples, many of which are addressed on this site under the ‘Help a BA’ section, where coaching is done outside of the job. But that is different to on-the-job coaching. What happens if you could get things done faster without having to coach someone? What happens if you could get a task done in half the time it takes a BA who is learning something new (soft or hard skills)? Some projects have extremely tight deadlines, such as when a new legislative act brings about changes to core processing systems. Can coaching really be possible on every project?

Please don’t misinterpret what I am trying to say. I wholeheartedly believe in coaching. I think that it is an essential aspect of team dynamics. I would just like to debate whether it is always appropriate, and whether certain projects can afford to have BA’s coaching other BA’s. Of course not all projects will actually result in any coaching taking place (as not all projects will have BA’s learning new skills), but where the possibility does exist, I wonder if it’s worth asking the question: Can this project afford for any coaching to take place?

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

The post When does coaching become detrimental to project success? – Ryan Knapton 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).

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).