Hi

I attended and spoke at the Perth Business Analyst World Conference this week and really enjoyed it. This was a bit of a departure from the SharePoint events that I normally frequent, and I really didn’t know what to expect. Certainly, not having to fly 30+ hours just to speak is a big plus 🙂 The recommendation to the organisers to consider me, came about via Craig Brown, who has a very popular project management blog that I follow. Thanks so much Craig, I owe you a beer when I am in Melbourne next.

The conference report…

My talk was actually *not* about SharePoint and instead I was able to focus on more of my material on wicked problems, the shared understanding/shared commitment principle and then, the sense-making tools and techniques that I use to help bring this about. I was also able to demo the fruits of a very exciting, non IT project that I have been working on for a long time (more on that in a future post).

Despite my “This ain’t my normal crowd” trepidations, the feedback was great and the best thing to hear from participants, was that for many, it was stuff they have never heard before. That, for me, was really satisfying because I like the notion of presenting new ideas that actually have some decent practical examples to back them up. (This is something Andrew Woodward and I have in common. We love academic rigor for what we use, but it has to have been used in the real world with tangible success). Although I know that some people will disagree with the methods that myself and my colleagues use, I was able to demonstrate what I think is some pretty compelling case studies that support them.

What was interesting though, was that the examples and case studies were able to support what a lot of the other presenters had to say as well.

Ann Smith of Black Circle for example, had a great talk that was essentially about human cognition; essentially the wiring in our brains that serve to explain why big, fat documents are often not good ways to convey information. (Being a practicing dialogue mapper, no arguments from me there!) I am a nerd for this sort of stuff, having written previously on behavioural styles, learning styles and organisational culture, and Anne offered some new, interesting things that I have previously not considered or covered – more blog fodder for CleverWorkarounds, methinks.

Another highlight,the Western Power Business Transformation project, presented by Lorraine Pestell was also fascinating (I have a weakness for voice of the customer type sessions and this was no exception). Many of the strategic challenges that they are facing, such as sustainability and the changing business/regulatory environment, is very similar to the work I am doing elsewhere and it was great to see how Lorraine and her team were approaching the challenge and has given me some ideas and approaches to take back with me to my clients and projects.

The BA identity crisis

But back to the question suggested by the title of this post. There were some panel and round-table sessions about the topics of what actually *is* a BA, how you validate or recognise BA excellence, and the perennial BA versus PM turf-war debate.

Up until this time, I had actually never considered myself a BA because I had never actually given it any thought! As a self employed consultant, the only thing that matters is doing a good enough job to keep people wanting you to come back. So to that end, I didn’t worry so much about what I was called, provided that my clients were happy and the invoice was paid. But even if I wasn’t a consultant, I think that role titles often do not reflect reality and they also have a pigeonholing effect, depending on the attitudes and perceptions of what others think that role entails. Many position titles were discussed, “Solutions Architect”, “Business Architect”, “Change Manager” and some that were so pretentious that they bordered on wanky. More fancy words with no more clarity. No wonder many BA’s are struggling a bit for a sense of identity.

What I noticed when talking to the conference participants was that some attendees spoke from a lens where they seemed to feel that it was incumbent on them to provide a “translator” role between IT and “the business”. After all, nerds and CFO’s can’t communicate right? Enter the BA to ask questions and solve problems.

I have no major objection to that notion at some levels, but it is that *precise* mindset that makes me think “Well, I am definitely not a BA.”

Why? It was the notion that this “translation” was based on being the go-between from IT and the business. Thus, taking what one party says, transforming it and then passing it to the other party. As a result, BA’s are acting as a listener and interpreter, yet relaying second hand messages (messages that may be very different originally) between parties.

I personally balk at this. In fact, it really grates on me. By that definition, I don’t think I am a BA at all.

Interestingly, other topics of conversations were around “Well, how does a BA fit into Agile?”, “Is there a place for the BA in an Agile world”, and the like. What was interesting, and somewhat concerning, about these conversations was that those BAs who tended to think of themselves in terms of this “translation” role, really did not have a great grasp on the underlying principles of what we now call “Agile”.

Although Agile means a lot of different things and there are different sub-methods applied, these BAs got all focussed on the processes of Agile. They overlooked the fact that the process is actually the means to an end and it is the end-game that they have overlooked. Agile, (okay well Scrum anyway) attempts to use process and rigour (yes, rigour!) to make a project as conducive to shared understanding as possible. Probably the best thing that Agile does, above all else, is put diverse people in the same room. That alone will make bigger understanding breakthroughs than anything else!

Business Analyst KPI – shared understanding?

So, why am I not a BA?

My methods for translating are fundamentally inclusive. In other words, I do not “translate” anything, “take” it to another party and “relay” through my own words (and lens). I feel that despite all best intentions and whatever diagramming or modelling tool that you use, when you do this, you will always still find that you have your own cognitive biases that will not necessarily deliver the shared understanding that you think you are delivering. Instead, what I do is provide a rich container for a group to explore an issue together. In the same way that Agile tends to like all project members and stakeholders to be in the same room, Dialogue Mapping puts everyone in the same room and provides a suitable container for handling dialogue in a much better manner than traditional meetings and workshops.

If you agree with my previous assertions that a lot of the visible causes of project failure (scope creep, vague requirements, etc) comes from a lack of shared understanding among participants, and that BAs identify themselves as the bridge between IT and “the business” (which by the way is an insultingly gross simplification), then isn’t the ultimate KPI for the BA is to create and maintain that shared understanding? If not, yours is just another opinion that is counted no more or less than anybody else’s. Are you signal or noise?

So, in my humble opinion, the role of the BA is not to be the go-between from disparate stakeholders. Instead, it is your ability to create the sort of conducive holding environment that enables project participants to achieving shared understanding. How you do that is completely up to you of course, and if you have managed to progress a group from an agreed undesirable present state to a desirable future state, then your methods are totally validated.

Get over titles…

Now, if you call yourself a BA and think I am picking on you because you feel that you are the translator, don’t feel bad because plenty of PMs are guilty in their way too. In some ways, I feel that business analysts only exist as a career because enough people with the “Project Manager” title thought that time and budget alone were the only factors in project success. Some PMs who disagreed with this, felt that solving the problem was also critical, gravitated to the discipline of what we now label as “Business Analyst”. Some application developers that felt there was more to life than cutting code and made a similar gravitation. Put a bunch of like-minded people together and soon enough we have a “cool kids” club and lo’ and behold, we have a new discipline with a new set of titles.

(“Information architect” is a more recent example of this phenomenon than “Business Analyst”).

But, let me tell you something else about this title misconception. For a BA to label all PMs as interested only in time and budget is an insult to those PMs who actually understand that achieving and maintaining shared understanding is the end-game. The truly great project managers who I have had the pleasure of working with were actually leaders, not managers. They have all of the same characteristics of what makes a truly good business analyst: Critical thinking, soft-skills and most of all, a great radar for determining when stakeholders are not aligned and doing what is necessary to rectify the situation. They do not always dive into process and structure because their particular body of knowledge told them to. Instead, they have coffees, drink beer, conduct lunch-time workshops with free food and beverages, mediate, essentially whatever is needed to oil the cogs of dialogue that prevents something small becoming something nasty later.

By the way, I have met some angel application developers like this too, as well as infrastructure people.

If you want proof of a truly great project manager, then Kailash Awati’s wonderful site should be mandatory reading for both the BA and PM disciplines (and scrum masters too for that matter!). Kailash writes what essentially is a project management blog, but he has a deeper understanding of the sorts of soft factors that would put many BAs and some facilitators to shame.

Conclusion

In my talk at the conference, I emphasised that the ultimate success factor in any project is bringing about shared commitment through shared understanding among the participants. I believe that achieving these goals is the ultimate KPI for a BA, or anybody else who feels that they are there to help solve a problem, not deliver a crap solution that happens to be on time and on budget.

Thus, any method that helps a group achieve this is a good method because it has made a positive difference in advancing a group from understood present state to an understood desirable future state.

So, perhaps I am, after all, a BA?

Thanks for reading

Paul Culmsee

www.sevensigma.com.au