As communicators, most business analysts will religiously use a spellchecker. After all nothing is less convincing than a misspelt document – it shows a lack of attention to detail. But there’s more to Microsoft Word than just spell-checking. How many people take any notice of the readability statistics? These statistics give an indication of how easy – or difficult – a piece of text is to read. The two Flesch figures at the bottom both measure readability, but in different…
Continue ReadingArticles
Your Project Pitch
Sometimes a salesperson only has once chance to capture a prospect’s attention. That’s why the good ones always have an elevator pitch polished and ready to go. What about you? When your CIO gets into the lift and asks “So what are you working on?” forget about trying to sell your project and concentrate on selling yourself. After all, projects come and go but keeping – and promoting – good staff is what a CIO’s job entails. Putting your work…
Continue ReadingData Modelling & Object Oriented Development
At some stage in their working life, every business analyst will have some involvement with data modelling. They may need to model how data is (or will be) used or – if they only deal with requirements investigation – then someone else in the team will need to verify that the data to support new functions will be available. To produce a data model (a logical view of the data) the technique of choice has been, and still remains, the…
Continue ReadingHow to Write Use Cases
A previous IRM paper – How to use Use Cases – highlighted the need for clear and logical thinking when documenting the primary and alternate flows of a use case. A use case diagram is all well and good for communicating the scope of a particular event but to explain what’s happening inside the use case we need to revert back to a textual description. The How to use Use Cases paper described a relatively simple event – a student registering…
Continue ReadingCommon Business Analysis Problems
One of the fortunate things about being a training company is that over the course of a year we get to hear from hundreds of business analysts about their problems and frustrations. It doesn’t seem to matter whether the analyst works for a finance company, in manufacturing, energy, utilities, telecommunications or for a government department, the same issues crop up time and again. Interestingly, the issues raised by business analysts are less to do with project methodology or personal skills…
Continue ReadingFrom Mission Statement to Business Process
Most business analysts will never interview a CEO and many don’t understand how a company’s real objectives cascade down to the little bit of requirements they’re doing for a particular system. How does my system fit into the company’s business strategy? What is my role in the big picture? To understand this we need to start at the beginning – or rather at the top. Everyone knows a company’s objective is to make money (if we’re a commercial organisation) or…
Continue ReadingEvent-Based Analysis & Modelling
Many business analysts mix structured techniques with UML and use events as the entry point to their analysis activity. An event can be any activity, action or business process where the system under investigation needs to respond. In this approach to business analysis, once the scope of the system has been identified, the first deliverable is a table (a list) of events. Event-based analysis aligns very well with UML and object-oriented development as both are based on how a system…
Continue ReadingJust Enough Documentation
Is documentation a blessing or a curse? If you’re working on an agile project does it get in the way? If you’re updating a core system that runs your company’s business, are you cursing the analyst who didn’t adequately document all the business functionality? Is today’s agile project tomorrow’s core system? How much documentation to produce is one of the most troublesome issues facing analysts today. There are no hard and fast rules on this and successful projects define their…
Continue ReadingSolution Mode Thinking
One of the biggest mistakes made by business analysts is going into “solution mode” before they’ve fully analysed a problem. They either approach a client meeting with pre-conceived ideas on what will fix the problem or jump to conclusions during the investigation phase without understanding all the underlying issues. We can all be guilty of this and sometimes the more experienced the analyst, the more prone they are to fall into this trap. Why is this so? Problem Solving When you…
Continue ReadingHow to Deliver a Recommendation
Like it or not, every business analyst (and usually most project managers and developers) will have to stand up in front of a group and present. The group might be your business clients, the project stakeholders or just your fellow team members but for many people, one of two things will happen: It will frighten the life out of them They’ll umm and ah their way through, sending the audience to sleep Why is this so? As a business analyst…
Continue Reading