There are no “best practices” only a bunch of good practices that work best in certain contexts. Do you agree? At last week’s SQuAD conference, this theme resounded over and over and one presenter even threw out the idea that as an IT profession, we are very limited in our set of tools and techniques, instead preferring to apply the same tools to different situations and hoping we get expected results.
I took this as a challenge and started thinking about what I could do to fill up my “bag of tricks” or “practices in context” to share with the “bridgers” who read this blog. So here’s your mission should you choose to accept it.
Write a post on your own blog or post a comment below that provides information about one tool, tip, technique, or method you’ve found helpful in “bridging the gap”. Provide some context around when the idea can be applied and consider telling us a story about when you applied it with great success.
Once you’ve published your thoughts, come back and post a link in the comments section, send me an email, or tweet it out with the hashtag #bagoftricks. I’ll pick up all links and add them to this post.
Here’s the running list:
- Pointing out your own mistakes and uncertainties during document review
- Identifying business processes and use cases to get a complete view of requirements, by Linda Erzah
- Using a domain model to create conceptual understanding
- Be a sounding board for ideas and requirements
- 7 Tips for Requirements Management, provided by Jama Software
- Developing a Common Information Model, by James Parnitzke
- Effectively managing multiple participants in a conference call
- Matrices Rock! or, Using a Matrix for Evaluation, Decision-Making, and Presentation by Jeffrey Harrell
- Wiki Way — Documentation without documents by Harris Lloyd-Levy
I know there’s more! Submit your posts today!
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
{ 6 comments… read them below or add one }
Gain as much technical knowledge as possible: data modeling, metadata, improve data querying skills and technical vocabulary
A very intriguing request!
As a business analyst, a tool in my bag of tricks that I’ve used often in addition to either functional decomposition diagrams or the process flow diagrams is the state transition diagram.
In my work, state transition diagram (std) comes in very handy in social services application or systems that are “Case based” and where formal “workflow” tools are not available. When creating, reviewing or simply presenting std to the user community (especially during requirements verification), I never refer to the diagram with its formal name. I often refer to the diagram as “case” flow diagrams (please do not confuse this with Use Cases) – here, a case refers to an actual “case folder” that a user maintains to track a “case” or and incident – example: a family seeking social services from an organization.
Using an std, we can look at the “triggers” or “actions” or events that occur for a case to move from one status (state) to another. It is also useful in answering the question why is this “case folder” not moving along?
One major benefits of an std is to clearly see where cycles emerge or are likely to emerge. Other benefits include: 1) existence of too many “states” or “Case Statuses”; 2) The presence of what I call “phantom” events – these are events that take up too much of the users time and effort but do not add useful information to the case or in moving the case along; 3) complexity of a business process. This third benefit becomes very useful during requirements validation in constructing case scenarios.
In summary then, State Transition Diagram is definitely one tool that is always in my bag of tricks.
In one of my projects, I had this complex task in a Bank BPO of analyzing huge data flow from mainframes to hundreds of users who would process the information to generate reports which will be used by certain downstream systems / analyst. The project was to implement BI solution by transforming the bank’s platform to use tools & technology in DW&BI space.
The team was struggling to get the flow and consolidate that to weekly, monthly & yearly reports. The task required interaction with tens of BPO staff without taking much of their time and yet understanding and documenting the data flow. The project went into red and the progress was escalated.
Being a damage control specialist, I had two weeks to do this and I was able to achieve this. The trick I used was Reverse Engineering.
What it requires is extreme dedication to the number crunching work and working backwards reading through all the macros and formulas used in these excel sheets until you reach the source file. Document these in different process flow diagrams and send these for validation to all relevant business users.
The benefits are as follows:
1. It saves lots of user time in explaining the flow and the data processing a group does.
2. It gives you in-depth understanding of the flow which makes your meeting time with the user quite effective and you can then restrict this to clarifications and probable enhancements requests.
3. You have documented and cross checked the data processing manually after the flow is documented in place which drastically reduces the scope for any significant corrections
4. In addition you have already delivered substantial part of your analysis to the business teams and IT teams when you have sent this for review, which would enable the IT team to start the thought process / work in parallel while you can still work on minor corrections or enhancements.
Now a days you do get tools that will give you all interfaces and data flow diagram but when you are dealing with hundreds of excel sheets, I believe reverse engineering is still the best bet.
Hi Nitin, Thank you for your detailed tip on reverse engineering. Sounds like a great way to help flesh out requirements when there is an existing, complicated process that’s unknown.
Thanks again for posting
Laura
I am following a discussion on another blog about the necessity for documentation. Some say documentation is not needed, some (as me) say we need it. However, something I’ve learned: documentation can be anything.
What Nitin described is a scenario well-know. I’ve been through similar ones. You have a system that one needs to change, and no documentation is available. Reverse engineering is, sometimes, the only option left to go forward with one given project. What does it have to do with documentation?
If any form of documentation was available, maybe that task could have been easier to accomplish. By document I include: a picture of a whiteboard, a scanned piece of paper, a text file with instructions on how to obtain the numbers and their source, etc.
You got the idea. We need to break free of the concept of document as something formal, distant. We need to put the ideas in some form of long lasting format, and make it easily searchable and traceable.
Another situation similar to Nitin’s example – though for me it was more an attempt to access facts without relying on SME assistance than reverse engineering.
About 20 years ago I started at a new employer as a Data Analyst with responsibility to prepare a data model for an application that had 2,000 tables and no documentation. As a newbie in a specialised industry it is not surprising that it was difficult to get access to subject matter experts for a task that was also not seen by them as being worthwhile.
So I changed my approach. I arranged to get a dump of the database metadata: all of the table and column definition data plus indexes and foreign key relationships etc.
From that I was able to:
- Prioritise and identify key tables and trace primary key fields to other tables.
- Establish what patterns and relationships existed (done manually as referential integrity not set up at all for performance reasons).
- Identify issues and anomalies to be followed up (and there were a few that surprised even the SMEs).
I learned a few things from that exercise:
- Respect the time of SMEs
- Try and access the facts
- Don’t give up
- Add value
A good outcome…
1. Produced data models for a substantial part of the system.
2. The SME’s and others learned the value of data modeling
3. Several unexpected bonuses (like when SME’s learned of comparisons between metadata downloads and how they documented ALL DB changes made in a release and not just the major ones the SMEs remembered).