Diaries of Business/Systems Analysts

Name:
Kim Liddelow

Company:
Self Employed

Title:
Senior Business Analyst

What company/organization you work for?
I’m self employed. For the last year I’ve been on contract to Commander, a medium sized telco here in Australia with a software solutions arm where I work.

What is your main role at your company?
Commander is a consulting company and my role is to go in shortly after or during the sales process to meet with the client’s subject matter experts to gather their requirements and model the process and functional requirements. Often this is two part, starting with an “As-is” model and then a “To-be” model. I then work with our development team to deliver the “To-be” model.

What do you find challenging about your job?
Probably the office politics but that’s another story. I guess the most challenging thing is juggling multiple projects at the same time. They each have their own demands and deadlines. I can only do what I can do though, so I don’t fret about it very much. This is also one of the things I like best about my job - lots of variety.

What have you found that makes your job easier?
We use a modelling tool called Holocentric (www.holocentric.com). It uses a process based approach to specifying systems which I really like. The processes and activities (use cases) can be system based or external to the system. In this way when we model a system, we show the whole business process and not just the part that the system will do. I find clients really understand and value this. The Holocentric model becomes our central repository as we work on the specification. Requirements (functional, non-functional), business rules, business domain model, UI specification are all linked through the use cases. Holocentric also supports all the standard UML artefacts.
Holocentric generates a word document and / or a web site which we give to our clients.

How did you become a Business Analyst?
I was living in San Francisco at the time of the tech wreck working as a java developer. It was my big chance to convert from client server applications to internet applications! I’d moved from Seattle to take the job and I’d only been in it for a few months when everything went pear shaped. The company I worked for went from 80 odd to less than 10 people.
So there I was in San Francisco, no job, but fortunately my wife’s company was still going. So I was at a party a few months later and got to talking with another Australian guy. He turned out to be CEO of a software company and to cut a long story short he hired me. Turned out the job was as a BA. For years I’d used Yourdon’s (and others) data flow diagram approach to specs but for this new job I decided I needed to use UML. So I went out and bought the 3 amigos book – The Unified Modeling Language User Guide (Grady Booch, James Rumbaugh, Ivar Jacobson) and started to read. After a while I realised I’d learned all about use cases and the different artefacts in UML but didn’t know when to use them. So I then bought The Rational Unified Process an Introduction (Philippe Kruchten) and worked out from that what to do. The first project went OK and I just carried on from there. We moved back to Australia in 2002.
So it was all very seat of the pants but I’d been writing functional specifications for years as part of my development work.

What is one piece of advice that you would like to pass on to junior Business Analysts?
Two things really:
1) Use the artefacts you need to support your argument for the project you are working on. BA work is intuitive and using the same cookie cutter approach for every project doesn’t work. Work out a process and the artefacts to support that process that work for you and your organisation. Then on each project, only use the bits of the process and artefacts that you need to clearly define that system.
2) Avoid going into detail too early. I often see that inexperienced BA’s will drop straight into technical detail. As BA’s we don’t do technical. Our models are solution independent. A very common error I see is people using use cases to define screens. That is design it is not business analysis.

Oh and try to learn something new every day (that’s 3 things). I particularly like learning new stuff about different businesses.

What does a day in your role as Business Analyst look like?
Of course it varies enormously. A good day is facilitating a workshop for requirements gathering on a new project. Usually that is multiple days. Then following that it’s taking the information gathered in the workshops and developing a specification from it. This is the bit I like most about being a BA.

If you were to learn a new skill or competency what would it be and why?
I’ve been thinking about this for a while. As an independent I’m basically a hired gun for projects. So to enhance my rate there are a few different streams I can try.
• One is into project management and I’m not at all interested in being a PM. Also I’m not really interested in managing other BA’s but will do it if asked.
• Another is into a Business Architecture role. I find the idea of this interesting and working more at an enterprise level very appealing. Not sure how to do it though. Anyone out there have any ideas? I’m trying to position myself within the current job I have with some success. Of course a lot of companies don’t really know what a business architect is. I’m not even sure I do;-) In this job with Commander my focus has moved into a much more business role and I like this very much.
• One other idea I have is to give training on UML and use cases. I think I’m pretty good at them, there is a demand for that skill and a lot of people interested in knowing more. I’d still keep working as a BA though as well.

Anything else about yourself which would help others get a better perspective into the business analysis profession?
I started out as a developer back in 1985 and I’m what is called a technical BA in Australia. Essentially I do process and functional modelling. I have no particular knowledge of any industry although of course in 23 years I’ve worked in lots of them. This makes me a generalist. The skills that I have to sell that are my “unique selling point” are UML, many years experience, functional modelling, process modelling.