Tag: Tips

For me a good day of gathering requirements is marked by a business user saying, “That’s a very good question.” In the majority of instances the trick of coming up with those questions is the same – while talking to users about their business processes, I am mentally mapping the information those processes involve to a data model.

In a previous life I was a Data Administrator. Relational database technology was new and ‘normalisation’ was a magical art. Apprentice data analysts could get to third normal form. Full data wizards understood fourth and fifth normal form. Hard to believe it now but we ran sessions with business users that focused purely on data. We asked them to put their processes out of mind and focus only on their information requirements. Our deliverables were entity/relationship models intended to support the development of enterprise-wide, reusable databases. It was a VERY painful process for all involved.

I’d estimate that data administrators (myself included) spent about 30% of their time documenting business data requirements and the other 70% debating with other data administrators about such things as naming standards, domains, and whether “Double-headed arrows,” “Crows Feet” or “A Big Dot” was the best way to represent the “Many” end of relationships on Entity/Relationship (E/R) diagrams. I really miss those days – NOT!

Fast forward twenty-something years to today. The Unified Modelling Language has morphed E/R diagrams into Class Diagrams (although Relational databases for the most part are still the norm rather than genuine Object-oriented databases). When people talk about requirements the two main types are Functional and Non-Functional. Data requirements are typically relegated to entries in a glossary or one or more E/R diagrams in an appendix.

Business users now, as then, have zero (or less) interest in looking at a data model. However, they are more than happy to be shown a screen ‘wireframe’ representing the way a system would present data to them in support of their business process. The trick, at least in my case, is applying my data perspective during discussions of these wireframes, but without using the “E” or “R” words. Most typically a screen equates to an entity (e.g. Customer, Contract, Order). So does a displayed table of items (e.g. Order Line Item, Payments). Fields in the screen (or columns in the table) either are ‘facts’ about that entity or reference some other entity (e.g. the Customer ‘named’ in an order or the Product ‘short description’ in an order line item).

OK, back to the magical source of ‘good’ questions. The basic data normalisation technique is ensuring that each attribute is a fact about the most appropriate entity. [“The key, the whole key and nothing but the key, so help me Codd.”] If not, then it is a fact about some other entity.

For example in an Order Line Item, “Quantity” is definitely a fact about the Line Item. The “Product” being ordered is a fact about that Line Item, but because there are a bunch of ‘facts’ about Products irrespective of them being ordered, there needs to be a Product entity. Users entering Line Items need a way to ‘identify the product’, and having done so the screen is populated by fields that are facts taken from the identified instance (e.g. short description, unit price). A “good question” might be, “When a Product is ordered, is the Unit Price the same in all cases, or can the unit price be different (e.g. Customer-specific price schedules)?”

Another ‘good question’ that has its basis in normalisation is, “Can that fact have multiple values at the same time (e.g. an Employee being classified as having multiple Skills)? Or the cardinality of a relationship (e.g. can a Contract involve more than one Supplier?).

If you have data analysis skills, I encourage you to apply them during requirements gathering. If you are light on data modelling skills, I encourage you to learn more about the subject. Regardless, I encourage you to keep these skills hidden from your business users and let them think you have magical abilities to ask ‘good’ questions.

Anyone else, “been there, suffered that”? If so please add any examples and/or tips for gathering requirements without diverting Business Users from their focus on their processes.

Don’t forget to leave your comments below.

It is common within the ICT industry, to come across job advertisements listing prior domain experience as mandatory for a Business Analyst. Finance and health are among the worst culprits and those of us who have faced a position description stating ‘experience in a financial organisation is essential’ will understand exactly what I mean. Whilst prior domain experience certainly has benefits for the organisation in terms of shortening the learning curve of a Business Analyst, and getting them started faster, there are also pitfalls that organisations should be aware of and should take into consideration.

I recall my first Business Analyst position in the health industry. The organisation was looking for a Business Analyst with experience in health. Fortunately having worked with the Program Manager previously was enough to get me in the door with my proven analysis skills and experience. The clinical project I was assigned required me to work as a Business Analyst very closely with subject matter experts from Nursing and Allied Health disciplines. Naturally I was aware of my lack of domain knowledge and relied on my inherent Business Analysis skills and techniques to get up to speed quickly – document analysis was a great place to start.

To my surprise, the subject matter experts on the team commended my ability to actively listen and understand their domain to the point that I was adopted by the team as a ‘pseudo clinician.’ I received comments like ‘we are really glad you haven’t worked in health before, it means you ask the obvious questions instead of bringing your own assumptions and past experiences that may not align to how we define and do things here.’ Another comment was ‘it is so nice to not have to hear you tell us, how the place you used to work does things, and that “x” word actually means something completely different in your prior organisation.’ The take away lesson I learnt, is that the power of ignorance should not be disregarded and can actually be used as a strength to create the right frame of reference from the start, instead of having to alter perceptions brought from other ‘similar’ organisations within the industry. It is easier to create new understandings than to change those already deeply embedded.

Travelling further back to my university days, I recall a business lecturer emphasising the value of learning critical lessons from other industries that ‘do what they do best.’ For example, if you are working on a system to manage capacity within an aged care facility, why not look to the lessons learnt and finely tuned practices of the airline or hospitality industry for creative ideas and advice? The benefit of having a Business Analyst who has worked across multiple industries is that they can bring a new perspective to solving cross-industry problems. I have worked in mining and construction which many would assume is quite a contrast to health, however from a process and systems perspective, body parts and tyres are really not that different – they each need to be screened and assessed, have attributes which need to be recorded, have an acceptable range for blood pressure or tyre pressure, require monitoring and reporting.

In my current role as a Service Delivery Manager for an expert Business Analysis consultancy, I would rather hire a Business Analyst who is foremost a Business Analyst and not a health or finance industry subject matter expert. Similarly, I would take my car to a mechanic and not a motoring enthusiast. When I look for a great Business Analyst to join our highly skilled team, I look for someone who is well versed in the core competencies, skills and techniques required for the role, whether that is business process modeling, stakeholder management, use case documentation, business/functional/non-functional requirements specification, requirement traceability, business case development, enterprise analysis or workshop facilitation. The frustration however comes with placing these expert people into clients who are more focused on hiring a Business Analyst with subject matter expertise, than a Business Analyst who is great at their own job, and who brings a diverse range of experiences with them to the role. The divide between a Business Analyst and ‘the business’ needs to remain preserved – the role of the Business Analyst is to facilitate decision making and provide objective advice, however when the Business Analyst is also the subject matter expert, objectivity can be compromised and the Business Analyst may creep into decision making, or making assumptions and prioritising requirements without the business input.

With all this said, my first Business Analyst role in the health industry did assist me in some ways with my subsequent health role – for example I was familiar with software solutions used within the industry which could be applied to my later role, although it would not take long for a Business Analyst without prior health experience to also quickly come up to speed on this. My experience working with clinical stakeholders was an advantage, however the same core stakeholder management skills come into play whether proving your value and credibility to a clinician or tyre performance manager.

Many industries feel they are unique, just as many stakeholders feel their processes and requirements are very different from the next. If this were the case, it would be difficult for cross-industry process classification frameworks to exist, and Business Analysis guidelines such as the Business Analysis Body of Knowledge (BABOK) to be developed. I therefore still arrive at the conclusion that whilst prior domain knowledge does have advantages, it is certainly not everything it is promoted to be by the industry and it is not my preference in hiring someone for a role. The industry has not yet matured in this space, and those on the job hunt will share this frustration. So I urge you to keep educating the market with the benefits, as the industry agnostic Business Analyst has a lot of value to offer – as Business Analysts many of us know this, perhaps it will take the industry a while longer to catch up. However, with the modern pressures now on industry to innovate or perish, some will be more open to looking at the agnostic Business Analyst providing cross-industry innovation.

Don’t forget to leave your comments below.