Analysis is just Analysis, right?

If I've learned anything in the time I've been working in IT it's this: every project is different. The deliverables may be similar, may even be precisely the same, but the environment in which you're attempting to deliver them will not be. Each place has a different culture, different personalities, different challenges and constraints. The path you need to take from working out what is needed to the final release is a constant variable.

I said previously that my job as a Business Analyst involves taking stock of what is required before I know properly what my role in that is going to be. I stand by that, and I can't stress it enough. Part of my role as a BA is assessing the problems the project is likely to face and helping to define the approach so as to best mitigate them. Nothing frustrates me more than somebody pulling out a textbook definition of how something should be done and sticking stubbornly to it. Because the real world is never, never, a textbook example of anything. In order to be a competent Business Analyst, in fact in order to be a competent anything, I believe you need to have some flexibility and the capacity to adjust and appropriately apply what you know.

Methodologies

Methodologies are a perfect example of this, and perhaps the easiest way to contextualise what I mean. As a lot of people probably have at some point, I ended up some years ago now on a Prince2 training course. As far as I know, this is still the benchmark for Project Management competency. And it was an interesting course: Prince2 is logical, it has a natural progression to it, and it links up the worlds of business goals and project delivery quite nicely. Almost everyone I know who has done their certification (and I hasten to add that as a BA I only did the Foundation element, not the full Practitioner) has said to me "it's good, but we don't use it". And we laugh about that. But I don't think that's strictly true. What they mostly mean, I think, it that they don't use it all, they use different elements of it in different situations. And I think that's fine. Why would you produce a whole raft of artefacts that stick strictly to the Prince2 method if your project doesn't need them all? All that does is inflate your timelines without moving your forward along your critical path. You're not progressing along the straight(ish) line from problem to solution if you do that, you're taking time out to wander through the woods at the edge of the road for no real reason other than because you think maybe you should,

Requirements Techniques

I'm stating the obvious, I know, but project initiation and scoping should be a question and answer exercise. Q: What do we want to achieve? A: This. Q: How can we achieve it? A: Like this. The first question is often the easy bit (well, everything's relative). The second question is where things often fall apart. Mainly because this bit requires a touch of creative thinking. Not that IT project planners are incapable of creative thinking, but they tend to be a little too reliant on the conviction that the answer is already out there. "Somebody else has already done the thinking on how you gather and analyse requirements, so why should we reinvent the wheel? Let's just use this/that/some other method we've seen before." The problem with that school of thought is that it oversimplifies. It assumes, and as an analyst I don't like to assume anything - I've been burnt too many times before by assuming things...

I'll give an example. One company I was at was running what was, essentially, a data warehousing project. Not an Enterprise level data warehouse, but a warehouse nonetheless. For gathering together a consolidated dataset from multiple source systems to support a set of defined reporting requirements. Regulatory reporting requirements. Successive leads on that project told me that we were going to tackle the problem with use cases: they'd seen them before, they'd used them before, they knew they were effective. Now I've used use cases before too, loads of times, and I agree, they can be quite effective. But consider for a minute what a use case gives you. It gives you an Actor (a user or stakeholder, whatever you want to call them); it gives you a set of functions - the things this person typically does; and it gives you processing steps, both happy path and alternatives to handle edge cases and process errors. Now consider what a developer will need when building a data warehouse. They'll need to know what data they're working with, what it looks like, where it's coming from, how they should put it into a standard format so it can be combined and merged together. What are the rules they need to transform it into that standard format? What will the reports coming out at the end need to contain - which fields, what will they be grouped by, which values need to be calculated?

You see the problem right? Use cases deliver none of the things that those types of projects require. They're great for functional development projects. They're pretty worthless for anything else. It was a classic case of picking a method that someone else has already done the thinking on for you. I argued about it for, I don't know, months. I explained it was like someone asking for directions to the station and you answering with your grandmother's recipe for lasagna. I likened it to calling out a plumber who turns up at your house without a toolbox, who just walks in with a hammer and tells you he can weld pipes, remove taps, service a boiler and fit a new shower screen with just this one tool. Assuming there is just one method of analysing something, just one way of gathering requirements that always works, is as ludicrous as denying the existence of the screwdriver and the wrench and the blowtorch.

The issue got resolved eventually, as these things tend to, but it was a shame that we wasted so much time before the penny dropped. (And by penny dropped I of course mean the development team telling a senior manager they couldn't use what had been produced).

Forwards and Backwards

The reality of analysis is that most of the time, almost all of the time in fact, you have to work backwards. What I mean by that is you have to figure out what you want to end up with before you can piece together how you achieve it. It's the same as working out where you want to go for dinner before deciding whether to book a taxi or go catch a bus, the right bus. I mean, you can just leave the house and see where you end up, walking about is a proven method of doing things, but you might find yourself at a disused warehouse by the docks rather than the nice Italian your friend told you about.

Also, project delivery is a chain. There are different stages in that chain with different people doing different parts of it. In order to do your job effectively, you have to think about what the next person along (and maybe the one along from them too) realistically needs from you and then structure your work to provide that input into them. And it's not just the difference between functional requirements and data requirements, process definitions and ETL rules, but also what these people are most likely to be receptive to. There's no point writing a sixty page functional spec if you're dealing with some development personalities that you know are not going to read it. "Here's a ton of pages with paragraphs and long sentences." "Er, thanks" as they get tossed in the bin. At the moment I'm writing a lot of data requirements, logical rules and the like, and I've been doing them mostly in SQL because I know it's a common language that I can speak in with our dev team. A CASE statement says all I need to tell them without the need for a lengthy explanation of different conditions. At other times I've written psuedocode, I've drawn diagrams, I've written sentences, I've given worked examples. Whatever seems like the best idea in that particular situation.

Incidental Knowledge

This is a particular bugbear of mine, I admit, but there is a often a perception that analysis is just analysis, it's some general generic thing that is all-encompassing and will give you all the answers to everything, answers to questions that aren't even being asked. And if it doesn't, then what have you done wrong? As I implied above, by working out the steps you need to take to get to what you want to achieve you're automatically putting a natural boundary around your work. You have to: if you didn't you'd never finish. You can go on trying to find things out forever, it has to stop somewhere.

I'll give an example. Let's say I needed to work on a project which is extending the product handling functionality of a system. I spend a lot of time understanding what a product is, how it's structured, all the different elements that define it and the things that people in the business do to manage and report on it. A product becomes part of an order, an order is made by a customer. So in my analysis I might take in these things as well and find out a few bits of information about how the system works with these concepts to make sure I'm not missing anything. A customer may also have a credit profile, but that has nothing to do with products so I stop before I get that far down the rabbit hole. For the purposes of what I'm doing, I don't need to know much about that right now. As interested as I might be, I have time constraints, I need to move on. The amount of times though that someone will then come to me assuming I understand everything there is to know about a customer's credit profile, by virtue of the fact I did some analysis on that system so I must know, is incredible.

To go back to my Italian restaurant scenario, that's a little bit like assuming that the person who got the restaurant's address off the internet and followed some directions to get there is now capable of drafting up a detailed map of four square miles of the city, to scale. My point is, analysis is like anything else: you work to meet the ask. That work doesn't automatically meet any other alternative ask. To do that you need a different scope and a different approach. There's no reason you can't do both asks at the same time, combine them even, but you have to know that's what you need to do first. And it will take longer to do, obviously.

In reality, you do tend to build up incidental knowledge when performing analysis. Because you hear stakeholders talk about things that you aren't necessarily looking at. They sometimes mention them when giving you context. You acquire a bit of an understanding despite yourself. But it is just that: a bit of an understanding. It would give you a good head start if you were to then go and do further analysis in that area, but it's a mistake to assume this incidental knowledge is anything more significant than that. It is also, by the way, just as likely that nobody mentioned it to you and you know nothing about it. It kind of comes down to chance and your capacity for retaining what otherwise seems like disposable information.

In a Nutshell

Analysis is essentially nothing more than forming an understanding of something. I know that sounds obvious really, but it's something that often seems difficult to articulate somehow. A surprising number of people don't really know what it entails, and seem to view it as some sort of dark art. I'd categorise it as forming a comprehension of how an existing thing actually works, in detail, or how something new will have to work in order to satisfy the demands it has to meet. And it is entirely scalable: it can be done for a single, small logical problem, and it can be performed against the operational practices of an entire organisation, or the entirety of its data asset. There are lots of different ways of doing it and the skill is really in picking which method best suits the circumstances. There's nothing wrong with refining your approach as you go, in fact that's often the best way to do it, but my advice is to stop and think about it a little bit before you start regardless of the pressures being brought to just get going. The time taken up by a little bit of consideration and judgement will save massive amounts of wasted effort in doing the wrong, and ultimately unusable, thing instead.