Collaboration isn’t some kind of Arthurian round table. It’s not about everyone having their say or having equal weight assigned to their say.
I have no time for the old style of business analyst who spends months crafting 3,000 pages of text (but not a single model) to describe requirements and then archives the document and moves on to another project. This “toss it over the fence” approach is the reason why so many projects that take a Waterfall approach don’t find problems with the analysis until they hit user acceptance testing (i.e., after a lot of time and money has been spent on the wrong thing).
I see the business analyst as the lynchpin between several stakeholder groups. After all, if the real business need is not identified and clearly articulated, how can the right solution be defined, built and tested? And don’t forget that the right solution might not be software.
So it is essential the BAs ensure they discover and articulate the business need, not just clearly and unambiguously, but also in a timely fashion. This means that as soon as they can articulate a need (whether via a process model, a decision model, a data model, or a textual description of something), they communicate that to all stakeholders. They don’t hold onto it until some massive document is ready to be reviewed (possibly weeks or months later). Moreover, if the need changes, or a better way to articulate it comes along, they communicate the changes immediately, without multiple cycles of reviews. By collaborating directly with the business (challenging their thinking, ensuring their needs support the strategic goals of the enterprise) to produce and test their models, reviews become unnecessary and the latest version is the approved version.
For me, in my professional environment, collaboration primarily involves sharing knowledge and the skills to define and access that knowledge. I might share a BPMN 2.0 process model. At some point before that, I will have shared the knowledge of how to read a BPMN 2.0 process model, even if that meant staying after hours to give tutorials.
However, collaboration does not mean a software developer or a project manager get to vote on whether I use BPMN 2.0 to model business processes any more than my role as a BA gets to vote on whether the developer uses Java or the PM uses MS Project.
I worked on a project where a team of BAs helped the business produce, validate and test models of their key decision logic. On the basis of the need represented by those models, a technical solutions provider was chosen. However, that solutions provider and the software development PM threw out the models because they didn’t want to spend half a day learning how to read them. I suspect they also didn’t like the idea of the business’s being able to manage its own decision logic independently of their technology suite. The result was not only the wasted effort and cost in producing the models in the first place but also that the business lost ownership of its own decision logic as it vanished into the dungeons of the software code.
In a truly collaborative environment, the business would have owned and prioritised the logic, the BAs would have decided how to model and test it (the latter in collaboration with test specialists), the developers would have decided how to implement the logic in the software and the testers would have decided how to QA that the software correctly implemented the logic expressed in the models. All stakeholders would have ensured that the others had access to any knowledge and skills they needed in order to fulfil their role.
There should be no L’Oréal system in place. Nobody is worth it, everybody must earn it and expertise in a particular area trumps opinion. Collaboration should not mean giving everyone an equal vote, unless they have the expertise to understand what they are voting for.
Perhaps you disagree. What are your thoughts? If I can’t defend my position, I’m open to adopting (or at least adapting to) yours.
Kind regards.
Declan Chellar
Post scriptum
You have read this far, which means you weren’t put off by the word “ochlocracy”. Chances are you had to look it up, as I had to when I first came across it two weeks ago. Even though I studied Ancient Greek at university, I didn’t recognise the root (όχλος – mob). It has astounded me over recent years how few people in the workplace want to learn something new, so the title of this post was aimed at eliminating those for whom it is too much trouble to learn even one new word. I acknowledge it smacks of pretentiousness and if I were to say “ochlocracy” in a meeting knowing full well that 90% of the people in the room would not know what it meant, that would certainly be pretentious. But in a meeting room, people can’t right-click on a word I say and look up its meaning – on a blog, it’s as easy as that. It didn’t put you off and I thank you for taking the time to look it up and read my post.
Leave a Reply