IIBA gaining momentum and finally mature enough to provide value

The IIBA continues to gather momentum in the business analysis and architecture community and is finally over its post-natal difficulties.

After earlier (perhaps over harsh) criticism from my side on the initial versions of the BABOK, I am finding real value in the community materials and (even more) the discussions.

I found the initial form of the practice to be at once too high-level and too "traditional" systems analysis focused for the increasingly varied role of the business analyst/ architect in organisations (see here and here). This was quite a feat since high-level and systems-level analysis do not always happily mix! It was descriptive, but not hugely insightful.

To see how this has changed, delve into the latest monthly newsletter or even better into the related online commnunities which contains a great range of interesting articles on topics as broad as developing business architecture to truly impact an organisation to BA handicraft (eg. handling constraints, assumptions, dependencies and risks and the definition of business analysis models). 

I can only encourage people involved in any facet of business analysis (from financial engineers, business architects, demand-managers, business strategists, management consultants, process, business and systems analysts to software engineers) to get into this community. Business analysis is a great blend of soft and hard skills that requires an incredibly broad often conflicting capabilities from the practictioner/consultant and this is reflected in the contributions to the IIBA online.

On a slightly geeky note, my favourite article this month is, in fact, one on BA-handicraft rather than any strategic contribution - the author argues that the best way to handle "CADs" (Constraints, Assumptions and Dependencies) is to basically convert them to risks or requirements and manage them accordingly - that is, to give them priorities/impact values and probabilities. The author argues that this will result in a more meaningful discussion of these items (which too often get lost in projects) and shift the discussion to a dialogue rather than a "cover your arse" list of things that were "signed off" on. 

I could not agree more and - as many of my colleagues would, I hope, attest - I have been pushing this approach (and in particular the use of impact/ probability/ maturity/ certainty) in our eBusiness practice for years. This stuff is - obviously - not rocket science, but discipline and rigour in this space are so crucial to success in projects and increasingly business in general, that I believe it is worth emphasising again and again!