I spent some time this afternoon tweeting about business analysis. This was pretty much a stream of consciousness thing for how I see my role. I’m kind of interested in seeing it end-to-end so I’m going to experiment with embedding all the tweets after the cut. 

So here goes (with some additional commentary interspersed):

“Qualtitative”. Oh well, Twitter is a fast medium without a spell checker. 🙂

Aside: You would expect BPMN to stand for Business Process Modelling Notation but, no, it really does stand for Business Process Model and Notation. Go figure. 🙂

I tend to prefer Baseline/Target for the record. I may explain why someday (but no promises, and not today).

Whether or not your project will have the luxury of sufficient time/resources to actually do this is another question.

Whether or not your project can afford to not get a solid understanding of what’s in place is also another question.

Yes, these two questions contradict each other. Such is life, and working out which is more important what a good project manager & lead BA are for. Such is life.

No, I really did have to take that line, much I think to @ryorin’s disgust. 🙂

There is, sometimes, a whole world of pain buried behind those last four tweets. Equally, there is sometimes the exhilaration of finding a clean, elegant, solution that makes life easier for the entire agency. I live for those moments, for the rest of the time I have Comfort Anime.

… to non-existent. Almost every agency has clients or has to deal with other agencies. This inevitably requires business processes and increasingly externally facing systems to manage these interactions.

5 – 10 is better, but often not achievable.

This is one reason I like Sparx Enterprise Architect: a) it allows fairly seamless integration of text into the artefacts on diagrams, and b) it allows relatively painless extraction into websites or word documents.

Key terms here are Cloud/Kite/Sea-Level/Clam (or sub-function). In my opinion BPMs should go no lower than Sea-Level.

The goal levels really are awesome.

Another reason to pick a modelling tool that supports recursive extraction of artefacts. Done right the artefact on a higher level diagram directly expands into its lower level diagram, and this can be built into word templates that read the model from the top level down.

Traceability down is being able to show that the higher level goal is actually delivered by the lower level goals.

Which is not to say that your answers are wrong, or even any less right than mine. Business Analysis is as much an art as it is a science, and possibly more.

Going back to the Outcomes/Outputs, these are the reasons that an Australian Commonwealth agency exists and is funded to achieve. Those are pretty fundamental goals for an organisation.

Of course you still have to find an active verb so that you’re telling a story along the lines of “The Actor Does Something. The System Does Something in Response.” etc. I’m also not going into any details about normal/alternate flows here. That’s a book in its own right. 🙂

Bearing in mind that there may be multiples of these if you are implementing a use case on a variety of platforms. The web UI design will not (or should not) match the iOS UI design, etc.

The two books I’ve mentioned are the first things I take into a new workplace with me.

This also makes them less fragile, and potentially re-usable with only minor revisions when a system is replaced.

Highly satisfying when you manage it though.

Here’s a little something I prepared earlier:

Requirements vs Design

I think I got them all. Looking back over that, it’s pretty good for an off the top of my head brain dump of being a business analyst.

Obviously there are huge gaps (e.g nothing about waterfall vs agile or the religious wars around development methodologies) but I think that what is there is fairly accurate. On that note, I think I’m done for the day, and I hope it was enjoyable and/or educational.