Monthly Archives: February 2010

The power of the BA

I was doing some spring cleaning recently and I started reading some old material I was meant to be filing (I am not a very efficient spring cleaner).

I came across some of my masters degree notes on power, politics and negotiation in organisations.  Some of the main sources of power were:

  • Being the “locus of communication”.  In other words being the person between multiple teams that handles a lot of the inter-team communication;
  • The ability to set the agenda in discussions (generally meetings and workshops by also interviews); and
  • The one framing the questions for discussion (apparently the way you word the question often dictates the answer, which dictates what will happen next in the organisation).

As I read through the list, these and several other sources of power seemed almost like a job description for a BA.

Then I read another old paper which I sometimes quote in courses.  It talked about who survives, thrives and gains power in tumultuous times in organisations.  This paper concluded that the power brokers (survivors) were the:

  • Boundary spanners (those who communicate between teams);
  • People who understand their own knowledge needs and the knowledge needs of others; and
  • Those good a team facilitation (workshops, meetings and BA stuff).

I pondered these papers (which still need filing) and I began to think about the book “Bargaining for advantage” by Richard G Shell.

This is my favourite guide to negotiation.  Among other things the book stresses the importance:

  • Information gathering and understanding in the negotiation process (ie what BAs do);
  • The importance of knowing who the influencers are in a negotiation (often the BAs); and
  • Knowing where to go to bring outside (but maybe biased) views to the table to influence the discussion.

I began pondering the idea of finishing my filing, but instead drifted off to wondering how much power BAs have.  It seems to me that they wield vast organisational and political power on projects, in their teams and in their organisations.

Yet, one of the gripes I hear from BAs is that they don’t have any power to make things happen on their projects.  All power rests with the PM and the BA is mere a pawn in the mighty game of organisational politics.

I have concluded that in fact business analysts DO wield vast power.  They just claim that they don’t.  I’d be interested to know if you agree.

I’d also be interested to know the answer to my new question – If, indeed, the BA does wield vast power and yet claims not to …. is this because he or she is unaware of the power of the BA, or is it a conspiracy, where they are controlling the information to keep everyone else ignorant of the impact they are really having on the world?

Leave a comment

Posted by on February 26, 2010 in Business Analysis, Culture


Emergent Requirements in Civil Engineering

I often talk about how requirements emerge in software projects – how we initially express what we think is needed and over time the real understanding comes to light. 

This approach is so common because so much of what we do in software projects is exploration – we don’t know what we don’t know and we’re finally acknowledging the uncertainty that surrounds much of software development.  This is far from a new approach, over 20 years ago the Barry Boehm coined an acronym “IKIWISI” – it stands for “I’ll Know It When I See It” – normally preceded by “I don’t know what I want”.

Critics of software development frequently ask why software enginering can’t be as predictable as civil engineering.   The reality of civil engineering is often very different, as I learned on an airline flight a few years ago.  I sat next to an award-winning Australian architect and we got talking about the differences between civil and software engineering.  He described what happened with a property he designed:

 The building had been carefully planned, detailed designs produced and virtual walkthrough’s prepared and agreed to.  The placement of the building on the section and the position of the doors and windows were carefully worked out to provide the best possible view.   Once the foundations had been poared and the ground floor framed up he walked through the skeleton of the building and checked the view from every window and door space.  He noticed that the placement of a large sliding door gave a good view out to sea, but if he could move the door about two meters to the left the view would be fantastic.  The change was made (over the objections from the builder) and when the building was finished it won an award as an architectural mastepiece.  IKIWISI in the building industry!

For a concise discussion of the differences between Software Engineering  and other engineering disciplines see

Another Agile practice that has a mirror in civil engineering is Adaptive Reuse – refactoring buildings for new uses.  See 

Another IKIWISI story in home construction can be found here:

Posted by Shane Hastie

Leave a comment

Posted by on February 7, 2010 in Agile


Tags: ,