Just finished Effect Managing IT by Ingrid Otterson and Mijo Balic, a deceptively long read (for its 102 pages). Its dry style makes it feel like it’s been inspired by university textbook writers and it’s a little too prescriptive for me (it provides an agenda for a steering group meeting!), but it has some great points that are worth considering.
Business Analysis
6
Feb 09
People Should Eat Dog Food Too
A good friend of mine wanted to find out how a customer application process worked in his department. He didn’t grab his notebook and interview his colleagues. He didn’t draw up elaborate as-is process flows in Visio. He didn’t even write one word of documentation. Instead, he did something much more effective – he went through the application process himself.
14 letters and 5 weeks later, my friend had conclusive evidence of how the process worked, along with a set of recommendations on how to improve it.
21
Oct 08
You Can’t Write
And I can’t either. You’ve got to face the facts – as a business analyst, no one is going to read your documentation because of your poetic commentary, your witty explanations or your inspired diagrams. At most, people might read it because they have to. So why do we get so attached to our masterpieces?
12
Oct 08
Run When It Gets Too Hard?
A month ago, a talented member of our project team (no, not me) got the business people, developers and everyone in between to agree to a simple, elegant solution to a business problem. This week, all that hard work was undone. We’ve now got signoff on a much more complex solution – we need to do four calculations and one of these calculations is not like the others. So why does this bother me so much? Not because it creates more work (this is one time where laziness cannot afford to win out), but because it sets alarm bells ringing in my head.
20
Aug 08
Lazy Documents
I have seen my fair share of templates. For each document a business systems analyst is expected to produce, there is a pre-made formula. At first, I thought it was like colouring in – you get an outline, you colour in between the lines and at the end, you have a masterpiece. It quickly became apparent that this approach wouldn’t turn me into the next Picasso.
The problem with the way most templates are used is that a single template is designed to encompass a humungously broad range of vaguely related scenarios. Matching this vast, vague template beast to any specific focused software development project I have ever worked on is a painful exercise both for the writer and the reader (on the off-chance your audience tries to read it). Software projects vary substantially: one project may be process focused; another may revolve around the UI; and, yet another may involve purely back-end processing. Sometimes people forget that templates are intended as a starting point, a guide or cue and should never become a rigid exercise of filling-in a form without regard for the purpose of the writing in the first place.